From john.elwell@siemens-enterprise.com Wed Dec 2 05:40:07 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB7828C1C9 for ; Wed, 2 Dec 2009 05:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOzWpHSPMxaJ for ; Wed, 2 Dec 2009 05:40:06 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CFF3E28C0F0 for ; Wed, 2 Dec 2009 05:40:05 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-181646 for dispatch@ietf.org; Wed, 2 Dec 2009 14:39:57 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5162D23F01F9 for ; Wed, 2 Dec 2009 14:39:57 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Dec 2009 14:39:57 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Wed, 2 Dec 2009 14:39:55 +0100 Thread-Topic: Announcement of Last Call for SIP Forum UA config recommendation Thread-Index: AcpzVO7XPoaUkozeTDW2UkrbhqZW8w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Announcement of Last Call for SIP Forum UA config recommendation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 13:40:07 -0000 As I hinted at earlier, Last Call has now started on this - see the announc= ement below, sent on the UA config Task Group list. John ############################################# This notice serves to open the UA Config Task Group Last Call period on v20= of the UA config draft: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,3= 80/Itemid,261/ The period will close at 24.00 UTC on 2009-12-23. The SIPForum's Recommenda= tion process requires rough consensus of the active participants in the Tas= k Group. A Task Group Last Call is in the style of "speak now or forever ho= ld your peace" regarding the document under consideration. We consider an active participant to be an individual whom the Task Group L= ead can identify as having contributed substantive comments, text, or analy= sis to the Recommendation. To be considered in the consensus determination,= active participants are those who contributed at least one comment or body= text submittal to a pre-last-call draft of the Recommendation or participa= ted in recent conference calls. The Task Group Lead my choose to include re= cognized subject matter experts at his/her discretion. The Technical Workin= g Group Chair arbitrates on any disputes over whether an individual is an a= ctive participant or not. Per the SIP Forum Recommendation process, any SIP Forum Participant Member = may participate in the Task Group work, and there is no special dispensatio= n for Full Member companies with respect to the acceptance or rejection of= a proposed recommendation. Upon conclusion of the last call, we will have a follow-up conference call = on 2010-01-04 to discuss any issues raised during last call and discuss app= ropriate actions. Should there be no substantial issues surrounding v20, t= he Technical Work Group Chair will then make a determination to recommend t= he document to the SIPforum Board of Directors for approval as a SIPforum R= ecommendation. The procedure for balloting will be based on that used recently by the SIPc= onnect 1.1 Task Group: 1. Members reply by email to the list by the deadline, submitting their bal= lots and comments using the following spreadsheet file. http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,3= 81/Itemid,261/ =20 2. The ballot is submitted with the Subject line indicating the overall ver= dict (Approve, Disapprove, Abstain). Example: UA-Config Ballot - Approve. 3. An Approve or Abstain vote need not contain any comments, but if they ar= e included they are non-binding, in other words a change to the document is= not necessarily required for approval. 4. A Disapprove vote MUST including comments citing specific sections, text= and proposed text changes. 5. The enclosed ballot spreadsheet file name should includes the balloter's= initials or name (so as to avoid overwriting someone else's ballot when it= is saved). =20 Example: ua-config_ballot_elwell. 6. Comments MUST provide specific changes to the text which would satisfy t= he objection. =20 7. Along with the enclosure, a summary should be included in the body of th= e ballot response email (see below).=20 _____ I Approve (may attach comments in spreadsheet)=20 _____ I Disapprove (must attach comments in spreadsheet)=20 _____ I Abstain for the following reasons (may attach comments in spreadshe= et): ________ Lack of Time ________ Lack of Expertise ________ Other: _______________________________________________ ____________________________________________ (Name) ____________________________________________ (E-Mail Address) From dwing@cisco.com Wed Dec 2 18:00:37 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543A33A69C5; Wed, 2 Dec 2009 18:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9jEA7-FY-tD; Wed, 2 Dec 2009 18:00:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 373443A69D2; Wed, 2 Dec 2009 18:00:36 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACWrFktAZnwM/2dsb2JhbACKKLVql2yEMQSBag X-IronPort-AV: E=Sophos;i="4.47,332,1257120000"; d="scan'208";a="71719050" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2009 02:00:27 +0000 Received: from dwingwxp01 ([10.32.240.195]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB320Q7j006075; Thu, 3 Dec 2009 02:00:26 GMT From: "Dan Wing" To: , Date: Wed, 2 Dec 2009 18:00:25 -0800 Message-ID: <03ea01ca73bc$6271c6f0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acpzt/rQ69a8xjf4TxOGhT82PwXl9wABBhhg Cc: draft-ietf-sipping-nat-scenarios@tools.ietf.org, draft-ietf-sipping-v6-transition@tools.ietf.org Subject: [dispatch] FW: [BEHAVE] WGLC: draft-ietf-behave-turn-ipv6-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 02:00:37 -0000 Dispatch, MMUSIC (home of ICE), and SIP v6-transition-related authors: BEHAVE just started a two-week WGLC on TURN-IPv6. Please send comments to behave@ietf.org or to draft-ietf-behave-turn-ipv6@tools.ietf.org. -d -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing Sent: Wednesday, December 02, 2009 5:36 PM To: behave@ietf.org Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org Subject: [BEHAVE] WGLC: draft-ietf-behave-turn-ipv6-07 We are starting a two-week working group last call for "Traversal Using Relays around NAT (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6-07, http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6-07 Please send comments to the list or the authors. WGLC for this document will end on Wednesday, December 16. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From salvatore.loreto@ericsson.com Fri Dec 4 01:08:47 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C353A695C for ; Fri, 4 Dec 2009 01:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GJe01izdvlk for ; Fri, 4 Dec 2009 01:08:46 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4B8613A692D for ; Fri, 4 Dec 2009 01:08:45 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-91-4b18d1701cdf Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DE.12.02357.071D81B4; Fri, 4 Dec 2009 10:08:00 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 10:07:52 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 10:07:52 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 449DF2742 for ; Fri, 4 Dec 2009 11:07:52 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 027FD21A31 for ; Fri, 4 Dec 2009 11:07:52 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AE3C3219D0 for ; Fri, 4 Dec 2009 11:07:51 +0200 (EET) Message-ID: <4B18D167.90805@ericsson.com> Date: Fri, 04 Dec 2009 11:07:51 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: IETF Dispatch References: <4B0EC34C.2070505@ericsson.com> In-Reply-To: <4B0EC34C.2070505@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 04 Dec 2009 09:07:52.0498 (UTC) FILETIME=[42662120:01CA74C1] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Disaggregated media X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:08:47 -0000 Hi there, at the last IETF meeting in Hiroshima, the Diasaggregated Media Charter has received interest to be chartered, but subject to getting interest also on the mailing list. So if you are interested in this issue and especially in actively working on it, please respond to this mail. thanks Sal From spromano@unina.it Fri Dec 4 01:57:49 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E47C28C0DC for ; Fri, 4 Dec 2009 01:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttTmR31di1lm for ; Fri, 4 Dec 2009 01:57:48 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 4251328C0D6 for ; Fri, 4 Dec 2009 01:57:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nB49vZMT003230; Fri, 4 Dec 2009 10:57:35 +0100 Received: from dhcp215.rm.cnr.it (dhcp215.rm.cnr.it [150.146.113.215]) by webmail.unina.it (Horde MIME library) with HTTP; Fri, 04 Dec 2009 10:57:35 +0100 Message-ID: <20091204105735.7txvxfdtcsk4ccow@webmail.unina.it> Date: Fri, 04 Dec 2009 10:57:35 +0100 From: spromano@unina.it To: Salvatore Loreto References: <4B0EC34C.2070505@ericsson.com> <4B18D167.90805@ericsson.com> In-Reply-To: <4B18D167.90805@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it X-Virus-Status: Clean Cc: IETF Dispatch Subject: Re: [dispatch] Disaggregated media X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:57:49 -0000 Hi Salvatore, I strongly support this initiative, and our team at the University of =20 Napoli is ready to actively contribute to this work. Cheers, Simon Quoting Salvatore Loreto : > Hi there, > > at the last IETF meeting in Hiroshima, > the Diasaggregated Media Charter has received interest to be chartered, > but subject to getting interest also on the mailing list. > > So if you are interested in this issue and especially in actively > working on it, > please respond to this mail. > > thanks > Sal > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From pkyzivat@cisco.com Fri Dec 4 05:52:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096F13A68E0 for ; Fri, 4 Dec 2009 05:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmg8Rqlwx6an for ; Fri, 4 Dec 2009 05:51:59 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1F96D3A6806 for ; Fri, 4 Dec 2009 05:51:59 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFABajGEtAZnwM/2dsb2JhbACZJKYWl0WEMwQ X-IronPort-AV: E=Sophos;i="4.47,341,1257120000"; d="scan'208";a="72092342" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Dec 2009 13:51:50 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB4Dpo13008281; Fri, 4 Dec 2009 13:51:50 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 08:51:50 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 08:51:49 -0500 Message-ID: <4B1913F5.3090200@cisco.com> Date: Fri, 04 Dec 2009 08:51:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4B0EC34C.2070505@ericsson.com> <4B18D167.90805@ericsson.com> In-Reply-To: <4B18D167.90805@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2009 13:51:49.0261 (UTC) FILETIME=[ED19DBD0:01CA74E8] Cc: IETF Dispatch Subject: Re: [dispatch] Disaggregated media X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:52:00 -0000 Salvatore Loreto wrote: > Hi there, > > at the last IETF meeting in Hiroshima, > the Diasaggregated Media Charter has received interest to be chartered, > but subject to getting interest also on the mailing list. > > So if you are interested in this issue and especially in actively > working on it, > please respond to this mail. I'm interested. I haven't got a lot of time to spend on it, but will contribute as best I can. Thanks, Paul From RIFATYU@nortel.com Fri Dec 4 05:58:11 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9ED3A68A2 for ; Fri, 4 Dec 2009 05:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNQgAUG+CY0F for ; Fri, 4 Dec 2009 05:58:11 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B7D0B3A6868 for ; Fri, 4 Dec 2009 05:58:10 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nB4Dvv608936; Fri, 4 Dec 2009 13:57:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Dec 2009 08:57:36 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02A3CC42@zcarhxm2.corp.nortel.com> In-Reply-To: <4B18D167.90805@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated media Thread-Index: Acp0wWD+49V3Ld5vS0ObQ2wpiLIuKwAJ/Bdw References: <4B0EC34C.2070505@ericsson.com> <4B18D167.90805@ericsson.com> From: "Rifaat Shekh-Yusef" To: "Salvatore Loreto" , "IETF Dispatch" Subject: Re: [dispatch] Disaggregated media X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:58:11 -0000 Hi Salvatore, I am interested and should be able to active and hopefully contribute. Regards, Rifaat =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto Sent: Friday, December 04, 2009 4:08 AM To: IETF Dispatch Subject: [dispatch] Disaggregated media Hi there, at the last IETF meeting in Hiroshima, the Diasaggregated Media Charter has received interest to be chartered, but subject to getting interest also on the mailing list. So if you are interested in this issue and especially in actively working on it, please respond to this mail. thanks Sal _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Fri Dec 4 08:13:07 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F393A695A for ; Fri, 4 Dec 2009 08:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxttbqxhsA3V for ; Fri, 4 Dec 2009 08:13:06 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id A2FAF3A6864 for ; Fri, 4 Dec 2009 08:13:06 -0800 (PST) Received: from [192.168.216.97] ([216.13.45.138]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Mdb4G-1NSkPU3NGu-00PNNt; Fri, 04 Dec 2009 11:12:57 -0500 From: Peter Musgrave Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 4 Dec 2009 11:12:55 -0500 Message-Id: To: dispatch@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Provags-ID: V01U2FsdGVkX19jSLIaeo/JXCUSvtvUgdJ073PeLllkxalWj5y Ppqgr5maV5+q3K/cy4H8UMpDs72w6ihZkf3v9RnvPnG3/c0MCD bOZ74Fb5KOJ6ZZhT2K8IravdbnT6UHOnwiAYvyNcKE= Subject: Re: [dispatch] Disaggregated Media X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 16:14:01 -0000 Hi, I am interested in this issue and available to contribute. In fact, I am facing this very issue at the moment! Cheers, Peter Musgrave From shida@ntt-at.com Fri Dec 4 22:19:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B043A68C6 for ; Fri, 4 Dec 2009 22:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjfOU2IOKE7D for ; Fri, 4 Dec 2009 22:19:23 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.212.20]) by core3.amsl.com (Postfix) with SMTP id 38B573A6405 for ; Fri, 4 Dec 2009 22:19:16 -0800 (PST) Received: (qmail 11634 invoked from network); 5 Dec 2009 06:31:51 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway02.websitewelcome.com with SMTP; 5 Dec 2009 06:31:51 -0000 Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:61897 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGnym-00073g-H0; Sat, 05 Dec 2009 00:18:52 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4B18D167.90805@ericsson.com> Date: Sat, 5 Dec 2009 15:19:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B0EC34C.2070505@ericsson.com> <4B18D167.90805@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: IETF Dispatch Subject: Re: [dispatch] Disaggregated media X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 06:19:38 -0000 I am interested and willing to contribute.=20 Regards Shida On Dec 4, 2009, at 6:07 PM, Salvatore Loreto wrote: > Hi there, >=20 > at the last IETF meeting in Hiroshima, > the Diasaggregated Media Charter has received interest to be = chartered, > but subject to getting interest also on the mailing list. >=20 > So if you are interested in this issue and especially in actively = working on it, > please respond to this mail. >=20 > thanks > Sal >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Sat Dec 5 11:09:02 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565F63A67EF for ; Sat, 5 Dec 2009 11:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdlL4HW3Pzav for ; Sat, 5 Dec 2009 11:09:01 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 58BE53A672F for ; Sat, 5 Dec 2009 11:09:00 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-cd-4b1aafc1ac2c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5C.77.02357.1CFAA1B4; Sat, 5 Dec 2009 20:08:50 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Dec 2009 20:08:35 +0100 Received: from [131.160.126.151] ([131.160.126.151]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Dec 2009 20:08:34 +0100 Message-ID: <4B1AAF15.7080804@ericsson.com> Date: Sat, 05 Dec 2009 21:05:57 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH References: <4B0EBC63.3010007@ericsson.com> In-Reply-To: <4B0EBC63.3010007@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2009 19:08:34.0847 (UTC) FILETIME=[57B9E2F0:01CA75DE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Draft minutes of the main DISPATCH session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 19:09:02 -0000 Hi, we have already added the minutes of two of the three ad-hoc meetings. You can fetch them from the same URI (make sure you refresh the page in your browser). As soon as we receive the minutes of the remaining ad-hoc, we will add them as well. Cheers, Gonzalo Gonzalo Camarillo wrote: > Folks, > > here you have the draft minutes of the main DISPATCH session. > > http://www.ietf.org/proceedings/09nov/minutes/dispatch.txt > > Comments are welcome. > > We are working with the cochairs of the three ad-hoc meetings we had in > Japan to prepare the minutes of those meetings as well (the minutes will > be based on the raw notes that have already been distributed). As soon > as those are ready, we will append them to the main DISPATCH minutes > above so that everything is archived at the IETF. > > Cheers, > > Gonzalo > DISPATCH co-chair From gonzalo.camarillo@ericsson.com Sun Dec 6 04:06:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52423A683B for ; Sun, 6 Dec 2009 04:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC9P3QVGMyKR for ; Sun, 6 Dec 2009 04:06:55 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 809513A6832 for ; Sun, 6 Dec 2009 04:06:54 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-31-4b1b9e5336ff Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 84.18.14961.35E9B1B4; Sun, 6 Dec 2009 13:06:43 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 13:06:43 +0100 Received: from [131.160.126.151] ([131.160.126.151]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 13:06:43 +0100 Message-ID: <4B1B9E52.3020709@ericsson.com> Date: Sun, 06 Dec 2009 14:06:42 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH Content-Type: multipart/mixed; boundary="------------070605000409010309000304" X-OriginalArrivalTime: 06 Dec 2009 12:06:43.0167 (UTC) FILETIME=[9333C6F0:01CA766C] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Session recording charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 12:06:56 -0000 This is a multi-part message in MIME format. --------------070605000409010309000304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, the proponents of the session recording topic have updated their charter proposal per the discussions in Hiroshima (see attachment). We intend to discuss this charter with our ADs shortly. Let us know if you have any comments on the updated charter. Thanks, Gonzalo DISPATCH co-chair --------------070605000409010309000304 Content-Type: text/plain; name="IETF SRP Charter - draft 20091120.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IETF SRP Charter - draft 20091120.txt" Session Recording Protocol - Working Group Charter The Session Recording Protocol (SRP) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder. Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. The Session Recording problem presents certain unique requirements that are not addressed in the current SIP protocol specification. These include requirements such as the need for a distinction between the session that is being recorded versus the session that has been established for recording. Privacy and security of conversations are significant concerns. The working group will make sure that any protocol specified addresses these concerns and provides mechanisms to alert users to the fact that a session they are particpating in is being recorded. The working group must take care that the session recording requirments and protocol does not conflict with the IETF statement on wiretapping contained in RFC 2804. The SRP Working Group will thoroughly identify use cases, provide example system architectures and deployment scenarios, and define requirements. The scope of the activity includes: * Recorder Control * Session metadata content and format * Security mechanisms, including transport and media encryption * Privacy concerns, including end-user notification * Negotiation of recording media streams The group will define these issues and rationalize with IETF standards and practices. This includes encryption, NAT traversal, SIP-enabled firewalls, authorization, and security. The group will produce: * Updated Requirements, Use Cases, Architecture draft * Specification for Session Recording Protocol Timeline: Apr 2010 Use Cases and Requirements to IESG as Informational Draft Nov 2010 Architecture to IESG as Informational Draft Nov 2010 Submit protocol draft to IESG as standards track --------------070605000409010309000304-- From audet.francois@gmail.com Sun Dec 6 07:13:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5903A3A687D for ; Sun, 6 Dec 2009 07:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWyeEDNzY91f for ; Sun, 6 Dec 2009 07:13:06 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 89DEA3A681A for ; Sun, 6 Dec 2009 07:13:05 -0800 (PST) Received: by ywh1 with SMTP id 1so7283073ywh.18 for ; Sun, 06 Dec 2009 07:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=j2+r7uJ7jgTVwqM9yr+GtS6EmcEEJH4X7XHoUF2CoGY=; b=UV+usphwxHLa597npJNDFQycoj2XmUgRa9fZDxew7g0iDZ8Sq5x4MABhaRGHdjv/eQ 1n2uI6a+4obsmElHwdUUk61/7y5sIGpqIo44l9Bi5p4B4THv+e14J3uQwfHy/bPtCfJM VQu9UHlLzOdLGDTrGR9fYNIwT4a+/knIsCiB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=wQNsuWo2ExZQJUh0M5lire1B6VcnFa7Ou2/J7jbgHWQgeCmIxpBczr92zcG6oJ0G8h /R8H4wnyZHGQ5sRWXRrpIqCIKZazTA0CVfnag7zgpf52u2/6XEkpWFjKptZhohAC1nwB 0TyDYU9vMRJ16dPWMj2IJnppDgm/8t0cvKGvQ= Received: by 10.90.23.40 with SMTP id 40mr9068563agw.65.1260112372963; Sun, 06 Dec 2009 07:12:52 -0800 (PST) Received: from ?192.168.15.102? (adsl-75-36-222-80.dsl.pltn13.sbcglobal.net [75.36.222.80]) by mx.google.com with ESMTPS id 8sm2196358yxg.60.2009.12.06.07.12.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Dec 2009 07:12:52 -0800 (PST) References: <4B1B9E52.3020709@ericsson.com> Message-Id: <81046C80-3F4F-4452-9885-D68CF8958259@gmail.com> From: Francois AUDET To: Gonzalo Camarillo In-Reply-To: <4B1B9E52.3020709@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 6 Dec 2009 07:12:47 -0800 Cc: DISPATCH Subject: Re: [dispatch] Session recording charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 15:13:10 -0000 Looks good to me. On Dec 6, 2009, at 4:06, Gonzalo Camarillo wrote: > Folks, > > the proponents of the session recording topic have updated their > charter proposal per the discussions in Hiroshima (see attachment). > We intend to discuss this charter with our ADs shortly. Let us know > if you have any comments on the updated charter. > > Thanks, > > Gonzalo > DISPATCH co-chair > > > > > Session Recording Protocol - Working Group Charter > > The Session Recording Protocol (SRP) working group is chartered to > define a SIP-based protocol > for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such > as call centers and financial trading floors. In some of these > environments, all calls must > be recorded for regulatory and compliance reasons. In others, calls > may be recorded for quality > control, business analytics, or consumer protection. Recording is > typically done by sending a > copy of the media to the recording devices. The working group will > determine requirements and > produce a specification for a protocol that will manage delivery of > media from an end-point that > originates media, or that has access to it, to a recording device. > PBX and recording vendors > today implement proprietary, incompatible mechanisms to facilitate > recording. A standard protocol > will reduce the complexity and cost of providing such recording > services. > > The Session Recording problem presents certain unique requirements > that are not addressed in the > current SIP protocol specification. These include requirements such > as the need for a distinction > between the session that is being recorded versus the session that > has been established for recording. > > Privacy and security of conversations are significant concerns. The > working group will make sure > that any protocol specified addresses these concerns and provides > mechanisms to alert users to > the fact that a session they are particpating in is being recorded. > > The working group must take care that the session recording > requirments and protocol does not > conflict with the IETF statement on wiretapping contained in RFC 2804. > > > The SRP Working Group will thoroughly identify use cases, provide > example system architectures > and deployment scenarios, and define requirements. > > The scope of the activity includes: > > * Recorder Control > * Session metadata content and format > * Security mechanisms, including transport and media encryption > * Privacy concerns, including end-user notification > * Negotiation of recording media streams > > The group will define these issues and rationalize with IETF > standards and practices. This includes > encryption, NAT traversal, SIP-enabled firewalls, authorization, and > security. > > The group will produce: > > * Updated Requirements, Use Cases, Architecture draft > * Specification for Session Recording Protocol > > Timeline: > > Apr 2010 Use Cases and Requirements to IESG as Informational Draft > > Nov 2010 Architecture to IESG as Informational Draft > > Nov 2010 Submit protocol draft to IESG as standards track > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From victor.pascual.avila@gmail.com Sun Dec 6 07:51:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A023A67E6 for ; Sun, 6 Dec 2009 07:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l-MfK8BuGqb for ; Sun, 6 Dec 2009 07:51:01 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 90FA63A681A for ; Sun, 6 Dec 2009 07:51:00 -0800 (PST) Received: by bwz23 with SMTP id 23so3060310bwz.29 for ; Sun, 06 Dec 2009 07:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZaaAWykecqKyOv/QOmBmWsg7ZxqwX6bjYs14k0qTecU=; b=ilL5JYa8teZP2l5j6c0frl5jDjwV38iTL7uh2UZ6oh2l+5Gz+OAa7UUI7MjAK1QZIg JCcCJMR8h4J/ervz8xqp9bhK6I256i9kdJKe+4u2g02FlOYnMaLwzVLDTosxNSdCKXQF HCY10rVKYuvTPsmtcGFGeFzUb2rYXDVbK6nnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qtecUD50LY1I9EPKXfWwdBAGzP4JpLw4Ws/+PhTFg8vPtMY0r0XNR0XnGqNiqasJdR izKjb8bZdo7wzBZFo2Bv4nV3pN2vYiA709GNKjLBDvz7IJMfsXhmxrNX7fktEi132sR3 2DKAiQfcHdnR5FUy39UPcvMyHBH4iYKdJ/YyY= MIME-Version: 1.0 Received: by 10.204.33.6 with SMTP id f6mr5895928bkd.37.1260114646771; Sun, 06 Dec 2009 07:50:46 -0800 (PST) In-Reply-To: <81046C80-3F4F-4452-9885-D68CF8958259@gmail.com> References: <4B1B9E52.3020709@ericsson.com> <81046C80-3F4F-4452-9885-D68CF8958259@gmail.com> Date: Sun, 6 Dec 2009 16:50:46 +0100 Message-ID: <618e24240912060750h63acc905g8cbe54c16d6caf10@mail.gmail.com> From: Victor Pascual Avila To: Francois AUDET Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Session recording charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 15:51:04 -0000 +1 -Victor On Sunday, December 6, 2009, Francois AUDET wrot= e: > > Looks good to me. > > > On Dec 6, 2009, at 4:06, Gonzalo Camarillo wrote: > > > Folks, > > the proponents of the session recording topic have updated their charter = proposal per the discussions in Hiroshima (see attachment). We intend to di= scuss this charter with our ADs shortly. Let us know if you have any commen= ts on the updated charter. > > Thanks, > > Gonzalo > DISPATCH co-chair > > > > > Session Recording Protocol - Working Group Charter > > The Session Recording Protocol (SRP) working group is chartered to define= a SIP-based protocol > for controlling a session (media) recorder. > > Session recording is a critical requirement in many business communicatio= ns environments such > as call centers and financial trading floors. =C2=A0In some of these envi= ronments, all calls must > be recorded for regulatory and compliance reasons. =C2=A0In others, calls= may be recorded for quality > control, business analytics, or consumer protection. =C2=A0Recording is t= ypically done by sending a > copy of the media to the recording devices. =C2=A0The working group will = determine requirements and > produce a specification for a protocol that will manage delivery of media= from an end-point that > originates media, or that has access to it, to a recording device. PBX an= d recording vendors > today implement proprietary, incompatible mechanisms to facilitate record= ing. A standard protocol > will reduce the complexity and cost of providing such recording services. > > The Session Recording problem presents certain unique requirements that a= re not addressed in the > current SIP protocol specification. These include requirements such as th= e need for a distinction > between the session that is being recorded versus the session that has be= en established for recording. > > Privacy and security of conversations are significant concerns. The worki= ng group will make sure > that any protocol specified addresses these concerns and provides mechani= sms to alert users to > the fact that a session they are particpating in is being recorded. > > The working group must take care that the session recording requirments a= nd protocol does not > conflict with the IETF statement on wiretapping contained in RFC 2804. > > > The SRP Working Group will thoroughly identify use cases, provide example= system architectures > and deployment scenarios, and define requirements. > > The scope of the activity includes: > > =C2=A0* Recorder Control > =C2=A0* Session metadata content and format > =C2=A0* Security mechanisms, including transport and media encryption > =C2=A0* Privacy concerns, including end-user notification > =C2=A0* Negotiation of recording media streams > > The group will define these issues and rationalize with IETF standards an= d practices. This includes > encryption, NAT traversal, SIP-enabled firewalls, authorization, and secu= rity. > > The group will produce: > > =C2=A0* Updated Requirements, Use Cases, Architecture draft > =C2=A0* Specification for Session Recording Protocol > > Timeline: > > =C2=A0Apr 2010 =C2=A0 Use Cases and Requirements to IESG as Informationa= l Draft > > =C2=A0Nov 2010 =C2=A0 Architecture to IESG as Informational Draft > > =C2=A0Nov 2010 =C2=A0 Submit protocol draft to IESG as standards track > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Victor Pascual =C3=81vila From gonzalo.camarillo@ericsson.com Sun Dec 6 23:22:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C191628C10E for ; Sun, 6 Dec 2009 23:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q8L2lgd97Vz for ; Sun, 6 Dec 2009 23:22:00 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 971013A6863 for ; Sun, 6 Dec 2009 23:22:00 -0800 (PST) X-AuditID: c1b4fb3e-b7bc9ae000005cee-9e-4b1cad0d7d56 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 21.E4.23790.D0DAC1B4; Mon, 7 Dec 2009 08:21:49 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 08:21:49 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 08:21:48 +0100 Message-ID: <4B1CAD0C.7010508@ericsson.com> Date: Mon, 07 Dec 2009 09:21:48 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH References: <4B0EBC63.3010007@ericsson.com> <4B1AAF15.7080804@ericsson.com> In-Reply-To: <4B1AAF15.7080804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2009 07:21:48.0942 (UTC) FILETIME=[F0A9CAE0:01CA770D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Draft minutes of the main DISPATCH session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 07:22:02 -0000 Hi, we have now added links to the audio files from the main session. Big thanks to Vijay for preparing the files! Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, > > we have already added the minutes of two of the three ad-hoc meetings. > You can fetch them from the same URI (make sure you refresh the page in > your browser). As soon as we receive the minutes of the remaining > ad-hoc, we will add them as well. > > Cheers, > > Gonzalo > > Gonzalo Camarillo wrote: >> Folks, >> >> here you have the draft minutes of the main DISPATCH session. >> >> http://www.ietf.org/proceedings/09nov/minutes/dispatch.txt >> >> Comments are welcome. >> >> We are working with the cochairs of the three ad-hoc meetings we had >> in Japan to prepare the minutes of those meetings as well (the minutes >> will be based on the raw notes that have already been distributed). As >> soon as those are ready, we will append them to the main DISPATCH >> minutes above so that everything is archived at the IETF. >> >> Cheers, >> >> Gonzalo >> DISPATCH co-chair > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.musgrave@magorcorp.com Mon Dec 7 05:05:30 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1A928C122 for ; Mon, 7 Dec 2009 05:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXT6j7zBAm0L for ; Mon, 7 Dec 2009 05:05:29 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id EC1123A683B for ; Mon, 7 Dec 2009 05:05:28 -0800 (PST) Received: from [192.168.216.97] ([216.13.45.138]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lij5x-1NneZb1vB7-00cWnQ; Mon, 07 Dec 2009 08:05:18 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Peter Musgrave In-Reply-To: <618e24240912060750h63acc905g8cbe54c16d6caf10@mail.gmail.com> Date: Mon, 7 Dec 2009 08:05:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1B9E52.3020709@ericsson.com> <81046C80-3F4F-4452-9885-D68CF8958259@gmail.com> <618e24240912060750h63acc905g8cbe54c16d6caf10@mail.gmail.com> To: Victor Pascual Avila X-Mailer: Apple Mail (2.1077) X-Provags-ID: V01U2FsdGVkX1/ixaeDWSfea3iV8C/+j7UEa0jVUcGMY1+J6UI Vb5vn885YOc4fjRYJ0Aox+j1pvKbCV8c1hU7PPJvVinAl0dT+t Dm2DP23lemc4sDiaTpy7U1JWhXZV92Xq5vzS4WDoPw= Cc: DISPATCH Subject: Re: [dispatch] Session recording charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 13:05:30 -0000 n++; Peter On 2009-12-06, at 10:50 AM, Victor Pascual Avila wrote: > +1 > -Victor >=20 > On Sunday, December 6, 2009, Francois AUDET = wrote: >>=20 >> Looks good to me. >>=20 >>=20 >> On Dec 6, 2009, at 4:06, Gonzalo Camarillo = wrote: >>=20 >>=20 >> Folks, >>=20 >> the proponents of the session recording topic have updated their = charter proposal per the discussions in Hiroshima (see attachment). We = intend to discuss this charter with our ADs shortly. Let us know if you = have any comments on the updated charter. >>=20 >> Thanks, >>=20 >> Gonzalo >> DISPATCH co-chair >>=20 >>=20 >>=20 >>=20 >> Session Recording Protocol - Working Group Charter >>=20 >> The Session Recording Protocol (SRP) working group is chartered to = define a SIP-based protocol >> for controlling a session (media) recorder. >>=20 >> Session recording is a critical requirement in many business = communications environments such >> as call centers and financial trading floors. In some of these = environments, all calls must >> be recorded for regulatory and compliance reasons. In others, calls = may be recorded for quality >> control, business analytics, or consumer protection. Recording is = typically done by sending a >> copy of the media to the recording devices. The working group will = determine requirements and >> produce a specification for a protocol that will manage delivery of = media from an end-point that >> originates media, or that has access to it, to a recording device. = PBX and recording vendors >> today implement proprietary, incompatible mechanisms to facilitate = recording. A standard protocol >> will reduce the complexity and cost of providing such recording = services. >>=20 >> The Session Recording problem presents certain unique requirements = that are not addressed in the >> current SIP protocol specification. These include requirements such = as the need for a distinction >> between the session that is being recorded versus the session that = has been established for recording. >>=20 >> Privacy and security of conversations are significant concerns. The = working group will make sure >> that any protocol specified addresses these concerns and provides = mechanisms to alert users to >> the fact that a session they are particpating in is being recorded. >>=20 >> The working group must take care that the session recording = requirments and protocol does not >> conflict with the IETF statement on wiretapping contained in RFC = 2804. >>=20 >>=20 >> The SRP Working Group will thoroughly identify use cases, provide = example system architectures >> and deployment scenarios, and define requirements. >>=20 >> The scope of the activity includes: >>=20 >> * Recorder Control >> * Session metadata content and format >> * Security mechanisms, including transport and media encryption >> * Privacy concerns, including end-user notification >> * Negotiation of recording media streams >>=20 >> The group will define these issues and rationalize with IETF = standards and practices. This includes >> encryption, NAT traversal, SIP-enabled firewalls, authorization, and = security. >>=20 >> The group will produce: >>=20 >> * Updated Requirements, Use Cases, Architecture draft >> * Specification for Session Recording Protocol >>=20 >> Timeline: >>=20 >> Apr 2010 Use Cases and Requirements to IESG as Informational Draft >>=20 >> Nov 2010 Architecture to IESG as Informational Draft >>=20 >> Nov 2010 Submit protocol draft to IESG as standards track >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > --=20 > Victor Pascual =C1vila > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From kpfleming@digium.com Mon Dec 7 10:49:23 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4603C3A6817 for ; Mon, 7 Dec 2009 10:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLGFqh5u0GkB for ; Mon, 7 Dec 2009 10:49:22 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 6B1673A67A8 for ; Mon, 7 Dec 2009 10:49:22 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NHidz-0004gR-HI; Mon, 07 Dec 2009 12:49:11 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 788DA29E0001; Mon, 7 Dec 2009 12:49:11 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n91ceYo8m2T; Mon, 7 Dec 2009 12:49:11 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 23B1CDFC827; Mon, 7 Dec 2009 12:49:11 -0600 (CST) Message-ID: <4B1D4E26.6080204@digium.com> Date: Mon, 07 Dec 2009 12:49:10 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Peter Musgrave References: <4B1B9E52.3020709@ericsson.com> <81046C80-3F4F-4452-9885-D68CF8958259@gmail.com> <618e24240912060750h63acc905g8cbe54c16d6caf10@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Session recording charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 18:49:23 -0000 Peter Musgrave wrote: > n++; /me fails at coming up with an even-cleverer metaphor for expressing agreement n++; -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From andrew.hutton@siemens-enterprise.com Tue Dec 8 08:19:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8C53A68A4 for ; Tue, 8 Dec 2009 08:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRyBVr+CQk7y for ; Tue, 8 Dec 2009 08:19:35 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A40DC3A68D1 for ; Tue, 8 Dec 2009 08:19:25 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-231061; Tue, 8 Dec 2009 17:19:14 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 2E0B81EB822E; Tue, 8 Dec 2009 17:19:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 8 Dec 2009 17:19:14 +0100 From: "Hutton, Andrew" To: "dispatch@ietf.org" Date: Tue, 8 Dec 2009 17:19:16 +0100 Thread-Topic: Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: Acp4IjASM9oqQPovQgCIZ12IJxj4eg== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_101C6067BEC68246B0C3F6843BCCC1E306847E29DEMCHP058Agloba_" MIME-Version: 1.0 Cc: "Leon.Portman@nice.com" , "Jain, Rajnish" , "HKaplan@acmepacket.com" Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 16:19:36 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E306847E29DEMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments on the session recording requirements draft draft-rehor-dispa= tch-session-recording-req-00 1. The introduction states that the "recording sessions can be of any kind = such as voice, video and instant messaging". I think it would be sensible t= o restrict the scope to RTP based media (I.e. voice and video) and possibly= move out the instant messaging recording as a separate work item if needed= . 2. The introduction contains a statement regarding "draft-wing-sipping-srtp= -key". This draft describes a mechanism for disclosing SRTP session keys to= intermediaries which is not relevant to this work because the scope of the= new work relates to the case when an endpoint forks media to the recorder = and therefore uses separate SRTP keys. 3. I think the last sentence of the introduction (I.e. "There are already I= ETF working groups ....") should be removed as it relates to IETF process a= nd is not relevant for the draft. 4. Section 3. The definition of a "Recording Client" states that the RC "is= a SIP User Agent (UA) or a "Back-to-Back-User-Agent (B2BUA) that acts as t= he source of the recorded media". I think we should remove the B2BUA refere= nce as it is not relevant what is important is simply that the RC is a SIP = UA that acts as the source of the media. 5. Section 4, Use case 6. Typo "agents and agents and..". 6. Section 5. I don't see the need for Figure 2 as it really seems to be lo= gically the same as Figure 1. The recording control and media both have to = originate from the recording client and therefore in Figure 2 it is the com= bination of the B2BUA and the A/S (Probably also a B2BUA) which make up the= RC. 7. Section 5. Figure 3 needs to show the location of the RC. 8. Section 5. Figure 4. I find it difficult to see how the "Recording Contr= ol" and the "Recorded Media" can be split in this way as they both need to = be handled by the RC. Since the diagram shows SIP as the protocol between U= A-C and the A/S then I assume that this SIP interface would need to be enha= nced with something to provide the recording control which does not seem to= make sense. 9. Section 5. Figure 4. Also needs to show the location of the RC. 10. Section 6 Req-021. This does not look like a requirement to me but some= kind of implementation limitation and may not even be possible as I don't = see how SRTP could be made to work in this way. The definition of the RC st= ates that it is the source of the media which seems incompatible with this = requirement. 11. Section 6 Req-030. This does not sound like an SRP requirement. Regards Andy Andrew Hutton Office of the CTO. Siemens Enterprise Communications. --_000_101C6067BEC68246B0C3F6843BCCC1E306847E29DEMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Some comm= ents on the=20 session recording requirements draft draft-rehor-dispatch-session-recording-req-00
 
1. The in= troduction=20 states that the "recording sessions can be of any kind such as voice, video= and=20 instant messaging". I think it would be sensible to restrict the scope to R= TP=20 based media (I.e. voice and video) and possibly move out the instant messag= ing=20 recording as a separate work item if needed.
 
2. The in= troduction=20 contains a statement regarding "draft-wing-sipping-srtp-key". This draft=20 describes a mechanism for disclosing SRTP session keys to intermediaries wh= ich=20 is not relevant to this work because the scope of the new work relates to t= he=20 case when an endpoint forks media to the recorder and therefore uses separa= te=20 SRTP keys.
 
3. I thin= k the last=20 sentence of the introduction (I.e. "There are alrea= dy IETF=20 working groups ....") should be removed as it relates to IETF process = and=20 is not relevant for the draft.
 
4. Sectio= n 3. The=20 definition of a "Recording Client" states that the RC "is a SIP User Agent = (UA)=20 or a "Back-to-Back-User-Agent (B2BUA) that acts as the source of the record= ed=20 media". I think we should remove the B2BUA reference as it is not relevant = what=20 is important is simply that the RC is a SIP UA that acts as the source of t= he=20 media.
 
5. Sectio= n 4, Use=20 case 6. Typo "agents and agents and..".
 
6. Sectio= n 5. I=20 don't see the need for Figure 2 as it really seems to be logically the same= as=20 Figure 1. The recording control and media both have to originate from = the=20 recording client and therefore in Figure 2 it is the combination of the B2B= UA=20 and the A/S (Probably also a B2BUA) which make up the RC.
 
7. Sectio= n 5. Figure=20 3 needs to show the location of the RC.
 
8. Sectio= n 5. Figure=20 4. I find it difficult to see how the "Recording Control" and the "Recorded= =20 Media" can be split in this way as they both need to be handled by the RC. = Since=20 the diagram shows SIP as the protocol between UA-C and the A/S then I assum= e=20 that this SIP interface would need to be enhanced with something to provide= the=20 recording control which does not seem to make sense.
 
9. Sectio= n 5. Figure=20 4. Also needs to show the location of the RC.
 
10. Secti= on 6=20 Req-021. This does not look like a requirement to me but some kind of=20 implementation limitation and may not even be possible as I don't see how S= RTP=20 could be made to work in this way. The definition of the RC states that it = is=20 the source of the media which seems incompatible with this=20 requirement.
 
11. Secti= on 6=20 Req-030. This does not sound like an SRP requirement.
 
Regards
Andy
 

Andrew Hutton

Office of the=20 CTO.
<= SPAN=20 class=3DGramE>Siemens Enterprise=20 Communications.

--_000_101C6067BEC68246B0C3F6843BCCC1E306847E29DEMCHP058Agloba_-- From peter.musgrave@magorcorp.com Tue Dec 8 12:40:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9E33A67B1 for ; Tue, 8 Dec 2009 12:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYS49n+nZzEP for ; Tue, 8 Dec 2009 12:39:59 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5E6853A66B4 for ; Tue, 8 Dec 2009 12:39:59 -0800 (PST) Received: from [192.168.216.97] ([216.13.45.138]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LxyjU-1OC5cu0NEq-015TnF; Tue, 08 Dec 2009 15:39:22 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-11-677197382 From: Peter Musgrave In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> Date: Tue, 8 Dec 2009 15:39:15 -0500 Message-Id: References: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1077) X-Provags-ID: V01U2FsdGVkX1/1i4BKjZly6XseaFTI5f/IZD+bZ3PA0Rl2kvU IyYp3mvQPxOln93EDwaap9j1evS1djlMFOx5uoQvTSjx3RoyWo PmisG4aYilg682blhBpfN4tjqmIju6CauT5SfTTNcc= Cc: "Leon.Portman@nice.com" , "dispatch@ietf.org" , "Jain, Rajnish" , "HKaplan@acmepacket.com" Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:40:00 -0000 --Apple-Mail-11-677197382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, For (1): How about restricting it to the media described in the sdp between the = parties for the session to be recorded (assuming call setup in SIP) or = the equivalent for non-SIP? What I have in mind is a video conference with collab content in a = second video stream and a tcp session for BFCP. In this case it might be = desirable to record some of the BFCP information to indicate which = collab content is on the second video stream. In general the BFCP is = listed as an m-line in the sdp. Also: Is it worth stating as a requirement that the streams in each direction = be sent separately to the recording device (or is this implied?). Some = recording devices check for times when both parties are talking - since = in a call center scenario such recordings may be discussions worth = listening to... Peter Musgrave On 2009-12-08, at 11:19 AM, Hutton, Andrew wrote: > Some comments on the session recording requirements draft = draft-rehor-dispatch-session-recording-req-00 > =20 > 1. The introduction states that the "recording sessions can be of any = kind such as voice, video and instant messaging". I think it would be = sensible to restrict the scope to RTP based media (I.e. voice and video) = and possibly move out the instant messaging recording as a separate work = item if needed. > =20 >=20 > Regards > Andy > =20 > Andrew Hutton > Office of the CTO. > Siemens Enterprise Communications. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-11-677197382 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Some comments on the=20 session recording requirements draft draft-rehor-dispatch-session-recording-req-00
 
1.= The introduction=20 states that the "recording sessions can be of any kind such as voice, = video and=20 instant messaging". I think it would be sensible to restrict the scope = to RTP=20 based media (I.e. voice and video) and possibly move out the instant = messaging=20 recording as a separate work item if needed.
 

Regards
Andy
 
Andrew Hutton

Office of the=20 CTO.
Siemens Enterprise=20 Communications.

_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.iet= f.org/mailman/listinfo/dispatch

= --Apple-Mail-11-677197382-- From spencer@wonderhamster.org Tue Dec 8 14:24:03 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D283A6999; Tue, 8 Dec 2009 14:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BtC-jlr-0zt; Tue, 8 Dec 2009 14:24:02 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 1C4253A694F; Tue, 8 Dec 2009 14:24:02 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LnQ3S-1NiwZR2SPm-00hjwq; Tue, 08 Dec 2009 17:23:51 -0500 Message-ID: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> From: "Spencer Dawkins" To: , Date: Tue, 8 Dec 2009 16:23:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18fUPZ4yDDsptMgRVnbJWHyE5XwegdBNXMY3AB +aJaMaso16iDm86WrCqWVOa3gG/hjmQ+XpeHKWIZCMVMogU39h QPmUanSK6EThL7t+eAj73IP6nJJAWdziAJJVwF98aI= Cc: martini@ietf.org Subject: [dispatch] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 22:24:03 -0000 Cullen has asked me to announce a new mailing list, called MARTINI (acronym for "Multiple AoR reachabiliTy InformatioN Indication"), to be used for discussion of what has variously been called "implicit registration", "domain registration", and probably some other terms as well. To be a little more precise, the MARTINI mailing list was created to discuss means by which an entity that is authoritative for SIP URIs can dynamically register reachability information for multiple Addresses of Record ("AORs") with a service provider. The coordinates are in the place you'd expect: General Discussion: martini@ietf.org To Subscribe: martini-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/martini/index.html Just to catch people up... DISPATCH recommended that this proposed work go forward in a mini-working group. The IESG approved a proposed charter to be sent for a two-week review on last Thursday's telechat, so you should see that announcement popping out fairly quickly. That charter also proposes an interim meeting in January 2010, and we'll be discussing logistics on the MARTINI mailing list in the near future, so please subscribe Real Soon Now if you are interested in the topic. Thanks! Spencer From stpeter@stpeter.im Tue Dec 8 16:33:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C783A69CD; Tue, 8 Dec 2009 16:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIrWqXlPLYzp; Tue, 8 Dec 2009 16:33:28 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EE0863A6955; Tue, 8 Dec 2009 16:33:27 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3493B40126; Tue, 8 Dec 2009 17:33:16 -0700 (MST) Message-ID: <4B1EF04A.6070309@stpeter.im> Date: Tue, 08 Dec 2009 17:33:14 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> <92707897-D022-4ABE-957E-052458093CF1@estacado.net> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090100000203030708010702" Cc: Ben Campbell , dispatch@ietf.org, rai@ietf.org, martini@ietf.org Subject: Re: [dispatch] [RAI] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:33:29 -0000 This is a cryptographically signed message in MIME format. --------------ms090100000203030708010702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit /me is looking forward to the SCOTCH BoF... ;-) On 12/8/09 5:14 PM, Mike Hammer (hmmr) wrote: > Probably an occupational hazard. > > What next? > > What Hype Is SIP Keen on Evolving to Yet (WHISKEY)? :) > > Mike > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Ben >> Campbell >> Sent: Tuesday, December 08, 2009 5:27 PM >> To: Spencer Dawkins >> Cc: dispatch@ietf.org; rai@ietf.org; martini@ietf.org >> Subject: Re: [RAI] New Mailing List announcement - MARTINI (was - > DREGS) >> DRINKS, now MARTINI? Is there a trend there? >> >> On Dec 8, 2009, at 4:23 PM, Spencer Dawkins wrote: >> >>> Cullen has asked me to announce a new mailing list, called MARTINI >> (acronym >>> for "Multiple AoR reachabiliTy InformatioN Indication"), to be used > for >>> discussion of what has variously been called "implicit > registration", >>> "domain registration", and probably some other terms as well. >>> >>> To be a little more precise, the MARTINI mailing list was created to >> discuss >>> means by which an entity that is authoritative for SIP URIs can >> dynamically >>> register reachability information for multiple Addresses of Record >> ("AORs") >>> with a service provider. >>> >>> The coordinates are in the place you'd expect: >>> >>> General Discussion: martini@ietf.org >>> To Subscribe: martini-request@ietf.org >>> In Body: subscribe >>> Archive: http://www.ietf.org/mail-archive/web/martini/index.html >>> >>> Just to catch people up... DISPATCH recommended that this proposed > work >> go >>> forward in a mini-working group. The IESG approved a proposed > charter to >> be >>> sent for a two-week review on last Thursday's telechat, so you > should >> see >>> that announcement popping out fairly quickly. >>> >>> That charter also proposes an interim meeting in January 2010, and > we'll >> be >>> discussing logistics on the MARTINI mailing list in the near future, > so >>> please subscribe Real Soon Now if you are interested in the topic. >>> >>> Thanks! >>> >>> Spencer >>> _______________________________________________ --------------ms090100000203030708010702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwOTAwMzMxNFowIwYJKoZIhvcNAQkEMRYEFEkC1s1xqnvKLT8j0ge+ Fi7eaOpvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAYd3HpfJU6wlNGVLzuKEnPzIH5IcDuFGJQQQEDOBj /3diq6LJjfO7Bizw4ifWB3KUjBP4WjycdlrmWzSESyN1kMIyJFGs3ZGDWSpfsTYoWIhKmtlQ 6SlS0W3/osN0xZJd0v5hBCztSYyDcCABIpzhFKIGie1IRtRNtxfZXDLWphOnjGUwsfqiRaiI TLIlSlVm6TS3M5m923ZQ/M1dYm25TC4dq1ODcxxa45imGwKKss41RzwUa8uPdbICEry6xr7p z0CFwvuF7tRzayME0fAIT01n9X+xAaAlLKhSNzC5htWtXrE/Uxz1/msL8u1Kj2CLJckmWZKS 6DFX0UPKmgQZowAAAAAAAA== --------------ms090100000203030708010702-- From ben@estacado.net Tue Dec 8 14:28:43 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AA23A6A90; Tue, 8 Dec 2009 14:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoy35GrgoyxC; Tue, 8 Dec 2009 14:28:43 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id E149C3A6A8E; Tue, 8 Dec 2009 14:28:42 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-28-128.dsl.rcsntx.swbell.net [68.94.28.128]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nB8MRAm0028743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Dec 2009 16:27:14 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell X-Priority: 3 In-Reply-To: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> Date: Tue, 8 Dec 2009 16:27:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92707897-D022-4ABE-957E-052458093CF1@estacado.net> References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Tue, 08 Dec 2009 17:59:50 -0800 Cc: dispatch@ietf.org, rai@ietf.org, martini@ietf.org Subject: Re: [dispatch] [RAI] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 22:28:43 -0000 DRINKS, now MARTINI? Is there a trend there? On Dec 8, 2009, at 4:23 PM, Spencer Dawkins wrote: > Cullen has asked me to announce a new mailing list, called MARTINI = (acronym > for "Multiple AoR reachabiliTy InformatioN Indication"), to be used = for > discussion of what has variously been called "implicit registration", > "domain registration", and probably some other terms as well. >=20 > To be a little more precise, the MARTINI mailing list was created to = discuss > means by which an entity that is authoritative for SIP URIs can = dynamically > register reachability information for multiple Addresses of Record = ("AORs") > with a service provider. >=20 > The coordinates are in the place you'd expect: >=20 > General Discussion: martini@ietf.org > To Subscribe: martini-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/martini/index.html >=20 > Just to catch people up... DISPATCH recommended that this proposed = work go > forward in a mini-working group. The IESG approved a proposed charter = to be > sent for a two-week review on last Thursday's telechat, so you should = see > that announcement popping out fairly quickly. >=20 > That charter also proposes an interim meeting in January 2010, and = we'll be > discussing logistics on the MARTINI mailing list in the near future, = so > please subscribe Real Soon Now if you are interested in the topic. >=20 > Thanks! >=20 > Spencer=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From rbarnes@bbn.com Tue Dec 8 15:30:25 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8783A692D; Tue, 8 Dec 2009 15:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY3huW2nfUZu; Tue, 8 Dec 2009 15:30:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id F295A3A683D; Tue, 8 Dec 2009 15:30:23 -0800 (PST) Received: from [192.1.255.190] (helo=col-dhcp-192-1-255-190.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NI97f-0003XQ-CC; Tue, 08 Dec 2009 18:05:35 -0500 From: Richard Barnes To: Ben Campbell In-Reply-To: <92707897-D022-4ABE-957E-052458093CF1@estacado.net> X-Priority: 3 References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> <92707897-D022-4ABE-957E-052458093CF1@estacado.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Dec 2009 18:05:35 -0500 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 08 Dec 2009 17:59:50 -0800 Cc: dispatch@ietf.org, rai@ietf.org, martini@ietf.org Subject: Re: [dispatch] [RAI] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 23:30:26 -0000 I know SIMPLE has already done some work in this area, but I think we may need a BoF on INTER-domain eVENT distributION. --Richard On Dec 8, 2009, at 5:27 PM, Ben Campbell wrote: > DRINKS, now MARTINI? Is there a trend there? > > On Dec 8, 2009, at 4:23 PM, Spencer Dawkins wrote: > >> Cullen has asked me to announce a new mailing list, called MARTINI >> (acronym >> for "Multiple AoR reachabiliTy InformatioN Indication"), to be used >> for >> discussion of what has variously been called "implicit registration", >> "domain registration", and probably some other terms as well. >> >> To be a little more precise, the MARTINI mailing list was created >> to discuss >> means by which an entity that is authoritative for SIP URIs can >> dynamically >> register reachability information for multiple Addresses of Record >> ("AORs") >> with a service provider. >> >> The coordinates are in the place you'd expect: >> >> General Discussion: martini@ietf.org >> To Subscribe: martini-request@ietf.org >> In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/martini/index.html >> >> Just to catch people up... DISPATCH recommended that this proposed >> work go >> forward in a mini-working group. The IESG approved a proposed >> charter to be >> sent for a two-week review on last Thursday's telechat, so you >> should see >> that announcement popping out fairly quickly. >> >> That charter also proposes an interim meeting in January 2010, and >> we'll be >> discussing logistics on the MARTINI mailing list in the near >> future, so >> please subscribe Real Soon Now if you are interested in the topic. >> >> Thanks! >> >> Spencer >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From hmmr@cisco.com Tue Dec 8 16:15:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B915E3A69AE; Tue, 8 Dec 2009 16:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKGhCxCGWlz3; Tue, 8 Dec 2009 16:15:00 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 597573A69BF; Tue, 8 Dec 2009 16:15:00 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJd6HkurRN+J/2dsb2JhbADBFpc4hDIE X-IronPort-AV: E=Sophos;i="4.47,364,1257120000"; d="scan'208";a="116388019" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2009 00:14:48 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB90ElZN028377; Wed, 9 Dec 2009 00:14:47 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 18:14:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Dec 2009 18:14:46 -0600 Message-ID: In-Reply-To: <92707897-D022-4ABE-957E-052458093CF1@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] New Mailing List announcement - MARTINI (was - DREGS) Thread-Index: Acp4VchcJjTJGx6QT5ChxBNwEDZijQADosTg References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> <92707897-D022-4ABE-957E-052458093CF1@estacado.net> From: "Mike Hammer (hmmr)" To: "Ben Campbell" , "Spencer Dawkins" X-OriginalArrivalTime: 09 Dec 2009 00:14:47.0312 (UTC) FILETIME=[9DCED100:01CA7864] X-Mailman-Approved-At: Tue, 08 Dec 2009 17:59:50 -0800 Cc: dispatch@ietf.org, rai@ietf.org, martini@ietf.org Subject: Re: [dispatch] [RAI] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:15:01 -0000 Probably an occupational hazard. What next? What Hype Is SIP Keen on Evolving to Yet (WHISKEY)? :) Mike > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Ben > Campbell > Sent: Tuesday, December 08, 2009 5:27 PM > To: Spencer Dawkins > Cc: dispatch@ietf.org; rai@ietf.org; martini@ietf.org > Subject: Re: [RAI] New Mailing List announcement - MARTINI (was - DREGS) >=20 > DRINKS, now MARTINI? Is there a trend there? >=20 > On Dec 8, 2009, at 4:23 PM, Spencer Dawkins wrote: >=20 > > Cullen has asked me to announce a new mailing list, called MARTINI > (acronym > > for "Multiple AoR reachabiliTy InformatioN Indication"), to be used for > > discussion of what has variously been called "implicit registration", > > "domain registration", and probably some other terms as well. > > > > To be a little more precise, the MARTINI mailing list was created to > discuss > > means by which an entity that is authoritative for SIP URIs can > dynamically > > register reachability information for multiple Addresses of Record > ("AORs") > > with a service provider. > > > > The coordinates are in the place you'd expect: > > > > General Discussion: martini@ietf.org > > To Subscribe: martini-request@ietf.org > > In Body: subscribe > > Archive: http://www.ietf.org/mail-archive/web/martini/index.html > > > > Just to catch people up... DISPATCH recommended that this proposed work > go > > forward in a mini-working group. The IESG approved a proposed charter to > be > > sent for a two-week review on last Thursday's telechat, so you should > see > > that announcement popping out fairly quickly. > > > > That charter also proposes an interim meeting in January 2010, and we'll > be > > discussing logistics on the MARTINI mailing list in the near future, so > > please subscribe Real Soon Now if you are interested in the topic. > > > > Thanks! > > > > Spencer > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www.ietf.org/mailman/listinfo/rai >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From petithug@acm.org Tue Dec 8 16:37:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE113A69AE; Tue, 8 Dec 2009 16:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmExyi9uaa9I; Tue, 8 Dec 2009 16:37:55 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id D2D103A6955; Tue, 8 Dec 2009 16:37:55 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 97114DCC40EC; Wed, 9 Dec 2009 00:37:44 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 571D4DCC40EA; Wed, 9 Dec 2009 00:37:43 +0000 (UTC) Message-ID: <4B1EF156.1080600@acm.org> Date: Tue, 08 Dec 2009 16:37:42 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> <92707897-D022-4ABE-957E-052458093CF1@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Dec 2009 17:59:50 -0800 Cc: Ben Campbell , dispatch@ietf.org, rai@ietf.org, martini@ietf.org Subject: Re: [dispatch] [RAI] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:37:56 -0000 Mike Hammer (hmmr) wrote: > Probably an occupational hazard. > > What next? > > What Hype Is SIP Keen on Evolving to Yet (WHISKEY)? :) also Partial Implementation of Sip Standard, a de facto WG where PSTN carriers work hard converting MUST in SHOULD, SHOULD in MAY and MAY in "not in my lifetime". > > Mike > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Ben >> Campbell >> Sent: Tuesday, December 08, 2009 5:27 PM >> To: Spencer Dawkins >> Cc: dispatch@ietf.org; rai@ietf.org; martini@ietf.org >> Subject: Re: [RAI] New Mailing List announcement - MARTINI (was - > DREGS) >> DRINKS, now MARTINI? Is there a trend there? >> >> On Dec 8, 2009, at 4:23 PM, Spencer Dawkins wrote: >> >>> Cullen has asked me to announce a new mailing list, called MARTINI >> (acronym >>> for "Multiple AoR reachabiliTy InformatioN Indication"), to be used > for >>> discussion of what has variously been called "implicit > registration", >>> "domain registration", and probably some other terms as well. >>> >>> To be a little more precise, the MARTINI mailing list was created to >> discuss >>> means by which an entity that is authoritative for SIP URIs can >> dynamically >>> register reachability information for multiple Addresses of Record >> ("AORs") >>> with a service provider. >>> >>> The coordinates are in the place you'd expect: >>> >>> General Discussion: martini@ietf.org >>> To Subscribe: martini-request@ietf.org >>> In Body: subscribe >>> Archive: http://www.ietf.org/mail-archive/web/martini/index.html >>> >>> Just to catch people up... DISPATCH recommended that this proposed > work >> go >>> forward in a mini-working group. The IESG approved a proposed > charter to >> be >>> sent for a two-week review on last Thursday's telechat, so you > should >> see >>> that announcement popping out fairly quickly. >>> >>> That charter also proposes an interim meeting in January 2010, and > we'll >> be >>> discussing logistics on the MARTINI mailing list in the near future, > so >>> please subscribe Real Soon Now if you are interested in the topic. >>> >>> Thanks! >>> >>> Spencer -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From richard@shockey.us Tue Dec 8 18:45:27 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9333A6833 for ; Tue, 8 Dec 2009 18:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWVFbzXjPN6T for ; Tue, 8 Dec 2009 18:45:27 -0800 (PST) Received: from outbound-mail-314.bluehost.com (outbound-mail-314.bluehost.com [67.222.54.7]) by core3.amsl.com (Postfix) with SMTP id 46EB23A6359 for ; Tue, 8 Dec 2009 18:45:27 -0800 (PST) Received: (qmail 12619 invoked by uid 0); 9 Dec 2009 02:38:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 9 Dec 2009 02:38:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=GOMjWlf0i2MDHml4tpCqmdmQaCaV0Fy76DHTBN086JSRiI5z/eAR1hcUnlMPiGtrIb3GZzxiquhHvz23eNIEtupzz19OeaJCXp9vcuwLScI5aTHkwUOaJ0yvAUPq95A2; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NICRo-0002pa-MI; Tue, 08 Dec 2009 19:38:36 -0700 From: "Richard Shockey" To: "'Mike Hammer \(hmmr\)'" , "'Ben Campbell'" , "'Spencer Dawkins'" References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> <92707897-D022-4ABE-957E-052458093CF1@estacado.net> In-Reply-To: Date: Tue, 8 Dec 2009 21:38:32 -0500 Message-ID: <006b01ca7878$b4053810$1c0fa830$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp4VchcJjTJGx6QT5ChxBNwEDZijQADosTgAAUWFaA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: dispatch@ietf.org, rai@ietf.org, martini@ietf.org Subject: Re: [dispatch] [RAI] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 02:45:27 -0000 SCOTCH ... > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Mike Hammer (hmmr) > Sent: Tuesday, December 08, 2009 7:15 PM > To: Ben Campbell; Spencer Dawkins > Cc: dispatch@ietf.org; rai@ietf.org; martini@ietf.org > Subject: Re: [RAI] New Mailing List announcement - MARTINI (was - > DREGS) > > Probably an occupational hazard. > > What next? > > What Hype Is SIP Keen on Evolving to Yet (WHISKEY)? :) > > Mike > > > > -----Original Message----- > > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf > Of > Ben > > Campbell > > Sent: Tuesday, December 08, 2009 5:27 PM > > To: Spencer Dawkins > > Cc: dispatch@ietf.org; rai@ietf.org; martini@ietf.org > > Subject: Re: [RAI] New Mailing List announcement - MARTINI (was - > DREGS) > > > > DRINKS, now MARTINI? Is there a trend there? > > > > On Dec 8, 2009, at 4:23 PM, Spencer Dawkins wrote: > > > > > Cullen has asked me to announce a new mailing list, called MARTINI > > (acronym > > > for "Multiple AoR reachabiliTy InformatioN Indication"), to be > used > for > > > discussion of what has variously been called "implicit > registration", > > > "domain registration", and probably some other terms as well. > > > > > > To be a little more precise, the MARTINI mailing list was created > to > > discuss > > > means by which an entity that is authoritative for SIP URIs can > > dynamically > > > register reachability information for multiple Addresses of Record > > ("AORs") > > > with a service provider. > > > > > > The coordinates are in the place you'd expect: > > > > > > General Discussion: martini@ietf.org > > > To Subscribe: martini-request@ietf.org > > > In Body: subscribe > > > Archive: http://www.ietf.org/mail-archive/web/martini/index.html > > > > > > Just to catch people up... DISPATCH recommended that this proposed > work > > go > > > forward in a mini-working group. The IESG approved a proposed > charter to > > be > > > sent for a two-week review on last Thursday's telechat, so you > should > > see > > > that announcement popping out fairly quickly. > > > > > > That charter also proposes an interim meeting in January 2010, and > we'll > > be > > > discussing logistics on the MARTINI mailing list in the near > future, > so > > > please subscribe Real Soon Now if you are interested in the topic. > > > > > > Thanks! > > > > > > Spencer > > > _______________________________________________ > > > RAI mailing list > > > RAI@ietf.org > > > https://www.ietf.org/mailman/listinfo/rai > > > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www.ietf.org/mailman/listinfo/rai > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From brett@broadsoft.com Wed Dec 9 05:04:26 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D933A697A for ; Wed, 9 Dec 2009 05:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4QzuK62XUHF for ; Wed, 9 Dec 2009 05:04:25 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 1D36E3A682C for ; Wed, 9 Dec 2009 05:04:25 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 9 Dec 2009 05:04:13 -0800 From: Brett Tate To: "dispatch@ietf.org" Date: Wed, 9 Dec 2009 05:03:55 -0800 Thread-Topic: locating spawns of DISPATCH Thread-Index: Acp40BCNtPXWigy6Q1y/9cBnnuaetg== Message-ID: <747A6506A991724FB09B129B79D5FEB6145DF116A3@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ac9L DwVv Eesj Ejml E9hO GJ6x Hl7/ Hqqb Iia3 IxQq JF8A Jc2H JdMj JkiL J5po KgVP; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {AD71FF36-B096-4487-B4DF-FD79FAA13786}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Wed, 09 Dec 2009 13:03:55 GMT; bABvAGMAYQB0AGkAbgBnACAAcwBwAGEAdwBuAHMAIABvAGYAIABEAEkAUwBQAEEAVABDAEgA x-cr-puzzleid: {AD71FF36-B096-4487-B4DF-FD79FAA13786} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] locating spawns of DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:04:26 -0000 Greetings, Are the working group spawns of DISPATCH collected somewhere to easily noti= ce them (without searching email archive)? For instance, will they be link= ed somehow to DISPATCH charter, status, or a supplemental DISPATCH webpage? Thanks, Brett From Simo.Veikkolainen@nokia.com Wed Dec 9 05:11:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0237728C0DE for ; Wed, 9 Dec 2009 05:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGG6+sdYJAui for ; Wed, 9 Dec 2009 05:11:51 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C752C28C133 for ; Wed, 9 Dec 2009 05:11:50 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB9DBLcc000354 for ; Wed, 9 Dec 2009 07:11:38 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:11:17 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:11:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:11:04 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 9 Dec 2009 14:11:03 +0100 From: To: Date: Wed, 9 Dec 2009 14:11:02 +0100 Thread-Topic: Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Dec 2009 13:11:04.0757 (UTC) FILETIME=[1020E650:01CA78D1] X-Nokia-AV: Clean Subject: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:11:53 -0000 Hello, Below is the proposed charter text for Combining SIP and XMPP revised accor= ding to the discussions in Hiroshima. Basically the changes are - include video in addition to voice - mention that existing SIP and XMPP endpoints are not affected - update milestones. Comments are very welcome. Regards, Simo -----8<------8<------8<------ Combining SIP VoIP and XMPP IM/Presence =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Currently most standards-based Voice over IP (VoIP) deployments use the Ses= sion Initiation Protocol (SIP). In addition to providing basic voice servi= ce SIP has an extensive support for more advanced telephony features includ= ing interworking with the traditional Public Switched Telephone Network (PS= TN). SIP is also gaining popularity in the field of video communication. A= t the same time, the Extensible Messaging and Presence Protocol (XMPP) is e= njoying widespread usage in instant messaging and presence services. =20 Both SIP and XMPP offer extensions for integrating voice and video with IM = and presence (XMPP voice via the Jingle extension, and SIP IM/presence via = SIMPLE protocols). However, widespread deployment of these extensions has n= ot so far taken place. In order to speed up deployment of integrated VoIP a= nd IM systems, SIP based voice and XMPP based IM/Presence could be combined= in endpoints to offer a voice, IM and presence service without any changes= to existing SIP and XMPP service infrastructure.=20 The objective of this Working Group is to develop solutions for combining S= IP based voice with XMPP based IM and Presence such that a unified user exp= erience can be offered to end user. Specifically, solutions are needed on=20 - addressing; end users should be able to initiate sessions to a user ident= ity in either SIP or XMPP domain. The corresponding user identity in the ot= her protocol domain needs to be learned automatically. - session correlation; endpoints need to be able to correlate SIP voice and= video sessions with XMPP IM/Presence in such a manner that they can be pre= sented to the end user in a seamless fashion - presence; it should be possible to change the XMPP presence status based = on the user's activity in the SIP domain. Existing SIP and XMPP endpoints are not affected and can interoperate with = the implementations that comply with the extensions defined by this Working= Group (but obviously without the additional functionality provided by thes= e extensions). The goal is to rely on existing service infrastructure, and new requirement= s should be imposed only on the endpoints.=20 Protocol interworking, that is, translation from one protocol to another, i= s out of scope of this WG. Milestones Jun 2010 Problem statement and use cases submitted to IESG as Informational= . Jun 2011 Specification on combining SIP based voice and video and XMPP base= d IM/Presence in a seamless manner submitted to IESG as Proposed Standard. -----8<------8<------8<------ From rajnish.jain@ipc.com Wed Dec 9 07:20:17 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AA43A6850 for ; Wed, 9 Dec 2009 07:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.718 X-Spam-Level: X-Spam-Status: No, score=-3.718 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrdjjNufPVrh for ; Wed, 9 Dec 2009 07:20:16 -0800 (PST) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 4112F3A6844 for ; Wed, 9 Dec 2009 07:20:16 -0800 (PST) Received: from unknown [65.244.37.51] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net(mxl_mta-6.4.0-2) with ESMTP id 520cf1b4.aa94db90.229579.00-434.496599.p01c12o144.mxlogic.net (envelope-from ); Wed, 09 Dec 2009 08:20:05 -0700 (MST) X-MXL-Hash: 4b1fc0254cee8c94-2254938f96f008d9d598987df358b49bcd4f15cb Received: from unknown [65.244.37.51] (EHLO smtp.ipc.com) by p01c12o144.mxlogic.net(mxl_mta-6.4.0-2) over TLS secured channel with ESMTP id 510cf1b4.0.229483.00-027.496357.p01c12o144.mxlogic.net (envelope-from ); Wed, 09 Dec 2009 08:19:50 -0700 (MST) X-MXL-Hash: 4b1fc0161867c99d-fb66fefed8eec5d733638f2c84d5203695f855b6 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.1.228]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Wed, 9 Dec 2009 10:19:48 -0500 From: "Jain, Rajnish" To: Peter Musgrave , "Hutton, Andrew" Date: Wed, 9 Dec 2009 10:19:47 -0500 Thread-Topic: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: Acp4RpN/JmWZLWQDT+aFrw70Bv7UigAm9CCQ Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.000.1038-17058.004 x-tm-as-result: No--44.337200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009113001)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=z+2a4RCZxltofrpCDsS06w==:17 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=rd_hZMwNXrk22cojUFoA:9 a=0jH_0oqjVcX_IgZCKMsA:7 a=JlA8cNE] X-AnalysisOut: [cpnU3CskUhWKlc94QONUA:4 a=lZB815dzVvQA:10] Cc: "Leon.Portman@nice.com" , "dispatch@ietf.org" , "HKaplan@acmepacket.com" Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:20:17 -0000 Also: Is it worth stating as a requirement that the streams in each direction be = sent separately to the recording device (or is this implied?). Some recordi= ng devices check for times when both parties are talking - since in a call = center scenario such recordings may be discussions worth listening to... Peter Musgrave This is implied in REQ-010. I think we can add a clarifying note that indic= ates that the recording media streams may carry the Rx and Tx of recorded m= edia stream separately. o REQ-010 The mechanism MUST support the ability to deliver multiple media streams for a given Recorded Session over separate Recording Sessions to the RS. Thanks, Raj Jain On 2009-12-08, at 11:19 AM, Hutton, Andrew wrote: Some comments on the session recording requirements draft draft-rehor-dispa= tch-session-recording-req-00 1. The introduction states that the "recording sessions can be of any kind = such as voice, video and instant messaging". I think it would be sensible t= o restrict the scope to RTP based media (I.e. voice and video) and possibly= move out the instant messaging recording as a separate work item if needed= . Regards Andy Andrew Hutton Office of the CTO. Siemens Enterprise Communications. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From spencer@wonderhamster.org Wed Dec 9 07:26:31 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D143A6882 for ; Wed, 9 Dec 2009 07:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3SBQkR6r1Ai for ; Wed, 9 Dec 2009 07:26:27 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id C440B3A67B6 for ; Wed, 9 Dec 2009 07:26:27 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LfTyT-1NtR8u45eL-00odoy; Wed, 09 Dec 2009 10:26:16 -0500 Message-ID: From: "Spencer Dawkins" To: "Brett Tate" , References: <747A6506A991724FB09B129B79D5FEB6145DF116A3@EXMBXCLUS01.citservers.local> Date: Wed, 9 Dec 2009 09:26:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18ge+PcE11RNTvFH5VSFpd2jIsJF4ybevNBK9n aVfusFMfKR8qRBrZ2i/PB5D15oOcfNW7xuT5/Lp0ie/5i7fcso C1ZAtY/0SQGK/chF82OrLeWgvBuMrdKIgINPamF8+0= Subject: Re: [dispatch] locating spawns of DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:26:31 -0000 Hi, Brett, Great question! > Greetings, > > Are the working group spawns of DISPATCH collected somewhere to easily > notice them (without searching email archive)? For instance, will they be > linked somehow to DISPATCH charter, status, or a supplemental DISPATCH > webpage? > > Thanks, > Brett So if people use -dispatch- as part of their submission filenames, that will show up on the tools version of the DISPATCH mailing list page (http://tools.ietf.org/wg/dispatch/). The problem I've been seeing is that there are still -sipping- proposals floating around, that haven't been adopted yet and don't get automatically linked, but this should be less of a problem as time passes. Since one of the main outputs of DISPATCH is working group charters, I'd expect a lot of -dispatch- drafts to be replaced by -$DispatchedToWGName- drafts - that's a manual tagging exercise, but I hope we do it, because if we don't, the DISPATCH page will be a mess. The IESG uses a wiki to keep track of what BOFs are requested for each IETF. Maybe that would be a helpful thing to clone, since DISPATCH is doing essentially the same type of thing for the RAI area? Thanks, Spencer From mary.barnes@nortel.com Wed Dec 9 07:32:16 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8463A68C7 for ; Wed, 9 Dec 2009 07:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.685 X-Spam-Level: X-Spam-Status: No, score=-6.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7eLoxmZluma for ; Wed, 9 Dec 2009 07:32:15 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BE7E33A6875 for ; Wed, 9 Dec 2009 07:32:14 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nB9FVu414895; Wed, 9 Dec 2009 15:31:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Dec 2009 09:32:44 -0600 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB6145DF116A3@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] locating spawns of DISPATCH Thread-Index: Acp40BCNtPXWigy6Q1y/9cBnnuaetgAE/aTw References: <747A6506A991724FB09B129B79D5FEB6145DF116A3@EXMBXCLUS01.citservers.local> From: "Mary Barnes" To: "Brett Tate" , Subject: Re: [dispatch] locating spawns of DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:32:16 -0000 Hi Brett, That's a good point. I had been summarizing such in the status emails, but can see the value in keeping this in a single place. I'll add a page to the supplementary webpage on softarmor and send a note to the list when that's done. Thanks, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Brett Tate Sent: Wednesday, December 09, 2009 7:04 AM To: dispatch@ietf.org Subject: [dispatch] locating spawns of DISPATCH Greetings, Are the working group spawns of DISPATCH collected somewhere to easily notice them (without searching email archive)? For instance, will they be linked somehow to DISPATCH charter, status, or a supplemental DISPATCH webpage? Thanks, Brett _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From spencer@wonderhamster.org Wed Dec 9 07:35:45 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE14C28C137; Wed, 9 Dec 2009 07:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqxe1ovMYMeW; Wed, 9 Dec 2009 07:35:45 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 1548028C132; Wed, 9 Dec 2009 07:35:45 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LdYEs-1NzjkW0N5G-00isB9; Wed, 09 Dec 2009 10:35:33 -0500 Message-ID: <56F1480C226B41A78326CDE4C7D9F0D3@china.huawei.com> From: "Spencer Dawkins" To: , References: <87BADCE5E5DF469CAD666A48CDCB14F8@china.huawei.com> Date: Wed, 9 Dec 2009 09:35:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19rgeBswgrLrNCKum1tIpA2sMlDTXc5Eo5Qqs1 JJSVVN6bQ20129DS+Ty0w5k6ven9AcdTBFx/lDU6TFZmRZ33CB MS7wTa8CxWmnE5yJ0447nafpQdnhg2QExfMF5ARl+U= Cc: martini@ietf.org Subject: Re: [dispatch] New Mailing List announcement - MARTINI (was - DREGS) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:35:46 -0000 Just to let people know - the secretariat has issued the proposed charter, at http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06799.html. Thanks, Spencer From dworley@nortel.com Wed Dec 9 13:15:18 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07B128C1CD for ; Wed, 9 Dec 2009 13:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrCWsD3+XVTU for ; Wed, 9 Dec 2009 13:15:16 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1561628C1CE for ; Wed, 9 Dec 2009 13:15:14 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nB9LF1424206 for ; Wed, 9 Dec 2009 21:15:01 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 16:14:45 -0500 From: "Dale Worley" To: DISPATCH Content-Type: text/plain Organization: Nortel Networks Date: Wed, 09 Dec 2009 16:14:45 -0500 Message-Id: <1260393285.4277.31.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 21:14:45.0864 (UTC) FILETIME=[A20E6680:01CA7914] Subject: [dispatch] XML questions about draft-ietf-sipping-media-policy-dataset-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 21:15:19 -0000 I've edited my questions about the XML in draft-ietf-sipping-media-policy-dataset-08 into better order. They are appended to this message. Dale ----------------------------------------------------------------------------- This is based on a copy of the draft-ietf-sipping-media-policy-dataset-08 draft, which I have in a private directory. Apparently, the -08 version was never published. I assume that the authors have an archival copy of -08. The MD5 of my copy of the text version of -08 (with LF as EOL) is dfd01da655ee324727a0f0fbe6ff69a8. - Section 1 Are merging rules still needed? We are no longer using session-policy-dataset, which required merging, but IIRC someone mentioned an additional need for merging. - Section 4.2 Section 4.2 contains: If a UA has an SDP offer as well as an answer [RFC3264] and wants to create a session info document, the UA MUST use the answer to fill in the elements of the session info document except for the remote-host- port and local-host-port elements, which are taken from the remote and local session description respectively. The local session description is the one created locally by the UA (i.e., the offer if the UA has initiated the offer/answer exchange). The remote session description is the one received from the remote UA. If a UA has an SDP offer as well as an answer [RFC3264] and wants to create a session info document, the UA MUST use the answer to fill in the elements of the session info document except for the local-host-port and remote-host-port elements, which are taken from the SDP generated by the UA and the SDP received by the UA, respectively (regardless of which is the offer and which is the answer). However, this process doesn't seem to allow for the possibility that the locally-provided and remote-provided SDP may differ. (Although I think the relevant differences are restricted to which codecs may be used.) It seems that directionality attributes could/should be used to have the media-policy specify the admitted codecs in each direction appropriately. The specification of codecs in SDP is strange in that an answer may contain codecs that are not given in the offer, but they are not usable in the session. How should they be encoded in session-info? Section 4.2 seems to envision that an offer SDP can be mapped into a media-policy, which can then be restricted or subsetted to give a new media-policy, which can then be translated into an answer SDP. But the transformation of SDP into media-policy XML seems to lose the sequencing of the m= lines, in that there is no semantics specified for the elements of a media-policy. Perhaps the intention is that the elements correspond in order to the m= lines, but that does not seem to be stated. Note that SDP can contain zero m= lines, which would seem to map to a with a with no . But that is not allowed by 6.3. - Section 5 Perhaps this change of wording would be clearer: Session policy documents describe a policy for SIP sessions. Session policy documents are independent of >>any<< specific session description and express general policies for SIP sessions. - Section 5.1 The element is not being used any more. - Section 6.2 Section 6.2 says that at least one codec must be allowed per media type (see second sentence), but the correspondence between codec and media type isn't explicit, and it would be a difficult validity constraint to verify. Also, the text does not specify that we're only concerned with media types that are admitted by the element. And worse, what if the are a set-complement construction (excluded-policy="allow"), in which case the set of admitted media-types is not knowable? I would suggest removing the restriction, and understanding that an allowed media-type with no allowable codecs is unusable in practice. - Section 6.2.1.1 The and elements want to specify the codec via a mime-type, but that isn't what SDP uses. The translation between the two is described in RFC 4855 section 3, which should be referenced. - Section 6.3.1 How are 0 port values encoded? Semantically, it identifies a "sendonly" mode. Should it be encoded as a zero value of or (better) by appropriate direction attributes. In any case, this should be specified clearly to avoid interoperation problems. - Section 6.4 Section 6.4 uses the phrase "sessions a UA may set up in parallel". Does this refer to the set of sessions for a single dialog? Or the set of all sessions of all dialogs that the UA is participating in at one time? - Section 6.10 Do we want to be subordinate to ? This is arguably a layer violation: and could be siblings under an element that declares that the policy applies to the context. This allows to have defined semantics, but allowing its containing element/message to determine what those semantics apply to. - Section 8 The TBD note at the beginning of section 8 (and the task it described) can be removed now that sipping-profile-datasets has been abandoned. Where is the up-to-date version of "uaprofile.rng"? What is the proper URL to access it? - Imported from ietf-sipping-profile-datasets The 'policy' and 'excluded-policy' attributes are quite grotty, as they can be used only in specific combinations among several related elements, and are quite verbose in any case. It would be much better to define a "set" construct (to specify a finite set of permitted values) and a "set-complement" construct (to specify all values are permitted except a finite set of values). These constructs have the same expressive power as the existing attributes. E.g.: audio video audio/G729 audio/G723 becomes audio video audio/G729 audio/G723 but correct usage of this form is much easier to describe in the schema. (Looking at the example, perhaps we want to replace the and elements with "set" and "set-complement" attributes on its parent element. That is less mathematically pure, but has the same expressive power and is more terse.) As far as I can tell, there are nine "container" types which use the set/complement mechanism: 6.1 container of 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 The "direction" attribute seems to be weakly defined. As far as I can tell, in a policy one can have, for any of the nine container types, (1) no element, (2) one element with the value "sendrecv", or (3) optionally one element with the value "sendonly" and optionally one element with the value "recvonly". But this is not stated in either this draft or draft-petrie-sipping-profile-datasets and I might well be wrong. Also, if we still utilize merging, we need to state that case (2) is equivalent to duplicating the value, with one copy marked "sendonly" and one marked "recvonly", so that we have explicitly shown how to align two containers with direction attributes in order to merge (intersect) them. - Empty elements There are a lot of situations where it is sensible for an element to have zero sub-elements, in that the stated rules give a clear meaning to the element. In particular, any "set" construct with zero elements permits nothing, and any "set-complement" construct with zero elements permits everything. But most of the relevant elements (including all the container types) are defined to require at least one sub-element. However, there is currently a special case in section 4: It states that an empty rejects a session. (If it wasn't for the defined special case, a session with *no* streams would be admissible under this policy.) It would be better if the "reject everything" state could be described in a different manner, so as to avoid the special case. - The word "container" Beware of the use of the word "container". In the session-policy-dataset, "container" is (mostly) used to describe elements which inherit from . I suggest that we restrict the use in media-policy-dataset in that way. Although now that we are removing session-policy-dataset, "container" is no longer defined by , but it still means the elements which carry "direction", "policy", etc. That change would require rewriting these paragraphs of 6.1: The element can only be used in session policy document (i.e., inside the >>element<<). This element MAY have the following attributes (see Section 3.3): direction, visibility, excluded-policy. Multiple elements MAY only be present in a element if each applies to a different set of streams (i.e., one element for incoming and one for outgoing streams). The element MUST contain one or more elements. There may be other uses of "container" that should be changed. - "Registered" requirements In a number of places, parameters are required to have values that are appropriately registered. On the face of it, this prevents experimental or private-use values from being used at all. This is probably not what we intend. Given that there is general knowledge of how to create private-use values, these registration requirements should just be deleted. From dworley@nortel.com Wed Dec 9 13:40:33 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CBC3A690C for ; Wed, 9 Dec 2009 13:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0PK2SnkaoXi for ; Wed, 9 Dec 2009 13:40:32 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 595B63A680F for ; Wed, 9 Dec 2009 13:40:32 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nB9LeC429643; Wed, 9 Dec 2009 21:40:12 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 16:39:57 -0500 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4AFADAD9.7040402@cisco.com> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com> <9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de> <4AF7934B.7080902@cisco.com> <9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> <4AFAD1 50.9070900@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372CDE@S4DE8PSAAQB.mitte.t-com.d e> <4AFADAD9.7040402@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 09 Dec 2009 16:39:57 -0500 Message-Id: <1260394797.4277.39.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 21:39:57.0442 (UTC) FILETIME=[2706E620:01CA7918] Cc: paul.while@ericsson.com, dispatch@ietf.org, R.Jesske@telekom.de, calme@alcatel-lucent.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 21:40:33 -0000 On Wed, 2009-11-11 at 10:40 -0500, Paul Kyzivat wrote: > > R.Jesske@telekom.de wrote: > > Hi Paul, > > Sorry. I was to fast with my writing an sending. > > What I meant to write was the 100. But I dont know any other 1xx beyond 18x and 199 that would fit. Or did I forgot one. > > > > Or is it more the general avalibility for 1xx for future. > > Enumerating which ones are meaningful isn't future proof. > Maybe this is a special case since there is a requirement to explicitly > document which responses this header may appear in (why?), > but IMO it would be better not to second guess, and just allow them all. Yes, we should generically allow Reason in any 101-199 or final response. The proper use of "Reason: Q.850;cause=..." is "to describe the cause for the generation of the response by a datum that is to be interpreted based on the Q.850 standard". The usual reason for this is that the ultimate cause of the generation of the response was an SS7 protocol operation that contained the specified cause code, but even that need not be true. The goal is to specify how the receiver should interpret the header; based on that, the restrictions on the sender are implied. Dale From krehor@cisco.com Wed Dec 9 18:09:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB663A6877 for ; Wed, 9 Dec 2009 18:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6TSaUECJHaN for ; Wed, 9 Dec 2009 18:09:22 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 064C73A6862 for ; Wed, 9 Dec 2009 18:09:22 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: IETF SRP Charter - draft 20091120.txt : 2757 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEfnH0urRN+K/2dsb2JhbAC+YIkJCY4BgiMJBxWBZASNRg X-IronPort-AV: E=Sophos;i="4.47,371,1257120000"; d="txt'?scan'208,217";a="117084295" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2009 02:09:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBA29BbS008990 for ; Thu, 10 Dec 2009 02:09:11 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 18:09:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA793D.C31E0D68" Date: Wed, 9 Dec 2009 18:09:09 -0800 Message-ID: <7744FE52C78D944587F03773EB451461066A8EA0@xmb-sjc-22e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session Recording Protocol - Working Group Charter Thread-Index: AcpqGezeSOLoVd8qTSaYaZ91SSjJ+w== From: "Ken Rehor (krehor)" To: X-OriginalArrivalTime: 10 Dec 2009 02:09:11.0012 (UTC) FILETIME=[C34E1240:01CA793D] Subject: [dispatch] Session Recording Protocol - Working Group Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 02:09:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA793D.C31E0D68 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA793D.C31E0D68" ------_=_NextPart_002_01CA793D.C31E0D68 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Attached is the Session Recording Protocol Working Group Charter updated to reflect comments and concerns raised at the Dispatch meeting in Hiroshima. =20 We previously sent this to Dispatch Chairs Mary Barnes and Gonzalo Camarillo. Please post any comments, questions, or suggested changes. =20 Thanks very much, =20 Ken Rehor krehor@cisco.com +1 408 902 3107 =20 ------_=_NextPart_002_01CA793D.C31E0D68 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Attached is the=20 Session Recording Protocol Working Group Charter updated to reflect = comments and=20 concerns raised at the Dispatch meeting in = Hiroshima.
 
We = previously sent=20 this to Dispatch Chairs Mary Barnes and Gonzalo Camarillo. =20 Please post any comments, questions, or suggested=20 changes.
 
Thanks = very=20 much,
 
Ken=20 Rehor
krehor@cisco.com
=
+1 408 = 902=20 3107
 
------_=_NextPart_002_01CA793D.C31E0D68-- ------_=_NextPart_001_01CA793D.C31E0D68 Content-Type: text/plain; name="IETF SRP Charter - draft 20091120.txt" Content-Transfer-Encoding: base64 Content-Description: IETF SRP Charter - draft 20091120.txt Content-Disposition: attachment; filename="IETF SRP Charter - draft 20091120.txt" DQoNCg0KU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2wgLSBXb3JraW5nIEdyb3VwIENoYXJ0ZXIN Cg0KVGhlIFNlc3Npb24gUmVjb3JkaW5nIFByb3RvY29sIChTUlApIHdvcmtpbmcgZ3JvdXAgaXMg Y2hhcnRlcmVkIHRvIGRlZmluZSBhIFNJUC1iYXNlZCBwcm90b2NvbCANCmZvciBjb250cm9sbGlu ZyBhIHNlc3Npb24gKG1lZGlhKSByZWNvcmRlci4NCg0KU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBj cml0aWNhbCByZXF1aXJlbWVudCBpbiBtYW55IGJ1c2luZXNzIGNvbW11bmljYXRpb25zIGVudmly b25tZW50cyBzdWNoIA0KYXMgY2FsbCBjZW50ZXJzIGFuZCBmaW5hbmNpYWwgdHJhZGluZyBmbG9v cnMuICBJbiBzb21lIG9mIHRoZXNlIGVudmlyb25tZW50cywgYWxsIGNhbGxzIG11c3QgDQpiZSBy ZWNvcmRlZCBmb3IgcmVndWxhdG9yeSBhbmQgY29tcGxpYW5jZSByZWFzb25zLiAgSW4gb3RoZXJz LCBjYWxscyBtYXkgYmUgcmVjb3JkZWQgZm9yIHF1YWxpdHkgDQpjb250cm9sLCBidXNpbmVzcyBh bmFseXRpY3MsIG9yIGNvbnN1bWVyIHByb3RlY3Rpb24uICBSZWNvcmRpbmcgaXMgdHlwaWNhbGx5 IGRvbmUgYnkgc2VuZGluZyBhIA0KY29weSBvZiB0aGUgbWVkaWEgdG8gdGhlIHJlY29yZGluZyBk ZXZpY2VzLiAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXRlcm1pbmUgcmVxdWlyZW1lbnRzIGFu ZCANCnByb2R1Y2UgYSBzcGVjaWZpY2F0aW9uIGZvciBhIHByb3RvY29sIHRoYXQgd2lsbCBtYW5h Z2UgZGVsaXZlcnkgb2YgbWVkaWEgZnJvbSBhbiBlbmQtcG9pbnQgdGhhdCANCm9yaWdpbmF0ZXMg bWVkaWEsIG9yIHRoYXQgaGFzIGFjY2VzcyB0byBpdCwgdG8gYSByZWNvcmRpbmcgZGV2aWNlLiBQ QlggYW5kIHJlY29yZGluZyB2ZW5kb3JzIA0KdG9kYXkgaW1wbGVtZW50IHByb3ByaWV0YXJ5LCBp bmNvbXBhdGlibGUgbWVjaGFuaXNtcyB0byBmYWNpbGl0YXRlIHJlY29yZGluZy4gQSBzdGFuZGFy ZCBwcm90b2NvbCANCndpbGwgcmVkdWNlIHRoZSBjb21wbGV4aXR5IGFuZCBjb3N0IG9mIHByb3Zp ZGluZyBzdWNoIHJlY29yZGluZyBzZXJ2aWNlcy4NCg0KVGhlIFNlc3Npb24gUmVjb3JkaW5nIHBy b2JsZW0gcHJlc2VudHMgY2VydGFpbiB1bmlxdWUgcmVxdWlyZW1lbnRzIHRoYXQgYXJlIG5vdCBh ZGRyZXNzZWQgaW4gdGhlIA0KY3VycmVudCBTSVAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4gVGhl c2UgaW5jbHVkZSByZXF1aXJlbWVudHMgc3VjaCBhcyB0aGUgbmVlZCBmb3IgYSBkaXN0aW5jdGlv biANCmJldHdlZW4gdGhlIHNlc3Npb24gdGhhdCBpcyBiZWluZyByZWNvcmRlZCB2ZXJzdXMgdGhl IHNlc3Npb24gdGhhdCBoYXMgYmVlbiBlc3RhYmxpc2hlZCBmb3IgcmVjb3JkaW5nLg0KDQpQcml2 YWN5IGFuZCBzZWN1cml0eSBvZiBjb252ZXJzYXRpb25zIGFyZSBzaWduaWZpY2FudCBjb25jZXJu cy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBtYWtlIHN1cmUgDQp0aGF0IGFueSBwcm90b2NvbCBz cGVjaWZpZWQgYWRkcmVzc2VzIHRoZXNlIGNvbmNlcm5zIGFuZCBwcm92aWRlcyBtZWNoYW5pc21z IHRvIGFsZXJ0IHVzZXJzIHRvIA0KdGhlIGZhY3QgdGhhdCBhIHNlc3Npb24gdGhleSBhcmUgcGFy dGljcGF0aW5nIGluIGlzIGJlaW5nIHJlY29yZGVkLg0KDQpUaGUgd29ya2luZyBncm91cCBtdXN0 IHRha2UgY2FyZSB0aGF0IHRoZSBzZXNzaW9uIHJlY29yZGluZyByZXF1aXJtZW50cyBhbmQgcHJv dG9jb2wgZG9lcyBub3QgDQpjb25mbGljdCB3aXRoIHRoZSBJRVRGIHN0YXRlbWVudCBvbiB3aXJl dGFwcGluZyBjb250YWluZWQgaW4gUkZDIDI4MDQuDQoNCg0KVGhlIFNSUCBXb3JraW5nIEdyb3Vw IHdpbGwgdGhvcm91Z2hseSBpZGVudGlmeSB1c2UgY2FzZXMsIHByb3ZpZGUgZXhhbXBsZSBzeXN0 ZW0gYXJjaGl0ZWN0dXJlcyANCmFuZCBkZXBsb3ltZW50IHNjZW5hcmlvcywgYW5kIGRlZmluZSBy ZXF1aXJlbWVudHMuDQoNClRoZSBzY29wZSBvZiB0aGUgYWN0aXZpdHkgaW5jbHVkZXM6DQoNCiAg KiBSZWNvcmRlciBDb250cm9sDQogICogU2Vzc2lvbiBtZXRhZGF0YSBjb250ZW50IGFuZCBmb3Jt YXQNCiAgKiBTZWN1cml0eSBtZWNoYW5pc21zLCBpbmNsdWRpbmcgdHJhbnNwb3J0IGFuZCBtZWRp YSBlbmNyeXB0aW9uDQogICogUHJpdmFjeSBjb25jZXJucywgaW5jbHVkaW5nIGVuZC11c2VyIG5v dGlmaWNhdGlvbg0KICAqIE5lZ290aWF0aW9uIG9mIHJlY29yZGluZyBtZWRpYSBzdHJlYW1zDQoN ClRoZSBncm91cCB3aWxsIGRlZmluZSB0aGVzZSBpc3N1ZXMgYW5kIHJhdGlvbmFsaXplIHdpdGgg SUVURiBzdGFuZGFyZHMgYW5kIHByYWN0aWNlcy4gVGhpcyBpbmNsdWRlcyANCmVuY3J5cHRpb24s IE5BVCB0cmF2ZXJzYWwsIFNJUC1lbmFibGVkIGZpcmV3YWxscywgYXV0aG9yaXphdGlvbiwgYW5k IHNlY3VyaXR5Lg0KDQpUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlOg0KDQogICogVXBkYXRlZCBSZXF1 aXJlbWVudHMsIFVzZSBDYXNlcywgQXJjaGl0ZWN0dXJlIGRyYWZ0DQogICogU3BlY2lmaWNhdGlv biBmb3IgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2wNCg0KVGltZWxpbmU6DQoNCiAgIEFwciAy MDEwICAgVXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFs IERyYWZ0DQoNCiAgIE5vdiAyMDEwICAgQXJjaGl0ZWN0dXJlIHRvIElFU0cgYXMgSW5mb3JtYXRp b25hbCBEcmFmdA0KDQogICBOb3YgMjAxMCAgIFN1Ym1pdCBwcm90b2NvbCBkcmFmdCB0byBJRVNH IGFzIHN0YW5kYXJkcyB0cmFjaw0K ------_=_NextPart_001_01CA793D.C31E0D68-- From adie@radvision.com Wed Dec 9 22:19:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599493A695C for ; Wed, 9 Dec 2009 22:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqeq0mIroxqs for ; Wed, 9 Dec 2009 22:19:09 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id A2BEF3A6A58 for ; Wed, 9 Dec 2009 22:18:57 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id nBA6GpJs030429 for dispatch@ietf.org; Thu, 10 Dec 2009 08:16:51 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id nBA6GpYk030423 for ; Thu, 10 Dec 2009 08:16:51 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7960.7CE48500" Date: Thu, 10 Dec 2009 08:17:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a dual stack UA? Thread-index: Acp5YGxfBMRwRDSARvaKt8gAZhG9wg== From: "Adi Shachar(Even-Tzur)" To: Subject: [dispatch] draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a dual stack UA? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:19:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7960.7CE48500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 As I understand this draft will become an RFC. =20 I would like to better understand the recommendation of the draft for the mixed ipv4/ipv6 UA behavior. My main concern is regarding the Offer out such a UA should create.=20 The idea mentioned in the draft is to enable communication both in ipv4 or ipv6, but the question is how exactly it should be done. =20 There are few options for the OFFER out (assuming we have audio & video): 1. Include total of 2 'm' lines: one 'm' line for audio and one 'm' line for video (with 2 'c' lines each, one in ipv4 and one in ipv6). 2. Include total of 4 'm' lines: one 'm' line for audio with 'c' line with ipv4, one 'm' line for audio with 'c ' line with ipv6, one 'm' line for video with 'c' line with ipv4 and one 'm' line for video with 'c ' line with ipv6 (RFC 4091). 3. The draft refer that the problem should be solved using STUN relay. As far as I know, the STUN server returns MY public address and not the destination address, so how does the UA know from STUN response what does the destination address support, ipv4 or ipv6? Should the Offering UA, based on STUN relay, know whether to include only ipv4 or ipv6 in the 'm' lines? 4. Any other option? =20 =20 thanks, Adi. =20 ------_=_NextPart_001_01CA7960.7CE48500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

As I understand this draft will become an = RFC.

 

I would like to better understand the recommendation = of the draft for the mixed ipv4/ipv6 UA behavior.

My main concern is regarding the Offer out such a = UA should create.

The idea mentioned in the draft  is to enable = communication both in ipv4 or ipv6, but the question is how exactly it should be = done.

 

There are few options for  the OFFER out = (assuming we have audio & video):

1.       Include total of 2 = ‘m’ lines: one ‘m’ line for audio and one ‘m’ line for video = (with 2 ‘c’ lines each, one in ipv4 and one in ipv6).

2.       Include  total of 4 = ‘m’ lines: one ‘m’ line for audio with ‘c’ line with = ipv4,  one ‘m’ line for audio with ‘c ‘ line with ipv6, one ‘m’ line for = video with ‘c’ line with ipv4 and one ‘m’ line for video with ‘c ‘ line with = ipv6 (RFC 4091).

3.       The draft refer that the = problem should be solved using STUN relay. As far as I know, the STUN server = returns MY public address and not the destination address, so how does the UA know = from STUN response what does the destination address support, ipv4 or ipv6? = Should the Offering UA, based on STUN relay, know whether to include only ipv4 = or ipv6 in the ‘m’ lines?

4.       Any other = option?

 

 

thanks,

Adi.

 

------_=_NextPart_001_01CA7960.7CE48500-- From emcho@sip-communicator.org Thu Dec 10 00:41:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB38E3A69CD for ; Thu, 10 Dec 2009 00:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2LD30Pgorhe for ; Thu, 10 Dec 2009 00:41:52 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 8A8E93A6962 for ; Thu, 10 Dec 2009 00:41:51 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1120654eyd.51 for ; Thu, 10 Dec 2009 00:41:37 -0800 (PST) Received: by 10.213.24.3 with SMTP id t3mr2262535ebb.40.1260434496941; Thu, 10 Dec 2009 00:41:36 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 13sm377036ewy.9.2009.12.10.00.41.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 00:41:35 -0800 (PST) Sender: Emil Ivov Message-ID: <4B20B43E.9030200@sip-communicator.org> Date: Thu, 10 Dec 2009 09:41:34 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 08:41:53 -0000 Hey Simo, all, I haven't seen anything in the charter being said about common authentication of a client against the SIP and the XMPP service. Consider for example a provider that is deploying a SIP+XMPP service. Is it supposed to: a) deliver to its users two different sets of credentials and connection information and expect everyone of them to configure two different accounts in order to use their service or b) distribute proprietory clients that somehow "know" they should use the same username and password with both services. I am thinking that we should probably have this specified and my concern is that unless we specifically state it in the charter the following line might prevent us from doing so: > The goal is to rely on existing service infrastructure, and new > requirements should be imposed only on the endpoints. If we agree to slightly loosen the above then we could also add an objective along these lines: - authentication; when authenticating against a SIP and an XMPP service that were meant to be used jointly, end users should only need to provide a single set of credentials. How does this sound? Emil =D0=9D=D0=B0 09.12.09 14:11, Simo.Veikkolainen@nokia.com =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: > Hello, > Below is the proposed charter text for Combining SIP and XMPP revised a= ccording to the discussions in Hiroshima. Basically the changes are >=20 > - include video in addition to voice > - mention that existing SIP and XMPP endpoints are not affected > - update milestones. >=20 > Comments are very welcome. >=20 > Regards, > Simo >=20 >=20 > -----8<------8<------8<------ >=20 > Combining SIP VoIP and XMPP IM/Presence > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Currently most standards-based Voice over IP (VoIP) deployments use the= Session Initiation Protocol (SIP). In addition to providing basic voice= service SIP has an extensive support for more advanced telephony feature= s including interworking with the traditional Public Switched Telephone N= etwork (PSTN). SIP is also gaining popularity in the field of video comm= unication. At the same time, the Extensible Messaging and Presence Protoc= ol (XMPP) is enjoying widespread usage in instant messaging and presence = services. =20 >=20 > Both SIP and XMPP offer extensions for integrating voice and video with= IM and presence (XMPP voice via the Jingle extension, and SIP IM/presenc= e via SIMPLE protocols). However, widespread deployment of these extensio= ns has not so far taken place. In order to speed up deployment of integra= ted VoIP and IM systems, SIP based voice and XMPP based IM/Presence could= be combined in endpoints to offer a voice, IM and presence service witho= ut any changes to existing SIP and XMPP service infrastructure.=20 >=20 > The objective of this Working Group is to develop solutions for combini= ng SIP based voice with XMPP based IM and Presence such that a unified us= er experience can be offered to end user. Specifically, solutions are nee= ded on=20 > - addressing; end users should be able to initiate sessions to a user i= dentity in either SIP or XMPP domain. The corresponding user identity in = the other protocol domain needs to be learned automatically. > - session correlation; endpoints need to be able to correlate SIP voice= and video sessions with XMPP IM/Presence in such a manner that they can = be presented to the end user in a seamless fashion > - presence; it should be possible to change the XMPP presence status ba= sed on the user's activity in the SIP domain. >=20 > Existing SIP and XMPP endpoints are not affected and can interoperate w= ith the implementations that comply with the extensions defined by this W= orking Group (but obviously without the additional functionality provided= by these extensions). >=20 > The goal is to rely on existing service infrastructure, and new require= ments should be imposed only on the endpoints.=20 >=20 > Protocol interworking, that is, translation from one protocol to anothe= r, is out of scope of this WG. >=20 > Milestones > Jun 2010 Problem statement and use cases submitted to IESG as Informati= onal. > Jun 2011 Specification on combining SIP based voice and video and XMPP = based IM/Presence in a seamless manner submitted to IESG as Proposed Stan= dard. >=20 > -----8<------8<------8<------ >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From andrew.hutton@siemens-enterprise.com Thu Dec 10 01:01:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEE33A67FA for ; Thu, 10 Dec 2009 01:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66V60NCwfhp8 for ; Thu, 10 Dec 2009 01:01:21 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 126C83A677C for ; Thu, 10 Dec 2009 01:01:20 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-248622; Thu, 10 Dec 2009 10:01:07 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CDB7023F0209; Thu, 10 Dec 2009 10:01:07 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 10 Dec 2009 10:01:08 +0100 From: "Hutton, Andrew" To: "Jain, Rajnish" , Peter Musgrave Date: Thu, 10 Dec 2009 10:01:12 +0100 Thread-Topic: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: Acp4RpN/JmWZLWQDT+aFrw70Bv7UigAm9CCQACUlq2A= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E306847E33BA@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Leon.Portman@nice.com" , "dispatch@ietf.org" , "HKaplan@acmepacket.com" Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 09:01:22 -0000 Yes I agree this should be clarified and it should be clear that both modes= are allowed (i.e. tx/rx mixed or seperated). Regards Andy =20 -----Original Message----- From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com]=20 Sent: 09 December 2009 15:20 To: Peter Musgrave; Hutton, Andrew Cc: dispatch@ietf.org; Leon.Portman@nice.com; HKaplan@acmepacket.com Subject: RE: [dispatch] Comments on draft-rehor-dispatch-session-recording-= req-00 Also: Is it worth stating as a requirement that the streams in each direction be = sent separately to the recording device (or is this implied?). Some recordi= ng devices check for times when both parties are talking - since in a call = center scenario such recordings may be discussions worth listening to... Peter Musgrave This is implied in REQ-010. I think we can add a clarifying note that indic= ates that the recording media streams may carry the Rx and Tx of recorded m= edia stream separately. o REQ-010 The mechanism MUST support the ability to deliver multiple media streams for a given Recorded Session over separate Recording Sessions to the RS. Thanks, Raj Jain On 2009-12-08, at 11:19 AM, Hutton, Andrew wrote: Some comments on the session recording requirements draft draft-rehor-dispa= tch-session-recording-req-00 1. The introduction states that the "recording sessions can be of any kind = such as voice, video and instant messaging". I think it would be sensible t= o restrict the scope to RTP based media (I.e. voice and video) and possibly= move out the instant messaging recording as a separate work item if needed= . Regards Andy Andrew Hutton Office of the CTO. Siemens Enterprise Communications. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From spromano@unina.it Thu Dec 10 03:06:21 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4AF3A699A for ; Thu, 10 Dec 2009 03:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svhsz+8QK1Jb for ; Thu, 10 Dec 2009 03:06:20 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 45BEF3A6842 for ; Thu, 10 Dec 2009 03:06:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nBAB658p025103 for ; Thu, 10 Dec 2009 12:06:05 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 10 Dec 2009 12:06:05 +0100 Message-ID: <20091210120605.vtv7d7ttwk8w8s84@webmail.unina.it> Date: Thu, 10 Dec 2009 12:06:05 +0100 From: spromano@unina.it To: dispatch@ietf.org References: <7744FE52C78D944587F03773EB451461066A8EA0@xmb-sjc-22e.amer.cisco.com> In-Reply-To: <7744FE52C78D944587F03773EB451461066A8EA0@xmb-sjc-22e.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it X-Virus-Status: Clean Subject: Re: [dispatch] Session Recording Protocol - Working Group Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:06:22 -0000 I like this charter text. Simon Quoting "Ken Rehor (krehor)" : > Attached is the Session Recording Protocol Working Group Charter updated > to reflect comments and concerns raised at the Dispatch meeting in > Hiroshima. > > We previously sent this to Dispatch Chairs Mary Barnes and Gonzalo > Camarillo. Please post any comments, questions, or suggested changes. > > Thanks very much, > > Ken Rehor > krehor@cisco.com > +1 408 902 3107 > > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From scott.lawrence@nortel.com Thu Dec 10 04:34:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B29D3A69D5 for ; Thu, 10 Dec 2009 04:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjpKRXfVyfcI for ; Thu, 10 Dec 2009 04:34:09 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 962973A69C1 for ; Thu, 10 Dec 2009 04:34:09 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBACXpi05354; Thu, 10 Dec 2009 12:33:51 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 07:33:36 -0500 From: "Scott Lawrence" To: Emil Ivov In-Reply-To: <4B20B43E.9030200@sip-communicator.org> References: <4B20B43E.9030200@sip-communicator.org> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 10 Dec 2009 07:33:35 -0500 Message-Id: <1260448415.25475.1800.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2009 12:33:36.0508 (UTC) FILETIME=[FE7B13C0:01CA7994] Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 12:34:10 -0000 On Thu, 2009-12-10 at 09:41 +0100, Emil Ivov wrote: > > - authentication; when authenticating against a SIP and an XMPP > service > that were meant to be used jointly, end users should only need to > provide a single set of credentials. In theory, it may already be possible to do what you want, at least from one side... RFC 2617 (used for both SIP and HTTP) already specifies a 'domain' parameter in the WWW-Authenticate header used to challenge a SIP UA: domain A quoted, space-separated list of URIs, as specified in RFC XURI [7], that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL (see section 1.2 above) of the server being accessed. An absoluteURI in this list may refer to a different server than the one being accessed. The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a prefix (after both have been made absolute) may be assumed to be in the same protection space. If this directive is omitted or its value is empty, the client should assume that the protection space consists of all URIs on the responding server. If the SIP server were to include an xmpp: URI in that list, then the challenged SIP UA could reasonably infer that the credentials it has for that XMPP service are also valid at this SIP service. From stpeter@stpeter.im Thu Dec 10 09:45:50 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B0F3A6B4C for ; Thu, 10 Dec 2009 09:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uycdeKIt8cX for ; Thu, 10 Dec 2009 09:45:49 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 775143A68A4 for ; Thu, 10 Dec 2009 09:45:33 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 70EEB40332; Thu, 10 Dec 2009 10:45:21 -0700 (MST) Message-ID: <4B2133B0.5090903@stpeter.im> Date: Thu, 10 Dec 2009 10:45:20 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070704090905000504040608" Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:45:50 -0000 This is a cryptographically signed message in MIME format. --------------ms070704090905000504040608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit +1 On 12/9/09 6:11 AM, Simo.Veikkolainen@nokia.com wrote: > Hello, Below is the proposed charter text for Combining SIP and XMPP > revised according to the discussions in Hiroshima. Basically the > changes are > > - include video in addition to voice - mention that existing SIP and > XMPP endpoints are not affected - update milestones. > > Comments are very welcome. > > Regards, Simo > > > -----8<------8<------8<------ > > Combining SIP VoIP and XMPP IM/Presence > ======================================= > > Currently most standards-based Voice over IP (VoIP) deployments use > the Session Initiation Protocol (SIP). In addition to providing > basic voice service SIP has an extensive support for more advanced > telephony features including interworking with the traditional Public > Switched Telephone Network (PSTN). SIP is also gaining popularity in > the field of video communication. At the same time, the Extensible > Messaging and Presence Protocol (XMPP) is enjoying widespread usage > in instant messaging and presence services. > > Both SIP and XMPP offer extensions for integrating voice and video > with IM and presence (XMPP voice via the Jingle extension, and SIP > IM/presence via SIMPLE protocols). However, widespread deployment of > these extensions has not so far taken place. In order to speed up > deployment of integrated VoIP and IM systems, SIP based voice and > XMPP based IM/Presence could be combined in endpoints to offer a > voice, IM and presence service without any changes to existing SIP > and XMPP service infrastructure. > > The objective of this Working Group is to develop solutions for > combining SIP based voice with XMPP based IM and Presence such that a > unified user experience can be offered to end user. Specifically, > solutions are needed on - addressing; end users should be able to > initiate sessions to a user identity in either SIP or XMPP domain. > The corresponding user identity in the other protocol domain needs to > be learned automatically. - session correlation; endpoints need to be > able to correlate SIP voice and video sessions with XMPP IM/Presence > in such a manner that they can be presented to the end user in a > seamless fashion - presence; it should be possible to change the XMPP > presence status based on the user's activity in the SIP domain. > > Existing SIP and XMPP endpoints are not affected and can interoperate > with the implementations that comply with the extensions defined by > this Working Group (but obviously without the additional > functionality provided by these extensions). > > The goal is to rely on existing service infrastructure, and new > requirements should be imposed only on the endpoints. > > Protocol interworking, that is, translation from one protocol to > another, is out of scope of this WG. > > Milestones Jun 2010 Problem statement and use cases submitted to IESG > as Informational. Jun 2011 Specification on combining SIP based voice > and video and XMPP based IM/Presence in a seamless manner submitted > to IESG as Proposed Standard. > > -----8<------8<------8<------ > > > _______________________________________________ dispatch mailing list > dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------ms070704090905000504040608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxMDE3NDUyMFowIwYJKoZIhvcNAQkEMRYEFCoR7lSHrBloVRYvKbpm pEPjzbUwMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAExRkLf09YAhEzCeRgWrCG/Lmym+igMuoi/14sDhE 4u0stQOfzoDryYCMc1hu7ireFBQtFwrokA4TEnxlQl7QLYxhFVBag61MIlU3+Iio/1I+ZiKq hD9SEZ0nYipc/LLaYjSBNcr5lUbOlxQC1lIyuANj4IKONyuMcF3vNPOxYAUN9N97mGGDvi82 1WzjUcGFS4lDfln2Jgl0qDFI4kStklPprlgaltgXfG9agVSzJQZTX16TJWBcC9dQf3tjPxXB kiKLUHjDJSKe41r0NTLtNEB0/m6H+fsKHOXAK3Lql5j2wP+5TJfEoOMzGGNMuegrYrS2gNZV 3yie9Ch6Rv7XowAAAAAAAA== --------------ms070704090905000504040608-- From stpeter@stpeter.im Thu Dec 10 09:49:55 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE583A68A4 for ; Thu, 10 Dec 2009 09:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjdK8PSoq9QP for ; Thu, 10 Dec 2009 09:49:54 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 59D483A67F0 for ; Thu, 10 Dec 2009 09:49:54 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8BBC740332; Thu, 10 Dec 2009 10:49:42 -0700 (MST) Message-ID: <4B2134B5.30409@stpeter.im> Date: Thu, 10 Dec 2009 10:49:41 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Emil Ivov References: <4B20B43E.9030200@sip-communicator.org> In-Reply-To: <4B20B43E.9030200@sip-communicator.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040207040702010703020508" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:49:55 -0000 This is a cryptographically signed message in MIME format. --------------ms040207040702010703020508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/10/09 1:41 AM, Emil Ivov wrote: > Hey Simo, all, > > I haven't seen anything in the charter being said about common > authentication of a client against the SIP and the XMPP service. > Consider for example a provider that is deploying a SIP+XMPP service. > Is it supposed to: > > a) deliver to its users two different sets of credentials and > connection information and expect everyone of them to configure two > different accounts in order to use their service > > or > > b) distribute proprietory clients that somehow "know" they should use > the same username and password with both services. > > I am thinking that we should probably have this specified and my > concern is that unless we specifically state it in the charter the > following line might prevent us from doing so: > >> The goal is to rely on existing service infrastructure, and new >> requirements should be imposed only on the endpoints. > > If we agree to slightly loosen the above then we could also add an > objective along these lines: > > - authentication; when authenticating against a SIP and an XMPP > service that were meant to be used jointly, end users should only > need to provide a single set of credentials. > > How does this sound? It sounds out of scope to me. This is a matter of local service policy. Yes, it's a good idea for a given service operator to do that, but the proposed WG will not (and IMHO should not) be defining best practices for service operators, but instead focusing on the more narrow problem of defining protocol elements that will enable end users to have a seamless experience in dual-stack clients. Not that I'm opposed to a best practices document for service operators, but I think that can be handled via an independent submission. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms040207040702010703020508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxMDE3NDk0MVowIwYJKoZIhvcNAQkEMRYEFG1On+s0MhVOfziGmJlF jJgR7PzXMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAKpSJfq+Ya/EDaQzR7wR33cBU/eqagKed9/XzVKHk IxR4OyEBx5S8eee9o/GqcKM3IbisZhwsxoYBURH0Xw41QBe+wLwxkRfSpkUldAejCOQypaAA NCC9tkdkZDh9BnffBg3fPCLekMUHd8t3jpL7DU/dnW0OZgYe60K1OOlWYeTGc2BqhV2wuFR/ U5zT21ohfZWtn3vlrvyukQMyENvLTpMJlxwWxO/4HOjCnkHD1aqFbjHTHnS/KOuUMK2tj/l4 gUJAOtxe8nFjph9U/3Kjvh4tcDfkp0p6/0HQiXoV+eyq8YoZLHqRT+PHsdPZbbweSk7vzErb EerA8dFrF9hmsAAAAAAAAA== --------------ms040207040702010703020508-- From emcho@sip-communicator.org Thu Dec 10 10:40:03 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BAA3A6801 for ; Thu, 10 Dec 2009 10:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3aGg-EzX0r7 for ; Thu, 10 Dec 2009 10:40:02 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 16AC93A6824 for ; Thu, 10 Dec 2009 10:40:01 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so96857eyd.51 for ; Thu, 10 Dec 2009 10:39:46 -0800 (PST) Received: by 10.213.96.207 with SMTP id i15mr3075326ebn.69.1260470386486; Thu, 10 Dec 2009 10:39:46 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 24sm2285622eyx.22.2009.12.10.10.39.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 10:39:44 -0800 (PST) Sender: Emil Ivov Message-ID: <4B21406E.60605@sip-communicator.org> Date: Thu, 10 Dec 2009 19:39:42 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> In-Reply-To: <4B2134B5.30409@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:40:03 -0000 =D0=9D=D0=B0 10.12.09 18:49, Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > On 12/10/09 1:41 AM, Emil Ivov wrote: >> Hey Simo, all, >> >> I haven't seen anything in the charter being said about common=20 >> authentication of a client against the SIP and the XMPP service.=20 >> Consider for example a provider that is deploying a SIP+XMPP service. >> Is it supposed to: >> >> a) deliver to its users two different sets of credentials and=20 >> connection information and expect everyone of them to configure two=20 >> different accounts in order to use their service >> >> or >> >> b) distribute proprietory clients that somehow "know" they should use >> the same username and password with both services. >> >> I am thinking that we should probably have this specified and my=20 >> concern is that unless we specifically state it in the charter the=20 >> following line might prevent us from doing so: >> >>> The goal is to rely on existing service infrastructure, and new=20 >>> requirements should be imposed only on the endpoints. >> >> If we agree to slightly loosen the above then we could also add an=20 >> objective along these lines: >> >> - authentication; when authenticating against a SIP and an XMPP >> service that were meant to be used jointly, end users should only >> need to provide a single set of credentials. >> >> How does this sound? >=20 > It sounds out of scope to me.=20 Well, aren't we in the process of defining the scope? > This is a matter of local service policy. How should a user agent discover this policy? > Yes, it's a good idea for a given service operator to do that, but the > proposed WG will not (and IMHO should not) be defining best practices > for service operators, but instead focusing on the more narrow problem > of defining protocol elements that will enable end users to have a > seamless experience in dual-stack clients. Not that I'm opposed to a > best practices document for service operators, but I think that can be > handled via an independent submission. My concern is that unless we clearly define this it would be hard for UA developers to come up with a solution that is both generic and user friendly. Again, you would either need to make users configure two separate accounts, or make service providers distribute proprietary clients. I thought it was part of IETF's job to avoid such things. Cheers, Emil From emcho@sip-communicator.org Thu Dec 10 10:47:45 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B683A6947 for ; Thu, 10 Dec 2009 10:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yvEUhJeSjPw for ; Thu, 10 Dec 2009 10:47:44 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 40C1D3A6A18 for ; Thu, 10 Dec 2009 10:47:44 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so98629eyd.51 for ; Thu, 10 Dec 2009 10:47:31 -0800 (PST) Received: by 10.213.100.161 with SMTP id y33mr380417ebn.2.1260470851528; Thu, 10 Dec 2009 10:47:31 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 13sm674918ewy.5.2009.12.10.10.47.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 10:47:30 -0800 (PST) Sender: Emil Ivov Message-ID: <4B214241.9030502@sip-communicator.org> Date: Thu, 10 Dec 2009 19:47:29 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Scott Lawrence References: <4B20B43E.9030200@sip-communicator.org> <1260448415.25475.1800.camel@scott> In-Reply-To: <1260448415.25475.1800.camel@scott> Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:47:45 -0000 =CD=E0 10.12.09 13:33, Scott Lawrence =ED=E0=EF=E8=F1=E0: > On Thu, 2009-12-10 at 09:41 +0100, Emil Ivov wrote: >=20 > If the SIP server were to include an xmpp: URI in that list, then the > challenged SIP UA could reasonably infer that the credentials it has fo= r > that XMPP service are also valid at this SIP service. This could be one solution, indeed. However, in order for the SIP server to be able to include such a URI we need the charter to allow one of the xmpp+sip documents to state how cross authentication will be handled. Cheers, Emil From scott.lawrence@nortel.com Thu Dec 10 10:55:25 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B447D3A68C8 for ; Thu, 10 Dec 2009 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axrdGnPHQKOr for ; Thu, 10 Dec 2009 10:55:25 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7CEA928C12A for ; Thu, 10 Dec 2009 10:55:23 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBAIt8G08913; Thu, 10 Dec 2009 18:55:08 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 13:55:07 -0500 From: "Scott Lawrence" To: Emil Ivov In-Reply-To: <4B21406E.60605@sip-communicator.org> References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 10 Dec 2009 13:55:07 -0500 Message-Id: <1260471307.25475.1912.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2009 18:55:08.0052 (UTC) FILETIME=[4AE77D40:01CA79CA] Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:55:25 -0000 On Thu, 2009-12-10 at 19:39 +0100, Emil Ivov wrote: > > Again, you would either need to make users configure two separate > accounts, or make service providers distribute proprietary clients. I > thought it was part of IETF's job to avoid such things. I think it's the job of the IETF to describe/define how the protocol works on the wire; _not_ how service providers architect their offerings. There are any number of ways to do that, and for most of them the clients just don't need to know. From emcho@sip-communicator.org Thu Dec 10 11:07:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A293A6A26 for ; Thu, 10 Dec 2009 11:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXYUS3xA-oQL for ; Thu, 10 Dec 2009 11:07:03 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 7D4A93A6824 for ; Thu, 10 Dec 2009 11:07:02 -0800 (PST) Received: by ewy6 with SMTP id 6so194061ewy.29 for ; Thu, 10 Dec 2009 11:06:45 -0800 (PST) Received: by 10.213.23.200 with SMTP id s8mr3163033ebb.52.1260472005236; Thu, 10 Dec 2009 11:06:45 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 5sm2291599eyh.0.2009.12.10.11.06.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 11:06:44 -0800 (PST) Sender: Emil Ivov Message-ID: <4B2146C2.6060803@sip-communicator.org> Date: Thu, 10 Dec 2009 20:06:42 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Scott Lawrence References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> In-Reply-To: <1260471307.25475.1912.camel@scott> Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:07:04 -0000 =CD=E0 10.12.09 19:55, Scott Lawrence =ED=E0=EF=E8=F1=E0: > On Thu, 2009-12-10 at 19:39 +0100, Emil Ivov wrote: >> >> Again, you would either need to make users configure two separate >> accounts, or make service providers distribute proprietary clients. I >> thought it was part of IETF's job to avoid such things. >=20 > I think it's the job of the IETF to describe/define how the protocol > works on the wire; _not_ how service providers architect their > offerings. There are any number of ways to do that, and for most of > them the clients just don't need to know. This is not about service providers architecturing their offerings. This is about allowing UA developers to build clients which would work with _any_ provider. Clients that don't require users to enter two user names and two passwords so that they would connect to one service. Cheers, Emil From scott.lawrence@nortel.com Thu Dec 10 11:14:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC3B3A6A3E for ; Thu, 10 Dec 2009 11:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.064 X-Spam-Level: X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg3bPV8ToDRo for ; Thu, 10 Dec 2009 11:13:55 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B4EC63A6A2B for ; Thu, 10 Dec 2009 11:13:54 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBAJDdG14344; Thu, 10 Dec 2009 19:13:39 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 14:13:39 -0500 From: "Scott Lawrence" To: Emil Ivov In-Reply-To: <4B2146C2.6060803@sip-communicator.org> References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> Content-Type: text/plain; charset="UTF-8" Organization: Nortel Networks Date: Thu, 10 Dec 2009 14:13:38 -0500 Message-Id: <1260472418.25475.1915.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Dec 2009 19:13:39.0271 (UTC) FILETIME=[E13E0D70:01CA79CC] Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:14:00 -0000 On Thu, 2009-12-10 at 20:06 +0100, Emil Ivov wrote: >=20 > =D0=9D=D0=B0 10.12.09 19:55, Scott Lawrence =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > > On Thu, 2009-12-10 at 19:39 +0100, Emil Ivov wrote: > >> > >> Again, you would either need to make users configure two separate > >> accounts, or make service providers distribute proprietary clients. I > >> thought it was part of IETF's job to avoid such things. > >=20 > > I think it's the job of the IETF to describe/define how the protocol > > works on the wire; _not_ how service providers architect their > > offerings. There are any number of ways to do that, and for most of > > them the clients just don't need to know. >=20 > This is not about service providers architecturing their offerings. This > is about allowing UA developers to build clients which would work with > _any_ provider. Clients that don't require users to enter two user names > and two passwords so that they would connect to one service. ... but it's not one service - it's two. No one is suggesting that XMPP and SIP are to be merged. From emcho@sip-communicator.org Thu Dec 10 11:23:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2579828C12B for ; Thu, 10 Dec 2009 11:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JovuuMYEfuYc for ; Thu, 10 Dec 2009 11:23:13 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 0B71A28C139 for ; Thu, 10 Dec 2009 11:23:12 -0800 (PST) Received: by ewy6 with SMTP id 6so210545ewy.29 for ; Thu, 10 Dec 2009 11:22:57 -0800 (PST) Received: by 10.213.2.84 with SMTP id 20mr148688ebi.46.1260472975963; Thu, 10 Dec 2009 11:22:55 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 14sm693301ewy.3.2009.12.10.11.22.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 11:22:54 -0800 (PST) Sender: Emil Ivov Message-ID: <4B214A8D.9080608@sip-communicator.org> Date: Thu, 10 Dec 2009 20:22:53 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Scott Lawrence References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> In-Reply-To: <1260472418.25475.1915.camel@scott> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:23:14 -0000 =D0=9D=D0=B0 10.12.09 20:13, Scott Lawrence =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > On Thu, 2009-12-10 at 20:06 +0100, Emil Ivov wrote: >> >> =D0=9D=D0=B0 10.12.09 19:55, Scott Lawrence =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >>> On Thu, 2009-12-10 at 19:39 +0100, Emil Ivov wrote: >>>> >>>> Again, you would either need to make users configure two separate >>>> accounts, or make service providers distribute proprietary clients. = I >>>> thought it was part of IETF's job to avoid such things. >>> >>> I think it's the job of the IETF to describe/define how the protocol >>> works on the wire; _not_ how service providers architect their >>> offerings. There are any number of ways to do that, and for most of >>> them the clients just don't need to know. >> >> This is not about service providers architecturing their offerings. Th= is >> is about allowing UA developers to build clients which would work with= >> _any_ provider. Clients that don't require users to enter two user nam= es >> and two passwords so that they would connect to one service. >=20 > ... but it's not one service - it's two. No one is suggesting that XMP= P > and SIP are to be merged. Indeed not. We are suggesting that they are combinded "[so] that a unified user experience can be offered to end user." Cheers, Emil From spencer@wonderhamster.org Thu Dec 10 11:27:27 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0C93A687F for ; Thu, 10 Dec 2009 11:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kje163bqjitz for ; Thu, 10 Dec 2009 11:27:27 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 247A33A677E for ; Thu, 10 Dec 2009 11:27:27 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lm2Pp-1NrsIa0SfZ-00ZD2r; Thu, 10 Dec 2009 14:27:02 -0500 Message-ID: <8647CF2D344C40F19ABD162093605F46@china.huawei.com> From: "Spencer Dawkins" To: "Scott Lawrence" , "Emil Ivov" References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> Date: Thu, 10 Dec 2009 13:26:49 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/XMpL/yLoBrsZGbHAWpKP4xls8BDFZYF7p+/Z X7crJgjR5NdRvCTYeKfITW4h9XoSHw9FbdbfgbTLv/2K1q6b9X NQL0ZlPrqN4ULSBrAKQ3jdExjzMTGpsJYGQ+OYOGq0= Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:27:28 -0000 Hi, Scott and Emil, >> >> Again, you would either need to make users configure two separate >> >> accounts, or make service providers distribute proprietary clients. I >> >> thought it was part of IETF's job to avoid such things. >> > >> > I think it's the job of the IETF to describe/define how the protocol >> > works on the wire; _not_ how service providers architect their >> > offerings. There are any number of ways to do that, and for most of >> > them the clients just don't need to know. >> >> This is not about service providers architecturing their offerings. This >> is about allowing UA developers to build clients which would work with >> _any_ provider. Clients that don't require users to enter two user names >> and two passwords so that they would connect to one service. > > ... but it's not one service - it's two. No one is suggesting that XMPP > and SIP are to be merged. is this the disconnect - that Emil is thinking that either (1) one of the protocols changes to accept credentials from the other protocol, or (2) we come up with a mechanism that does single-signon for both protocols, while Scott is thinking that we're just connecting to two different services, with this detail hidden by whatever client application knows how to do both? Thanks, Spencer From emcho@sip-communicator.org Thu Dec 10 11:40:43 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0833A67B5 for ; Thu, 10 Dec 2009 11:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyDcHfAjwIvh for ; Thu, 10 Dec 2009 11:40:42 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 6357C3A6824 for ; Thu, 10 Dec 2009 11:40:41 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so435556eyf.5 for ; Thu, 10 Dec 2009 11:40:26 -0800 (PST) Received: by 10.213.0.144 with SMTP id 16mr3165881ebb.37.1260474025513; Thu, 10 Dec 2009 11:40:25 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 16sm701735ewy.2.2009.12.10.11.40.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 11:40:24 -0800 (PST) Sender: Emil Ivov Message-ID: <4B214EA7.1090405@sip-communicator.org> Date: Thu, 10 Dec 2009 20:40:23 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Spencer Dawkins References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> In-Reply-To: <8647CF2D344C40F19ABD162093605F46@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Simo.Veikkolainen@nokia.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:40:43 -0000 Hey Spencer, =D0=9D=D0=B0 10.12.09 20:26, Spencer Dawkins =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > is this the disconnect - that Emil is thinking that either (1) one of t= he=20 > protocols changes to accept credentials from the other protocol, or (2)= we=20 > come up with a mechanism that does single-signon for both protocols,=20 It doesn't need to be a protocol change or a new single-sinon mechanism. Both of these are possible options but probably a bit too disruptive given the we-are-not-inventing-a-new-protocol prerequisite that we have set ourselves. =46rom a UA perspective it would be enough to simply know (i.e. have it written somewhere) that clients use the same credentials against both servers. I am guessing however that simply enforcing this would contradict use cases that others here may have in mind. This is why I was suggesting that we should think this through once the new WG is formed. Cheers, Emil From RIFATYU@nortel.com Thu Dec 10 11:49:05 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC57A3A6841 for ; Thu, 10 Dec 2009 11:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnmej2BBxnlj for ; Thu, 10 Dec 2009 11:49:05 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ADB473A6830 for ; Thu, 10 Dec 2009 11:49:04 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBAJmjj27798; Thu, 10 Dec 2009 19:48:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 14:48:28 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02C0FEF9@zcarhxm2.corp.nortel.com> In-Reply-To: <4B214EA7.1090405@sip-communicator.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp50KilDLa0FBPQT4urlNvfWCJ1QgAADAAg References: <4B20B43E.9030200@sip-communicator.org><4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org><1260472418.25475.1915.camel@scott><8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> From: "Rifaat Shekh-Yusef" To: "Emil Ivov" , "Spencer Dawkins" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:49:06 -0000 Hi Emil, The following is a quote from the draft's abstract: "It is even possible that SIP and XMPP services are offered by different = service providers" In this case I do not think that you can use the same credentials for = both services. Regards, Rifaat -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Emil Ivov Sent: Thursday, December 10, 2009 2:40 PM To: Spencer Dawkins Cc: dispatch@ietf.org; Simo.Veikkolainen@nokia.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and = XMPP Hey Spencer, =EE=C1 10.12.09 20:26, Spencer Dawkins =CE=C1=D0=C9=D3=C1: > is this the disconnect - that Emil is thinking that either (1) one of > the protocols changes to accept credentials from the other protocol, > or (2) we come up with a mechanism that does single-signon for both > protocols, It doesn't need to be a protocol change or a new single-sinon mechanism. Both of these are possible options but probably a bit too disruptive = given the we-are-not-inventing-a-new-protocol prerequisite that we have = set ourselves. >From a UA perspective it would be enough to simply know (i.e. have it = written somewhere) that clients use the same credentials against both = servers. I am guessing however that simply enforcing this would contradict use = cases that others here may have in mind. This is why I was suggesting = that we should think this through once the new WG is formed. Cheers, Emil _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From emcho@sip-communicator.org Thu Dec 10 11:51:28 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F153A6889 for ; Thu, 10 Dec 2009 11:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IWG2CQUgjKk for ; Thu, 10 Dec 2009 11:51:27 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 617D73A6841 for ; Thu, 10 Dec 2009 11:51:27 -0800 (PST) Received: by ewy6 with SMTP id 6so239356ewy.29 for ; Thu, 10 Dec 2009 11:51:12 -0800 (PST) Received: by 10.213.47.140 with SMTP id n12mr3178442ebf.32.1260474670904; Thu, 10 Dec 2009 11:51:10 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 13sm707872ewy.13.2009.12.10.11.51.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 11:51:10 -0800 (PST) Sender: Emil Ivov Message-ID: <4B21512C.5000709@sip-communicator.org> Date: Thu, 10 Dec 2009 20:51:08 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <4B20B43E.9030200@sip-communicator.org><4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org><1260472418.25475.1915.camel@scott><8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <90243C8A881F8D419D855264D9636F3A02C0FEF9@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C0FEF9@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 19:51:28 -0000 =EE=C1 10.12.09 20:48, Rifaat Shekh-Yusef =CE=C1=D0=C9=D3=C1: > Hi Emil, >=20 > The following is a quote from the draft's abstract: > "It is even possible that SIP and XMPP services are offered by differen= t service providers" >=20 > In this case I do not think that you can use the same credentials for b= oth services. Absolutely, which is why I said we probably wouldn't want to enforce this and give it some further thought once the WG is formed. Cheers, Emil >=20 > Regards, > Rifaat >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On B= ehalf Of Emil Ivov > Sent: Thursday, December 10, 2009 2:40 PM > To: Spencer Dawkins > Cc: dispatch@ietf.org; Simo.Veikkolainen@nokia.com > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and = XMPP >=20 > Hey Spencer, >=20 > =EE=C1 10.12.09 20:26, Spencer Dawkins =CE=C1=D0=C9=D3=C1: >> is this the disconnect - that Emil is thinking that either (1) one of >> the protocols changes to accept credentials from the other protocol, >> or (2) we come up with a mechanism that does single-signon for both >> protocols, >=20 > It doesn't need to be a protocol change or a new single-sinon mechanism= =2E > Both of these are possible options but probably a bit too disruptive gi= ven the we-are-not-inventing-a-new-protocol prerequisite that we have set= ourselves. >=20 >>From a UA perspective it would be enough to simply know (i.e. have it w= ritten somewhere) that clients use the same credentials against both serv= ers. >=20 > I am guessing however that simply enforcing this would contradict use c= ases that others here may have in mind. This is why I was suggesting that= we should think this through once the new WG is formed. >=20 > Cheers, > Emil >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From spencer@wonderhamster.org Thu Dec 10 12:02:32 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515DE3A6958 for ; Thu, 10 Dec 2009 12:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90IPTA0TZ0aM for ; Thu, 10 Dec 2009 12:02:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5AD8F3A68C8 for ; Thu, 10 Dec 2009 12:02:31 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LqjRS-1Nx5eM2YPC-00eQrx; Thu, 10 Dec 2009 15:02:13 -0500 Message-ID: <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> From: "Spencer Dawkins" To: "Emil Ivov" References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> Date: Thu, 10 Dec 2009 14:02:00 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX198xDIAFus0v9jTdesvW2f5tLBYmtWPnp5kIpy JmoU7yld4I/FWG7zOENUNqrphs+QZR3AuQj/Rl4LJFcx9XKJcH NK6LOiwx7J2PpbO7ILEQukE+BbUeLpxDq3WvjNd1GQ= Cc: dispatch@ietf.org, Simo.Veikkolainen@nokia.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:02:32 -0000 Hi, Emil, I think I'm following you - you're saying that the client should be smart enough that I only have to enter spencer@wonderhamster.org once, and the client would be able to use that string as my SIP AOR as well as my Jabber ID, right? Thanks, Spencer ----- Original Message ----- From: "Emil Ivov" To: "Spencer Dawkins" Cc: "Scott Lawrence" ; ; Sent: Thursday, December 10, 2009 1:40 PM Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP Hey Spencer, Ðа 10.12.09 20:26, Spencer Dawkins напиÑа: > is this the disconnect - that Emil is thinking that either (1) one of the > protocols changes to accept credentials from the other protocol, or (2) we > come up with a mechanism that does single-signon for both protocols, It doesn't need to be a protocol change or a new single-sinon mechanism. Both of these are possible options but probably a bit too disruptive given the we-are-not-inventing-a-new-protocol prerequisite that we have set ourselves. >From a UA perspective it would be enough to simply know (i.e. have it written somewhere) that clients use the same credentials against both servers. I am guessing however that simply enforcing this would contradict use cases that others here may have in mind. This is why I was suggesting that we should think this through once the new WG is formed. Cheers, Emil From emcho@sip-communicator.org Thu Dec 10 12:05:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACF53A68E6 for ; Thu, 10 Dec 2009 12:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QScXc00d3YG4 for ; Thu, 10 Dec 2009 12:05:28 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 334E93A6889 for ; Thu, 10 Dec 2009 12:05:28 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so115762eyd.51 for ; Thu, 10 Dec 2009 12:05:13 -0800 (PST) Received: by 10.213.0.151 with SMTP id 23mr3145040ebb.43.1260475513526; Thu, 10 Dec 2009 12:05:13 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 16sm714419ewy.14.2009.12.10.12.05.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 12:05:12 -0800 (PST) Sender: Emil Ivov Message-ID: <4B215477.7000003@sip-communicator.org> Date: Thu, 10 Dec 2009 21:05:11 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Spencer Dawkins References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> In-Reply-To: <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Simo.Veikkolainen@nokia.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:05:29 -0000 =D0=9D=D0=B0 10.12.09 21:02, Spencer Dawkins =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > Hi, Emil, >=20 > I think I'm following you - you're saying that the client should be sma= rt=20 > enough that I only have to enter spencer@wonderhamster.org once, and th= e=20 > client would be able to use that string as my SIP AOR as well as my Jab= ber=20 > ID, right? Right! Cheers, Emil From Markus.Isomaki@nokia.com Thu Dec 10 12:06:47 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D533A6954 for ; Thu, 10 Dec 2009 12:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4oF1rKEv0-i for ; Thu, 10 Dec 2009 12:06:46 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 720213A6889 for ; Thu, 10 Dec 2009 12:06:46 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBAK6TX3018145; Thu, 10 Dec 2009 22:06:32 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 22:06:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 22:06:26 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 10 Dec 2009 21:06:25 +0100 From: To: , Date: Thu, 10 Dec 2009 21:06:23 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp50ifyXn2YMk1sSG2B245tL6JQ3wAADHXA Message-ID: References: <4B20B43E.9030200@sip-communicator.org><4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org><1260472418.25475.1915.camel@scott><8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <90243C8A881F8D419D855264D9636F3A02C0FEF9@zcarhxm2.corp.nortel.com> <4B21512C.5000709@sip-communicator.org> In-Reply-To: <4B21512C.5000709@sip-communicator.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2009 20:06:26.0147 (UTC) FILETIME=[40D8FB30:01CA79D4] X-Nokia-AV: Clean Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:06:47 -0000 Hi,=20 Emil Ivov wrote: > >=EE=C1 10.12.09 20:48, Rifaat Shekh-Yusef =CE=C1=D0=C9=D3=C1: >> Hi Emil, >>=20 >> The following is a quote from the draft's abstract: >> "It is even possible that SIP and XMPP services are offered=20 >by different service providers" >>=20 >> In this case I do not think that you can use the same=20 >credentials for both services. > >Absolutely, which is why I said we probably wouldn't want to=20 >enforce this and give it some further thought once the WG is formed. > I think it is valuable that the SIP and XMPP *can* be offered by different = completely independent providers. That provides most flexibility on the cli= ent side, and we don't really loose much. On the other hand it's a valid ca= se too that SIP and XMPP come from the same provider. Whether that's one or= two services is semantics, but I think it should be possible to offer that= to the user as one service. (The user does not care how many different pro= tocols are used, but they of course do care about the identities they get.)= So I'm symphathetic to Emil's goal to improve client <-> service provider = interoperability and user experience.=20 Markus = From spencer@wonderhamster.org Thu Dec 10 12:06:58 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D973A6889 for ; Thu, 10 Dec 2009 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exb7h7k9qcXW for ; Thu, 10 Dec 2009 12:06:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 318123A6A36 for ; Thu, 10 Dec 2009 12:06:57 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M9Zfb-1NDdxn1c6h-00CqfD; Thu, 10 Dec 2009 15:06:45 -0500 Message-ID: <74A7E95BC4DB466AA58BE345A20F2F1D@china.huawei.com> From: "Spencer Dawkins" To: "Emil Ivov" References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> Date: Thu, 10 Dec 2009 14:06:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+LI8hZ3LGU+N9ZvLS4dQCpwlMg6ZastySj32l Uy1Nntm1+nLM0Tc0PGI/fkXsrxrEqpqe+GRbZXckOWLev4B27m 4GfJcCV2P7c8/mYe5l55hotN65HXirsZWyfK6Rosk0= Cc: dispatch@ietf.org, Simo.Veikkolainen@nokia.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:06:58 -0000 ah - thanks! i was reading more into "credentials" than you meant to say. Spencer ----- Original Message ----- From: "Emil Ivov" To: "Spencer Dawkins" Cc: "Scott Lawrence" ; ; Sent: Thursday, December 10, 2009 2:05 PM Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP Ðа 10.12.09 21:02, Spencer Dawkins напиÑа: > Hi, Emil, > > I think I'm following you - you're saying that the client should be smart > enough that I only have to enter spencer@wonderhamster.org once, and the > client would be able to use that string as my SIP AOR as well as my Jabber > ID, right? Right! Cheers, Emil From stpeter@stpeter.im Thu Dec 10 12:07:07 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7778428C141 for ; Thu, 10 Dec 2009 12:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il35CthVJSRu for ; Thu, 10 Dec 2009 12:07:06 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6040B3A6954 for ; Thu, 10 Dec 2009 12:07:06 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7563F4033C; Thu, 10 Dec 2009 13:06:54 -0700 (MST) Message-ID: <4B2154DD.4090302@stpeter.im> Date: Thu, 10 Dec 2009 13:06:53 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Emil Ivov References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> In-Reply-To: <4B215477.7000003@sip-communicator.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020304060800000005040506" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:07:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020304060800000005040506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/10/09 1:05 PM, Emil Ivov wrote: > =D0=9D=D0=B0 10.12.09 21:02, Spencer Dawkins =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> Hi, Emil, >> >> I think I'm following you - you're saying that the client should be sm= art=20 >> enough that I only have to enter spencer@wonderhamster.org once, and t= he=20 >> client would be able to use that string as my SIP AOR as well as my Ja= bber=20 >> ID, right? >=20 > Right! That's a wonderful thing, but AFAICS it is a provisioning issue. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020304060800000005040506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxMDIwMDY1M1owIwYJKoZIhvcNAQkEMRYEFBH+lZgAC6c3Fp4t4TDG LnCUmmm/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAYM9/UXTtMyiRHTal1TEhCvWX/Iy/YeKK12fbEN+D d6p7Vd5mHLf5lDaBFkSUKVIjm/I4iWWFZvgY+ld2rm0wUTWPA72zEocswPX24Ao82hb5rYfu uPVnu89JxoBku78ea5hLUg69CheV2c2M0hR702IaVTPBtmRjnqu7CR1PRPQndXTBEknMI3QT t6kGXQ6fnKluu7jVa4lVXvBPKYT1ZAcdUCijLWEJjhKrF0hy2s28B6MNzvHW1YiefVb8JCjb 4OOmFJOEvRIwUxZKlMZC8LT2y/4ifcZpr/ErmYzfWvjqdq2nltFWsFYMMGzapwR/sN5QJoyJ vz7PFTZWoFZGFAAAAAAAAA== --------------ms020304060800000005040506-- From RIFATYU@nortel.com Thu Dec 10 12:20:58 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621C03A68E0 for ; Thu, 10 Dec 2009 12:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhJbdCFg2Yqs for ; Thu, 10 Dec 2009 12:20:57 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2B6C23A67A8 for ; Thu, 10 Dec 2009 12:20:57 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBAKKeG01240 for ; Thu, 10 Dec 2009 20:20:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 15:20:14 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02C10021@zcarhxm2.corp.nortel.com> In-Reply-To: <1256581091.3748.9.camel@khone.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New Version Notification fordraft-worley-service-example-04 Thread-Index: AcpWaNMOxWgXqSiASDigFGxD6ZBZ/QjZSQtQ References: <20091026005148.196193A68EF@core3.amsl.com> <1256581091.3748.9.camel@khone.us.nortel.com> From: "Rifaat Shekh-Yusef" To: "Dale Worley" , "DISPATCH" Subject: Re: [dispatch] New Version Notification fordraft-worley-service-example-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:20:58 -0000 Hi Dale, Question about section 2.8, Dialog/Session Timers: You described two approaches to this issue: 1. The executing UA supports timer per dialog 2. The executing UA forwards the refresh requests to refresh both dialogs What is the advantage of the second approach over the first one? The second approach might be a little challenging. For example, think about the scenario where the executing UA has established a dialog with the other party with SE: 3600, but the Min-SE of the Music Source is 7200. You might have a problem if the Music Source is the refresher. Thanks, Rifaat =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale (BL60:9D30) Sent: Monday, October 26, 2009 2:18 PM To: DISPATCH Subject: Re: [dispatch] New Version Notification fordraft-worley-service-example-04 I've submitted a new revision of a service example for music on hold. Since the design is getting debugged and we've seen implementations in real products, I would like to propose that this draft be sent to Bliss in order to be approved as an addition to the service examples RFC (5359), as the method described in the draft has some advantages relative to the method in section 2.3 of RFC 5359. Dale On Sun, 2009-10-25 at 17:51 -0700, IETF I-D Submission Tool wrote: > A new version of I-D, draft-worley-service-example-04.txt has been=20 > successfuly submitted by Dale Worley and posted to the IETF=20 > repository. >=20 > Filename: draft-worley-service-example > Revision: 04 > Title: Session Initiation Protocol Service Example -- Music on Hold > Creation_date: 2009-10-25 > WG ID: Independent Submission > Number_of_pages: 32 >=20 > Abstract: > The "music on hold" feature is one of the most desired features of=20 > telephone systems in the business environment. "Music on hold" is=20 > where, when one party to a call has the call "on hold", that party's=20 > telephone provides an audio stream (often music) to be heard by the=20 > other party. Architectural features of SIP make it difficult to=20 > implement music-on-hold in a way that is fully compliant with the=20 > standards. The implementation of music-on-hold described in this=20 > document is fully effective and standards-compliant, but has a number=20 > of advantages over the methods previously documented. In particular,=20 > it is less likely to produce peculiar user interface effects and more=20 > likely to work in systems which perform authentication than the method > of RFC 5359. http://tools.ietf.org/html/draft-worley-service-example-04 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From RIFATYU@nortel.com Thu Dec 10 12:27:49 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06333A6884 for ; Thu, 10 Dec 2009 12:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.129 X-Spam-Level: X-Spam-Status: No, score=-5.129 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBy3ebSmc5zF for ; Thu, 10 Dec 2009 12:27:49 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C4A423A6A3F for ; Thu, 10 Dec 2009 12:27:48 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBAKRVj03821; Thu, 10 Dec 2009 20:27:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 15:26:48 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02C1006C@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp50ifyXn2YMk1sSG2B245tL6JQ3wAADHXAAAEKnqA= References: <4B20B43E.9030200@sip-communicator.org><4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org><1260472418.25475.1915.camel@scott><8647CF2D344C40F19ABD162093605F46@china.huawei.com><4B214EA7.1090405@sip-communicator.org><90243C8A881F8D419D855264D9636F3A02C0FEF9@zcarhxm2.corp.nortel.com> <4B21512C.5000709@sip-communicator.org> From: "Rifaat Shekh-Yusef" To: , Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:27:49 -0000 > So I'm symphathetic to Emil's goal to improve client <-> service = provider interoperability and user experience. Well, I think we all sympathetic to this goal, but this has nothing to = do with this draft. I think that it is up to the client to address this = issue. Regards, Rifaat -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: Thursday, December 10, 2009 3:06 PM To: emcho@sip-communicator.org; Shekh-Yusef, Rifaat (BVW:9T16) Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org Subject: RE: [dispatch] Revised proposed charter for Combining SIP and = XMPP Hi,=20 Emil Ivov wrote: > >=EE=C1 10.12.09 20:48, Rifaat Shekh-Yusef =CE=C1=D0=C9=D3=C1: >> Hi Emil, >>=20 >> The following is a quote from the draft's abstract: >> "It is even possible that SIP and XMPP services are offered >by different service providers" >>=20 >> In this case I do not think that you can use the same >credentials for both services. > >Absolutely, which is why I said we probably wouldn't want to enforce=20 >this and give it some further thought once the WG is formed. > I think it is valuable that the SIP and XMPP *can* be offered by = different completely independent providers. That provides most = flexibility on the client side, and we don't really loose much. On the = other hand it's a valid case too that SIP and XMPP come from the same = provider. Whether that's one or two services is semantics, but I think = it should be possible to offer that to the user as one service. (The = user does not care how many different protocols are used, but they of = course do care about the identities they get.) So I'm symphathetic to = Emil's goal to improve client <-> service provider interoperability and = user experience.=20 Markus=20 From Even.roni@huawei.com Thu Dec 10 13:12:02 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE823A6A58 for ; Thu, 10 Dec 2009 13:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fmtrlNPFDyC for ; Thu, 10 Dec 2009 13:12:01 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 474E23A63D3 for ; Thu, 10 Dec 2009 13:12:01 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG008T4G7FDZ@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 11 Dec 2009 05:11:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG001QRG7F5S@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 11 Dec 2009 05:11:39 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-46-225.red.bezeqint.net [79.176.46.225]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUG00A98G70OZ@szxml02-in.huawei.com>; Fri, 11 Dec 2009 05:11:39 +0800 (CST) Date: Thu, 10 Dec 2009 23:08:27 +0200 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Message-id: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUwBCwx0w References: Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 21:12:02 -0000 Hi, I think that it must be stated very clearly that the assumption is that both XMPP client and SIP client reside on the same endpoint. I also think that the issue of support for multipoint (chat and audio/video) should be specified, is it in scope or not. Thanks Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Wednesday, December 09, 2009 3:11 PM > To: dispatch@ietf.org > Subject: [dispatch] Revised proposed charter for Combining SIP and XMPP > > Hello, > Below is the proposed charter text for Combining SIP and XMPP revised > according to the discussions in Hiroshima. Basically the changes are > > - include video in addition to voice > - mention that existing SIP and XMPP endpoints are not affected > - update milestones. > > Comments are very welcome. > > Regards, > Simo > > > -----8<------8<------8<------ > > Combining SIP VoIP and XMPP IM/Presence > ======================================= > > Currently most standards-based Voice over IP (VoIP) deployments use the > Session Initiation Protocol (SIP). In addition to providing basic > voice service SIP has an extensive support for more advanced telephony > features including interworking with the traditional Public Switched > Telephone Network (PSTN). SIP is also gaining popularity in the field > of video communication. At the same time, the Extensible Messaging and > Presence Protocol (XMPP) is enjoying widespread usage in instant > messaging and presence services. > > Both SIP and XMPP offer extensions for integrating voice and video with > IM and presence (XMPP voice via the Jingle extension, and SIP > IM/presence via SIMPLE protocols). However, widespread deployment of > these extensions has not so far taken place. In order to speed up > deployment of integrated VoIP and IM systems, SIP based voice and XMPP > based IM/Presence could be combined in endpoints to offer a voice, IM > and presence service without any changes to existing SIP and XMPP > service infrastructure. > > The objective of this Working Group is to develop solutions for > combining SIP based voice with XMPP based IM and Presence such that a > unified user experience can be offered to end user. Specifically, > solutions are needed on > - addressing; end users should be able to initiate sessions to a user > identity in either SIP or XMPP domain. The corresponding user identity > in the other protocol domain needs to be learned automatically. > - session correlation; endpoints need to be able to correlate SIP voice > and video sessions with XMPP IM/Presence in such a manner that they can > be presented to the end user in a seamless fashion > - presence; it should be possible to change the XMPP presence status > based on the user's activity in the SIP domain. > > Existing SIP and XMPP endpoints are not affected and can interoperate > with the implementations that comply with the extensions defined by > this Working Group (but obviously without the additional functionality > provided by these extensions). > > The goal is to rely on existing service infrastructure, and new > requirements should be imposed only on the endpoints. > > Protocol interworking, that is, translation from one protocol to > another, is out of scope of this WG. > > Milestones > Jun 2010 Problem statement and use cases submitted to IESG as > Informational. > Jun 2011 Specification on combining SIP based voice and video and XMPP > based IM/Presence in a seamless manner submitted to IESG as Proposed > Standard. > > -----8<------8<------8<------ > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From martin.4.palmer@bt.com Thu Dec 10 13:27:18 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9D33A6A35 for ; Thu, 10 Dec 2009 13:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVE6LpmPQepg for ; Thu, 10 Dec 2009 13:27:17 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 036693A693F for ; Thu, 10 Dec 2009 13:27:16 -0800 (PST) Received: from E03MVZ3-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 21:27:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 21:23:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: Acp4RpN/JmWZLWQDT+aFrw70Bv7UigAm9CCQACUlq2AAGf4k0A== References: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E306847E33BA@MCHP058A.global-ad.net> From: To: , , X-OriginalArrivalTime: 10 Dec 2009 21:27:04.0475 (UTC) FILETIME=[84B73EB0:01CA79DF] Cc: Leon.Portman@nice.com, dispatch@ietf.org, HKaplan@acmepacket.com Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 21:27:18 -0000 Have you also considered the scenario of persistent calls (nailed up = PWs) in which the calls are constantly recorded. Currently in our world = we mix a number of speakers - terminated on the same endpoint device - = into a single recording channel to cut down the required bandwidth. -----Original Message----- From: dispatch-bounces@ietf.org on behalf of Hutton, Andrew Sent: Thu 12/10/2009 9:01 AM To: Jain, Rajnish; Peter Musgrave Cc: Leon.Portman@nice.com; dispatch@ietf.org; HKaplan@acmepacket.com Subject: Re: [dispatch] Comments on = draft-rehor-dispatch-session-recording-req-00 =20 Yes I agree this should be clarified and it should be clear that both = modes are allowed (i.e. tx/rx mixed or seperated). Regards Andy =20 -----Original Message----- From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com]=20 Sent: 09 December 2009 15:20 To: Peter Musgrave; Hutton, Andrew Cc: dispatch@ietf.org; Leon.Portman@nice.com; HKaplan@acmepacket.com Subject: RE: [dispatch] Comments on = draft-rehor-dispatch-session-recording-req-00 Also: Is it worth stating as a requirement that the streams in each direction = be sent separately to the recording device (or is this implied?). Some = recording devices check for times when both parties are talking - since = in a call center scenario such recordings may be discussions worth = listening to... Peter Musgrave This is implied in REQ-010. I think we can add a clarifying note that = indicates that the recording media streams may carry the Rx and Tx of = recorded media stream separately. o REQ-010 The mechanism MUST support the ability to deliver multiple media streams for a given Recorded Session over separate Recording Sessions to the RS. Thanks, Raj Jain On 2009-12-08, at 11:19 AM, Hutton, Andrew wrote: Some comments on the session recording requirements draft = draft-rehor-dispatch-session-recording-req-00 1. The introduction states that the "recording sessions can be of any = kind such as voice, video and instant messaging". I think it would be = sensible to restrict the scope to RTP based media (I.e. voice and video) = and possibly move out the instant messaging recording as a separate work = item if needed. Regards Andy Andrew Hutton Office of the CTO. Siemens Enterprise Communications. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, = privileged or otherwise protected from disclosure. If you are not an = intended recipient of this e-mail, do not duplicate or redistribute it = by any means. Please delete it and any attachments and notify the sender = that you have received it in error. Unintended recipients are prohibited = from taking action on the basis of information in this e-mail.E-mail = messages may contain computer viruses or other defects, may not be = accurately replicated on other systems, or may be intercepted, deleted = or interfered with without the knowledge of the sender or the intended = recipient. If you are not comfortable with the risks associated with = e-mail messages, you may decide not to use e-mail to communicate with = IPC. IPC reserves the right, to the extent and under circumstances = permitted by applicable law, to retain, monitor and intercept e-mail = messages to and from its systems. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From rajnish.jain@ipc.com Thu Dec 10 15:13:40 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7131D3A6870 for ; Thu, 10 Dec 2009 15:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZjdBJXixxA2 for ; Thu, 10 Dec 2009 15:13:38 -0800 (PST) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 83D993A67AA for ; Thu, 10 Dec 2009 15:13:38 -0800 (PST) Received: from unknown [65.244.37.51] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net(mxl_mta-6.4.0-2) with ESMTP id 790812b4.a84c2b90.58063.00-402.125158.p01c12o144.mxlogic.net (envelope-from ); Thu, 10 Dec 2009 16:13:27 -0700 (MST) X-MXL-Hash: 4b21809740f0f73f-1a68f0530d6369c1f1bc1b00cc05b224851c0abd Received: from unknown [65.244.37.51] (EHLO smtp.ipc.com) by p01c12o144.mxlogic.net(mxl_mta-6.4.0-2) over TLS secured channel with ESMTP id a70812b4.0.57977.00-008.124928.p01c12o144.mxlogic.net (envelope-from ); Thu, 10 Dec 2009 16:13:06 -0700 (MST) X-MXL-Hash: 4b2180826a3b0cba-27d7321c69e4db1753637d85c1fe5aae3d71f230 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.1.228]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Thu, 10 Dec 2009 18:12:58 -0500 From: "Jain, Rajnish" To: "martin.4.palmer@bt.com" , "andrew.hutton@siemens-enterprise.com" , "peter.musgrave@magorcorp.com" Date: Thu, 10 Dec 2009 18:12:53 -0500 Thread-Topic: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: Acp4RpN/JmWZLWQDT+aFrw70Bv7UigAm9CCQACUlq2AAGf4k0AADsiTQ Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E306847E29DE@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E306847E33BA@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.000.1038-17060.004 x-tm-as-result: No--46.282600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009113001)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=z+2a4RCZxltofrpCDsS06w==:17 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=DKqOm-NVAAAA:8 a=C7nHA56JAAAA:8 a=vvKfUcgjAAAA:8 a=lzMD05] X-AnalysisOut: [bia_LL_3AwDqEA:9 a=DwOSF-xBxF4kce6IxRMA:7 a=f3KJnQg7P4O2xh] X-AnalysisOut: [gGnlrDhOuiQkEA:4 a=lZB815dzVvQA:10 a=G0ULH6RxXl8A:10 a=Hwv] X-AnalysisOut: [HyInW8OUA:10 a=OeN1TrMypwAA:10 a=cbdPks__skC1ePP4:21 a=n5p] X-AnalysisOut: [MXllBYmvSaP-7:21] Cc: "Leon.Portman@nice.com" , "dispatch@ietf.org" , "HKaplan@acmepacket.com" Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 23:13:40 -0000 > Have you also considered the scenario of persistent calls (nailed up PWs)= in > which the calls are constantly recorded. Currently in our world we mix a > number of speakers - terminated on the same endpoint device - into a sing= le > recording channel to cut down the required bandwidth. Yes. This is captured in requirements REQ-03 and REQ-09. o REQ-003 The mechanism MUST support persistent Recording Sessions, such that the connection and attributes of media in the Recording Session are not dynamically signaled for each Recorded Session before it can be recorded. Call details and metadata will still be signaled, but can be post- correlated to the recorded media. There will still need to be a means of correlating the recorded media connection/packets to the Recorded Session, however this may be on a permanent filter-type basis, such as based on a SIP AoR of an agent that is always recorded, or based on identifiers in the recorded media itself. o REQ-009 The mechanism MUST support the ability to deliver mixed media streams to the RS. The RS MAY be informed about the composition of the mixed streams through session metadata. Note: A mixed media stream is where several recorded sessions are carried in a single recording session. A mixed media stream is typically produced by a mixer function. > > -----Original Message----- > From: dispatch-bounces@ietf.org on behalf of Hutton, Andrew > Sent: Thu 12/10/2009 9:01 AM > To: Jain, Rajnish; Peter Musgrave > Cc: Leon.Portman@nice.com; dispatch@ietf.org; HKaplan@acmepacket.com > Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recordin= g- > req-00 > > > Yes I agree this should be clarified and it should be clear that both mod= es > are allowed (i.e. tx/rx mixed or seperated). > > Regards > Andy > > > -----Original Message----- > From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] > Sent: 09 December 2009 15:20 > To: Peter Musgrave; Hutton, Andrew > Cc: dispatch@ietf.org; Leon.Portman@nice.com; HKaplan@acmepacket.com > Subject: RE: [dispatch] Comments on draft-rehor-dispatch-session-recordin= g- > req-00 > > > Also: > Is it worth stating as a requirement that the streams in each direction b= e > sent separately to the recording device (or is this implied?). Some > recording devices check for times when both parties are talking - since i= n a > call center scenario such recordings may be discussions worth listening > to... > > Peter Musgrave > > > This is implied in REQ-010. I think we can add a clarifying note that > indicates that the recording media streams may carry the Rx and Tx of > recorded media stream separately. > > o REQ-010 The mechanism MUST support the ability to deliver multiple > media streams for a given Recorded Session over separate Recording > Sessions to the RS. > > Thanks, > Raj Jain > > > On 2009-12-08, at 11:19 AM, Hutton, Andrew wrote: > > > Some comments on the session recording requirements draft draft-rehor- > dispatch-session-recording-req-00 > > 1. The introduction states that the "recording sessions can be of any kin= d > such as voice, video and instant messaging". I think it would be sensible= to > restrict the scope to RTP based media (I.e. voice and video) and possibly > move out the instant messaging recording as a separate work item if neede= d. > > > Regards > Andy > > Andrew Hutton > Office of the CTO. > Siemens Enterprise Communications. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it by > any means. Please delete it and any attachments and notify the sender tha= t > you have received it in error. Unintended recipients are prohibited from > taking action on the basis of information in this e-mail.E-mail messages = may > contain computer viruses or other defects, may not be accurately replicat= ed > on other systems, or may be intercepted, deleted or interfered with witho= ut > the knowledge of the sender or the intended recipient. If you are not > comfortable with the risks associated with e-mail messages, you may decid= e > not to use e-mail to communicate with IPC. IPC reserves the right, to the > extent and under circumstances permitted by applicable law, to retain, > monitor and intercept e-mail messages to and from its systems. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From fluffy@cisco.com Thu Dec 10 20:10:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03273A68E8 for ; Thu, 10 Dec 2009 20:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCR5g2pUW3SQ for ; Thu, 10 Dec 2009 20:10:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A23953A68AC for ; Thu, 10 Dec 2009 20:10:35 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,379,1257120000"; d="scan'208";a="117857665" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2009 04:10:24 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBB4ANc3028760; Fri, 11 Dec 2009 04:10:23 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4AD7515F.9090704@cisco.com> Date: Thu, 10 Dec 2009 21:10:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85FDEC10-0419-44BA-ADD3-4328328EF206@cisco.com> References: <4AD7515F.9090704@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1077) Cc: dispatch@ietf.org, Avshalom Houri Subject: Re: [dispatch] [Sip] Securing messages with TEL URI over SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 04:10:36 -0000 On Oct 15, 2009, at 10:44 AM, Paul Kyzivat wrote: >=20 >=20 > Avshalom Houri wrote: >> I have found discussion thread on how to secure e.g. TEL URI over SIP = from 2007. >> transport=3Dtls is deprecated and it does not mean end to end anyway. >> We still do not have "tels" URI. >> Was this discussion concluded and if how it was concluded? >=20 > AFAIK there was never any resolution of this - nobody knows how to do = it. >=20 > I think the most fundamental problem is that there is no good answer = to who is permitted and able to authenticate the use of a particular TEL = URI. The vipr drafts in dispatch do take an attempt at one possible solution = to this problem. (moving thread to dispatch) From attila.sipos@vegastream.com Fri Dec 11 00:27:09 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4E13A6920 for ; Fri, 11 Dec 2009 00:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEPnGk+X5se2 for ; Fri, 11 Dec 2009 00:27:08 -0800 (PST) Received: from cluster-a.mailcontrol.com (cluster-a.mailcontrol.com [85.115.52.190]) by core3.amsl.com (Postfix) with ESMTP id 440163A659C for ; Fri, 11 Dec 2009 00:27:07 -0800 (PST) Received: from rly03a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly03a.srv.mailcontrol.com (MailControl) with ESMTP id nBB8QoW1007041 for ; Fri, 11 Dec 2009 08:26:54 GMT Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly03a.srv.mailcontrol.com (MailControl) id nBB8Qe6J005376 for ; Fri, 11 Dec 2009 08:26:40 GMT Received: from exsmtp04.nasstar-t1.net (exsmtp04.nasstar-t1.net [89.28.233.151]) by rly03a-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id nBB8Ptak032040; Fri, 11 Dec 2009 08:26:40 +0000 (GMT) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp04.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 08:27:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Dec 2009 08:26:28 -0000 Message-ID: <680808427CF931459462C3D78CB5EC6008347EBF@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] locating spawns of DISPATCH Thread-Index: Acp40BCNtPXWigy6Q1y/9cBnnuaetgAE/aTwAFVl8PA= From: "Attila Sipos" To: "Mary Barnes" , "Brett Tate" , X-OriginalArrivalTime: 11 Dec 2009 08:27:55.0392 (UTC) FILETIME=[D6810800:01CA7A3B] X-Scanned-By: MailControl A-09-22-10 (www.mailcontrol.com) on 10.65.1.113 Subject: Re: [dispatch] locating spawns of DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 08:27:09 -0000 would be ok to also list the working groups that would have been spawns of dispatch had dispatch been around? In other words, also list the working groups created before the existence of dispatch? Regards Attila -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 09 December 2009 15:33 To: Brett Tate; dispatch@ietf.org Subject: Re: [dispatch] locating spawns of DISPATCH Hi Brett, That's a good point. I had been summarizing such in the status emails, but can see the value in keeping this in a single place. I'll add a page to the supplementary webpage on softarmor and send a note to the list when that's done. Thanks, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Brett Tate Sent: Wednesday, December 09, 2009 7:04 AM To: dispatch@ietf.org Subject: [dispatch] locating spawns of DISPATCH Greetings, Are the working group spawns of DISPATCH collected somewhere to easily notice them (without searching email archive)? For instance, will they be linked somehow to DISPATCH charter, status, or a supplemental DISPATCH webpage? Thanks, Brett _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Fri Dec 11 00:27:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C894528C0EA for ; Fri, 11 Dec 2009 00:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1Mr6uhQJF-N for ; Fri, 11 Dec 2009 00:27:34 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4A34E3A659C for ; Fri, 11 Dec 2009 00:27:31 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-260827; Fri, 11 Dec 2009 09:27:19 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C3EA71EB81F1; Fri, 11 Dec 2009 09:27:19 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 11 Dec 2009 09:27:19 +0100 From: "Elwell, John" To: "Adi Shachar(Even-Tzur)" , "dispatch@ietf.org" Date: Fri, 11 Dec 2009 09:27:18 +0100 Thread-Topic: [dispatch] draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a dual stack UA? Thread-Index: Acp5YGxfBMRwRDSARvaKt8gAZhG9wgA2uSww Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CA50E53193MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [dispatch] draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a dual stack UA? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 08:27:38 -0000 --_000_A444A0F8084434499206E78C106220CA50E53193MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would suggest you post this question to the MMUSIC list, but the quick an= swer is ICE/ICE-lite (previously ANAT, RFC 4091, which is being obsoleted b= y ICE). John ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Adi Shachar(Even-Tzur) Sent: 10 December 2009 06:17 To: dispatch@ietf.org Subject: [dispatch] draft-ietf-sipping-v6-transition-07 - what should be th= e Offer out of a dual stack UA? Hi All, As I understand this draft will become an RFC. I would like to better understand the recommendation of the draft for the m= ixed ipv4/ipv6 UA behavior. My main concern is regarding the Offer out such a UA should create. The idea mentioned in the draft is to enable communication both in ipv4 or= ipv6, but the question is how exactly it should be done. There are few options for the OFFER out (assuming we have audio & video): 1. Include total of 2 'm' lines: one 'm' line for audio and one 'm' l= ine for video (with 2 'c' lines each, one in ipv4 and one in ipv6). 2. Include total of 4 'm' lines: one 'm' line for audio with 'c' lin= e with ipv4, one 'm' line for audio with 'c ' line with ipv6, one 'm' line= for video with 'c' line with ipv4 and one 'm' line for video with 'c ' lin= e with ipv6 (RFC 4091). 3. The draft refer that the problem should be solved using STUN relay= . As far as I know, the STUN server returns MY public address and not the d= estination address, so how does the UA know from STUN response what does th= e destination address support, ipv4 or ipv6? Should the Offering UA, based = on STUN relay, know whether to include only ipv4 or ipv6 in the 'm' lines? 4. Any other option? thanks, Adi. --_000_A444A0F8084434499206E78C106220CA50E53193MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would suggest you post this question to the MMUS= IC list,=20 but the quick answer is ICE/ICE-lite (previously ANAT, RFC 4091, which is b= eing=20 obsoleted by ICE).
 
John

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Adi=20 Shachar(Even-Tzur)
Sent: 10 December 2009 06:17
To:=20 dispatch@ietf.org
Subject: [dispatch]=20 draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a d= ual=20 stack UA?

Hi All,

 

As I understand this draft will become an=20 RFC.

 

I woul= d like=20 to better understand the recommendation of the draft for the mixed ipv4/i= pv6=20 UA behavior.

My main concern is regarding the Offer out such a UA= should=20 create.

The idea mentioned in the draft  is to enable=20 communication both in ipv4 or ipv6, but the question is how exactly it sh= ould=20 be done.

 

There are few options for  the OFFER out (assum= ing we=20 have audio & video):

1.      = ;=20 Include total of 2 ‘= m’ lines: one=20 ‘m’ line for audio and one ‘m’ line for video (wi= th 2 ‘c’ lines each, one in=20 ipv4 and one in ipv6).

2.      = ;=20 Include  total of 4 &= #8216;m’=20 lines: one ‘m’ line for audio with ‘c’ line with = ipv4,  one ‘m’ line for=20 audio with ‘c ‘ line with ipv6, one ‘m’ line for = video with ‘c’ line with ipv4=20 and one ‘m’ line for video with ‘c ‘ line with ip= v6 (RFC 4091).

3.      = ;=20 The draft refer that the p= roblem=20 should be solved using STUN relay. As far as I know, the STUN server retu= rns=20 MY public address and not the destination address, so how does the UA kno= w=20 from STUN response what does the destination address support, ipv4 or ipv= 6?=20 Should the Offering UA, based on STUN relay, know whether to include only= ipv4=20 or ipv6 in the ‘m’ lines?

4.      = ;=20 Any other option?

 

 

thanks,

Adi.

 

--_000_A444A0F8084434499206E78C106220CA50E53193MCHP058Aglobala_-- From enrico.marocco@telecomitalia.it Fri Dec 11 00:34:25 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9510128B56A for ; Fri, 11 Dec 2009 00:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45WCum44ee5y for ; Fri, 11 Dec 2009 00:34:24 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 591FF3A659C for ; Fri, 11 Dec 2009 00:34:24 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Dec 2009 09:34:10 +0100 Received: from [163.162.173.7] (163.162.173.7) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Dec 2009 09:34:09 +0100 Message-ID: <4B220430.5090600@telecomitalia.it> Date: Fri, 11 Dec 2009 09:34:56 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Peter Saint-Andre References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B2154DD.4090302@stpeter.im> In-Reply-To: <4B2154DD.4090302@stpeter.im> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030905010403050401000005" Cc: "Simo.Veikkolainen@nokia.com" , "dispatch@ietf.org" Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 08:34:25 -0000 --------------ms030905010403050401000005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Peter Saint-Andre wrote: >>> I think I'm following you - you're saying that the client should be smart >>> enough that I only have to enter spencer@wonderhamster.org once, and the >>> client would be able to use that string as my SIP AOR as well as my Jabber >>> ID, right? >> Right! > > That's a wonderful thing, but AFAICS it is a provisioning issue. That is a provisioning decision indeed, but a means in the protocol for indicating when a set of credentials can be used across different services seems quite desirable. And I guess, at least in the case of digest authentication, also easily achievable with proper usage of RFC 2617, as Scott pointed out. All is needed, as far as I understand it, is just some descriptive text put visibly in some key document the WG will produce. If that is out-of-scope for the WG-to-be, or if it doesn't address the use case being discussed, please help me understand what I am missing. -- Ciao, Enrico --------------ms030905010403050401000005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMjEx MDgzNDU2WjAjBgkqhkiG9w0BCQQxFgQULtgQHECdv3ALwhbNPw2FvPRj5v8wXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAECW0oqsPRlkfDS10Epe aNdXxl+EPOgJPHkxE4WkF/nuSDhYidUqk1nk9I7xqHBIhzvn3/ZMYylx7yWrVnO2u3O5Q7hn sJWHL4CvprXcnoWfeSlt8CpoNG4z28Pl8wEine4GhkASxc2sRILS9e2Z15xJZIPlKl+p3cyu vgdPssmZ4OVW47XkT3vSh7YCCDPNM7H+xxh42G0K+WOpR+lkpb4vLK3tQOzbHTDFVxh11oGr yEKzGfT5Xg0hmyXEX93acvYhPakguiReVlxFmVfBLfeaLP23LY5I4XFWirPF/JIt5Yol7ziZ OTlw4DHBx5f5zU7edaLerrw0aCk/qqPib6EAAAAAAAA= --------------ms030905010403050401000005-- From john.elwell@siemens-enterprise.com Fri Dec 11 00:42:51 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE0A3A67D1 for ; Fri, 11 Dec 2009 00:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylkddzSx+8Xr for ; Fri, 11 Dec 2009 00:42:50 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4615C3A6783 for ; Fri, 11 Dec 2009 00:42:49 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-260659 for dispatch@ietf.org; Fri, 11 Dec 2009 09:42:37 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id BFE031EB81F1 for ; Fri, 11 Dec 2009 09:42:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 11 Dec 2009 09:42:37 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Fri, 11 Dec 2009 09:42:37 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp50ifyXn2YMk1sSG2B245tL6JQ3wAADHXAAAEKnqAAGbKeEA== Message-ID: References: <4B20B43E.9030200@sip-communicator.org><4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org><1260472418.25475.1915.camel@scott><8647CF2D344C40F19ABD162093605F46@china.huawei.com><4B214EA7.1090405@sip-communicator.org><90243C8A881F8D419D855264D9636F3A02C0FEF9@zcarhxm2.corp.nortel.com> <4B21512C.5000709@sip-communicator.org> <90243C8A881F8D419D855264D9636F3A02C1006C@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C1006C@zcarhxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 08:42:51 -0000 I agree with Rifaat. The client's provisioning interface can include a shor= t cut that allows a user to use the same credentials for XMPP as are used f= or SIP (or vice versa). We don't need to standardize that and we certainly = need to cater for the more general case of there being two service provider= s. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef > Sent: 10 December 2009 20:27 > To: Markus.Isomaki@nokia.com; emcho@sip-communicator.org > Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for=20 > Combining SIP and XMPP >=20 > > So I'm symphathetic to Emil's goal to improve client <->=20 > service provider interoperability and user experience. >=20 > Well, I think we all sympathetic to this goal, but this has=20 > nothing to do with this draft. I think that it is up to the=20 > client to address this issue. >=20 > Regards, > Rifaat >=20 > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > Sent: Thursday, December 10, 2009 3:06 PM > To: emcho@sip-communicator.org; Shekh-Yusef, Rifaat (BVW:9T16) > Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org > Subject: RE: [dispatch] Revised proposed charter for=20 > Combining SIP and XMPP >=20 > Hi,=20 >=20 > Emil Ivov wrote: > > > >=EE=C1 10.12.09 20:48, Rifaat Shekh-Yusef =CE=C1=D0=C9=D3=C1: > >> Hi Emil, > >>=20 > >> The following is a quote from the draft's abstract: > >> "It is even possible that SIP and XMPP services are offered > >by different service providers" > >>=20 > >> In this case I do not think that you can use the same > >credentials for both services. > > > >Absolutely, which is why I said we probably wouldn't want to enforce=20 > >this and give it some further thought once the WG is formed. > > >=20 > I think it is valuable that the SIP and XMPP *can* be offered=20 > by different completely independent providers. That provides=20 > most flexibility on the client side, and we don't really=20 > loose much. On the other hand it's a valid case too that SIP=20 > and XMPP come from the same provider. Whether that's one or=20 > two services is semantics, but I think it should be possible=20 > to offer that to the user as one service. (The user does not=20 > care how many different protocols are used, but they of=20 > course do care about the identities they get.) So I'm=20 > symphathetic to Emil's goal to improve client <-> service=20 > provider interoperability and user experience.=20 >=20 > Markus=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From john.elwell@siemens-enterprise.com Fri Dec 11 00:44:57 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DBF3A6953 for ; Fri, 11 Dec 2009 00:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnB0pvNSXBgz for ; Fri, 11 Dec 2009 00:44:57 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C307A3A6783 for ; Fri, 11 Dec 2009 00:44:56 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-260643 for dispatch@ietf.org; Fri, 11 Dec 2009 09:44:44 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C1CC91EB81F1 for ; Fri, 11 Dec 2009 09:44:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 11 Dec 2009 09:44:44 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Fri, 11 Dec 2009 09:44:43 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp6PLub3zwpnxh4TXyfOgc3j7nrsQAATxqg Message-ID: References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B2154DD.4090302@stpeter.im> <4B220430.5090600@telecomitalia.it> In-Reply-To: <4B220430.5090600@telecomitalia.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 08:44:57 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco > Sent: 11 December 2009 08:35 > To: Peter Saint-Andre > Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for=20 > Combining SIP and XMPP >=20 > Peter Saint-Andre wrote: > >>> I think I'm following you - you're saying that the client=20 > should be smart=20 > >>> enough that I only have to enter=20 > spencer@wonderhamster.org once, and the=20 > >>> client would be able to use that string as my SIP AOR as=20 > well as my Jabber=20 > >>> ID, right? > >> Right! > >=20 > > That's a wonderful thing, but AFAICS it is a provisioning issue. >=20 > That is a provisioning decision indeed, but a means in the=20 > protocol for > indicating when a set of credentials can be used across different > services seems quite desirable. And I guess, at least in the case of > digest authentication, also easily achievable with proper usage of RFC > 2617, as Scott pointed out. All is needed, as far as I=20 > understand it, is > just some descriptive text put visibly in some key document=20 > the WG will > produce. [JRE] I don't object to that, but this doesn't need to be in the charter. John From Sebastian.Schumann@t-com.sk Fri Dec 11 01:29:09 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F433A6A79 for ; Fri, 11 Dec 2009 01:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1Qh-7EAfnvC for ; Fri, 11 Dec 2009 01:29:08 -0800 (PST) Received: from mail1.st.sk (mail1.st.sk [195.146.138.74]) by core3.amsl.com (Postfix) with ESMTP id 43D943A69D9 for ; Fri, 11 Dec 2009 01:29:07 -0800 (PST) X-TM-IMSS-Message-ID: <7e13e584000100ec@st.sk> Received: from EXCHANGE2.st.sk ([fe80::49e2:e6ce:946c:aa22]) by EXCHANGEKE1.st.sk ([fe80::c173:5b2:d585:d82a%10]) with mapi; Fri, 11 Dec 2009 10:28:49 +0100 From: Schumann Sebastian To: 'Roni Even' , "'Simo.Veikkolainen@nokia.com'" , "'dispatch@ietf.org'" Date: Fri, 11 Dec 2009 10:28:48 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUwBCwx0wABhsqsA= Message-ID: References: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> In-Reply-To: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> Accept-Language: en-US, sk-SK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sk-SK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 09:29:09 -0000 Hi A would second the case that Roni was raising. It might appear that users will have SIP hardware endpoints, but the provid= er might want to offer all "non-voice/call related" communication (messagin= g, presence etc) over XMPP. I see it feasible to have the SIP presence state of a certain endpoint infl= uence the XMPP state of another endpoint. E.g., on-the-phone from a hardwar= e endpoint to have the XMPP user appearing as DND etc. Sebastian > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even > Sent: Thursday, 10. December 2009 22:08 > To: Simo.Veikkolainen@nokia.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for=20 > Combining SIP and XMPP >=20 > Hi, > I think that it must be stated very clearly that the=20 > assumption is that both > XMPP client and SIP client reside on the same endpoint. > I also think that the issue of support for multipoint (chat=20 > and audio/video) > should be specified, is it in scope or not. > Thanks > Roni Even= From scott.lawrence@nortel.com Sun Dec 13 04:42:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E6B3A67B7 for ; Sun, 13 Dec 2009 04:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCeALPpUqATa for ; Sun, 13 Dec 2009 04:42:52 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 921EF3A67A2 for ; Sun, 13 Dec 2009 04:42:52 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBDCgV805615; Sun, 13 Dec 2009 12:42:31 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 07:41:34 -0500 From: "Scott Lawrence" To: Shida Schubert In-Reply-To: <3623C7AE-6491-4D5A-8150-FC2A3E420A91@ntt-at.com> References: <20091026005148.196193A68EF@core3.amsl.com> <1256581091.3748.9.camel@khone.us.nortel.com> <3623C7AE-6491-4D5A-8150-FC2A3E420A91@ntt-at.com> Content-Type: text/plain Organization: Nortel Networks Date: Sun, 13 Dec 2009 07:41:33 -0500 Message-Id: <1260708093.30342.131.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2009 12:41:34.0237 (UTC) FILETIME=[9A77FCD0:01CA7BF1] Cc: DISPATCH Subject: Re: [dispatch] New Version Notification for draft-worley-service-example-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 12:42:53 -0000 On Tue, 2009-10-27 at 20:00 +0900, Shida Schubert wrote: > Dale, > > Is your intent to update RFC5359 to have this > replace the current section 2.3 or do you see this draft > as a standalone informational draft describing a better > way of doing Music on Hold? The draft doesn't go into much detail on the specifics of the advantages over the method described in 5359 (and other methods in use); it could probably use some expansion in that area because the advantages are real. This feature (providing a third party audio stream during 'hold') is, as the draft says, an important requirement in many deployments, and one whose present record for interoperability is not very good. I am strongly supportive of having this work sent to BLISS to be progressed as an Update to 5359. One nit on the terminology in the draft: I'd suggest replacing the references to preventing 'SPIT' with something along the lines of 'as a media security measure'; the term 'SPIT' is much more sweeping and not specifically descriptive of what a UA is doing when deciding whether or not to render a media stream within an existing call. From Simo.Veikkolainen@nokia.com Mon Dec 14 00:06:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFB03A69C4 for ; Mon, 14 Dec 2009 00:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+nf8H+71pWy for ; Mon, 14 Dec 2009 00:06:21 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 53BF33A688C for ; Mon, 14 Dec 2009 00:06:21 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBE85wIL000639; Mon, 14 Dec 2009 10:06:02 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:05:53 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:05:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:05:45 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 14 Dec 2009 09:05:42 +0100 From: To: , Date: Mon, 14 Dec 2009 09:05:40 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp51B4amb9KWoZHTk6ajI4Xf6uJDwCv2V4g Message-ID: References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> In-Reply-To: <4B215477.7000003@sip-communicator.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Dec 2009 08:05:45.0008 (UTC) FILETIME=[3CC5CB00:01CA7C94] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 08:06:22 -0000 DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEVtaWwgSXZvdiBbbWFpbHRv OmVtaWxAc2lwLWNvbW11bmljYXRvci5vcmddIE9uIEJlaGFsZiBPZiBleHQgRW1pbA0KPg0KPtCd 0LAgMTAuMTIuMDkgMjE6MDIsIFNwZW5jZXIgRGF3a2lucyDQvdCw0L/QuNGB0LA6DQo+PiBIaSwg RW1pbCwNCj4+DQo+PiBJIHRoaW5rIEknbSBmb2xsb3dpbmcgeW91IC0geW91J3JlIHNheWluZyB0 aGF0IHRoZSBjbGllbnQgc2hvdWxkIGJlDQo+c21hcnQNCj4+IGVub3VnaCB0aGF0IEkgb25seSBo YXZlIHRvIGVudGVyIHNwZW5jZXJAd29uZGVyaGFtc3Rlci5vcmcgb25jZSwgYW5kDQo+dGhlDQo+ PiBjbGllbnQgd291bGQgYmUgYWJsZSB0byB1c2UgdGhhdCBzdHJpbmcgYXMgbXkgU0lQIEFPUiBh cyB3ZWxsIGFzIG15DQo+SmFiYmVyDQo+PiBJRCwgcmlnaHQ/DQo+DQo+UmlnaHQhDQoNCkhtbSwg SSBndWVzcyBiZWZvcmUgZG9pbmcgdGhlIGluaXRpYWwgcmVnaXN0cmF0aW9uLCB0aGUgY2xpZW50 IGNvdWxkIGp1c3QgYXNrIHRoZSBjcmVkZW50aWFscyAodXNlcm5hbWUgYW5kIHBhc3N3b3JkKSBv bmNlIGFuZCB1c2UgdGhlbSBmb3IgYm90aCBTSVAgYW5kIFhNUFAgc2VydmljZXMgLSBidXQgdGhh dCB3b3VsZCByZXF1aXJlIHRoZSBjbGllbnQgdG8ga25vdyBiZWZvcmVoYW5kIHRoYXQgdGhlIHNh bWUgY3JlZGVudGlhbHMgYXJlIGdvb2QgZm9yIGJvdGggc2VydmljZXMuDQoNClNvIGFyZSB5b3Ug YXNraW5nIGZvciBhbiBpbmRpY2F0aW9uIGZyb20gdGhlIFNJUCBvciBYTVBQIHNlcnZlciBzYXlp bmcgc29tZXRoaW5nIGxpa2UgInlvdXIgcmVnaXN0cmF0aW9uIHRvIFNJUCBzZXJ2aWNlIGF0IGV4 YW1wbGUub3JnIHNlcnZpY2Ugd2FzIHN1Y2Nlc3NmdWwsIGFuZCwgYnkgdGhlIHdheSwgeW91IGNh biB5b3UgdXNlIHRoZSBzYW1lIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBmb3IgcmVnaXN0ZXJpbmcg dG8gWE1QUCBzZXJ2aWNlIGF0IGV4YW1wbGUub3JnIj8NCg0KU2ltbw0KDQo+Q2hlZXJzLA0KPkVt aWwNCg0K From Simo.Veikkolainen@nokia.com Mon Dec 14 00:48:16 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392BA3A6958 for ; Mon, 14 Dec 2009 00:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPkoDGobbZ6G for ; Mon, 14 Dec 2009 00:48:15 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D08993A6819 for ; Mon, 14 Dec 2009 00:48:14 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBE8lV0W008859; Mon, 14 Dec 2009 10:47:55 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:47:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:47:32 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 14 Dec 2009 09:47:31 +0100 From: To: , Date: Mon, 14 Dec 2009 09:47:30 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUwBCwx0wAK84OyA= Message-ID: References: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> In-Reply-To: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Dec 2009 08:47:32.0111 (UTC) FILETIME=[131F59F0:01CA7C9A] X-Nokia-AV: Clean Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 08:48:16 -0000 >-----Original Message----- >From: ext Roni Even [mailto:Even.roni@huawei.com] >Sent: 10 December, 2009 23:08 >To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >Subject: RE: [dispatch] Revised proposed charter for Combining SIP and >XMPP > >Hi, >I think that it must be stated very clearly that the assumption is that >both >XMPP client and SIP client reside on the same endpoint. Having both SIP and XMPP clients on the same endpoint is the assumption we = have - otherwise there couldn't be a "combined" endpoint. Could you point t= o a specific place in the charter text which you feel needs clarification. >I also think that the issue of support for multipoint (chat and >audio/video) >should be specified, is it in scope or not. This might be good to state in the charter. My opinion is that we should no= t develop solutions specifically for multipoint use cases. To me that seems= quite large problem area which is beyond what we are trying to address her= e. Simo >Thanks >Roni Even > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Simo.Veikkolainen@nokia.com >> Sent: Wednesday, December 09, 2009 3:11 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Revised proposed charter for Combining SIP and >XMPP >> >> Hello, >> Below is the proposed charter text for Combining SIP and XMPP revised >> according to the discussions in Hiroshima. Basically the changes are >> >> - include video in addition to voice >> - mention that existing SIP and XMPP endpoints are not affected >> - update milestones. >> >> Comments are very welcome. >> >> Regards, >> Simo >> >> >> -----8<------8<------8<------ >> >> Combining SIP VoIP and XMPP IM/Presence >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Currently most standards-based Voice over IP (VoIP) deployments use >the >> Session Initiation Protocol (SIP). In addition to providing basic >> voice service SIP has an extensive support for more advanced telephony >> features including interworking with the traditional Public Switched >> Telephone Network (PSTN). SIP is also gaining popularity in the field >> of video communication. At the same time, the Extensible Messaging and >> Presence Protocol (XMPP) is enjoying widespread usage in instant >> messaging and presence services. >> >> Both SIP and XMPP offer extensions for integrating voice and video >with >> IM and presence (XMPP voice via the Jingle extension, and SIP >> IM/presence via SIMPLE protocols). However, widespread deployment of >> these extensions has not so far taken place. In order to speed up >> deployment of integrated VoIP and IM systems, SIP based voice and XMPP >> based IM/Presence could be combined in endpoints to offer a voice, IM >> and presence service without any changes to existing SIP and XMPP >> service infrastructure. >> >> The objective of this Working Group is to develop solutions for >> combining SIP based voice with XMPP based IM and Presence such that a >> unified user experience can be offered to end user. Specifically, >> solutions are needed on >> - addressing; end users should be able to initiate sessions to a user >> identity in either SIP or XMPP domain. The corresponding user identity >> in the other protocol domain needs to be learned automatically. >> - session correlation; endpoints need to be able to correlate SIP >voice >> and video sessions with XMPP IM/Presence in such a manner that they >can >> be presented to the end user in a seamless fashion >> - presence; it should be possible to change the XMPP presence status >> based on the user's activity in the SIP domain. >> >> Existing SIP and XMPP endpoints are not affected and can interoperate >> with the implementations that comply with the extensions defined by >> this Working Group (but obviously without the additional functionality >> provided by these extensions). >> >> The goal is to rely on existing service infrastructure, and new >> requirements should be imposed only on the endpoints. >> >> Protocol interworking, that is, translation from one protocol to >> another, is out of scope of this WG. >> >> Milestones >> Jun 2010 Problem statement and use cases submitted to IESG as >> Informational. >> Jun 2011 Specification on combining SIP based voice and video and XMPP >> based IM/Presence in a seamless manner submitted to IESG as Proposed >> Standard. >> >> -----8<------8<------8<------ >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Mon Dec 14 00:59:51 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE0A3A684F for ; Mon, 14 Dec 2009 00:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=1.517, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsiXxLLPajLp for ; Mon, 14 Dec 2009 00:59:50 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id DBEBE3A6819 for ; Mon, 14 Dec 2009 00:59:49 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00B8MWUP7T@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 16:56:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM0075QWUL2V@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 16:56:49 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-138-101.red.bezeqint.net [82.81.138.101]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUM0047FWUD4J@szxml02-in.huawei.com>; Mon, 14 Dec 2009 16:56:45 +0800 (CST) Date: Mon, 14 Dec 2009 10:53:32 +0200 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, emcho@sip-communicator.org, spencer@wonderhamster.org Message-id: <01e501ca7c9a$ef3f95d0$cdbec170$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acp51B4amb9KWoZHTk6ajI4Xf6uJDwCv2V4gAAG579A= References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 08:59:51 -0000 Hi, I think that this will also require not only some common relation = between the SIP and XMPP clients but also some co-ordination between the = XMPP server and SIP server and according to my understanding this is out = of scope in the charter. On the other hand I see more benefits of such co-ordination since it = will allow the SIP client and XMPP client to be separate. I thought that = such work is in the scope of the XMPP working group. Roni > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Monday, December 14, 2009 10:06 AM > To: emcho@sip-communicator.org; spencer@wonderhamster.org > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and > XMPP >=20 >=20 >=20 > >-----Original Message----- > >From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of ext > Emil > > > >=D0=9D=D0=B0 10.12.09 21:02, Spencer Dawkins = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > >> Hi, Emil, > >> > >> I think I'm following you - you're saying that the client should be > >smart > >> enough that I only have to enter spencer@wonderhamster.org once, = and > >the > >> client would be able to use that string as my SIP AOR as well as my > >Jabber > >> ID, right? > > > >Right! >=20 > Hmm, I guess before doing the initial registration, the client could > just ask the credentials (username and password) once and use them for > both SIP and XMPP services - but that would require the client to know > beforehand that the same credentials are good for both services. >=20 > So are you asking for an indication from the SIP or XMPP server saying > something like "your registration to SIP service at example.org = service > was successful, and, by the way, you can you use the same username and > password for registering to XMPP service at example.org"? >=20 > Simo >=20 > >Cheers, > >Emil >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Mon Dec 14 01:12:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC423A681F for ; Mon, 14 Dec 2009 01:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw-+368mynD6 for ; Mon, 14 Dec 2009 01:12:21 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 781373A6834 for ; Mon, 14 Dec 2009 01:12:18 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00IPTXIPYD@szxga03-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 17:11:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM005BOXIPP9@szxga03-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 17:11:13 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-138-101.red.bezeqint.net [82.81.138.101]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUM00B4FXHYHY@szxml02-in.huawei.com>; Mon, 14 Dec 2009 17:11:13 +0800 (CST) Date: Mon, 14 Dec 2009 11:07:41 +0200 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Message-id: <01f501ca7c9c$f3efec90$dbcfc5b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUwBCwx0wAK84OyAAAOm+cA== References: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:12:22 -0000 Simo, The text in the proposed charter " The goal is to rely on existing service infrastructure, and new requirements should be imposed only on the endpoints." Is not strong enough since it is a SHOULD while as far as I understand you mean "SHALL". Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Monday, December 14, 2009 10:48 AM > To: Even.roni@huawei.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and > XMPP > > > > >-----Original Message----- > >From: ext Roni Even [mailto:Even.roni@huawei.com] > >Sent: 10 December, 2009 23:08 > >To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org > >Subject: RE: [dispatch] Revised proposed charter for Combining SIP and > >XMPP > > > >Hi, > >I think that it must be stated very clearly that the assumption is > that > >both > >XMPP client and SIP client reside on the same endpoint. > > Having both SIP and XMPP clients on the same endpoint is the assumption > we have - otherwise there couldn't be a "combined" endpoint. Could you > point to a specific place in the charter text which you feel needs > clarification. > > >I also think that the issue of support for multipoint (chat and > >audio/video) > >should be specified, is it in scope or not. > > This might be good to state in the charter. My opinion is that we > should not develop solutions specifically for multipoint use cases. To > me that seems quite large problem area which is beyond what we are > trying to address here. > > Simo > > > >Thanks > >Roni Even > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > >> Behalf Of Simo.Veikkolainen@nokia.com > >> Sent: Wednesday, December 09, 2009 3:11 PM > >> To: dispatch@ietf.org > >> Subject: [dispatch] Revised proposed charter for Combining SIP and > >XMPP > >> > >> Hello, > >> Below is the proposed charter text for Combining SIP and XMPP > revised > >> according to the discussions in Hiroshima. Basically the changes are > >> > >> - include video in addition to voice > >> - mention that existing SIP and XMPP endpoints are not affected > >> - update milestones. > >> > >> Comments are very welcome. > >> > >> Regards, > >> Simo > >> > >> > >> -----8<------8<------8<------ > >> > >> Combining SIP VoIP and XMPP IM/Presence > >> ======================================= > >> > >> Currently most standards-based Voice over IP (VoIP) deployments use > >the > >> Session Initiation Protocol (SIP). In addition to providing basic > >> voice service SIP has an extensive support for more advanced > telephony > >> features including interworking with the traditional Public Switched > >> Telephone Network (PSTN). SIP is also gaining popularity in the > field > >> of video communication. At the same time, the Extensible Messaging > and > >> Presence Protocol (XMPP) is enjoying widespread usage in instant > >> messaging and presence services. > >> > >> Both SIP and XMPP offer extensions for integrating voice and video > >with > >> IM and presence (XMPP voice via the Jingle extension, and SIP > >> IM/presence via SIMPLE protocols). However, widespread deployment of > >> these extensions has not so far taken place. In order to speed up > >> deployment of integrated VoIP and IM systems, SIP based voice and > XMPP > >> based IM/Presence could be combined in endpoints to offer a voice, > IM > >> and presence service without any changes to existing SIP and XMPP > >> service infrastructure. > >> > >> The objective of this Working Group is to develop solutions for > >> combining SIP based voice with XMPP based IM and Presence such that > a > >> unified user experience can be offered to end user. Specifically, > >> solutions are needed on > >> - addressing; end users should be able to initiate sessions to a > user > >> identity in either SIP or XMPP domain. The corresponding user > identity > >> in the other protocol domain needs to be learned automatically. > >> - session correlation; endpoints need to be able to correlate SIP > >voice > >> and video sessions with XMPP IM/Presence in such a manner that they > >can > >> be presented to the end user in a seamless fashion > >> - presence; it should be possible to change the XMPP presence status > >> based on the user's activity in the SIP domain. > >> > >> Existing SIP and XMPP endpoints are not affected and can > interoperate > >> with the implementations that comply with the extensions defined by > >> this Working Group (but obviously without the additional > functionality > >> provided by these extensions). > >> > >> The goal is to rely on existing service infrastructure, and new > >> requirements should be imposed only on the endpoints. > >> > >> Protocol interworking, that is, translation from one protocol to > >> another, is out of scope of this WG. > >> > >> Milestones > >> Jun 2010 Problem statement and use cases submitted to IESG as > >> Informational. > >> Jun 2011 Specification on combining SIP based voice and video and > XMPP > >> based IM/Presence in a seamless manner submitted to IESG as Proposed > >> Standard. > >> > >> -----8<------8<------8<------ > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Mon Dec 14 01:17:43 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616513A69CB for ; Mon, 14 Dec 2009 01:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhMEhLHS+8jP for ; Mon, 14 Dec 2009 01:17:42 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F18643A69BA for ; Mon, 14 Dec 2009 01:17:41 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00GL7XRVR8@szxga03-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 17:16:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM0096GXRVBT@szxga03-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 17:16:43 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-138-101.red.bezeqint.net [82.81.138.101]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUM00IMYXRNTG@szxml01-in.huawei.com>; Mon, 14 Dec 2009 17:16:43 +0800 (CST) Date: Mon, 14 Dec 2009 11:13:31 +0200 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Message-id: <01f601ca7c9d$b8722b00$29568100$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUwBCwx0wAK84OyAAAQFzkA== References: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:17:43 -0000 Simo, On the multipoint case, I think that the proposal should at least discuss it, not proposing a solution but pointing out what will work and what not. Thinking about it, I think that it relates to other services like call transfer on the SIP side what happens to the XMPP session, is this in scope to cause transfer of both sessions. I am not sure where the charter ends, is it just for establishing simple point to point calls and terminating them while any other call features are out of scope? Roni > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Monday, December 14, 2009 10:48 AM > To: Even.roni@huawei.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and > XMPP > > > > >-----Original Message----- > >From: ext Roni Even [mailto:Even.roni@huawei.com] > >Sent: 10 December, 2009 23:08 > >To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org > >Subject: RE: [dispatch] Revised proposed charter for Combining SIP and > >XMPP > > > >Hi, > >I think that it must be stated very clearly that the assumption is > that > >both > >XMPP client and SIP client reside on the same endpoint. > > Having both SIP and XMPP clients on the same endpoint is the assumption > we have - otherwise there couldn't be a "combined" endpoint. Could you > point to a specific place in the charter text which you feel needs > clarification. > > >I also think that the issue of support for multipoint (chat and > >audio/video) > >should be specified, is it in scope or not. > > This might be good to state in the charter. My opinion is that we > should not develop solutions specifically for multipoint use cases. To > me that seems quite large problem area which is beyond what we are > trying to address here. > > Simo > > > >Thanks > >Roni Even > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > >> Behalf Of Simo.Veikkolainen@nokia.com > >> Sent: Wednesday, December 09, 2009 3:11 PM > >> To: dispatch@ietf.org > >> Subject: [dispatch] Revised proposed charter for Combining SIP and > >XMPP > >> > >> Hello, > >> Below is the proposed charter text for Combining SIP and XMPP > revised > >> according to the discussions in Hiroshima. Basically the changes are > >> > >> - include video in addition to voice > >> - mention that existing SIP and XMPP endpoints are not affected > >> - update milestones. > >> > >> Comments are very welcome. > >> > >> Regards, > >> Simo > >> > >> > >> -----8<------8<------8<------ > >> > >> Combining SIP VoIP and XMPP IM/Presence > >> ======================================= > >> > >> Currently most standards-based Voice over IP (VoIP) deployments use > >the > >> Session Initiation Protocol (SIP). In addition to providing basic > >> voice service SIP has an extensive support for more advanced > telephony > >> features including interworking with the traditional Public Switched > >> Telephone Network (PSTN). SIP is also gaining popularity in the > field > >> of video communication. At the same time, the Extensible Messaging > and > >> Presence Protocol (XMPP) is enjoying widespread usage in instant > >> messaging and presence services. > >> > >> Both SIP and XMPP offer extensions for integrating voice and video > >with > >> IM and presence (XMPP voice via the Jingle extension, and SIP > >> IM/presence via SIMPLE protocols). However, widespread deployment of > >> these extensions has not so far taken place. In order to speed up > >> deployment of integrated VoIP and IM systems, SIP based voice and > XMPP > >> based IM/Presence could be combined in endpoints to offer a voice, > IM > >> and presence service without any changes to existing SIP and XMPP > >> service infrastructure. > >> > >> The objective of this Working Group is to develop solutions for > >> combining SIP based voice with XMPP based IM and Presence such that > a > >> unified user experience can be offered to end user. Specifically, > >> solutions are needed on > >> - addressing; end users should be able to initiate sessions to a > user > >> identity in either SIP or XMPP domain. The corresponding user > identity > >> in the other protocol domain needs to be learned automatically. > >> - session correlation; endpoints need to be able to correlate SIP > >voice > >> and video sessions with XMPP IM/Presence in such a manner that they > >can > >> be presented to the end user in a seamless fashion > >> - presence; it should be possible to change the XMPP presence status > >> based on the user's activity in the SIP domain. > >> > >> Existing SIP and XMPP endpoints are not affected and can > interoperate > >> with the implementations that comply with the extensions defined by > >> this Working Group (but obviously without the additional > functionality > >> provided by these extensions). > >> > >> The goal is to rely on existing service infrastructure, and new > >> requirements should be imposed only on the endpoints. > >> > >> Protocol interworking, that is, translation from one protocol to > >> another, is out of scope of this WG. > >> > >> Milestones > >> Jun 2010 Problem statement and use cases submitted to IESG as > >> Informational. > >> Jun 2011 Specification on combining SIP based voice and video and > XMPP > >> based IM/Presence in a seamless manner submitted to IESG as Proposed > >> Standard. > >> > >> -----8<------8<------8<------ > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Markus.Isomaki@nokia.com Mon Dec 14 01:35:49 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BE528C10E for ; Mon, 14 Dec 2009 01:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HryWjgdYz9j for ; Mon, 14 Dec 2009 01:35:48 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 343053A6863 for ; Mon, 14 Dec 2009 01:35:47 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBE9Z5wY007326; Mon, 14 Dec 2009 11:35:24 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 11:35:15 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 11:35:10 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 14 Dec 2009 10:35:10 +0100 From: To: , , Date: Mon, 14 Dec 2009 10:35:09 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp40Q7ip7w6jZFTT/mrU3f1dBmWUwBCwx0wAK84OyAAAQFzkAAAZwXg Message-ID: References: <008f01ca79dc$f27d89c0$d7789d40$%roni@huawei.com> <01f601ca7c9d$b8722b00$29568100$%roni@huawei.com> In-Reply-To: <01f601ca7c9d$b8722b00$29568100$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Dec 2009 09:35:10.0718 (UTC) FILETIME=[BAFC29E0:01CA7CA0] X-Nokia-AV: Clean Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:35:50 -0000 Hi, I think we should take the following step-wise approach: 1. Define the necessary standards for the basic 1-to-1 VoIP+video+IM+presen= ce use cases with a combined SIP+XMPP client. This should be the initial ch= arter.=20 2. Get some running code and hopefully even deployments to see that we are = on a useful track. (If nothing happens, we probably aren't, and should do s= omething else.) 3. Only after that, go into more complex cases (transfer, multipoint etc.).= =20 The challenge of course is that in step 1. we should aim at such modularity= that what is defined is forward-compatible with what we might want to achi= eve in step 3. I don't propose that we put any hard requirements on the cha= rter to have such a review, but definitely that should be one dimension for= instance when comparing different approaches. Markus >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Roni Even >Sent: 14 December, 2009 11:14 >To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >Subject: Re: [dispatch] Revised proposed charter for Combining=20 >SIP and XMPP > >Simo, >On the multipoint case, I think that the proposal should at=20 >least discuss it, not proposing a solution but pointing out=20 >what will work and what not. >Thinking about it, I think that it relates to other services=20 >like call transfer on the SIP side what happens to the XMPP=20 >session, is this in scope to cause transfer of both sessions. > >I am not sure where the charter ends, is it just for=20 >establishing simple point to point calls and terminating them=20 >while any other call features are out of scope? > >Roni =20 > >> -----Original Message----- >> From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On=20 >> Behalf Of Simo.Veikkolainen@nokia.com >> Sent: Monday, December 14, 2009 10:48 AM >> To: Even.roni@huawei.com; dispatch@ietf.org >> Subject: Re: [dispatch] Revised proposed charter for=20 >Combining SIP and=20 >> XMPP >>=20 >>=20 >>=20 >> >-----Original Message----- >> >From: ext Roni Even [mailto:Even.roni@huawei.com] >> >Sent: 10 December, 2009 23:08 >> >To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >> >Subject: RE: [dispatch] Revised proposed charter for Combining SIP=20 >> >and XMPP >> > >> >Hi, >> >I think that it must be stated very clearly that the assumption is >> that >> >both >> >XMPP client and SIP client reside on the same endpoint. >>=20 >> Having both SIP and XMPP clients on the same endpoint is the=20 >> assumption we have - otherwise there couldn't be a "combined"=20 >> endpoint. Could you point to a specific place in the charter text=20 >> which you feel needs clarification. >>=20 >> >I also think that the issue of support for multipoint (chat and >> >audio/video) >> >should be specified, is it in scope or not. >>=20 >> This might be good to state in the charter. My opinion is that we=20 >> should not develop solutions specifically for multipoint use=20 >cases. To=20 >> me that seems quite large problem area which is beyond what we are=20 >> trying to address here. >>=20 >> Simo >>=20 >>=20 >> >Thanks >> >Roni Even >> > >> > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> >> Behalf Of Simo.Veikkolainen@nokia.com >> >> Sent: Wednesday, December 09, 2009 3:11 PM >> >> To: dispatch@ietf.org >> >> Subject: [dispatch] Revised proposed charter for Combining SIP and >> >XMPP >> >> >> >> Hello, >> >> Below is the proposed charter text for Combining SIP and XMPP >> revised >> >> according to the discussions in Hiroshima. Basically the changes=20 >> >> are >> >> >> >> - include video in addition to voice >> >> - mention that existing SIP and XMPP endpoints are not affected >> >> - update milestones. >> >> >> >> Comments are very welcome. >> >> >> >> Regards, >> >> Simo >> >> >> >> >> >> -----8<------8<------8<------ >> >> >> >> Combining SIP VoIP and XMPP IM/Presence=20 >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> Currently most standards-based Voice over IP (VoIP)=20 >deployments use >> >the >> >> Session Initiation Protocol (SIP). In addition to=20 >providing basic=20 >> >> voice service SIP has an extensive support for more advanced >> telephony >> >> features including interworking with the traditional Public=20 >> >> Switched Telephone Network (PSTN). SIP is also gaining=20 >popularity=20 >> >> in the >> field >> >> of video communication. At the same time, the Extensible Messaging >> and >> >> Presence Protocol (XMPP) is enjoying widespread usage in instant=20 >> >> messaging and presence services. >> >> >> >> Both SIP and XMPP offer extensions for integrating voice and video >> >with >> >> IM and presence (XMPP voice via the Jingle extension, and SIP=20 >> >> IM/presence via SIMPLE protocols). However, widespread deployment=20 >> >> of these extensions has not so far taken place. In order to speed=20 >> >> up deployment of integrated VoIP and IM systems, SIP based voice=20 >> >> and >> XMPP >> >> based IM/Presence could be combined in endpoints to offer a voice, >> IM >> >> and presence service without any changes to existing SIP and XMPP=20 >> >> service infrastructure. >> >> >> >> The objective of this Working Group is to develop solutions for=20 >> >> combining SIP based voice with XMPP based IM and Presence=20 >such that >> a >> >> unified user experience can be offered to end user. Specifically,=20 >> >> solutions are needed on >> >> - addressing; end users should be able to initiate sessions to a >> user >> >> identity in either SIP or XMPP domain. The corresponding user >> identity >> >> in the other protocol domain needs to be learned automatically. >> >> - session correlation; endpoints need to be able to correlate SIP >> >voice >> >> and video sessions with XMPP IM/Presence in such a manner=20 >that they >> >can >> >> be presented to the end user in a seamless fashion >> >> - presence; it should be possible to change the XMPP presence=20 >> >> status based on the user's activity in the SIP domain. >> >> >> >> Existing SIP and XMPP endpoints are not affected and can >> interoperate >> >> with the implementations that comply with the extensions=20 >defined by=20 >> >> this Working Group (but obviously without the additional >> functionality >> >> provided by these extensions). >> >> >> >> The goal is to rely on existing service infrastructure, and new=20 >> >> requirements should be imposed only on the endpoints. >> >> >> >> Protocol interworking, that is, translation from one protocol to=20 >> >> another, is out of scope of this WG. >> >> >> >> Milestones >> >> Jun 2010 Problem statement and use cases submitted to IESG as=20 >> >> Informational. >> >> Jun 2011 Specification on combining SIP based voice and video and >> XMPP >> >> based IM/Presence in a seamless manner submitted to IESG as=20 >> >> Proposed Standard. >> >> >> >> -----8<------8<------8<------ >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch >= From emcho@sip-communicator.org Mon Dec 14 03:36:51 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782B83A6840 for ; Mon, 14 Dec 2009 03:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z7k8ehzTpJl for ; Mon, 14 Dec 2009 03:36:50 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 5BF633A67EA for ; Mon, 14 Dec 2009 03:36:50 -0800 (PST) Received: by fxm5 with SMTP id 5so3388689fxm.28 for ; Mon, 14 Dec 2009 03:36:33 -0800 (PST) Received: by 10.223.161.205 with SMTP id s13mr5594943fax.27.1260790593672; Mon, 14 Dec 2009 03:36:33 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 15sm1494215fxm.14.2009.12.14.03.36.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 03:36:31 -0800 (PST) Sender: Emil Ivov Message-ID: <4B26233D.60104@sip-communicator.org> Date: Mon, 14 Dec 2009 12:36:29 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 11:36:51 -0000 Hey Simo, =D0=9D=D0=B0 14.12.09 09:05, Simo.Veikkolainen@nokia.com =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: > Hmm, I guess before doing the initial registration, the client could > just ask the credentials (username and password) once and use them > for both SIP and XMPP services - but that would require the client to > know beforehand that the same credentials are good for both > services. Right. > So are you asking for an indication from the SIP or XMPP server > saying something like "your registration to SIP service at > example.org service was successful, and, by the way, you can you use > the same username and password for registering to XMPP service at > example.org"? Yes, something along these lines would do just fine. This could also help discovering that there is an associated XMPP service in the first place and could also be used for discovering its address in case it is different from the XMPP server at example.org. Cheers, Emil From pkyzivat@cisco.com Mon Dec 14 05:07:12 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117993A68BD for ; Mon, 14 Dec 2009 05:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDPbMYEKYblt for ; Mon, 14 Dec 2009 05:07:11 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D3D913A686C for ; Mon, 14 Dec 2009 05:07:10 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoKAITHJUtAZnwN/2dsb2JhbACECpRdp2KHAIINAwSMaoEvgQQbgQtSBA X-IronPort-AV: E=Sophos;i="4.47,395,1257120000"; d="scan'208";a="74109439" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2009 13:06:55 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBED6sI0016312; Mon, 14 Dec 2009 13:06:54 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:06:55 -0500 Received: from [10.86.245.38] ([10.86.245.38]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:06:54 -0500 Message-ID: <4B26386C.5040704@cisco.com> Date: Mon, 14 Dec 2009 08:06:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emil Ivov References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> In-Reply-To: <4B26233D.60104@sip-communicator.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Dec 2009 13:06:54.0549 (UTC) FILETIME=[4F0EF050:01CA7CBE] Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 13:07:12 -0000 I don't know how XMPP does authentication, but if it can use digest, then as someone else already mentioned, the "common credentials" can be automatic. Its a matter of the servers being integrated enough to use the same user, pw, and realm, and for the client to be integrated enough to recognize that the same realm has been requested. At that point it becomes a "quality of implementation" issue, on a par with implementing digest to cache and reuse credentials rather than asking for them again every time challenged. Thanks, Paul Emil Ivov wrote: > Hey Simo, > > Ðа 14.12.09 09:05, Simo.Veikkolainen@nokia.com напиÑа: >> Hmm, I guess before doing the initial registration, the client could >> just ask the credentials (username and password) once and use them >> for both SIP and XMPP services - but that would require the client to >> know beforehand that the same credentials are good for both >> services. > > Right. > >> So are you asking for an indication from the SIP or XMPP server >> saying something like "your registration to SIP service at >> example.org service was successful, and, by the way, you can you use >> the same username and password for registering to XMPP service at >> example.org"? > > Yes, something along these lines would do just fine. This could also > help discovering that there is an associated XMPP service in the first > place and could also be used for discovering its address in case it is > different from the XMPP server at example.org. > > Cheers, > Emil > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Mon Dec 14 05:49:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304FC28C129 for ; Mon, 14 Dec 2009 05:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYTXEIgt5a91 for ; Mon, 14 Dec 2009 05:49:52 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3B75228C126 for ; Mon, 14 Dec 2009 05:49:52 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUN005MZAA1VS@szxga01-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 21:46:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUN00828AA0PF@szxga01-in.huawei.com> for dispatch@ietf.org; Mon, 14 Dec 2009 21:46:49 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-138-101.red.bezeqint.net [82.81.138.101]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUN009PZA9RLB@szxml01-in.huawei.com>; Mon, 14 Dec 2009 21:46:48 +0800 (CST) Date: Mon, 14 Dec 2009 15:43:34 +0200 From: Roni Even In-reply-to: <4B26386C.5040704@cisco.com> To: 'Paul Kyzivat' , 'Emil Ivov' Message-id: <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acp8vl2hEfX/IuMEQ+2JIX+hTYBniQABFdpQ References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 13:49:53 -0000 The current proposed charter requires no dependency on the server = infrastructure, if we change it than we need to discuss other = functionality that may be dependent on support in the infrastructure. >From the proposed charter: " The goal is to rely on existing service infrastructre, and new = requirements should be imposed only to the endpoint." BTW: The above requirement about no dependency was discussed also in = Hiroshima. Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, December 14, 2009 3:07 PM > To: Emil Ivov > Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and > XMPP >=20 > I don't know how XMPP does authentication, but if it can use digest, > then as someone else already mentioned, the "common credentials" can = be > automatic. Its a matter of the servers being integrated enough to use > the same user, pw, and realm, and for the client to be integrated > enough > to recognize that the same realm has been requested. >=20 > At that point it becomes a "quality of implementation" issue, on a par > with implementing digest to cache and reuse credentials rather than > asking for them again every time challenged. >=20 > Thanks, > Paul >=20 > Emil Ivov wrote: > > Hey Simo, > > > > =D0=9D=D0=B0 14.12.09 09:05, Simo.Veikkolainen@nokia.com = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > >> Hmm, I guess before doing the initial registration, the client = could > >> just ask the credentials (username and password) once and use them > >> for both SIP and XMPP services - but that would require the client > to > >> know beforehand that the same credentials are good for both > >> services. > > > > Right. > > > >> So are you asking for an indication from the SIP or XMPP server > >> saying something like "your registration to SIP service at > >> example.org service was successful, and, by the way, you can you = use > >> the same username and password for registering to XMPP service at > >> example.org"? > > > > Yes, something along these lines would do just fine. This could also > > help discovering that there is an associated XMPP service in the > first > > place and could also be used for discovering its address in case it > is > > different from the XMPP server at example.org. > > > > Cheers, > > Emil > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Simo.Veikkolainen@nokia.com Mon Dec 14 06:20:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071A93A68D4 for ; Mon, 14 Dec 2009 06:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IJWiIFJhctw for ; Mon, 14 Dec 2009 06:20:00 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 24E293A6882 for ; Mon, 14 Dec 2009 06:19:58 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBEEJasv026700; Mon, 14 Dec 2009 16:19:37 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 16:19:17 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 16:19:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 16:19:12 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 14 Dec 2009 15:19:11 +0100 From: To: , , Date: Mon, 14 Dec 2009 15:19:11 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp8vl2hEfX/IuMEQ+2JIX+hTYBniQABFdpQAAEjGMA= Message-ID: References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> In-Reply-To: <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Dec 2009 14:19:12.0729 (UTC) FILETIME=[68D0AC90:01CA7CC8] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:20:01 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZXh0IFJvbmkgRXZlbiBbbWFpbHRv OkV2ZW4ucm9uaUBodWF3ZWkuY29tXQ0KPg0KPlRoZSBjdXJyZW50IHByb3Bvc2VkIGNoYXJ0ZXIg cmVxdWlyZXMgbm8gZGVwZW5kZW5jeSBvbiB0aGUgc2VydmVyDQo+aW5mcmFzdHJ1Y3R1cmUsIGlm IHdlIGNoYW5nZSBpdCB0aGFuIHdlIG5lZWQgdG8gZGlzY3VzcyBvdGhlcg0KPmZ1bmN0aW9uYWxp dHkgdGhhdCBtYXkgYmUgZGVwZW5kZW50IG9uIHN1cHBvcnQgaW4gdGhlIGluZnJhc3RydWN0dXJl Lg0KPg0KPkZyb20gdGhlIHByb3Bvc2VkIGNoYXJ0ZXI6DQo+IiBUaGUgZ29hbCBpcyB0byByZWx5 IG9uIGV4aXN0aW5nIHNlcnZpY2UgaW5mcmFzdHJ1Y3RyZSwgYW5kIG5ldw0KPnJlcXVpcmVtZW50 cyBzaG91bGQgYmUgaW1wb3NlZCBvbmx5IHRvIHRoZSBlbmRwb2ludC4iDQoNClRoaXMgaXMgY29y cmVjdCBhbmQgYXQgbGVhc3QgSSB3b3VsZCBsaWtlIHRvIGtlZXAgaXQgdGhhdCB3YXkuIEhvd2V2 ZXIsIGlmIHRoZSBzYW1lIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGZvciBib3RoIFNJUCBhbmQgWE1Q UCwgaXQgd291bGQgbWVhbiB0aGUgU0lQIGFuZCBYTVBQIGluZnJhcyBzaGFyZSB0aGUgc2FtZSBj cmVkZW50aWFscyBkYXRhYmFzZS4gSG93IHRoaXMgaXMgZG9uZSAob3IgaWYgYSBwcm92aWRlciBk ZWNpZGVzIHRvIGRvIHRoYXQgaW4gdGhlIGZpcnN0IHBsYWNlKSBzaG91bGQgYmUgb3V0IG9mIHNj b3BlIG9mIHRoaXMgY2hhcnRlci4NCg0KV2hldGhlciBhIHByb3RvY29sIG1lY2hhbmlzbSBzaG91 bGQgYmUgaW1wbGVtZW50ZWQgZm9yIGluZGljYXRpbmcgdG8gdGhlIGNsaWVudCB0aGF0IHRoZSBz YW1lIGNyZWRlbnRpYWxzIGNhbiBhbHNvIGJlIHVzZWQgaW4gdGhlIG90aGVyIGRvbWFpbiBpcyBh bm90aGVyIGlzc3VlLiBJIHNlZSB0aGVyZSBtaWdodCBiZSB2YWx1ZSBpbiBzdWNoIGEgbWVjaGFu aXNtLCBhbmQgb25lIHBvc3NpYmxlIHdheSBvZiBkb2luZyB0aGlzIGlzIHRvIHNpbXBseSBwcm92 aWRlIHRoZSBzYW1lICJyZWFsbSIgdG8gdGhlIGNsaWVudC4gQnV0IHRoaXMgZG9lc24ndCBuZWNl c3NhcmlseSBoYXZlIHRvIGJlIGluIHRoZSBjaGFydGVyIC0gd2UgY2FuIHN0aWxsIGRvY3VtZW50 IGl0IGluIHRoZSBJLUQncyBhbmQgUkZDcyB3ZSBhcmUgcHJvZHVjaW5nIGlmIGZvbGtzIHNlZSB0 aGlzIGFzIGEgdXNlZnVsIHRoaW5nIHRvIGRvLg0KDQpTaW1vDQoNCj4NCj5CVFc6IFRoZSBhYm92 ZSByZXF1aXJlbWVudCBhYm91dCBubyBkZXBlbmRlbmN5IHdhcyBkaXNjdXNzZWQgYWxzbyBpbg0K Pkhpcm9zaGltYS4NCj4NCj5Sb25pIEV2ZW4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCj4+IFNlbnQ6 IE1vbmRheSwgRGVjZW1iZXIgMTQsIDIwMDkgMzowNyBQTQ0KPj4gVG86IEVtaWwgSXZvdg0KPj4g Q2M6IFNpbW8uVmVpa2tvbGFpbmVuQG5va2lhLmNvbTsgZGlzcGF0Y2hAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFJldmlzZWQgcHJvcG9zZWQgY2hhcnRlciBmb3IgQ29tYmlu aW5nIFNJUCBhbmQNCj4+IFhNUFANCj4+DQo+PiBJIGRvbid0IGtub3cgaG93IFhNUFAgZG9lcyBh dXRoZW50aWNhdGlvbiwgYnV0IGlmIGl0IGNhbiB1c2UgZGlnZXN0LA0KPj4gdGhlbiBhcyBzb21l b25lIGVsc2UgYWxyZWFkeSBtZW50aW9uZWQsIHRoZSAiY29tbW9uIGNyZWRlbnRpYWxzIiBjYW4N Cj5iZQ0KPj4gYXV0b21hdGljLiBJdHMgYSBtYXR0ZXIgb2YgdGhlIHNlcnZlcnMgYmVpbmcgaW50 ZWdyYXRlZCBlbm91Z2ggdG8gdXNlDQo+PiB0aGUgc2FtZSB1c2VyLCBwdywgYW5kIHJlYWxtLCBh bmQgZm9yIHRoZSBjbGllbnQgdG8gYmUgaW50ZWdyYXRlZA0KPj4gZW5vdWdoDQo+PiB0byByZWNv Z25pemUgdGhhdCB0aGUgc2FtZSByZWFsbSBoYXMgYmVlbiByZXF1ZXN0ZWQuDQo+Pg0KPj4gQXQg dGhhdCBwb2ludCBpdCBiZWNvbWVzIGEgInF1YWxpdHkgb2YgaW1wbGVtZW50YXRpb24iIGlzc3Vl LCBvbiBhIHBhcg0KPj4gd2l0aCBpbXBsZW1lbnRpbmcgZGlnZXN0IHRvIGNhY2hlIGFuZCByZXVz ZSBjcmVkZW50aWFscyByYXRoZXIgdGhhbg0KPj4gYXNraW5nIGZvciB0aGVtIGFnYWluIGV2ZXJ5 IHRpbWUgY2hhbGxlbmdlZC4NCj4+DQo+PiAJVGhhbmtzLA0KPj4gCVBhdWwNCj4+DQo+PiBFbWls IEl2b3Ygd3JvdGU6DQo+PiA+IEhleSBTaW1vLA0KPj4gPg0KPj4gPiDQndCwIDE0LjEyLjA5IDA5 OjA1LCBTaW1vLlZlaWtrb2xhaW5lbkBub2tpYS5jb20g0L3QsNC/0LjRgdCwOg0KPj4gPj4gSG1t LCBJIGd1ZXNzIGJlZm9yZSBkb2luZyB0aGUgaW5pdGlhbCByZWdpc3RyYXRpb24sIHRoZSBjbGll bnQNCj5jb3VsZA0KPj4gPj4ganVzdCBhc2sgdGhlIGNyZWRlbnRpYWxzICh1c2VybmFtZSBhbmQg cGFzc3dvcmQpIG9uY2UgYW5kIHVzZSB0aGVtDQo+PiA+PiBmb3IgYm90aCBTSVAgYW5kIFhNUFAg c2VydmljZXMgLSBidXQgdGhhdCB3b3VsZCByZXF1aXJlIHRoZSBjbGllbnQNCj4+IHRvDQo+PiA+ PiBrbm93IGJlZm9yZWhhbmQgdGhhdCB0aGUgc2FtZSBjcmVkZW50aWFscyBhcmUgZ29vZCBmb3Ig Ym90aA0KPj4gPj4gc2VydmljZXMuDQo+PiA+DQo+PiA+IFJpZ2h0Lg0KPj4gPg0KPj4gPj4gU28g YXJlIHlvdSBhc2tpbmcgZm9yIGFuIGluZGljYXRpb24gZnJvbSB0aGUgU0lQIG9yIFhNUFAgc2Vy dmVyDQo+PiA+PiBzYXlpbmcgc29tZXRoaW5nIGxpa2UgInlvdXIgcmVnaXN0cmF0aW9uIHRvIFNJ UCBzZXJ2aWNlIGF0DQo+PiA+PiBleGFtcGxlLm9yZyBzZXJ2aWNlIHdhcyBzdWNjZXNzZnVsLCBh bmQsIGJ5IHRoZSB3YXksIHlvdSBjYW4geW91DQo+dXNlDQo+PiA+PiB0aGUgc2FtZSB1c2VybmFt ZSBhbmQgcGFzc3dvcmQgZm9yIHJlZ2lzdGVyaW5nIHRvIFhNUFAgc2VydmljZSBhdA0KPj4gPj4g ZXhhbXBsZS5vcmciPw0KPj4gPg0KPj4gPiBZZXMsIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5l cyB3b3VsZCBkbyBqdXN0IGZpbmUuIFRoaXMgY291bGQgYWxzbw0KPj4gPiBoZWxwIGRpc2NvdmVy aW5nIHRoYXQgdGhlcmUgaXMgYW4gYXNzb2NpYXRlZCBYTVBQIHNlcnZpY2UgaW4gdGhlDQo+PiBm aXJzdA0KPj4gPiBwbGFjZSBhbmQgY291bGQgYWxzbyBiZSB1c2VkIGZvciBkaXNjb3ZlcmluZyBp dHMgYWRkcmVzcyBpbiBjYXNlIGl0DQo+PiBpcw0KPj4gPiBkaWZmZXJlbnQgZnJvbSB0aGUgWE1Q UCBzZXJ2ZXIgYXQgZXhhbXBsZS5vcmcuDQo+PiA+DQo+PiA+IENoZWVycywNCj4+ID4gRW1pbA0K Pj4gPg0KPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+ID4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRpc3BhdGNo IG1haWxpbmcgbGlzdA0KPj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0K From stpeter@stpeter.im Mon Dec 14 06:45:25 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3993A682E for ; Mon, 14 Dec 2009 06:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRyD0T+4UW1a for ; Mon, 14 Dec 2009 06:45:24 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 809683A680B for ; Mon, 14 Dec 2009 06:45:24 -0800 (PST) Received: from squire.local (dsl-228-57.dynamic-dsl.frii.net [216.17.228.57]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7464B40337; Mon, 14 Dec 2009 07:45:10 -0700 (MST) Message-ID: <4B264F6D.90102@stpeter.im> Date: Mon, 14 Dec 2009 07:45:01 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im><4B21406E.60605@sip-communicator.org><1260471307.25475.1912.camel@scott><4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> In-Reply-To: <4B26386C.5040704@cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070003010602000203050103" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:45:25 -0000 This is a cryptographically signed message in MIME format. --------------ms070003010602000203050103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/14/09 6:06 AM, Paul Kyzivat wrote: > I don't know how XMPP does authentication, As described in RFC 3920, XMPP uses SASL. The most commonly used mechanisms are DIGEST-MD5 (currently being deprecated in favor of SCRAM), PLAIN (over TLS), EXTERNAL, and ANONYMOUS. > but if it can use digest, > then as someone else already mentioned, the "common credentials" can be > automatic. Its a matter of the servers being integrated enough to use > the same user, pw, and realm, and for the client to be integrated enough > to recognize that the same realm has been requested. > > At that point it becomes a "quality of implementation" issue, on a par > with implementing digest to cache and reuse credentials rather than > asking for them again every time challenged. Quite possibly. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070003010602000203050103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNDE0NDUwMVowIwYJKoZIhvcNAQkEMRYEFN5+UtbI9dKQUf+vGPp8 8U8FuPKDMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJeK4um9fW+hqtQB7axjjoLxs6+j6oIorGbt1K76P +J8ZN45hstBjyFGFLH3BhmlkQ5RMTY0CFTv0NfY/OKkxcCsU0t8GrniJJQ9db7aFdNQCo7Q7 3z2xa1Ye1tjnQLQ7DYdPzSADNhRwSZNbEt0An/4tfRmCUc37yvUrJv7/kFH4izHcY9UDHYg6 504I6AhleEefut6V5g/ZvBi4xZoI1mLpk0yeQ2TdV+VrCh/SCvZXjrGRDc5wfOHpLthODeFZ VprFYjzAQuyBs2kOzn8kiAlx03qim0a7RK9kah7useo2INCQWd/gS7CAhcG0o69A1+KH5Nj6 6ttgdRokjQ8nwAAAAAAAAA== --------------ms070003010602000203050103-- From stpeter@stpeter.im Mon Dec 14 07:04:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067963A684C for ; Mon, 14 Dec 2009 07:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoY4T6-NPcjU for ; Mon, 14 Dec 2009 07:04:34 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BA6993A6774 for ; Mon, 14 Dec 2009 07:04:34 -0800 (PST) Received: from squire.local (dsl-228-57.dynamic-dsl.frii.net [216.17.228.57]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F386C40337; Mon, 14 Dec 2009 08:04:20 -0700 (MST) Message-ID: <4B2653F3.6070907@stpeter.im> Date: Mon, 14 Dec 2009 08:04:19 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060007010306010506020005" Cc: dispatch@ietf.org, Even.roni@huawei.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:04:36 -0000 This is a cryptographically signed message in MIME format. --------------ms060007010306010506020005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/14/09 7:19 AM, Simo.Veikkolainen@nokia.com wrote: >> -----Original Message----- From: ext Roni Even >> [mailto:Even.roni@huawei.com] >> >> The current proposed charter requires no dependency on the server >> infrastructure, if we change it than we need to discuss other >> functionality that may be dependent on support in the >> infrastructure. >> >> From the proposed charter: " The goal is to rely on existing >> service infrastructre, and new requirements should be imposed only >> to the endpoint." > > This is correct and at least I would like to keep it that way. > However, if the same credentials are used for both SIP and XMPP, it > would mean the SIP and XMPP infras share the same credentials > database. How this is done (or if a provider decides to do that in > the first place) should be out of scope of this charter. Agreed. As I understand it, this group is trying to define some simple methods that make it easier to implement a dual-stack (SIP/XMPP) client. IMHO it would best to complete some of the "low-hanging fruit" before adding additional complexities. And you can bet that anything involving authentication will be complex, or at least controversial. > Whether a protocol mechanism should be implemented for indicating to > the client that the same credentials can also be used in the other > domain is another issue. I see there might be value in such a > mechanism, and one possible way of doing this is to simply provide > the same "realm" to the client. But this doesn't necessarily have to > be in the charter - we can still document it in the I-D's and RFCs we > are producing if folks see this as a useful thing to do. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060007010306010506020005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNDE1MDQxOVowIwYJKoZIhvcNAQkEMRYEFHzXEWVdBEv5+/AdJIUL rWWcDxkiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAiPwd4bQg2ibZaq5Ah6Ry5PfCeifCUb8KdbsD1EVd B2tDOOynSJ5kGEsHUFQibbtfULBtFLeTSSZIxE0/B0hS/jHnwpub6JS5nHM3CNvPlYm3/7/H VUOKC4o4GHR35Qpjp5N11EDjg/BxbF5wQSNwQsmnrSs4uRAQE0VVBRqeb1SdZQ8zYnBNqH05 Po7kO4/18kb3Tf5Yz3JMGXPOTzCvnDMSMEP/CoCQiH24Uu92jMBky71CY0NUi15dyBzdtnry lM0qCRd0P06ERfDYVg4jwZe6rl/ReHqNXNqcF7S8gZxJ+7TQ2YXoZXZigInbuDZ8bkvL+oP1 s0E8Byt0zr/A2wAAAAAAAA== --------------ms060007010306010506020005-- From emcho@sip-communicator.org Mon Dec 14 07:26:09 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426A13A67E4 for ; Mon, 14 Dec 2009 07:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQIW4WVevzsx for ; Mon, 14 Dec 2009 07:26:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 415AB3A67CC for ; Mon, 14 Dec 2009 07:26:07 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so859996eyd.51 for ; Mon, 14 Dec 2009 07:25:51 -0800 (PST) Received: by 10.213.96.65 with SMTP id g1mr5880707ebn.44.1260804351052; Mon, 14 Dec 2009 07:25:51 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 28sm4687594eye.3.2009.12.14.07.25.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 07:25:49 -0800 (PST) Sender: Emil Ivov Message-ID: <4B2658FB.50506@sip-communicator.org> Date: Mon, 14 Dec 2009 16:25:47 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Even.roni@huawei.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:26:09 -0000 Hey Simo, =D0=9D=D0=B0 14.12.09 15:19, Simo.Veikkolainen@nokia.com =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: >> -----Original Message----- From: ext Roni Even >> [mailto:Even.roni@huawei.com] >>=20 >> The current proposed charter requires no dependency on the server=20 >> infrastructure, if we change it than we need to discuss other=20 >> functionality that may be dependent on support in the >> infrastructure. >>=20 >> From the proposed charter: " The goal is to rely on existing >> service infrastructre, and new requirements should be imposed only >> to the endpoint." >=20 > This is correct and at least I would like to keep it that way. > However, if the same credentials are used for both SIP and XMPP, it > would mean the SIP and XMPP infras share the same credentials > database. How this is done (or if a provider decides to do that in > the first place) should be out of scope of this charter. >=20 > Whether a protocol mechanism should be implemented for indicating to > the client that the same credentials can also be used in the other > domain is another issue. I see there might be value in such a > mechanism, and one possible way of doing this is to simply provide > the same "realm" to the client. But this doesn't necessarily have to > be in the charter - we can still document it in the I-D's and RFCs we > are producing if folks see this as a useful thing to do. As long as people don't see such documenting (i.e. recommendations/best practices directed toward server side developers and maintainers) as a contradiction with the above quote from the charter, then that would indeed be just fine. Emil From bernard_aboba@hotmail.com Mon Dec 14 08:06:39 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708F53A68FB for ; Mon, 14 Dec 2009 08:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlatziK7LuLs for ; Mon, 14 Dec 2009 08:06:38 -0800 (PST) Received: from blu0-omc4-s10.blu0.hotmail.com (blu0-omc4-s10.blu0.hotmail.com [65.55.111.149]) by core3.amsl.com (Postfix) with ESMTP id 9112C3A67E2 for ; Mon, 14 Dec 2009 08:06:38 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.135]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:06:25 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: References: In-Reply-To: Date: Mon, 14 Dec 2009 08:06:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp80b3uFDcTMqvuR6KMeOpkmfI1nAABEg3w Content-Language: en-us X-OriginalArrivalTime: 14 Dec 2009 16:06:25.0864 (UTC) FILETIME=[63432C80:01CA7CD7] Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:06:39 -0000 > This is correct and at least I would like to keep it that way. > However, if the same credentials are used for both SIP and XMPP, it > would mean the SIP and XMPP infras share the same credentials > database. How this is done (or if a provider decides to do that in > the first place) should be out of scope of this charter. Right. However, this is a deployment issue, not a protocol issue. The focus here is on the endpoints; the backend servers may exist within the same administrative domain, or they may not; they may share the same backend, or they may not. Even if they share the same backend, they may not necessarily utilize the same backend schema elements. In any case, I'd argue that changing the authentication mechanisms for either SIP or XMPP should be out of scope. In the case of XMPP (which relies on SASL), it isn't even clear to me that such a change should even be discussed in the RAI area (as opposed to the Security area). From stpeter@stpeter.im Mon Dec 14 08:36:12 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E133A68D4 for ; Mon, 14 Dec 2009 08:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvIQMXLQwCnK for ; Mon, 14 Dec 2009 08:36:11 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D9F4D3A686E for ; Mon, 14 Dec 2009 08:36:10 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0DD5340337; Mon, 14 Dec 2009 09:35:56 -0700 (MST) Message-ID: <4B266349.1050100@stpeter.im> Date: Mon, 14 Dec 2009 09:09:45 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Emil Ivov References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <4B2658FB.50506@sip-communicator.org> In-Reply-To: <4B2658FB.50506@sip-communicator.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050903060504080605070806" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org, Even.roni@huawei.com Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:36:12 -0000 This is a cryptographically signed message in MIME format. --------------ms050903060504080605070806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/14/09 8:25 AM, Emil Ivov wrote: > Hey Simo, >=20 > =D0=9D=D0=B0 14.12.09 15:19, Simo.Veikkolainen@nokia.com =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0: >>> -----Original Message----- From: ext Roni Even >>> [mailto:Even.roni@huawei.com] >>> >>> The current proposed charter requires no dependency on the server=20 >>> infrastructure, if we change it than we need to discuss other=20 >>> functionality that may be dependent on support in the >>> infrastructure. >>> >>> From the proposed charter: " The goal is to rely on existing >>> service infrastructre, and new requirements should be imposed only >>> to the endpoint." >> This is correct and at least I would like to keep it that way. >> However, if the same credentials are used for both SIP and XMPP, it >> would mean the SIP and XMPP infras share the same credentials >> database. How this is done (or if a provider decides to do that in >> the first place) should be out of scope of this charter. >> >> Whether a protocol mechanism should be implemented for indicating to >> the client that the same credentials can also be used in the other >> domain is another issue. I see there might be value in such a >> mechanism, and one possible way of doing this is to simply provide >> the same "realm" to the client. But this doesn't necessarily have to >> be in the charter - we can still document it in the I-D's and RFCs we >> are producing if folks see this as a useful thing to do. >=20 > As long as people don't see such documenting (i.e. recommendations/best= > practices directed toward server side developers and maintainers) as a > contradiction with the above quote from the charter, then that would > indeed be just fine. The charter is a positive statement of what the group will work on. That doesn't forbid the group (or certainly individual contributors) from working on other tasks that are deemed helpful. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050903060504080605070806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNDE2MDk0NVowIwYJKoZIhvcNAQkEMRYEFApCV5y8ZBv0O0kstXVp m9V9eu9YMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAlwftPivOfPN2LTb2oGstkyx5z02zgcqEiWhq2v8S BHsQpbcLrmuYTTzUYL2Jy3EeFEf4g2fvkG5XGogj95qUskT8000Uf5HvM+WtUsPlVs/MwMzg cTxUITSjihEp1ZFwLa0wc53IVvmnqOInpvfAAtH2pwe/hfVeHApv0ZfgR3tuM+Jye5r+Ml/e 89ydmGvY1/0tPfa8fZ2MRn9pXaHCjwKx6814AeWQgMuKd1lnovK9BkpvlGKtpWfE48rO1ZQE z+UwM+OK1aZtWP3gXRofZKoS7lqoKrefTFHgym72Hk9h5V3Er+ifpeZ7tdrXShRjVhVpqPK3 zGieRYO6Ds+56gAAAAAAAA== --------------ms050903060504080605070806-- From Even.roni@huawei.com Mon Dec 14 15:04:45 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0424E3A6868 for ; Mon, 14 Dec 2009 15:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8m0vWMGnPew for ; Mon, 14 Dec 2009 15:04:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1934A3A6853 for ; Mon, 14 Dec 2009 15:04:44 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO009GQ038U6@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 15 Dec 2009 07:04:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00GAG038N9@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 15 Dec 2009 07:04:20 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-138-101.red.bezeqint.net [82.81.138.101]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO000LT02TFM@szxml02-in.huawei.com>; Tue, 15 Dec 2009 07:04:20 +0800 (CST) Date: Tue, 15 Dec 2009 01:00:58 +0200 From: Roni Even In-reply-to: <4B2658FB.50506@sip-communicator.org> To: 'Emil Ivov' , Simo.Veikkolainen@nokia.com Message-id: <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acp80cDp8Ejk3fAuRD2caw6obJqwogAPZd8Q References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <4B2658FB.50506@sip-communicator.org> Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 23:04:45 -0000 Hi, I want to clarify that during the Hiroshima session my view was that = support for some infrastructure assumption will be beneficial. I had = other use case where you have a video conferencing SIP appliance that = does not have XMPP support in a room with a PC that does the XMPP = talking to a client that does both XMPP and SIP. The infrastructure is = this case will need to know the relation between the appliance and the = PC similar to the case discussed here where both client share the same = credentials, this need to be supported in the infrastructure and somehow = conveyed to the clients. The way I see it is that Simo's view as was presented in Hiroshima is = that the clients will need to assume two separate servers with no = relations and any assumption on relation between the servers is not part = of the charter. To summarize, I think this is not a question of shared credentials but a = question if the sentence " The goal is to rely on existing service = infrastructre, and new requirements should be imposed only to the = endpoint." is part of the charter. Roni Even > -----Original Message----- > From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of Emil > Ivov > Sent: Monday, December 14, 2009 5:26 PM > To: Simo.Veikkolainen@nokia.com > Cc: Even.roni@huawei.com; pkyzivat@cisco.com; dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and > XMPP >=20 > Hey Simo, >=20 > =D0=9D=D0=B0 14.12.09 15:19, Simo.Veikkolainen@nokia.com = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > >> -----Original Message----- From: ext Roni Even > >> [mailto:Even.roni@huawei.com] > >> > >> The current proposed charter requires no dependency on the server > >> infrastructure, if we change it than we need to discuss other > >> functionality that may be dependent on support in the > >> infrastructure. > >> > >> From the proposed charter: " The goal is to rely on existing > >> service infrastructre, and new requirements should be imposed only > >> to the endpoint." > > > > This is correct and at least I would like to keep it that way. > > However, if the same credentials are used for both SIP and XMPP, it > > would mean the SIP and XMPP infras share the same credentials > > database. How this is done (or if a provider decides to do that in > > the first place) should be out of scope of this charter. > > > > Whether a protocol mechanism should be implemented for indicating to > > the client that the same credentials can also be used in the other > > domain is another issue. I see there might be value in such a > > mechanism, and one possible way of doing this is to simply provide > > the same "realm" to the client. But this doesn't necessarily have to > > be in the charter - we can still document it in the I-D's and RFCs = we > > are producing if folks see this as a useful thing to do. >=20 > As long as people don't see such documenting (i.e. = recommendations/best > practices directed toward server side developers and maintainers) as a > contradiction with the above quote from the charter, then that would > indeed be just fine. >=20 > Emil From bernie@ietf.hoeneisen.ch Tue Dec 15 08:57:55 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D025B3A6AB8; Tue, 15 Dec 2009 08:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReyE1G-fdnkN; Tue, 15 Dec 2009 08:57:55 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id CC91A3A6A9D; Tue, 15 Dec 2009 08:57:54 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NKaiO-0002GC-8r; Tue, 15 Dec 2009 17:57:36 +0100 Date: Tue, 15 Dec 2009 17:57:36 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF DISPATCH list Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list Subject: [dispatch] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 16:57:55 -0000 Hi DISPATCH E.164 to Metadata (E2M) defines a new DDDS application for all the services that do not fit into the original ENUM concept, but still are relevant in today's deployments, such as 'cnam', 'unused' or 'send-n'. draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the issues with certain ENUM WG documents that are currently locked in the publication queue. The sheperding AD (Cullen) does not see E2M happening in the ENUM WG, as he intends to shut down the ENUM WG. He advised me to send this proposal to the DISPATCH WG and task DISPATCH to find a proper home for this work. Several people generally support to E2M proposal, however, some details of the E2M proposal still need more work. So lets find soon a proper home for E2M! cheers, Bernie PS (to ENUM mailing list subscribers): Since -01 the E2M discussion has moved from the ENUM to the DISPATCH mailing list. Those of you who are only subscribed to the ENUM mailing list, please subscribe also to the DISPATCH mailing list and send your comments to (only). PPS (to those of you, who reply to this email): Please remove from the destination list of your replies to avoid crossposting. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, December 14, 2009 4:45 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : E.164 to Metadata (E2M) Dynamic Delegation Discovery System (DDDS) Application Author(s) : B. Hoeneisen Filename : draft-hoeneisen-e164-to-metadata-01.txt Pages : 14 Date : 2009-12-14 This document proposes a new Dynamic Delegation Discovery System (DDDS) Application to map E.164 numbers to metadata. It discusses the use of the Domain Name System (DNS) for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From richard@shockey.us Tue Dec 15 09:51:15 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6CB83A68F2 for ; Tue, 15 Dec 2009 09:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFVTWnckhTEm for ; Tue, 15 Dec 2009 09:51:14 -0800 (PST) Received: from outbound-mail-313.bluehost.com (outbound-mail-313.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id D0FD13A62C1 for ; Tue, 15 Dec 2009 09:51:14 -0800 (PST) Received: (qmail 7113 invoked by uid 0); 15 Dec 2009 17:51:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 15 Dec 2009 17:51:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=WLpvoz2tNUHA3CMOl7cYBmXTdVK+GLk/NFTpaEiEj3bMqoV0nuwTXoZS/OZXvZ3gcIauZQJxqA+OP7wLI6r+XPRtSifbjD5sQl8M6whPotuYAgSRIKMTxZzLlrdtd/d9; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NKbY5-0002mc-8j; Tue, 15 Dec 2009 10:51:01 -0700 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , "'IETF DISPATCH list'" References: In-Reply-To: Date: Tue, 15 Dec 2009 12:50:58 -0500 Message-ID: <010501ca7daf$28e4c2f0$7aae48d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acp9p7hjWgKKwjSNQRWPUUlN2ssjDwAB1duw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: 'IETF ENUM list' Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 17:51:15 -0000 And as the ENUM WG co-chair (for now) I wholeheartedly support this idea. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Bernie Hoeneisen > Sent: Tuesday, December 15, 2009 11:58 AM > To: IETF DISPATCH list > Cc: IETF ENUM list > Subject: [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to- > metadata-01.txt > > Hi DISPATCH > > E.164 to Metadata (E2M) defines a new DDDS application for all the > services that do not fit into the original ENUM concept, but still are > relevant in today's deployments, such as 'cnam', 'unused' or 'send-n'. > > draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the > issues with certain ENUM WG documents that are currently locked in the > publication queue. > > The sheperding AD (Cullen) does not see E2M happening in the ENUM WG, > as > he intends to shut down the ENUM WG. He advised me to send this > proposal > to the DISPATCH WG and task DISPATCH to find a proper home for this > work. > > Several people generally support to E2M proposal, however, some > details of > the E2M proposal still need more work. > > So lets find soon a proper home for E2M! > > cheers, > Bernie > > > PS (to ENUM mailing list subscribers): > Since -01 the E2M discussion has moved from the ENUM to the DISPATCH > mailing list. Those of you who are only subscribed to the ENUM mailing > list, please subscribe also to the DISPATCH mailing list > and send your > comments to > (only). > > > PPS (to those of you, who reply to this email): > Please remove from the destination list of your > replies to > avoid crossposting. > > > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, December 14, 2009 4:45 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : E.164 to Metadata (E2M) Dynamic Delegation > Discovery System (DDDS) Application > Author(s) : B. Hoeneisen > Filename : draft-hoeneisen-e164-to-metadata-01.txt > Pages : 14 > Date : 2009-12-14 > > This document proposes a new Dynamic Delegation Discovery System > (DDDS) Application to map E.164 numbers to metadata. > > It discusses the use of the Domain Name System (DNS) for resolving > E.164 numbers into metadata to provide information about E.164 > numbers in cases where E.164 Number to URI Mapping (ENUM) can not > be > used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata- > 01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From bernie@ietf.hoeneisen.ch Tue Dec 15 11:01:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B623A67A6 for ; Tue, 15 Dec 2009 11:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLS0mgr1gwej for ; Tue, 15 Dec 2009 11:01:55 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with SMTP id 875CB3A67F3 for ; Tue, 15 Dec 2009 11:01:05 -0800 (PST) X-Mailbox-Line: From bernie@ietf.hoeneisen.ch Tue Dec 15 19:36:32 2009 Date: Tue, 15 Dec 2009 19:36:32 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Tony Rutkowski In-Reply-To: <4B27D162.4080000@netmagic.com> Message-ID: References: <4B27D162.4080000@netmagic.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Georges Sebek , IETF DISPATCH list Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:01:56 -0000 Hi Tony Thanks for bringing this up. I am all for coordination with other SDOs, if there are (inter-)dependencies, overlap, similar work or whatsover. However, I fail to see the relevance of the ITU-T SG 17 with respect to the E2U proposal. Could you please explain a bit more what you believe are the touch points of E2U and ITU-T SG 17 (in particular IdM)? cheers, Bernie On Tue, 15 Dec 2009, Tony Rutkowski wrote: > Hi Bernie, > > Since Rec. ITU-T E.164 is ITU-T's standard and they > are significantly engaged in IdM standards activities in > SG17, this should probably be coordinated with them. > Although it might be regarded as apostasy by some IETFers, > it might even be done together with them. > > cheers, > tony > >> Hi DISPATCH >> >> E.164 to Metadata (E2M) defines a new DDDS application for all the services >> that do not fit into the original ENUM concept, but still are >> relevant in today's deployments, such as 'cnam', 'unused' or 'send-n'. >> >> draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the issues >> with certain ENUM WG documents that are currently locked in the publication >> queue. >> >> The sheperding AD (Cullen) does not see E2M happening in the ENUM WG, as he >> intends to shut down the ENUM WG. He advised me to send this proposal to >> the DISPATCH WG and task DISPATCH to find a proper home for this work. >> >> Several people generally support to E2M proposal, however, some details of >> the E2M proposal still need more work. >> >> So lets find soon a proper home for E2M! >> >> cheers, >> Bernie >> >> >> PS (to ENUM mailing list subscribers): >> Since -01 the E2M discussion has moved from the ENUM to the DISPATCH >> mailing list. Those of you who are only subscribed to the ENUM mailing >> list, please subscribe also to the DISPATCH mailing list >> and send your comments to >> (only). >> >> >> PPS (to those of you, who reply to this email): >> Please remove from the destination list of your replies to >> avoid crossposting. >> >> >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >> Sent: Monday, December 14, 2009 4:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : E.164 to Metadata (E2M) Dynamic Delegation >> Discovery System (DDDS) Application >> Author(s) : B. Hoeneisen >> Filename : draft-hoeneisen-e164-to-metadata-01.txt >> Pages : 14 >> Date : 2009-12-14 >> >> This document proposes a new Dynamic Delegation Discovery System >> (DDDS) Application to map E.164 numbers to metadata. >> >> It discusses the use of the Domain Name System (DNS) for resolving >> E.164 numbers into metadata to provide information about E.164 >> numbers in cases where E.164 Number to URI Mapping (ENUM) can not be >> used. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www.ietf.org/mailman/listinfo/enum >> > > From trutkowski@netmagic.com Tue Dec 15 10:12:25 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA4D3A6ADF; Tue, 15 Dec 2009 10:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n9WETHKYTLA; Tue, 15 Dec 2009 10:12:23 -0800 (PST) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id C70053A68F2; Tue, 15 Dec 2009 10:12:23 -0800 (PST) Received: from [192.168.0.31] ([173.72.150.224]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KUP00G7AH7MCGO9@vms173005.mailsrvcs.net>; Tue, 15 Dec 2009 12:11:51 -0600 (CST) Message-id: <4B27D162.4080000@netmagic.com> Date: Tue, 15 Dec 2009 13:11:46 -0500 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091208 Shredder/3.0 MIME-version: 1.0 To: Bernie Hoeneisen References: In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 15 Dec 2009 11:22:05 -0800 Cc: IETF ENUM list , Georges Sebek , IETF DISPATCH list Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 18:12:25 -0000 Hi Bernie, Since Rec. ITU-T E.164 is ITU-T's standard and they are significantly engaged in IdM standards activities in SG17, this should probably be coordinated with them. Although it might be regarded as apostasy by some IETFers, it might even be done together with them. cheers, tony > Hi DISPATCH > > E.164 to Metadata (E2M) defines a new DDDS application for all the > services that do not fit into the original ENUM concept, but still are > relevant in today's deployments, such as 'cnam', 'unused' or 'send-n'. > > draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the > issues with certain ENUM WG documents that are currently locked in the > publication queue. > > The sheperding AD (Cullen) does not see E2M happening in the ENUM WG, > as he intends to shut down the ENUM WG. He advised me to send this > proposal to the DISPATCH WG and task DISPATCH to find a proper home > for this work. > > Several people generally support to E2M proposal, however, some > details of the E2M proposal still need more work. > > So lets find soon a proper home for E2M! > > cheers, > Bernie > > > PS (to ENUM mailing list subscribers): > Since -01 the E2M discussion has moved from the ENUM to the DISPATCH > mailing list. Those of you who are only subscribed to the ENUM mailing > list, please subscribe also to the DISPATCH mailing list > and send your > comments to (only). > > > PPS (to those of you, who reply to this email): > Please remove from the destination list of your > replies to avoid crossposting. > > > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, December 14, 2009 4:45 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : E.164 to Metadata (E2M) Dynamic Delegation > Discovery System (DDDS) Application > Author(s) : B. Hoeneisen > Filename : draft-hoeneisen-e164-to-metadata-01.txt > Pages : 14 > Date : 2009-12-14 > > This document proposes a new Dynamic Delegation Discovery System > (DDDS) Application to map E.164 numbers to metadata. > > It discusses the use of the Domain Name System (DNS) for resolving > E.164 numbers into metadata to provide information about E.164 > numbers in cases where E.164 Number to URI Mapping (ENUM) can not be > used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-01.txt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From trutkowski@netmagic.com Tue Dec 15 11:10:44 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE03A3A68F5 for ; Tue, 15 Dec 2009 11:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-E5yN8zH2hB for ; Tue, 15 Dec 2009 11:10:40 -0800 (PST) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id E2AC53A688F for ; Tue, 15 Dec 2009 11:10:39 -0800 (PST) Received: from [192.168.0.31] ([unknown] [173.72.150.224]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KUP006UXJWZ1L90@vms173019.mailsrvcs.net> for dispatch@ietf.org; Tue, 15 Dec 2009 13:10:16 -0600 (CST) Message-id: <4B27DF13.6080706@netmagic.com> Date: Tue, 15 Dec 2009 14:10:11 -0500 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091208 Shredder/3.0 MIME-version: 1.0 To: Bernie Hoeneisen References: <4B27D162.4080000@netmagic.com> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 15 Dec 2009 11:22:05 -0800 Cc: Georges Sebek , IETF DISPATCH list , abbie barbir , Richard Brackney Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:10:44 -0000 Hi Bernie, SG17 is the home within ITU-T (among other things) of security metadata work. This includes, for example, pointers from OIDs to metadata where a variant of ENUM is being used in conjunction with that namespace. There is an active sub-group dedicated to Identity Management known as Q.10/17. Substantial discussions have occurred over the past two years on how an IdM trusted interoperability model (now adopted as X.1250) that includes obtaining metadata associated with network application identifiers like E.164. This has included SG2 which is explicitly responsible for E.164, and international cnam capabilities. Toward this end, we are collaborating with the CAB Forum to adopt the EVcert specification as an ITU-T standard to enhance the trust in provider metadata, among other things. I've copied the chair and co-chairs that group, Abbie Barbir and Dick Brackney, respectively. Ultimately this is their call at the ITU-T end. Hope this helps, --tony On 12/15/2009 1:36 PM, Bernie Hoeneisen wrote: > Hi Tony > > Thanks for bringing this up. > > I am all for coordination with other SDOs, if there are > (inter-)dependencies, overlap, similar work or whatsover. > > However, I fail to see the relevance of the ITU-T SG 17 with respect > to the E2U proposal. Could you please explain a bit more what you > believe are the touch points of E2U and ITU-T SG 17 (in particular IdM)? > > cheers, > Bernie > > > On Tue, 15 Dec 2009, Tony Rutkowski wrote: > >> Hi Bernie, >> >> Since Rec. ITU-T E.164 is ITU-T's standard and they >> are significantly engaged in IdM standards activities in >> SG17, this should probably be coordinated with them. >> Although it might be regarded as apostasy by some IETFers, >> it might even be done together with them. >> >> cheers, >> tony >> >>> Hi DISPATCH >>> >>> E.164 to Metadata (E2M) defines a new DDDS application for all the >>> services that do not fit into the original ENUM concept, but still are >>> relevant in today's deployments, such as 'cnam', 'unused' or 'send-n'. >>> >>> draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the >>> issues with certain ENUM WG documents that are currently locked in >>> the publication queue. >>> >>> The sheperding AD (Cullen) does not see E2M happening in the ENUM >>> WG, as he intends to shut down the ENUM WG. He advised me to send >>> this proposal to the DISPATCH WG and task DISPATCH to find a proper >>> home for this work. >>> >>> Several people generally support to E2M proposal, however, some >>> details of the E2M proposal still need more work. >>> >>> So lets find soon a proper home for E2M! >>> >>> cheers, >>> Bernie >>> >>> >>> PS (to ENUM mailing list subscribers): >>> Since -01 the E2M discussion has moved from the ENUM to the DISPATCH >>> mailing list. Those of you who are only subscribed to the ENUM >>> mailing list, please subscribe also to the DISPATCH mailing list >>> and send your >>> comments to (only). >>> >>> >>> PPS (to those of you, who reply to this email): >>> Please remove from the destination list of your >>> replies to avoid crossposting. >>> >>> >>> >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] >>> On Behalf Of Internet-Drafts@ietf.org >>> Sent: Monday, December 14, 2009 4:45 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : E.164 to Metadata (E2M) Dynamic Delegation >>> Discovery System (DDDS) Application >>> Author(s) : B. Hoeneisen >>> Filename : draft-hoeneisen-e164-to-metadata-01.txt >>> Pages : 14 >>> Date : 2009-12-14 >>> >>> This document proposes a new Dynamic Delegation Discovery System >>> (DDDS) Application to map E.164 numbers to metadata. >>> >>> It discusses the use of the Domain Name System (DNS) for resolving >>> E.164 numbers into metadata to provide information about E.164 >>> numbers in cases where E.164 Number to URI Mapping (ENUM) can not be >>> used. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www.ietf.org/mailman/listinfo/enum >>> >> >> > From bernie@ietf.hoeneisen.ch Tue Dec 15 11:29:12 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17EF3A6882 for ; Tue, 15 Dec 2009 11:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VtPGr1NpXLC for ; Tue, 15 Dec 2009 11:29:11 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id BA9893A67F3 for ; Tue, 15 Dec 2009 11:29:11 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NKd4r-0002b2-6o for dispatch@ietf.org; Tue, 15 Dec 2009 20:28:57 +0100 Date: Tue, 15 Dec 2009 20:28:57 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF DISPATCH list Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [dispatch] E2M: Proposed Charter (draft version only) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:29:13 -0000 Hi, As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for an E2M charter (draft) for discussion on this mailing list. Have fun! cheers, Bernie --- E.164 to Metadata (E2M) (proposed charter / draft state) ----------------------- Last Modified: 2009-12-15 Additional information is available at tools.ietf.org/wg/e2m [not yet in use] Chair(s): * TBA Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: General Discussion: e2m@ietf.org [not yet in use] To Subscribe: e2m-request@ietf.org [not yet in use] In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/e2m/index.html [not yet in use] Description of Working Group: Abstract E.164 to Metadata (E2M) will use of the Domain Name System (DNS) for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. Background ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. Thus, ENUM can be used to look up the services associated with an E.164 number. However, it is controversial whether or not the result of an ENUM lookup should always be intended to establish a communications session using the URI found in the corresponding Naming Authority Pointer (NAPTR) DNS Resource Record (RR). Problem Statement Several proposals for Enumservice registrations do not fulfill the above mentioned interpretation, which suggests that an ENUM lookup should always be intended to result in a communications session. These proposals are therefore virtually locked in the process. Such proposals include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, and 'send-n' to describe the structure of an ENUM tree. Another issue is that the result of an ENUM (E2U) lookup always needs to be an URI, which unnecessarily complicates simple mappings. The authors of such Enumservice proposals tried to circumvent the issues by introducing the 'data' URI scheme or inventing completely new URI schemes, with limited success however. The main objection remained that an ENUM lookup should always result in a URI intended to establish a communications session. Proposal The E2M Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application E2M, which can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. The resulting metadata can be used (for example) to provide hints about properties of certain ENUM domains or to provide information that can be used as attributes of an E.164 number. E2M will provide the means for services related to E.164 numbers that do not fit into the concept of ENUM (E2U), and thus a way forward for such existing ENUM WG documents in the queue. Along with the E2M DDDS application a new IANA registry will be specified for registration of E2M services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similarly as specified for Enumservice registrations. The E2M specifications shall reuse a much as possible from the ENUM DDDS and its IANA registry specification. The E2M Working Group may take on further proposals for E2M service registrations (e.g. send-n) until the IANA registration for E2M services is approved by the IESG. Goals and Milestones: Aug 2010 Submit Internet Draft(s) for the E2M DDDS application and its IANA registry specification Dec 2010 Submit 'cnam' and 'unused' as E2M service registrations (Informational) XXX 2011 Close the E2M Working Group (or recharter) Internet-Drafts: http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-01 http://tools.ietf.org/html/draft-ietf-enum-unused-04 http://tools.ietf.org/html/draft-ietf-enum-cnam-08 (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) Request For Comments: None From richard@shockey.us Tue Dec 15 11:35:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB99D3A68FE for ; Tue, 15 Dec 2009 11:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8Xd-MZUY7Co for ; Tue, 15 Dec 2009 11:35:38 -0800 (PST) Received: from outbound-mail-128.bluehost.com (outbound-mail-128.bluehost.com [67.222.38.28]) by core3.amsl.com (Postfix) with SMTP id E162D3A67E5 for ; Tue, 15 Dec 2009 11:35:37 -0800 (PST) Received: (qmail 12788 invoked by uid 0); 15 Dec 2009 19:35:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 15 Dec 2009 19:35:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=ZRgAwT7U9dxyDRk7DaosmK7B9muOfCdNAIKG6oMDRKXtHEpBiNFfg+Q4RuRafVzmtp9zO0S7DIQXju5ikrplfCZMPjjEaH6h7FCUpqVYqcOnOQKeNTmCDc2uKb65m5+W; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NKdB4-0001nN-Kb; Tue, 15 Dec 2009 12:35:22 -0700 From: "Richard Shockey" To: , "'Bernie Hoeneisen'" References: <4B27D162.4080000@netmagic.com> <4B27DF13.6080706@netmagic.com> In-Reply-To: <4B27DF13.6080706@netmagic.com> Date: Tue, 15 Dec 2009 14:35:18 -0500 Message-ID: <014401ca7dbd$bcd07730$36716590$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acp9u936qC7KRLs6QVyIBFqzZ16inQAAabEg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: 'Georges Sebek' , 'IETF DISPATCH list' , 'abbie barbir' , 'Richard Brackney' Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:35:39 -0000 Thanks Tony ... I appreciate this note. Its just one more justification for properly advancing this e2m concept. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Tony Rutkowski > Sent: Tuesday, December 15, 2009 2:10 PM > To: Bernie Hoeneisen > Cc: Georges Sebek; IETF DISPATCH list; abbie barbir; Richard Brackney > Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft- > hoeneisen-e164-to-metadata-01.txt > > Hi Bernie, > > SG17 is the home within ITU-T (among other things) > of security metadata work. This includes, for example, > pointers from OIDs to metadata where a variant of ENUM > is being used in conjunction with that namespace. > > There is an active sub-group dedicated to Identity Management > known as Q.10/17. Substantial discussions have occurred over > the past two years on how an IdM trusted interoperability model > (now adopted as X.1250) that includes obtaining metadata > associated with network application identifiers like E.164. > This has included SG2 which is explicitly responsible for > E.164, and international cnam capabilities. Toward this end, > we are collaborating with the CAB Forum to adopt the > EVcert specification as an ITU-T standard to enhance the > trust in provider metadata, among other things. > > I've copied the chair and co-chairs that group, Abbie > Barbir and Dick Brackney, respectively. Ultimately this > is their call at the ITU-T end. > > Hope this helps, > --tony > > > > On 12/15/2009 1:36 PM, Bernie Hoeneisen wrote: > > Hi Tony > > > > Thanks for bringing this up. > > > > I am all for coordination with other SDOs, if there are > > (inter-)dependencies, overlap, similar work or whatsover. > > > > However, I fail to see the relevance of the ITU-T SG 17 with respect > > to the E2U proposal. Could you please explain a bit more what you > > believe are the touch points of E2U and ITU-T SG 17 (in particular > IdM)? > > > > cheers, > > Bernie > > > > > > On Tue, 15 Dec 2009, Tony Rutkowski wrote: > > > >> Hi Bernie, > >> > >> Since Rec. ITU-T E.164 is ITU-T's standard and they > >> are significantly engaged in IdM standards activities in > >> SG17, this should probably be coordinated with them. > >> Although it might be regarded as apostasy by some IETFers, > >> it might even be done together with them. > >> > >> cheers, > >> tony > >> > >>> Hi DISPATCH > >>> > >>> E.164 to Metadata (E2M) defines a new DDDS application for all the > >>> services that do not fit into the original ENUM concept, but still > are > >>> relevant in today's deployments, such as 'cnam', 'unused' or > 'send-n'. > >>> > >>> draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the > >>> issues with certain ENUM WG documents that are currently locked in > >>> the publication queue. > >>> > >>> The sheperding AD (Cullen) does not see E2M happening in the ENUM > >>> WG, as he intends to shut down the ENUM WG. He advised me to send > >>> this proposal to the DISPATCH WG and task DISPATCH to find a > proper > >>> home for this work. > >>> > >>> Several people generally support to E2M proposal, however, some > >>> details of the E2M proposal still need more work. > >>> > >>> So lets find soon a proper home for E2M! > >>> > >>> cheers, > >>> Bernie > >>> > >>> > >>> PS (to ENUM mailing list subscribers): > >>> Since -01 the E2M discussion has moved from the ENUM to the > DISPATCH > >>> mailing list. Those of you who are only subscribed to the ENUM > >>> mailing list, please subscribe also to the DISPATCH mailing list > >>> and send your > >>> comments to (only). > >>> > >>> > >>> PPS (to those of you, who reply to this email): > >>> Please remove from the destination list of your > >>> replies to avoid crossposting. > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org > >>> [mailto:i-d-announce-bounces@ietf.org] > >>> On Behalf Of Internet-Drafts@ietf.org > >>> Sent: Monday, December 14, 2009 4:45 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> > >>> Title : E.164 to Metadata (E2M) Dynamic Delegation > >>> Discovery System (DDDS) Application > >>> Author(s) : B. Hoeneisen > >>> Filename : draft-hoeneisen-e164-to-metadata-01.txt > >>> Pages : 14 > >>> Date : 2009-12-14 > >>> > >>> This document proposes a new Dynamic Delegation Discovery System > >>> (DDDS) Application to map E.164 numbers to metadata. > >>> > >>> It discusses the use of the Domain Name System (DNS) for > resolving > >>> E.164 numbers into metadata to provide information about E.164 > >>> numbers in cases where E.164 Number to URI Mapping (ENUM) can > not be > >>> used. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to- > metadata-01.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> _______________________________________________ > >>> enum mailing list > >>> enum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/enum > >>> > >> > >> > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Tue Dec 15 11:57:11 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1DF3A68CD for ; Tue, 15 Dec 2009 11:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIJzHCo2yR+j for ; Tue, 15 Dec 2009 11:57:10 -0800 (PST) Received: from outbound-mail-314.bluehost.com (outbound-mail-314.bluehost.com [67.222.54.7]) by core3.amsl.com (Postfix) with SMTP id 3B0593A68BA for ; Tue, 15 Dec 2009 11:57:10 -0800 (PST) Received: (qmail 14522 invoked by uid 0); 15 Dec 2009 19:56:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 15 Dec 2009 19:56:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=NkfD1tznz/VaUWJB9g8hcB0PJwf9PcPwvso259UDRGbiyxCiFnpqjDUdokB8OagAOcyCLA+qYHGEUAct+gYtzxFjsi6+Bvyb9Six2XzKtFCQ3SkGv6eyYQwYcU9YAnwH; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NKdVu-00007A-Hz for dispatch@ietf.org; Tue, 15 Dec 2009 12:56:56 -0700 From: "Richard Shockey" To: "'IETF DISPATCH list'" References: In-Reply-To: Date: Tue, 15 Dec 2009 14:56:51 -0500 Message-ID: <015b01ca7dc0$becf4d10$3c6de730$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acp9vNqz1zMlOglFR6eMPH6YzFhhGAAAluvg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: Re: [dispatch] E2M: Proposed Charter (draft version only) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:57:11 -0000 +1 in support of this charter As the editor of the ENUM draft on CNAM frankly I was a bit appalled at what I was forced to go through to try and make this work to the satisfaction of some in the RAI directorate and the IESG. The result was nothing if not a total kludge (see the draft) . It would have been much simpler to add the parameter to the SIP URI but there are those that have a layer 10 conviction that only routing information can be in the URI... but then I couldn't use the DATA URI since that was too much like TXT RR's etc. So you have to invent a total kludge PSTN PSTNDATA uri http://tools.ietf.org/html/draft-ietf-enum-cnam-08 The point here is, BTW, that phone numbers are not going away. Not now not ever, some folks just need to get over that issue ASAP. 99.9999 % of all SIP transactions in the field involve phone numbers and there needs to be simpler and more effective way of expressing and or looking up metadata associated with those identifiers. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Bernie Hoeneisen > Sent: Tuesday, December 15, 2009 2:29 PM > To: IETF DISPATCH list > Subject: [dispatch] E2M: Proposed Charter (draft version only) > > Hi, > > As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for an > E2M > charter (draft) for discussion on this mailing list. > > Have fun! > > cheers, > Bernie > > --- > > E.164 to Metadata (E2M) (proposed charter / draft state) > ----------------------- > > Last Modified: 2009-12-15 > > Additional information is available at tools.ietf.org/wg/e2m > [not yet in use] > > > Chair(s): > > * TBA > > Real-time Applications and Infrastructure Area Director(s): > > * Robert Sparks > * Cullen Jennings > > Real-time Applications and Infrastructure Area Advisor: > > * Cullen Jennings > > > Mailing Lists: > > General Discussion: e2m@ietf.org [not yet in use] > To Subscribe: e2m-request@ietf.org [not yet in use] > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/e2m/index.html > [not yet in use] > > > Description of Working Group: > > Abstract > > E.164 to Metadata (E2M) will use of the Domain Name System (DNS) > for resolving E.164 numbers into metadata to provide information > about E.164 numbers in cases where E.164 Number to URI Mapping > (ENUM) can not be used. > > > Background > > ENUM provides an identifier mapping mechanism to map E.164 numbers > to Uniform Resource Identifiers (URIs) using the DNS. > > Thus, ENUM can be used to look up the services associated with an > E.164 number. However, it is controversial whether or not the > result > of an ENUM lookup should always be intended to establish a > communications session using the URI found in the corresponding > Naming Authority Pointer (NAPTR) DNS Resource Record (RR). > > > Problem Statement > > Several proposals for Enumservice registrations do not fulfill the > above mentioned interpretation, which suggests that an ENUM lookup > should always be intended to result in a communications session. > These proposals are therefore virtually locked in the process. > Such proposals include (but are not limited to) Enumservices for > 'cnam' to provide information about the calling party name, > 'unused' to provide a hint that a number is not in use, and > 'send-n' to describe the structure of an ENUM tree. > > Another issue is that the result of an ENUM (E2U) lookup always > needs to be an URI, which unnecessarily complicates simple > mappings. > > The authors of such Enumservice proposals tried to circumvent the > issues by introducing the 'data' URI scheme or inventing > completely > new URI schemes, with limited success however. The main objection > remained that an ENUM lookup should always result in a URI > intended > to establish a communications session. > > Proposal > > The E2M Working Group is chartered to develop a new Dynamic > Delegation Discovery System (DDDS) application E2M, which can be > used with DNS NAPTR RRs for resolving E.164 numbers into metadata. > The resulting metadata can be used (for example) to provide hints > about properties of certain ENUM domains or to provide information > that can be used as attributes of an E.164 number. > > E2M will provide the means for services related to E.164 numbers > that do not fit into the concept of ENUM (E2U), and thus a > way forward for such existing ENUM WG documents in the queue. > > Along with the E2M DDDS application a new IANA registry will be > specified for registration of E2M services. The registration > policy > shall be Expert Review and Specification Required (see RFC 5226), > similarly as specified for Enumservice registrations. > > The E2M specifications shall reuse a much as possible from the > ENUM > DDDS and its IANA registry specification. > > The E2M Working Group may take on further proposals for E2M > service > registrations (e.g. send-n) until the IANA registration for E2M > services is approved by the IESG. > > > Goals and Milestones: > > Aug 2010 Submit Internet Draft(s) for the E2M DDDS application > and > its IANA registry specification > > Dec 2010 Submit 'cnam' and 'unused' as E2M service registrations > (Informational) > > XXX 2011 Close the E2M Working Group (or recharter) > > > Internet-Drafts: > > http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-01 > http://tools.ietf.org/html/draft-ietf-enum-unused-04 > http://tools.ietf.org/html/draft-ietf-enum-cnam-08 > (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) > > > Request For Comments: > > None > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From abarbir@live.ca Tue Dec 15 12:23:31 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CE63A68D8 for ; Tue, 15 Dec 2009 12:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ln2G+zbRlE9 for ; Tue, 15 Dec 2009 12:23:30 -0800 (PST) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by core3.amsl.com (Postfix) with ESMTP id 9EF1F3A67EC for ; Tue, 15 Dec 2009 12:23:29 -0800 (PST) Received: from BLU108-DS1 ([65.55.116.73]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 12:23:16 -0800 X-Originating-IP: [70.48.70.192] X-Originating-Email: [abarbir@live.ca] Message-ID: From: "abbie barbir" To: "'Richard Shockey'" , , "'Bernie Hoeneisen'" References: <4B27D162.4080000@netmagic.com> <4B27DF13.6080706@netmagic.com> <014401ca7dbd$bcd07730$36716590$@us> In-Reply-To: <014401ca7dbd$bcd07730$36716590$@us> Date: Wed, 16 Dec 2009 03:23:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp9u936qC7KRLs6QVyIBFqzZ16inQAAabEgABrRL3A= Content-Language: en-ca X-OriginalArrivalTime: 15 Dec 2009 20:23:16.0286 (UTC) FILETIME=[6F00B5E0:01CA7DC4] X-Mailman-Approved-At: Tue, 15 Dec 2009 14:38:56 -0800 Cc: 'Georges Sebek' , 'IETF DISPATCH list' , 'Richard Brackney' Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:24:18 -0000 Hi Tony many thanks for the e-mail I would welcome this activity to be submitted and discussed in Q10/17 Please let me know how I can be of any further help Regards Abbie -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: December-15-09 2:35 PM To: trutkowski@netmagic.com; 'Bernie Hoeneisen' Cc: 'Georges Sebek'; 'IETF DISPATCH list'; 'abbie barbir'; 'Richard Brackney'; 'Cullen Jennings' Subject: RE: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt Thanks Tony ... I appreciate this note. Its just one more justification for properly advancing this e2m concept. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Tony Rutkowski > Sent: Tuesday, December 15, 2009 2:10 PM > To: Bernie Hoeneisen > Cc: Georges Sebek; IETF DISPATCH list; abbie barbir; Richard Brackney > Subject: Re: [dispatch] [Enum] E2M: Find a proper home for draft- > hoeneisen-e164-to-metadata-01.txt > > Hi Bernie, > > SG17 is the home within ITU-T (among other things) > of security metadata work. This includes, for example, > pointers from OIDs to metadata where a variant of ENUM > is being used in conjunction with that namespace. > > There is an active sub-group dedicated to Identity Management > known as Q.10/17. Substantial discussions have occurred over > the past two years on how an IdM trusted interoperability model > (now adopted as X.1250) that includes obtaining metadata > associated with network application identifiers like E.164. > This has included SG2 which is explicitly responsible for > E.164, and international cnam capabilities. Toward this end, > we are collaborating with the CAB Forum to adopt the > EVcert specification as an ITU-T standard to enhance the > trust in provider metadata, among other things. > > I've copied the chair and co-chairs that group, Abbie > Barbir and Dick Brackney, respectively. Ultimately this > is their call at the ITU-T end. > > Hope this helps, > --tony > > > > On 12/15/2009 1:36 PM, Bernie Hoeneisen wrote: > > Hi Tony > > > > Thanks for bringing this up. > > > > I am all for coordination with other SDOs, if there are > > (inter-)dependencies, overlap, similar work or whatsover. > > > > However, I fail to see the relevance of the ITU-T SG 17 with respect > > to the E2U proposal. Could you please explain a bit more what you > > believe are the touch points of E2U and ITU-T SG 17 (in particular > IdM)? > > > > cheers, > > Bernie > > > > > > On Tue, 15 Dec 2009, Tony Rutkowski wrote: > > > >> Hi Bernie, > >> > >> Since Rec. ITU-T E.164 is ITU-T's standard and they > >> are significantly engaged in IdM standards activities in > >> SG17, this should probably be coordinated with them. > >> Although it might be regarded as apostasy by some IETFers, > >> it might even be done together with them. > >> > >> cheers, > >> tony > >> > >>> Hi DISPATCH > >>> > >>> E.164 to Metadata (E2M) defines a new DDDS application for all the > >>> services that do not fit into the original ENUM concept, but still > are > >>> relevant in today's deployments, such as 'cnam', 'unused' or > 'send-n'. > >>> > >>> draft-hoeneisen-e164-to-metadata decribes how E2M can resolve the > >>> issues with certain ENUM WG documents that are currently locked in > >>> the publication queue. > >>> > >>> The sheperding AD (Cullen) does not see E2M happening in the ENUM > >>> WG, as he intends to shut down the ENUM WG. He advised me to send > >>> this proposal to the DISPATCH WG and task DISPATCH to find a > proper > >>> home for this work. > >>> > >>> Several people generally support to E2M proposal, however, some > >>> details of the E2M proposal still need more work. > >>> > >>> So lets find soon a proper home for E2M! > >>> > >>> cheers, > >>> Bernie > >>> > >>> > >>> PS (to ENUM mailing list subscribers): > >>> Since -01 the E2M discussion has moved from the ENUM to the > DISPATCH > >>> mailing list. Those of you who are only subscribed to the ENUM > >>> mailing list, please subscribe also to the DISPATCH mailing list > >>> and send your > >>> comments to (only). > >>> > >>> > >>> PPS (to those of you, who reply to this email): > >>> Please remove from the destination list of your > >>> replies to avoid crossposting. > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org > >>> [mailto:i-d-announce-bounces@ietf.org] > >>> On Behalf Of Internet-Drafts@ietf.org > >>> Sent: Monday, December 14, 2009 4:45 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D ACTION:draft-hoeneisen-e164-to-metadata-01.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> > >>> Title : E.164 to Metadata (E2M) Dynamic Delegation > >>> Discovery System (DDDS) Application > >>> Author(s) : B. Hoeneisen > >>> Filename : draft-hoeneisen-e164-to-metadata-01.txt > >>> Pages : 14 > >>> Date : 2009-12-14 > >>> > >>> This document proposes a new Dynamic Delegation Discovery System > >>> (DDDS) Application to map E.164 numbers to metadata. > >>> > >>> It discusses the use of the Domain Name System (DNS) for > resolving > >>> E.164 numbers into metadata to provide information about E.164 > >>> numbers in cases where E.164 Number to URI Mapping (ENUM) can > not be > >>> used. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to- > metadata-01.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> _______________________________________________ > >>> enum mailing list > >>> enum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/enum > >>> > >> > >> > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.105/2562 - Release Date: 12/14/09 14:40:00 From Simo.Veikkolainen@nokia.com Wed Dec 16 01:56:40 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E913A6851 for ; Wed, 16 Dec 2009 01:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.633 X-Spam-Level: X-Spam-Status: No, score=-6.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxeKJORzXm55 for ; Wed, 16 Dec 2009 01:56:39 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A6AD23A6B4A for ; Wed, 16 Dec 2009 01:56:37 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBG9trSb005939; Wed, 16 Dec 2009 03:56:20 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:56:15 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:56:11 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:56:06 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 16 Dec 2009 10:56:05 +0100 From: To: , Date: Wed, 16 Dec 2009 10:56:04 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp80cDp8Ejk3fAuRD2caw6obJqwogAPZd8QAEmY9yA= Message-ID: References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <4B2658FB.50506@sip-communicator.org> <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> In-Reply-To: <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Dec 2009 09:56:06.0479 (UTC) FILETIME=[FC4D95F0:01CA7E35] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:56:40 -0000 DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGV4dCBSb25pIEV2ZW4gW21h aWx0bzpFdmVuLnJvbmlAaHVhd2VpLmNvbV0NCj4NCj5IaSwNCj5JIHdhbnQgdG8gY2xhcmlmeSB0 aGF0IGR1cmluZyB0aGUgSGlyb3NoaW1hIHNlc3Npb24gbXkgdmlldyB3YXMgdGhhdA0KPnN1cHBv cnQgZm9yIHNvbWUgaW5mcmFzdHJ1Y3R1cmUgYXNzdW1wdGlvbiB3aWxsIGJlIGJlbmVmaWNpYWwu IEkgaGFkDQo+b3RoZXIgdXNlIGNhc2Ugd2hlcmUgeW91IGhhdmUgYSB2aWRlbyBjb25mZXJlbmNp bmcgU0lQIGFwcGxpYW5jZSB0aGF0DQo+ZG9lcyBub3QgaGF2ZSBYTVBQIHN1cHBvcnQgaW4gYSBy b29tIHdpdGggYSBQQyB0aGF0IGRvZXMgdGhlIFhNUFANCj50YWxraW5nIHRvIGEgY2xpZW50IHRo YXQgZG9lcyBib3RoIFhNUFAgYW5kIFNJUC4gVGhlIGluZnJhc3RydWN0dXJlIGlzDQo+dGhpcyBj YXNlIHdpbGwgbmVlZCB0byBrbm93IHRoZSByZWxhdGlvbiBiZXR3ZWVuIHRoZSBhcHBsaWFuY2Ug YW5kIHRoZQ0KPlBDIHNpbWlsYXIgdG8gdGhlIGNhc2UgZGlzY3Vzc2VkIGhlcmUgd2hlcmUgYm90 aCBjbGllbnQgc2hhcmUgdGhlIHNhbWUNCj5jcmVkZW50aWFscywgdGhpcyBuZWVkIHRvIGJlIHN1 cHBvcnRlZCBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUgYW5kIHNvbWVob3cNCj5jb252ZXllZCB0byB0 aGUgY2xpZW50cy4NCj5UaGUgd2F5IEkgc2VlIGl0IGlzIHRoYXQgU2ltbydzIHZpZXcgYXMgd2Fz IHByZXNlbnRlZCBpbiBIaXJvc2hpbWEgaXMNCj50aGF0IHRoZSBjbGllbnRzIHdpbGwgbmVlZCB0 byBhc3N1bWUgdHdvIHNlcGFyYXRlIHNlcnZlcnMgd2l0aCBubw0KPnJlbGF0aW9ucyBhbmQgYW55 IGFzc3VtcHRpb24gb24gcmVsYXRpb24gYmV0d2VlbiB0aGUgc2VydmVycyBpcyBub3QgcGFydA0K Pm9mIHRoZSBjaGFydGVyLg0KDQpBICJkdWFsIHN0YWNrIiBTSVAvWE1QUCBjbGllbnQgc2hvdWxk IGJlIGFibGUgdG8gdGFsayBTSVAgdG8gYSBTSVAtb25seSBlbmRwb2ludCBhbmQgWE1QUCB0byBh biBYTVBQLW9ubHkgZW5kcG9pbnQuIFdoYXQgaXMgdGhhdCB5b3UgbmVlZCBpbiBhZGRpdGlvbiB0 byB0aGlzPyANCg0KU2ltbw0KDQo+VG8gc3VtbWFyaXplLCBJIHRoaW5rIHRoaXMgaXMgbm90IGEg cXVlc3Rpb24gb2Ygc2hhcmVkIGNyZWRlbnRpYWxzIGJ1dCBhDQo+cXVlc3Rpb24gaWYgdGhlIHNl bnRlbmNlICIgVGhlIGdvYWwgaXMgdG8gcmVseSBvbiBleGlzdGluZyBzZXJ2aWNlDQo+aW5mcmFz dHJ1Y3RyZSwgYW5kIG5ldyByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGltcG9zZWQgb25seSB0byB0 aGUNCj5lbmRwb2ludC4iIGlzIHBhcnQgb2YgdGhlIGNoYXJ0ZXIuDQo+DQo+Um9uaSBFdmVuDQo+ DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogRW1pbCBJdm92IFttYWls dG86ZW1pbEBzaXAtY29tbXVuaWNhdG9yLm9yZ10gT24gQmVoYWxmIE9mIEVtaWwNCj4+IEl2b3YN Cj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTQsIDIwMDkgNToyNiBQTQ0KPj4gVG86IFNpbW8u VmVpa2tvbGFpbmVuQG5va2lhLmNvbQ0KPj4gQ2M6IEV2ZW4ucm9uaUBodWF3ZWkuY29tOyBwa3l6 aXZhdEBjaXNjby5jb207IGRpc3BhdGNoQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW2Rpc3Bh dGNoXSBSZXZpc2VkIHByb3Bvc2VkIGNoYXJ0ZXIgZm9yIENvbWJpbmluZyBTSVAgYW5kDQo+PiBY TVBQDQo+Pg0KPj4gSGV5IFNpbW8sDQo+Pg0KPj4g0J3QsCAxNC4xMi4wOSAxNToxOSwgU2ltby5W ZWlra29sYWluZW5Abm9raWEuY29tINC90LDQv9C40YHQsDoNCj4+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tIEZyb206IGV4dCBSb25pIEV2ZW4NCj4+ID4+IFttYWlsdG86RXZlbi5yb25p QGh1YXdlaS5jb21dDQo+PiA+Pg0KPj4gPj4gVGhlIGN1cnJlbnQgcHJvcG9zZWQgY2hhcnRlciBy ZXF1aXJlcyBubyBkZXBlbmRlbmN5IG9uIHRoZSBzZXJ2ZXINCj4+ID4+IGluZnJhc3RydWN0dXJl LCBpZiB3ZSBjaGFuZ2UgaXQgdGhhbiB3ZSBuZWVkIHRvIGRpc2N1c3Mgb3RoZXINCj4+ID4+IGZ1 bmN0aW9uYWxpdHkgdGhhdCBtYXkgYmUgZGVwZW5kZW50IG9uIHN1cHBvcnQgaW4gdGhlDQo+PiA+ PiBpbmZyYXN0cnVjdHVyZS4NCj4+ID4+DQo+PiA+PiBGcm9tIHRoZSBwcm9wb3NlZCBjaGFydGVy OiAiIFRoZSBnb2FsIGlzIHRvIHJlbHkgb24gZXhpc3RpbmcNCj4+ID4+IHNlcnZpY2UgaW5mcmFz dHJ1Y3RyZSwgYW5kIG5ldyByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGltcG9zZWQgb25seQ0KPj4g Pj4gdG8gdGhlIGVuZHBvaW50LiINCj4+ID4NCj4+ID4gVGhpcyBpcyBjb3JyZWN0IGFuZCBhdCBs ZWFzdCBJIHdvdWxkIGxpa2UgdG8ga2VlcCBpdCB0aGF0IHdheS4NCj4+ID4gSG93ZXZlciwgaWYg dGhlIHNhbWUgY3JlZGVudGlhbHMgYXJlIHVzZWQgZm9yIGJvdGggU0lQIGFuZCBYTVBQLCBpdA0K Pj4gPiB3b3VsZCBtZWFuIHRoZSBTSVAgYW5kIFhNUFAgaW5mcmFzIHNoYXJlIHRoZSBzYW1lIGNy ZWRlbnRpYWxzDQo+PiA+IGRhdGFiYXNlLiBIb3cgdGhpcyBpcyBkb25lIChvciBpZiBhIHByb3Zp ZGVyIGRlY2lkZXMgdG8gZG8gdGhhdCBpbg0KPj4gPiB0aGUgZmlyc3QgcGxhY2UpIHNob3VsZCBi ZSBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBjaGFydGVyLg0KPj4gPg0KPj4gPiBXaGV0aGVyIGEgcHJv dG9jb2wgbWVjaGFuaXNtIHNob3VsZCBiZSBpbXBsZW1lbnRlZCBmb3IgaW5kaWNhdGluZyB0bw0K Pj4gPiB0aGUgY2xpZW50IHRoYXQgdGhlIHNhbWUgY3JlZGVudGlhbHMgY2FuIGFsc28gYmUgdXNl ZCBpbiB0aGUgb3RoZXINCj4+ID4gZG9tYWluIGlzIGFub3RoZXIgaXNzdWUuIEkgc2VlIHRoZXJl IG1pZ2h0IGJlIHZhbHVlIGluIHN1Y2ggYQ0KPj4gPiBtZWNoYW5pc20sIGFuZCBvbmUgcG9zc2li bGUgd2F5IG9mIGRvaW5nIHRoaXMgaXMgdG8gc2ltcGx5IHByb3ZpZGUNCj4+ID4gdGhlIHNhbWUg InJlYWxtIiB0byB0aGUgY2xpZW50LiBCdXQgdGhpcyBkb2Vzbid0IG5lY2Vzc2FyaWx5IGhhdmUg dG8NCj4+ID4gYmUgaW4gdGhlIGNoYXJ0ZXIgLSB3ZSBjYW4gc3RpbGwgZG9jdW1lbnQgaXQgaW4g dGhlIEktRCdzIGFuZCBSRkNzDQo+d2UNCj4+ID4gYXJlIHByb2R1Y2luZyBpZiBmb2xrcyBzZWUg dGhpcyBhcyBhIHVzZWZ1bCB0aGluZyB0byBkby4NCj4+DQo+PiBBcyBsb25nIGFzIHBlb3BsZSBk b24ndCBzZWUgc3VjaCBkb2N1bWVudGluZyAoaS5lLg0KPnJlY29tbWVuZGF0aW9ucy9iZXN0DQo+ PiBwcmFjdGljZXMgZGlyZWN0ZWQgdG93YXJkIHNlcnZlciBzaWRlIGRldmVsb3BlcnMgYW5kIG1h aW50YWluZXJzKSBhcyBhDQo+PiBjb250cmFkaWN0aW9uIHdpdGggdGhlIGFib3ZlIHF1b3RlIGZy b20gdGhlIGNoYXJ0ZXIsIHRoZW4gdGhhdCB3b3VsZA0KPj4gaW5kZWVkIGJlIGp1c3QgZmluZS4N Cj4+DQo+PiBFbWlsDQoNCg== From Even.roni@huawei.com Wed Dec 16 04:51:23 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7FF3A67EA for ; Wed, 16 Dec 2009 04:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTYBBwWftkLv for ; Wed, 16 Dec 2009 04:51:22 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BC4123A68A2 for ; Wed, 16 Dec 2009 04:51:21 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUQ008V7X0X6Q@szxga02-in.huawei.com> for dispatch@ietf.org; Wed, 16 Dec 2009 20:50:57 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUQ00168X0XW7@szxga02-in.huawei.com> for dispatch@ietf.org; Wed, 16 Dec 2009 20:50:57 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-122-36.red.bezeqint.net [79.181.122.36]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUQ0010KX0NIH@szxml01-in.huawei.com>; Wed, 16 Dec 2009 20:50:57 +0800 (CST) Date: Wed, 16 Dec 2009 14:47:34 +0200 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, emcho@sip-communicator.org Message-id: <038c01ca7e4d$f7828c70$e687a550$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acp80cDp8Ejk3fAuRD2caw6obJqwogAPZd8QAEmY9yAABdRZwA== References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <4B2658FB.50506@sip-communicator.org> <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:51:23 -0000 Simo Inline Roni > -----Original Message----- > From: Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] > Sent: Wednesday, December 16, 2009 11:56 AM > To: Even.roni@huawei.com; emcho@sip-communicator.org > Cc: pkyzivat@cisco.com; dispatch@ietf.org > Subject: RE: [dispatch] Revised proposed charter for Combining SIP and > XMPP >=20 >=20 >=20 > >-----Original Message----- > >From: ext Roni Even [mailto:Even.roni@huawei.com] > > > >Hi, > >I want to clarify that during the Hiroshima session my view was that > >support for some infrastructure assumption will be beneficial. I had > >other use case where you have a video conferencing SIP appliance that > >does not have XMPP support in a room with a PC that does the XMPP > >talking to a client that does both XMPP and SIP. The infrastructure = is > >this case will need to know the relation between the appliance and = the > >PC similar to the case discussed here where both client share the = same > >credentials, this need to be supported in the infrastructure and > somehow > >conveyed to the clients. > >The way I see it is that Simo's view as was presented in Hiroshima is > >that the clients will need to assume two separate servers with no > >relations and any assumption on relation between the servers is not > part > >of the charter. >=20 > A "dual stack" SIP/XMPP client should be able to talk SIP to a = SIP-only > endpoint and XMPP to an XMPP-only endpoint. What is that you need in > addition to this? The dual stack client need to know that these two clients are the same = user. For example start a XMPP chat and add the SIP video call. This is = not advertised by the remote XMPP client but by the infrastructure.=20 >From the other direction (two systems) it will involve starting chat = from XMPP and adding SIP video to the call by the XMPP client for = example by telling the other side or the SIP server to call the his SIP = client on the appliance. >=20 > Simo >=20 > >To summarize, I think this is not a question of shared credentials = but > a > >question if the sentence " The goal is to rely on existing service > >infrastructre, and new requirements should be imposed only to the > >endpoint." is part of the charter. > > > >Roni Even > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of = Emil > >> Ivov > >> Sent: Monday, December 14, 2009 5:26 PM > >> To: Simo.Veikkolainen@nokia.com > >> Cc: Even.roni@huawei.com; pkyzivat@cisco.com; dispatch@ietf.org > >> Subject: Re: [dispatch] Revised proposed charter for Combining SIP > and > >> XMPP > >> > >> Hey Simo, > >> > >> =D0=9D=D0=B0 14.12.09 15:19, Simo.Veikkolainen@nokia.com = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > >> >> -----Original Message----- From: ext Roni Even > >> >> [mailto:Even.roni@huawei.com] > >> >> > >> >> The current proposed charter requires no dependency on the = server > >> >> infrastructure, if we change it than we need to discuss other > >> >> functionality that may be dependent on support in the > >> >> infrastructure. > >> >> > >> >> From the proposed charter: " The goal is to rely on existing > >> >> service infrastructre, and new requirements should be imposed > only > >> >> to the endpoint." > >> > > >> > This is correct and at least I would like to keep it that way. > >> > However, if the same credentials are used for both SIP and XMPP, > it > >> > would mean the SIP and XMPP infras share the same credentials > >> > database. How this is done (or if a provider decides to do that = in > >> > the first place) should be out of scope of this charter. > >> > > >> > Whether a protocol mechanism should be implemented for indicating > to > >> > the client that the same credentials can also be used in the = other > >> > domain is another issue. I see there might be value in such a > >> > mechanism, and one possible way of doing this is to simply = provide > >> > the same "realm" to the client. But this doesn't necessarily have > to > >> > be in the charter - we can still document it in the I-D's and = RFCs > >we > >> > are producing if folks see this as a useful thing to do. > >> > >> As long as people don't see such documenting (i.e. > >recommendations/best > >> practices directed toward server side developers and maintainers) = as > a > >> contradiction with the above quote from the charter, then that = would > >> indeed be just fine. > >> > >> Emil From pkyzivat@cisco.com Wed Dec 16 06:33:35 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1633A67B3 for ; Wed, 16 Dec 2009 06:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA8r61jMTtI4 for ; Wed, 16 Dec 2009 06:33:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2AE9F3A67EE for ; Wed, 16 Dec 2009 06:33:34 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGAKd+KEurRN+J/2dsb2JhbACYeaYMlxGCLwSBeASNTg X-IronPort-AV: E=Sophos;i="4.47,406,1257120000"; d="scan'208";a="280453455" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 16 Dec 2009 14:33:20 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBGEXJBW014582; Wed, 16 Dec 2009 14:33:20 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:33:19 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:33:19 -0500 Message-ID: <4B28EFAF.7060203@cisco.com> Date: Wed, 16 Dec 2009 09:33:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Shockey References: <015b01ca7dc0$becf4d10$3c6de730$@us> In-Reply-To: <015b01ca7dc0$becf4d10$3c6de730$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 14:33:19.0406 (UTC) FILETIME=[B64CD4E0:01CA7E5C] Cc: 'IETF DISPATCH list' Subject: Re: [dispatch] E2M: Proposed Charter (draft version only) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 14:33:35 -0000 Richard Shockey wrote: > +1 in support of this charter > > As the editor of the ENUM draft on CNAM frankly I was a bit appalled at what > I was forced to go through to try and make this work to the satisfaction of > some in the RAI directorate and the IESG. The result was nothing if not a > total kludge (see the draft) . It would have been much simpler to add the > parameter to the SIP URI but there are those that have a layer 10 conviction > that only routing information can be in the URI... but then I couldn't use > the DATA URI since that was too much like TXT RR's etc. So you have to > invent a total kludge PSTN PSTNDATA uri I'm not sure if I am one of "those that have a layer 10 conviction" or not. I did argue against adding a parameter to the sip URI, not because of a general objection to non-routing information in a URI, but rather an objection to spurious information in a URI type that *is* intended for routing. I recommended the data URI, and never understood the arguments against it. This proposal seems like a reasonable way forward, modulo my limited knowledge of DNS. Thanks, Paul > http://tools.ietf.org/html/draft-ietf-enum-cnam-08 > > The point here is, BTW, that phone numbers are not going away. Not now not > ever, some folks just need to get over that issue ASAP. 99.9999 % of all SIP > transactions in the field involve phone numbers and there needs to be > simpler and more effective way of expressing and or looking up metadata > associated with those identifiers. > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Bernie Hoeneisen >> Sent: Tuesday, December 15, 2009 2:29 PM >> To: IETF DISPATCH list >> Subject: [dispatch] E2M: Proposed Charter (draft version only) >> >> Hi, >> >> As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for an >> E2M >> charter (draft) for discussion on this mailing list. >> >> Have fun! >> >> cheers, >> Bernie >> >> --- >> >> E.164 to Metadata (E2M) (proposed charter / draft state) >> ----------------------- >> >> Last Modified: 2009-12-15 >> >> Additional information is available at tools.ietf.org/wg/e2m >> [not yet in use] >> >> >> Chair(s): >> >> * TBA >> >> Real-time Applications and Infrastructure Area Director(s): >> >> * Robert Sparks >> * Cullen Jennings >> >> Real-time Applications and Infrastructure Area Advisor: >> >> * Cullen Jennings >> >> >> Mailing Lists: >> >> General Discussion: e2m@ietf.org [not yet in use] >> To Subscribe: e2m-request@ietf.org [not yet in use] >> In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/e2m/index.html >> [not yet in use] >> >> >> Description of Working Group: >> >> Abstract >> >> E.164 to Metadata (E2M) will use of the Domain Name System (DNS) >> for resolving E.164 numbers into metadata to provide information >> about E.164 numbers in cases where E.164 Number to URI Mapping >> (ENUM) can not be used. >> >> >> Background >> >> ENUM provides an identifier mapping mechanism to map E.164 numbers >> to Uniform Resource Identifiers (URIs) using the DNS. >> >> Thus, ENUM can be used to look up the services associated with an >> E.164 number. However, it is controversial whether or not the >> result >> of an ENUM lookup should always be intended to establish a >> communications session using the URI found in the corresponding >> Naming Authority Pointer (NAPTR) DNS Resource Record (RR). >> >> >> Problem Statement >> >> Several proposals for Enumservice registrations do not fulfill the >> above mentioned interpretation, which suggests that an ENUM lookup >> should always be intended to result in a communications session. >> These proposals are therefore virtually locked in the process. >> Such proposals include (but are not limited to) Enumservices for >> 'cnam' to provide information about the calling party name, >> 'unused' to provide a hint that a number is not in use, and >> 'send-n' to describe the structure of an ENUM tree. >> >> Another issue is that the result of an ENUM (E2U) lookup always >> needs to be an URI, which unnecessarily complicates simple >> mappings. >> >> The authors of such Enumservice proposals tried to circumvent the >> issues by introducing the 'data' URI scheme or inventing >> completely >> new URI schemes, with limited success however. The main objection >> remained that an ENUM lookup should always result in a URI >> intended >> to establish a communications session. >> >> Proposal >> >> The E2M Working Group is chartered to develop a new Dynamic >> Delegation Discovery System (DDDS) application E2M, which can be >> used with DNS NAPTR RRs for resolving E.164 numbers into metadata. >> The resulting metadata can be used (for example) to provide hints >> about properties of certain ENUM domains or to provide information >> that can be used as attributes of an E.164 number. >> >> E2M will provide the means for services related to E.164 numbers >> that do not fit into the concept of ENUM (E2U), and thus a >> way forward for such existing ENUM WG documents in the queue. >> >> Along with the E2M DDDS application a new IANA registry will be >> specified for registration of E2M services. The registration >> policy >> shall be Expert Review and Specification Required (see RFC 5226), >> similarly as specified for Enumservice registrations. >> >> The E2M specifications shall reuse a much as possible from the >> ENUM >> DDDS and its IANA registry specification. >> >> The E2M Working Group may take on further proposals for E2M >> service >> registrations (e.g. send-n) until the IANA registration for E2M >> services is approved by the IESG. >> >> >> Goals and Milestones: >> >> Aug 2010 Submit Internet Draft(s) for the E2M DDDS application >> and >> its IANA registry specification >> >> Dec 2010 Submit 'cnam' and 'unused' as E2M service registrations >> (Informational) >> >> XXX 2011 Close the E2M Working Group (or recharter) >> >> >> Internet-Drafts: >> >> http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-01 >> http://tools.ietf.org/html/draft-ietf-enum-unused-04 >> http://tools.ietf.org/html/draft-ietf-enum-cnam-08 >> (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) >> >> >> Request For Comments: >> >> None >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mary.barnes@nortel.com Wed Dec 16 12:05:30 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708C83A67F3 for ; Wed, 16 Dec 2009 12:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWgTWSGF6qas for ; Wed, 16 Dec 2009 12:05:29 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E8BFE3A6900 for ; Wed, 16 Dec 2009 12:05:28 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBGK59P22235; Wed, 16 Dec 2009 20:05:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Dec 2009 14:06:28 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-77 DISPATCH WG deadlines Thread-Index: AcohwNkciiguS2xuQiuKUNJpbaNnbQAuvWPQFwNk07A= From: "Mary Barnes" To: Cc: rai-ads@tools.ietf.org Subject: [dispatch] IETF-77 DISPATCH WG deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:05:30 -0000 Hi all, The following summarizes the deadlines for discussing topics in DISPATCH prior to the WG session at IETF-77. =20 We will again work within the deadlines for BoFs: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77 This provides enough time to dispatch topics prior to the meeting as appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs, mailing lists, etc. Thus, allowing us to have more focused and constructive discussions on a smaller set of topics prior to the WG session. =20 Jan 18th, 2010. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. ------------------------------------------------------------------------ -------------------- This will help folks with similar topics to work together before the meeting. If a preliminary charter proposal is available at this point, please include it. Note: Jan 25th is BoF proposal request date.=20 Feb 1st, 2010. Cutoff for charter proposals for topics.=20 -------------------------------------------------------------- A charter proposal must consist of a minimum of a problem statement and at least one milestone/deliverable. This deadline will allow time for consideration of proposals that could potentially be "dispatched" prior to the WG session. Feb 8th, 2010. Topics that are to be the focus of IETF-77 are announced. [AD BoF approval date] ------------------------------------------------------------------------ The idea here is to focus the discussion over the weeks preceding IETF-77 on these main topics, noting that any new or updates to any documents are due 3-4 weeks later. This will ensure we have constructive discussions before the meeting and are actually able to determine consensus as to where work should be progressed (e.g., separate BoF, a new WG, an existing WG, individual document, etc.) at IETF-77. Note, that the exact disposition for a topic may (per the usual process) require follow-up and confirmation by the ADS and/or IESG (e.g., for a new WG, Bof, individually sponsored document, etc.) or with another WG to ensure agreement with the DISPATCH WG consensus for the topic. March 1st, 2010. -00 draft deadline. ----------------------------------- March 8th, 2010. Draft deadline. -------------------------------- As discussed previously, the intention is not necessarily to preclude folks submitting documents on other topics, however, it is very unlikely there would be agenda time allocated to documents/topics submitted after the deadlines. We can include one or two slides on these topics in the DISPATCH WG chair charts so that the authors can gather other interested parties to contribute to the work.=20 Regards, Mary and Gonzalo DISPATCH WG co-chairs=20 From gonzalo.camarillo@ericsson.com Thu Dec 17 01:03:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C073A67B0 for ; Thu, 17 Dec 2009 01:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YkL7YySeo5f for ; Thu, 17 Dec 2009 01:03:03 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9C9EE3A693F for ; Thu, 17 Dec 2009 01:03:02 -0800 (PST) X-AuditID: c1b4fb3e-b7bc3ae000002f8e-21-4b29f0b38b29 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D3.B3.12174.3B0F92B4; Thu, 17 Dec 2009 09:49:55 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 09:49:45 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 09:49:43 +0100 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8A14B233F; Thu, 17 Dec 2009 10:49:43 +0200 (EET) Message-ID: <4B29F0A7.5070400@ericsson.com> Date: Thu, 17 Dec 2009 10:49:43 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4B0EBC63.3010007@ericsson.com> <4B1AAF15.7080804@ericsson.com> <4B1CAD0C.7010508@ericsson.com> In-Reply-To: <4B1CAD0C.7010508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2009 08:49:45.0452 (UTC) FILETIME=[E1D6D2C0:01CA7EF5] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Draft minutes of the main DISPATCH session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 09:03:04 -0000 Hi, the minutes now include all the ad-hoc meetings. They should be complete now. http://www.ietf.org/proceedings/09nov/minutes/dispatch.txt Thanks to all the chairs of the ad-hocs for providing us with their minutes. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, > > we have now added links to the audio files from the main session. Big > thanks to Vijay for preparing the files! > > Cheers, > > Gonzalo > > Gonzalo Camarillo wrote: >> Hi, >> >> we have already added the minutes of two of the three ad-hoc meetings. >> You can fetch them from the same URI (make sure you refresh the page >> in your browser). As soon as we receive the minutes of the remaining >> ad-hoc, we will add them as well. >> >> Cheers, >> >> Gonzalo >> >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> here you have the draft minutes of the main DISPATCH session. >>> >>> http://www.ietf.org/proceedings/09nov/minutes/dispatch.txt >>> >>> Comments are welcome. >>> >>> We are working with the cochairs of the three ad-hoc meetings we had >>> in Japan to prepare the minutes of those meetings as well (the >>> minutes will be based on the raw notes that have already been >>> distributed). As soon as those are ready, we will append them to the >>> main DISPATCH minutes above so that everything is archived at the IETF. >>> >>> Cheers, >>> >>> Gonzalo >>> DISPATCH co-chair >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Simo.Veikkolainen@nokia.com Thu Dec 17 04:35:45 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADA63A68EF for ; Thu, 17 Dec 2009 04:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLTdpp2ph2G8 for ; Thu, 17 Dec 2009 04:35:44 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 15FF33A6850 for ; Thu, 17 Dec 2009 04:35:43 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBHCYuvp028436; Thu, 17 Dec 2009 14:35:19 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 14:34:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 14:34:07 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 17 Dec 2009 13:34:01 +0100 From: To: , Date: Thu, 17 Dec 2009 13:33:59 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: Acp80cDp8Ejk3fAuRD2caw6obJqwogAPZd8QAEmY9yAABdRZwAAxi3EQ Message-ID: References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <4B2658FB.50506@sip-communicator.org> <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> <038c01ca7e4d$f7828c70$e687a550$%roni@huawei.com> In-Reply-To: <038c01ca7e4d$f7828c70$e687a550$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2009 12:34:07.0243 (UTC) FILETIME=[39B11DB0:01CA7F15] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 12:35:45 -0000 Um9uaSwNCg0KPj4gQSAiZHVhbCBzdGFjayIgU0lQL1hNUFAgY2xpZW50IHNob3VsZCBiZSBhYmxl IHRvIHRhbGsgU0lQIHRvIGEgU0lQLQ0KPm9ubHkNCj4+IGVuZHBvaW50IGFuZCBYTVBQIHRvIGFu IFhNUFAtb25seSBlbmRwb2ludC4gV2hhdCBpcyB0aGF0IHlvdSBuZWVkIGluDQo+PiBhZGRpdGlv biB0byB0aGlzPw0KPlRoZSBkdWFsIHN0YWNrIGNsaWVudCBuZWVkIHRvIGtub3cgdGhhdCB0aGVz ZSB0d28gY2xpZW50cyBhcmUgdGhlIHNhbWUNCj51c2VyLiBGb3IgZXhhbXBsZSBzdGFydCBhIFhN UFAgY2hhdCBhbmQgYWRkIHRoZSBTSVAgdmlkZW8gY2FsbC4gVGhpcyBpcw0KPm5vdCBhZHZlcnRp c2VkIGJ5IHRoZSByZW1vdGUgWE1QUCBjbGllbnQgYnV0IGJ5IHRoZSBpbmZyYXN0cnVjdHVyZS4N Cj4NCj5Gcm9tIHRoZSBvdGhlciBkaXJlY3Rpb24gKHR3byBzeXN0ZW1zKSBpdCB3aWxsIGludm9s dmUgc3RhcnRpbmcgY2hhdA0KPmZyb20gWE1QUCBhbmQgYWRkaW5nIFNJUCB2aWRlbyB0byB0aGUg Y2FsbCBieSB0aGUgWE1QUCBjbGllbnQgZm9yDQo+ZXhhbXBsZSBieSB0ZWxsaW5nIHRoZSBvdGhl ciBzaWRlIG9yIHRoZSBTSVAgc2VydmVyIHRvIGNhbGwgdGhlIGhpcyBTSVANCj5jbGllbnQgb24g dGhlIGFwcGxpYW5jZS4NCj4NCg0KTGV0IG1lIHNlZSBpZiBJIHVuZGVyc3Rvb2QgeW91IGNvcnJl Y3RseS4gSXQgc291bmRzIHlvdSBhcmUgbG9va2luZyBmb3IgdHdvIHVzZSBjYXNlczoNCg0KMSkg dG8gYWRkIFNJUCB2b2ljZS92aWRlbyBvciBYTVBQIGNoYXQgZnJvbSBhbiBpbnRlZ3JhdGVkIGVu ZHBvaW50IGV2ZW4gdGhvdWdoIHRoZSBvdGhlciBlbmRwb2ludCBpcyBTSVAtb25seSBvciBYTVBQ LW9ubHkNCg0KMikgdG8gYWRkIFNJUCB2b2ljZS92aWRlbyBvciBYTVBQIGNoYXQgZnJvbSBhIFhN UFAtb25seSBvciBTSVAtb25seSBlbmRwb2ludCwgcmVzcGVjdGl2ZWx5Lg0KDQpGb3IgMiksIEkg ZG9uJ3Qgc2VlIGhvdyB0aGF0IGlzIHBvc3NpYmxlIHdpdGhvdXQgY2hhbmdlcyBpbiB0aGUgY2xp ZW50IHNpZGUuIA0KDQpGb3IgMSksIHlvdSB3b3VsZCBuZWVkIHRvIGJlIGFibGUsIGZyb20gYSAi ZHVhbCBzdGFjayIgZW5kcG9pbnQsIHRvIHRlbGwgdGhlIFhNUFAgc2VydmVyIHRvIHN0YXJ0IGFu IFhNUFAgc2Vzc2lvbiwgb3IgdGhlIFNJUCBzZXJ2ZXIgdG8gbWFrZSBhIFNJUCBjYWxsIHRvIHRo ZSBzYW1lIHVzZXIgeW91IGFscmVhZHkgaGF2ZSBhIFNJUCBvciBYTVBQIHNlc3Npb24gd2l0aC4g V2hpbGUgcHJvYmFibHkgZG9hYmxlLCB0aGlzIGlzIG5vdCB3aGF0IHdlIGhhZCBpbiBtaW5kIGZv ciB0aGlzIHdvcmsuDQoNClNpbW8NCg== From Even.roni@huawei.com Thu Dec 17 05:01:24 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390C33A6AB4 for ; Thu, 17 Dec 2009 05:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEIaHvSAvMEA for ; Thu, 17 Dec 2009 05:01:23 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F18933A672E for ; Thu, 17 Dec 2009 05:01:22 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00F8FS5MRQ@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 17 Dec 2009 21:00:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00FIDS5MKF@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 17 Dec 2009 21:00:58 +0800 (CST) Received: from windows8d787f9 (bzq-109-65-50-133.red.bezeqint.net [109.65.50.133]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS0032ZS5CK6@szxml01-in.huawei.com>; Thu, 17 Dec 2009 21:00:58 +0800 (CST) Date: Thu, 17 Dec 2009 14:57:36 +0200 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, emcho@sip-communicator.org Message-id: <03fd01ca7f18$8772c9b0$96585d10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acp80cDp8Ejk3fAuRD2caw6obJqwogAPZd8QAEmY9yAABdRZwAAxi3EQAAE+aoA= iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <4B20B43E.9030200@sip-communicator.org> <4B2134B5.30409@stpeter.im> <4B21406E.60605@sip-communicator.org> <1260471307.25475.1912.camel@scott> <4B2146C2.6060803@sip-communicator.org> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <4B2658FB.50506@sip-communicator.org> <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> <038c01ca7e4d$f7828c70$e687a550$%roni@huawei.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:01:24 -0000 Simo, The other user has two endpoints, one is a video conferencing appliance and the other is a PC running XMPP client. The user will register his XMPP and SIP capability using the two endpoints in the infrastructure Roni > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Thursday, December 17, 2009 2:34 PM > To: Even.roni@huawei.com; emcho@sip-communicator.org > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Revised proposed charter for Combining SIP and > XMPP > > Roni, > > >> A "dual stack" SIP/XMPP client should be able to talk SIP to a SIP- > >only > >> endpoint and XMPP to an XMPP-only endpoint. What is that you need in > >> addition to this? > >The dual stack client need to know that these two clients are the same > >user. For example start a XMPP chat and add the SIP video call. This > is > >not advertised by the remote XMPP client but by the infrastructure. > > > >From the other direction (two systems) it will involve starting chat > >from XMPP and adding SIP video to the call by the XMPP client for > >example by telling the other side or the SIP server to call the his > SIP > >client on the appliance. > > > > Let me see if I understood you correctly. It sounds you are looking for > two use cases: > > 1) to add SIP voice/video or XMPP chat from an integrated endpoint even > though the other endpoint is SIP-only or XMPP-only > > 2) to add SIP voice/video or XMPP chat from a XMPP-only or SIP-only > endpoint, respectively. > > For 2), I don't see how that is possible without changes in the client > side. > > For 1), you would need to be able, from a "dual stack" endpoint, to > tell the XMPP server to start an XMPP session, or the SIP server to > make a SIP call to the same user you already have a SIP or XMPP session > with. While probably doable, this is not what we had in mind for this > work. > > Simo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From L.Liess@telekom.de Thu Dec 17 07:43:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F94D3A6B5C for ; Thu, 17 Dec 2009 07:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3kwpm0Lf0Mh for ; Thu, 17 Dec 2009 07:43:37 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 2EFAA3A68B7 for ; Thu, 17 Dec 2009 07:43:37 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 17 Dec 2009 16:43:13 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 16:43:13 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Dec 2009 16:43:11 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alert-Info URN charter issue Thread-Index: Acp/L6MT+9ZyNw6QTVaSquojGWm2Pw== From: To: , , X-OriginalArrivalTime: 17 Dec 2009 15:43:13.0845 (UTC) FILETIME=[A4CB2E50:01CA7F2F] Cc: R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:43:38 -0000 Hi, During the Alert-Info URN discussion in Hiroshima we had consensus that = there is interest in chartering a mini-WG on Alert-Info URNs. However, = we didn't come to an agreement about whether or not we need to decide = before chartering if the Alert-Info URNs must be semantic. We need to = clarify this issue before submitting the charter proposal for Anaheim.=20 =20 Some thoughts on this:=20 - The decision wether or not we allow non-semantic Alert-Info URNs is = tightly coupled with which problems/use cases we want to solve. The = problem to be solved /use cases must, as far as I know, be decided = before chartering. =20 - The Alert-Info URNs for use cases as call waiting and other services, = country ringback, priority ringing, are semantic anyway. So these use = cases are definitively in the charter.=20 - The critical use cases, for which we need non-semantic, = rendering-oriented Alert-Info URNs, are ringing tones used in = PBX-systems (e.g. "short", as described in =A74.3.8 of the draft) and in = local exchanges in some countries (e.g. the TIA ring tones described by = Adam in = http://www.ietf.org/mail-archive/web/bliss/current/msg01020.html, which = is not in the draft). In these use cases, the Alert-Info URNs are not = transmitted end-to-end, as, e.g. in case of country ringback tones, but = are sent by the PBX-system or local exchange to an end device within its = own domain. In most cases, we can expect that the end device was = configured by the user or service provider how to handle the = rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. - Rendering-oriented ring tones as described above are use cases which = we encounter today and people will be implement them in some way. If we = do not provide a standard which can be used for the implementation, = people will provide proprietary, non-interoperable solutions. For this = reason, I wouldn't like that the Alert-Info URN scheme we are going to = define can not be used to implement these use cases. This does not imply = that we should also define Alert-Info URN identifiers for all these = cases, but we should at least define the scheme which can be used by = other people to define the specific identifiers. =20 Based on the thoughts above, I would propose to handle the issue as = follows: 1) Include into the charter, as one of the problems to be solved: = "special ring tones for incoming calls (used in enterprise networks and = in some countries) when the proxy and the UAs are from different vendors = with no external ring file being used" =20 =20 2) In the draft, define a requirement which states something like that: - Alert-Info URNs must be semantic whenever they are used across = different domains or if the sender has no reason to assume that the = receiver has the same understanding of non-semantic Alert-Info URNs.=20 - Non-semantic, rendering-oriented Alert-Info URNs may be used = inside closed environements, when there are predefined rules which = define the semantic of a specific rendering and the sender can expect = that the receiver is able to understand the rendering-oriented = Alert-Info URNs. If an UA receives an Alert-Info URN it does not = understand, it ignores the Alert-Info URN.=20 Is this an acceptable proposal or does anyone have a better idea how to = handle this issue?=20 Thanks a lot Laura From john.elwell@siemens-enterprise.com Thu Dec 17 08:13:32 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747DA3A6861 for ; Thu, 17 Dec 2009 08:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-i39jYxseJz for ; Thu, 17 Dec 2009 08:13:29 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D4BD63A67FE for ; Thu, 17 Dec 2009 08:13:28 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-319727; Thu, 17 Dec 2009 17:13:13 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EE1531EB825C; Thu, 17 Dec 2009 17:13:12 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 17 Dec 2009 17:13:13 +0100 From: "Elwell, John" To: "L.Liess@telekom.de" , "dispatch@ietf.org" , "adam@nostrum.com" Date: Thu, 17 Dec 2009 17:13:11 +0100 Thread-Topic: Alert-Info URN charter issue Thread-Index: Acp/L6MT+9ZyNw6QTVaSquojGWm2PwAA113A Message-ID: References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "R.Jesske@telekom.de" , "Martin.Huelsemann@telekom.de" Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:13:33 -0000 Laura, I suspect the wording you propose below goes somewhat beyond what would be = appropriate for charter text. However, you are correct in that the charter = needs to say something about semantic versus non-semantic tones. In Hiroshima I heard a justification for non-semantic tones that is not cap= tured below: cases where a TDM gateway detects a certain tone pattern and c= an only convey in SIP some characteristic of that pattern (e.g., "short"), = rather than a specific meaning. This sounds like a more compelling use case= for non-semantic tones than what is described below. John > -----Original Message----- > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: 17 December 2009 15:43 > To: dispatch@ietf.org; Elwell, John; adam@nostrum.com > Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com;=20 > alan@sipstation.com; R.Jesske@telekom.de; Martin.Huelsemann@telekom.de > Subject: Alert-Info URN charter issue >=20 >=20 > Hi, >=20 > During the Alert-Info URN discussion in Hiroshima we had=20 > consensus that there is interest in chartering a mini-WG on=20 > Alert-Info URNs. However, we didn't come to an agreement=20 > about whether or not we need to decide before chartering if=20 > the Alert-Info URNs must be semantic. We need to clarify=20 > this issue before submitting the charter proposal for Anaheim.=20 > =20 > Some thoughts on this:=20 > - The decision wether or not we allow non-semantic=20 > Alert-Info URNs is tightly coupled with which problems/use=20 > cases we want to solve. The problem to be solved /use cases =20 > must, as far as I know, be decided before chartering. =20 >=20 > - The Alert-Info URNs for use cases as call waiting and=20 > other services, country ringback, priority ringing, are=20 > semantic anyway. So these use cases are definitively in the charter.=20 >=20 > - The critical use cases, for which we need non-semantic,=20 > rendering-oriented Alert-Info URNs, are ringing tones used in=20 > PBX-systems (e.g. "short", as described in =A74.3.8 of the=20 > draft) and in local exchanges in some countries (e.g. the TIA=20 > ring tones described by Adam in=20 > http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht > ml, which is not in the draft). In these use cases, the=20 > Alert-Info URNs are not transmitted end-to-end, as, e.g. in=20 > case of country ringback tones, but are sent by the=20 > PBX-system or local exchange to an end device within its own=20 > domain. In most cases, we can expect that the end device was=20 > configured by the user or service provider how to handle the=20 > rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. >=20 > - Rendering-oriented ring tones as described above are use=20 > cases which we encounter today and people will be implement=20 > them in some way. If we do not provide a standard which can=20 > be used for the implementation, people will provide=20 > proprietary, non-interoperable solutions. For this reason, I=20 > wouldn't like that the Alert-Info URN scheme we are going to=20 > define can not be used to implement these use cases. This=20 > does not imply that we should also define Alert-Info URN=20 > identifiers for all these cases, but we should at least=20 > define the scheme which can be used by other people to define=20 > the specific identifiers. =20 >=20 >=20 > Based on the thoughts above, I would propose to handle the=20 > issue as follows: >=20 > 1) Include into the charter, as one of the problems to be=20 > solved: "special ring tones for incoming calls (used in=20 > enterprise networks and in some countries) when the proxy and=20 > the UAs are from different vendors with no external ring file=20 > being used" =20 > =20 > 2) In the draft, define a requirement which states something=20 > like that: > - Alert-Info URNs must be semantic whenever they are=20 > used across different domains or if the sender has no reason=20 > to assume that the receiver has the same understanding of=20 > non-semantic Alert-Info URNs.=20 > - Non-semantic, rendering-oriented Alert-Info URNs may=20 > be used inside closed environements, when there are=20 > predefined rules which define the semantic of a specific=20 > rendering and the sender can expect that the receiver is able=20 > to understand the rendering-oriented Alert-Info URNs. If an=20 > UA receives an Alert-Info URN it does not understand, it=20 > ignores the Alert-Info URN.=20 >=20 >=20 > Is this an acceptable proposal or does anyone have a better=20 > idea how to handle this issue?=20 >=20 > Thanks a lot > Laura > = From adam@nostrum.com Thu Dec 17 08:33:55 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E7D3A6962 for ; Thu, 17 Dec 2009 08:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwzY5oG+MFvs for ; Thu, 17 Dec 2009 08:33:54 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2A5AA3A6861 for ; Thu, 17 Dec 2009 08:33:53 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nBHGXWhi032067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 10:33:32 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B2A5D5C.6090705@nostrum.com> Date: Thu, 17 Dec 2009 10:33:32 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:33:55 -0000 > > I would propose to handle the issue as follows: > > 1) Include into the charter, as one of the problems to be solved: "special ring tones for incoming calls (used in enterprise networks and in some countries) when the proxy and the UAs are from different vendors with no external ring file being used" > > 2) In the draft, define a requirement which states something like that: > - Alert-Info URNs must be semantic whenever they are used across different domains or if the sender has no reason to assume that the receiver has the same understanding of non-semantic Alert-Info URNs. > - Non-semantic, rendering-oriented Alert-Info URNs may be used inside closed environements, when there are predefined rules which define the semantic of a specific rendering and the sender can expect that the receiver is able to understand the rendering-oriented Alert-Info URNs. If an UA receives an Alert-Info URN it does not understand, it ignores the Alert-Info URN. > > > Is this an acceptable proposal or does anyone have a better idea how to handle this issue? > I like this approach. Depending on how we end up defining combinations of various aspects of ring/ringback tones, the final sentance may end up reading something like "...it ignores the portions of the Alert-Info URN that it does not understand," but I don't think that's a fundamental change to your proposal. I'd also point out, on point 1, that the closed environments in which rendering-oriented ringtones may apply extends beyond enterprises and specific countries. It can also apply, for example, when mapping from any legacy protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the edge of a network. /a From gonzalo.camarillo@ericsson.com Thu Dec 17 09:09:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A059E3A68E7 for ; Thu, 17 Dec 2009 09:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl8HJgGIHxlX for ; Thu, 17 Dec 2009 09:09:09 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 72E613A68DF for ; Thu, 17 Dec 2009 09:09:08 -0800 (PST) X-AuditID: c1b4fb3e-b7bc3ae000002f8e-6c-4b2a55a65440 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 12.FF.12174.6A55A2B4; Thu, 17 Dec 2009 17:00:39 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 17:00:32 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 17:00:32 +0100 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0C4D8233F; Thu, 17 Dec 2009 18:00:32 +0200 (EET) Message-ID: <4B2A559F.9040606@ericsson.com> Date: Thu, 17 Dec 2009 18:00:31 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Volker Hilt References: <1260393285.4277.31.camel@khone.us.nortel.com> In-Reply-To: <1260393285.4277.31.camel@khone.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2009 16:00:32.0322 (UTC) FILETIME=[0FC63220:01CA7F32] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] XML questions about draft-ietf-sipping-media-policy-dataset-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:09:10 -0000 Hi Volker, could you please submit 08 per Dale's email below so that people on this list can follow the discussions? Right now, the last revision that was submitted is 07: http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-07 Thanks, Gonzalo Dale Worley wrote: > I've edited my questions about the XML in > draft-ietf-sipping-media-policy-dataset-08 into better order. They are > appended to this message. > > Dale > ----------------------------------------------------------------------------- > This is based on a copy of the > draft-ietf-sipping-media-policy-dataset-08 draft, which I have in a > private directory. Apparently, the -08 version was never published. > I assume that the authors have an archival copy of -08. The MD5 of my > copy of the text version of -08 (with LF as EOL) is > dfd01da655ee324727a0f0fbe6ff69a8. > > - Section 1 > > Are merging rules still needed? We are no longer using > session-policy-dataset, which required merging, but IIRC someone > mentioned an additional need for merging. > > - Section 4.2 > > Section 4.2 contains: > > If a UA has an SDP offer as well as an answer [RFC3264] and wants to > create a session info document, the UA MUST use the answer to fill in > the elements of the session info document except for the remote-host- > port and local-host-port elements, which are taken from the remote > and local session description respectively. The local session > description is the one created locally by the UA (i.e., the offer if > the UA has initiated the offer/answer exchange). The remote session > description is the one received from the remote UA. > > If a UA has an SDP offer as well as an answer [RFC3264] and wants to > create a session info document, the UA MUST use the answer to fill in > the elements of the session info document except for the local-host-port > and remote-host-port elements, which are taken from the SDP generated > by the UA and the SDP received by the UA, respectively (regardless of > which is the offer and which is the answer). > > However, this process doesn't seem to allow for the possibility that > the locally-provided and remote-provided SDP may differ. (Although I > think the relevant differences are restricted to which codecs may be > used.) It seems that directionality attributes could/should be used > to have the media-policy specify the admitted codecs in each direction > appropriately. > > The specification of codecs in SDP is strange in that an answer may > contain codecs that are not given in the offer, but they are not > usable in the session. How should they be encoded in session-info? > > Section 4.2 seems to envision that an offer SDP can be mapped into a > media-policy, which can then be restricted or subsetted to give a new > media-policy, which can then be translated into an answer SDP. But > the transformation of SDP into media-policy XML seems to lose the > sequencing of the m= lines, in that there is no semantics specified > for the elements of a media-policy. Perhaps the intention is > that the elements correspond in order to the m= lines, but > that does not seem to be stated. > > Note that SDP can contain zero m= lines, which would seem to map to a > with a with no . But that is not > allowed by 6.3. > > - Section 5 > > Perhaps this change of wording would be clearer: > > Session policy documents describe a policy for SIP sessions. Session > policy documents are independent of >>any<< specific session description > and express general policies for SIP sessions. > > - Section 5.1 > > The element is not being used any more. > > - Section 6.2 > > Section 6.2 says that at least one codec must be allowed per media > type (see second sentence), but the correspondence between codec and > media type isn't explicit, and it would be a difficult validity > constraint to verify. Also, the text does not specify that we're only > concerned with media types that are admitted by the > element. And worse, what if the are a set-complement > construction (excluded-policy="allow"), in which case the set of > admitted media-types is not knowable? I would suggest removing the > restriction, and understanding that an allowed media-type with no > allowable codecs is unusable in practice. > > - Section 6.2.1.1 > > The and elements want to specify the codec via a > mime-type, but that isn't what SDP uses. The translation between the > two is described in RFC 4855 section 3, which should be referenced. > > - Section 6.3.1 > > How are 0 port values encoded? Semantically, it identifies a > "sendonly" mode. Should it be encoded as a zero value of > or (better) by appropriate direction attributes. > In any case, this should be specified clearly to avoid interoperation > problems. > > - Section 6.4 > > Section 6.4 uses the phrase "sessions a UA may set up in parallel". > Does this refer to the set of sessions for a single dialog? Or the > set of all sessions of all dialogs that the UA is participating in at > one time? > > - Section 6.10 > > Do we want to be subordinate to ? This is > arguably a layer violation: and could be > siblings under an element that declares that the policy applies to the > context. This allows to have defined semantics, but > allowing its containing element/message to determine what those > semantics apply to. > > - Section 8 > > The TBD note at the beginning of section 8 (and the task it described) > can be removed now that sipping-profile-datasets has been abandoned. > > Where is the up-to-date version of "uaprofile.rng"? What is the > proper URL to access it? > > - Imported from ietf-sipping-profile-datasets > > The 'policy' and 'excluded-policy' attributes are quite grotty, as > they can be used only in specific combinations among several related > elements, and are quite verbose in any case. It would be much better > to define a "set" construct (to specify a finite set of permitted > values) and a "set-complement" construct (to specify all values are > permitted except a finite set of values). These constructs have the > same expressive power as the existing attributes. E.g.: > > > audio > video > > > > audio/G729 > > > audio/G723 > > > > becomes > > > > audio > video > > > > > > audio/G729 > > > audio/G723 > > > > > but correct usage of this form is much easier to describe in the schema. > > (Looking at the example, perhaps we want to replace the and > elements with "set" and "set-complement" attributes > on its parent element. That is less mathematically pure, but has the > same expressive power and is more terse.) > > As far as I can tell, there are nine "container" types which use the > set/complement mechanism: > > 6.1 container of > 6.2 > 6.3 > 6.4 > 6.5 > 6.6 > 6.7 > 6.8 > 6.9 > > The "direction" attribute seems to be weakly defined. As far as I can > tell, in a policy one can have, for any of the nine container types, > (1) no element, (2) one element with the value "sendrecv", or (3) > optionally one element with the value "sendonly" and optionally one > element with the value "recvonly". But this is not stated in either > this draft or draft-petrie-sipping-profile-datasets and I might well > be wrong. > > Also, if we still utilize merging, we need to state that case (2) is > equivalent to duplicating the value, with one copy marked "sendonly" > and one marked "recvonly", so that we have explicitly shown how to > align two containers with direction attributes in order to merge > (intersect) them. > > - Empty elements > > There are a lot of situations where it is sensible for an element to > have zero sub-elements, in that the stated rules give a clear meaning > to the element. In particular, any "set" construct with zero elements > permits nothing, and any "set-complement" construct with zero elements > permits everything. But most of the relevant elements (including all > the container types) are defined to require at least one sub-element. > > However, there is currently a special case in section 4: It states > that an empty rejects a session. (If it wasn't for the > defined special case, a session with *no* streams would be admissible > under this policy.) It would be better if the "reject everything" > state could be described in a different manner, so as to avoid the > special case. > > - The word "container" > > Beware of the use of the word "container". In the > session-policy-dataset, "container" is (mostly) used to describe > elements which inherit from . I suggest that we > restrict the use in media-policy-dataset in that way. > > Although now that we are removing session-policy-dataset, "container" > is no longer defined by , but it still means the > elements which carry "direction", "policy", etc. > > That change would require rewriting these paragraphs of 6.1: > > The element can only be used in session policy document > (i.e., inside the >>element<<). > > This element MAY have the following attributes (see Section 3.3): > direction, visibility, excluded-policy. > > Multiple elements MAY only be present in a > element if each applies to a different set of streams (i.e., one > element for incoming and one for outgoing streams). > The element MUST contain one or more > elements. > > There may be other uses of "container" that should be changed. > > - "Registered" requirements > > In a number of places, parameters are required to have values that are > appropriately registered. On the face of it, this prevents > experimental or private-use values from being used at all. This is > probably not what we intend. Given that there is general knowledge of > how to create private-use values, these registration requirements > should just be deleted. > From spencer@wonderhamster.org Thu Dec 17 10:10:12 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323FE3A6973 for ; Thu, 17 Dec 2009 10:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpH+-xc7rPCF for ; Thu, 17 Dec 2009 10:10:10 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DBAA73A680F for ; Thu, 17 Dec 2009 10:10:09 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MTAtC-1NUaAk1B5C-00Sa8l; Thu, 17 Dec 2009 13:09:54 -0500 Message-ID: <0603E8FF8C9545B0AE0C990AB3617B19@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" , References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <4B2A5D5C.6090705@nostrum.com> Date: Thu, 17 Dec 2009 12:09:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+su1YfhLG6uD70XptKVvU6PqeKyWtTTOLgcX7 so7K7kfG/NW8ubDXaOWCrqFH4RNDM5RvEQ08dbqwOcwMfWN5uQ OUubSO47+hMR8RNruxwZkK8Htr6sfmHnJR7kkq6CYM= Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, R.Jesske@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:10:12 -0000 When I was looking at Laura's note, I was worried that the inclusion of non-semantic Alert-Info URNs would make semantic Alert-Info URNs less attractive - I like semantic Alert-Info URNs, and wasn't happy about anything that might lessen the deployment and use of semantic Alert-Info URNs. Looking at John's followup, and at Adam's note below, I'm convinced that there is a role for standardized non-semantic Alert-Info URNs, and agree that including this in the charter would be useful, if people think that's a decision that can happen pre-charter. Of course, I'm the poster child for "but the working group needs to decide that", and if the working group needs to decide that, I'd be good. Thanks, Spencer ----- Original Message ----- From: "Adam Roach" To: Cc: ; ; Sent: Thursday, December 17, 2009 10:33 AM Subject: Re: [dispatch] Alert-Info URN charter issue > > >> I would propose to handle the issue as follows: >> >> 1) Include into the charter, as one of the problems to be solved: >> "special ring tones for incoming calls (used in enterprise networks and >> in some countries) when the proxy and the UAs are from different vendors >> with no external ring file being used" >> >> 2) In the draft, define a requirement which states something like that: >> - Alert-Info URNs must be semantic whenever they are used across >> different domains or if the sender has no reason to assume that the >> receiver has the same understanding of non-semantic Alert-Info URNs. >> - Non-semantic, rendering-oriented Alert-Info URNs may be used >> inside closed environements, when there are predefined rules which define >> the semantic of a specific rendering and the sender can expect that the >> receiver is able to understand the rendering-oriented Alert-Info URNs. If >> an UA receives an Alert-Info URN it does not understand, it ignores the >> Alert-Info URN. >> >> >> Is this an acceptable proposal or does anyone have a better idea how to >> handle this issue? >> > > I like this approach. Depending on how we end up defining combinations of > various aspects of ring/ringback tones, the final sentance may end up > reading something like "...it ignores the portions of the Alert-Info URN > that it does not understand," but I don't think that's a fundamental > change to your proposal. > > I'd also point out, on point 1, that the closed environments in which > rendering-oriented ringtones may apply extends beyond enterprises and > specific countries. It can also apply, for example, when mapping from any > legacy protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the edge of > a network. From L.Liess@telekom.de Fri Dec 18 07:27:13 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC243A680A for ; Fri, 18 Dec 2009 07:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daZQ0Fsm-hUs for ; Fri, 18 Dec 2009 07:27:12 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id F11D63A68E6 for ; Fri, 18 Dec 2009 07:27:06 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 18 Dec 2009 16:26:47 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 16:26:47 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Dec 2009 16:26:43 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alert-Info URN charter issue Thread-Index: Acp/L6MT+9ZyNw6QTVaSquojGWm2PwAA113AACIsqMA= References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> From: To: , , X-OriginalArrivalTime: 18 Dec 2009 15:26:47.0077 (UTC) FILETIME=[830C1550:01CA7FF6] Cc: R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 15:27:13 -0000 Hi John and Adam,=20 Thank you very much for your quick comments and proposals. My = understanding is that modifications should be done to the charter = proposal:=20 - short sentence in the charter about "semantic vs. non-semantic"=20 - add the use case "TDM gateway mapping from any legacy protocol (e.g. = 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the edge of a network" By adding the TDM gateway use case (which I think is a very good use = case), my original assumptions that non-semantic Alert-Info URNs are: - only sent by the proxy to end devices of its customers/end users and - never sent end-to-end=20 are no longer valid. I have to remove the restriction for non-semantic = Alert-Info URN identifiers derived from these assumptions. =20 Let's do a second trial for charter text changes: 1) Add to the use cases: =20 " - special ringing tones, e. g. tones used in enterprise networks, = tones used in some countries or tones from legacy protocols which TDM = gateways must map to SIP at the edge of a network" =20 2) Add folowing sentence:=20 " For better interoperability and flexibility, the Alert-Info URNs = identifiers should be semantic whenever possible." =20 I am not absolutely happy with the formulation "whenever possible" = because it is somehow imprecise, but I don't currently see any precise = criteria to allow or disallow non-semantic URNs. Any better idea or can = we leave it this way, at least for the charter? Note: I did not ignore the comments about how the receiver handles = unknown Alert-Info URN identifiers/portions, but I think this is part of = the specification (requirements or UA behaviour), not of the charter, = and I would postpone this discussion for now.=20 Thanks a lot Laura =20 >=20 > I suspect the wording you propose below goes somewhat beyond=20 > what would be appropriate for charter text. However, you are=20 > correct in that the charter needs to say something about=20 > semantic versus non-semantic tones.=20 >=20 > In Hiroshima I heard a justification for non-semantic tones=20 > that is not captured below: cases where a TDM gateway detects=20 > a certain tone pattern and can only convey in SIP some=20 > characteristic of that pattern (e.g., "short"), rather than a=20 > specific meaning. This sounds like a more compelling use case=20 > for non-semantic tones than what is described below. >=20 > John >=20 >=20 > > -----Original Message----- > > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > > Sent: 17 December 2009 15:43 > > To: dispatch@ietf.org; Elwell, John; adam@nostrum.com > > Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com;=20 > > alan@sipstation.com; R.Jesske@telekom.de;=20 > Martin.Huelsemann@telekom.de > > Subject: Alert-Info URN charter issue > >=20 > >=20 > > Hi, > >=20 > > During the Alert-Info URN discussion in Hiroshima we had=20 > > consensus that there is interest in chartering a mini-WG on=20 > > Alert-Info URNs. However, we didn't come to an agreement=20 > > about whether or not we need to decide before chartering if=20 > > the Alert-Info URNs must be semantic. We need to clarify=20 > > this issue before submitting the charter proposal for Anaheim.=20 > > =20 > > Some thoughts on this:=20 > > - The decision wether or not we allow non-semantic=20 > > Alert-Info URNs is tightly coupled with which problems/use=20 > > cases we want to solve. The problem to be solved /use cases =20 > > must, as far as I know, be decided before chartering. =20 > >=20 > > - The Alert-Info URNs for use cases as call waiting and=20 > > other services, country ringback, priority ringing, are=20 > > semantic anyway. So these use cases are definitively in the=20 > charter.=20 > >=20 > > - The critical use cases, for which we need non-semantic,=20 > > rendering-oriented Alert-Info URNs, are ringing tones used in=20 > > PBX-systems (e.g. "short", as described in =A74.3.8 of the=20 > > draft) and in local exchanges in some countries (e.g. the TIA=20 > > ring tones described by Adam in=20 > > http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht > > ml, which is not in the draft). In these use cases, the=20 > > Alert-Info URNs are not transmitted end-to-end, as, e.g. in=20 > > case of country ringback tones, but are sent by the=20 > > PBX-system or local exchange to an end device within its own=20 > > domain. In most cases, we can expect that the end device was=20 > > configured by the user or service provider how to handle the=20 > > rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. > >=20 > > - Rendering-oriented ring tones as described above are use=20 > > cases which we encounter today and people will be implement=20 > > them in some way. If we do not provide a standard which can=20 > > be used for the implementation, people will provide=20 > > proprietary, non-interoperable solutions. For this reason, I=20 > > wouldn't like that the Alert-Info URN scheme we are going to=20 > > define can not be used to implement these use cases. This=20 > > does not imply that we should also define Alert-Info URN=20 > > identifiers for all these cases, but we should at least=20 > > define the scheme which can be used by other people to define=20 > > the specific identifiers. =20 > >=20 > >=20 > > Based on the thoughts above, I would propose to handle the=20 > > issue as follows: > >=20 > > 1) Include into the charter, as one of the problems to be=20 > > solved: "special ring tones for incoming calls (used in=20 > > enterprise networks and in some countries) when the proxy and=20 > > the UAs are from different vendors with no external ring file=20 > > being used" =20 > > =20 > > 2) In the draft, define a requirement which states something=20 > > like that: > > - Alert-Info URNs must be semantic whenever they are=20 > > used across different domains or if the sender has no reason=20 > > to assume that the receiver has the same understanding of=20 > > non-semantic Alert-Info URNs.=20 > > - Non-semantic, rendering-oriented Alert-Info URNs may=20 > > be used inside closed environements, when there are=20 > > predefined rules which define the semantic of a specific=20 > > rendering and the sender can expect that the receiver is able=20 > > to understand the rendering-oriented Alert-Info URNs. If an=20 > > UA receives an Alert-Info URN it does not understand, it=20 > > ignores the Alert-Info URN.=20 > >=20 > >=20 > > Is this an acceptable proposal or does anyone have a better=20 > > idea how to handle this issue?=20 > >=20 > > Thanks a lot > > Laura > >=20 >=20 From pkyzivat@cisco.com Fri Dec 18 14:08:03 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA783A69CF for ; Fri, 18 Dec 2009 14:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muAteffVM8A0 for ; Fri, 18 Dec 2009 14:08:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9CF033A6832 for ; Fri, 18 Dec 2009 14:08:01 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsFAIaMK0tAZnwM/2dsb2JhbACQDoh7pX2XIoIuB4F5BI1V X-IronPort-AV: E=Sophos;i="4.47,420,1257120000"; d="scan'208";a="75301017" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2009 22:07:43 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBIM7hjc002945; Fri, 18 Dec 2009 22:07:43 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 17:07:43 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 17:07:42 -0500 Message-ID: <4B2BFD2E.4050009@cisco.com> Date: Fri, 18 Dec 2009 17:07:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Dec 2009 22:07:42.0972 (UTC) FILETIME=[857A5BC0:01CA802E] Cc: dispatch@ietf.org, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 22:08:03 -0000 Perhaps this is more theoretical than real, but I have been imagining another broad use of "non-semantic" URNs: URNs that identify specific media "by name". For instance, is there a standard identifier for music, as there is an ISBN for books? I'm thinking of a name for a particular "work" independent of its specific rendering, such as "Beethoven's Fifth". You wouldn't want that entire thing as a ring tone, but maybe the first 4/8 note intro. You might want something longer for a ringback. This sort of alert could be used e2e, though there is no guarantee that the other end will understand it. Given a URN you don't understand, you could search out some definitions of it (possibly different renderings) and pick one you like. This sort of usage seems to be on the borderline of "semantic". Thanks, Paul This usage brid L.Liess@telekom.de wrote: > Hi John and Adam, > > Thank you very much for your quick comments and proposals. My understanding is that modifications should be done to the charter proposal: > - short sentence in the charter about "semantic vs. non-semantic" > - add the use case "TDM gateway mapping from any legacy protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the edge of a network" > > By adding the TDM gateway use case (which I think is a very good use case), my original assumptions that non-semantic Alert-Info URNs are: > - only sent by the proxy to end devices of its customers/end users and > - never sent end-to-end > are no longer valid. I have to remove the restriction for non-semantic Alert-Info URN identifiers derived from these assumptions. > > Let's do a second trial for charter text changes: > 1) Add to the use cases: > " - special ringing tones, e. g. tones used in enterprise networks, tones used in some countries or tones from legacy protocols which TDM gateways must map to SIP at the edge of a network" > 2) Add folowing sentence: > " For better interoperability and flexibility, the Alert-Info URNs identifiers should be semantic whenever possible." > > I am not absolutely happy with the formulation "whenever possible" because it is somehow imprecise, but I don't currently see any precise criteria to allow or disallow non-semantic URNs. Any better idea or can we leave it this way, at least for the charter? > > Note: I did not ignore the comments about how the receiver handles unknown Alert-Info URN identifiers/portions, but I think this is part of the specification (requirements or UA behaviour), not of the charter, and I would postpone this discussion for now. > > > Thanks a lot > Laura > > > > > >> I suspect the wording you propose below goes somewhat beyond >> what would be appropriate for charter text. However, you are >> correct in that the charter needs to say something about >> semantic versus non-semantic tones. >> >> In Hiroshima I heard a justification for non-semantic tones >> that is not captured below: cases where a TDM gateway detects >> a certain tone pattern and can only convey in SIP some >> characteristic of that pattern (e.g., "short"), rather than a >> specific meaning. This sounds like a more compelling use case >> for non-semantic tones than what is described below. >> >> John >> >> >>> -----Original Message----- >>> From: L.Liess@telekom.de [mailto:L.Liess@telekom.de] >>> Sent: 17 December 2009 15:43 >>> To: dispatch@ietf.org; Elwell, John; adam@nostrum.com >>> Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com; >>> alan@sipstation.com; R.Jesske@telekom.de; >> Martin.Huelsemann@telekom.de >>> Subject: Alert-Info URN charter issue >>> >>> >>> Hi, >>> >>> During the Alert-Info URN discussion in Hiroshima we had >>> consensus that there is interest in chartering a mini-WG on >>> Alert-Info URNs. However, we didn't come to an agreement >>> about whether or not we need to decide before chartering if >>> the Alert-Info URNs must be semantic. We need to clarify >>> this issue before submitting the charter proposal for Anaheim. >>> >>> Some thoughts on this: >>> - The decision wether or not we allow non-semantic >>> Alert-Info URNs is tightly coupled with which problems/use >>> cases we want to solve. The problem to be solved /use cases >>> must, as far as I know, be decided before chartering. >>> >>> - The Alert-Info URNs for use cases as call waiting and >>> other services, country ringback, priority ringing, are >>> semantic anyway. So these use cases are definitively in the >> charter. >>> - The critical use cases, for which we need non-semantic, >>> rendering-oriented Alert-Info URNs, are ringing tones used in >>> PBX-systems (e.g. "short", as described in §4.3.8 of the >>> draft) and in local exchanges in some countries (e.g. the TIA >>> ring tones described by Adam in >>> http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht >>> ml, which is not in the draft). In these use cases, the >>> Alert-Info URNs are not transmitted end-to-end, as, e.g. in >>> case of country ringback tones, but are sent by the >>> PBX-system or local exchange to an end device within its own >>> domain. In most cases, we can expect that the end device was >>> configured by the user or service provider how to handle the >>> rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. >>> >>> - Rendering-oriented ring tones as described above are use >>> cases which we encounter today and people will be implement >>> them in some way. If we do not provide a standard which can >>> be used for the implementation, people will provide >>> proprietary, non-interoperable solutions. For this reason, I >>> wouldn't like that the Alert-Info URN scheme we are going to >>> define can not be used to implement these use cases. This >>> does not imply that we should also define Alert-Info URN >>> identifiers for all these cases, but we should at least >>> define the scheme which can be used by other people to define >>> the specific identifiers. >>> >>> >>> Based on the thoughts above, I would propose to handle the >>> issue as follows: >>> >>> 1) Include into the charter, as one of the problems to be >>> solved: "special ring tones for incoming calls (used in >>> enterprise networks and in some countries) when the proxy and >>> the UAs are from different vendors with no external ring file >>> being used" >>> >>> 2) In the draft, define a requirement which states something >>> like that: >>> - Alert-Info URNs must be semantic whenever they are >>> used across different domains or if the sender has no reason >>> to assume that the receiver has the same understanding of >>> non-semantic Alert-Info URNs. >>> - Non-semantic, rendering-oriented Alert-Info URNs may >>> be used inside closed environements, when there are >>> predefined rules which define the semantic of a specific >>> rendering and the sender can expect that the receiver is able >>> to understand the rendering-oriented Alert-Info URNs. If an >>> UA receives an Alert-Info URN it does not understand, it >>> ignores the Alert-Info URN. >>> >>> >>> Is this an acceptable proposal or does anyone have a better >>> idea how to handle this issue? >>> >>> Thanks a lot >>> Laura >>> > From hgs@cs.columbia.edu Fri Dec 18 14:27:57 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40A03A6918 for ; Fri, 18 Dec 2009 14:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR9UJRRd4+xo for ; Fri, 18 Dec 2009 14:27:56 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id E36AB3A68BA for ; Fri, 18 Dec 2009 14:27:51 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBIMRXuC008592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Dec 2009 17:27:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4B2BFD2E.4050009@cisco.com> Date: Fri, 18 Dec 2009 17:27:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4A3E55-81D0-4B19-8893-DFE50594E19D@cs.columbia.edu> References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: dispatch@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 22:27:58 -0000 Not sure it's used for music, but see DOIs: http://www.doi.org/ (Almost) every scientific paper has one these days, although they = probably don't make good ring tones. On Dec 18, 2009, at 5:07 PM, Paul Kyzivat wrote: > Perhaps this is more theoretical than real, but I have been imagining = another broad use of "non-semantic" URNs: >=20 > URNs that identify specific media "by name". For instance, is there a = standard identifier for music, as there is an ISBN for books? I'm = thinking of a name for a particular "work" independent of its specific = rendering, such as "Beethoven's Fifth". You wouldn't want that entire = thing as a ring tone, but maybe the first 4/8 note intro. You might want = something longer for a ringback. >=20 > This sort of alert could be used e2e, though there is no guarantee = that the other end will understand it. Given a URN you don't understand, = you could search out some definitions of it (possibly different = renderings) and pick one you like. >=20 > This sort of usage seems to be on the borderline of "semantic". From tme@americafree.tv Fri Dec 18 16:32:30 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B4628C122 for ; Fri, 18 Dec 2009 16:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2bK3yics1Bi for ; Fri, 18 Dec 2009 16:32:29 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 8915628C11A for ; Fri, 18 Dec 2009 16:32:29 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 54F4357E0D5C; Fri, 18 Dec 2009 19:32:14 -0500 (EST) Message-Id: From: Marshall Eubanks To: Henning Schulzrinne In-Reply-To: <2E4A3E55-81D0-4B19-8893-DFE50594E19D@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 18 Dec 2009 19:32:13 -0500 References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> <2E4A3E55-81D0-4B19-8893-DFE50594E19D@cs.columbia.edu> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, L.Liess@telekom.de, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 00:32:30 -0000 On Dec 18, 2009, at 5:27 PM, Henning Schulzrinne wrote: > Not sure it's used for music, but see DOIs: > http://www.doi.org/ > > (Almost) every scientific paper has one these days, although they > probably don't make good ring tones. > > On Dec 18, 2009, at 5:07 PM, Paul Kyzivat wrote: > >> Perhaps this is more theoretical than real, but I have been >> imagining another broad use of "non-semantic" URNs: >> >> URNs that identify specific media "by name". For instance, is there >> a standard identifier for music, as there is an ISBN for books? I'm >> thinking of a name for a particular "work" independent of its >> specific rendering, such as "Beethoven's Fifth". You wouldn't want >> that entire thing as a ring tone, but maybe the first 4/8 note >> intro. You might want something longer for a ringback. No. This is a big issue in music license payments online, with, e.g., SoundExchange (the US payment agent for online music royalties) holding onto hundreds of millions of dollars for royalties paid on music whose that can't be located - see, e.g., http://www.p2pnet.net/story/18864 The industry is rampant with complaints that royalty payments are not passed along (not just be SoundExchange) and the cynics in the music industry (who are not hard to find) think that the lack of a URN for music (either performances or compositions) is a feature, not a bug, of the payment system. There are a number of companies that offer digital "fingerprints" to recognize a given performance or composition, generally in connection with DRM or fighting against file sharing - see, e.g., http://www.drmwatch.com/drmtech/article.php/3363151 but these are proprietary and not really intended as a public index. Regards Marshall >> >> This sort of alert could be used e2e, though there is no guarantee >> that the other end will understand it. Given a URN you don't >> understand, you could search out some definitions of it (possibly >> different renderings) and pick one you like. >> >> This sort of usage seems to be on the borderline of "semantic". > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dean.willis@softarmor.com Sun Dec 20 20:00:34 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32AF3A6976 for ; Sun, 20 Dec 2009 20:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OByb8cV2dPeW for ; Sun, 20 Dec 2009 20:00:34 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1495F3A67A8 for ; Sun, 20 Dec 2009 20:00:34 -0800 (PST) Received: from [192.168.2.100] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBL409nw019517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Dec 2009 22:00:10 -0600 Message-ID: <4B2EF2E2.7070905@softarmor.com> Date: Sun, 20 Dec 2009 22:00:34 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marshall Eubanks References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> <2E4A3E55-81D0-4B19-8893-DFE50594E19D@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, R.Jesske@telekom.de, L.Liess@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 04:00:34 -0000 Marshall Eubanks wrote: > The industry is rampant with complaints that royalty payments are not > passed along (not just be SoundExchange) and the cynics in the music > industry (who are not hard to find) think that the lack of a URN for > music (either performances or compositions) is a feature, not a bug, of > the payment system. Oh cool! Another industry to disrupt! Santa Clause did bring me a present after all. -- Dean From andrew.hutton@siemens-enterprise.com Mon Dec 21 03:59:19 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E5D28C0E6 for ; Mon, 21 Dec 2009 03:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnIpDz3QbrOP for ; Mon, 21 Dec 2009 03:59:13 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4C3ED3A680B for ; Mon, 21 Dec 2009 03:59:11 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-346252; Mon, 21 Dec 2009 12:58:55 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1E2F61EB826B; Mon, 21 Dec 2009 12:58:55 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 21 Dec 2009 12:58:55 +0100 From: "Hutton, Andrew" To: "L.Liess@telekom.de" Date: Mon, 21 Dec 2009 12:59:02 +0100 Thread-Topic: Alert-Info URN charter issue Thread-Index: Acp/L6MT+9ZyNw6QTVaSquojGWm2PwAA113AACIsqMAAnd7YAA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3068795CA21@MCHP058A.global-ad.net> References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 11:59:20 -0000 Hi Laura, I think your proposal for the charter are ok and I think what we hopefully = will end up with is only specifying the use of non-semantic identifiers in = certain interworking scenarios and using the preferred semantic identifiers= in all other cases. Regards Andy=20 =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of L.Liess@telekom.de Sent: 18 December 2009 15:27 To: Elwell, John; dispatch@ietf.org; adam@nostrum.com Cc: R.Jesske@telekom.de; Martin.Huelsemann@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue Hi John and Adam,=20 Thank you very much for your quick comments and proposals. My understanding= is that modifications should be done to the charter proposal:=20 - short sentence in the charter about "semantic vs. non-semantic"=20 - add the use case "TDM gateway mapping from any legacy protocol (e.g. 3GP= P2 IOS, GR-303, V5.2, etc) to SIP at the edge of a network" By adding the TDM gateway use case (which I think is a very good use case),= my original assumptions that non-semantic Alert-Info URNs are: - only sent by the proxy to end devices of its customers/end users and - never sent end-to-end=20 are no longer valid. I have to remove the restriction for non-semantic Aler= t-Info URN identifiers derived from these assumptions. =20 Let's do a second trial for charter text changes: 1) Add to the use cases: =20 " - special ringing tones, e. g. tones used in enterprise networks, tone= s used in some countries or tones from legacy protocols which TDM gateways = must map to SIP at the edge of a network" =20 2) Add folowing sentence:=20 " For better interoperability and flexibility, the Alert-Info URNs identi= fiers should be semantic whenever possible." =20 I am not absolutely happy with the formulation "whenever possible" because = it is somehow imprecise, but I don't currently see any precise criteria to = allow or disallow non-semantic URNs. Any better idea or can we leave it th= is way, at least for the charter? Note: I did not ignore the comments about how the receiver handles unknown = Alert-Info URN identifiers/portions, but I think this is part of the specif= ication (requirements or UA behaviour), not of the charter, and I would pos= tpone this discussion for now.=20 Thanks a lot Laura =20 >=20 > I suspect the wording you propose below goes somewhat beyond=20 > what would be appropriate for charter text. However, you are=20 > correct in that the charter needs to say something about=20 > semantic versus non-semantic tones.=20 >=20 > In Hiroshima I heard a justification for non-semantic tones=20 > that is not captured below: cases where a TDM gateway detects=20 > a certain tone pattern and can only convey in SIP some=20 > characteristic of that pattern (e.g., "short"), rather than a=20 > specific meaning. This sounds like a more compelling use case=20 > for non-semantic tones than what is described below. >=20 > John >=20 >=20 > > -----Original Message----- > > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > > Sent: 17 December 2009 15:43 > > To: dispatch@ietf.org; Elwell, John; adam@nostrum.com > > Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com;=20 > > alan@sipstation.com; R.Jesske@telekom.de;=20 > Martin.Huelsemann@telekom.de > > Subject: Alert-Info URN charter issue > >=20 > >=20 > > Hi, > >=20 > > During the Alert-Info URN discussion in Hiroshima we had=20 > > consensus that there is interest in chartering a mini-WG on=20 > > Alert-Info URNs. However, we didn't come to an agreement=20 > > about whether or not we need to decide before chartering if=20 > > the Alert-Info URNs must be semantic. We need to clarify=20 > > this issue before submitting the charter proposal for Anaheim.=20 > > =20 > > Some thoughts on this:=20 > > - The decision wether or not we allow non-semantic=20 > > Alert-Info URNs is tightly coupled with which problems/use=20 > > cases we want to solve. The problem to be solved /use cases =20 > > must, as far as I know, be decided before chartering. =20 > >=20 > > - The Alert-Info URNs for use cases as call waiting and=20 > > other services, country ringback, priority ringing, are=20 > > semantic anyway. So these use cases are definitively in the=20 > charter.=20 > >=20 > > - The critical use cases, for which we need non-semantic,=20 > > rendering-oriented Alert-Info URNs, are ringing tones used in=20 > > PBX-systems (e.g. "short", as described in =A74.3.8 of the=20 > > draft) and in local exchanges in some countries (e.g. the TIA=20 > > ring tones described by Adam in=20 > > http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht > > ml, which is not in the draft). In these use cases, the=20 > > Alert-Info URNs are not transmitted end-to-end, as, e.g. in=20 > > case of country ringback tones, but are sent by the=20 > > PBX-system or local exchange to an end device within its own=20 > > domain. In most cases, we can expect that the end device was=20 > > configured by the user or service provider how to handle the=20 > > rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. > >=20 > > - Rendering-oriented ring tones as described above are use=20 > > cases which we encounter today and people will be implement=20 > > them in some way. If we do not provide a standard which can=20 > > be used for the implementation, people will provide=20 > > proprietary, non-interoperable solutions. For this reason, I=20 > > wouldn't like that the Alert-Info URN scheme we are going to=20 > > define can not be used to implement these use cases. This=20 > > does not imply that we should also define Alert-Info URN=20 > > identifiers for all these cases, but we should at least=20 > > define the scheme which can be used by other people to define=20 > > the specific identifiers. =20 > >=20 > >=20 > > Based on the thoughts above, I would propose to handle the=20 > > issue as follows: > >=20 > > 1) Include into the charter, as one of the problems to be=20 > > solved: "special ring tones for incoming calls (used in=20 > > enterprise networks and in some countries) when the proxy and=20 > > the UAs are from different vendors with no external ring file=20 > > being used" =20 > > =20 > > 2) In the draft, define a requirement which states something=20 > > like that: > > - Alert-Info URNs must be semantic whenever they are=20 > > used across different domains or if the sender has no reason=20 > > to assume that the receiver has the same understanding of=20 > > non-semantic Alert-Info URNs.=20 > > - Non-semantic, rendering-oriented Alert-Info URNs may=20 > > be used inside closed environements, when there are=20 > > predefined rules which define the semantic of a specific=20 > > rendering and the sender can expect that the receiver is able=20 > > to understand the rendering-oriented Alert-Info URNs. If an=20 > > UA receives an Alert-Info URN it does not understand, it=20 > > ignores the Alert-Info URN.=20 > >=20 > >=20 > > Is this an acceptable proposal or does anyone have a better=20 > > idea how to handle this issue?=20 > >=20 > > Thanks a lot > > Laura > >=20 >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From L.Liess@telekom.de Mon Dec 21 05:05:57 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5CA28C117 for ; Mon, 21 Dec 2009 05:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfXeC8lZAY7X for ; Mon, 21 Dec 2009 05:05:56 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id EA60C3A6948 for ; Mon, 21 Dec 2009 05:05:55 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 21 Dec 2009 14:05:33 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 14:05:33 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 21 Dec 2009 14:05:31 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003CD7388@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4B2BFD2E.4050009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Alert-Info URN charter issue Thread-Index: AcqALox5wfn0WfdcQSqRaStJ6IVnegCB/8dg References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de><40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> From: To: X-OriginalArrivalTime: 21 Dec 2009 13:05:33.0021 (UTC) FILETIME=[475B00D0:01CA823E] Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, R.Jesske@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 13:05:58 -0000 Paul, The idea sounds very interesting to me. I think the syntax and the rules = for the Alert-Info URN should be flexible enough so that Alert-Info URN = can be used later for use-cases as you described.=20 I could add your description to the text of the draft, as an example of = possible future use cases, but because I don't know of any real use case = and the concrete requirements for it, I would not try to define now a = concrete Alert-Info URN identifier. Maybe later, when somebody thinks = about a real implementation in this direction. =20 Is this OK for you?=20 Thanks a lot Laura =20 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, December 18, 2009 11:08 PM > To: Liess, Laura > Cc: dispatch@ietf.org; Jesske, Roland; H=FClsemann, Martin > Subject: Re: [dispatch] Alert-Info URN charter issue >=20 > Perhaps this is more theoretical than real, but I have been imagining=20 > another broad use of "non-semantic" URNs: >=20 > URNs that identify specific media "by name". For instance, is there a=20 > standard identifier for music, as there is an ISBN for books? I'm=20 > thinking of a name for a particular "work" independent of its=20 > specific=20 > rendering, such as "Beethoven's Fifth". You wouldn't want that entire=20 > thing as a ring tone, but maybe the first 4/8 note intro. You=20 > might want=20 > something longer for a ringback. >=20 > This sort of alert could be used e2e, though there is no=20 > guarantee that=20 > the other end will understand it. Given a URN you don't=20 > understand, you=20 > could search out some definitions of it (possibly different=20 > renderings)=20 > and pick one you like. >=20 > This sort of usage seems to be on the borderline of "semantic". >=20 > Thanks, > Paul >=20 > This usage brid >=20 > L.Liess@telekom.de wrote: > > Hi John and Adam,=20 > >=20 > > Thank you very much for your quick comments and proposals.=20 > My understanding is that modifications should be done to the=20 > charter proposal:=20 > > - short sentence in the charter about "semantic vs.=20 > non-semantic"=20 > > - add the use case "TDM gateway mapping from any legacy=20 > protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the=20 > edge of a network" > >=20 > > By adding the TDM gateway use case (which I think is a very=20 > good use case), my original assumptions that non-semantic=20 > Alert-Info URNs are: > > - only sent by the proxy to end devices of its=20 > customers/end users and > > - never sent end-to-end=20 > > are no longer valid. I have to remove the restriction for=20 > non-semantic Alert-Info URN identifiers derived from these=20 > assumptions. =20 > >=20 > > Let's do a second trial for charter text changes: > > 1) Add to the use cases: =20 > > " - special ringing tones, e. g. tones used in=20 > enterprise networks, tones used in some countries or tones=20 > from legacy protocols which TDM gateways must map to SIP at=20 > the edge of a network" =20 > > 2) Add folowing sentence:=20 > > " For better interoperability and flexibility, the=20 > Alert-Info URNs identifiers should be semantic whenever possible." =20 > >=20 > > I am not absolutely happy with the formulation "whenever=20 > possible" because it is somehow imprecise, but I don't=20 > currently see any precise criteria to allow or disallow=20 > non-semantic URNs. Any better idea or can we leave it this=20 > way, at least for the charter? > >=20 > > Note: I did not ignore the comments about how the receiver=20 > handles unknown Alert-Info URN identifiers/portions, but I=20 > think this is part of the specification (requirements or UA=20 > behaviour), not of the charter, and I would postpone this=20 > discussion for now.=20 > >=20 > >=20 > > Thanks a lot > > Laura > >=20 > >=20 > > =20 > >=20 > >=20 > >> I suspect the wording you propose below goes somewhat beyond=20 > >> what would be appropriate for charter text. However, you are=20 > >> correct in that the charter needs to say something about=20 > >> semantic versus non-semantic tones.=20 > >> > >> In Hiroshima I heard a justification for non-semantic tones=20 > >> that is not captured below: cases where a TDM gateway detects=20 > >> a certain tone pattern and can only convey in SIP some=20 > >> characteristic of that pattern (e.g., "short"), rather than a=20 > >> specific meaning. This sounds like a more compelling use case=20 > >> for non-semantic tones than what is described below. > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > >>> Sent: 17 December 2009 15:43 > >>> To: dispatch@ietf.org; Elwell, John; adam@nostrum.com > >>> Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com;=20 > >>> alan@sipstation.com; R.Jesske@telekom.de;=20 > >> Martin.Huelsemann@telekom.de > >>> Subject: Alert-Info URN charter issue > >>> > >>> > >>> Hi, > >>> > >>> During the Alert-Info URN discussion in Hiroshima we had=20 > >>> consensus that there is interest in chartering a mini-WG on=20 > >>> Alert-Info URNs. However, we didn't come to an agreement=20 > >>> about whether or not we need to decide before chartering if=20 > >>> the Alert-Info URNs must be semantic. We need to clarify=20 > >>> this issue before submitting the charter proposal for Anaheim.=20 > >>> =20 > >>> Some thoughts on this:=20 > >>> - The decision wether or not we allow non-semantic=20 > >>> Alert-Info URNs is tightly coupled with which problems/use=20 > >>> cases we want to solve. The problem to be solved /use cases =20 > >>> must, as far as I know, be decided before chartering. =20 > >>> > >>> - The Alert-Info URNs for use cases as call waiting and=20 > >>> other services, country ringback, priority ringing, are=20 > >>> semantic anyway. So these use cases are definitively in the=20 > >> charter.=20 > >>> - The critical use cases, for which we need non-semantic,=20 > >>> rendering-oriented Alert-Info URNs, are ringing tones used in=20 > >>> PBX-systems (e.g. "short", as described in =A74.3.8 of the=20 > >>> draft) and in local exchanges in some countries (e.g. the TIA=20 > >>> ring tones described by Adam in=20 > >>> http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht > >>> ml, which is not in the draft). In these use cases, the=20 > >>> Alert-Info URNs are not transmitted end-to-end, as, e.g. in=20 > >>> case of country ringback tones, but are sent by the=20 > >>> PBX-system or local exchange to an end device within its own=20 > >>> domain. In most cases, we can expect that the end device was=20 > >>> configured by the user or service provider how to handle the=20 > >>> rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. > >>> > >>> - Rendering-oriented ring tones as described above are use=20 > >>> cases which we encounter today and people will be implement=20 > >>> them in some way. If we do not provide a standard which can=20 > >>> be used for the implementation, people will provide=20 > >>> proprietary, non-interoperable solutions. For this reason, I=20 > >>> wouldn't like that the Alert-Info URN scheme we are going to=20 > >>> define can not be used to implement these use cases. This=20 > >>> does not imply that we should also define Alert-Info URN=20 > >>> identifiers for all these cases, but we should at least=20 > >>> define the scheme which can be used by other people to define=20 > >>> the specific identifiers. =20 > >>> > >>> > >>> Based on the thoughts above, I would propose to handle the=20 > >>> issue as follows: > >>> > >>> 1) Include into the charter, as one of the problems to be=20 > >>> solved: "special ring tones for incoming calls (used in=20 > >>> enterprise networks and in some countries) when the proxy and=20 > >>> the UAs are from different vendors with no external ring file=20 > >>> being used" =20 > >>> =20 > >>> 2) In the draft, define a requirement which states something=20 > >>> like that: > >>> - Alert-Info URNs must be semantic whenever they are=20 > >>> used across different domains or if the sender has no reason=20 > >>> to assume that the receiver has the same understanding of=20 > >>> non-semantic Alert-Info URNs.=20 > >>> - Non-semantic, rendering-oriented Alert-Info URNs may=20 > >>> be used inside closed environements, when there are=20 > >>> predefined rules which define the semantic of a specific=20 > >>> rendering and the sender can expect that the receiver is able=20 > >>> to understand the rendering-oriented Alert-Info URNs. If an=20 > >>> UA receives an Alert-Info URN it does not understand, it=20 > >>> ignores the Alert-Info URN.=20 > >>> > >>> > >>> Is this an acceptable proposal or does anyone have a better=20 > >>> idea how to handle this issue?=20 > >>> > >>> Thanks a lot > >>> Laura > >>> > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From L.Liess@telekom.de Mon Dec 21 05:17:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C8328C105 for ; Mon, 21 Dec 2009 05:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txr54-Wcio2o for ; Mon, 21 Dec 2009 05:17:27 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 02A0F28C0E3 for ; Mon, 21 Dec 2009 05:17:26 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 21 Dec 2009 14:16:25 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 14:16:10 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 21 Dec 2009 14:16:09 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003CD739F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3068795CA21@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alert-Info URN charter issue Thread-Index: Acp/L6MT+9ZyNw6QTVaSquojGWm2PwAA113AACIsqMAAnd7YAAAC+mpA References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <101C6067BEC68246B0C3F6843BCCC1E3068795CA21@MCHP058A.global-ad.net> From: To: X-OriginalArrivalTime: 21 Dec 2009 13:16:10.0249 (UTC) FILETIME=[C32C4790:01CA823F] Cc: dispatch@ietf.org Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 13:17:29 -0000 Andrew,=20 I think so too. We should use non-semantic identifiers only when there = no other posibility, but we should not exclude them conmpletely.=20 Thanks a lot Laura =20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > Sent: Monday, December 21, 2009 12:59 PM > To: Liess, Laura > Cc: dispatch@ietf.org > Subject: RE: Alert-Info URN charter issue >=20 > Hi Laura, >=20 > I think your proposal for the charter are ok and I think what=20 > we hopefully will end up with is only specifying the use of=20 > non-semantic identifiers in certain interworking scenarios=20 > and using the preferred semantic identifiers in all other cases. >=20 > Regards > Andy=20 >=20 > =20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of L.Liess@telekom.de > Sent: 18 December 2009 15:27 > To: Elwell, John; dispatch@ietf.org; adam@nostrum.com > Cc: R.Jesske@telekom.de; Martin.Huelsemann@telekom.de > Subject: Re: [dispatch] Alert-Info URN charter issue >=20 > Hi John and Adam,=20 >=20 > Thank you very much for your quick comments and proposals. My=20 > understanding is that modifications should be done to the=20 > charter proposal:=20 > - short sentence in the charter about "semantic vs.=20 > non-semantic"=20 > - add the use case "TDM gateway mapping from any legacy=20 > protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the=20 > edge of a network" >=20 > By adding the TDM gateway use case (which I think is a very=20 > good use case), my original assumptions that non-semantic=20 > Alert-Info URNs are: > - only sent by the proxy to end devices of its customers/end users and > - never sent end-to-end=20 > are no longer valid. I have to remove the restriction for=20 > non-semantic Alert-Info URN identifiers derived from these=20 > assumptions. =20 >=20 > Let's do a second trial for charter text changes: > 1) Add to the use cases: =20 > " - special ringing tones, e. g. tones used in enterprise=20 > networks, tones used in some countries or tones from legacy=20 > protocols which TDM gateways must map to SIP at the edge of a=20 > network" =20 > 2) Add folowing sentence:=20 > " For better interoperability and flexibility, the=20 > Alert-Info URNs identifiers should be semantic whenever possible." =20 >=20 > I am not absolutely happy with the formulation "whenever=20 > possible" because it is somehow imprecise, but I don't=20 > currently see any precise criteria to allow or disallow=20 > non-semantic URNs. Any better idea or can we leave it this=20 > way, at least for the charter? >=20 > Note: I did not ignore the comments about how the receiver=20 > handles unknown Alert-Info URN identifiers/portions, but I=20 > think this is part of the specification (requirements or UA=20 > behaviour), not of the charter, and I would postpone this=20 > discussion for now.=20 >=20 >=20 > Thanks a lot > Laura >=20 >=20 > =20 >=20 >=20 > >=20 > > I suspect the wording you propose below goes somewhat beyond=20 > > what would be appropriate for charter text. However, you are=20 > > correct in that the charter needs to say something about=20 > > semantic versus non-semantic tones.=20 > >=20 > > In Hiroshima I heard a justification for non-semantic tones=20 > > that is not captured below: cases where a TDM gateway detects=20 > > a certain tone pattern and can only convey in SIP some=20 > > characteristic of that pattern (e.g., "short"), rather than a=20 > > specific meaning. This sounds like a more compelling use case=20 > > for non-semantic tones than what is described below. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > > > Sent: 17 December 2009 15:43 > > > To: dispatch@ietf.org; Elwell, John; adam@nostrum.com > > > Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com;=20 > > > alan@sipstation.com; R.Jesske@telekom.de;=20 > > Martin.Huelsemann@telekom.de > > > Subject: Alert-Info URN charter issue > > >=20 > > >=20 > > > Hi, > > >=20 > > > During the Alert-Info URN discussion in Hiroshima we had=20 > > > consensus that there is interest in chartering a mini-WG on=20 > > > Alert-Info URNs. However, we didn't come to an agreement=20 > > > about whether or not we need to decide before chartering if=20 > > > the Alert-Info URNs must be semantic. We need to clarify=20 > > > this issue before submitting the charter proposal for Anaheim.=20 > > > =20 > > > Some thoughts on this:=20 > > > - The decision wether or not we allow non-semantic=20 > > > Alert-Info URNs is tightly coupled with which problems/use=20 > > > cases we want to solve. The problem to be solved /use cases =20 > > > must, as far as I know, be decided before chartering. =20 > > >=20 > > > - The Alert-Info URNs for use cases as call waiting and=20 > > > other services, country ringback, priority ringing, are=20 > > > semantic anyway. So these use cases are definitively in the=20 > > charter.=20 > > >=20 > > > - The critical use cases, for which we need non-semantic,=20 > > > rendering-oriented Alert-Info URNs, are ringing tones used in=20 > > > PBX-systems (e.g. "short", as described in =A74.3.8 of the=20 > > > draft) and in local exchanges in some countries (e.g. the TIA=20 > > > ring tones described by Adam in=20 > > > http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht > > > ml, which is not in the draft). In these use cases, the=20 > > > Alert-Info URNs are not transmitted end-to-end, as, e.g. in=20 > > > case of country ringback tones, but are sent by the=20 > > > PBX-system or local exchange to an end device within its own=20 > > > domain. In most cases, we can expect that the end device was=20 > > > configured by the user or service provider how to handle the=20 > > > rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. > > >=20 > > > - Rendering-oriented ring tones as described above are use=20 > > > cases which we encounter today and people will be implement=20 > > > them in some way. If we do not provide a standard which can=20 > > > be used for the implementation, people will provide=20 > > > proprietary, non-interoperable solutions. For this reason, I=20 > > > wouldn't like that the Alert-Info URN scheme we are going to=20 > > > define can not be used to implement these use cases. This=20 > > > does not imply that we should also define Alert-Info URN=20 > > > identifiers for all these cases, but we should at least=20 > > > define the scheme which can be used by other people to define=20 > > > the specific identifiers. =20 > > >=20 > > >=20 > > > Based on the thoughts above, I would propose to handle the=20 > > > issue as follows: > > >=20 > > > 1) Include into the charter, as one of the problems to be=20 > > > solved: "special ring tones for incoming calls (used in=20 > > > enterprise networks and in some countries) when the proxy and=20 > > > the UAs are from different vendors with no external ring file=20 > > > being used" =20 > > > =20 > > > 2) In the draft, define a requirement which states something=20 > > > like that: > > > - Alert-Info URNs must be semantic whenever they are=20 > > > used across different domains or if the sender has no reason=20 > > > to assume that the receiver has the same understanding of=20 > > > non-semantic Alert-Info URNs.=20 > > > - Non-semantic, rendering-oriented Alert-Info URNs may=20 > > > be used inside closed environements, when there are=20 > > > predefined rules which define the semantic of a specific=20 > > > rendering and the sender can expect that the receiver is able=20 > > > to understand the rendering-oriented Alert-Info URNs. If an=20 > > > UA receives an Alert-Info URN it does not understand, it=20 > > > ignores the Alert-Info URN.=20 > > >=20 > > >=20 > > > Is this an acceptable proposal or does anyone have a better=20 > > > idea how to handle this issue?=20 > > >=20 > > > Thanks a lot > > > Laura > > >=20 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Mon Dec 21 11:09:44 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1664E3A6834 for ; Mon, 21 Dec 2009 11:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdrUFloX08oH for ; Mon, 21 Dec 2009 11:09:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6FCA53A680A for ; Mon, 21 Dec 2009 11:09:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQGAJ9WL0tAZnwN/2dsb2JhbACPf4h9qECVTYIuB4F5BI1a X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="75845581" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Dec 2009 19:09:23 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBLJ9NYI016440; Mon, 21 Dec 2009 19:09:23 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 14:09:23 -0500 Received: from [10.86.246.245] ([10.86.246.245]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 14:09:23 -0500 Message-ID: <4B2FC7E2.5000909@cisco.com> Date: Mon, 21 Dec 2009 14:09:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de><40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003CD7388@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003CD7388@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Dec 2009 19:09:23.0105 (UTC) FILETIME=[1B197910:01CA8271] Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, R.Jesske@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:09:44 -0000 Its just an idea of mine with no concrete needs. So whatever you want to do is fine with me. I certainly don't see any reason to delay needed work for it. Thanks, Paul L.Liess@telekom.de wrote: > Paul, > > The idea sounds very interesting to me. I think the syntax and the rules for the Alert-Info URN should be flexible enough so that Alert-Info URN can be used later for use-cases as you described. > > I could add your description to the text of the draft, as an example of possible future use cases, but because I don't know of any real use case and the concrete requirements for it, I would not try to define now a concrete Alert-Info URN identifier. Maybe later, when somebody thinks about a real implementation in this direction. > > Is this OK for you? > > > Thanks a lot > Laura > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, December 18, 2009 11:08 PM >> To: Liess, Laura >> Cc: dispatch@ietf.org; Jesske, Roland; Hülsemann, Martin >> Subject: Re: [dispatch] Alert-Info URN charter issue >> >> Perhaps this is more theoretical than real, but I have been imagining >> another broad use of "non-semantic" URNs: >> >> URNs that identify specific media "by name". For instance, is there a >> standard identifier for music, as there is an ISBN for books? I'm >> thinking of a name for a particular "work" independent of its >> specific >> rendering, such as "Beethoven's Fifth". You wouldn't want that entire >> thing as a ring tone, but maybe the first 4/8 note intro. You >> might want >> something longer for a ringback. >> >> This sort of alert could be used e2e, though there is no >> guarantee that >> the other end will understand it. Given a URN you don't >> understand, you >> could search out some definitions of it (possibly different >> renderings) >> and pick one you like. >> >> This sort of usage seems to be on the borderline of "semantic". >> >> Thanks, >> Paul >> >> This usage brid >> >> L.Liess@telekom.de wrote: >>> Hi John and Adam, >>> >>> Thank you very much for your quick comments and proposals. >> My understanding is that modifications should be done to the >> charter proposal: >>> - short sentence in the charter about "semantic vs. >> non-semantic" >>> - add the use case "TDM gateway mapping from any legacy >> protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the >> edge of a network" >>> By adding the TDM gateway use case (which I think is a very >> good use case), my original assumptions that non-semantic >> Alert-Info URNs are: >>> - only sent by the proxy to end devices of its >> customers/end users and >>> - never sent end-to-end >>> are no longer valid. I have to remove the restriction for >> non-semantic Alert-Info URN identifiers derived from these >> assumptions. >>> Let's do a second trial for charter text changes: >>> 1) Add to the use cases: >>> " - special ringing tones, e. g. tones used in >> enterprise networks, tones used in some countries or tones >> from legacy protocols which TDM gateways must map to SIP at >> the edge of a network" >>> 2) Add folowing sentence: >>> " For better interoperability and flexibility, the >> Alert-Info URNs identifiers should be semantic whenever possible." >>> I am not absolutely happy with the formulation "whenever >> possible" because it is somehow imprecise, but I don't >> currently see any precise criteria to allow or disallow >> non-semantic URNs. Any better idea or can we leave it this >> way, at least for the charter? >>> Note: I did not ignore the comments about how the receiver >> handles unknown Alert-Info URN identifiers/portions, but I >> think this is part of the specification (requirements or UA >> behaviour), not of the charter, and I would postpone this >> discussion for now. >>> >>> Thanks a lot >>> Laura >>> >>> >>> >>> >>> >>>> I suspect the wording you propose below goes somewhat beyond >>>> what would be appropriate for charter text. However, you are >>>> correct in that the charter needs to say something about >>>> semantic versus non-semantic tones. >>>> >>>> In Hiroshima I heard a justification for non-semantic tones >>>> that is not captured below: cases where a TDM gateway detects >>>> a certain tone pattern and can only convey in SIP some >>>> characteristic of that pattern (e.g., "short"), rather than a >>>> specific meaning. This sounds like a more compelling use case >>>> for non-semantic tones than what is described below. >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: L.Liess@telekom.de [mailto:L.Liess@telekom.de] >>>>> Sent: 17 December 2009 15:43 >>>>> To: dispatch@ietf.org; Elwell, John; adam@nostrum.com >>>>> Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com; >>>>> alan@sipstation.com; R.Jesske@telekom.de; >>>> Martin.Huelsemann@telekom.de >>>>> Subject: Alert-Info URN charter issue >>>>> >>>>> >>>>> Hi, >>>>> >>>>> During the Alert-Info URN discussion in Hiroshima we had >>>>> consensus that there is interest in chartering a mini-WG on >>>>> Alert-Info URNs. However, we didn't come to an agreement >>>>> about whether or not we need to decide before chartering if >>>>> the Alert-Info URNs must be semantic. We need to clarify >>>>> this issue before submitting the charter proposal for Anaheim. >>>>> >>>>> Some thoughts on this: >>>>> - The decision wether or not we allow non-semantic >>>>> Alert-Info URNs is tightly coupled with which problems/use >>>>> cases we want to solve. The problem to be solved /use cases >>>>> must, as far as I know, be decided before chartering. >>>>> >>>>> - The Alert-Info URNs for use cases as call waiting and >>>>> other services, country ringback, priority ringing, are >>>>> semantic anyway. So these use cases are definitively in the >>>> charter. >>>>> - The critical use cases, for which we need non-semantic, >>>>> rendering-oriented Alert-Info URNs, are ringing tones used in >>>>> PBX-systems (e.g. "short", as described in §4.3.8 of the >>>>> draft) and in local exchanges in some countries (e.g. the TIA >>>>> ring tones described by Adam in >>>>> http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht >>>>> ml, which is not in the draft). In these use cases, the >>>>> Alert-Info URNs are not transmitted end-to-end, as, e.g. in >>>>> case of country ringback tones, but are sent by the >>>>> PBX-system or local exchange to an end device within its own >>>>> domain. In most cases, we can expect that the end device was >>>>> configured by the user or service provider how to handle the >>>>> rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. >>>>> >>>>> - Rendering-oriented ring tones as described above are use >>>>> cases which we encounter today and people will be implement >>>>> them in some way. If we do not provide a standard which can >>>>> be used for the implementation, people will provide >>>>> proprietary, non-interoperable solutions. For this reason, I >>>>> wouldn't like that the Alert-Info URN scheme we are going to >>>>> define can not be used to implement these use cases. This >>>>> does not imply that we should also define Alert-Info URN >>>>> identifiers for all these cases, but we should at least >>>>> define the scheme which can be used by other people to define >>>>> the specific identifiers. >>>>> >>>>> >>>>> Based on the thoughts above, I would propose to handle the >>>>> issue as follows: >>>>> >>>>> 1) Include into the charter, as one of the problems to be >>>>> solved: "special ring tones for incoming calls (used in >>>>> enterprise networks and in some countries) when the proxy and >>>>> the UAs are from different vendors with no external ring file >>>>> being used" >>>>> >>>>> 2) In the draft, define a requirement which states something >>>>> like that: >>>>> - Alert-Info URNs must be semantic whenever they are >>>>> used across different domains or if the sender has no reason >>>>> to assume that the receiver has the same understanding of >>>>> non-semantic Alert-Info URNs. >>>>> - Non-semantic, rendering-oriented Alert-Info URNs may >>>>> be used inside closed environements, when there are >>>>> predefined rules which define the semantic of a specific >>>>> rendering and the sender can expect that the receiver is able >>>>> to understand the rendering-oriented Alert-Info URNs. If an >>>>> UA receives an Alert-Info URN it does not understand, it >>>>> ignores the Alert-Info URN. >>>>> >>>>> >>>>> Is this an acceptable proposal or does anyone have a better >>>>> idea how to handle this issue? >>>>> >>>>> Thanks a lot >>>>> Laura >>>>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From L.Liess@telekom.de Tue Dec 22 04:41:33 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FFA3A68E2 for ; Tue, 22 Dec 2009 04:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qj0EFoAaAyo for ; Tue, 22 Dec 2009 04:41:31 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 18D923A690B for ; Tue, 22 Dec 2009 04:41:30 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 22 Dec 2009 13:41:04 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 13:41:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 22 Dec 2009 13:41:04 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003CD76A8@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4B2FC7E2.5000909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Alert-Info URN charter issue Thread-Index: AcqCcR0xrhkTxSW3QD+UEx0JLg7xFAAgZqDw References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de><40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003CD7388@S4DE9JSAANI.ost.t-com.de> <4B2FC7E2.5000909@cisco.com> From: To: X-OriginalArrivalTime: 22 Dec 2009 12:41:04.0784 (UTC) FILETIME=[06A19100:01CA8304] Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, R.Jesske@telekom.de Subject: Re: [dispatch] Alert-Info URN charter issue X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 12:41:33 -0000 Paul, It's a very nice idea and it shouldn't get lost. I will find a place = for it in the draft, overview or so. Maybe later someone will implement = a nice service with it.=20 Thanks a lot Laura > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, December 21, 2009 8:09 PM > To: Liess, Laura > Cc: dispatch@ietf.org; Jesske, Roland; H=FClsemann, Martin > Subject: Re: [dispatch] Alert-Info URN charter issue >=20 > Its just an idea of mine with no concrete needs. So whatever=20 > you want to=20 > do is fine with me. I certainly don't see any reason to delay needed=20 > work for it. >=20 > Thanks, > Paul >=20 > L.Liess@telekom.de wrote: > > Paul, > >=20 > > The idea sounds very interesting to me. I think the syntax=20 > and the rules for the Alert-Info URN should be flexible=20 > enough so that Alert-Info URN can be used later for use-cases=20 > as you described.=20 > >=20 > > I could add your description to the text of the draft, as=20 > an example of possible future use cases, but because I don't=20 > know of any real use case and the concrete requirements for=20 > it, I would not try to define now a concrete Alert-Info URN=20 > identifier. Maybe later, when somebody thinks about a real=20 > implementation in this direction. =20 > >=20 > > Is this OK for you?=20 > >=20 > >=20 > > Thanks a lot > > Laura > >=20 > > =20 > > =20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org=20 > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Friday, December 18, 2009 11:08 PM > >> To: Liess, Laura > >> Cc: dispatch@ietf.org; Jesske, Roland; H=FClsemann, Martin > >> Subject: Re: [dispatch] Alert-Info URN charter issue > >> > >> Perhaps this is more theoretical than real, but I have=20 > been imagining=20 > >> another broad use of "non-semantic" URNs: > >> > >> URNs that identify specific media "by name". For instance,=20 > is there a=20 > >> standard identifier for music, as there is an ISBN for books? I'm=20 > >> thinking of a name for a particular "work" independent of its=20 > >> specific=20 > >> rendering, such as "Beethoven's Fifth". You wouldn't want=20 > that entire=20 > >> thing as a ring tone, but maybe the first 4/8 note intro. You=20 > >> might want=20 > >> something longer for a ringback. > >> > >> This sort of alert could be used e2e, though there is no=20 > >> guarantee that=20 > >> the other end will understand it. Given a URN you don't=20 > >> understand, you=20 > >> could search out some definitions of it (possibly different=20 > >> renderings)=20 > >> and pick one you like. > >> > >> This sort of usage seems to be on the borderline of "semantic". > >> > >> Thanks, > >> Paul > >> > >> This usage brid > >> > >> L.Liess@telekom.de wrote: > >>> Hi John and Adam,=20 > >>> > >>> Thank you very much for your quick comments and proposals.=20 > >> My understanding is that modifications should be done to the=20 > >> charter proposal:=20 > >>> - short sentence in the charter about "semantic vs.=20 > >> non-semantic"=20 > >>> - add the use case "TDM gateway mapping from any legacy=20 > >> protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the=20 > >> edge of a network" > >>> By adding the TDM gateway use case (which I think is a very=20 > >> good use case), my original assumptions that non-semantic=20 > >> Alert-Info URNs are: > >>> - only sent by the proxy to end devices of its=20 > >> customers/end users and > >>> - never sent end-to-end=20 > >>> are no longer valid. I have to remove the restriction for=20 > >> non-semantic Alert-Info URN identifiers derived from these=20 > >> assumptions. =20 > >>> Let's do a second trial for charter text changes: > >>> 1) Add to the use cases: =20 > >>> " - special ringing tones, e. g. tones used in=20 > >> enterprise networks, tones used in some countries or tones=20 > >> from legacy protocols which TDM gateways must map to SIP at=20 > >> the edge of a network" =20 > >>> 2) Add folowing sentence:=20 > >>> " For better interoperability and flexibility, the=20 > >> Alert-Info URNs identifiers should be semantic whenever=20 > possible." =20 > >>> I am not absolutely happy with the formulation "whenever=20 > >> possible" because it is somehow imprecise, but I don't=20 > >> currently see any precise criteria to allow or disallow=20 > >> non-semantic URNs. Any better idea or can we leave it this=20 > >> way, at least for the charter? > >>> Note: I did not ignore the comments about how the receiver=20 > >> handles unknown Alert-Info URN identifiers/portions, but I=20 > >> think this is part of the specification (requirements or UA=20 > >> behaviour), not of the charter, and I would postpone this=20 > >> discussion for now.=20 > >>> > >>> Thanks a lot > >>> Laura > >>> > >>> > >>> =20 > >>> > >>> > >>>> I suspect the wording you propose below goes somewhat beyond=20 > >>>> what would be appropriate for charter text. However, you are=20 > >>>> correct in that the charter needs to say something about=20 > >>>> semantic versus non-semantic tones.=20 > >>>> > >>>> In Hiroshima I heard a justification for non-semantic tones=20 > >>>> that is not captured below: cases where a TDM gateway detects=20 > >>>> a certain tone pattern and can only convey in SIP some=20 > >>>> characteristic of that pattern (e.g., "short"), rather than a=20 > >>>> specific meaning. This sounds like a more compelling use case=20 > >>>> for non-semantic tones than what is described below. > >>>> > >>>> John > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > >>>>> Sent: 17 December 2009 15:43 > >>>>> To: dispatch@ietf.org; Elwell, John; adam@nostrum.com > >>>>> Cc: pkyzivat@cisco.com; Gonzalo.Camarillo@ericsson.com;=20 > >>>>> alan@sipstation.com; R.Jesske@telekom.de;=20 > >>>> Martin.Huelsemann@telekom.de > >>>>> Subject: Alert-Info URN charter issue > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> During the Alert-Info URN discussion in Hiroshima we had=20 > >>>>> consensus that there is interest in chartering a mini-WG on=20 > >>>>> Alert-Info URNs. However, we didn't come to an agreement=20 > >>>>> about whether or not we need to decide before chartering if=20 > >>>>> the Alert-Info URNs must be semantic. We need to clarify=20 > >>>>> this issue before submitting the charter proposal for Anaheim.=20 > >>>>> =20 > >>>>> Some thoughts on this:=20 > >>>>> - The decision wether or not we allow non-semantic=20 > >>>>> Alert-Info URNs is tightly coupled with which problems/use=20 > >>>>> cases we want to solve. The problem to be solved /use cases =20 > >>>>> must, as far as I know, be decided before chartering. =20 > >>>>> > >>>>> - The Alert-Info URNs for use cases as call waiting and=20 > >>>>> other services, country ringback, priority ringing, are=20 > >>>>> semantic anyway. So these use cases are definitively in the=20 > >>>> charter.=20 > >>>>> - The critical use cases, for which we need non-semantic,=20 > >>>>> rendering-oriented Alert-Info URNs, are ringing tones used in=20 > >>>>> PBX-systems (e.g. "short", as described in =A74.3.8 of the=20 > >>>>> draft) and in local exchanges in some countries (e.g. the TIA=20 > >>>>> ring tones described by Adam in=20 > >>>>> http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht > >>>>> ml, which is not in the draft). In these use cases, the=20 > >>>>> Alert-Info URNs are not transmitted end-to-end, as, e.g. in=20 > >>>>> case of country ringback tones, but are sent by the=20 > >>>>> PBX-system or local exchange to an end device within its own=20 > >>>>> domain. In most cases, we can expect that the end device was=20 > >>>>> configured by the user or service provider how to handle the=20 > >>>>> rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA. > >>>>> > >>>>> - Rendering-oriented ring tones as described above are use=20 > >>>>> cases which we encounter today and people will be implement=20 > >>>>> them in some way. If we do not provide a standard which can=20 > >>>>> be used for the implementation, people will provide=20 > >>>>> proprietary, non-interoperable solutions. For this reason, I=20 > >>>>> wouldn't like that the Alert-Info URN scheme we are going to=20 > >>>>> define can not be used to implement these use cases. This=20 > >>>>> does not imply that we should also define Alert-Info URN=20 > >>>>> identifiers for all these cases, but we should at least=20 > >>>>> define the scheme which can be used by other people to define=20 > >>>>> the specific identifiers. =20 > >>>>> > >>>>> > >>>>> Based on the thoughts above, I would propose to handle the=20 > >>>>> issue as follows: > >>>>> > >>>>> 1) Include into the charter, as one of the problems to be=20 > >>>>> solved: "special ring tones for incoming calls (used in=20 > >>>>> enterprise networks and in some countries) when the proxy and=20 > >>>>> the UAs are from different vendors with no external ring file=20 > >>>>> being used" =20 > >>>>> =20 > >>>>> 2) In the draft, define a requirement which states something=20 > >>>>> like that: > >>>>> - Alert-Info URNs must be semantic whenever they are=20 > >>>>> used across different domains or if the sender has no reason=20 > >>>>> to assume that the receiver has the same understanding of=20 > >>>>> non-semantic Alert-Info URNs.=20 > >>>>> - Non-semantic, rendering-oriented Alert-Info URNs may=20 > >>>>> be used inside closed environements, when there are=20 > >>>>> predefined rules which define the semantic of a specific=20 > >>>>> rendering and the sender can expect that the receiver is able=20 > >>>>> to understand the rendering-oriented Alert-Info URNs. If an=20 > >>>>> UA receives an Alert-Info URN it does not understand, it=20 > >>>>> ignores the Alert-Info URN.=20 > >>>>> > >>>>> > >>>>> Is this an acceptable proposal or does anyone have a better=20 > >>>>> idea how to handle this issue?=20 > >>>>> > >>>>> Thanks a lot > >>>>> Laura > >>>>> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > >=20 >=20 From HKaplan@acmepacket.com Tue Dec 22 07:42:26 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F8C3A69ED for ; Tue, 22 Dec 2009 07:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnOIBq9hyv3Z for ; Tue, 22 Dec 2009 07:42:26 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CE1483A680D for ; Tue, 22 Dec 2009 07:42:25 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 22 Dec 2009 10:42:08 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 22 Dec 2009 10:42:08 -0500 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Tue, 22 Dec 2009 10:42:06 -0500 Thread-Topic: I-D Action:draft-kaplan-dispatch-session-id-00.txt Thread-Index: AcqDG6xsgnWn63MYQ5SZ5sKy181S3gAAS0bw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_E6C2E8958BA59A4FB960963D475F7AC31A582F3CBDmail_" MIME-Version: 1.0 Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 15:42:26 -0000 --_002_E6C2E8958BA59A4FB960963D475F7AC31A582F3CBDmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, I've re-submitted a draft I originally submitted to the SIP WG back when it= was in existence. The draft defines a session correlation identifier for = troubleshooting purposes. =20 I'd like to have this dispatched to the appropriate WG, preferably the SIP-= CLF WG (since they're a prime customer of it). -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, December 22, 2009 10:30 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-kaplan-dispatch-session-id-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : A Session Identifier for the Session Initiation > Protocol (SIP) > Author(s) : H. Kaplan > Filename : draft-kaplan-dispatch-session-id-00.txt > Pages : 11 > Date : 2009-12-22 >=20 > There are several reasons for having a globally unique session > identifier for the same SIP session, which can be maintained across > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP > header to carry such a value: Session-ID. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- > 00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --_002_E6C2E8958BA59A4FB960963D475F7AC31A582F3CBDmail_ Content-Type: text/plain; name="draft-kaplan-dispatch-session-id-00.url.txt" Content-Description: draft-kaplan-dispatch-session-id-00.url.txt Content-Disposition: attachment; filename="draft-kaplan-dispatch-session-id-00.url.txt"; size=100; creation-date="Tue, 22 Dec 2009 10:30:21 GMT"; modification-date="Tue, 22 Dec 2009 10:30:21 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_002_E6C2E8958BA59A4FB960963D475F7AC31A582F3CBDmail_-- From richard@shockey.us Tue Dec 22 10:36:23 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323E53A688D for ; Tue, 22 Dec 2009 10:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6MMym+Gb09N for ; Tue, 22 Dec 2009 10:36:22 -0800 (PST) Received: from outbound-mail-132.bluehost.com (outbound-mail-132.bluehost.com [67.222.39.22]) by core3.amsl.com (Postfix) with SMTP id EAFC43A6861 for ; Tue, 22 Dec 2009 10:36:21 -0800 (PST) Received: (qmail 1951 invoked by uid 0); 22 Dec 2009 18:36:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 22 Dec 2009 18:36:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=kZ4hp9hiey5O7OvoYW1xb9+FsvEa497JqGupFtpVGEYKBUTvIDOYIw8K5b3sRVGWxmaRjKTYuArok4z12hejrAGTkKEpwGSTMNL7gXRFmF0xWrlErqT6FLU/pUC1TYP6; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NN9aX-0003Kw-0D; Tue, 22 Dec 2009 11:36:05 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , References: In-Reply-To: Date: Tue, 22 Dec 2009 13:36:03 -0500 Message-ID: <010201ca8335$9e5a3de0$db0eb9a0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqDG6xsgnWn63MYQ5SZ5sKy181S3gAAS0bwAAYp8TA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: Re: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 18:36:23 -0000 BIG +1 I never understood the objection to this idea. It helps solve a multitude of problems. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Tuesday, December 22, 2009 10:42 AM > To: dispatch@ietf.org > Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id- > 00.txt > > > Howdy, > I've re-submitted a draft I originally submitted to the SIP WG back > when it was in existence. The draft defines a session correlation > identifier for troubleshooting purposes. > > I'd like to have this dispatched to the appropriate WG, preferably the > SIP-CLF WG (since they're a prime customer of it). > > -hadriel > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Tuesday, December 22, 2009 10:30 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-kaplan-dispatch-session-id-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : A Session Identifier for the Session > Initiation > > Protocol (SIP) > > Author(s) : H. Kaplan > > Filename : draft-kaplan-dispatch-session-id-00.txt > > Pages : 11 > > Date : 2009-12-22 > > > > There are several reasons for having a globally unique session > > identifier for the same SIP session, which can be maintained across > > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP > > header to carry such a value: Session-ID. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session- > id- > > 00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. From spencer@wonderhamster.org Tue Dec 22 10:55:47 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC733A695D for ; Tue, 22 Dec 2009 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PlvOXhJNSfm for ; Tue, 22 Dec 2009 10:55:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8DFE73A68AA for ; Tue, 22 Dec 2009 10:55:46 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M23CF-1OGe1V3eY7-00tcZ1; Tue, 22 Dec 2009 13:55:22 -0500 Message-ID: From: "Spencer Dawkins" To: "Richard Shockey" , "'Hadriel Kaplan'" , References: <010201ca8335$9e5a3de0$db0eb9a0$@us> Date: Tue, 22 Dec 2009 12:55:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/fxvn/D+yiHlF3x4o9XqCBme3uatNqaPI5PUO rkun6+T9CGFeSQRBFdL9knYVosr5mHZbXHOvNgA0Wp+YbDe8/y cuUXqH9+bJH3lS0Frxdv2qtmXnLLXlqTq8LGNVVsTg= Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 18:55:47 -0000 I'm remembering that Hadriel had two drafts at about the same time - one was a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot of confusion during discussions. So I'm hoping that at least some of the objection was caused by confusion! https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just for the record... Thanks, Spencer ----- Original Message ----- From: "Richard Shockey" To: "'Hadriel Kaplan'" ; Sent: Tuesday, December 22, 2009 12:36 PM Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt > BIG +1 I never understood the objection to this idea. It helps solve a > multitude of problems. > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Tuesday, December 22, 2009 10:42 AM >> To: dispatch@ietf.org >> Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id- >> 00.txt >> >> >> Howdy, >> I've re-submitted a draft I originally submitted to the SIP WG back >> when it was in existence. The draft defines a session correlation >> identifier for troubleshooting purposes. >> >> I'd like to have this dispatched to the appropriate WG, preferably the >> SIP-CLF WG (since they're a prime customer of it). >> >> -hadriel >> >> >> > -----Original Message----- >> > From: i-d-announce-bounces@ietf.org >> > [mailto:i-d-announce-bounces@ietf.org] >> > On Behalf Of Internet-Drafts@ietf.org >> > Sent: Tuesday, December 22, 2009 10:30 AM >> > To: i-d-announce@ietf.org >> > Subject: I-D Action:draft-kaplan-dispatch-session-id-00.txt >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > >> > Title : A Session Identifier for the Session >> Initiation >> > Protocol (SIP) >> > Author(s) : H. Kaplan >> > Filename : draft-kaplan-dispatch-session-id-00.txt >> > Pages : 11 >> > Date : 2009-12-22 >> > >> > There are several reasons for having a globally unique session >> > identifier for the same SIP session, which can be maintained across >> > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP >> > header to carry such a value: Session-ID. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session- >> id- >> > 00.txt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Wed Dec 23 07:47:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448BB3A67F9 for ; Wed, 23 Dec 2009 07:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHy8XOjVBrlD for ; Wed, 23 Dec 2009 07:47:52 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 177FF3A67B2 for ; Wed, 23 Dec 2009 07:47:52 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 23 Dec 2009 10:47:34 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 23 Dec 2009 10:47:34 -0500 From: Hadriel Kaplan To: Spencer Dawkins , Richard Shockey , "dispatch@ietf.org" Date: Wed, 23 Dec 2009 10:47:33 -0500 Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: AcqDOFd4RIEl5CPDQfeiCDibC/SOIwArmVlw Message-ID: References: <010201ca8335$9e5a3de0$db0eb9a0$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:47:53 -0000 Yup, but they were really trying to solve two different problems, for diffe= rent issues. The secure-call-id one was trying to change the rfc3261 recommendation for = call-id creation, so that middleboxes like SBC's wouldn't need to change th= em for security purposes, and so that dialog matching works better. It won= 't make the call-id end-to-end though, because other B2BUAs/PBXs/etc. will = still change the call-id. The session-id was trying to create an identifier that crosses all boxes, f= or troubleshooting purposes. They sound similar, but they're not. -hadriel > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, December 22, 2009 1:55 PM > To: Richard Shockey; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id- > 00.txt >=20 > I'm remembering that Hadriel had two drafts at about the same time - one > was > a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot of > confusion during discussions. >=20 > So I'm hoping that at least some of the objection was caused by confusion= ! >=20 > https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and > https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just fo= r > the record... >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Richard Shockey" > To: "'Hadriel Kaplan'" ; > Sent: Tuesday, December 22, 2009 12:36 PM > Subject: Re: [dispatch] FW: > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 >=20 > > BIG +1 I never understood the objection to this idea. It helps solve a > > multitude of problems. > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Hadriel Kaplan > >> Sent: Tuesday, December 22, 2009 10:42 AM > >> To: dispatch@ietf.org > >> Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id- > >> 00.txt > >> > >> > >> Howdy, > >> I've re-submitted a draft I originally submitted to the SIP WG back > >> when it was in existence. The draft defines a session correlation > >> identifier for troubleshooting purposes. > >> > >> I'd like to have this dispatched to the appropriate WG, preferably th= e > >> SIP-CLF WG (since they're a prime customer of it). > >> > >> -hadriel > >> > >> > >> > -----Original Message----- > >> > From: i-d-announce-bounces@ietf.org > >> > [mailto:i-d-announce-bounces@ietf.org] > >> > On Behalf Of Internet-Drafts@ietf.org > >> > Sent: Tuesday, December 22, 2009 10:30 AM > >> > To: i-d-announce@ietf.org > >> > Subject: I-D Action:draft-kaplan-dispatch-session-id-00.txt > >> > > >> > A New Internet-Draft is available from the on-line Internet-Drafts > >> > directories. > >> > > >> > Title : A Session Identifier for the Session > >> Initiation > >> > Protocol (SIP) > >> > Author(s) : H. Kaplan > >> > Filename : draft-kaplan-dispatch-session-id-00.txt > >> > Pages : 11 > >> > Date : 2009-12-22 > >> > > >> > There are several reasons for having a globally unique session > >> > identifier for the same SIP session, which can be maintained across > >> > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP > >> > header to carry such a value: Session-ID. > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session- > >> id- > >> > 00.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME compliant mail reader > >> > implementation to automatically retrieve the ASCII version of the > >> > Internet-Draft. > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From spencer@wonderhamster.org Wed Dec 23 10:50:42 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C833A6926 for ; Wed, 23 Dec 2009 10:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+KsH4ctfrow for ; Wed, 23 Dec 2009 10:50:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6EB9E3A6817 for ; Wed, 23 Dec 2009 10:50:41 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MYhC6-1NRHUU04xO-00Vrdx; Wed, 23 Dec 2009 13:50:23 -0500 Message-ID: <42F5BF5843CA4ED6ADFAEEE6D60F3D05@china.huawei.com> From: "Spencer Dawkins" To: "Hadriel Kaplan" References: <010201ca8335$9e5a3de0$db0eb9a0$@us> Date: Wed, 23 Dec 2009 12:50:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+yoMxaSykVx/biWvQrNujoR+MLbXbO8U8CADH n8/M9Lsgh/unT+b9dXSiUQvk+5mgyiaE15BRej3DiSXexZ+I6k BPQSCEENCY0RBQpHF0Kh8mu+UF4H87lJC16lMPFzIU= Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:50:42 -0000 yeah, we still need to talk about the objections that weren't caused by confusion :-) spencer ----- Original Message ----- From: "Hadriel Kaplan" To: "Spencer Dawkins" ; "Richard Shockey" ; Sent: Wednesday, December 23, 2009 9:47 AM Subject: RE: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt Yup, but they were really trying to solve two different problems, for different issues. The secure-call-id one was trying to change the rfc3261 recommendation for call-id creation, so that middleboxes like SBC's wouldn't need to change them for security purposes, and so that dialog matching works better. It won't make the call-id end-to-end though, because other B2BUAs/PBXs/etc. will still change the call-id. The session-id was trying to create an identifier that crosses all boxes, for troubleshooting purposes. They sound similar, but they're not. -hadriel > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, December 22, 2009 1:55 PM > To: Richard Shockey; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id- > 00.txt > > I'm remembering that Hadriel had two drafts at about the same time - one > was > a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot of > confusion during discussions. > > So I'm hoping that at least some of the objection was caused by confusion! > > https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and > https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just for > the record... > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Richard Shockey" > To: "'Hadriel Kaplan'" ; > Sent: Tuesday, December 22, 2009 12:36 PM > Subject: Re: [dispatch] FW: > I-DAction:draft-kaplan-dispatch-session-id-00.txt > > > > BIG +1 I never understood the objection to this idea. It helps solve a > > multitude of problems. > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Hadriel Kaplan > >> Sent: Tuesday, December 22, 2009 10:42 AM > >> To: dispatch@ietf.org > >> Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id- > >> 00.txt > >> > >> > >> Howdy, > >> I've re-submitted a draft I originally submitted to the SIP WG back > >> when it was in existence. The draft defines a session correlation > >> identifier for troubleshooting purposes. > >> > >> I'd like to have this dispatched to the appropriate WG, preferably the > >> SIP-CLF WG (since they're a prime customer of it). > >> > >> -hadriel > >> > >> > >> > -----Original Message----- > >> > From: i-d-announce-bounces@ietf.org > >> > [mailto:i-d-announce-bounces@ietf.org] > >> > On Behalf Of Internet-Drafts@ietf.org > >> > Sent: Tuesday, December 22, 2009 10:30 AM > >> > To: i-d-announce@ietf.org > >> > Subject: I-D Action:draft-kaplan-dispatch-session-id-00.txt > >> > > >> > A New Internet-Draft is available from the on-line Internet-Drafts > >> > directories. > >> > > >> > Title : A Session Identifier for the Session > >> Initiation > >> > Protocol (SIP) > >> > Author(s) : H. Kaplan > >> > Filename : draft-kaplan-dispatch-session-id-00.txt > >> > Pages : 11 > >> > Date : 2009-12-22 > >> > > >> > There are several reasons for having a globally unique session > >> > identifier for the same SIP session, which can be maintained across > >> > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP > >> > header to carry such a value: Session-ID. > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session- > >> id- > >> > 00.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME compliant mail reader > >> > implementation to automatically retrieve the ASCII version of the > >> > Internet-Draft. > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Wed Dec 23 19:15:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC543A6895 for ; Wed, 23 Dec 2009 19:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWHiTAcCkJlJ for ; Wed, 23 Dec 2009 19:14:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9BA6A3A68AF for ; Wed, 23 Dec 2009 19:14:59 -0800 (PST) Received: from [192.168.2.100] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBO3Ed2n016826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Dec 2009 21:14:40 -0600 Message-ID: <4B32DC9B.3040406@softarmor.com> Date: Wed, 23 Dec 2009 21:14:35 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 03:15:00 -0000 Hadriel Kaplan wrote: > Howdy, > I've re-submitted a draft I originally submitted to the SIP WG back when it was in existence. The draft defines a session correlation identifier for troubleshooting purposes. > > I'd like to have this dispatched to the appropriate WG, preferably the SIP-CLF WG (since they're a prime customer of it). Process question: If we think it is roughly in-scope for the CLF working group, do we need to "dispatch" it? Or just ask on their list and let them decide on whether to get the AD to add it to their charter? And for what it is worth, I think we do need a session-correlator. Although I expect that somebody's SBC will remove it just for fun... -- Dean From L.Liess@telekom.de Thu Dec 24 02:54:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D031A3A6986 for ; Thu, 24 Dec 2009 02:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjpMVwxA0dwa for ; Thu, 24 Dec 2009 02:54:38 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 8E2CF3A6922 for ; Thu, 24 Dec 2009 02:54:36 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 24 Dec 2009 11:54:14 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 11:54:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 24 Dec 2009 11:54:12 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003CD7C4C@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4B32DC9B.3040406@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: AcqER0CbqrAUgX6MQbi6XzvRbCk6lwAMDlSA References: <4B32DC9B.3040406@softarmor.com> From: To: , X-OriginalArrivalTime: 24 Dec 2009 10:54:13.0749 (UTC) FILETIME=[6E2EC250:01CA8487] Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, R.Jesske@telekom.de Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 10:56:15 -0000 > And for what it is worth, I think we do need a session-correlator.=20 Session-ID is badly needed by the troubleshooting guys. It is also needed in 3GPP IMS for the conference service, for session correlation across SBCs and application servers. We already plan to implement the current version of the draft.=20 > Although I expect that somebody's SBC will remove it just for fun... I don't think so. People, also incumbent carriers, learn from implementation experience, and they are the main customers for SBCs. =20 > Process question: If we think it is roughly in-scope for the=20 > CLF working=20 > group, do we need to "dispatch" it? Or just ask on their list and let=20 > them decide on whether to get the AD to add it to their charter? I think this would make sense.=20 Laura =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Thursday, December 24, 2009 4:15 AM > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] FW:=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hadriel Kaplan wrote: > > Howdy, > > I've re-submitted a draft I originally submitted to the SIP=20 > WG back when it was in existence. The draft defines a=20 > session correlation identifier for troubleshooting purposes. =20 > >=20 > > I'd like to have this dispatched to the appropriate WG,=20 > preferably the SIP-CLF WG (since they're a prime customer of it). >=20 > Process question: If we think it is roughly in-scope for the=20 > CLF working=20 > group, do we need to "dispatch" it? Or just ask on their list and let=20 > them decide on whether to get the AD to add it to their charter? >=20 > And for what it is worth, I think we do need a session-correlator.=20 > Although I expect that somebody's SBC will remove it just for fun... >=20 > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From L.Liess@telekom.de Thu Dec 24 04:50:46 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F9A3A6905 for ; Thu, 24 Dec 2009 04:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjZwXA47p0g9 for ; Thu, 24 Dec 2009 04:50:46 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 383133A68D2 for ; Thu, 24 Dec 2009 04:50:46 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 24 Dec 2009 13:50:26 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 13:50:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 24 Dec 2009 13:50:25 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003CD7C70@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4B2EF2E2.7070905@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Alert-Info URN WG charter Thread-Index: AcqB8h5ulLbAd5ucQmajGDnkan4arwCmgK/A References: <40FB0FFB97588246A1BEFB05759DC8A003C90F4E@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003C9136F@S4DE9JSAANI.ost.t-com.de> <4B2BFD2E.4050009@cisco.com> <2E4A3E55-81D0-4B19-8893-DFE50594E19D@cs.columbia.edu> <4B2EF2E2.7070905@softarmor.com> From: To: X-OriginalArrivalTime: 24 Dec 2009 12:50:26.0780 (UTC) FILETIME=[AA6ED9C0:01CA8497] Subject: [dispatch] Alert-Info URN WG charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 12:50:46 -0000 Hi,=20 It seems to me that we reached a consensus on the "semantic vs. = non-semantic" issue, at least at the WG-charter level. Please find = attached the updated charter proposal: =20 The SIP Alert-Info URN (SAIU) working group is chartered to define a = new URN-scheme which allows SIP to convey a particular alert indication = using a name instead of a referenced URI. The Alert-Info URN solves = interoperability problems which we encounter today around the use of the = Alert-Info header field.=20 RFC 3261 allows a UAS or proxy to provide a specific = ring-/ringback-tone as a reference (e.g. HTTP URI) which can be played = to the user in the Alert-Info header.=20 This mechanism does not ensure interoperability when there is no = common understanding of the referenced content (different countries, = different vendors for the proxy and UAs, hearing impaired) or when the = user has his own tones configured in the end device. This is the case, = e.g. for: * ring-/ringback-tones which indicate services as call waiting, call = forwarding, blind transfer, automatic callback, call hold=20 * ring tones for emergency announcements sent over PBX systems or over = the local telephone network=20 * country-specific ringback tones * special ringing tones, e. g. ringing tones used in closed in = enterprise networks, ringing tones used in some countries or when TDM = gateways must map ring-/ringback-tones from legacy protocols to SIP at = the edge of a network There are a variety of URI conventions and proprietary Alert-Info = header field parameters to provide this today, all of which are = non-interoperable. =20 A standardized set of Alert-Info URNs will increase SIP = interoperability for this header field by replacing proprietary = conventions. The group will produce a specification which: * describes the problem statement * describes the requirements and the use cases we know about today * defines an Alert-Info URN-scheme which allows to solve the = interoperability problems described in the use cases * defines the specific Alert-Info URNs identifiers for some of the use = cases above The Alert-Info URN scheme must be open, so that additional Alert-Info = URN identifiers can be defined later if necessary. Whenever possible, = the Alert-Info URNs identifiers should be semantic. =20 Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Apr 2011 - Alert-Info URN specification to IESG (PS) =20 Please let me know what you think about it, if we can go ahead with it = for Anaheim, if you see open issues or if changes are needed.=20 Kind regards Laura=20 =20 From spencer@wonderhamster.org Thu Dec 24 08:01:52 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B393A68B5 for ; Thu, 24 Dec 2009 08:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb3T1Rke7lxY for ; Thu, 24 Dec 2009 08:01:45 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A23893A688B for ; Thu, 24 Dec 2009 08:01:45 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MSciy-1NXqXX2DkS-00S1lq; Thu, 24 Dec 2009 11:01:27 -0500 Message-ID: <36D784AAD47343248BE3274F64A101ED@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" , "Hadriel Kaplan" References: <4B32DC9B.3040406@softarmor.com> Date: Thu, 24 Dec 2009 10:01:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19bLo67QlQwmL3EEC83nBNXFiRnQ8roY405RxC gh35fKaXNzMfhJUoSMUGO3qs1Ls3DFhM71ixIywE2fu1e1gY+1 tYqnRlZZsMEYgftCVFt7oIkfOjxu1DPdEk84JWCcdU= Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 16:01:52 -0000 Speaking as sipclf co-chair, I've been assured by my AD that session ID is not part of what sipclf is currently chartered to do. I believe the "dispatching" part is for DISPATCH to say (1) this work matters, and (2) the right way to proceed is $PLAN... where $PLAN could be sending it to sipclf and adding it to the sipclf charter, but there can also be other $PLANs. I'm not clear what the boundaries of what needs to be dispatched are - but session ID isn't close to those boundaries! Spencer >> I'd like to have this dispatched to the appropriate WG, preferably the >> SIP-CLF WG (since they're a prime customer of it). > > Process question: If we think it is roughly in-scope for the CLF working > group, do we need to "dispatch" it? Or just ask on their list and let them > decide on whether to get the AD to add it to their charter? > > And for what it is worth, I think we do need a session-correlator. > Although I expect that somebody's SBC will remove it just for fun... > > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Thu Dec 24 08:36:31 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8883A68ED for ; Thu, 24 Dec 2009 08:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_50=0.001, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI-plCRj8R2H for ; Thu, 24 Dec 2009 08:36:30 -0800 (PST) Received: from outbound-mail-146.bluehost.com (outbound-mail-146.bluehost.com [67.222.38.36]) by core3.amsl.com (Postfix) with SMTP id B504B3A6880 for ; Thu, 24 Dec 2009 08:36:30 -0800 (PST) Received: (qmail 19408 invoked by uid 0); 24 Dec 2009 16:36:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 24 Dec 2009 16:36:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=O1zBKjmbLWm95OIfDoHEgm9JjIv6Mw4OkHZh0/43OXg/DipTjoSBO6XY29ge6WbVpe4rzu6/5fkE5W4h5OoO987d48gA95o1HhVf7BiYSfsFnXvuhUf9H5VwoZQ9INhQ; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NNqfc-0002wv-Sw; Thu, 24 Dec 2009 09:36:13 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Paul E. Jones'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> In-Reply-To: <4B32DEE9.5000302@softarmor.com> Date: Thu, 24 Dec 2009 11:36:11 -0500 Message-ID: <007301ca84b7$343dd6f0$9cb984d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqESKCTJBOCvkc8RXWRCJ9hm+tiBwAbAu2Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 16:36:32 -0000 The intent of the draft is to inform and clearly document to the IETF SIP community that "there is a problem" with fax in SIP networks. In fact, the problem seems to be much worse than some of us have originally believed. I recently met with several folks from the international wholesale carrier community (the i3forum ) who are reporting similar problems with fax in their networks. These issues have the potential for delaying significant SIP deployment in these networks, aka loss of sales for the supplier community. (hint) Let us not forget that fax is a essential communications service in the PSTN and that SIP networks MUST figure out ways to accommodate it. The SIP Forum Fax Task group is currently investigating the problems documented in the draft and taking additional input from all parties. Everyone in the IETF SIP Community is free to participate in this work. http://www.sipforum.org/content/view/310/252/ The goal is to develop a formal SIP Forum recommendation on what steps can be taken to fix the problems. If it is determined that either SIP or T.38 protocols needs to be modified in some way then a follow on document ( ID or ITU Liaison letter ) will be developed suggesting alternatives for consideration. With that follow up document in mind I do think is important to publish the fax problem statement as Informational. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, December 23, 2009 10:24 PM > To: Paul E. Jones > Cc: 'Richard Shockey'; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > problem-statement-00.txt > > Paul E. Jones wrote: > > Folks, > > > > I didn't see any comments regarding this draft. What is the opinion > about > > publishing this as an informational RFC? > > I'm sympathetic to the fax problem. > > But I'm not sure what the intent of publishing this draft as an RFC > might be. It reads more like a liaison statement from FaxTG to IETF > informing IETF of what FaxTG is working on. We have a less costly > pulication route for LS available that might be a better alternative > if > that's the case. > > If, however, you're leading towards another fax effort in IETF, then > it > might make sense to take this draft along the individual informational > route. > > -- > Dean From pkyzivat@cisco.com Thu Dec 24 12:33:58 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9BD3A6900; Thu, 24 Dec 2009 12:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns0UeDasYeEB; Thu, 24 Dec 2009 12:33:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EC3833A68F4; Thu, 24 Dec 2009 12:33:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEGAAtfM0tAZnwM/2dsb2JhbACZDaVbiQ0JjRSCSoFpBA X-IronPort-AV: E=Sophos;i="4.47,451,1257120000"; d="scan'208";a="76501701" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Dec 2009 20:33:36 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBOKXapF016840; Thu, 24 Dec 2009 20:33:36 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 15:33:36 -0500 Received: from [10.86.246.48] ([10.86.246.48]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 15:33:36 -0500 Message-ID: <4B33D01C.9000006@cisco.com> Date: Thu, 24 Dec 2009 15:33:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Shockey References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> In-Reply-To: <007301ca84b7$343dd6f0$9cb984d0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Dec 2009 20:33:36.0068 (UTC) FILETIME=[5E23B040:01CA84D8] Cc: "'Paul E. Jones'" , dispatch@ietf.org, sipcore@ietf.org Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 20:33:58 -0000 I know this is a bit off topic, and doesn't alleviate the problem, but has anybody ever proposed that an INVITE with offer for fax be responded to with a 3xx containing a mailto: URI? Or that ENUM for a fax device yield a mailto uri? Thanks, Paul Richard Shockey wrote: > The intent of the draft is to inform and clearly document to the IETF SIP > community that "there is a problem" with fax in SIP networks. In fact, the > problem seems to be much worse than some of us have originally believed. > > I recently met with several folks from the international wholesale carrier > community (the i3forum ) who are reporting similar problems with fax in > their networks. These issues have the potential for delaying significant SIP > deployment in these networks, aka loss of sales for the supplier community. > (hint) > > Let us not forget that fax is a essential communications service in the PSTN > and that SIP networks MUST figure out ways to accommodate it. > > The SIP Forum Fax Task group is currently investigating the problems > documented in the draft and taking additional input from all parties. > Everyone in the IETF SIP Community is free to participate in this work. > > http://www.sipforum.org/content/view/310/252/ > > The goal is to develop a formal SIP Forum recommendation on what steps can > be taken to fix the problems. If it is determined that either SIP or T.38 > protocols needs to be modified in some way then a follow on document ( ID or > ITU Liaison letter ) will be developed suggesting alternatives for > consideration. > > With that follow up document in mind I do think is important to publish the > fax problem statement as Informational. > > > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype: rshockey101 > LinkedIn : http://www.linkedin.com/in/rshockey101 > http//www.sipforum.org > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Wednesday, December 23, 2009 10:24 PM >> To: Paul E. Jones >> Cc: 'Richard Shockey'; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- >> problem-statement-00.txt >> >> Paul E. Jones wrote: >> > Folks, >> > >> > I didn't see any comments regarding this draft. What is the opinion >> about >> > publishing this as an informational RFC? >> >> I'm sympathetic to the fax problem. >> >> But I'm not sure what the intent of publishing this draft as an RFC >> might be. It reads more like a liaison statement from FaxTG to IETF >> informing IETF of what FaxTG is working on. We have a less costly >> pulication route for LS available that might be a better alternative >> if >> that's the case. >> >> If, however, you're leading towards another fax effort in IETF, then >> it >> might make sense to take this draft along the individual informational >> route. >> >> -- >> Dean > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From paulej@packetizer.com Thu Dec 24 13:27:34 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5FB3A6991; Thu, 24 Dec 2009 13:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htrgI40mGpfX; Thu, 24 Dec 2009 13:27:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 70E533A694A; Thu, 24 Dec 2009 13:27:32 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id nBOLR7bK009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Dec 2009 16:27:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1261690033; bh=DpPUed1p6h2R+rX8OF+Xlct9PWBG/JQRbBi//WkB/go=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BHVhf4qF6MAIvt7a/Um8un6OAohqWWPGge8AdsytCEz7JIadg78w1KVE7ZgsRjNjA AKenDWSXf8gqMAySx94QwPYq98PlRdmabQ8iL7Vz5JqXiVBwn2qEZCFy5V0WK+mrpo QZ97NisRfRyw2z/7uW1GodfKlklc9sbREeHUAL90= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id nBOLR6fS014233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Dec 2009 16:27:06 -0500 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Richard Shockey'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> In-Reply-To: <4B33D01C.9000006@cisco.com> Date: Thu, 24 Dec 2009 16:26:57 -0500 Message-ID: <002801ca84df$d2acbdb0$78063910$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqE2GjTh3dt4UyxQtKK1ILroEe7OwABDGxg Content-Language: en-us X-Mailman-Approved-At: Thu, 24 Dec 2009 13:53:08 -0800 Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 21:27:34 -0000 Paul, That could certainly be done and T.37 could be used on gateways to make that work. But, as you said, it does not fix the problem with T.38. Perhaps equally important, I think there are many, many businesses that will not be moving to email anytime soon. I wish they would -- that would solve this problem :-) Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, December 24, 2009 3:34 PM > To: Richard Shockey > Cc: 'Paul E. Jones'; dispatch@ietf.org; sipcore@ietf.org > Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum- > fax-problem-statement-00.txt > > I know this is a bit off topic, and doesn't alleviate the problem, but > has anybody ever proposed that an INVITE with offer for fax be > responded > to with a 3xx containing a mailto: URI? Or that ENUM for a fax device > yield a mailto uri? > > Thanks, > Paul > > Richard Shockey wrote: > > The intent of the draft is to inform and clearly document to the IETF > SIP > > community that "there is a problem" with fax in SIP networks. In > fact, the > > problem seems to be much worse than some of us have originally > believed. > > > > I recently met with several folks from the international wholesale > carrier > > community (the i3forum ) who are reporting similar problems with fax > in > > their networks. These issues have the potential for delaying > significant SIP > > deployment in these networks, aka loss of sales for the supplier > community. > > (hint) > > > > Let us not forget that fax is a essential communications service in > the PSTN > > and that SIP networks MUST figure out ways to accommodate it. > > > > The SIP Forum Fax Task group is currently investigating the problems > > documented in the draft and taking additional input from all parties. > > Everyone in the IETF SIP Community is free to participate in this > work. > > > > http://www.sipforum.org/content/view/310/252/ > > > > The goal is to develop a formal SIP Forum recommendation on what > steps can > > be taken to fix the problems. If it is determined that either SIP or > T.38 > > protocols needs to be modified in some way then a follow on document > ( ID or > > ITU Liaison letter ) will be developed suggesting alternatives for > > consideration. > > > > With that follow up document in mind I do think is important to > publish the > > fax problem statement as Informational. > > > > > > Richard Shockey > > Shockey Consulting > > Chairman of the Board of Directors SIP Forum > > PSTN Mobile: +1 703.593.2683 > > > > skype: rshockey101 > > LinkedIn : http://www.linkedin.com/in/rshockey101 > > http//www.sipforum.org > > > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Wednesday, December 23, 2009 10:24 PM > >> To: Paul E. Jones > >> Cc: 'Richard Shockey'; sipcore@ietf.org > >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > >> problem-statement-00.txt > >> > >> Paul E. Jones wrote: > >> > Folks, > >> > > >> > I didn't see any comments regarding this draft. What is the > opinion > >> about > >> > publishing this as an informational RFC? > >> > >> I'm sympathetic to the fax problem. > >> > >> But I'm not sure what the intent of publishing this draft as an RFC > >> might be. It reads more like a liaison statement from FaxTG to IETF > >> informing IETF of what FaxTG is working on. We have a less costly > >> pulication route for LS available that might be a better > alternative > >> if > >> that's the case. > >> > >> If, however, you're leading towards another fax effort in IETF, > then > >> it > >> might make sense to take this draft along the individual > informational > >> route. > >> > >> -- > >> Dean > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From richard@shockey.us Sat Dec 26 09:23:08 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09553A683F for ; Sat, 26 Dec 2009 09:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_50=0.001, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK44Evew+Rru for ; Sat, 26 Dec 2009 09:23:07 -0800 (PST) Received: from outbound-mail-150.bluehost.com (outbound-mail-150.bluehost.com [67.222.38.40]) by core3.amsl.com (Postfix) with SMTP id 233343A6804 for ; Sat, 26 Dec 2009 09:23:07 -0800 (PST) Received: (qmail 19382 invoked by uid 0); 26 Dec 2009 17:22:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 26 Dec 2009 17:22:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=QwSK0ioW5xGEHMvZ7fW+NIO+zGQ/Zj2xqmUGsynyYvv440yZFx0RT7qrhVJYrbQNOzOkve6c1UUUyHbaUP4qv/s11n/fptercNi14I9ZvaI4cbj7gfFC6/CGgKnpkQFU; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NOaLo-0003OP-7n; Sat, 26 Dec 2009 10:22:48 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> In-Reply-To: <4B33D01C.9000006@cisco.com> Date: Sat, 26 Dec 2009 12:22:47 -0500 Message-ID: <014c01ca8650$0bab1eb0$23015c10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqE2F9KlbLPPQV9SOqtJG2oa7TRbwBdHa8w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: "'Paul E. Jones'" , dispatch@ietf.org, sipcore@ietf.org Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 17:23:08 -0000 Paul its certainly not off topic and a reasonable idea, but not practical for a number of reasons. What you describe is a classic T.37 mode for fax that the old IETF Fax WG documented in RFC 3965. The problem is "non repudiation". Fax has a certain legal standing and there is the requirement that there be actual documentation that a fax was sent by foo at such and such a time to bar and that the service provider or appropriate intermediary can provide the appropriate documentation of such a transaction. The problem is becoming more acute due to a variety of regulations, HIPPA and USA SOX, real estate etal which require the transmission of a signature as part of a legal filing and no, digital signatures have not proven to be successful even though they have legal standing in most countries now. Health care records cannot be sent by email for privacy reasons especially test results. Fax is pretty simple and it works for these class of transactions. As a result my contacts in the fax industry have noted a minor resurgence in fax machine and fax port sales. Some of us years ago thought using a variant of the Internet Print Protocol, based on HTTP for real time document transmission would have been a better idea but that went nowhere as well. The issue is there something in SIP signaling that can alert the first hop what this session really is such as ;USER=FAX that can help. I don't know, that is what needs to be investigated. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, December 24, 2009 3:34 PM > To: Richard Shockey > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; > sipcore@ietf.org > Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- > forum-fax-problem-statement-00.txt > > I know this is a bit off topic, and doesn't alleviate the problem, but > has anybody ever proposed that an INVITE with offer for fax be > responded > to with a 3xx containing a mailto: URI? Or that ENUM for a fax > device > yield a mailto uri? > > Thanks, > Paul > > Richard Shockey wrote: > > The intent of the draft is to inform and clearly document to the > IETF SIP > > community that "there is a problem" with fax in SIP networks. In > fact, the > > problem seems to be much worse than some of us have originally > believed. > > > > I recently met with several folks from the international wholesale > carrier > > community (the i3forum ) who are reporting similar problems with fax > in > > their networks. These issues have the potential for delaying > significant SIP > > deployment in these networks, aka loss of sales for the supplier > community. > > (hint) > > > > Let us not forget that fax is a essential communications service in > the PSTN > > and that SIP networks MUST figure out ways to accommodate it. > > > > The SIP Forum Fax Task group is currently investigating the problems > > documented in the draft and taking additional input from all > parties. > > Everyone in the IETF SIP Community is free to participate in this > work. > > > > http://www.sipforum.org/content/view/310/252/ > > > > The goal is to develop a formal SIP Forum recommendation on what > steps can > > be taken to fix the problems. If it is determined that either SIP or > T.38 > > protocols needs to be modified in some way then a follow on document > ( ID or > > ITU Liaison letter ) will be developed suggesting alternatives for > > consideration. > > > > With that follow up document in mind I do think is important to > publish the > > fax problem statement as Informational. > > > > > > Richard Shockey > > Shockey Consulting > > Chairman of the Board of Directors SIP Forum > > PSTN Mobile: +1 703.593.2683 > > > > skype: rshockey101 > > LinkedIn : http://www.linkedin.com/in/rshockey101 > > http//www.sipforum.org > > > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Wednesday, December 23, 2009 10:24 PM > >> To: Paul E. Jones > >> Cc: 'Richard Shockey'; sipcore@ietf.org > >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > >> problem-statement-00.txt > >> > >> Paul E. Jones wrote: > >> > Folks, > >> > > >> > I didn't see any comments regarding this draft. What is the > opinion > >> about > >> > publishing this as an informational RFC? > >> > >> I'm sympathetic to the fax problem. > >> > >> But I'm not sure what the intent of publishing this draft as an > RFC > >> might be. It reads more like a liaison statement from FaxTG to > IETF > >> informing IETF of what FaxTG is working on. We have a less costly > >> pulication route for LS available that might be a better > alternative > >> if > >> that's the case. > >> > >> If, however, you're leading towards another fax effort in IETF, > then > >> it > >> might make sense to take this draft along the individual > informational > >> route. > >> > >> -- > >> Dean > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From dean.willis@softarmor.com Mon Dec 28 23:17:03 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5FE3A67A8 for ; Mon, 28 Dec 2009 23:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNYircx04T-E for ; Mon, 28 Dec 2009 23:17:01 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 61EE83A6784 for ; Mon, 28 Dec 2009 23:17:00 -0800 (PST) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBT7Ga1Z024055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Dec 2009 01:16:38 -0600 Message-ID: <4B39ACCB.40603@softarmor.com> Date: Tue, 29 Dec 2009 01:16:27 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: L.Liess@telekom.de References: <4B32DC9B.3040406@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003CD7C4C@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003CD7C4C@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: R.Jesske@telekom.de, dispatch@ietf.org, Martin.Huelsemann@telekom.de, HKaplan@acmepacket.com Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 07:17:03 -0000 L.Liess@telekom.de wrote: > Dean Said: > > Although I expect that somebody's SBC will remove it just for > fun... > I don't think so. People, also incumbent carriers, learn from > implementation experience, and they are the main customers for SBCs. My experience with incumbent carriers is much less hopeful. As far as I can tell, they only learn from new legislation or regulation, and then ony when fined large amounts for ignoring the rules. Are we aware of any regulators willing to issue large fines for removing the proposed session-OD? -- Dean From dean.willis@softarmor.com Mon Dec 28 23:22:54 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CE03A66B4; Mon, 28 Dec 2009 23:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOId-Y5QtpUE; Mon, 28 Dec 2009 23:22:53 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1CCBB3A67A8; Mon, 28 Dec 2009 23:22:53 -0800 (PST) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBT7MUuL024126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Dec 2009 01:22:32 -0600 Message-ID: <4B39AE2C.9090304@softarmor.com> Date: Tue, 29 Dec 2009 01:22:20 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> In-Reply-To: <4B33D01C.9000006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Paul E. Jones'" , dispatch@ietf.org, sipcore@ietf.org Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 07:22:54 -0000 Paul Kyzivat wrote: > I know this is a bit off topic, and doesn't alleviate the problem, but > has anybody ever proposed that an INVITE with offer for fax be responded > to with a 3xx containing a mailto: URI? Or that ENUM for a fax device > yield a mailto uri? I was going to say "redirect to T.37, since real-time fax over VoIP is just a bad idea" but Paul beat me to it. Seriously: fax over IP really only works when the real-time conversion is done close to the edge of the IP network. and the core transit is store-and-forward/ The close to the consumer edge, the better. Trying to retrofit the timing equirements of fax onto RTP is an exercise in futility for those who don't understand the concept of lossy networks. -- Dean From L.Liess@telekom.de Tue Dec 29 03:36:59 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA323A68A8 for ; Tue, 29 Dec 2009 03:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZS6O06WOD4t for ; Tue, 29 Dec 2009 03:36:58 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id B0F103A6827 for ; Tue, 29 Dec 2009 03:36:57 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 29 Dec 2009 12:36:30 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Dec 2009 12:36:30 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Dec 2009 12:36:26 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003CD8091@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4B39ACCB.40603@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt thread-index: AcqIVuFnlisyR48KTqG4X7g5kX+QQAACiE2Q References: <4B32DC9B.3040406@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003CD7C4C@S4DE9JSAANI.ost.t-com.de> <4B39ACCB.40603@softarmor.com> From: To: X-OriginalArrivalTime: 29 Dec 2009 11:36:30.0468 (UTC) FILETIME=[2A401C40:01CA887B] Cc: R.Jesske@telekom.de, dispatch@ietf.org, Martin.Huelsemann@telekom.de, HKaplan@acmepacket.com Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 11:36:59 -0000 Dean, > Are we aware of any regulators willing to issue large fines=20 > for removing=20 > the proposed session-OD? Personally, I see two scenarios which may lead to the Session-ID being = removed: 1) I, don't expect such rules from regulators, rather the other way = round. Regulators want control and legal interception and personal data = privacy.=20 Imagine some bad guys use the session-ID to send pornographic stuff = end-to-end. Then the regulator will require carriers to disalow = SIP-Headers with such content. What could a carrier do? Session-ID is a = Hash and the carrier can not inspect its content and sort out just the = "bad" Session-IDs. Probably in this case the first SBC in the network = will have to drop the end device generated Session-ID and generate a new = Session ID. Unfortunatly, not very e2e friendly. But do you see a = better, more end-device-friendly solution, for this problem?=20 2) Another problem may occur is with SBCs and B2BUAswhich are = Session-ID non-aware (e.g. application servers). Many of them use = positive rather then negative lists do decide what to drop and what to = pass to the next hop. They drop headers which they don't know, exactly = as the PSTN-switches did. Maybe this will change some time (from my = point of view this is, in practice, a money machine for vendors and = quite expensive for carriers), but this is what we have today. When such = SBCs and B2BUAs are not upgraded with regard to Session ID, they will = drop it, just because they don't know it. I think we can help to = minimize the number of boxes which do not support Session-ID and drop = it, by trying to reach soon a stable version of the draft, which can be = used as a reference for vendors and monitoring systems. Despite these problems, I am quite optimistic concerning the Session-ID: = =20 In the DT SIP network all, nodes will be upgraded to support the = Session-ID because this is required by both customer support and by the = sequrity guys to improve the customer service.=20 =20 - When a customer calls the customer support "My call to....could = not be set up" the support must trace all SIP messages of this call e2e. = This is not possible without an e2e identifier. (I know, in part a = self-made problem, but only in part. Regulators require legal = interception and Callling Line Identification Restriction. One needs = B2BUAs to do this. Maybe not so many of them...)=20 - When customers complain about being charged for calls to special = numbers they didn't call, we have, in most cases, to deal with stolen = user-id and password. The security guys need to go through old traces = and reconstruct the calls e2e. Session-ID is needed to improve the customer service, so is for DT a = "must". I don't now what other carriers do, but I think they have, or = will have soon, similar problems. But I think people will use = Session-ID, as soon as the draft has a stable status. =20 Thanks a lot Laura =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, December 29, 2009 8:16 AM > To: Liess, Laura > Cc: HKaplan@acmepacket.com; dispatch@ietf.org; H=FClsemann,=20 > Martin; Jesske, Roland > Subject: Re: [dispatch] FW:=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > L.Liess@telekom.de wrote: >=20 > > Dean Said: > > > Although I expect that somebody's SBC will remove it just for > > fun... > > I don't think so. People, also incumbent carriers, learn from > > implementation experience, and they are the main customers=20 > for SBCs. =20 >=20 > My experience with incumbent carriers is much less hopeful.=20 > As far as I=20 > can tell, they only learn from new legislation or regulation,=20 > and then=20 > ony when fined large amounts for ignoring the rules. >=20 > Are we aware of any regulators willing to issue large fines=20 > for removing=20 > the proposed session-OD? From kcartwright@tnsi.com Tue Dec 29 14:25:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531243A68EC for ; Tue, 29 Dec 2009 14:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_50=0.001, HTML_MESSAGE=0.001, OBFUSCATING_COMMENT=0.973] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iezs0OfBwDD2 for ; Tue, 29 Dec 2009 14:24:49 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 672A03A68B7 for ; Tue, 29 Dec 2009 14:24:48 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.38971684; Tue, 29 Dec 2009 17:29:48 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 29 Dec 2009 17:24:20 -0500 From: "Cartwright, Kenneth" To: "dispatch@ietf.org" Date: Tue, 29 Dec 2009 17:24:17 -0500 Thread-Topic: Re: [dispatch] E2M: Proposed Charter (draft version only) Thread-Index: AcqI1aj2UP220S/qSs+59UsL8OTiGw== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA091AB63873@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA091AB63873TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [dispatch] E2M: Proposed Charter (draft version only) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 22:25:00 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA091AB63873TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernie, Thanks for offering up the food for thought captured in the proposal. I th= ink that the first time I heard E2M proposed was at the ENUM meeting at Dub= lin. At first blush, I liked the concept, due to the clutter that seemed t= o me to be gathering in E2U (er E2Everything). However, after considering = it further, my reservations about this proposed charter are as follows: It is being built around a pre-assumed solution, DDDS with "E2M" as the DDD= S application name, without first fully understanding and characterizing th= e problem that needs to be solved. And without first understanding and cha= racterizing the problem that needs to be solved, we are not likely to selec= t the correct solution. More specifically, DNS has shortcomings when attem= pting to use it simply as a generic distributed database, as DDDS attempts = to do. These shortcomings include: (1) only strings formed like domain nam= es can be used as lookup keys (a severe limitation that is completely un-ne= cessary), (2) no good way to identify the source of the lookup, (3) no XML = like structure to the responses to allow for richer response data, (4) only= supports key lookups, no ability to support queries. Are those shortcomings going to get in the way of E2M's usefulness as new s= ervice types and subtypes are introduced, and new uses cases arise? I thin= k that is very possible. To add further weight to this point, look at the = core Domain Name System (.com, .org, .net, .biz, .info, etc, etc). The gro= ups of companies and organizations that defined, implemented and run that s= ystem (*the* prototypical DNS system) did not even use DNS to serve up meta= data about their domain names. They chose protocols like WhoIs, EPP, and I= RIS. They did not choose to use their DNS systems to store or query/resolv= e for metadata about domain names. That is very telling. What I do like about DDDS, however, is the design and administrative proces= ses that allow for the introduction, review, and approval of new "data elem= ent sets" (i.e. service types and their contained elements). However, this= can also be accomplished using design constructs of XML (see IRIS and EPP = as examples) and similar administrative policies. Another alluring, but mi= sleading, aspect of creating another ENUM like DDDS service is that we all = have bind servers and we all understand ENUM well and we've all implemented= it. But that also can lead to us falling into the everything-looks-like-a= -nail-to-me-if-my-favorite-tool-is-my-hammer trap. In short, you are right on the money that we very much do need to get the V= oIP/ENUM/PSTN data/metadata service problem scoped, defined, and solved. H= owever, I do not think another DDDS/DNS based solution is the *best* soluti= on. Please look at RFCs 4698 and 3981 as food for thought. Ken =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * From: Bernie Hoeneisen > * To: IETF DISPATCH list > * Date: Tue, 15 Dec 2009 20:28:57 +0100 (CET) size=3D2 width=3D"100%" align=3Dcenter> Hi, As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for an E2M = charter (draft) for discussion on this mailing list. Have fun! cheers, Bernie --- E.164 to Metadata (E2M) (proposed charter / draft state) ----------------------- Last Modified: 2009-12-15 Additional information is available at tools.ietf.org/wg/e2m [not yet in use] Chair(s): * TBA Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: General Discussion: e2m at ietf.org [not yet in use] To Subscribe: e2m-request at ietf.org [not yet in use] In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/e2m/index.html [not yet in use] Description of Working Group: Abstract E.164 to Metadata (E2M) will use of the Domain Name System (DNS) for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. Background ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. Thus, ENUM can be used to look up the services associated with an E.164 number. However, it is controversial whether or not the result of an ENUM lookup should always be intended to establish a communications session using the URI found in the corresponding Naming Authority Pointer (NAPTR) DNS Resource Record (RR). Problem Statement Several proposals for Enumservice registrations do not fulfill the above mentioned interpretation, which suggests that an ENUM lookup should always be intended to result in a communications session. These proposals are therefore virtually locked in the process. Such proposals include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, and 'send-n' to describe the structure of an ENUM tree. Another issue is that the result of an ENUM (E2U) lookup always needs to be an URI, which unnecessarily complicates simple mappings. The authors of such Enumservice proposals tried to circumvent the issues by introducing the 'data' URI scheme or inventing completely new URI schemes, with limited success however. The main objection remained that an ENUM lookup should always result in a URI intended to establish a communications session. Proposal The E2M Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application E2M, which can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. The resulting metadata can be used (for example) to provide hints about properties of certain ENUM domains or to provide information that can be used as attributes of an E.164 number. E2M will provide the means for services related to E.164 numbers that do not fit into the concept of ENUM (E2U), and thus a way forward for such existing ENUM WG documents in the queue. Along with the E2M DDDS application a new IANA registry will be specified for registration of E2M services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similarly as specified for Enumservice registrations. The E2M specifications shall reuse a much as possible from the ENUM DDDS and its IANA registry specification. The E2M Working Group may take on further proposals for E2M service registrations (e.g. send-n) until the IANA registration for E2M services is approved by the IESG. Goals and Milestones: Aug 2010 Submit Internet Draft(s) for the E2M DDDS application and its IANA registry specification Dec 2010 Submit 'cnam' and 'unused' as E2M service registrations (Informational) XXX 2011 Close the E2M Working Group (or recharter) Internet-Drafts: http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-01 http://tools.ietf.org/html/draft-ietf-enum-unused-04 http://tools.ietf.org/html/draft-ietf-enum-cnam-08 (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) Request For Comments: None size=3D2 width=3D"100%" align=3Dcenter> * Follow-Ups: * Re: [dispatch] E2M: Proposed Charter (draft version only) * From: Richard Shockey * Prev by Date: Re: [dispatch] [Enum] E2M: Find a proper home for draft-= hoeneisen-e164-to-metadata-01.txt * Next by Date: Re: [dispatch] [Enum] E2M: Find a proper home for draft-= hoeneisen-e164-to-metadata-01.txt * Previous by thread: [dispatch] E2M: Find a proper home for draft-hoene= isen-e164-to-metadata-01.txt * Next by thread: Re: [dispatch] E2M: Proposed Charter (draft version on= ly) * Index(es): * Date * Thread Note Well: Messages sent to this mailing list are the opinions of the sende= rs and do not imply endorsement by the IETF. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA091AB63873TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Bernie,=

Thanks for offering up the food for thoug= ht captured in the proposal.  I think that the first time I heard E2M proposed was at the ENUM meeting at Dublin.  At first blush,= I liked the concept, due to the clutter that seemed to me to be gathering = in E2U (er E2Everything).  However, after considering it further, my r= eservations about this proposed charter are as follows:

It is being built around a pre-assumed so= lution, DDDS with “E2M” as the DDDS application name, without first fully understanding and characterizing the problem tha= t needs to be solved.  And without first understanding and characteriz= ing the problem that needs to be solved, we are not likely to select the co= rrect solution.  More specifically, DNS has shortcomings when attempting to use it simply as a generic distributed= database, as DDDS attempts to do.  These shortcomings include: (1) on= ly strings formed like domain names can be used as lookup keys (a severe li= mitation that is completely un-necessary), (2) no good way to identify the source of the lookup, (3) no XML like stru= cture to the responses to allow for richer response data, (4) only supports= key lookups, no ability to support queries.

Are those shortcomings going to get in th= e way of E2M’s usefulness as new service types and subtypes are introduced, and new uses cases arise?  I think that = is very possible.  To add further weight to this point, look at the co= re Domain Name System (.com, .org, .net, .biz, .info, etc, etc).  The = groups of companies and organizations that defined, implemented and run that system (*the* prototypical DNS system) did not ev= en use DNS to serve up metadata about their domain names.  They chose = protocols like WhoIs, EPP, and IRIS.  They did not choose to use their= DNS systems to store or query/resolve for metadata about domain names.  That is very telling.=

What I do like about DDDS, however, is th= e design and administrative processes that allow for the introduction, review, and approval of new “data elemen= t sets” (i.e. service types and their contained elements).  Howe= ver, this can also be accomplished using design constructs of XML (see IRIS= and EPP as examples) and similar administrative policies.  Another alluring, but misleading, aspect of creating anoth= er ENUM like DDDS service is that we all have bind servers and we all under= stand ENUM well and we’ve all implemented it.  But that also can= lead to us falling into the everything-looks-like-a-nail-to-me-if-my-favor= ite-tool-is-my-hammer trap.

In short, you are right on the money that= we very much do need to get the VoIP/ENUM/PSTN data/metadata service problem scoped, defined, and solved.  However, = I do not think another DDDS/DNS based solution is the *best* solution.  Please look at RFCs 4698 a= nd 3981 as food for thought.

Ken

 <= /p>

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

size=3D2 width=3D&quo= t;100%" align=3Dcenter> 
Hi,
 

As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for= an E2M charter (draft) for discussion on this mailing list. 

 
Have fun!
 
cheers,
 Bernie
 
---
 
E.164 to Metadata (E2M) (proposed charter / draft state)=

-----------------------
 
Last Modified: 2009-12-15
 
Additional information is available at tools.ietf.org/wg/e2m
[not yet in use]
 
 
Chair(s):
 
    * TBA
 
Real-time Applications and Infrastructure Area Director(s):
 
    * Robert Sparks <rjsparks at nostrum.com>
    * Cullen Jennings <fluffy at cisco.com>
 
Real-time Applications and Infrastructure Area Advisor:<=
/font>
 
    * Cullen Jennings <fluffy at cisco.com>
 
 
Mailing Lists:
 
General Discussion: e2m at ietf.org [not yet in use]
To Subscribe: e2m-request at ietf.org [not yet in use]
In Body: subscribe
Archive: h=
ttp://www.ietf.org/mail-archive/web/e2m/index.html
         [not yet in use]
 
 
Description of Working Group:
 
Abstract
 
   E.164 to Metadata (E2M) will use of the Domain Name System (D=
NS)
   for resolving E.164 numbers into metadata to provide informat=
ion
   about E.164 numbers in cases where E.164 Number to URI Mappin=
g
   (ENUM) can not be used.
 
 
Background
 
   ENUM provides an identifier mapping mechanism to map E.164 nu=
mbers
   to Uniform Resource Identifiers (URIs) using the DNS.
 
   Thus, ENUM can be used to look up the services associated wit=
h an
   E.164 number.  However, it is controversial whether or n=
ot the result
   of an ENUM lookup should always be intended to establish a
   communications session using the URI found in the correspondi=
ng
   Naming Authority Pointer (NAPTR) DNS Resource Record (RR).
 
 
Problem Statement
 
   Several proposals for Enumservice registrations do not fulfil=
l the
   above mentioned interpretation, which suggests that an ENUM l=
ookup
   should always be intended to result in a communications sessi=
on.
   These proposals are therefore virtually locked in the process=
.
   Such proposals include (but are not limited to) Enumservices =
for
   'cnam' to provide information about the calling party name,
   'unused' to provide a hint that a number is not in use, and
   'send-n' to describe the structure of an ENUM tree.
 
   Another issue is that the result of an ENUM (E2U) lookup alwa=
ys
   needs to be an URI, which unnecessarily complicates simple ma=
ppings.
 
   The authors of such Enumservice proposals tried to circumvent=
 the
   issues by introducing the 'data' URI scheme or inventing comp=
letely
   new URI schemes, with limited success however.  The main=
 objection
   remained that an ENUM lookup should always result in a URI in=
tended
   to establish a communications session.
 
Proposal
 
   The E2M Working Group is chartered to develop a new Dynamic
   Delegation Discovery System (DDDS) application E2M, which can=
 be
   used with DNS NAPTR RRs for resolving E.164 numbers into meta=
data.
   The resulting metadata can be used (for example) to provide h=
ints
   about properties of certain ENUM domains or to provide inform=
ation
   that can be used as attributes of an E.164 number.=

 
   E2M will provide the means for services related to E.164 numb=
ers
   that do not fit into the concept of ENUM (E2U), and thus a
   way forward for such existing ENUM WG documents in the queue.=

 
   Along with the E2M DDDS application a new IANA registry will =
be
   specified for registration of E2M services. The registration =
policy
   shall be Expert Review and Specification Required (see RFC 52=
26),
   similarly as specified for Enumservice registrations.
 
   The E2M specifications shall reuse a much as possible from th=
e ENUM
   DDDS and its IANA registry specification.
 
   The E2M Working Group may take on further proposals for E2M s=
ervice
   registrations (e.g. send-n) until the IANA registration for E=
2M
   services is approved by the IESG.

 


 


Goals and Milestones:


 


   Aug 2010  Submit Internet Draft(s) for the E2M DDDS appl=
ication and


             i=
ts IANA registry specification


 


   Dec 2010  Submit 'cnam' and 'unused' as E2M service regi=
strations


             (=
Informational)


 


   XXX 2011  Close the E2M Working Group (or recharter)


 


 


Internet-Drafts:


 


   http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-0=
1


   http://tools.ietf.org/html/draft-ietf-enum-unused-04


   http://tools.ietf.org/html/draft-ietf-enum-cnam-08<=
/font>


   (http://tools.ietf.org/html/draft-bellis-enum-send-n-02)


 


 


Request For Comments:


 


   None


 


size=3D2 w=
idth=3D"100%" align=3Dcenter>







Note Well: Message=
s sent to this mailing list are the opinions of the senders and do not impl=
y endorsement by the IETF.


 

This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA091AB63873TNSMAILNAwin2_--