From john.elwell@siemens-enterprise.com Thu Oct 1 00:33: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 0DDDA3A67FD for ; Thu, 1 Oct 2009 00:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 ZWXQ4nL+IOsW for ; Thu, 1 Oct 2009 00:33:14 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id C98CE3A67A1 for ; Thu, 1 Oct 2009 00:33:13 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n917YYAc016177; Thu, 1 Oct 2009 09:34:34 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n917YY9v031361; Thu, 1 Oct 2009 09:34:34 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Thu, 1 Oct 2009 09:34:33 +0200 From: "Elwell, John" To: Cullen Jennings Date: Thu, 1 Oct 2009 09:34:32 +0200 Thread-Topic: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted Thread-Index: AcpCIZaG3Uf0se6DRsybegN3pSicXQAQr+ZA Message-ID: <7402509E63C5A145A6095D46C179A5B71006480F@DEMCHP99E35MSX.ww902.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 01 Oct 2009 07:33:15 -0000 Cullen, > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 30 September 2009 23:58 > To: Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted >=20 >=20 > John, >=20 > I think this is going the right direction, but few comments. >=20 > Req 5 is too vague to be of any use. If this was replaced with =20 > something like "The solution must allow for media steering", that =20 > would make sense to me [JRE] There is also a note that says "the precise identification of element= s of a SIP message that must be allowed to change is for further study, but= is expected to include at least those parts of SDP that are changed in ord= er to accomplish media steering." However, I think we can delete the note and change the requirement to say: "The solution MUST work when a call traverses multiple domains, including c= ases where domains perform media steering." If folks consider there are other aspects of traversing intermediate domain= s that need to be accommodated, they should identify them and get them expl= icitly put into the requirement. >=20 > On Req 4 - I don't think it is just the sink/source of the media. It =20 > seems that just about anything that is meant to be end to end=20 > you want =20 > bound to the identity. Imagine an page mode IM. In that case the =20 > "media" is the message and you want that bound to the caller id. [JRE] This document focuses on caller identification (see abstract), as dis= tinct from sender identification (see 4th/5th paragraphs of Intro), because= that is where SIP Identity suffers deployment difficulties. Caller identif= ication does need to be linked to sensitive end-to-end information sent by = the caller during a call, even if it is sent in SIP messages rather than as= media, and to this end I plan to add: "REQx - It MUST be possible to bind sensitive end-to-end information sent b= y the calling UA in call-related SIP messages to an asserted caller identif= ication." (and of course existing REQ6 covers the corresponding connected identificat= ion case). This leaves call-unrelated messages (e.g., for page mode IM), and this isn'= t really addressed by the I-D at all. I will add to the start of the Requir= ements section the following statement: "These requirements are not intended to replace any existing sender identif= ication requirements for SIP messages outside the context of a call (e.g., = using the MESSAGE method)." When I spoke to you privately recently, you indicated that you would like t= o see the requirements expressed at a higher level, e.g., in terms of confi= dentiality, integrity protection, etc.. To address this, I was planning to = insert three new requirements in front of the existing requirements, along = the lines of: " REQ1 - It MUST be possible to ensure that sensitive information sen= t and received during a call cannot be eavesdropped by a third party (confi= dentiality) and assert such a property to a caller or called user. REQ2 - It MUST be possible to ensure that information sent and recei= ved during a call is not inserted, modified or deleted by a third party (in= tegrity) and assert such a property to a caller or called user. REQ3 - It MUST be possible to provide a called user with verified in= formation identifying the party to which information is sent and from which= information is received during a call (authenticated caller identification= )." If you still have such a concern, would the above additional requirements g= o some way towards satisfying it? Thanks, John From R.Jesske@telekom.de Thu Oct 1 06:33: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 CD10628C0F2 for ; Thu, 1 Oct 2009 06:33:31 -0700 (PDT) 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=[AWL=0.000, 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 20cvvdU8Otux for ; Thu, 1 Oct 2009 06:33:31 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 8781828C1A3 for ; Thu, 1 Oct 2009 06:33:29 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 01 Oct 2009 15:34:49 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 15:34:48 +0200 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, 1 Oct 2009 15:34:42 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4050707AD@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1254171015.3866.37.camel@khone.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New draft version ofdraft-jesske-dispatch-reason-in-responses-00 Thread-Index: AcpAfU0WjmaRxjQERla9umTL5XDE1QCHoBVw References: <9886E5FCA6D76549A3011068483A4BD404EE1E67@S4DE8PSAAQB.mitte.t-com.de> <1254171015.3866.37.camel@khone.us.nortel.com> From: To: X-OriginalArrivalTime: 01 Oct 2009 13:34:48.0575 (UTC) FILETIME=[F24988F0:01CA429B] Cc: dispatch@ietf.org Subject: Re: [dispatch] New draft version ofdraft-jesske-dispatch-reason-in-responses-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, 01 Oct 2009 13:33:31 -0000 Hi Dale, Thank you fo yor comment. I will update the abstract with th enext = version. Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: Dale Worley [mailto:dworley@nortel.com]=20 Gesendet: Montag, 28. September 2009 22:50 An: Jesske, Roland Cc: dispatch@ietf.org Betreff: Re: [dispatch] New draft version = ofdraft-jesske-dispatch-reason-in-responses-00 On Mon, 2009-09-14 at 13:10 +0200, R.Jesske@telekom.de wrote: > A since a couple of weeks a new version of the Reason in Responses > draft is now available. >=20 > = http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-00 >=20 > I have incorporated all comments and the discussion conclusions > received for this draft. There seems to be quite a bit of duplicated text in the Abstract. Dale From mary.barnes@nortel.com Thu Oct 1 06:55: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 369563A688B for ; Thu, 1 Oct 2009 06:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 ZamTKAmwM-wG for ; Thu, 1 Oct 2009 06:55:08 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 16C803A69FB for ; Thu, 1 Oct 2009 06:55:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n91Du1D11006; Thu, 1 Oct 2009 13:56:01 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, 1 Oct 2009 08:56:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISPATCH IETF-76 plans Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9A= From: "Mary Barnes" To: Subject: [dispatch] DISPATCH IETF-76 plans 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, 01 Oct 2009 13:55:09 -0000 Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been previously put forth - both prior to Sept. 7th deadline and up through the 21st. Obviously, we have to balance interest and willingness to contribute to the work (based on mailing list discussions) with the fact that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback to refine requirements, problem statement, scope and deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available early enough for the WG to provide feedback - i.e., you do not have to wait for the pre-meeting deadlines, which are more in the way of drop dead dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair From L.Liess@telekom.de Thu Oct 1 07:36: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 1F1AE3A6A64 for ; Thu, 1 Oct 2009 07:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=0.288, 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 4Q3upuGr2joa for ; Thu, 1 Oct 2009 07:36:52 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id BB36328C15B for ; Thu, 1 Oct 2009 07:36:51 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 01 Oct 2009 16:38:11 +0200 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, 1 Oct 2009 16:38:11 +0200 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, 1 Oct 2009 16:38:20 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00379537F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4AB975CE.4040104@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal: SIP Alert-Info URN Thread-Index: Aco76tbQ6gI14jOZTe68aX+AKEahQgFF+KPA References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <4AB975CE.4040104@cisco.com> From: To: , X-OriginalArrivalTime: 01 Oct 2009 14:38:11.0444 (UTC) FILETIME=[CCF94B40:01CA42A4] Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 01 Oct 2009 14:36:53 -0000 Paul, Please excuse my late answer.=20 I like very much your reason list. Would you agree that we add the list to the draft as requirements, together with some parts of the text from an earlier e-mail you sent to me on the same issue in august http://www.ietf.org/mail-archive/web/bliss/current/msg01028.html ? =20 Thanks a lot Laura =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, September 23, 2009 3:12 AM > To: Dean Willis > Cc: Liess, Laura; dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN >=20 > I agree with Dean here. >=20 > The example of the "France standard ring tone" is a case=20 > where you have=20 > a URN that identifies some specific audio signal, but in a=20 > semantic way=20 > rather than by providing an encoding of it. This can be useful for a=20 > variety of reasons: > - its not biased towards a particular representation, > which might not be suitable for all devices > - its convenient when you want to store the actual encoding > locally rather than fetching it > - because it is specified "by name" rather than "by value", > its easier to make policy decisions about whether to use it or not. > - it facilitates translation for the hearing impaired >=20 > Thanks, > Paul >=20 > Dean Willis wrote: > >=20 > > On Sep 22, 2009, at 9:12 AM, =20 > =20 > > wrote: > >> > >> My understanding from your mail way that you know of other=20 > use cases > >> from other mobile standards group. Is that correct? If=20 > yes, does it > >> make sense to consider them here? The syntax is open so=20 > people can add > >> new labels. > >> > >=20 > > It's been a while but I may remember conversations in 3GPP,=20 > 3GPP2, and OMA. > >=20 > > The ring-back for national standard ringers has always=20 > seemed like a a=20 > > good application of URN in alert-info. In other words, if you call=20 > > somebody in France, you might get back a 180 with an=20 > alert-info with a=20 > > URN that basically means "France standard ring tone". > >=20 > > I vaguely remember discussion about URN-based alert-info=20 > for "public=20 > > alert" calls, like storm warnings and evacuation orders. > >=20 > >=20 > > There's also been discussion of use in forward-ring cases, as in=20 > > alert-info in an INVITE request. > >=20 > > See=20 > http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. This=20 > > suggests several additional cases that may need to be considered,=20 > > probably national variants of distinctive-ring indicators. > >=20 > >=20 > > While we probably don't want to charter every possible use case, it=20 > > would probably be appropriate to consider any published use=20 > cases from=20 > > the mobile groups. So perhaps part of the task of the WG=20 > would be to=20 > > review the extant standards and see if any of them should=20 > be added to=20 > > the initial registry. > >=20 > > --=20 > > Dean > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 From john.elwell@siemens-enterprise.com Thu Oct 1 07:42: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 46AC13A6A68 for ; Thu, 1 Oct 2009 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=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 gs1rAwy0ZKpn for ; Thu, 1 Oct 2009 07:42:08 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id CCA833A67F1 for ; Thu, 1 Oct 2009 07:42:07 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n91EhVXK012778; Thu, 1 Oct 2009 16:43:31 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n91EhVNO022634; Thu, 1 Oct 2009 16:43:31 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 1 Oct 2009 16:43:30 +0200 From: "Elwell, John" To: Mary Barnes , "dispatch@ietf.org" Date: Thu, 1 Oct 2009 16:43:18 +0200 Thread-Topic: DISPATCH IETF-76 plans Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAAWj2sA== Message-ID: <7402509E63C5A145A6095D46C179A5B71006498C@DEMCHP99E35MSX.ww902.siemens.net> References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Victor Pascual Subject: Re: [dispatch] DISPATCH IETF-76 plans 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, 01 Oct 2009 14:42:09 -0000 Mary, As I indicated earlier, a charter proposal for Identity is not appropriate = at this stage. However, Victor and I still anticipate the need for discussi= on time during the DISPATCH session, based on a revised draft due to appear= in the next week or so. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 01 October 2009 14:56 > To: dispatch@ietf.org > Subject: [dispatch] DISPATCH IETF-76 plans >=20 > Hi all,=20 >=20 > Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics > to be handled/dispatched prior to and at IETF-76 were due on=20 > Sept. 21st. > The following summarizes the status of the topics that had been > previously put forth - both prior to Sept. 7th deadline and up through > the 21st. Obviously, we have to balance interest and willingness to > contribute to the work (based on mailing list discussions)=20 > with the fact > that some folks were more conscientious in meeting the deadlines.=20 >=20 > We received charter proposals (problem=20 > statements/deliverables) for the > following, with the current status highlighted. =20 >=20 > o Overload (received prior to Sept. 16th) - separate mailing=20 > list setup. > Needs more discussion.=20 >=20 > o CBUS: some good discussion on problem statement. Needs more > discussion. >=20 > o Session recording: updated charter proposal based on=20 > IETF-75 feedback. > Need more WG feedback. Is this ready? =20 >=20 > o Disaggregated media: Good level of interest=20 >=20 > o SIP - XMPP: High level of WG interest. Propose a separate Mailing > list and Adhoc at IETF-76.=20 >=20 > o Alert-info URNs: Good level of interest.=20 >=20 > o NGN Reason: Some interest. Needs more discussion and scoping.=20 >=20 > The above items are the current targets for IETF-76=20 > discussions. Based > on those discussions, agenda time will be allocated, items dispatched > and adhocs scheduled as appropriate. Note, that the minimum time we > would allocate to a topic is 30 minutes and some may warrant=20 > 45 minutes. > If we schedule adhocs, we will try to have those announced around the > time the agenda is finalized.=20 >=20 > As a reminder, the following are the cutoffs for drafts, so=20 > please make > sure that any drafts relevant to the topic are submitted=20 > prior to those > deadlines: > * - 00 documents: Oct. 19th (just over 2 weeks) > * all other documents: Oct. 26th (just over 3 weeks) >=20 > Please keep in mind that the focus of discussions should be=20 > the problem > statement, scope and proposed deliverables for the topic. =20 >=20 > We did not receive charter proposals for the following. The current > status is summarized: > o Third-party authorization: Pre-IETF-75 problem statement had some > discussion. But, no discussion since that time.=20 > o Identity: Document available. Need further discussion and=20 > WG feedback > to refine requirements, problem statement, scope and > deliverables/milestones.=20 > o Domain registrations in SIP: Problem statement posted, but no > deliverables/milestones or document.=20 > o Reference to an earlier communication: Problem statement posted, but > no deliverables/milestones or document.=20 >=20 > As a reminder, items can be dispatched without being=20 > discussed at a f2f > meeting and the most effective way to achieve this is to have problem > statements, scope of topics and any relevant documents available early > enough for the WG to provide feedback - i.e., you do not have to wait > for the pre-meeting deadlines, which are more in the way of drop dead > dates than optimal dates. =20 >=20 > Please, let the chairs know if there are any concerns. >=20 > Thanks, > Mary Barnes > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From L.Liess@telekom.de Thu Oct 1 07:43: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 E26993A6A77 for ; Thu, 1 Oct 2009 07:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.272, 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 rXBFz5WW4E+b for ; Thu, 1 Oct 2009 07:43:34 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 11B583A6A69 for ; Thu, 1 Oct 2009 07:43:33 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 01 Oct 2009 16:44:58 +0200 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, 1 Oct 2009 16:44:58 +0200 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, 1 Oct 2009 16:45:04 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal: SIP Alert-Info URN Thread-Index: Aco7sQlUB4ur2qaKT1OCFzwPmSMZ1AGJ5nNw References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> From: To: , X-OriginalArrivalTime: 01 Oct 2009 14:44:58.0021 (UTC) FILETIME=[BF500550:01CA42A5] Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 01 Oct 2009 14:43:36 -0000 Dean, I have some questions on your mail: > The ring-back for national standard ringers has always seemed > like a a =20 > good application of URN in alert-info. In other words, if you call =20 > somebody in France, you might get back a 180 with an=20 > alert-info with a =20 > URN that basically means "France standard ring tone". In the use-cases we have now in the draft, the end devices resolves the alert-URN.=20 Would this be the same for the "France standard ring tone"? The user downloads a tone which=20 reminds him of France and configures it as "France standard ring tone"? Or is it something else you have in mind? > I vaguely remember discussion about URN-based alert-info for "public =20 > alert" calls, like storm warnings and evacuation orders. >=20 This makes sense to me and I will ask Brian, he is working on the emergency alerts stuff.=20 Concerning the syntax of the urn's you propose, I see here two alternatives: =20 1) Defining new categories, additional to "tone" and "service", e.g. "national-ring-back-tones". The alert-URN for the "France standard ring tone" could look like urn:alert:national-ring-back-tones:standard.france 2) Or just defining new alert-indications in the "tones"-category, e.g. like urn:alert:tones:standard-ring-back-tone.france Any thoughts/preferences on this?=20 > There's also been discussion of use in forward-ring cases, as=20 > in alert-=20 > info in an INVITE request. >=20 > See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. =20 > This suggests several additional cases that may need to be=20 > considered, =20 > probably national variants of distinctive-ring indicators. We have forward-ring cases in the draft for PBX, provided by Alan but we don't have anything similar for public networks. Deutsche Telekom doesn't use distinctive ringing so I can not say much on this issue. =20 Adam proposed to look at 3GPP2 A.S0014 and TIA/EIA (see http://www.ietf.org/mail-archive/web/bliss/current/msg01020.html and http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html ) .=20 I think for doing this experience with these specifications and this kind of tones is needed. This is not the case for me and possible also for Alan. So if these documents should be covered by this draft, we need contributions from experts. Or we try to standardize the mechanism as soon as possible and leave to the experts from the respective groups to define and register the alert indications they need. If we do not have sufficient expertise in IETF, I would prefer the second alternative, to avoid dependencies of IETF documents from other standard bodies. =20 Some of the tones in these documents describe the rendering, not the semantic, e.g. Short-Short-Short, and the alert-URN should describe the semantic. =20 > While we probably don't want to charter every possible use case, it =20 > would probably be appropriate to consider any published use=20 > cases from =20 > the mobile groups. So perhaps part of the task of the WG would be to =20 > review the extant standards and see if any of them should be=20 > added to =20 > the initial registry In principle the same comment as above. I would leave this to people who understand what they define. =20 Thanks a lot Laura =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, September 22, 2009 8:18 PM > To: Liess, Laura > Cc: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN >=20 >=20 > On Sep 22, 2009, at 9:12 AM, =20 > =20 > wrote: > > > > My understanding from your mail way that you know of other use cases > > from other mobile standards group. Is that correct? If yes, does it > > make sense to consider them here? The syntax is open so=20 > people can add > > new labels. > > >=20 > It's been a while but I may remember conversations in 3GPP,=20 > 3GPP2, and =20 > OMA. >=20 > The ring-back for national standard ringers has always seemed=20 > like a a =20 > good application of URN in alert-info. In other words, if you call =20 > somebody in France, you might get back a 180 with an=20 > alert-info with a =20 > URN that basically means "France standard ring tone". >=20 > I vaguely remember discussion about URN-based alert-info for "public =20 > alert" calls, like storm warnings and evacuation orders. >=20 >=20 > There's also been discussion of use in forward-ring cases, as=20 > in alert-=20 > info in an INVITE request. >=20 > See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. =20 > This suggests several additional cases that may need to be=20 > considered, =20 > probably national variants of distinctive-ring indicators. >=20 >=20 > While we probably don't want to charter every possible use case, it =20 > would probably be appropriate to consider any published use=20 > cases from =20 > the mobile groups. So perhaps part of the task of the WG would be to =20 > review the extant standards and see if any of them should be=20 > added to =20 > the initial registry. >=20 > -- > Dean >=20 >=20 From vkg@alcatel-lucent.com Thu Oct 1 07:51: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 CAFCE3A67A8 for ; Thu, 1 Oct 2009 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 Ky47STZuwWui for ; Thu, 1 Oct 2009 07:51:53 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id CD5823A676A for ; Thu, 1 Oct 2009 07:51:53 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n91ErG5A007972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 09:53:16 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n91ErEsg025018; Thu, 1 Oct 2009 09:53:14 -0500 (CDT) Message-ID: <4AC4C25A.3020909@alcatel-lucent.com> Date: Thu, 01 Oct 2009 09:53:14 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> In-Reply-To: <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 01 Oct 2009 14:51:54 -0000 Cullen Jennings wrote: > The security of this draft seems, uh, bad. It's so bad that I am having > a really hard time believing I actually am understanding it correctly. > Help me make sure that I have this right. > > Cisco and ACME are part of the AT&T trust domain and get sip trunking > from AT&T. Cisco sends a via that has ACME on the alias to AT&T. There > is nothing AT&T can do to validate this. Now Cisco has hijacked all of > ACME's call. If the trust domain consisted of just one party, well I see > how this might be secure, sort of, but it seems to fall apart as the > trust domain expands. Cullen: Two observations in trying to drill down to the problem definition here. First, I want to make sure that we are not assuming the case of a virtual server sending requests on different connections. While this was solvable for the TLS case, it is not for the TCP case. Second, maybe I am not understanding the gist of what you wrote above, but the connection reuse is between adjacent nodes. In your example above, ATT will reuse the Cisco connection when requests from ACME need to go to Cisco and reuse the Acme connection when requests from Cisco need to go to Acme. If my understanding is incorrect, can you please amplify with a boxes and arrow diagram or something along those lines? Thank you, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From pkyzivat@cisco.com Thu Oct 1 08:18: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 7AA1628C149 for ; Thu, 1 Oct 2009 08:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 smr64py9LYac for ; Thu, 1 Oct 2009 08:18:27 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4B3EE28C145 for ; Thu, 1 Oct 2009 08:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3208; q=dns/txt; s=rtpiport02001; t=1254410393; x=1255619993; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Charter=20proposal:=20=20SIP=20Aler t-Info=20URN|Date:=20Thu,=2001=20Oct=202009=2011:19:45=20 -0400|Message-ID:=20<4AC4C891.1080708@cisco.com>|To:=20L. Liess@telekom.de|CC:=20alan@sipstation.com,=20dispatch@ie tf.org,=20R.Jesske@telekom.de|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<40FB0F FB97588246A1BEFB05759DC8A00379537F@S4DE9JSAANI.ost.t-com. de>|References:=20<40FB0FFB97588246A1BEFB05759DC8A0036E29 AD@S4DE9JSAANI.ost.t-com.de>=09=09<40FB0FFB97588246A1BEFB05759 DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de>=20<58C1975B-4034- 4D04-83C2-1E48D6461B15@softarmor.com>=20<4AB975CE.4040104 @cisco.com>=20<40FB0FFB97588246A1BEFB05759DC8A00379537F@S 4DE9JSAANI.ost.t-com.de>; bh=g0GVlEO025ARILqnOIL4UchnaJ+WghXIwEtx5DQWlFY=; b=AoaO3WYMFy6ALh9C0HJB8H4DGGKeg99Q9NNauleoT69j0pttTDYvR0Oa fmy+Z4JeT00OZiMlIQCNrUznvWXyzqanECCVjNW+pWoGnQksb9jqVBrda hZxzWKvEA6wUdkBIWHLO2h1azWOJ1lNmcrl2t394fFc7/zC1FOhmxtdsh g=; Authentication-Results: rtp-iport-2.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GAH5lxEpAZnme/2dsb2JhbACPKLAUiFsBj0sGhCk X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="60942847" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Oct 2009 15:19:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91FJqPU032129; Thu, 1 Oct 2009 11:19:52 -0400 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 n91FJoiJ003036; Thu, 1 Oct 2009 15:19:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 11:19:51 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 11:19:51 -0400 Message-ID: <4AC4C891.1080708@cisco.com> Date: Thu, 01 Oct 2009 11:19:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <4AB975CE.4040104@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A00379537F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00379537F@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2009 15:19:51.0298 (UTC) FILETIME=[9F00BE20:01CA42AA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3208; t=1254410392; x=1255274392; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=3A=20=2 0SIP=20Alert-Info=20URN |Sender:=20 |To:=20L.Liess@telekom.de; bh=g0GVlEO025ARILqnOIL4UchnaJ+WghXIwEtx5DQWlFY=; b=Ijd8Y7ckAfdox/MBcp/AlTNZsQ4TAB/yPjyKf0eo2KVYM6kehGhsyWJfar AeI5t1ga3WWmMsR/quHGninz/J6X21BMYdQHxpkq4PJGeOR8S0HIFgW9SfW0 ehuEtPY375; Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 01 Oct 2009 15:18:28 -0000 L.Liess@telekom.de wrote: > Paul, > > Please excuse my late answer. > > I like very much your reason list. Would you agree that we add the list > to the draft as requirements, together with some parts of the text from > an earlier e-mail you sent to me on the same issue in august > http://www.ietf.org/mail-archive/web/bliss/current/msg01028.html ? Sure! > Thanks a lot > Laura > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, September 23, 2009 3:12 AM >> To: Dean Willis >> Cc: Liess, Laura; dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN >> >> I agree with Dean here. >> >> The example of the "France standard ring tone" is a case >> where you have >> a URN that identifies some specific audio signal, but in a >> semantic way >> rather than by providing an encoding of it. This can be useful for a >> variety of reasons: >> - its not biased towards a particular representation, >> which might not be suitable for all devices >> - its convenient when you want to store the actual encoding >> locally rather than fetching it >> - because it is specified "by name" rather than "by value", >> its easier to make policy decisions about whether to use it or not. >> - it facilitates translation for the hearing impaired >> >> Thanks, >> Paul >> >> Dean Willis wrote: >>> On Sep 22, 2009, at 9:12 AM, >> >>> wrote: >>>> My understanding from your mail way that you know of other >> use cases >>>> from other mobile standards group. Is that correct? If >> yes, does it >>>> make sense to consider them here? The syntax is open so >> people can add >>>> new labels. >>>> >>> It's been a while but I may remember conversations in 3GPP, >> 3GPP2, and OMA. >>> The ring-back for national standard ringers has always >> seemed like a a >>> good application of URN in alert-info. In other words, if you call >>> somebody in France, you might get back a 180 with an >> alert-info with a >>> URN that basically means "France standard ring tone". >>> >>> I vaguely remember discussion about URN-based alert-info >> for "public >>> alert" calls, like storm warnings and evacuation orders. >>> >>> >>> There's also been discussion of use in forward-ring cases, as in >>> alert-info in an INVITE request. >>> >>> See >> http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. This >>> suggests several additional cases that may need to be considered, >>> probably national variants of distinctive-ring indicators. >>> >>> >>> While we probably don't want to charter every possible use case, it >>> would probably be appropriate to consider any published use >> cases from >>> the mobile groups. So perhaps part of the task of the WG >> would be to >>> review the extant standards and see if any of them should >> be added to >>> the initial registry. >>> >>> -- >>> Dean >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> > From pkyzivat@cisco.com Thu Oct 1 08:28: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 341543A6974 for ; Thu, 1 Oct 2009 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 Ci95r5E8Cg6r for ; Thu, 1 Oct 2009 08:28:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 95A0C3A6853 for ; Thu, 1 Oct 2009 08:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6212; q=dns/txt; s=sjiport06001; t=1254410977; x=1255620577; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Charter=20proposal:=20=20SIP=20Aler t-Info=20URN|Date:=20Thu,=2001=20Oct=202009=2011:29:29=20 -0400|Message-ID:=20<4AC4CAD9.1010401@cisco.com>|To:=20L. Liess@telekom.de|CC:=20dean.willis@softarmor.com,=20alan@ sipstation.com,=20dispatch@ietf.org,=0D=0A=20=20=20=20=20 =20=20=20adam@nostrum.com|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<40FB0F FB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com. de>|References:=20<40FB0FFB97588246A1BEFB05759DC8A0036E29 AD@S4DE9JSAANI.ost.t-com.de>=20=20<40FB0FFB97588246A1BEFB05759 DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de>=20<58C1975B-4034- 4D04-83C2-1E48D6461B15@softarmor.com>=20<40FB0FFB97588246 A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de>; bh=2+oz7MqNmBnyLBU78KJIKDMjRhZogY4T2686Tdleikw=; b=sfZ6FtYqnNM560JCAez2jUUUOCc5WyHb+XZHaEKwcR7Y/pBBn5rAGWOx Cd9fNAIA0gbElbwNS8CPXu5QGBlvMrOWhx/D14eoX2Tiwpp3+czkz9wXx A9YcYiBKZNan6MLTIoNEfoEQzX4roaHJO0DnV+0+UyL4hGY/pGPry9loI I=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GANdnxEqrR7PE/2dsb2JhbACPKLAniFsBj0wGhCk X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="400122813" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Oct 2009 15:29:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n91FTbaw026825; Thu, 1 Oct 2009 08:29:37 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n91FTVfE000907; Thu, 1 Oct 2009 15:29:36 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 11:29:36 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 11:29:36 -0400 Message-ID: <4AC4CAD9.1010401@cisco.com> Date: Thu, 01 Oct 2009 11:29:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2009 15:29:36.0269 (UTC) FILETIME=[FBAC3BD0:01CA42AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6212; t=1254410977; x=1255274977; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=3A=20=2 0SIP=20Alert-Info=20URN |Sender:=20; bh=2+oz7MqNmBnyLBU78KJIKDMjRhZogY4T2686Tdleikw=; b=YzIX5rYGKZTZpr4ovIgP8oWE3Z4Sm9a+o2isUtKXazyS+t1TFvAdivb2B/ wubgGhFK4s1GrZDEp1hPzxPX4WgJGIJXMAN9pFppx1w3/BxH09q08ZImAfja /YZeY3fwhX; Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 01 Oct 2009 15:28:13 -0000 L.Liess@telekom.de wrote: > > Dean, > > I have some questions on your mail: > > > The ring-back for national standard ringers has always seemed > > > like a a > > good application of URN in alert-info. In other words, if you > call > > somebody in France, you might get back a 180 with an > > alert-info with a > > URN that basically means "France standard ring tone". > > In the use-cases we have now in the draft, the end devices resolves the > alert-URN. > Would this be the same for the "France standard ring tone"? The user > downloads a tone which > reminds him of France and configures it as "France standard ring tone"? > Or is it something else you have in mind? In the end, the device decides what it wants to do. It can ignore the alert-info if it wants. What the alert-info does is say what the other end suggests/prefers. Given that URNs provide unique names, it means the device can look them up among things it knows about. Or it could access some external source of tones, providing the URN it is looking for, and perhaps receiving back something. (This could be just a form of downloading ringtones.) You can also consider a "distinctive ring" feature as just a matter of taking caller info and mapping it to a particular alert-info URN. That could be done in the phone, or it could be done in an application server acting on behalf of the phone. > > I vaguely remember discussion about URN-based alert-info for > "public > > alert" calls, like storm warnings and evacuation orders. > > > > This makes sense to me and I will ask Brian, he is working on the > emergency alerts stuff. > > Concerning the syntax of the urn's you propose, I see here two > alternatives: > > 1) Defining new categories, additional to "tone" and "service", e.g. > "national-ring-back-tones". The alert-URN for the "France standard ring > tone" could look like urn:alert:national-ring-back-tones:standard.france > 2) Or just defining new alert-indications in the "tones"-category, e.g. > like urn:alert:tones:standard-ring-back-tone.france I think perhaps the latter. But it might be a political issue. Thanks, Paul > Any thoughts/preferences on this? > > > There's also been discussion of use in forward-ring cases, as > > in alert- > > info in an INVITE request. > > > > See > http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. > > This suggests several additional cases that may need to be > > considered, > > probably national variants of distinctive-ring indicators. > > We have forward-ring cases in the draft for PBX, provided by Alan but > we don't have anything similar for public networks. Deutsche Telekom > doesn't use distinctive ringing so I can not say much on this issue. > > Adam proposed to look at 3GPP2 A.S0014 and TIA/EIA (see > http://www.ietf.org/mail-archive/web/bliss/current/msg01020.html and > http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html ) . > I think for doing this experience with these specifications and this > kind of tones is needed. This is not the case for me and possible also > for Alan. So if these documents should be covered by this draft, we > need contributions from experts. Or we try to standardize the mechanism > as soon as possible and leave to the experts from the respective groups > to define and register the alert indications they need. If we do not > have sufficient expertise in IETF, I would prefer the second > alternative, to avoid dependencies of IETF documents from other standard > bodies. > Some of the tones in these documents describe the rendering, not the > semantic, e.g. Short-Short-Short, and the alert-URN should describe the > semantic. > > > > While we probably don't want to charter every possible use > case, it > > would probably be appropriate to consider any published use > > cases from > > the mobile groups. So perhaps part of the task of the WG would > be to > > review the extant standards and see if any of them should be > > added to > > the initial registry > > In principle the same comment as above. I would leave this to people who > understand what they define. > > > Thanks a lot > Laura > > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Tuesday, September 22, 2009 8:18 PM >> To: Liess, Laura >> Cc: Alan Johnston; dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN >> >> >> On Sep 22, 2009, at 9:12 AM, >> >> wrote: >>> My understanding from your mail way that you know of other use cases >>> from other mobile standards group. Is that correct? If yes, does it >>> make sense to consider them here? The syntax is open so >> people can add >>> new labels. >>> >> It's been a while but I may remember conversations in 3GPP, >> 3GPP2, and >> OMA. >> >> The ring-back for national standard ringers has always seemed >> like a a >> good application of URN in alert-info. In other words, if you call >> somebody in France, you might get back a 180 with an >> alert-info with a >> URN that basically means "France standard ring tone". >> >> I vaguely remember discussion about URN-based alert-info for "public >> alert" calls, like storm warnings and evacuation orders. >> >> >> There's also been discussion of use in forward-ring cases, as >> in alert- >> info in an INVITE request. >> >> See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. >> This suggests several additional cases that may need to be >> considered, >> probably national variants of distinctive-ring indicators. >> >> >> While we probably don't want to charter every possible use case, it >> would probably be appropriate to consider any published use >> cases from >> the mobile groups. So perhaps part of the task of the WG would be to >> review the extant standards and see if any of them should be >> added to >> the initial registry. >> >> -- >> Dean >> >> > From christer.holmberg@ericsson.com Thu Oct 1 11:09: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 DA0DB3A6ACC for ; Thu, 1 Oct 2009 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=0.516, 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 Eu2EDrTHkxj0 for ; Thu, 1 Oct 2009 11:09:58 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 68C513A6ACB for ; Thu, 1 Oct 2009 11:09:58 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-78-4ac4f0cae619 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 6D.91.22406.AC0F4CA4; Thu, 1 Oct 2009 20:11:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 20:11:22 +0200 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, 1 Oct 2009 20:10:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISPATCH IETF-76 plans Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AACPh1zQ== References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , X-OriginalArrivalTime: 01 Oct 2009 18:11:22.0809 (UTC) FILETIME=[9538B290:01CA42C2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] DISPATCH IETF-76 plans 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, 01 Oct 2009 18:09:59 -0000 Hi Mary, =20 Regarding CBUS, there has been some questoin regarding the event package = definition procedure, so to start with I think it would be useful to get = that clarified. =20 Regards, =20 Christer ________________________________ From: dispatch-bounces@ietf.org on behalf of Mary Barnes Sent: Thu 01/10/2009 15:56 To: dispatch@ietf.org Subject: [dispatch] DISPATCH IETF-76 plans Hi all, Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been previously put forth - both prior to Sept. 7th deadline and up through the 21st. Obviously, we have to balance interest and willingness to contribute to the work (based on mailing list discussions) with the fact that some folks were more conscientious in meeting the deadlines. We received charter proposals (problem statements/deliverables) for the following, with the current status highlighted.=20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion. o CBUS: some good discussion on problem statement. Needs more discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready?=20 o Disaggregated media: Good level of interest o SIP - XMPP: High level of WG interest. Propose a separate Mailing list and Adhoc at IETF-76. o Alert-info URNs: Good level of interest. o NGN Reason: Some interest. Needs more discussion and scoping. The above items are the current targets for IETF-76 discussions. Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the time the agenda is finalized. As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some discussion. But, no discussion since that time. o Identity: Document available. Need further discussion and WG feedback to refine requirements, problem statement, scope and deliverables/milestones. o Domain registrations in SIP: Problem statement posted, but no deliverables/milestones or document. o Reference to an earlier communication: Problem statement posted, but no deliverables/milestones or document. As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available early enough for the WG to provide feedback - i.e., you do not have to wait for the pre-meeting deadlines, which are more in the way of drop dead dates than optimal dates.=20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Thu Oct 1 22:32: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 36D103A69D4 for ; Thu, 1 Oct 2009 22:32:25 -0700 (PDT) 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 Nhq+Dvyb8eNQ for ; Thu, 1 Oct 2009 22:32:23 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 81CDF3A696E for ; Thu, 1 Oct 2009 22:32:23 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n925XjXb013300; Fri, 2 Oct 2009 00:33:45 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Fri, 2 Oct 2009 05:33:46 -0000 (UTC) Message-ID: In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> Date: Fri, 2 Oct 2009 05:33:46 -0000 (UTC) From: "Dean Willis" To: L.Liess@telekom.de User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 02 Oct 2009 05:32:25 -0000 On Thu, October 1, 2009 2:45 pm, L.Liess@telekom.de wrote: > > > Dean, > > I have some questions on your mail: > > > The ring-back for national standard ringers has always seemed > > > like a a > > good application of URN in alert-info. In other words, if you > call > > somebody in France, you might get back a 180 with an > > alert-info with a > > URN that basically means "France standard ring tone". > > In the use-cases we have now in the draft, the end devices resolves the > alert-URN. > Would this be the same for the "France standard ring tone"? The user > downloads a tone which > reminds him of France and configures it as "France standard ring tone"? > Or is it something else you have in mind? I think it needs to be a semantic definition. For example, someone who is using a speech-to-text application for making a phone call should see something like "Ringing: With French standard ring tone" so they would know their call is being handled in France. So, given the semantic encoding, it's up the the UA to figure out how to render it, possibly based on local configuration as you propose above. This raises the question: would it be reasonable to have two entries, one with a semantic value, the other with a more directive rendering that could be used if the UA had no idea about the semantic value? > > I vaguely remember discussion about URN-based alert-info for > "public > > alert" calls, like storm warnings and evacuation orders. > > > > This makes sense to me and I will ask Brian, he is working on the > emergency alerts stuff. > > Concerning the syntax of the urn's you propose, I see here two > alternatives: > > 1) Defining new categories, additional to "tone" and "service", e.g. > "national-ring-back-tones". The alert-URN for the "France standard ring > tone" could look like urn:alert:national-ring-back-tones:standard.france > > 2) Or just defining new alert-indications in the "tones"-category, e.g. > like urn:alert:tones:standard-ring-back-tone.france > > Any thoughts/preferences on this? No preference here. I'm just guessing that somebody somewhere has a registry of these things, and it might behoove us to follow its structure, or at least to find the reference to it. -- Dean From R.Jesske@telekom.de Thu Oct 1 22:49: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 BC7C93A69F5 for ; Thu, 1 Oct 2009 22:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.867, 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 9WP8Pr7AxLcR for ; Thu, 1 Oct 2009 22:49:58 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 2C9E63A69F4 for ; Thu, 1 Oct 2009 22:49:57 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 02 Oct 2009 07:51:19 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:51:18 +0200 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, 2 Oct 2009 07:51:17 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwA== References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 02 Oct 2009 05:51:18.0247 (UTC) FILETIME=[5C73FF70:01CA4324] Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 02 Oct 2009 05:49:59 -0000 Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been previously put forth - both prior to Sept. 7th deadline and up through the 21st. Obviously, we have to balance interest and willingness to contribute to the work (based on mailing list discussions) with the fact that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback to refine requirements, problem statement, scope and deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available early enough for the WG to provide feedback - i.e., you do not have to wait for the pre-meeting deadlines, which are more in the way of drop dead dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From RIFATYU@nortel.com Fri Oct 2 03:59: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 A00FC3A6873 for ; Fri, 2 Oct 2009 03:59:17 -0700 (PDT) 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 LM-TH3rGwpcG for ; Fri, 2 Oct 2009 03:59:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 828E73A67FD for ; Fri, 2 Oct 2009 03:58:55 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n92B0HB23970; Fri, 2 Oct 2009 11:00:17 GMT 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_01CA434F.85AA8876" Date: Fri, 2 Oct 2009 07:00:14 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgO+rxqAACPN20AAEur0kAEfzNzQABfrf6A= References: From: "Rifaat Shekh-Yusef" To: , , , "Mary Barnes" , Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/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, 02 Oct 2009 10:59:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA434F.85AA8876 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Simo, =20 > If I understood your scenario correctly, you are proposing to use separate correlation id's in each direction. [RSY] Yes, I am proposing the use of separate correlation id's and utilizing the existing call-id's for that, to avoid the introduction of new end-to-end id. =20 >That would work as well, but I don't see the reason why Alice would choose call-id2 as her correlation id, if in any case call-id1 gets to her UA in F2. [RSY] Alice would choose call-id2 because this is the Call-ID of her dialog with the B2BUA. If Bob wants to initiate an IM session with Alice, he would send call-id2 as a correlation id which would allow Alice to search her active calls for a dialog with call-id2. If Bob sends call-id1 as a correlation id, Alice will not be able to find a dialog with call-id1 as this is not her dialog. =20 Regards, Rifaat =20 =20 =20 =20 ________________________________ From: Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com]=20 Sent: Wednesday, September 30, 2009 5:09 AM To: Shekh-Yusef, Rifaat (BVW:9T16); Markus.Isomaki@nokia.com; dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Subject: RE: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Hello Rifaat, =20 sorry for the late reply. =20 If I understood your scenario correctly, you are proposing to use separete correlation id's in each direction. That would work as well, but I don't see the reason why Alice would choose call-id2 as her correlation id, if in any case call-id1 gets to her UA in F2. =20 Simo ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Rifaat Shekh-Yusef Sent: 24 September, 2009 18:57 To: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; Mary Barnes; gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP =09 =09 Simo, =20 If I add a B2BUA to the example that you have in section 7.2: =20 Bob B2BUA Alice | | | | (F1) INVITE | (F2) INVITE | |-------------------------------------------------- >|---------------------------------------------------> | | XMPP-Contact: Bob; call-id1 | XMPP-Contact: Bob; call-id1 | | | | | | | | (F4) 200 OK | (F3) 200 OK | |<-------------------------------------------------- |<-------------------------------------------------- | | XMPP-Contact: Alice; call-id2 | XMPP-Contact: Alice; call-id2 | | | | =20 =20 Let (F1) INVITE have the correlation-id as the Call-ID of the dialog between Bob and the B2BUA (call-id1),=20 and (F3) 200 OK have the correlation-id as the Call-ID of the dialog between the B2BUA and Alice (call-id2). =20 Would it not be enough for Bob to send call-id2 to Alice as the ? and for Alice to send call-id1 to Bob as the ? =20 Regards, Rifaat ________________________________ From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, September 24, 2009 2:54 AM To: Shekh-Yusef, Rifaat (BVW:9T16); Simo.Veikkolainen@nokia.com; dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Subject: RE: [dispatch] New topic proposal for DISPATCH - SIP/XMPP =09 =09 Hi Rifaat, =20 In our proposal the correlation works so that: 1. UAs engaged in a SIP session/dialog exchange an identifier related to that session (as well as their XMPP full JIDs) 2. They insert them in the very first XMPP messages they subsequently exchange, in order to correlate that exchange to be related to the SIP session. =20 The correlation identifier has to be end-to-end, otherwise the other end won't be able to use it for correlation. Call-ID is often changed enroute. So, if one endpoint puts it in an XMPP messages as a reference to a SIP session, the other endpoint won't recognize it as it has a different Call-ID for the same session. =20 Markus ________________________________ From: ext Rifaat Shekh-Yusef [mailto:rifatyu@nortel.com] Sent: 23 September, 2009 22:57 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; Mary Barnes; gonzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo) Subject: RE: [dispatch] New topic proposal for DISPATCH =09 =09 Simo, Markus, =20 I am very interested in this work and I like your approach. =20 I have a question regarding the open issue you have in section 5.2: Why do you require the correlation-value to be an end-to-end identifier? In the case where there is an SBC that creates a new dialog for the target, would it not be enough for each endpoint to use the Call-ID of the other dialog as the correlation-value? =20 Thanks, Rifaat =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com Sent: Friday, September 04, 2009 8:09 AM To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Cc: Markus.Isomaki@nokia.com Subject: [dispatch] New topic proposal for DISPATCH =09 =09 =09 Hi, =20 We would like to propose a new DISPATCH topic on how SIP and XMPP can be used together in a complementary fashion. =20 We have been working on a solution which combines SIP based VoIP and XMPP based IM and Presence. The requirements and a proposed solution is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 . =20 The motivation for this work comes from experience which shows that most standards based VoIP deployments use SIP. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is widely used in instant messaging and presence services. An interesting scenario arises when a SIP based voice (and video) service is combined together with an XMPP based instant messaging and presence service.=20 =20 Note that the goal in this work is not SIP-XMPP protocol translation, but to define protocol extensions and best practises such that SIP based VoIP and XMPP based IM and presence could be seamlessly combined and offered to the end user. For rapid deployment, we assume no changes in the server infrastructure, and instead impose new requirements and protocol extensions only to the endpoints. =20 We would like to get some discussion going on the use case itself as well as on the solution. Also, we would like to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such work. =20 Exact charter proposal and problem statemen is to follow.=20 =20 Regards, Simo and Markus =20 =20 ------_=_NextPart_001_01CA434F.85AA8876 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Simo,
 
> If I understood your scenario = correctly,=20 you are proposing to use separate correlation id's in each=20 direction.
[RSY]=20 Yes, I am proposing the use of separate correlation id's=20 and utilizing the existing call-id's for that, to avoid = the=20 introduction of new end-to-end id.
 
>That would work as well, but I don't see the reason why = Alice=20 would choose call-id2 as her correlation id, if in any case call-id1 = gets to her=20 UA in F2.
[RSY]=20 Alice would choose call-id2 because this is the Call-ID of her dialog = with the=20 B2BUA.
If Bob=20 wants to initiate an IM session with Alice, he would send call-id2 as a=20 correlation id which would allow Alice to search her active calls for a = dialog=20 with call-id2.
If Bob=20 sends call-id1 as a correlation id, Alice will not be able to find a = dialog with=20 call-id1 as this is not her dialog.
 
Regards,
 Rifaat
 
 
 
 

From: Simo.Veikkolainen@nokia.com=20 [mailto:Simo.Veikkolainen@nokia.com]
Sent: Wednesday, = September 30,=20 2009 5:09 AM
To: Shekh-Yusef, Rifaat (BVW:9T16);=20 Markus.Isomaki@nokia.com; dispatch@ietf.org; Barnes, Mary (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Subject: RE: [dispatch] New = topic=20 proposal for DISPATCH - SIP/XMPP

Hello Rifaat,
 
sorry for the late reply.
 
If I understood your scenario correctly, you are = proposing to=20 use separete correlation id's in each direction. That would work as = well, but I=20 don't see the reason why Alice would choose call-id2 as her correlation = id, if=20 in any case call-id1 gets to her UA in F2.
 
Simo

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Rifaat=20 Shekh-Yusef
Sent: 24 September, 2009 18:57
To: = Isomaki=20 Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-D/Helsinki);=20 dispatch@ietf.org; Mary Barnes;=20 gonzalo.camarillo@ericsson.com
Subject: Re: [dispatch] New = topic=20 proposal for DISPATCH - SIP/XMPP

Simo,

 

If = I add a B2BUA to the example that = you have=20 in section 7.2:

 

Bob           &nbs= p;            = ;            =             B2BUA           &nbs= p;            = ;            &nbs= p;     Alice

|           &nbs= p;            = ;            =            =        = |           &nbs= p;            = ;            =                  |<= /P>

| (F1) = INVITE           &nbs= p;            = ;            | (F2) = INVITE           &nbs= p;            = ;            |

|--------------------------------------------------=20 >|--------------------------------------------------->=20 |

| = XMPP-Contact: Bob;=20 call-id1           | XMPP-Contact: Bob; = call-id1          =20 |

|           &nbs= p;            = ;            =                 =20 |           &nbs= p;            = ;            =            =       =20 |

|           &nbs= p;            = ;            =             &= nbsp;   =20 |           &nbs= p;            = ;            =             &= nbsp;    =20 |

| (F4) 200 = OK           &nbs= p;            = ;          |=20 (F3) 200 OK           &nbs= p;            = ;          =20 |

|<--------------------------------------------------=20 |<-------------------------------------------------- |

| = XMPP-Contact:=20 Alice; call-id2         | = XMPP-Contact:=20 Alice;=20 call-id2          |

|           &nbs= p;            = ;            =             &= nbsp;   =20 |           &nbs= p;            = ;            =             &= nbsp;   =20 |

 

 

Let (F1) = INVITE have=20 the correlation-id as the = Call-ID of the=20 dialog between Bob and the B2BUA (call-id1),

and (F3) = 200 OK have=20 the correlation-id as the = Call-ID of the=20 dialog between the B2BUA and Alice (call-id2).

 

Would it = not be=20 enough for Bob to send call-id2 to Alice as the <sip-correlation>? and for Alice to send call-id1 to Bob as=20 the <sip-correlation>?

 

Regards,

 Rifaat


From: Markus.Isomaki@nokia.com=20 [mailto:Markus.Isomaki@nokia.com]
Sent: Thursday, September = 24,=20 2009 2:54 AM
To: Shekh-Yusef, Rifaat (BVW:9T16);=20 Simo.Veikkolainen@nokia.com; dispatch@ietf.org; Barnes, Mary = (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Subject: RE: [dispatch] New = topic=20 proposal for DISPATCH - SIP/XMPP

Hi Rifaat,
 
In our proposal the correlation works so=20 that:
1. UAs engaged in a SIP session/dialog = exchange an=20 identifier related to that session (as well as their XMPP full=20 JIDs)
2. They insert them in the very first XMPP = messages=20 they subsequently exchange, in order to correlate that exchange to be = related=20 to the SIP session.
 
The correlation identifier has to be = end-to-end,=20 otherwise the other end won't be able to use it for correlation. = Call-ID is=20 often changed enroute. So, if one endpoint puts it in an XMPP messages = as a=20 reference to a SIP session, the other endpoint won't recognize it as = it has a=20 different Call-ID for the same session.
 
Markus

From: ext Rifaat Shekh-Yusef=20 [mailto:rifatyu@nortel.com]
Sent: 23 September, 2009=20 22:57
To: Veikkolainen Simo (Nokia-D/Helsinki); = dispatch@ietf.org;=20 Mary Barnes; gonzalo.camarillo@ericsson.com
Cc: Isomaki = Markus=20 (Nokia-CIC/Espoo)
Subject: RE: [dispatch] New topic = proposal for=20 DISPATCH

Simo, Markus,
 
I=20 am very interested in this work and I like your=20 approach.
 
I=20 have a question regarding the open issue you have in section=20 5.2:
Why do you require the correlation-value to be an = end-to-end=20 identifier?
In=20 the case where there is an SBC that creates a new dialog for = the=20 target, would it not be enough for each endpoint to use = the Call-ID=20 of the other dialog as the correlation-value?
 
Thanks,
 Rifaat
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 Simo.Veikkolainen@nokia.com
Sent: Friday, September = 04, 2009=20 8:09 AM
To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Cc:=20 Markus.Isomaki@nokia.com
Subject: [dispatch] New topic = proposal=20 for DISPATCH

Hi,
 
We would like to propose a new DISPATCH topic on how SIP and = XMPP can=20 be used together in a complementary fashion.
 
We have been working on a solution which combines SIP based = VoIP and=20 XMPP based IM and Presence. The requirements and a proposed solution = is=20 outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip= -xmpp-im-01.
 
The motivation for this work comes from experience which shows = that=20 most standards based VoIP deployments use SIP. At the same time, the = Extensible Messaging and Presence Protocol (XMPP) is widely used in = instant=20 messaging and presence services. An interesting scenario arises when = a SIP=20 based voice (and video) service is combined together with an XMPP = based=20 instant messaging and presence service.
 
Note that the goal in this work is not SIP-XMPP protocol = translation,=20 but to define protocol extensions and best practises such that SIP = based=20 VoIP and XMPP based IM and presence could be seamlessly combined and = offered=20 to the end user. For rapid deployment, we assume no changes in the = server=20 infrastructure, and instead impose new requirements and protocol = extensions=20 only to the endpoints.
 
We would like to get some discussion going on the use case = itself as=20 well as on the solution. Also, we would like to hear you thoughts on = DISPATCH or a new "dispatched" mini-WG as the home for such = work.
 
Exact charter proposal and problem statemen is to follow. =
 
Regards,
Simo and Markus
 
 
------_=_NextPart_001_01CA434F.85AA8876-- From tom.taylor@rogers.com Fri Oct 2 06:13: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 E7AB428C0F4 for ; Fri, 2 Oct 2009 06:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 WVkrQyQN5p29 for ; Fri, 2 Oct 2009 06:13:12 -0700 (PDT) Received: from smtp107.rog.mail.re2.yahoo.com (smtp107.rog.mail.re2.yahoo.com [68.142.225.205]) by core3.amsl.com (Postfix) with SMTP id 961A428B797 for ; Fri, 2 Oct 2009 06:13:12 -0700 (PDT) Received: (qmail 95220 invoked from network); 2 Oct 2009 13:14:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iaziPs3fFhm3UWIVEIq/TJ6NC3MYWpaGrMn284+lXv6LaRu+VB+mcQF9jNUUclJSb6nbVHeinF54oI/8KTPe6KhWcseJ1HDNwfA3beO+wOwd0/ETccaYhIoCR9KnunqVNFwURDsmq6LtJhhEWSZJ2vJw+P23GyQ+tqTfmiBEnWQ= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp107.rog.mail.re2.yahoo.com with SMTP; 2 Oct 2009 13:14:38 -0000 X-YMail-OSG: tltg1zYVM1kduOxP2GIewU7ivDHJG6EBuZGt3Q4kf06hhD4ck_UkgVSpZgM6VFTRzQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC5FCBC.6090806@rogers.com> Date: Fri, 02 Oct 2009 09:14:36 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, L.Liess@telekom.de Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 02 Oct 2009 13:13:14 -0000 This is getting into very familiar territory -- Megaco did this stuff. For the semantics, have a look at the definitions in ITU-T Recommendation E.182 at http://www.itu.int/rec/T-REC-E.182-199803-I/en. Dean Willis wrote: > On Thu, October 1, 2009 2:45 pm, L.Liess@telekom.de wrote: >> >> Dean, >> >> I have some questions on your mail: >> >> > The ring-back for national standard ringers has always seemed >> >> > like a a >> > good application of URN in alert-info. In other words, if you >> call >> > somebody in France, you might get back a 180 with an >> > alert-info with a >> > URN that basically means "France standard ring tone". >> >> In the use-cases we have now in the draft, the end devices resolves the >> alert-URN. >> Would this be the same for the "France standard ring tone"? The user >> downloads a tone which >> reminds him of France and configures it as "France standard ring tone"? >> Or is it something else you have in mind? > > I think it needs to be a semantic definition. For example, someone who is > using a speech-to-text application for making a phone call should see > something like "Ringing: With French standard ring tone" so they would > know their call is being handled in France. > > So, given the semantic encoding, it's up the the UA to figure out how to > render it, possibly based on local configuration as you propose above. > This raises the question: would it be reasonable to have two entries, one > with a semantic value, the other with a more directive rendering that > could be used if the UA had no idea about the semantic value? > > >> > I vaguely remember discussion about URN-based alert-info for >> "public >> > alert" calls, like storm warnings and evacuation orders. >> > >> >> This makes sense to me and I will ask Brian, he is working on the >> emergency alerts stuff. >> >> Concerning the syntax of the urn's you propose, I see here two >> alternatives: >> >> 1) Defining new categories, additional to "tone" and "service", e.g. >> "national-ring-back-tones". The alert-URN for the "France standard ring >> tone" could look like urn:alert:national-ring-back-tones:standard.france > >> 2) Or just defining new alert-indications in the "tones"-category, e.g. >> like urn:alert:tones:standard-ring-back-tone.france >> >> Any thoughts/preferences on this? > > No preference here. I'm just guessing that somebody somewhere has a > registry of these things, and it might behoove us to follow its structure, > or at least to find the reference to it. > > > -- > Dean > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From fluffy@cisco.com Fri Oct 2 06:28: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 C884D3A69EB for ; Fri, 2 Oct 2009 06:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.055 X-Spam-Level: X-Spam-Status: No, score=-106.055 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 liggVi+pn+F7 for ; Fri, 2 Oct 2009 06:28:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6AB193A69E0 for ; Fri, 2 Oct 2009 06:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3068; q=dns/txt; s=sjiport06001; t=1254490183; x=1255699783; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[dispatch]=20TCP=20and=20SCTP=20connection=20reu se=20draft|Date:=20Thu,=201=20Oct=202009=2020:02:54=20-07 00|Message-Id:=20<99CBCA79-97E1-4068-84A6-D71161FBCA5A@ci sco.com>|To:=20"Vijay=20K.=20Gurbani"=20|Cc:=20"dispatch@ietf.org"=20, =0D=0A=20=20=20=20=20=20=20=20"Jain,=20Rajnish"=20,=0D=0A=20=20=20=20=20=20=20=20Hadriel=20K aplan=20|Mime-Version:=201.0=20(A pple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AC4C2 5A.3020909@alcatel-lucent.com>|References:=20<4AA7D34C.20 30804@alcatel-lucent.com>=20<7DE54C6D-63A5-45C1-A618-129B B4F3BE73@cisco.com>=20<4AC4C25A.3020909@alcatel-lucent.co m>; bh=nKOr0RsYwzaaJ0l+jyc0UL2PFfTe4xpgsT2p71iPU6k=; b=lNnMRi/j0kIHqpj06bufoN57zdi/N0CsvQcxgHzGc+qwPWzBvUlKap3/ HWK0RGtx6pEK9mQzcYHMXZnWQuuz5+7GCYzCviKgouMjMVdXSCDIqPgOV bkB7WJKJps4V/mCzXT3+L59esgYxCyscbt9iUBKospmqmjkCoVUclPsLE 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADadxUqrR7PD/2dsb2JhbAC/WYhbATIJjm0GgkuBYQ X-IronPort-AV: E=Sophos;i="4.44,494,1249257600"; d="scan'208";a="400780093" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2009 13:29:43 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n92DThVV024077; Fri, 2 Oct 2009 06:29:43 -0700 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n92DTd34019209; Fri, 2 Oct 2009 13:29:42 GMT Message-Id: <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> From: Cullen Jennings To: "Vijay K. Gurbani" In-Reply-To: <4AC4C25A.3020909@alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Oct 2009 20:02:54 -0700 References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3068; t=1254490183; x=1255354183; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[dispatch]=20TCP=20and=20SCTP=20connect ion=20reuse=20draft |Sender:=20; bh=nKOr0RsYwzaaJ0l+jyc0UL2PFfTe4xpgsT2p71iPU6k=; b=a9lKZ0U4IC6kRBgNOZVbelREb/FTWKnnbGRh9tCObNUQEnTmpz6397BbWw Zb0jKjTutYgWwAQhd9JXF6zxZSckJi8CvAC8iJdA19UvMwyAa7LGGuyKF0nq CHAkcFgjnt; Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 02 Oct 2009 13:28:16 -0000 So consider an case where the service provider proxy called sp.com has a rule that maps incoming phones call to +1 123 555-1xxx to enterprise A's proxy at a.com. If you resolve a.com in DNS you get an IP/port of 1.2.3.4:5060. Now b.com wants to hijack all the calls of enterprise A. It sends an an message to sp.com over a TCP connection and sends it with an VIA something like Via: SIP/2.0/TCP 1.2.3.4;branch=z9yadayada;alias The next call comes into to the sp destined to the phone number +1 234 555 1666. The SP maps this to a.com and does a DNS lookup on this and gets 1.2.3.4. It then looks in the alias table and sees that it already has an alias for this and sends the INVITE over the TCP connection that goes to b.com. It seems that reading the security section I get the idea that the things that stops this from happening is that b.com would have to be in the Spec(T) trust domain or else the alias parameter would be ignored. This seems like fairly week protection. I also have questions about how this all works with SCTP which there are multiple IP addresses and the attacker starts changing them but that more complex case is probably not worth discussing if I am still confused about the simpler TCP case. Seriously, I hope I am failing to understand how the security in the draft works. On Oct 1, 2009, at 7:53 , Vijay K. Gurbani wrote: > Cullen Jennings wrote: >> The security of this draft seems, uh, bad. It's so bad that I am >> having a really hard time believing I actually am understanding it >> correctly. Help me make sure that I have this right. >> Cisco and ACME are part of the AT&T trust domain and get sip >> trunking from AT&T. Cisco sends a via that has ACME on the alias to >> AT&T. There is nothing AT&T can do to validate this. Now Cisco has >> hijacked all of ACME's call. If the trust domain consisted of just >> one party, well I see how this might be secure, sort of, but it >> seems to fall apart as the trust domain expands. > > Cullen: Two observations in trying to drill down to the problem > definition here. First, I want to make sure that we are not > assuming the case of a virtual server sending requests on > different connections. While this was solvable for the TLS > case, it is not for the TCP case. > > Second, maybe I am not understanding the gist of what you > wrote above, but the connection reuse is between adjacent > nodes. In your example above, ATT will reuse the Cisco > connection when requests from ACME need to go to Cisco and > reuse the Acme connection when requests from Cisco need > to go to Acme. If my understanding is incorrect, can you > please amplify with a boxes and arrow diagram or something > along those lines? > > Thank you, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Fri Oct 2 07:18: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 B674F3A6A5B for ; Fri, 2 Oct 2009 07:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 CcTsjRcOgmgW for ; Fri, 2 Oct 2009 07:18:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id CD0543A6A50 for ; Fri, 2 Oct 2009 07:18:51 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n92EKHng020611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2009 09:20:17 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n92EKG1Z020160; Fri, 2 Oct 2009 09:20:16 -0500 (CDT) Message-ID: <4AC60C20.2050906@alcatel-lucent.com> Date: Fri, 02 Oct 2009 09:20:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> In-Reply-To: <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 02 Oct 2009 14:18:52 -0000 Cullen Jennings wrote: > So consider an case where the service provider proxy called sp.com has a > rule that maps incoming phones call to +1 123 555-1xxx to enterprise A's [...] Cullen: Yes, you are absolutely right in your example. > It seems that reading the security section I get the idea > that the things that stops this from happening is that b.com would have > to be in the Spec(T) trust domain or else the alias parameter would be > ignored. This seems like fairly week protection. We could possibly derive some heuristics like saving the DNS name in the connection object as well, but the fact remains that despite any heuristics, the primary security mechanism is the tie-in to Spec(T). It is weak and not enforceable to a great degree, but I believe it is the only option. Do you think the dependency on Spect(T) is not sufficient to get the draft through the IESG? What are our options if that is indeed the case? One option is to do nothing, but I think that is a disservice to the community that is using TCP connection reuse already. Better to have some guidelines than none. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From pkyzivat@cisco.com Fri Oct 2 07:37: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 B06D93A69E6 for ; Fri, 2 Oct 2009 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 Lw2hozJqNXSQ for ; Fri, 2 Oct 2009 07:37:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A14BB3A685A for ; Fri, 2 Oct 2009 07:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1637; q=dns/txt; s=sjiport03001; t=1254494314; x=1255703914; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20TCP=20and=20SCTP=20connection=20reu se=20draft|Date:=20Fri,=2002=20Oct=202009=2010:38:40=20-0 400|Message-ID:=20<4AC61070.2040608@cisco.com>|To:=20"Vij ay=20K.=20Gurbani"=20|CC:=20Culle n=20Jennings=20,=0D=0A=20=20=20=20=20 =20=20=20"dispatch@ietf.org"=20,=0D=0A =20=20=20=20=20=20=20=20"Jain,=20Rajnish"=20,=0D=0A=20=20=20=20=20=20=20=20Hadriel=20Kaplan =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AC60C 20.2050906@alcatel-lucent.com>|References:=20<4AA7D34C.20 30804@alcatel-lucent.com>=09<7DE54C6D-63A5-45C1-A618-129B B4F3BE73@cisco.com>=09<4AC4C25A.3020909@alcatel-lucent.co m>=09<99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com>=20< 4AC60C20.2050906@alcatel-lucent.com>; bh=dcXgqMoHlWMDLgsB2t0Y17tRCDVV04RMB1s3yh5u51k=; b=iELRfW2iv8DmqpLIRlHm83nbB8c2Z6KzZiAXPK1Am3H/MbTmN3CGu5iw 1L396jf6gOFY/T+kP4ZSkC/OMmwo5uZUuugV7cV8UL4YsCkrUyFGspJFB bazY6U9m/+FaafdkJ+P0RU0bq53tqPw70qGHdpYwFJXw/CdN4q3WAeCm5 s=; Authentication-Results: sj-iport-3.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOqsxUqrR7PD/2dsb2JhbAC/fIhbAY8mBoQs X-IronPort-AV: E=Sophos;i="4.44,494,1249257600"; d="scan'208";a="193920258" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 02 Oct 2009 14:38:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n92EcYKT019194; Fri, 2 Oct 2009 07:38:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n92EcTTi006718; Fri, 2 Oct 2009 14:38:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:38:29 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:38:28 -0400 Message-ID: <4AC61070.2040608@cisco.com> Date: Fri, 02 Oct 2009 10:38:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> <4AC60C20.2050906@alcatel-lucent.com> In-Reply-To: <4AC60C20.2050906@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2009 14:38:28.0712 (UTC) FILETIME=[01ADEE80:01CA436E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1637; t=1254494314; x=1255358314; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20TCP=20and=20SCTP=20connect ion=20reuse=20draft |Sender:=20; bh=dcXgqMoHlWMDLgsB2t0Y17tRCDVV04RMB1s3yh5u51k=; b=Ll+qKFfq6UqRLhWk2vrIYx2fGo7PCLavFuTLIYPK6tKYiytTAbndVSLvfo YDXfCo/A3Ven2GTWPbgdVupkNZfAo7iGNKuPvTyOKRnVLkZA949iynhHXmXp SIJDmA7K9q; Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 02 Oct 2009 14:37:07 -0000 IIUC, the key to avoiding the hyjacking that Cullen points out is that the server must not accept the alias unless it can authenticate the request containing the alias as coming from something responsible for the address carried in the alias. *How* that authentication is done can be defined in Spec(T), but the requirement to do it should be spelled out in the draft. Thanks, Paul Vijay K. Gurbani wrote: > Cullen Jennings wrote: >> So consider an case where the service provider proxy called sp.com has >> a rule that maps incoming phones call to +1 123 555-1xxx to enterprise >> A's > [...] > > Cullen: Yes, you are absolutely right in your example. > >> It seems that reading the security section I get the idea that the >> things that stops this from happening is that b.com would have to be >> in the Spec(T) trust domain or else the alias parameter would be >> ignored. This seems like fairly week protection. > > We could possibly derive some heuristics like saving the DNS > name in the connection object as well, but the fact remains > that despite any heuristics, the primary security mechanism > is the tie-in to Spec(T). It is weak and not enforceable > to a great degree, but I believe it is the only option. > > Do you think the dependency on Spect(T) is not sufficient > to get the draft through the IESG? What are our options if > that is indeed the case? > > One option is to do nothing, but I think that is a > disservice to the community that is using TCP connection > reuse already. Better to have some guidelines than none. > > Thanks, > > - vijay From vkg@alcatel-lucent.com Fri Oct 2 14:49: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 A3E1F3A689E for ; Fri, 2 Oct 2009 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 ee9L5urSuNeK for ; Fri, 2 Oct 2009 14:49:31 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 91C413A682E for ; Fri, 2 Oct 2009 14:49:31 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n92LovMB027326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2009 16:50:57 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n92LovMY018783; Fri, 2 Oct 2009 16:50:57 -0500 (CDT) Message-ID: <4AC675C0.2070302@alcatel-lucent.com> Date: Fri, 02 Oct 2009 16:50:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> <4AC60C20.2050906@alcatel-lucent.com> <4AC61070.2040608@cisco.com> In-Reply-To: <4AC61070.2040608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 02 Oct 2009 21:49:32 -0000 Paul Kyzivat wrote: > IIUC, the key to avoiding the hyjacking that Cullen points out is that > the server must not accept the alias unless it can authenticate the > request containing the alias as coming from something responsible for > the address carried in the alias. > > *How* that authentication is done can be defined in Spec(T), but the > requirement to do it should be spelled out in the draft. Paul: Thank you for shedding some light on the amorphous Spec(T). So, procedurally speaking, what should we do to move this work forward? Note that the requirement of complying to Spec(T) is already there in the draft (S6); what is unsure is how to specify a Spec(T) that provides for this authentication? Clearly Digest cannot be used if the neighbors interested in doing connection reuse are proxies. Can we simply leave it at saying that nodes in a Spec(T) for TCP connection reuse have a policy to trust each other (and leave that policy unspecified)? I hope I am making sense ...? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From pkyzivat@cisco.com Sat Oct 3 11:41:20 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 063893A6359 for ; Sat, 3 Oct 2009 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 0T6UY+zFRL5p for ; Sat, 3 Oct 2009 11:41:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2F6323A67B0 for ; Sat, 3 Oct 2009 11:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1621; q=dns/txt; s=rtpiport01001; t=1254595369; x=1255804969; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20TCP=20and=20SCTP=20connection=20reu se=20draft|Date:=20Sat,=2003=20Oct=202009=2014:42:45=20-0 400|Message-ID:=20<4AC79B25.5000307@cisco.com>|To:=20"Vij ay=20K.=20Gurbani"=20|CC:=20Culle n=20Jennings=20,=0D=0A=20=20=20=20=20 =20=20=20"dispatch@ietf.org"=20,=0D=0A =20=20=20=20=20=20=20=20"Jain,=20Rajnish"=20,=0D=0A=20=20=20=20=20=20=20=20Hadriel=20Kaplan =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AC675 C0.2070302@alcatel-lucent.com>|References:=20<4AA7D34C.20 30804@alcatel-lucent.com>=09<7DE54C6D-63A5-45C1-A618-129B B4F3BE73@cisco.com>=09<4AC4C25A.3020909@alcatel-lucent.co m>=09<99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com>=20< 4AC60C20.2050906@alcatel-lucent.com>=20<4AC61070.2040608@ cisco.com>=20<4AC675C0.2070302@alcatel-lucent.com>; bh=imAqszwKHsstE+HpiEUeP4XDL7FVxgWQwuzwRU0PCq4=; b=vE2p+3OJi0HtFbr3oLw/k0+zjk/HB3Uu/BTq56Dk0ExMVcyqM6qFp5+Q gRp3mhY7379u4dTL1Z+2AIYeR5LlRcg++Q+bs9580Rx1rgBvc3/jzboay q+ytIcmxKZ6FtGYe+lOKpA136fJfPfC3uaUwMN58Ax5JMkzo+5t1aBxIw w=; Authentication-Results: rtp-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABM4x0pAZnme/2dsb2JhbAC6KIhhAY5WBoQq X-IronPort-AV: E=Sophos;i="4.44,500,1249257600"; d="scan'208";a="61314429" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Oct 2009 18:42:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n93Igmqq022289; Sat, 3 Oct 2009 14:42:48 -0400 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 n93IgmD5015319; Sat, 3 Oct 2009 18:42:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Oct 2009 14:42:48 -0400 Received: from [10.86.247.186] ([10.86.247.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Oct 2009 14:42:44 -0400 Message-ID: <4AC79B25.5000307@cisco.com> Date: Sat, 03 Oct 2009 14:42:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> <4AC60C20.2050906@alcatel-lucent.com> <4AC61070.2040608@cisco.com> <4AC675C0.2070302@alcatel-lucent.com> In-Reply-To: <4AC675C0.2070302@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2009 18:42:44.0826 (UTC) FILETIME=[4BD133A0:01CA4459] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1621; t=1254595368; x=1255459368; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20TCP=20and=20SCTP=20connect ion=20reuse=20draft |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=imAqszwKHsstE+HpiEUeP4XDL7FVxgWQwuzwRU0PCq4=; b=gJq5C1vdTcBzAp2HdboqBHgUhBM4d7EAZ4W3qBY2KHQ8Y/awtWmZ8sgBg2 cg1drtT9sRMdpnYBy1usVeMAhXNnLQcUU1fJu7PlECkMp2kreD862ANZLhul OGRtPtQJdR; Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 03 Oct 2009 18:41:20 -0000 Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> IIUC, the key to avoiding the hyjacking that Cullen points out is that >> the server must not accept the alias unless it can authenticate the >> request containing the alias as coming from something responsible for >> the address carried in the alias. >> >> *How* that authentication is done can be defined in Spec(T), but the >> requirement to do it should be spelled out in the draft. > > Paul: Thank you for shedding some light on the amorphous Spec(T). > So, procedurally speaking, what should we do to move this work > forward? > > Note that the requirement of complying to Spec(T) is already > there in the draft (S6); what is unsure is how to specify > a Spec(T) that provides for this authentication? Clearly > Digest cannot be used if the neighbors interested in doing > connection reuse are proxies. Can we simply leave it at > saying that nodes in a Spec(T) for TCP connection reuse have > a policy to trust each other (and leave that policy unspecified)? > > I hope I am making sense ...? I'm not a security expert. What I said was at the limit of my understanding of this. That whole Spec(T) thing has always been obscure to me. I had in mind the use of digest. That would work if the neighbors are both UAs. (Unfortunately it seems this might be a common case, with SBCs talking to one another.) But if that is not the case, then it certainly isn't apparent to me what the answer would be. Maybe Cullen to shed more light based on that observation. Or maybe it doesn't help at all. Thanks, Paul From pkyzivat@cisco.com Sat Oct 3 15:01: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 498DB3A63EB for ; Sat, 3 Oct 2009 15:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.147, 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 TJhNvn+G3YoJ for ; Sat, 3 Oct 2009 15:01:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0F7B63A6359 for ; Sat, 3 Oct 2009 15:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4586; q=dns/txt; s=rtpiport01001; t=1254607384; x=1255816984; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Charter=20Proposal=20for=20Disaggre gated=20Media|Date:=20Sat,=2003=20Oct=202009=2018:03:01 =20-0400|Message-ID:=20<4AC7CA15.1050303@cisco.com>|To: =20Salvatore=20Loreto=20 |CC:=20IETF=20Dispatch=20,=0D=0A=20=20 =20=20=20=20=20=20Gonzalo=20Camarillo=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4ABA2B FA.40209@ericsson.com>|References:=20<4AB75AC7.6080509@er icsson.com>=20<4AB79C7C.5010803@cisco.com>=20<4ABA2BFA.40 209@ericsson.com>; bh=Sz5+bSsu47pd3s02PNfiz1L8r3bAv5rMG9ccogintZ4=; b=LBQ9pfe3j8IFa2uTE0XhoFafVAWJrzVPw7E8tXxcAF6PI4Xaa9EliU9i GNcW9Y798ihXTucu14TeSK+eVH/TI51sSdbs+Cnbm132unENy21I6g7e9 cM3x7ip7kaVMW7AF729Vh6Pu8yadTnH3T4yVRXei5qcMvikUX/Axnuszu 8=; Authentication-Results: rtp-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPNmx0pAZnme/2dsb2JhbAC6DIhhAY49BoQq X-IronPort-AV: E=Sophos;i="4.44,500,1249257600"; d="scan'208";a="61324266" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Oct 2009 22:03:03 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n93M33RF018639; Sat, 3 Oct 2009 18:03:03 -0400 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 n93M33lv005523; Sat, 3 Oct 2009 22:03:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Oct 2009 18:03:03 -0400 Received: from [10.86.247.186] ([10.86.247.186]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Oct 2009 18:03:02 -0400 Message-ID: <4AC7CA15.1050303@cisco.com> Date: Sat, 03 Oct 2009 18:03:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4AB75AC7.6080509@ericsson.com> <4AB79C7C.5010803@cisco.com> <4ABA2BFA.40209@ericsson.com> In-Reply-To: <4ABA2BFA.40209@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2009 22:03:02.0822 (UTC) FILETIME=[4719DC60:01CA4475] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4586; t=1254607383; x=1255471383; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20Proposal=20for=2 0Disaggregated=20Media |Sender:=20 |To:=20Salvatore=20Loreto=20; bh=Sz5+bSsu47pd3s02PNfiz1L8r3bAv5rMG9ccogintZ4=; b=p0hLFlYYN1fJDp0Xoe+R+j5laqpqW/bQf+xj2NkV5fs9bAwa5v0D+AVYtx Npjf1oLqGXgFR2qZ1NOrrmI/8W9J4UuyoiGaEGPdUAm89mn6o+0+O1z+Ps9k 426eqt7xRR; Cc: IETF Dispatch , Gonzalo Camarillo Subject: Re: [dispatch] Charter Proposal for 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, 03 Oct 2009 22:01:34 -0000 Sal, Sorry I've been rather unresponsive lately. I've been busy with other things. I think we are starting to get somewhere with your responses below. Also, all the other discussion on this topic is starting to gell into something that makes sense. Its still my opinion that if I am calling you, and I want to use multiple devices for my end of the call, that should be *my* problem, not yours. There are many possible mechanics for achieving that. IIUC, your argument is that making it *your* responsibility instead of mine allows for a more "loosely coupled" solution. I'm not entirely convinced of that. At the very least I am now "tightly coupled" in the sense that I can only make a disaggregated media call when the callee supports it. Unless that support becomes ubiquitous, it is a problem. The most compelling case so far that I have seen mentioned is the SIP+XMPP case. Its compelling because XMPP uses session establishment that is incompatible with SIP. But it still suffers all the same problems. In any case, I think the problem statement for the new WG is shaping up well, and there is a good community of interested parties with a variety of viewpoints. So I think we are now going in a good direction. Thanks, Paul Salvatore Loreto wrote: > Hi Paul, > > thanks for the comments, please see my answers in line > > cheers > Sal > > > Paul Kyzivat wrote: >> I agree with the utility of such work. Comments inline. >> > >> I don't understand the above. The disaggregated multimedia session >> will not be established unless *something* takes the initiative to >> establish it. IMO that thing, whatever it is, is acting as a >> "controller". >> >> The mechanism you have proposed before distributes the "controller" >> functionality across multiple nodes. There is something that causes a >> new stream to be established as a separate sip session and causes that >> to announce correlation with some other session. And then there is are >> the devices at the far end, that maintain the correlation and do >> required maintenance of the correlation as changes happen. >> >> Can you provide more definition of what you mean by "loosely coupled" >> while recognizing that something needs to know enough to do the >> initiation and maintenance of the correlation? >> > the "loosely couple control" is a scenario where you can easily remove, > at any point, any of several devices involved in the conversation, and > the other end of the conversation will remain unaffected. > > easily and at any point mean that you do not need to start a complicate > mechanism before you can remove the device (e.g. you do not need to > choose a new controller and transfer the control to it) > > of course loosely couple control still needs some sort of control, you > are right. > However the control could be easily a "distributed" control with a > minimal amount of information, where, for example, each device involved > in the conversation only knows the list of all the other devices > involved in the conversation, but it does not need to know the full > state "information" related to the dialog that each device has with the > far end of the conversation. >>> The objective of the proposed working group is to develop a framework >>> for Disaggregated Media that include both improvements on existing >>> mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms >>> like a loosely coupled mechanism that does not require the >>> implementation of complex logic on any of the terminals. >> >> I would argue that it is premature to assert that new mechanisms are >> required. > right, that is something the community has to decide. >>> Specifically, the proposed working group will develop the following >>> deliverables: 1. A framework document describing key design >>> considerations for Disaggregated mediamechanism. >>> 2. A specification for a loosely couple mechanism. >>> 3. One or more specifications to improve existing mechanism to >>> coordinate >>> disaggregated media. >> >> Are both (2) and (3) *specifications*? Or is (2) a requirements >> document that is then satisfied by (3)? > yes (1) and (2) can be combined and then eventually produce a new actual > mechanism. >> >> If (2) is requirements, then this makes sense to me, though it might >> be possible to combine that with (1). If both (2) and (3) are >> mechanism specs then I don't get it. >> >> Thanks, >> Paul > > From mary.barnes@nortel.com Sat Oct 3 15:15: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 6786A3A695C for ; Sat, 3 Oct 2009 15:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 MAio0DTHQHrW for ; Sat, 3 Oct 2009 15:15:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8D1903A63EB for ; Sat, 3 Oct 2009 15:15:28 -0700 (PDT) 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 n93MGsv15482; Sat, 3 Oct 2009 22:16:54 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: Sat, 3 Oct 2009 17:18:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF206283EA@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AACPh1zQBo/AzA References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , Subject: Re: [dispatch] DISPATCH IETF-76 plans 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, 03 Oct 2009 22:15:30 -0000 Hi Christer, Per RFC 3427bis, the procedure for event packages is as follows: Individual proposals for registration of a SIP event package MUST first be published as Internet-drafts for review by the DISPATCH Working Group, or the working group, mailing list, or expert designated by the RAI Area Directors if the DISPATCH Working Group has closed. Proposals should include a strong motivational section, a thorough description of the proposed syntax and semantics, event package considerations, security considerations, and examples of usage. Authors should submit their proposals as individual Internet- Drafts, and post an announcement to the working group mailing list to begin discussion. The DISPATCH Working Group will determine if a proposed package is a) an appropriate usage of SIP which should be spun into a new effort, b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort, c) contrary to similar work chartered in an existing effort, or d) should be adopted as or merged with chartered work. So, you're at the point of determining whether the proposed event package fits into the a), b), c) or d), which is what determines how the solution work would be handled. It's not clear to me from looking at the discussion thread that the working has agreed the category - i.e., I see some suggestions that this could be a general mechanism, etc.=20 I realize the new process is slightly confusing, but the idea beyond the charter proposals is to ensure that the problem statement is clear and well scoped and that the path forward for a solution is well understood and is agreed by the DISPATCH WG (and ADs, of course).=20 Thanks, Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, October 01, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: RE: [dispatch] DISPATCH IETF-76 plans Hi Mary, =20 Regarding CBUS, there has been some questoin regarding the event package definition procedure, so to start with I think it would be useful to get that clarified. =20 Regards, =20 Christer ________________________________ From: dispatch-bounces@ietf.org on behalf of Mary Barnes Sent: Thu 01/10/2009 15:56 To: dispatch@ietf.org Subject: [dispatch] DISPATCH IETF-76 plans Hi all, Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been previously put forth - both prior to Sept. 7th deadline and up through the 21st. Obviously, we have to balance interest and willingness to contribute to the work (based on mailing list discussions) with the fact that some folks were more conscientious in meeting the deadlines. We received charter proposals (problem statements/deliverables) for the following, with the current status highlighted.=20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion. o CBUS: some good discussion on problem statement. Needs more discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready?=20 o Disaggregated media: Good level of interest o SIP - XMPP: High level of WG interest. Propose a separate Mailing list and Adhoc at IETF-76. o Alert-info URNs: Good level of interest. o NGN Reason: Some interest. Needs more discussion and scoping. The above items are the current targets for IETF-76 discussions. Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the time the agenda is finalized. As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some discussion. But, no discussion since that time. o Identity: Document available. Need further discussion and WG feedback to refine requirements, problem statement, scope and deliverables/milestones. o Domain registrations in SIP: Problem statement posted, but no deliverables/milestones or document. o Reference to an earlier communication: Problem statement posted, but no deliverables/milestones or document. As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available early enough for the WG to provide feedback - i.e., you do not have to wait for the pre-meeting deadlines, which are more in the way of drop dead dates than optimal dates.=20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Sat Oct 3 15:48: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 E68B83A69C2 for ; Sat, 3 Oct 2009 15:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 HRZeiRYh+8bL for ; Sat, 3 Oct 2009 15:48:00 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B4BA53A6818 for ; Sat, 3 Oct 2009 15:47:59 -0700 (PDT) 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 n93MnMv16660; Sat, 3 Oct 2009 22:49:22 GMT 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: Sat, 3 Oct 2009 17:50:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwABVAQHw References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 03 Oct 2009 22:48:01 -0000 Hi Roland, Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Friday, October 02, 2009 12:51 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From drage@alcatel-lucent.com Sat Oct 3 16:59: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 C739F3A6832 for ; Sat, 3 Oct 2009 16:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, HELO_EQ_FR=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 HTbf0FVSk4ry for ; Sat, 3 Oct 2009 16:59:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 52CD23A67A4 for ; Sat, 3 Oct 2009 16:59:37 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n94012ko018681 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 Oct 2009 02:01:02 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 4 Oct 2009 02:01:02 +0200 From: "DRAGE, Keith (Keith)" To: "Gurbani, Vijay K (Vijay)" Date: Sun, 4 Oct 2009 02:01:01 +0200 Thread-Topic: [dispatch] TCP and SCTP connection reuse draft Thread-Index: AcpDqnQpAW23mU+pT2G0z/kQYrzxRgA1aKjw Message-ID: References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> <4AC60C20.2050906@alcatel-lucent.com> <4AC61070.2040608@cisco.com> <4AC675C0.2070302@alcatel-lucent.com> In-Reply-To: <4AC675C0.2070302@alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 03 Oct 2009 23:59:39 -0000 >From what I remember Spec (T) doesn't quite work like that. What Spec(T) essentially does is put down on paper the questions that need = to be satisfactorily answered for your peer to determine whether you are tr= ustworthy in regard to the identify or not.=20 There is thus an element of "Do the answers to these questions match the le= vel of authentication that I wish to have on identity within my own trust d= omain?".=20 regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: Friday, October 02, 2009 10:51 PM > To: Paul Kyzivat > Cc: dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan > Subject: Re: [dispatch] TCP and SCTP connection reuse draft >=20 > Paul Kyzivat wrote: > > IIUC, the key to avoiding the hyjacking that Cullen points=20 > out is that=20 > > the server must not accept the alias unless it can authenticate the=20 > > request containing the alias as coming from something=20 > responsible for=20 > > the address carried in the alias. > >=20 > > *How* that authentication is done can be defined in=20 > Spec(T), but the=20 > > requirement to do it should be spelled out in the draft. >=20 > Paul: Thank you for shedding some light on the amorphous Spec(T). > So, procedurally speaking, what should we do to move this=20 > work forward? >=20 > Note that the requirement of complying to Spec(T) is already=20 > there in the draft (S6); what is unsure is how to specify a=20 > Spec(T) that provides for this authentication? Clearly=20 > Digest cannot be used if the neighbors interested in doing=20 > connection reuse are proxies. Can we simply leave it at=20 > saying that nodes in a Spec(T) for TCP connection reuse have=20 > a policy to trust each other (and leave that policy unspecified)? >=20 > I hope I am making sense ...? >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 > Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From christer.holmberg@ericsson.com Sun Oct 4 13:48:48 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 A09823A68EC for ; Sun, 4 Oct 2009 13:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=0.510, 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 ghogY3-IcPhR for ; Sun, 4 Oct 2009 13:48:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DF3743A6405 for ; Sun, 4 Oct 2009 13:48:46 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-28-4ac90a8ac2f7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8A.AF.02516.A8A09CA4; Sun, 4 Oct 2009 22:50:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 22:50:18 +0200 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: Sun, 4 Oct 2009 22:50:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AACPh1zQBo/AzAADLgqX8= References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF206283EA@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , X-OriginalArrivalTime: 04 Oct 2009 20:50:18.0009 (UTC) FILETIME=[47E20090:01CA4534] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] DISPATCH IETF-76 plans 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, 04 Oct 2009 20:48:48 -0000 Hi Mary, >Per RFC 3427bis, the procedure for event packages is as follows: > > Individual proposals for registration of a SIP event package MUST > first be published as Internet-drafts for review by the DISPATCH > Working Group, or the working group, mailing list, or expert > designated by the RAI Area Directors if the DISPATCH Working Group > has closed. Proposals should include a strong motivational section, > a thorough description of the proposed syntax and semantics, event > package considerations, security considerations, and examples of > usage. Authors should submit their proposals as individual = Internet- > Drafts, and post an announcement to the working group mailing list = to > begin discussion. The DISPATCH Working Group will determine if a > proposed package is a) an appropriate usage of SIP which should be > spun into a new effort, b) applicable to SIP but not sufficiently > interesting, general, or in-scope to adopt as a working group = effort, > c) contrary to similar work chartered in an existing effort, or d) > should be adopted as or merged with chartered work. > >So, you're at the point of determining whether the proposed event >package fits into the a), b), c) or d), which is what determines how = the >solution work would be handled. It's not clear to me from looking at >the discussion thread that the working has agreed the category - i.e., = I >see some suggestions that this could be a general mechanism, etc. > >I realize the new process is slightly confusing, but the idea beyond = the >charter proposals is to ensure that the problem statement is clear and >well scoped and that the path forward for a solution is well understood >and is agreed by the DISPATCH WG (and ADs, of course). We did submit a draft. We did get some feedback for clarification, and=20 our intention is to submit a new version of the draft. =20 But, there were some comments and questiongs about the procedures, and = we wanted to sort those out. =20 Now, as far as a), b), c) and d) are concerned, I see no reason why this = would not be approriate usage of SIP. Whether it fits into an existing chartered = work, I think it fits into=20 SIPCORE charter, which does include SUB/NOT related issues. =20 Having said that, RFC 4660/1 were done in SIMPLE, so I guess that would = be another alternative. =20 Personally I do not see a need to form a new WG for this, but that is of = course for the WG to decide. =20 Regards, =20 Christer =20 =20 =20 =20 =20 =20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, October 01, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: RE: [dispatch] DISPATCH IETF-76 plans Hi Mary, Regarding CBUS, there has been some questoin regarding the event package definition procedure, so to start with I think it would be useful to get that clarified. Regards, Christer ________________________________ From: dispatch-bounces@ietf.org on behalf of Mary Barnes Sent: Thu 01/10/2009 15:56 To: dispatch@ietf.org Subject: [dispatch] DISPATCH IETF-76 plans Hi all, Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been previously put forth - both prior to Sept. 7th deadline and up through the 21st. Obviously, we have to balance interest and willingness to contribute to the work (based on mailing list discussions) with the fact that some folks were more conscientious in meeting the deadlines. We received charter proposals (problem statements/deliverables) for the following, with the current status highlighted. o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion. o CBUS: some good discussion on problem statement. Needs more discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? o Disaggregated media: Good level of interest o SIP - XMPP: High level of WG interest. Propose a separate Mailing list and Adhoc at IETF-76. o Alert-info URNs: Good level of interest. o NGN Reason: Some interest. Needs more discussion and scoping. The above items are the current targets for IETF-76 discussions. Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the time the agenda is finalized. As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some discussion. But, no discussion since that time. o Identity: Document available. Need further discussion and WG feedback to refine requirements, problem statement, scope and deliverables/milestones. o Domain registrations in SIP: Problem statement posted, but no deliverables/milestones or document. o Reference to an earlier communication: Problem statement posted, but no deliverables/milestones or document. As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available early enough for the WG to provide feedback - i.e., you do not have to wait for the pre-meeting deadlines, which are more in the way of drop dead dates than optimal dates. Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From crjohnson1@att.com Tue Sep 8 18:23: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 F3D3B3A689A; Tue, 8 Sep 2009 18:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hxyXV0f43bXr; Tue, 8 Sep 2009 18:23:56 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id BA5303A682B; Tue, 8 Sep 2009 18:23:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: crjohnson1@att.com X-Msg-Ref: server-8.tower-167.messagelabs.com!1252459460!15129568!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13757 invoked from network); 9 Sep 2009 01:24:21 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2009 01:24:21 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n891OLL7010837; Tue, 8 Sep 2009 21:24:21 -0400 Received: from misout7msgusr7d.ugd.att.com (misout7msgusr7d.ugd.att.com [144.155.43.106]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n891OFoQ010824; Tue, 8 Sep 2009 21:24:15 -0400 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 Message-ID: <9DE31798099D044DA5F3C0DEAB107C5A03C451E4@misout7msgusr7d.ugd.att.com> In-Reply-To: <4A8D551B.7060308@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] Revised Charter Proposal for SIP Overload Thread-Index: AcohnYQuAg4halqwT069AAL/gB8D5QABWWIg References: <4A8D551B.7060308@alcatel-lucent.com> From: "JOHNSON, CAROLYN R, ATTLABS" To: "Volker Hilt" , "DISPATCH" , "SIP-OVERLOAD" , "NOEL, ERIC C, ATTLABS" X-Mailman-Approved-At: Sun, 04 Oct 2009 22:48:53 -0700 Subject: Re: [dispatch] [sip-overload] Revised Charter Proposal for SIP Overload 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: , Date: Wed, 09 Sep 2009 01:23:58 -0000 X-Original-Date: Tue, 8 Sep 2009 21:24:13 -0400 X-List-Received-Date: Wed, 09 Sep 2009 01:23:58 -0000 Volker, Sorry for the delay, this got stuck in my drafts folder while I was out on vacation. One comment on the last dashed item: - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. I suggest replacing "telephone number" with "destination routing" so as not to limit to applications that use telephone prefixes. I believe it will be more general without losing the applicability to telephone IDs. The charter is clearly laid out.=20 Regards, Carolyn =20 -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent: Thursday, August 20, 2009 9:52 AM To: DISPATCH; SIP-OVERLOAD Subject: [sip-overload] Revised Charter Proposal for SIP Overload All, below is an revised SIP Overload Control charter proposal. I have received a few comments that are reflected in the new proposal. All comments, thoughts, feedback is very welcome! Thanks, Volker SIP Overload Control WG Charter ------------------------------- As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to process all incoming SIP messages. These resources can include CPU, memory, network bandwidth, input/output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the proposed working group is to develop mechanisms for SIP overload control. Two complementary approaches exist for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. Specifically, the proposed working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From ecnoel@att.com Thu Oct 1 08:16: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 F2B043A698C; Thu, 1 Oct 2009 08:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.044 X-Spam-Level: X-Spam-Status: No, score=-106.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, 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 oY9B3KM7YM0J; Thu, 1 Oct 2009 08:16:18 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id C478B3A6783; Thu, 1 Oct 2009 08:16:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ecnoel@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1254410262!3069964!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6091 invoked from network); 1 Oct 2009 15:17:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2009 15:17:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n91FHgke001762; Thu, 1 Oct 2009 11:17:42 -0400 Received: from misout7msgusr7b.ugd.att.com (misout7msgusr7b.ugd.att.com [144.155.43.104]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n91FHbs9001723; Thu, 1 Oct 2009 11:17:37 -0400 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, 1 Oct 2009 11:17:37 -0400 Message-ID: <5DA01D2CA74FAF40ADF71DB4177D345A02684E54@misout7msgusr7b.ugd.att.com> In-Reply-To: <4AA70C29.8020804@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP-OVERLOAD confernece call this morning? Thread-Index: Acow8VRa6Kmh5CjLTZaBc20kG+p5JgRuMPrA References: <4A8D551B.7060308@alcatel-lucent.com> <9DE31798099D044DA5F3C0DEAB107C5A03C451E4@misout7msgusr7d.ugd.att.com> <4AA70C29.8020804@bell-labs.com> From: "NOEL, ERIC C, ATTLABS" To: "Volker Hilt" X-Mailman-Approved-At: Sun, 04 Oct 2009 22:48:53 -0700 Cc: DISPATCH , SIP-OVERLOAD Subject: [dispatch] SIP-OVERLOAD confernece call this morning? 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, 01 Oct 2009 15:16:23 -0000 Volker, Is there a conference call this morning? I was away during last meeting and may have missed the schedule. Thanks, Eric From thomas.belling@nsn.com Mon Oct 5 09:01: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 2CD8B3A6A0D for ; Mon, 5 Oct 2009 09:01:19 -0700 (PDT) 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 yvJGPqguM4qG for ; Mon, 5 Oct 2009 09:01:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8F6303A6821 for ; Mon, 5 Oct 2009 09:01:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n95G2pPc011477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2009 18:02:51 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n95G2pG9024003; Mon, 5 Oct 2009 18:02:51 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 18:02:51 +0200 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: Mon, 5 Oct 2009 18:02:49 +0200 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72296AF79@DEMUEXC014.nsn-intra.net> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwACihIDQ References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> From: "Belling, Thomas (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 05 Oct 2009 16:02:51.0000 (UTC) FILETIME=[4A470780:01CA45D5] Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 05 Oct 2009 16:01:19 -0000 Hi Roland, Mary all 3GPP is relying upon this and waiting already for a long time for this = to be progressed. I would be very grateful if a way forward to bring this into RFC state = in the foreseeable future could be found. Roland, thanks for raising the 183 issue. As this entire work is = motivated by ISUP interworking and ISUP also allows for Causes in ACM or = CPG, it makes sense to allow the reason headers also in the = corresponding SIP 180 and 183 responses. I expect some related = discussions in the 3GPP CT3 meeting next week. Perhaps you can then = update the draft accordingly (also relating to the requirements = section). Thomas -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext R.Jesske@telekom.de Sent: Friday, October 02, 2009 7:51 AM To: mary.barnes@nortel.com; dispatch@ietf.org Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG 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 vkg@alcatel-lucent.com Mon Oct 5 14:01: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 0A1583A67ED for ; Mon, 5 Oct 2009 14:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_40=-0.185] 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 vR0tgO1kIICy for ; Mon, 5 Oct 2009 14:01:25 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E9E913A6407 for ; Mon, 5 Oct 2009 14:01:24 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n95L2x9A025832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 16:02:59 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n95L2xt1025242; Mon, 5 Oct 2009 16:02:59 -0500 (CDT) Message-ID: <4ACA5F03.3070803@alcatel-lucent.com> Date: Mon, 05 Oct 2009 16:02:59 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> <4AC60C20.2050906@alcatel-lucent.com> <4AC61070.2040608@cisco.com> <4AC675C0.2070302@alcatel-lucent.com> <4AC79B25.5000307@cisco.com> In-Reply-To: <4AC79B25.5000307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 05 Oct 2009 21:01:26 -0000 Paul Kyzivat wrote: > I'm not a security expert. What I said was at the limit of my > understanding of this. That whole Spec(T) thing has always been obscure > to me. > > I had in mind the use of digest. That would work if the neighbors are > both UAs. (Unfortunately it seems this might be a common case, with SBCs > talking to one another.) But if that is not the case, then it certainly > isn't apparent to me what the answer would be. > > Maybe Cullen to shed more light based on that observation. Or maybe it > doesn't help at all. Paul: Thanks for your help. I have talked to Cullen about this draft in the past, but clearly the security story still needs more work. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Mon Oct 5 14:04:41 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 63C1028C20C for ; Mon, 5 Oct 2009 14:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 s6x+7UD8zqON for ; Mon, 5 Oct 2009 14:04:40 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7251728C232 for ; Mon, 5 Oct 2009 14:04:39 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n95L6FoR027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Oct 2009 16:06:15 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n95L6FIG028955; Mon, 5 Oct 2009 16:06:15 -0500 (CDT) Message-ID: <4ACA5FC6.50709@alcatel-lucent.com> Date: Mon, 05 Oct 2009 16:06:14 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4AA7D34C.2030804@alcatel-lucent.com> <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> <4AC4C25A.3020909@alcatel-lucent.com> <99CBCA79-97E1-4068-84A6-D71161FBCA5A@cisco.com> <4AC60C20.2050906@alcatel-lucent.com> <4AC61070.2040608@cisco.com> <4AC675C0.2070302@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] TCP and SCTP connection reuse draft 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, 05 Oct 2009 21:04:41 -0000 DRAGE, Keith (Keith) wrote: > From what I remember Spec (T) doesn't quite work like that. > > What Spec(T) essentially does is put down on paper the questions that > need to be satisfactorily answered for your peer to determine whether > you are trustworthy in regard to the identify or not. Keith: Thanks for your input. So, the question is how strong is this guarantee supposed to be? Is it supposed to be cryptographically strong? or is it something that can be very elastic? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From john.elwell@siemens-enterprise.com Tue Oct 6 03:27: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 9790628C312 for ; Tue, 6 Oct 2009 03:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 qbf0N+j+FqMY for ; Tue, 6 Oct 2009 03:27:38 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 72EA53A684C for ; Tue, 6 Oct 2009 03:27:37 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n96ATDSo027088 for ; Tue, 6 Oct 2009 12:29:13 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n96ATDVo017769 for ; Tue, 6 Oct 2009 12:29:13 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Tue, 6 Oct 2009 12:29:12 +0200 From: "Elwell, John" To: "dispatch@ietf.org" Date: Tue, 6 Oct 2009 12:29:10 +0200 Thread-Topic: I-D Action:draft-elwell-dispatch-identity-reqs-01.txt Thread-Index: AcpGbiHd/bDyxTr1Rm6tLFgBb7Hq1wAAUH+w Message-ID: <7402509E63C5A145A6095D46C179A5B710064F04@DEMCHP99E35MSX.ww902.siemens.net> References: <20091006101502.8E2C028C30C@core3.amsl.com> In-Reply-To: <20091006101502.8E2C028C30C@core3.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] I-D Action:draft-elwell-dispatch-identity-reqs-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, 06 Oct 2009 10:27:39 -0000 This addresses some comments received. Changes are not too extensive (see C= hange Log). >From the limited comments received, it seems this is moving in the right di= rection, but in addition to further comments on the document itself, the au= thors would very much appreciate ideas on where to go from here. John > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 06 October 2009 11:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-elwell-dispatch-identity-reqs-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Requirements for secure caller=20 > identification in the Session Initiation Protocol (SIP) > Author(s) : J. Elwell, V. Pascual > Filename : draft-elwell-dispatch-identity-reqs-01.txt > Pages : 11 > Date : 2009-10-06 >=20 > This document examines requirements for secure caller identification > in SIP. Although existing mechanisms exist to achieve this, there > are some known shortcomings or deployment difficulties. >=20 > This work is being discussed on the dispatch@ietf.org mailing list. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs-0= 1.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. > = From R.Jesske@telekom.de Tue Oct 6 07:00: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 7512128C1BC for ; Tue, 6 Oct 2009 07:00:56 -0700 (PDT) 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 eoqKti-7G1kd for ; Tue, 6 Oct 2009 07:00:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 10A7328C183 for ; Tue, 6 Oct 2009 07:00:53 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 06 Oct 2009 16:02:02 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 16:01:31 +0200 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: Tue, 6 Oct 2009 16:01:29 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwABVAQHwAD/QSeA= References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 06 Oct 2009 14:01:31.0219 (UTC) FILETIME=[819A5A30:01CA468D] Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 06 Oct 2009 14:00:56 -0000 Hi Mary, Thank you for your clarification. So I will wait for that discussion.=20 With regard to your question I'm not really clear what the best way = would be. This behaviour would complete the behaviour of RFC 3326. And RFC 3326 = gives clear guidance what to do with the case for Reason in Responses, = so it is my understanding to have an own document. So that is my = proposal. Question is now if it should be an informal document. If this is = sufficient I'm happy with that way if not we should change the status. I = would be happy on comments on this. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Gesendet: Sonntag, 4. Oktober 2009 00:51 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Friday, October 02, 2009 12:51 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From thomas.belling@nsn.com Tue Oct 6 08:14: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 2AF683A6884 for ; Tue, 6 Oct 2009 08:14:15 -0700 (PDT) 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 wKi39KDupU5R for ; Tue, 6 Oct 2009 08:14:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 92ADC3A6861 for ; Tue, 6 Oct 2009 08:13:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n96FFSFT011370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Oct 2009 17:15:28 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n96FFSww021615; Tue, 6 Oct 2009 17:15:28 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 17:15:28 +0200 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: Tue, 6 Oct 2009 17:15:27 +0200 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72296B4EC@DEMUEXC014.nsn-intra.net> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwABVAQHwAD/QSeAASAa/UA== References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com><9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de><1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> From: "Belling, Thomas (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 06 Oct 2009 15:15:28.0211 (UTC) FILETIME=[D6419A30:01CA4697] Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 06 Oct 2009 15:14:15 -0000 Hi Mary, Roland RFC 3326 states: Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. We are interested in adding the reason header to responses. This could be done in the standard where the response codes are defined. = However, most response codes of interest come from RFC 3261 and touching = this RFC is certainly not the most brilliant idea.=20 The alternative is that RFC 3326 is updated, e.g. by the draft we are = discussing. This seems the prefered way. But RFC 3326 is standard track. Is it = possible to update it with an informational RFC? Thomas =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext R.Jesske@telekom.de Sent: Tuesday, October 06, 2009 4:01 PM To: mary.barnes@nortel.com; dispatch@ietf.org Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Mary, Thank you for your clarification. So I will wait for that discussion.=20 With regard to your question I'm not really clear what the best way = would be. This behaviour would complete the behaviour of RFC 3326. And RFC 3326 = gives clear guidance what to do with the case for Reason in Responses, = so it is my understanding to have an own document. So that is my = proposal. Question is now if it should be an informal document. If this is = sufficient I'm happy with that way if not we should change the status. I = would be happy on comments on this. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Sonntag, 4. Oktober 2009 00:51 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Friday, October 02, 2009 12:51 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG 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 salvatore.loreto@ericsson.com Tue Oct 6 10:02: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 C94353A68CC for ; Tue, 6 Oct 2009 10:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.409, 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 B9AG7PbqhBqk for ; Tue, 6 Oct 2009 10:02:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 268B83A691E for ; Tue, 6 Oct 2009 10:02:44 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-61-4acb78940e47 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 51.71.02516.4987BCA4; Tue, 6 Oct 2009 19:04:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:03:57 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:03:57 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D9CD024C0; Tue, 6 Oct 2009 20:03:56 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9B11F21A1F; Tue, 6 Oct 2009 20:03:56 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A64B219D4; Tue, 6 Oct 2009 20:03:56 +0300 (EEST) Message-ID: <4ACB787B.40107@ericsson.com> Date: Tue, 06 Oct 2009 20:03:55 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Dale Worley References: <4AB75AC7.6080509@ericsson.com> <1254169375.3866.28.camel@khone.us.nortel.com> In-Reply-To: <1254169375.3866.28.camel@khone.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 06 Oct 2009 17:03:57.0158 (UTC) FILETIME=[FDE41860:01CA46A6] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Charter Proposal for 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: Tue, 06 Oct 2009 17:02:46 -0000 Hi Dale, thanks for the support and the alternative text suggested. I completely agree on the fact that the text describing the existing methods is to verbose and it needs to be shrunk, and I like the text you propose, as well as the text to sharp the area we are focusing on. I am think to reuse part of them for the new version or the charter thanks Sal Dale Worley wrote: > The general approach of the charter looks good to me, but there seem > to be too many words used to describe the existing methods (which may > or may not be solutions to the problem), and a lack of sharpness in > describing the area we are focusing on. Let me propose some > alternative text. I think that this does not change the intention of > any of the text. > > > > Disaggregated Media WG Charter > ------------------------------- > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are treated > by the far end of the session as a single media session. > > OK > > Generally, a given participant uses a single device to establish (or > participate in) a given multimedia session. Consequently, the SIP > signaling to manage the multimedia session and the actual media > streams are typically co-located in the same device. In scenarios > involving disaggregated media, a user wants to establish a single > multimedia session combining different media streams coming from > different devices under his or her control. This creates a need to > coordinate the exchange of the those media streams within the media > session. > > OK > > The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate > the different devices under his control to involve them in the call. > The different devices can communicate with one another using Mbus > messages, and then let only one device, a call control engine, to > initiate, manage and terminate call control relations to other SIP endpoints. > All the different user's devices need to support the Mbus protocol. > > The Megaco [RFC3525] protocol can be used in a disaggregated media > scenario to let one of the user's devices act as a Media Gateway Controller, > coordinating all the other devices under the user's control, which in this case > will act as Media Gateways. In this case all the different user's devices > need to support the Megaco protocol. > > The SIP protocol provides 3pcc [RFC3725] as a possible mechanism > to coordinate the exchange of media streams coming from different > devices under the control of the same user, in the case at least > one among the different devices under his control supports this > mechanism and is able to become a Controller for the other in the call. > > All the existing mechanisms only cover a subset of the interesting scenarios > that involve disaggregated media. Scenarios not covered by existing mechanisms > include the loosely-coupled one where none of the nodes can act as a controller > because it does not support the necessary functionality or because it will not > participate in the whole session. > > There are a number of protocols now used that are used to > coordinate a number of devices (e.g., Mbus, Megaco, SIP 3pcc), but > the common methods of using those protocols all require a > "master" device that must remain involved in the user's session > for its entire duration. > > The objective of the proposed working group is to develop a framework > for Disaggregated Media that include both improvements on existing > mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > like a loosely coupled mechanism that does not require the implementation > of complex logic on any of the terminals. > > The objective of the proposed working group is to develop a > framework for Disaggregated Media in "loosely-coupled" scenarios, > where no single device can remain in the session for its entire > duration and/or no single device has the necessary functionality > to coordinate all of the media streams. > > The framework may include improvements on existing mechanisms > (e.g. 3pcc), the development of one or more new mechanisms, and/or > new methods of utilizing mechanisms. > > Specifically, the proposed working group will develop the following > deliverables: > 1. A framework document describing key design considerations for Disaggregated > mediamechanism. > 2. A specification for a loosely couple mechanism. > 3. One or more specifications to improve existing mechanism to coordinate > disaggregated media. > > Specifically, the proposed working group will develop the following > deliverables: > 1. Use cases and functional requirements for the mechanism(s) > 2. A framework document describing key design considerations for > disaggregated media mechanism(s) > > 3. One or more specifications for new mechanism(s), to improve > existing mechanism(s), and/or improve their utilization(s) to > coordinate disaggregated media > > > Dale > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From salvatore.loreto@ericsson.com Tue Oct 6 10:19: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 642563A688D for ; Tue, 6 Oct 2009 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=0.394, 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 7p5s28--OmZr for ; Tue, 6 Oct 2009 10:19:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3C2E43A68CC for ; Tue, 6 Oct 2009 10:19:48 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-52-4acb7c94ece1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4C.C0.22406.49C7BCA4; Tue, 6 Oct 2009 19:21:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:19:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:19:19 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C1AAD24C0; Tue, 6 Oct 2009 20:19:19 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7DF7B21A1F; Tue, 6 Oct 2009 20:19:19 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2FF4E219CB; Tue, 6 Oct 2009 20:19:19 +0300 (EEST) Message-ID: <4ACB7C16.7030002@ericsson.com> Date: Tue, 06 Oct 2009 20:19:18 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Dale Worley References: <4AB75AC7.6080509@ericsson.com> <1254169375.3866.28.camel@khone.us.nortel.com> <1254344526.4375.29.camel@khone.us.nortel.com> In-Reply-To: <1254344526.4375.29.camel@khone.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 06 Oct 2009 17:19:19.0993 (UTC) FILETIME=[23F18A90:01CA46A9] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Charter Proposal for 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: Tue, 06 Oct 2009 17:19:49 -0000 Dale Worley wrote: > On Mon, 2009-09-28 at 16:22 -0400, Dale Worley wrote: > >> The objective of the proposed working group is to develop a framework >> for Disaggregated Media that include both improvements on existing >> mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms >> like a loosely coupled mechanism that does not require the implementation >> of complex logic on any of the terminals. >> >> The objective of the proposed working group is to develop a >> framework for Disaggregated Media in "loosely-coupled" scenarios, >> where no single device can remain in the session for its entire >> duration and/or no single device has the necessary functionality >> to coordinate all of the media streams. >> > > We could add "and/or the session is discontinuous in time" to that list > -- that was a case discussed in the past, although we may have decided > to exclude that from consideration. > Hi Dale, I have to say that the Disaggregated Media in "loosely-coupled" scenario is different from a scenario where you want to correlate a new session to one discontinued in the past. I am in principle not against the inclusion of this topic, but I remember that there has been, one year ago or more, some discussion related to this issue and several people in the wg at time suggested to not take in consideration. However I would like to hear also the opinion of other people in the wg on this particular use case. cheers Sal From Christian.Groves@nteczone.com Tue Oct 6 21:41: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 888573A6A3A for ; Tue, 6 Oct 2009 21:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 K7l+fbYIRDyC for ; Tue, 6 Oct 2009 21:41:30 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by core3.amsl.com (Postfix) with ESMTP id 8D4593A6A33 for ; Tue, 6 Oct 2009 21:41:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAHC5y0p20daE/2dsb2JhbAAI1FiEKgQ X-IronPort-AV: E=Sophos;i="4.44,517,1249223400"; d="scan'208";a="448404625" Received: from unknown (HELO [127.0.0.1]) ([118.209.214.132]) by ipmail04.adl2.internode.on.net with ESMTP; 07 Oct 2009 15:13:05 +1030 Message-ID: <4ACC1C43.2000205@nteczone.com> Date: Wed, 07 Oct 2009 15:42:43 +1100 From: Christian Groves User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4AB75AC7.6080509@ericsson.com> In-Reply-To: <4AB75AC7.6080509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Dispatch Subject: Re: [dispatch] Charter Proposal for 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: Wed, 07 Oct 2009 04:41:31 -0000 Hello Salvatore, Regarding your reference to Megaco [RFC3525] in the charter I believe a better reference would be to ITU-T H.248.1. RFC5125 obsoletes RFC3525. RFC5125 points to H.248.1 and the associated H.248.x subseries as being the up to date documents. Regards Christian Salvatore Loreto wrote: > Hi there, > > below is a charter proposal for a WG on Disaggregated Media. > > All comments, thoughts, feedbacks are very welcome! > > cheers > Sal > > > > Disaggregated Media WG Charter > ------------------------------- Disaggregated media refers to the > ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are treated > by the far end of the session as a single media session. > > Generally, a given participant uses a single device to establish (or > participate in) a given multimedia session. Consequently, the SIP > signaling to manage the multimedia session and the actual media > streams are typically co-located in the same device. In scenarios > involving disaggregated media, a user wants to establish a single > multimedia session combining different media streams coming from > different devices under his or her control. This creates a need to > coordinate the exchange of the those media streams within the media > session. > > The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate > the different devices under his control to involve them in the call. > The different devices can communicate with one another using Mbus > messages, and then let only one device, a call control engine, to > initiate, manage and terminate call control relations to other SIP > endpoints. All the different user's devices need to support the Mbus > protocol. > > The Megaco [RFC3525] protocol can be used in a disaggregated media > scenario to let one of the user's devices act as a Media Gateway > Controller, > coordinating all the other devices under the user's control, which in > this case > will act as Media Gateways. In this case all the different user's > devices need to support the Megaco protocol. > > The SIP protocol provides 3pcc [RFC3725] as a possible mechanism > to coordinate the exchange of media streams coming from different > devices under the control of the same user, in the case at least one > among the different devices under his control supports this > mechanism and is able to become a Controller for the other in the call. > > All the existing mechanisms only cover a subset of the interesting > scenarios that involve disaggregated media. Scenarios not covered by > existing mechanisms include the loosely-coupled one where none of the > nodes can act as a controller > because it does not support the necessary functionality or because it > will not > participate in the whole session. > > > The objective of the proposed working group is to develop a framework > for Disaggregated Media that include both improvements on existing > mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > like a loosely coupled mechanism that does not require the > implementation of complex logic on any of the terminals. > > > Specifically, the proposed working group will develop the following > deliverables: 1. A framework document describing key design > considerations for Disaggregated mediamechanism. > 2. A specification for a loosely couple mechanism. > 3. One or more specifications to improve existing mechanism to coordinate > disaggregated media. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ranjit@motorola.com Wed Oct 7 02:20: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 A43503A6A5B; Wed, 7 Oct 2009 02:20:36 -0700 (PDT) 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=[AWL=0.001, 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 UkrbeRMaVXfL; Wed, 7 Oct 2009 02:20:36 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id DEACA3A6A50; Wed, 7 Oct 2009 02:20:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1254907334!29710715!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30383 invoked from network); 7 Oct 2009 09:22:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Oct 2009 09:22:14 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n979MECx025712; Wed, 7 Oct 2009 02:22:14 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n979MDgl001453; Wed, 7 Oct 2009 04:22:13 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n979MCcR001440; Wed, 7 Oct 2009 04:22:13 -0500 (CDT) 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, 7 Oct 2009 17:21:49 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B09D0679D@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D draft-avasarala-dispatch-comm-div-notification Thread-Index: AcpGdWfLon/cabg0SgacWMT5H0hN0QAuRQcA From: "Avasarala Ranjit-A20990" To: X-CFilter-Loop: Reflected Cc: sip@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: [dispatch] I-D draft-avasarala-dispatch-comm-div-notification 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, 07 Oct 2009 09:20:36 -0000 Hi All We submitted an updated version of the I-D "draft-avasarala-dispatch-comm-div-notification" addressing the comments received in the dispatch and sip maillists.=20 >From the limited comments received, it seems this is moving in the right direction, The authors would very much appreciate ideas and comments on the document and suggestions on where to go from here. The URL for the draft is http://www.ietf.org/staging/draft-avasarala-dispatch-comm-div-notificati on-02.txt Regards Ranjit From L.Liess@telekom.de Wed Oct 7 04:56: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 1628E28C25E for ; Wed, 7 Oct 2009 04:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.991 X-Spam-Level: X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=0.258, 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 EQL3QUG-Uwib for ; Wed, 7 Oct 2009 04:56:38 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 89C083A6936 for ; Wed, 7 Oct 2009 04:56:37 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 07 Oct 2009 13:58:14 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 13:58:14 +0200 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, 7 Oct 2009 13:58:14 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4AC5FCBC.6090806@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal: SIP Alert-Info URN Thread-Index: AcpDYkya0k5uREP9RG6YDzq9J7YBLgD2M5eg References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> <4AC5FCBC.6090806@rogers.com> From: To: , X-OriginalArrivalTime: 07 Oct 2009 11:58:14.0732 (UTC) FILETIME=[735DC0C0:01CA4745] Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 07 Oct 2009 11:56:39 -0000 > This is getting into very familiar territory -- Megaco did=20 > this stuff. For the=20 > semantics, have a look at the definitions in ITU-T=20 > Recommendation E.182 at=20 > http://www.itu.int/rec/T-REC-E.182-199803-I/en. I think this is a good idea and also still manageable for me. I could try to add the tones defined here and national ringing tones to the next version of the draft.=20 For the national ringing tones, I would use the e.164 country code rather than the country name.=20 Thanks a lot Laura =20 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 > Sent: Friday, October 02, 2009 3:15 PM > To: Dean Willis > Cc: Liess, Laura; dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN >=20 > This is getting into very familiar territory -- Megaco did=20 > this stuff. For the=20 > semantics, have a look at the definitions in ITU-T=20 > Recommendation E.182 at=20 > http://www.itu.int/rec/T-REC-E.182-199803-I/en. >=20 > Dean Willis wrote: > > On Thu, October 1, 2009 2:45 pm, L.Liess@telekom.de wrote: > >> > >> Dean, > >> > >> I have some questions on your mail: > >> > >> > The ring-back for national standard ringers has always seemed > >> > >> > like a a > >> > good application of URN in alert-info. In other words, if you > >> call > >> > somebody in France, you might get back a 180 with an > >> > alert-info with a > >> > URN that basically means "France standard ring tone". > >> > >> In the use-cases we have now in the draft, the end devices=20 > resolves the > >> alert-URN. > >> Would this be the same for the "France standard ring=20 > tone"? The user > >> downloads a tone which > >> reminds him of France and configures it as "France=20 > standard ring tone"? > >> Or is it something else you have in mind? > >=20 > > I think it needs to be a semantic definition. For example,=20 > someone who is > > using a speech-to-text application for making a phone call=20 > should see > > something like "Ringing: With French standard ring tone" so=20 > they would > > know their call is being handled in France. > >=20 > > So, given the semantic encoding, it's up the the UA to=20 > figure out how to > > render it, possibly based on local configuration as you=20 > propose above. > > This raises the question: would it be reasonable to have=20 > two entries, one > > with a semantic value, the other with a more directive=20 > rendering that > > could be used if the UA had no idea about the semantic value? > >=20 > >=20 > >> > I vaguely remember discussion about URN-based alert-info for > >> "public > >> > alert" calls, like storm warnings and evacuation orders. > >> > > >> > >> This makes sense to me and I will ask Brian, he is working on the > >> emergency alerts stuff. > >> > >> Concerning the syntax of the urn's you propose, I see here two > >> alternatives: > >> > >> 1) Defining new categories, additional to "tone" and=20 > "service", e.g. > >> "national-ring-back-tones". The alert-URN for the "France=20 > standard ring > >> tone" could look like=20 > urn:alert:national-ring-back-tones:standard.france > >=20 > >> 2) Or just defining new alert-indications in the=20 > "tones"-category, e.g. > >> like urn:alert:tones:standard-ring-back-tone.france > >> > >> Any thoughts/preferences on this? > >=20 > > No preference here. I'm just guessing that somebody somewhere has a > > registry of these things, and it might behoove us to follow=20 > its structure, > > or at least to find the reference to it. > >=20 > >=20 > > -- > > Dean > >=20 > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 From pkyzivat@cisco.com Wed Oct 7 06:09: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 B38013A6897 for ; Wed, 7 Oct 2009 06:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 Ct-32Y6lb-o2 for ; Wed, 7 Oct 2009 06:09:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 12EEF3A67E9 for ; Wed, 7 Oct 2009 06:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1841; q=dns/txt; s=sjiport01001; t=1254921033; x=1256130633; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Charter=20Proposal=20for=20Disaggre gated=20Media|Date:=20Wed,=2007=20Oct=202009=2009:10:28 =20-0400|Message-ID:=20<4ACC9344.4080005@cisco.com>|To: =20Salvatore=20Loreto=20 |CC:=20Dale=20Worley=20,=20DISPATCH =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4ACB7C 16.7030002@ericsson.com>|References:=20<4AB75AC7.6080509@ ericsson.com>=09<1254169375.3866.28.camel@khone.us.nortel .com>=09<1254344526.4375.29.camel@khone.us.nortel.com>=20 <4ACB7C16.7030002@ericsson.com>; bh=QhKGlmZwflsCqoAKfb3NEHOWWCpp37rtV2CF2UcywHI=; b=G+SZEJA7t6qQ+kbnJIE2cUdnJlbfWiTX2P1ZgU6+tjeVJTk5yYe+jSYs I2eb/XcRS31SLQ1UKKbNYnNKU3gkErRC6r6fK5+8iWZZicIjtxaEbd9BX c/9zg6pjyPjBMZeYq3yCF0YFdt47igA338eJ034WQ0ddcBYXdVgisTcyu g=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMsvzEqrR7MV/2dsb2JhbAC9UohjAY85BoQq X-IronPort-AV: E=Sophos;i="4.44,519,1249257600"; d="scan'208";a="252153419" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Oct 2009 13:10:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n97DAWWu025290; Wed, 7 Oct 2009 06:10:32 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n97DAWOS015324; Wed, 7 Oct 2009 13:10:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 09:10:32 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 09:10:31 -0400 Message-ID: <4ACC9344.4080005@cisco.com> Date: Wed, 07 Oct 2009 09:10:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4AB75AC7.6080509@ericsson.com> <1254169375.3866.28.camel@khone.us.nortel.com> <1254344526.4375.29.camel@khone.us.nortel.com> <4ACB7C16.7030002@ericsson.com> In-Reply-To: <4ACB7C16.7030002@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2009 13:10:31.0909 (UTC) FILETIME=[8C867150:01CA474F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1841; t=1254921032; x=1255785032; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20Proposal=20for=2 0Disaggregated=20Media |Sender:=20; bh=QhKGlmZwflsCqoAKfb3NEHOWWCpp37rtV2CF2UcywHI=; b=Jn/vHVTQcZKuEoWRRc6Vt4wnoLH8sIIM0nrJgeZXJa3cKz8Y5K8pN8G4VB 70muszmHy3r3PiyUWOK5opoGAivSIsFOD7a4HqoCyNoHU6U9pBe6gH2U6FfB wOPIjXOeodJgabFDfdApi1q/67A/+mP77EqWguUG2dNIEAYf/X7Qc=; Cc: DISPATCH Subject: Re: [dispatch] Charter Proposal for 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: Wed, 07 Oct 2009 13:09:15 -0000 Salvatore Loreto wrote: > Dale Worley wrote: >> On Mon, 2009-09-28 at 16:22 -0400, Dale Worley wrote: >> >>> The objective of the proposed working group is to develop a framework >>> for Disaggregated Media that include both improvements on existing >>> mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms >>> like a loosely coupled mechanism that does not require the >>> implementation of complex logic on any of the terminals. >>> >>> The objective of the proposed working group is to develop a >>> framework for Disaggregated Media in "loosely-coupled" scenarios, >>> where no single device can remain in the session for its entire >>> duration and/or no single device has the necessary functionality >>> to coordinate all of the media streams. >>> >> >> We could add "and/or the session is discontinuous in time" to that list >> -- that was a case discussed in the past, although we may have decided >> to exclude that from consideration. I'm having difficulty understanding what is the value of this. Thanks, Paul > Hi Dale, > > I have to say that the Disaggregated Media in "loosely-coupled" scenario > is different from a scenario > where you want to correlate a new session to one discontinued in the past. > > I am in principle not against the inclusion of this topic, > but I remember that there has been, one year ago or more, some > discussion related to this issue > and several people in the wg at time suggested to not take in > consideration. > > However I would like to hear also the opinion of other people in the wg > on this particular use case. > > cheers > Sal > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From francois.audet@skypelabs.com Wed Oct 7 06:56: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 ED75D3A68C0 for ; Wed, 7 Oct 2009 06:56:35 -0700 (PDT) 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 6KQjezMRF3+k for ; Wed, 7 Oct 2009 06:56:35 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 9554A3A6996 for ; Wed, 7 Oct 2009 06:56:34 -0700 (PDT) Received: from source ([209.85.220.205]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKSsyedvhrb2e0ETGvR+mG53BFGobvV09X@postini.com; Wed, 07 Oct 2009 06:58:15 PDT Received: by fxm1 with SMTP id 1so4593216fxm.7 for ; Wed, 07 Oct 2009 06:58:13 -0700 (PDT) Received: by 10.103.81.38 with SMTP id i38mr1416899mul.92.1254923893281; Wed, 07 Oct 2009 06:58:13 -0700 (PDT) Received: from ?192.168.15.105? (adsl-75-36-209-220.dsl.pltn13.sbcglobal.net [75.36.209.220]) by mx.google.com with ESMTPS id y2sm220901mug.42.2009.10.07.06.58.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 06:58:11 -0700 (PDT) References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> <4AC5FCBC.6090806@rogers.com> <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> Message-Id: From: Francois Audet To: "" In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPod Mail (7C145) Mime-Version: 1.0 (iPod Mail 7C145) Date: Wed, 7 Oct 2009 06:58:12 -0700 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 07 Oct 2009 13:56:36 -0000 On Oct 7, 2009, at 4:58 AM, wrote: > For the national ringing tones, I would use the e.164 country code > rather than the country name. > Are the tones under national jurisdiction, or are they somehow aligned with the country codes (which don't align with the country names)? From pkyzivat@cisco.com Wed Oct 7 07:11: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 9417F28C0F1 for ; Wed, 7 Oct 2009 07:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 9IqajwN693rF for ; Wed, 7 Oct 2009 07:11:36 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 89A5328C0EB for ; Wed, 7 Oct 2009 07:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1098; q=dns/txt; s=sjiport04001; t=1254924796; x=1256134396; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Charter=20proposal:=20=20SIP=20Aler t-Info=20URN|Date:=20Wed,=2007=20Oct=202009=2010:13:11=20 -0400|Message-ID:=20<4ACCA1F7.8080504@cisco.com>|To:=20Fr ancois=20Audet=20|CC:=20""=20,=0D=0A=20=20 =20=20=20=20=20=20"dispatch@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20<40FB0FFB97588246A1BEFB05759DC8 A0036E29AD@S4DE9JSAANI.ost.t-com.de>=09=09<40FB0FFB97588246A1B EFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de>=09<58C197 5B-4034-4D04-83C2-1E48D6461B15@softarmor.com>=09<40FB0FFB 97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de >=09=09<4AC5FCBC.6090806@rogers.com>=09<40FB0FFB97588 246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de>=20< BCBE2108-6A9B-4EB7-8E5F-A174739CAB2F@skypelabs.com>; bh=oFBPqC1GSmOcvE/MUekUC/gEClzejId5oBkAfhwl7Eg=; b=FO0wRMmDJkyjCeHaTk9xNhAkmXUbutqOlux3K9Jydq9Yw/1HN7LTMB40 yUr3+eqv1PITAo0+VGzMeAylPOrmbQvs8Lcc9vHfpRkhiwi7uPT/tIdYA jwkU9WGw1EFsf4QMc/zvznilRBEjDzUJtgZ4d/C2bxHSauVZxz0sQgxFL Y=; Authentication-Results: sj-iport-4.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMs+zEqrR7O6/2dsb2JhbAC+OIhjAY87BoQq X-IronPort-AV: E=Sophos;i="4.44,519,1249257600"; d="scan'208";a="45134466" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Oct 2009 14:13:16 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n97EDChY020536; Wed, 7 Oct 2009 07:13:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n97EDCHv010450; Wed, 7 Oct 2009 14:13:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 10:13:12 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 10:13:11 -0400 Message-ID: <4ACCA1F7.8080504@cisco.com> Date: Wed, 07 Oct 2009 10:13:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Francois Audet References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> <4AC5FCBC.6090806@rogers.com> <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2009 14:13:11.0813 (UTC) FILETIME=[4D9A4350:01CA4758] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1098; t=1254924796; x=1255788796; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=3A=20=2 0SIP=20Alert-Info=20URN |Sender:=20; bh=oFBPqC1GSmOcvE/MUekUC/gEClzejId5oBkAfhwl7Eg=; b=MwjGArQnclAudHgSJxjiBo/Eu+29y3sWuNwNt/yhbPmHAJ3Qv/vavjTEFR gBhOt/7iV1uoUx2xjBwxozhDaJhrsvp0oAE9sZNP2CItga7OE36QwU5sWDy8 GpB8tejUqf; Cc: "dispatch@ietf.org" , "" Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 07 Oct 2009 14:11:37 -0000 Francois Audet wrote: > > > On Oct 7, 2009, at 4:58 AM, wrote: > >> For the national ringing tones, I would use the e.164 country code >> rather than the country name. >> > Are the tones under national jurisdiction, or are they somehow aligned > with the country codes (which don't align with the country names)? I don't know about this stuff, but I sense it is the kind of thing that some people are very sensitive about. Its quite possible that some tones are mandated legally for certain locales, and others are merely conventions followed by one or more providers. I don't see any compelling reason to organize the URNs in any particular way (e.g. by E.164) since in general somebody on the originating side will be provisioning a value to include, and they can choose whatever they thing they should. If there is no existing organization of these to follow, and one is sought, I would be inclined to choose the kinds of names used for localization rather than E.164 codes. Or else just FCFS on friendly names. Thanks, Paul From tom.taylor@rogers.com Wed Oct 7 07:55: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 C54113A6AB4 for ; Wed, 7 Oct 2009 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 Vc80eP7j8Ye8 for ; Wed, 7 Oct 2009 07:55:57 -0700 (PDT) Received: from smtp115.rog.mail.re2.yahoo.com (smtp115.rog.mail.re2.yahoo.com [68.142.225.231]) by core3.amsl.com (Postfix) with SMTP id D3E123A6AAC for ; Wed, 7 Oct 2009 07:55:56 -0700 (PDT) Received: (qmail 19479 invoked from network); 7 Oct 2009 14:57:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=4fzig7ppuK9EUxtCqTQrF1G30WKa+EIF4RB0j3ysf3A4N16PpZpVO61LoDFJjHmZGgnipyFL2Zd5KuCnM13EFZv6F1998OmhCPSXC9eqqBRU6j15md3Dp+FxST+UBv1q5zfRNEPKfWl68E4K61WGyPLhX+hmJal7bKNrhbLnGmU= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp115.rog.mail.re2.yahoo.com with SMTP; 7 Oct 2009 14:57:33 -0000 X-YMail-OSG: 1FMTg3YVM1km7Frlepcg_dwd7OkgkKcYr1D2Z_R2adlk7TyUAymZjAEoZkPpvlxlSA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACCAC5C.3020208@rogers.com> Date: Wed, 07 Oct 2009 10:57:32 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Francois Audet References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> <4AC5FCBC.6090806@rogers.com> <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , "" Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 07 Oct 2009 14:55:57 -0000 In fact, in some countries the tones used to vary by region. I don't know if that is still the case -- I'd have to research whether the ITU-T collects that information any more. Francois Audet wrote: > > > On Oct 7, 2009, at 4:58 AM, wrote: > >> For the national ringing tones, I would use the e.164 country code >> rather than the country name. >> > Are the tones under national jurisdiction, or are they somehow aligned > with the country codes (which don't align with the country names)? > > From francois.audet@skypelabs.com Wed Oct 7 08:17: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 AB38428C15F for ; Wed, 7 Oct 2009 08:17:27 -0700 (PDT) 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 bUV7Sek2BU6B for ; Wed, 7 Oct 2009 08:17:27 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 512BA28C182 for ; Wed, 7 Oct 2009 08:17:26 -0700 (PDT) Received: from source ([72.14.220.153]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKSsyxaUHqAnlcquT7OedE4VMdoT5fSyOr@postini.com; Wed, 07 Oct 2009 08:19:07 PDT Received: by fg-out-1718.google.com with SMTP id d23so1394378fga.10 for ; Wed, 07 Oct 2009 08:19:05 -0700 (PDT) Received: by 10.86.220.9 with SMTP id s9mr83484fgg.40.1254928745300; Wed, 07 Oct 2009 08:19:05 -0700 (PDT) Received: from ?10.0.1.12? (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by mx.google.com with ESMTPS id l19sm816612fgb.17.2009.10.07.08.19.00 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 08:19:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Francois AUDET In-Reply-To: <4ACCAC5C.3020208@rogers.com> Date: Wed, 7 Oct 2009 08:18:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> <4AC5FCBC.6090806@rogers.com> <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> <4ACCAC5C.3020208@rogers.com> To: Tom Taylor X-Mailer: Apple Mail (2.1076) Cc: "dispatch@ietf.org" , "" Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 07 Oct 2009 15:17:27 -0000 That's what I was thinking as well. I'm sure people who are much better qualified than I am on this topic can provide guidance. On Oct 7, 2009, at 7:57 AM, Tom Taylor wrote: > In fact, in some countries the tones used to vary by region. I don't > know if that is still the case -- I'd have to research whether the > ITU-T collects that information any more. > > > Francois Audet wrote: >> On Oct 7, 2009, at 4:58 AM, wrote: >>> For the national ringing tones, I would use the e.164 country code >>> rather than the country name. >>> >> Are the tones under national jurisdiction, or are they somehow >> aligned with the country codes (which don't align with the country >> names)? -------- Francois AUDET mailto:francois.audet@skypelabs.com tel:+1-408-260-5502 From L.Liess@telekom.de Thu Oct 8 06:33: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 04A8D3A6922 for ; Thu, 8 Oct 2009 06:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=0.245, 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 36hm56Y289YT for ; Thu, 8 Oct 2009 06:33:29 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 2F8E43A68C8 for ; Thu, 8 Oct 2009 06:33:27 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 08 Oct 2009 15:35:00 +0200 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, 8 Oct 2009 15:34:59 +0200 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, 8 Oct 2009 15:34:58 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0037D422B@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal: SIP Alert-Info URN Thread-Index: AcpHYYRRb1i3TkMxSmGse1axlnJFEgAgRH6Q References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> <40FB0FFB97588246A1BEFB05759DC8A003795384@S4DE9JSAANI.ost.t-com.de> <4AC5FCBC.6090806@rogers.com> <40FB0FFB97588246A1BEFB05759DC8A0037D3C7F@S4DE9JSAANI.ost.t-com.de> <4ACCAC5C.3020208@rogers.com> From: To: , , , X-OriginalArrivalTime: 08 Oct 2009 13:34:59.0581 (UTC) FILETIME=[21BD2AD0:01CA481C] Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 08 Oct 2009 13:33:30 -0000 > I'm sure people who are much better qualified than I am on=20 > this topic =20 > can provide guidance. >=20 This exactly the problem I see with trying to add stuff when we do not have enough expertise. But, however, let's try.=20 As Paul sugested, let's use country names.=20 We have the ITU-T international specifications for tones, E.180 and E.182. Tom, thanks a lot for the reference. There are also the ETSI specifications TR 101 041 part 1 and part 2 (from 1997), which give a list of the tones used in Europe and in the world. I will check these specifications and provide a new version of the draft to the list.=20 =20 Thanks a lot,=20 Laura > -----Original Message----- > From: Francois AUDET [mailto:francois.audet@skypelabs.com]=20 > Sent: Wednesday, October 07, 2009 5:19 PM > To: Tom Taylor > Cc: Liess, Laura; ; dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN >=20 > That's what I was thinking as well. > I'm sure people who are much better qualified than I am on=20 > this topic =20 > can provide guidance. >=20 >=20 > On Oct 7, 2009, at 7:57 AM, Tom Taylor wrote: >=20 > > In fact, in some countries the tones used to vary by=20 > region. I don't =20 > > know if that is still the case -- I'd have to research whether the =20 > > ITU-T collects that information any more. > > > > > > Francois Audet wrote: > >> On Oct 7, 2009, at 4:58 AM, wrote: > >>> For the national ringing tones, I would use the e.164 country code > >>> rather than the country name. > >>> > >> Are the tones under national jurisdiction, or are they somehow =20 > >> aligned with the country codes (which don't align with the=20 > country =20 > >> names)? >=20 > -------- > Francois AUDET > mailto:francois.audet@skypelabs.com > tel:+1-408-260-5502 >=20 >=20 >=20 >=20 >=20 From MILANPA@nortel.com Thu Oct 8 10:44: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 40BC03A683A for ; Thu, 8 Oct 2009 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Ag5DN53xsDWB for ; Thu, 8 Oct 2009 10:44:39 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 02A3A3A6827 for ; Thu, 8 Oct 2009 10:44:38 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n98HkGn14380 for ; Thu, 8 Oct 2009 17:46:16 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, 8 Oct 2009 18:46:12 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00 Thread-Index: AcpIPra79TKDFnvVR5SmHfOlYnZntwAACXbw From: "Milan Patel" To: "DISPATCH" Subject: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-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, 08 Oct 2009 17:44:40 -0000 Hi, A new version of the Internet Draft for the Calling Party's Category and Originating Line Identity URI Parameters is now available.=20 http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt This is based on Rohan Mahy's draft-mahy-iptel-cpc-06 Best regards, Milan -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 08 October 2009 18:40 To: Patel, Milan (MOP:EP10) Cc: r.jesske@telekom.de; mdolly@att.com Subject: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00=20 A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has been successfuly submitted by Milan Patel and posted to the IETF repository. Filename: draft-patel-dispatch-cpc-oli-parameter Revision: 00 Title: Uniform Resource Identifier (URI) Parameters for indicating the Calling Party's Catagory and Originating Line Identity Creation_date: 2009-10-08 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document defines two new URI parameters to describe the calling party's category and toll class of service originating line information which are parameters also used in SS7 ISUP and other telephony signalling protocols. The intended use of these URI parameters is for the "tel" URI or equivalent SIP URI representation. =20 The IETF Secretariat. From jon.peterson@neustar.biz Thu Oct 8 13:44: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 78F163A6968 for ; Thu, 8 Oct 2009 13:44:44 -0700 (PDT) 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 nAoWyuk1beox for ; Thu, 8 Oct 2009 13:44:43 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id F02C03A69F8 for ; Thu, 8 Oct 2009 13:44:42 -0700 (PDT) Received: from ([192.168.128.21]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.896929; Thu, 08 Oct 2009 16:46:20 -0400 Message-ID: <4ACE4F9B.5090909@neustar.biz> Date: Thu, 08 Oct 2009 13:46:19 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Milan Patel References: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-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, 08 Oct 2009 20:44:44 -0000 In evaluating proposals to add capabilities to SIP via a tel URI, the first question we ask is, "Would this be useful in SIP requests that do NOT use telephone numbers?" If the answer is "yes," then probably the capability should be added to SIP in a way that works with and without the tel URI. (The draft is very slightly unclear about whether or not you can include this parameter in SIP URIs that do not contain embedded tel URIs but do contain non-tel-URI representations of telephone numbers - but I'm speaking here to the overall intention to couple the use of OLI/CPC information to telephone numbers exclusively.) While the draft focuses on the use case where SIP is gatewaying to ISUP, and thus where telephone numbers are likely to be used, I would be hesitant to rule out uses that do not involve telephone numbers - especially when the motivating use case given is REGISTER in an emergency context. Encapsulating the opaque numeric values of OLI into a SIP parameter also more or less restricts the use of this to entities that understand ISUP. This begs the obvious question: should there be a way in SIP (outside of gatewaying) to express these same concepts? Since you already translate the CPC values into human-readable equivalents ("operator", "payphone", "test"), is there some reason why OLI can't receive the same treatment? The only example of the semantics of OLI that you give ("oli=29" meaning "prison") indeed seems it could admit of that translation. If there is some good reason why CPC should be translated and OLI should be encapsulated, the draft should explicitly motivate it. By the by, since the Acks mention that I submitted a version of this proposal prior to Rohan's, just as an historical aside I in fact split that out from the original draft-ietf-sip-privacy-04 by Flemming and Bill Marshall, which for some reason had it tacked into an appendix. The parameter proposed in that document (which can still be found via Google), the Nature of Party ("np") parameter, maps to a set of human-readable literals like "ordinary", "police", "payphone", "emergency", and so on. The document then proposes a mapping to the ANI II digits; one could just as easily be provided for OLI or CPC in the ISUP variants of interest. The example given in that appendix shows this being used in a URI that doesn't contain a telephone number. In any event, if you want to have a pedigree of the idea in your Acks, you shouldn't leave out that document. Jon Peterson NeuStar, Inc. Milan Patel wrote: > Hi, > > A new version of the Internet Draft for the Calling Party's Category and > Originating Line Identity URI Parameters is now available. > http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt > > This is based on Rohan Mahy's draft-mahy-iptel-cpc-06 > > Best regards, > Milan > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 08 October 2009 18:40 > To: Patel, Milan (MOP:EP10) > Cc: r.jesske@telekom.de; mdolly@att.com > Subject: New Version Notification for > draft-patel-dispatch-cpc-oli-parameter-00 > > > A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has > been successfuly submitted by Milan Patel and posted to the IETF > repository. > > Filename: draft-patel-dispatch-cpc-oli-parameter > Revision: 00 > Title: Uniform Resource Identifier (URI) Parameters for > indicating the Calling Party's Catagory and Originating Line Identity > Creation_date: 2009-10-08 > WG ID: Independent Submission > Number_of_pages: 10 > > Abstract: > This document defines two new URI parameters to describe the calling > party's category and toll class of service originating line > information which are parameters also used in SS7 ISUP and other > telephony signalling protocols. The intended use of these URI > parameters is for the "tel" URI or equivalent SIP URI representation. > > > > > The IETF Secretariat. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From MILANPA@nortel.com Fri Oct 9 06:08: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 50BDD28C143 for ; Fri, 9 Oct 2009 06:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 hTdUBCmw6Xni for ; Fri, 9 Oct 2009 06:08:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 09D9328C0FD for ; Fri, 9 Oct 2009 06:08:15 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n99D9sG03101; Fri, 9 Oct 2009 13:09:55 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, 9 Oct 2009 14:09:35 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E900AFC4335@zharhxm1.corp.nortel.com> In-Reply-To: <4ACE4F9B.5090909@neustar.biz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00 Thread-Index: AcpIWG2LEh9C79w1SGmcT5Wo0ZWxJwAiByFg References: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com> <4ACE4F9B.5090909@neustar.biz> From: "Milan Patel" To: "Jon Peterson" Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-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: Fri, 09 Oct 2009 13:08:17 -0000 Hi Jon, Thanks for your initial evaluation for the draft. Your points make sense and I'll discuss them with the co-authors prior to revising the document. Indeed, I need to reconsider use of the oli and cpc for SIP URIs that do not use telephone numbers. I think use cases beyond gateway scenarios interworking SIP and ISUP would be useful to document if indeed it is valuable to use the cpc and oli in SIP URIs that do not include telephone numbers. Using the Bellcore text terms of the OLI values was my initial intention, but the use of the 2 digit code seemed clean and less restrictive. Of course I could have extended this to the CPC and used the 8 bit binary values assigned to CPC and OLI. I'll reconsider how the CPC and OLI are represented as URI parameters based on your comments.=20 Regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 -----Original Message----- From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 Sent: 08 October 2009 21:46 To: Patel, Milan (MOP:EP10) Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00 In evaluating proposals to add capabilities to SIP via a tel URI, the=20 first question we ask is, "Would this be useful in SIP requests that do=20 NOT use telephone numbers?" If the answer is "yes," then probably the=20 capability should be added to SIP in a way that works with and without=20 the tel URI. (The draft is very slightly unclear about whether or not=20 you can include this parameter in SIP URIs that do not contain embedded=20 tel URIs but do contain non-tel-URI representations of telephone numbers - but I'm speaking here to the overall intention to couple the use of=20 OLI/CPC information to telephone numbers exclusively.) While the draft focuses on the use case where SIP is gatewaying to ISUP, and thus where telephone numbers are likely to be used, I would be=20 hesitant to rule out uses that do not involve telephone numbers -=20 especially when the motivating use case given is REGISTER in an=20 emergency context. Encapsulating the opaque numeric values of OLI into a SIP parameter also more or less restricts the use of this to entities=20 that understand ISUP. This begs the obvious question: should there be a=20 way in SIP (outside of gatewaying) to express these same concepts?=20 Since you already translate the CPC values into human-readable=20 equivalents ("operator", "payphone", "test"), is there some reason why=20 OLI can't receive the same treatment? The only example of the semantics=20 of OLI that you give ("oli=3D29" meaning "prison") indeed seems it could = admit of that translation. If there is some good reason why CPC should=20 be translated and OLI should be encapsulated, the draft should=20 explicitly motivate it. By the by, since the Acks mention that I submitted a version of this=20 proposal prior to Rohan's, just as an historical aside I in fact split=20 that out from the original draft-ietf-sip-privacy-04 by Flemming and=20 Bill Marshall, which for some reason had it tacked into an appendix. The parameter proposed in that document (which can still be found via=20 Google), the Nature of Party ("np") parameter, maps to a set of=20 human-readable literals like "ordinary", "police", "payphone",=20 "emergency", and so on. The document then proposes a mapping to the ANI=20 II digits; one could just as easily be provided for OLI or CPC in the=20 ISUP variants of interest. The example given in that appendix shows this being used in a URI that doesn't contain a telephone number. In any=20 event, if you want to have a pedigree of the idea in your Acks, you=20 shouldn't leave out that document. Jon Peterson NeuStar, Inc. Milan Patel wrote: > Hi, > > A new version of the Internet Draft for the Calling Party's Category and > Originating Line Identity URI Parameters is now available.=20 > http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt > > This is based on Rohan Mahy's draft-mahy-iptel-cpc-06 > > Best regards, > Milan > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: 08 October 2009 18:40 > To: Patel, Milan (MOP:EP10) > Cc: r.jesske@telekom.de; mdolly@att.com > Subject: New Version Notification for > draft-patel-dispatch-cpc-oli-parameter-00=20 > > > A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has > been successfuly submitted by Milan Patel and posted to the IETF > repository. > > Filename: draft-patel-dispatch-cpc-oli-parameter > Revision: 00 > Title: Uniform Resource Identifier (URI) Parameters for > indicating the Calling Party's Catagory and Originating Line Identity > Creation_date: 2009-10-08 > WG ID: Independent Submission > Number_of_pages: 10 > > Abstract: > This document defines two new URI parameters to describe the calling > party's category and toll class of service originating line > information which are parameters also used in SS7 ISUP and other > telephony signalling protocols. The intended use of these URI > parameters is for the "tel" URI or equivalent SIP URI representation. > =20 > > > > The IETF Secretariat. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 From xavier.marjou@gmail.com Mon Oct 12 02:07: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 863A428C142 for ; Mon, 12 Oct 2009 02:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 71bFESRiNC-R for ; Mon, 12 Oct 2009 02:07:36 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 98D353A6934 for ; Mon, 12 Oct 2009 02:07:33 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so2079123eye.51 for ; Mon, 12 Oct 2009 02:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=iDBm1vHEiTmhqqRyZMMMTqiaI+yg3KLqa9y9jztjuBQ=; b=L72Uhk59xxRupwKXUsHC0InRB4keW35aNXGPJZiksl6mRtizFk9SxnhgPtnrBbaklx KjXdLNnIQqSgDbOeTBAPuYuNRjIfjDRPwv6zqq5Cbhy4Il+AqRVdTOeGfcNJGzHqjxrC y2Ey3ipadZwIu3uD1SlvvdYJyOTauU9Wa5Ek8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=XLL0lPc6mor3PdZyzoBwMhczqkE7wJ8rq41iMVB/9BOn203dKMUGkgnpXNm/Ex3X3t nPGk9QIGlmDNNvsL7uRAfWqarEdxD477NHe/QZOWj9GQ2IkqmOpEDy4sxr0ooYHnM/vc hTzoPhguarJLTzBF7tudP6KtmaBA53WpAhs0I= MIME-Version: 1.0 Sender: xavier.marjou@gmail.com Received: by 10.216.85.197 with SMTP id u47mr1811609wee.133.1255338450011; Mon, 12 Oct 2009 02:07:30 -0700 (PDT) Date: Mon, 12 Oct 2009 11:07:29 +0200 X-Google-Sender-Auth: 427c26e71484c372 Message-ID: <458913680910120207s4f06ddd6tbbccb6d11531c269@mail.gmail.com> From: Xavier Marjou To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Comments on cc-uui topic 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, 12 Oct 2009 09:07:37 -0000 Hi all, Reading the minutes of IETF75, I see that there is a proposal to form a "mini-WG" for draft-johnston-dispatch-sip-cc-uui-00.txt. My opinion is the following: - draft-johnston-sipping-cc-uui should progress as a standard track RFC. - do not create a dedicated WG for this specific topic since I believe the amount of work left to finalize the draft would not justify it. Cheers, Xavier From salvatore.loreto@ericsson.com Mon Oct 12 06:49: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 37A7E3A68E3 for ; Mon, 12 Oct 2009 06:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Ul7K0EAHcOTZ for ; Mon, 12 Oct 2009 06:49:41 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9D59A3A687D for ; Mon, 12 Oct 2009 06:49:40 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-c9-4ad333f3d702 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CA.D0.22406.3F333DA4; Mon, 12 Oct 2009 15:49:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:49:35 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:49:34 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B67792706 for ; Mon, 12 Oct 2009 16:49:34 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7B1CF21A1F for ; Mon, 12 Oct 2009 16:49:34 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 328ED219CB for ; Mon, 12 Oct 2009 16:49:34 +0300 (EEST) Message-ID: <4AD333ED.5050107@ericsson.com> Date: Mon, 12 Oct 2009 16:49:33 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: IETF Dispatch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 12 Oct 2009 13:49:34.0917 (UTC) FILETIME=[D521D750:01CA4B42] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] new draft: Updates to Referred-By header 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, 12 Oct 2009 13:49:42 -0000 Hi there, I have just submitted to Dispatch the "Updates to Referred-By in the Session Initiation Protocol (SIP)", draft-loreto-dispatch-3892bis-00. until it will appear on the Dispatch web page you can check from here: http://www.sloreto.com/tmp/draft-loreto-dispatch-3892bis-00.txt Abstract SIP Referred-By header field conveys the referrer identity of a request. This header field may be used when exploding a SIP MESSAGE or a SIP INVITE request to a pre-defined group URI and the P-Asserted-Identity header field or From header field in the exploded SIP requests needs to carry another value (e.g. the URI of a pre- defined group, or a conference focus URI). In those cases, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity or to the From header field value of the original SIP request received before exploding, so as to convey to the receiver the identity of the original inviting sender. RFC 3892 restricts the value of the header to only one SIP URI. However the P-Asserted-Identity header field currently allows two URI values and may be expanded in the future to carry more than two values as described in draft-ietf-sipping-update-pai-09. This document extends the Referred-By definition to support more than one value as well. the draft was presented as draft-loreto-sipping-3892bis-01 during IETF 74 in SF, and the main comment/suggestion we got was to highlight through some use cases the importance for a receiver to get all the identities expressions and what a receiver does with multiple identity expression. To address this point we have insert the following use cases: The TEL URI in the Referred-By is needed in specific cases: o When the message is interworked to a legacy service that does not support the SIP URI and a reply address is needed in that legacy service format. For instance if an Instant Message is sent through an interworking function to an SMS user then the sender's TEL URI can be translated into an MSISDN in the interworking function and sent as the sender address in the SMS message. The SMS user is then able to use this address to send replies to the sender. Because it is not possible to predict ahead of time if the message will be interworked or not, there is a need to have always both the SIP URI and the TEL URI o Usually clients, in order to be able to display the name or identity of the calling party, need the TEL URI. In fact most of the addresses stored in the client's contact list are based on phone numbers. So the client uses the TEL URI to find the person's name in the contact list and displays the name along with the TEL URI. Comments and suggestions are very welcome. cheers Sal From mary.barnes@nortel.com Mon Oct 12 07:57: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 BBF3C28C1D2 for ; Mon, 12 Oct 2009 07:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 LpNko2rYr5Zy for ; Mon, 12 Oct 2009 07:57:30 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A31EC3A69CC for ; Mon, 12 Oct 2009 07:57:30 -0700 (PDT) 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 n9CEvPF17272; Mon, 12 Oct 2009 14:57:25 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: Mon, 12 Oct 2009 09:57:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF207AF8BA@zrc2hxm0.corp.nortel.com> In-Reply-To: <458913680910120207s4f06ddd6tbbccb6d11531c269@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on cc-uui topic Thread-Index: AcpLG3SFACwZ91V4SjeWU+uHkUyNrAALmGgQ References: <458913680910120207s4f06ddd6tbbccb6d11531c269@mail.gmail.com> From: "Mary Barnes" To: "Xavier Marjou" , Subject: Re: [dispatch] Comments on cc-uui topic 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, 12 Oct 2009 14:57:31 -0000 Hi Xavier, Unfortunately, there are NO chartered items for RFCs in the DISPATCH WG under the new model documented in RFC3427bis. If a work item fits under the charter of an existing WG or an update to the charter of an existing WG is reasonable given the nature of the topic, then no new WG is required. However, for items that do not fit within an existing WG, the choices are to either progress as an individual AD sponsored document or to establish a "mini-WG" to complete the work. =20 The idea behind the "mini-WG"s is that the milestones/deliverables are quite clear from the beginning and in many cases there would be just one or two deliverables, with the milestones established to complete the work fairly quickly. If the milestones are not completed in a timely manner, then a WG may be closed. The advantage of this approach, versus the past approach of pushing many standards track documents into SIP and keeping many informational documents spanning a broad range of topics in SIPPING, is that these mini-WGs are very focused, which is the true intent of IETF working groups. With this model, there is far less potential for documents to languish. While it might seem this approach adds additional overhead, the overhead in establishing a new WG is fairly low and the burden of such is on the ADs ;) This also allows the ADs to pull additional folks into leadership positions since these smaller WGs are far more manageable and far less demanding timewise. This model also allows the ADs to spread the work amongst multiple WG chairs versus two chairs shepherding 20+ WG documents. =20 This whole approach is in response to the perceived and in some cases actual inefficiencies in completing work items in a timely manner in the old SIPPING and SIP WGs - there are many examples of items that have taken 5+ years to be published. This is a disservice to the community and the folks that spent years working on the drafts as it has resulted in RFCs that are no longer relevant to the industry. =20 Regards, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Xavier Marjou Sent: Monday, October 12, 2009 4:07 AM To: dispatch@ietf.org Subject: [dispatch] Comments on cc-uui topic Hi all, Reading the minutes of IETF75, I see that there is a proposal to form a "mini-WG" for draft-johnston-dispatch-sip-cc-uui-00.txt. My opinion is the following: - draft-johnston-sipping-cc-uui should progress as a standard track RFC. - do not create a dedicated WG for this specific topic since I believe the amount of work left to finalize the draft would not justify it. Cheers, Xavier _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Mon Oct 12 10:04: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 4673428C254 for ; Mon, 12 Oct 2009 10:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 0Jmm2LrePeuU for ; Mon, 12 Oct 2009 10:04:10 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E53BE28C236 for ; Mon, 12 Oct 2009 10:04:09 -0700 (PDT) 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 n9CH43C10631; Mon, 12 Oct 2009 17:04:03 GMT 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: Mon, 12 Oct 2009 12:05:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF207AFBDE@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwABVAQHwAD/QSeABeddtcA== References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 12 Oct 2009 17:04:11 -0000 Hi Roland, If you are just adding clarifications to the existing RFC, then it can = be an informational document, similar to the model for the SIPPING WG = offer-answer document. If you are changing any normative statements, = then you need at least a standards track document as an "Update" to RFC = 3326. And "Update" could still be used even if normative functionality = is not changed if the clarifications are far more understandable = integrated into RFC 3326.=20 For an informational document we would still need to determine whether = it would be AD sponsored or need a mini-WG or fits within SIPCORE, for = example. =20 Regards, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Tuesday, October 06, 2009 9:01 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Mary, Thank you for your clarification. So I will wait for that discussion.=20 With regard to your question I'm not really clear what the best way = would be. This behaviour would complete the behaviour of RFC 3326. And RFC 3326 = gives clear guidance what to do with the case for Reason in Responses, = so it is my understanding to have an own document. So that is my = proposal. Question is now if it should be an informal document. If this is = sufficient I'm happy with that way if not we should change the status. I = would be happy on comments on this. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Sonntag, 4. Oktober 2009 00:51 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Friday, October 02, 2009 12:51 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dworley@nortel.com Mon Oct 12 14:33: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 EBA963A688C for ; Mon, 12 Oct 2009 14:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 BOE5TkLqIrBg for ; Mon, 12 Oct 2009 14:33:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 70F183A67D7 for ; Mon, 12 Oct 2009 14:33:26 -0700 (PDT) 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 n9CLXMm20970; Mon, 12 Oct 2009 21:33:22 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 17:33:07 -0400 From: "Dale Worley" To: Salvatore Loreto In-Reply-To: <4AD333ED.5050107@ericsson.com> References: <4AD333ED.5050107@ericsson.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 12 Oct 2009 17:33:06 -0400 Message-Id: <1255383186.21215.54.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: 12 Oct 2009 21:33:07.0282 (UTC) FILETIME=[9697F320:01CA4B83] Cc: IETF Dispatch Subject: Re: [dispatch] new draft: Updates to Referred-By header 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, 12 Oct 2009 21:33:29 -0000 On Mon, 2009-10-12 at 16:49 +0300, Salvatore Loreto wrote: > Abstract > > SIP Referred-By header field conveys the referrer identity of a > request. This header field may be used when exploding a SIP MESSAGE > or a SIP INVITE request to a pre-defined group URI and the > P-Asserted-Identity header field or From header field in the exploded > SIP requests needs to carry another value (e.g. the URI of a pre- > defined group, or a conference focus URI). In those cases, the > Referred-By header field in the resulting exploded requests is set to > the P-Asserted-Identity or to the From header field value of the > original SIP request received before exploding, so as to convey to > the receiver the identity of the original inviting sender. What do you do if the original INVITE already has a Referred-By header? It seems to me that you want a new header to carry this information, as it has distinct semantics from all existing headers. I am also curious why the From header of the exploded messages would need to be different from the From header of the original message. Dale From R.Jesske@telekom.de Mon Oct 12 15:17: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 9B5073A689B for ; Mon, 12 Oct 2009 15:17:00 -0700 (PDT) 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 4ZXsYTlqG2HS for ; Mon, 12 Oct 2009 15:16:59 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id CD29A3A67EA for ; Mon, 12 Oct 2009 15:16:58 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 13 Oct 2009 00:16:53 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 00:16:52 +0200 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: Tue, 13 Oct 2009 00:17:05 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD405111FCE@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF207AFBDE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwABVAQHwAD/QSeABeddtcAAKRFDg References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF207AFBDE@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 12 Oct 2009 22:16:52.0921 (UTC) FILETIME=[B398AA90:01CA4B89] Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 12 Oct 2009 22:17:00 -0000 Hi Mary, So I would like to go with the informal approach.=20 When I started the discussion on this issue in advance to the Stockholm = meeting I've got only feedback from DISPATCH and BLISS but not from = SIPCORE. BLISS see this issue within their scope because it solves = interoperability problems with the PSTN/ISDN. DISPATCH discussed the draft which resulted in the new version. Question for me now is should I ask again on all lists who will be = responsible. Or is there an other way to go?=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Gesendet: Montag, 12. Oktober 2009 19:05 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, If you are just adding clarifications to the existing RFC, then it can = be an informational document, similar to the model for the SIPPING WG = offer-answer document. If you are changing any normative statements, = then you need at least a standards track document as an "Update" to RFC = 3326. And "Update" could still be used even if normative functionality = is not changed if the clarifications are far more understandable = integrated into RFC 3326.=20 For an informational document we would still need to determine whether = it would be AD sponsored or need a mini-WG or fits within SIPCORE, for = example. =20 Regards, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Tuesday, October 06, 2009 9:01 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Mary, Thank you for your clarification. So I will wait for that discussion.=20 With regard to your question I'm not really clear what the best way = would be. This behaviour would complete the behaviour of RFC 3326. And RFC 3326 = gives clear guidance what to do with the case for Reason in Responses, = so it is my understanding to have an own document. So that is my = proposal. Question is now if it should be an informal document. If this is = sufficient I'm happy with that way if not we should change the status. I = would be happy on comments on this. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Sonntag, 4. Oktober 2009 00:51 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Friday, October 02, 2009 12:51 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Mon Oct 12 15:48: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 7EB303A689E for ; Mon, 12 Oct 2009 15:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 H+urzQuU0ay0 for ; Mon, 12 Oct 2009 15:48:39 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 16D3A3A6866 for ; Mon, 12 Oct 2009 15:48:39 -0700 (PDT) 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 n9CMmVC24498; Mon, 12 Oct 2009 22:48: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 17:48:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF20809164@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD405111FCE@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: Aco218uRw/+yRdYvQ/arq4KyAr2raQLC3g2wAC7St9AAIQetwABVAQHwAD/QSeABeddtcAAKRFDgAAGfxYA= References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF207AFBDE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD405111FCE@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 12 Oct 2009 22:48:40 -0000 Hi Roland, This list is fine for this discussion. The needed feedback from the WG = right now is whether folks find the problem statement adequate and if = they believe that an informational document is sufficient to resolve the = requirements and address the concerns for which this document is = intended. Based on past discussions, it seemed that normative changes = to RFC 3326 might be needed to resolve some of the issues raised. For = example, this thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg00491.html Once we get feedback on the mailing list that folks agree the problem = statement and proposed work item (it seems there is sufficient interest = in general in solving the problem), the WG chairs can discuss with the = ADs the appropriate place to progress the work. Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Monday, October 12, 2009 5:17 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Mary, So I would like to go with the informal approach.=20 When I started the discussion on this issue in advance to the Stockholm = meeting I've got only feedback from DISPATCH and BLISS but not from = SIPCORE. BLISS see this issue within their scope because it solves = interoperability problems with the PSTN/ISDN. DISPATCH discussed the draft which resulted in the new version. Question for me now is should I ask again on all lists who will be = responsible. Or is there an other way to go?=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Montag, 12. Oktober 2009 19:05 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, If you are just adding clarifications to the existing RFC, then it can = be an informational document, similar to the model for the SIPPING WG = offer-answer document. If you are changing any normative statements, = then you need at least a standards track document as an "Update" to RFC = 3326. And "Update" could still be used even if normative functionality = is not changed if the clarifications are far more understandable = integrated into RFC 3326.=20 For an informational document we would still need to determine whether = it would be AD sponsored or need a mini-WG or fits within SIPCORE, for = example. =20 Regards, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Tuesday, October 06, 2009 9:01 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Mary, Thank you for your clarification. So I will wait for that discussion.=20 With regard to your question I'm not really clear what the best way = would be. This behaviour would complete the behaviour of RFC 3326. And RFC 3326 = gives clear guidance what to do with the case for Reason in Responses, = so it is my understanding to have an own document. So that is my = proposal. Question is now if it should be an informal document. If this is = sufficient I'm happy with that way if not we should change the status. I = would be happy on comments on this. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Sonntag, 4. Oktober 2009 00:51 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi Roland, Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Friday, October 02, 2009 12:51 AM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Dear all, I see that after my renewal of the draft only some comments were given. We see this as an important issue to keep interoperability between PSTN = and SIP networks. Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. The main used case is to put the Reason Header within 4xx, 5xx, 6xx and = 199 to send an specific indication either back into an other PSTN or an = Application Server that can put an announcement into the path based on = the ISUP cause. But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. Best regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Oktober 2009 15:56 An: dispatch@ietf.org Betreff: [dispatch] DISPATCH IETF-76 plans Hi all,=20 Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 We received charter proposals (problem statements/deliverables) for the = following, with the current status highlighted. =20 o Overload (received prior to Sept. 16th) - separate mailing list setup. Needs more discussion.=20 o CBUS: some good discussion on problem statement. Needs more = discussion. o Session recording: updated charter proposal based on IETF-75 feedback. Need more WG feedback. Is this ready? =20 o Disaggregated media: Good level of interest=20 o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 o Alert-info URNs: Good level of interest.=20 o NGN Reason: Some interest. Needs more discussion and scoping.=20 The above items are the current targets for IETF-76 discussions. Based = on those discussions, agenda time will be allocated, items dispatched = and adhocs scheduled as appropriate. Note, that the minimum time we = would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 As a reminder, the following are the cutoffs for drafts, so please make = sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: Oct. 19th (just over 2 weeks) * all other documents: Oct. 26th (just over 3 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. =20 We did not receive charter proposals for the following. The current = status is summarized: o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 o Identity: Document available. Need further discussion and WG feedback = to refine requirements, problem statement, scope and = deliverables/milestones.=20 o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 As a reminder, items can be dispatched without being discussed at a f2f = meeting and the most effective way to achieve this is to have problem = statements, scope of topics and any relevant documents available early = enough for the WG to provide feedback - i.e., you do not have to wait = for the pre-meeting deadlines, which are more in the way of drop dead = dates than optimal dates. =20 Please, let the chairs know if there are any concerns. Thanks, Mary Barnes DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Tue Oct 13 12:07: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 CD5A428C2A6 for ; Tue, 13 Oct 2009 12:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.197 X-Spam-Level: X-Spam-Status: No, score=-106.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, 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 OFpwTMahd3WE for ; Tue, 13 Oct 2009 12:07:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2BECE28C28A for ; Tue, 13 Oct 2009 12:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=856; q=dns/txt; s=sjiport01001; t=1255460831; x=1256670431; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Domain=20Registration=20Draft=20=20draft-kaplan-dispat ch-domain-registration|Date:=20Tue,=2013=20Oct=202009=201 3:06:54=20-0600|Message-Id:=20<22A4515E-F613-49F3-8079-11 42FB390113@cisco.com>|To:=20dispatch@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit; bh=CW8/M/bwft6QxTQMSfvPEt3FhhkQitH55bZfbxXuEX0=; b=Gd8El+FyC1cFtKt7PX/815PyzBIjsVxlCDhkpc5A7y/LZoTRX9BekTrO RMV9v1XrCOfz0kkV4I7Z3Wuf565Fq/9RH0/4ubMAVvHAn45ttKVHfCrWG 5ArSMHq1Ew3msM3+q6a7s+Y3cwLIUDKG1r0VhjocR0V95rpRUpPJmP80P k=; 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: ApoEAAps1EqrR7Ht/2dsb2JhbADBUZgkhC0E X-IronPort-AV: E=Sophos;i="4.44,552,1249257600"; d="scan'208";a="255386241" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 19:07:11 +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 n9DJ7AKv023419 for ; Tue, 13 Oct 2009 19:07:10 GMT Message-Id: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> From: Cullen Jennings To: dispatch@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org 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, 13 Oct 2009 13:06:54 -0600 X-Mailer: Apple Mail (2.936) Subject: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 13 Oct 2009 19:07:09 -0000 The SIP Forum has recently sent us the draft http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt This draft is pretty close to what several vendors are doing in some existing deployments. In my AD roll I have been trying to figure out how to progress this draft. Some people have asked me to AD sponsor it. I see the ways this draft could more forward are: 1) AD sponsor. I'm willing to do this if there is consensus in dispatch that this is a good way to move forward. 2) Use the dispatch WG to spin up a new WG to deal with this. 3) remove the options tag and go to the independent stream I expect that with both #1 and #2, the document will get roughly the same review and #1 is less work for me and the IESG. What's your thoughts on how we should move this forward? Thanks, Cullen From richard@shockey.us Tue Oct 13 12:32: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 66E2028C331 for ; Tue, 13 Oct 2009 12:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_40=-0.185, 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 HJtPMKF2g3Zx for ; Tue, 13 Oct 2009 12:31:59 -0700 (PDT) Received: from outbound-mail-319.bluehost.com (outbound-mail-319.bluehost.com [67.222.54.251]) by core3.amsl.com (Postfix) with SMTP id 779FA28C304 for ; Tue, 13 Oct 2009 12:31:59 -0700 (PDT) Received: (qmail 2143 invoked by uid 0); 13 Oct 2009 19:32:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 13 Oct 2009 19:32:01 -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=aU0WKtU7Z7vU5dTiBEW4ru4lxVi3wgm1xo4369w+kzLrDiqNNw2jYQihEKHyqZCXuJByQvFgAxAZomzQd9iHZgsgZNMnQMFtkmkPTDl5VjgjnxS6kk/eWbAEoxdOD19n; 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 1Mxn6G-0006ye-Pl; Tue, 13 Oct 2009 13:32:01 -0600 From: "Richard Shockey" To: "'Cullen Jennings'" , References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Date: Tue, 13 Oct 2009 15:31:58 -0400 Message-ID: <025f01ca4c3b$d4cbfc00$7e63f400$@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: AcpMOF5zYBSE3bl4QxaYqb1v7NC8fwAAs61A 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] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 13 Oct 2009 19:32:00 -0000 +1 on #1 please. This is important to existing deployments in the field. The function of this draft is to enhance interoperability and remove any ambiguities about what this procedure is. IMHO it is essentially non controversial. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Tuesday, October 13, 2009 3:07 PM > To: dispatch@ietf.org > Subject: [dispatch] Domain Registration Draft draft-kaplan-dispatch- > domain-registration > > > The SIP Forum has recently sent us the draft > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration- > 00.txt > > This draft is pretty close to what several vendors are doing in some > existing deployments. In my AD roll I have been trying to figure out > how to progress this draft. Some people have asked me to AD sponsor > it. I see the ways this draft could more forward are: > > 1) AD sponsor. I'm willing to do this if there is consensus in > dispatch that this is a good way to move forward. > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > 3) remove the options tag and go to the independent stream > > I expect that with both #1 and #2, the document will get roughly the > same review and #1 is less work for me and the IESG. What's your > thoughts on how we should move this forward? > > Thanks, Cullen > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From spencer@wonderhamster.org Tue Oct 13 12:37: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 653443A68C9 for ; Tue, 13 Oct 2009 12:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.358, 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 ji3m08FLKvBd for ; Tue, 13 Oct 2009 12:37:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 5A9BE28C29C for ; Tue, 13 Oct 2009 12:37:49 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lhgpl-1MT9HU31eL-00mPrW; Tue, 13 Oct 2009 15:37:48 -0400 Message-ID: <2C04BEDCB9FB4EA89ABD7FED078BBB95@china.huawei.com> From: "Spencer Dawkins" To: "Cullen Jennings" References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Date: Tue, 13 Oct 2009 14:37:42 -0500 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: V01U2FsdGVkX193rF499D4B3NdGu4aMh86czUc+Ikf0tYyimwt /RgCglVD9cmuREXyGVblqsnTyhhKlH1woQnvj8SZKPW5rTGsCH E+A1OH9YpqN/roP0vtbxdHjAsGlYkyTaSd9FUstC8w= Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draftdraft-kaplan-dispatch-domain-registration 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, 13 Oct 2009 19:37:51 -0000 Hi, Cullen, Well, obviously, I hope that "AD sponsored" is the right answer - we're hoping that this is a very minor amount of work, but it's not something that seems appropriate to specify in a SIP Forum specification, so it needs to be reviewed in the IETF. "Removing the option tag" - my understanding here is that the reason for using a SIP option tag is so that the decision to perform domain registration is part of normal SIP capability exchange, and that if we don't use a SIP option tag, we're going to end up with some SIP header field that advertises a capability and confirms whether or not it was used - so it should have been a SIP option tag in the first place. Other thoughts? Spencer > The SIP Forum has recently sent us the draft > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > This draft is pretty close to what several vendors are doing in some > existing deployments. In my AD roll I have been trying to figure out how > to progress this draft. Some people have asked me to AD sponsor it. I see > the ways this draft could more forward are: > > 1) AD sponsor. I'm willing to do this if there is consensus in dispatch > that this is a good way to move forward. > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > 3) remove the options tag and go to the independent stream > > I expect that with both #1 and #2, the document will get roughly the same > review and #1 is less work for me and the IESG. What's your thoughts on > how we should move this forward? > > Thanks, Cullen From john.elwell@siemens-enterprise.com Wed Oct 14 00:13: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 9DB553A696E for ; Wed, 14 Oct 2009 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_REGSTR=2.3, 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 qWtkxo6Hqrsk for ; Wed, 14 Oct 2009 00:13:41 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 81D783A6863 for ; Wed, 14 Oct 2009 00:13:41 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9E7DYwL028547; Wed, 14 Oct 2009 09:13:34 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9E7DYLK024704; Wed, 14 Oct 2009 09:13:34 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Wed, 14 Oct 2009 09:13:33 +0200 From: "Elwell, John" To: Cullen Jennings , "dispatch@ietf.org" Date: Wed, 14 Oct 2009 09:13:32 +0200 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpMOGArxJHIIapCSA+eM2jYHBsJsQAZPALg Message-ID: <7402509E63C5A145A6095D46C179A5B71477D79C@DEMCHP99E35MSX.ww902.siemens.net> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 14 Oct 2009 07:13:42 -0000 I would very much like to see this draft progress quickly, and if #1 is the= best way to do this, then let's do it. Concerning the option tag, normally a SIP service provider would be provisi= oned to support a SIP-PBX, so it would know from provisioning whether a REG= ISTER request is for domain registration or normal registration. However, w= e all know that mistakes in provisioning are often made, and the option tag= provides some protection against this. So my preference would be to procee= d with the option tag. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 13 October 2009 20:07 > To: dispatch@ietf.org > Subject: [dispatch] Domain Registration Draft=20 > draft-kaplan-dispatch-domain-registration >=20 >=20 > The SIP Forum has recently sent us the draft >=20 > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registrati > on-00.txt >=20 > This draft is pretty close to what several vendors are doing in some =20 > existing deployments. In my AD roll I have been trying to figure out =20 > how to progress this draft. Some people have asked me to AD sponsor =20 > it. I see the ways this draft could more forward are: >=20 > 1) AD sponsor. I'm willing to do this if there is consensus in =20 > dispatch that this is a good way to move forward. >=20 > 2) Use the dispatch WG to spin up a new WG to deal with this. >=20 > 3) remove the options tag and go to the independent stream >=20 > I expect that with both #1 and #2, the document will get roughly the =20 > same review and #1 is less work for me and the IESG. What's your =20 > thoughts on how we should move this forward? >=20 > Thanks, Cullen >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From victor.pascual.avila@gmail.com Wed Oct 14 02:58: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 CB02E3A6823 for ; Wed, 14 Oct 2009 02:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 s0jjcm4iGx8f for ; Wed, 14 Oct 2009 02:58:04 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 70E8228C16D for ; Wed, 14 Oct 2009 02:58:04 -0700 (PDT) Received: by ewy4 with SMTP id 4so4243199ewy.37 for ; Wed, 14 Oct 2009 02:58:03 -0700 (PDT) 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=V1acHbnKmK/es2ia5kh9777aPaPt3Y/GsJt2a729GX8=; b=C5Pvru/zKF45KcL2j+2Yn3ne2khRa8/ZJoe+/wz7ztTI66Cw8sDFwmKHzfDTUnQe8k nvQA+zN2B8r9BCc2HeXWIKnH22lvzKu7fPRo1rNuFu5UPaGAn70/Mmhr+VYuQSV2AQXg m8Ejm1Iarz7oF1axK1z39alHq6N4Ewt9EtXNc= 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=F7Ce6+0Q1dGjvRXp3U+o9W4HG9rwY18q5AAA7PuJOHaHG/lOClpySjw11IDzCe92zN +hI17iDxllbmR59voy7IiSPaXXsSSlPCL3ZHDE/+TeWVWBsZrWjOr84o7N7FKZOfzgoa nPbftXIEYIgF8l54HjbkptvGZzb7w4cIffbfg= MIME-Version: 1.0 Received: by 10.216.90.7 with SMTP id d7mr2787820wef.81.1255514283272; Wed, 14 Oct 2009 02:58:03 -0700 (PDT) In-Reply-To: <7402509E63C5A145A6095D46C179A5B71006480F@DEMCHP99E35MSX.ww902.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B71006480F@DEMCHP99E35MSX.ww902.siemens.net> Date: Wed, 14 Oct 2009 11:58:03 +0200 Message-ID: <618e24240910140258r4c01046fo4d1513d106ca998c@mail.gmail.com> From: Victor Pascual Avila To: DISPATCH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 14 Oct 2009 09:58:05 -0000 Hi, On Thu, Oct 1, 2009 at 9:34 AM, Elwell, John wrote: > Cullen, > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 30 September 2009 23:58 >> To: Elwell, John >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted >> >> >> John, >> >> I think this is going the right direction, but few comments. >> >> Req 5 is too vague to be of any use. If this was replaced with >> something like "The solution must allow for media steering", that >> would make sense to me > [JRE] There is also a note that says "the precise identification of eleme= nts of a SIP message that must be allowed to change is for further study, b= ut is expected to include at least those parts of SDP that are changed in o= rder to accomplish media steering." > However, I think we can delete the note and change the requirement to say= : > "The solution MUST work when a call traverses multiple domains, including= cases where domains perform media steering." > If folks consider there are other aspects of traversing intermediate doma= ins that need to be accommodated, they should identify them and get them ex= plicitly put into the requirement. > >> >> On Req 4 - I don't think it is just the sink/source of the media. It >> seems that just about anything that is meant to be end to end >> you want >> bound to the identity. Imagine an page mode IM. In that case the >> "media" is the message and you want that bound to the caller id. > [JRE] This document focuses on caller identification (see abstract), as d= istinct from sender identification (see 4th/5th paragraphs of Intro), becau= se that is where SIP Identity suffers deployment difficulties. Caller ident= ification does need to be linked to sensitive end-to-end information sent b= y the caller during a call, even if it is sent in SIP messages rather than = as media, and to this end I plan to add: > "REQx - It MUST be possible to bind sensitive end-to-end information sent= by the calling UA in call-related SIP messages to an asserted caller ident= ification." > (and of course existing REQ6 covers the corresponding connected identific= ation case). > > This leaves call-unrelated messages (e.g., for page mode IM), and this is= n't really addressed by the I-D at all. I will add to the start of the Requ= irements section the following statement: > "These requirements are not intended to replace any existing sender ident= ification requirements for SIP messages outside the context of a call (e.g.= , using the MESSAGE method)." > > When I spoke to you privately recently, you indicated that you would like= to see the requirements expressed at a higher level, e.g., in terms of con= fidentiality, integrity protection, etc.. To address this, I was planning t= o insert three new requirements in front of the existing requirements, alon= g the lines of: > " =C2=A0 =C2=A0REQ1 - It MUST be possible to ensure that sensitive inf= ormation sent and received during a call cannot be eavesdropped by a third = party (confidentiality) and assert such a property to a caller or called us= er. > =C2=A0 =C2=A0REQ2 - It MUST be possible to ensure that information sen= t and received during a call is not inserted, modified or deleted by a thir= d party (integrity) and assert such a property to a caller or called user.<= /t> > =C2=A0 =C2=A0REQ3 - It MUST be possible to provide a called user with = verified information identifying the party to which information is sent and= from which information is received during a call (authenticated caller ide= ntification)." > > If you still have such a concern, would the above additional requirements= go some way towards satisfying it? Following are the resulting requirements (included in -01 [1]) for secure caller identification (PSTN interworking and 3PCC are not included): REQ1 - It MUST be possible to ensure that sensitive information sent and received during a call cannot be eavesdropped by a third party (confidentiality) and assert such a property to a caller or called user. REQ2 - It MUST be possible to ensure that information sent and received during a call is not inserted, modified or deleted by a third party (integrity) and assert such a property to a caller or called user. REQ3 - It MUST be possible to provide a called user with verified information identifying the party to which information is sent and from which information is received during a call (authenticated caller identification). REQ4 - It MUST be possible for a called user to receive caller identification that includes the calling user's domain and the calling user's name or telephone number within that domain. REQ5 - It MUST be possible for a called UA to receive an assertion from the calling user's domain that the call originates in that domain and that caller identification is correct, based on that domain having authenticated the calling UA. REQ6 - It MUST be possible for a called UA to verify such an assertion based on a trust anchor, such as a CA certificate. REQ7 - It MUST be possible to bind the source and sink of secure media (e.g., using SRTP or TLS) to an asserted caller identification. REQ8 - It MUST be possible to bind sensitive end-to-end information sent by the calling UA in call-related SIP messages to an asserted caller identification. REQ9 - The solution MUST work when a call traverses multiple domains, including cases where domains perform media steering. REQ10 - It MUST be possible for a calling user to receive connected user identification meeting corresponding requirements to those above for caller identification. REQ11 - The resulting mechanisms MUST be backward compatible with [RFC3261]= . Comments are appreciated. [1] http://tools.ietf.org/html/draft-elwell-dispatch-identity-reqs-01 Cheers, --=20 Victor Pascual =C3=81vila From HKaplan@acmepacket.com Wed Oct 14 10:41: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 3E39D28C1B7 for ; Wed, 14 Oct 2009 10:41:54 -0700 (PDT) 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 Kv2S1R0y2GYB for ; Wed, 14 Oct 2009 10:41:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F126A28C1B6 for ; Wed, 14 Oct 2009 10:41:52 -0700 (PDT) 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, 14 Oct 2009 13:41:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 14 Oct 2009 13:41:54 -0400 From: Hadriel Kaplan To: Spencer Dawkins , Cullen Jennings Date: Wed, 14 Oct 2009 13:41:52 -0400 Thread-Topic: [dispatch] Domain Registration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpMPLILEkQ6BwtDT1K/4YuJHpN3EwAuNFeA Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <2C04BEDCB9FB4EA89ABD7FED078BBB95@china.huawei.com> In-Reply-To: <2C04BEDCB9FB4EA89ABD7FED078BBB95@china.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draftdraft-kaplan-dispatch-domain-registration 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, 14 Oct 2009 17:41:54 -0000 I'm for Option 1 (AD sponsor it) as well. :) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Tuesday, October 13, 2009 3:38 PM > To: Cullen Jennings > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Domain Registration Draftdraft-kaplan-dispatch- > domain-registration >=20 > Hi, Cullen, >=20 > Well, obviously, I hope that "AD sponsored" is the right answer - we're > hoping that this is a very minor amount of work, but it's not something > that > seems appropriate to specify in a SIP Forum specification, so it needs to > be > reviewed in the IETF. >=20 > "Removing the option tag" - my understanding here is that the reason for > using a SIP option tag is so that the decision to perform domain > registration is part of normal SIP capability exchange, and that if we > don't > use a SIP option tag, we're going to end up with some SIP header field > that > advertises a capability and confirms whether or not it was used - so it > should have been a SIP option tag in the first place. >=20 > Other thoughts? >=20 > Spencer >=20 > > The SIP Forum has recently sent us the draft > > > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > > > This draft is pretty close to what several vendors are doing in some > > existing deployments. In my AD roll I have been trying to figure out > how > > to progress this draft. Some people have asked me to AD sponsor it. I > see > > the ways this draft could more forward are: > > > > 1) AD sponsor. I'm willing to do this if there is consensus in dispatc= h > > that this is a good way to move forward. > > > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > > > 3) remove the options tag and go to the independent stream > > > > I expect that with both #1 and #2, the document will get roughly the > same > > review and #1 is less work for me and the IESG. What's your thoughts o= n > > how we should move this forward? > > > > Thanks, Cullen >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Wed Oct 14 12:36: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 58BBA3A687C for ; Wed, 14 Oct 2009 12:36:11 -0700 (PDT) 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 yoGgr6P9BpD8 for ; Wed, 14 Oct 2009 12:36:10 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7D58D3A657C for ; Wed, 14 Oct 2009 12:36:10 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9EJaAnN011594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Oct 2009 14:36:11 -0500 Message-ID: <4AD62824.4030704@softarmor.com> Date: Wed, 14 Oct 2009 14:36:04 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Cullen Jennings References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 14 Oct 2009 19:36:11 -0000 Cullen Jennings wrote: > > The SIP Forum has recently sent us the draft > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > This draft is pretty close to what several vendors are doing in some > existing deployments. In my AD roll I have been trying to figure out how > to progress this draft. Some people have asked me to AD sponsor it. I > see the ways this draft could more forward are: > > 2) Use the dispatch WG to spin up a new WG to deal with this. > I prefer option 2, given that the WG would take the requirements and not the solution mechanism from SIP Forum. This is our one chance to fix REGISTER, and at the same time fix the request-URI/parameter delivery problem. Let's not waste it on an incomplete solution. I think that we can reasonably deliver on the domain-registration requirement and at the same time solve (for devices that use the new technique) the problem of URI and parameter delivery during SIP routing. The "RUPDATE" approach I recently circulated (and that I would like to call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I should send a draft. Let's not be bashful. What we're talking about here is a replacement for the now-known-to-be-broken SIP REGISTER mechanism (and the registered-contact routing mechanism that depends on it). While not all that hard, getting it right is still beyond the scope of an AD-sponsored draft. -- dean From dean.willis@softarmor.com Wed Oct 14 12:37: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 6DEB23A65A6 for ; Wed, 14 Oct 2009 12:37:40 -0700 (PDT) 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 EtBB0OR9GJ1c for ; Wed, 14 Oct 2009 12:37:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B16003A657C for ; Wed, 14 Oct 2009 12:37:39 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9EJbcj1011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Oct 2009 14:37:40 -0500 Message-ID: <4AD6287D.4030604@softarmor.com> Date: Wed, 14 Oct 2009 14:37:33 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Shockey References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <025f01ca4c3b$d4cbfc00$7e63f400$@us> In-Reply-To: <025f01ca4c3b$d4cbfc00$7e63f400$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 14 Oct 2009 19:37:40 -0000 Richard Shockey wrote: > +1 on #1 please. > > This is important to existing deployments in the field. > > The function of this draft is to enhance interoperability and remove any > ambiguities about what this procedure is. IMHO it is essentially non > controversial. Non-controversial? It's a clever hack built on a broken mechanism. It ought to be very controversial. -- Dean From kumiko@cs.columbia.edu Wed Oct 14 15: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 AEC7F3A6922 for ; Wed, 14 Oct 2009 15:10:12 -0700 (PDT) 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, 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 oJYQAnfm8XLj for ; Wed, 14 Oct 2009 15:10:11 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 588B23A67AE for ; Wed, 14 Oct 2009 15:10:11 -0700 (PDT) Received: from dhcp4.cs.columbia.edu (dhcp4.cs.columbia.edu [128.59.19.204]) (user=ko2155 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n9EMAChU025690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Oct 2009 18:10:12 -0400 (EDT) Message-Id: <55394D27-920E-48EB-966A-E01655D91F58@cs.columbia.edu> From: Kumiko Ono To: dispatch@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 18:10:12 -0400 X-Mailer: Apple Mail (2.936) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Subject: [dispatch] I-D: Referencing Earlier Communications in SIP Requests 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, 14 Oct 2009 22:10:12 -0000 Hi, We've submitted a new I-D, "Referencing Earlier Communications in SIP Requests." You can find it at http://tools.ietf.org/html/draft-ono-earlier-comm-references-00 . Abstract: This document defines a SIP header extension that refers to earlier SIP or non-SIP communication in SIP requests. For example, this extension allows users to correlate a SIP session with earlier sessions or email exchanges. The background is described in another I-D, "Using Cross-Media Relations to Reduce False Positives during SPIT Filtering." http://tools.ietf.org/html/draft-ono-cross-media-relations-00 Your comments or questions are very welcome. Thanks, Kumiko From SBharrat@sonusnet.com Wed Oct 14 18:01: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 2A7B43A6359 for ; Wed, 14 Oct 2009 18:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_REGSTR=2.3] 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 t+zufCUtraSR for ; Wed, 14 Oct 2009 18:01:48 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 42A613A682E for ; Wed, 14 Oct 2009 18:01:47 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id n9F11jvP012200; Wed, 14 Oct 2009 21:01:45 -0400 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: Wed, 14 Oct 2009 20:59:55 -0400 Message-ID: <637C77B6763BB54ABF989B6B21D5323502982156@sonusmail05.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Domain Registration Draftdraft-kaplan-dispatch-domain-registration thread-index: AcpMOGArxJHIIapCSA+eM2jYHBsJsQAZPALgACUM0z8= References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <7402509E63C5A145A6095D46C179A5B71477D79C@DEMCHP99E35MSX.ww902.siemens.net> From: "Bharrat, Shaun" To: "Elwell, John" , "Cullen Jennings" , Subject: Re: [dispatch] Domain RegistrationDraft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 01:01:49 -0000 All: We also would like to see a timely specification and would support either #1 or #3. The solution at hand is essentially what we see in the wild and though not the complete rework of register that some hope for, it is a workable solution. Cheers, Shaun -----Original Message----- From: dispatch-bounces@ietf.org on behalf of Elwell, John Sent: Wed 10/14/2009 3:13 AM To: Cullen Jennings; dispatch@ietf.org Subject: Re: [dispatch] Domain RegistrationDraft = draft-kaplan-dispatch-domain-registration =20 I would very much like to see this draft progress quickly, and if #1 is = the best way to do this, then let's do it. Concerning the option tag, normally a SIP service provider would be = provisioned to support a SIP-PBX, so it would know from provisioning = whether a REGISTER request is for domain registration or normal = registration. However, we all know that mistakes in provisioning are = often made, and the option tag provides some protection against this. So = my preference would be to proceed with the option tag. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 13 October 2009 20:07 > To: dispatch@ietf.org > Subject: [dispatch] Domain Registration Draft=20 > draft-kaplan-dispatch-domain-registration >=20 >=20 > The SIP Forum has recently sent us the draft >=20 > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registrati > on-00.txt >=20 > This draft is pretty close to what several vendors are doing in some =20 > existing deployments. In my AD roll I have been trying to figure out =20 > how to progress this draft. Some people have asked me to AD sponsor =20 > it. I see the ways this draft could more forward are: >=20 > 1) AD sponsor. I'm willing to do this if there is consensus in =20 > dispatch that this is a good way to move forward. >=20 > 2) Use the dispatch WG to spin up a new WG to deal with this. >=20 > 3) remove the options tag and go to the independent stream >=20 > I expect that with both #1 and #2, the document will get roughly the =20 > same review and #1 is less work for me and the IESG. What's your =20 > thoughts on how we should move this forward? >=20 > Thanks, Cullen >=20 >=20 >=20 > _______________________________________________ > 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 From scott.lawrence@nortel.com Wed Oct 14 20: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 ED7E53A68A3 for ; Wed, 14 Oct 2009 20:01:52 -0700 (PDT) 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 3jtNSPDJ14zG for ; Wed, 14 Oct 2009 20:01:51 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6EC503A6359 for ; Wed, 14 Oct 2009 20:01:51 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9F31kd07302; Thu, 15 Oct 2009 03:01:47 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 23:01:44 -0400 From: "Scott Lawrence" To: Dean Willis In-Reply-To: <4AD62824.4030704@softarmor.com> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 14 Oct 2009 23:01:43 -0400 Message-Id: <1255575703.7009.405.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2009 03:01:44.0566 (UTC) FILETIME=[D3D63960:01CA4D43] Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 03:01:53 -0000 On Wed, 2009-10-14 at 14:36 -0500, Dean Willis wrote: > Cullen Jennings wrote: > > > > The SIP Forum has recently sent us the draft > > > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > > > This draft is pretty close to what several vendors are doing in some > > existing deployments. In my AD roll I have been trying to figure out how > > to progress this draft. Some people have asked me to AD sponsor it. I > > see the ways this draft could more forward are: > > > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > > > I prefer option 2, given that the WG would take the requirements and not > the solution mechanism from SIP Forum. > > This is our one chance to fix REGISTER, and at the same time fix the > request-URI/parameter delivery problem. Let's not waste it on an > incomplete solution. > > I think that we can reasonably deliver on the domain-registration > requirement and at the same time solve (for devices that use the new > technique) the problem of URI and parameter delivery during SIP routing. > The "RUPDATE" approach I recently circulated (and that I would like to > call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I > should send a draft. > > Let's not be bashful. What we're talking about here is a replacement for > the now-known-to-be-broken SIP REGISTER mechanism (and the > registered-contact routing mechanism that depends on it). While not all > that hard, getting it right is still beyond the scope of an AD-sponsored > draft. REGISTER is already abused more than enough. I agree with Dean that this certainly should be controversial, and that a fast-track approval would not be appropriate. From john.elwell@siemens-enterprise.com Wed Oct 14 23:22: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 9A5FA3A68A2 for ; Wed, 14 Oct 2009 23:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_REGSTR=2.3, 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 EEQTkAVy3KsA for ; Wed, 14 Oct 2009 23:22:44 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 8A4FD3A67A6 for ; Wed, 14 Oct 2009 23:22:44 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9F6MC3F019530; Thu, 15 Oct 2009 08:22:13 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9F6MCiQ029971; Thu, 15 Oct 2009 08:22:12 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 15 Oct 2009 08:22:12 +0200 From: "Elwell, John" To: Dean Willis , Cullen Jennings Date: Thu, 15 Oct 2009 08:22:09 +0200 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNBZj9CPEF8sQUThGgHNMoLvSWMQAWgzBA Message-ID: <7402509E63C5A145A6095D46C179A5B71477D9C0@DEMCHP99E35MSX.ww902.siemens.net> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> In-Reply-To: <4AD62824.4030704@softarmor.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 06:22:45 -0000 I think one step at the time. Hadriel's draft fixes the urgent problem of d= omain registration. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 14 October 2009 20:36 > To: Cullen Jennings > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Domain Registration Draft=20 > draft-kaplan-dispatch-domain-registration >=20 > Cullen Jennings wrote: > >=20 > > The SIP Forum has recently sent us the draft > >=20 > >=20 > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registrati > on-00.txt > >=20 > > This draft is pretty close to what several vendors are doing in some > > existing deployments. In my AD roll I have been trying to=20 > figure out how > > to progress this draft. Some people have asked me to AD=20 > sponsor it. I > > see the ways this draft could more forward are: > >=20 > > 2) Use the dispatch WG to spin up a new WG to deal with this. > >=20 >=20 > I prefer option 2, given that the WG would take the=20 > requirements and not > the solution mechanism from SIP Forum. >=20 > This is our one chance to fix REGISTER, and at the same time fix the > request-URI/parameter delivery problem. Let's not waste it on an > incomplete solution. >=20 > I think that we can reasonably deliver on the domain-registration > requirement and at the same time solve (for devices that use the new > technique) the problem of URI and parameter delivery during=20 > SIP routing. > The "RUPDATE" approach I recently circulated (and that I would like to > call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I > should send a draft. >=20 > Let's not be bashful. What we're talking about here is a=20 > replacement for > the now-known-to-be-broken SIP REGISTER mechanism (and the > registered-contact routing mechanism that depends on it).=20 > While not all > that hard, getting it right is still beyond the scope of an=20 > AD-sponsored > draft. >=20 > -- > dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From ben@nostrum.com Thu Oct 15 07:49: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 9A0863A68F4 for ; Thu, 15 Oct 2009 07:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 AqsNDovCSjaP for ; Thu, 15 Oct 2009 07:49:27 -0700 (PDT) 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 87A643A67F5 for ; Thu, 15 Oct 2009 07:49:27 -0700 (PDT) Received: from [10.0.1.8] (adsl-68-94-15-159.dsl.rcsntx.swbell.net [68.94.15.159]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9FEnQof037637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Oct 2009 09:49:26 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: <1255575703.7009.405.camel@scott> Date: Thu, 15 Oct 2009 09:49:20 -0500 Content-Transfer-Encoding: 7bit Message-Id: <06C60922-D74D-4425-8EF6-73F7D5413B89@nostrum.com> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <1255575703.7009.405.camel@scott> To: Scott Lawrence X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 68.94.15.159 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 14:49:28 -0000 On Oct 14, 2009, at 10:01 PM, Scott Lawrence wrote: [...] > > REGISTER is already abused more than enough. > > I agree with Dean that this certainly should be controversial, and > that > a fast-track approval would not be appropriate. +1 From david.middleton@nsn.com Thu Oct 15 08:16: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 6085A3A69E2 for ; Thu, 15 Oct 2009 08:16:37 -0700 (PDT) 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 FUhSdLkQNzYX for ; Thu, 15 Oct 2009 08:16:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0CC9C3A6870 for ; Thu, 15 Oct 2009 08:16:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9FFGVc8019538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2009 17:16:31 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9FFGTkJ016454; Thu, 15 Oct 2009 17:16:30 +0200 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 17:16:23 +0200 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, 15 Oct 2009 10:15:23 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpMPLILEkQ6BwtDT1K/4YuJHpN3EwAuNFeAACz60zA= References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com><2C04BEDCB9FB4EA89ABD7FED078BBB95@china.huawei.com> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Hadriel Kaplan" , "Spencer Dawkins" , "Cullen Jennings" X-OriginalArrivalTime: 15 Oct 2009 15:16:23.0936 (UTC) FILETIME=[75305000:01CA4DAA] Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 15:16:37 -0000 I support Option 1 as well. The draft is moving us in the right direction and should not be delayed to cover additional concerns. David =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan Sent: Wednesday, October 14, 2009 1:42 PM To: Spencer Dawkins; Cullen Jennings Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration I'm for Option 1 (AD sponsor it) as well. :) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Tuesday, October 13, 2009 3:38 PM > To: Cullen Jennings > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Domain Registration Draftdraft-kaplan-dispatch- > domain-registration >=20 > Hi, Cullen, >=20 > Well, obviously, I hope that "AD sponsored" is the right answer - we're > hoping that this is a very minor amount of work, but it's not something > that > seems appropriate to specify in a SIP Forum specification, so it needs to > be > reviewed in the IETF. >=20 > "Removing the option tag" - my understanding here is that the reason for > using a SIP option tag is so that the decision to perform domain > registration is part of normal SIP capability exchange, and that if we > don't > use a SIP option tag, we're going to end up with some SIP header field > that > advertises a capability and confirms whether or not it was used - so it > should have been a SIP option tag in the first place. >=20 > Other thoughts? >=20 > Spencer >=20 > > The SIP Forum has recently sent us the draft > > > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > > > This draft is pretty close to what several vendors are doing in some > > existing deployments. In my AD roll I have been trying to figure out > how > > to progress this draft. Some people have asked me to AD sponsor it. I > see > > the ways this draft could more forward are: > > > > 1) AD sponsor. I'm willing to do this if there is consensus in dispatch > > that this is a good way to move forward. > > > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > > > 3) remove the options tag and go to the independent stream > > > > I expect that with both #1 and #2, the document will get roughly the > same > > review and #1 is less work for me and the IESG. What's your thoughts on > > how we should move this forward? > > > > Thanks, Cullen >=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 jamie@broadsoft.com Thu Oct 15 08:16:41 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 A4FEA3A69EA for ; Thu, 15 Oct 2009 08:16:41 -0700 (PDT) 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 sq9nWI7OWgTE for ; Thu, 15 Oct 2009 08:16:40 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id C51463A69E9 for ; Thu, 15 Oct 2009 08:16:40 -0700 (PDT) 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; Thu, 15 Oct 2009 08:16:40 -0700 From: Jamie Palmer To: "dispatch@ietf.org" Date: Thu, 15 Oct 2009 08:16:36 -0700 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNqn5P0/T00hRzQ3iB0MwvuNszig== Message-ID: <654B87EB-6CA5-42EA-B2F5-DF4A87ACA680@broadsoft.com> 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_654B87EB6CA542EAB2F5DF4A87ACA680broadsoftcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 15 Oct 2009 08:17:24 -0700 Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 15:16:41 -0000 --_000_654B87EB6CA542EAB2F5DF4A87ACA680broadsoftcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would support option #1. regards, Jamie Palmer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, October 13, 2009 3:07 PM To: dispatch@ietf.org Subject: [dispatch] Domain Registration Draft draft-kaplan-dispatch- domain-registration The SIP Forum has recently sent us the draft http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt This draft is pretty close to what several vendors are doing in some existing deployments. In my AD roll I have been trying to figure out how to progress this draft. Some people have asked me to AD sponsor it. I see the ways this draft could more forward are: 1) AD sponsor. I'm willing to do this if there is consensus in dispatch that this is a good way to move forward. 2) Use the dispatch WG to spin up a new WG to deal with this. 3) remove the options tag and go to the independent stream I expect that with both #1 and #2, the document will get roughly the same review and #1 is less work for me and the IESG. What's your thoughts on how we should move this forward? Thanks, Cullen _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_654B87EB6CA542EAB2F5DF4A87ACA680broadsoftcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would support optio= n #1.  

regards,
Jamie Palmer
=



-----Or= iginal Message-----
From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On
Be= half Of Cullen Jennings
Sent: Tue= sday, October 13, 2009 3:07 PM
To= : dispatch@ietf.org
Subject: [dispatch] Domain Registration Draft d= raft-kaplan-dispatch-
domain-regi= stration


The SIP Forum= has recently sent us the draft
<= br>
http://www.ietf.org/id/d= raft-kaplan-dispatch-domain-registration-00.txt

This draft is= pretty close to what several vendors are doing in some
existing deployments. In my AD roll I have been tryi= ng to figure out
how to progress = this draft. Some people have asked me to AD sponsor
it. I see the ways this draft could more forward are:

1) AD sponsor. I'm willing to do this if there is consensus in
dispatch that this is a good way to= move forward.

<= blockquote type=3D"cite">2) Use the dispatch WG to spin up a new WG to deal= with this.

3) remove the options tag and go to the independent s= tream

I expect that with both #1 and #2, the document will get ro= ughly the
same review and #1 is l= ess work for me and the IESG. What's your
thoughts on how we should move this forward?

Thanks, Cu= llen <RAI AD>


__________________________________= _____________
dispatch mailing li= st
dispatch@ietf.org
https://www.ietf.org= /mailman/listinfo/dispatch


= --_000_654B87EB6CA542EAB2F5DF4A87ACA680broadsoftcom_-- From HKaplan@acmepacket.com Thu Oct 15 08:23: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 65BEB3A69EB for ; Thu, 15 Oct 2009 08:23:24 -0700 (PDT) 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 EJtEDqo9Oy67 for ; Thu, 15 Oct 2009 08:23:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 610513A69E7 for ; Thu, 15 Oct 2009 08:23:23 -0700 (PDT) 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; Thu, 15 Oct 2009 11:23:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 11:23:25 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 15 Oct 2009 11:23:23 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNBaVVIsvonjy4ThW4vPuuuTn2FAAorxHA Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> In-Reply-To: <4AD62824.4030704@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 15:23:24 -0000 This is not our "one chance to fix REGISTER". This draft isn't trying to "= fix REGISTER". What's broken about REGISTER that needs a fixin'? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Wednesday, October 14, 2009 3:36 PM > To: Cullen Jennings > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch- > domain-registration >=20 > Cullen Jennings wrote: > > > > The SIP Forum has recently sent us the draft > > > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > > > This draft is pretty close to what several vendors are doing in some > > existing deployments. In my AD roll I have been trying to figure out ho= w > > to progress this draft. Some people have asked me to AD sponsor it. I > > see the ways this draft could more forward are: > > > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > >=20 > I prefer option 2, given that the WG would take the requirements and not > the solution mechanism from SIP Forum. >=20 > This is our one chance to fix REGISTER, and at the same time fix the > request-URI/parameter delivery problem. Let's not waste it on an > incomplete solution. >=20 > I think that we can reasonably deliver on the domain-registration > requirement and at the same time solve (for devices that use the new > technique) the problem of URI and parameter delivery during SIP routing. > The "RUPDATE" approach I recently circulated (and that I would like to > call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I > should send a draft. >=20 > Let's not be bashful. What we're talking about here is a replacement for > the now-known-to-be-broken SIP REGISTER mechanism (and the > registered-contact routing mechanism that depends on it). While not all > that hard, getting it right is still beyond the scope of an AD-sponsored > draft. >=20 > -- > dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jamie-list@netpalmer.com Thu Oct 15 08: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 0E74C3A69F6 for ; Thu, 15 Oct 2009 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 psOI583aVWzn for ; Thu, 15 Oct 2009 08:23:30 -0700 (PDT) Received: from webmachine101.com (webmachine101.com [203.194.209.183]) by core3.amsl.com (Postfix) with ESMTP id B31233A69F5 for ; Thu, 15 Oct 2009 08:23:29 -0700 (PDT) Received: (qmail 7455 invoked by uid 503); 15 Oct 2009 15:23:29 -0000 Received: from unknown (HELO ?192.168.110.19?) (jamie-list@99.251.252.85) by webmachine101.com with ESMTPA; 15 Oct 2009 15:23:29 -0000 From: James Palmer Content-Type: multipart/alternative; boundary=Apple-Mail-80-287612589 Date: Thu, 15 Oct 2009 11:23:23 -0400 References: <654B87EB-6CA5-42EA-B2F5-DF4A87ACA680@broadsoft.com> To: dispatch@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [dispatch] Fwd: Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 15:23:31 -0000 --Apple-Mail-80-287612589 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes I would support Cullen's option #1 regards, Jamie Palmer > >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>> On >>> Behalf Of Cullen Jennings >>> Sent: Tuesday, October 13, 2009 3:07 PM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Domain Registration Draft draft-kaplan-dispatch- >>> domain-registration >>> >>> >>> The SIP Forum has recently sent us the draft >>> >>> http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt >>> >>> This draft is pretty close to what several vendors are doing in some >>> existing deployments. In my AD roll I have been trying to figure out >>> how to progress this draft. Some people have asked me to AD sponsor >>> it. I see the ways this draft could more forward are: >>> >>> 1) AD sponsor. I'm willing to do this if there is consensus in >>> dispatch that this is a good way to move forward. >>> >>> 2) Use the dispatch WG to spin up a new WG to deal with this. >>> >>> 3) remove the options tag and go to the independent stream >>> >>> I expect that with both #1 and #2, the document will get roughly the >>> same review and #1 is less work for me and the IESG. What's your >>> thoughts on how we should move this forward? >>> >>> Thanks, Cullen >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> > --Apple-Mail-80-287612589 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


-----Original Message-----
From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] On
Behalf Of Cullen Jennings
Sent: Tuesday, October 13, 2009 3:07 = PM
To: dispatch@ietf.org
Subject: [dispatch] Domain Registration Draft = draft-kaplan-dispatch-
domain-registration


The SIP Forum = has recently sent us the draft

http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00= .txt

This draft is = pretty close to what several vendors are doing in = some
existing deployments. In = my AD roll I have been trying to figure out
how to progress this draft. Some people have asked me to = AD sponsor
it. I see the ways = this draft could more forward are:

1) AD sponsor. = I'm willing to do this if there is consensus = in
dispatch that this is a = good way to move forward.

2) Use the = dispatch WG to spin up a new WG to deal with = this.

3) remove the = options tag and go to the independent stream

I expect that = with both #1 and #2, the document will get roughly = the
same review and #1 is less = work for me and the IESG. What's your
thoughts on how we should move this = forward?

Thanks, Cullen = <RAI AD>



_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch



= --Apple-Mail-80-287612589-- From HKaplan@acmepacket.com Thu Oct 15 08:57: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 4C25428C117 for ; Thu, 15 Oct 2009 08:57:42 -0700 (PDT) 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 qX5jc7KAeV4O for ; Thu, 15 Oct 2009 08:57:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 694D928C111 for ; Thu, 15 Oct 2009 08:57:41 -0700 (PDT) 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; Thu, 15 Oct 2009 11:57:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 11:57:41 -0400 From: Hadriel Kaplan To: Scott Lawrence , Ben Campbell Date: Thu, 15 Oct 2009 11:57:39 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNQ+yHpZzhyoR1R2KbKYHzpwxdcwAa3r6g Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <1255575703.7009.405.camel@scott> In-Reply-To: <1255575703.7009.405.camel@scott> 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: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 15:57:42 -0000 Scott/Ben, Can you describe what is controversial about the draft for you personally? Is it the idea of using a REGISTER request for something other than just a = single AoR? Is it that a REGISTER updates a different logical local database on the Reg= istrar? Is it the idea of allocating an option-tag? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Scott Lawrence > Sent: Wednesday, October 14, 2009 11:02 PM >=20 > REGISTER is already abused more than enough. >=20 > I agree with Dean that this certainly should be controversial, and that > a fast-track approval would not be appropriate. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Thu Oct 15 09:11: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 BEB5328C120 for ; Thu, 15 Oct 2009 09:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_REGSTR=2.3] 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 dIMG847oyCxR for ; Thu, 15 Oct 2009 09:11:25 -0700 (PDT) Received: from outbound-mail-301.bluehost.com (outbound-mail-301.bluehost.com [67.222.53.8]) by core3.amsl.com (Postfix) with SMTP id C8B8528C11E for ; Thu, 15 Oct 2009 09:11:25 -0700 (PDT) Received: (qmail 21632 invoked by uid 0); 15 Oct 2009 16:11:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 15 Oct 2009 16:11:28 -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=nEbDkQx0dF/BS69jC8f52WWDC5HH48893Rr/KEKqI+uB/mmlUZ5le1CygVUBRdpLfD+2wtwC2n8A26TZafcm15LGmDVfVjcu0tyIAEMnn4YzJE1Om3EKa6LkEAfeT8zG; 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 1MySvI-0007Ea-Cn; Thu, 15 Oct 2009 10:11:28 -0600 From: "Richard Shockey" To: "'Elwell, John'" , "'Dean Willis'" , "'Cullen Jennings'" References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <7402509E63C5A145A6095D46C179A5B71477D9C0@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477D9C0@DEMCHP99E35MSX.ww902.siemens.net> Date: Thu, 15 Oct 2009 12:11:25 -0400 Message-ID: <015801ca4db2$260c2cd0$72248670$@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: AcpNBZj9CPEF8sQUThGgHNMoLvSWMQAWgzBAABRmlnA= 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 Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 16:11:26 -0000 John is perfectly correct here. We are trying, in a responsible manner, to fix what is clearly and widely deployed in the field right now. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, October 15, 2009 2:22 AM > To: Dean Willis; Cullen Jennings > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Domain Registration Draft draft-kaplan- > dispatch-domain-registration > > I think one step at the time. Hadriel's draft fixes the urgent problem > of domain registration. > > John > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis > > Sent: 14 October 2009 20:36 > > To: Cullen Jennings > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Domain Registration Draft > > draft-kaplan-dispatch-domain-registration > > > > Cullen Jennings wrote: > > > > > > The SIP Forum has recently sent us the draft > > > > > > > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registrati > > on-00.txt > > > > > > This draft is pretty close to what several vendors are doing in > some > > > existing deployments. In my AD roll I have been trying to > > figure out how > > > to progress this draft. Some people have asked me to AD > > sponsor it. I > > > see the ways this draft could more forward are: > > > > > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > > > > > > I prefer option 2, given that the WG would take the > > requirements and not > > the solution mechanism from SIP Forum. > > > > This is our one chance to fix REGISTER, and at the same time fix the > > request-URI/parameter delivery problem. Let's not waste it on an > > incomplete solution. > > > > I think that we can reasonably deliver on the domain-registration > > requirement and at the same time solve (for devices that use the new > > technique) the problem of URI and parameter delivery during > > SIP routing. > > The "RUPDATE" approach I recently circulated (and that I would like > to > > call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, > I > > should send a draft. > > > > Let's not be bashful. What we're talking about here is a > > replacement for > > the now-known-to-be-broken SIP REGISTER mechanism (and the > > registered-contact routing mechanism that depends on it). > > While not all > > that hard, getting it right is still beyond the scope of an > > AD-sponsored > > draft. > > > > -- > > dean > > _______________________________________________ > > 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 bernarda@microsoft.com Thu Oct 15 10:06: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 86FD728C102 for ; Thu, 15 Oct 2009 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 iKBzfl39l84O for ; Thu, 15 Oct 2009 10:06:51 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 2470C3A6893 for ; Thu, 15 Oct 2009 10:06:50 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 15 Oct 2009 10:07:02 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.639.20; Thu, 15 Oct 2009 10:06:54 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 15 Oct 2009 10:06:53 -0700 From: Bernard Aboba To: "dispatch@ietf.org" Thread-Topic: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpNueO1NChNYrzLS8aCnrQznusgMg== Date: Thu, 15 Oct 2009 17:06:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F839FBA415E97B4DBD5BA437162E0603201BEC4ATK5EX14MBXW652w_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 15 Oct 2009 10:26:54 -0700 Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 17:06:55 -0000 --_000_F839FBA415E97B4DBD5BA437162E0603201BEC4ATK5EX14MBXW652w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This draft is attempting to provide a well specified alternative to the adh= oc solutions that have been deployed so far. It builds on REGISTER as it exists today, and therefore = I don't see how it would benefit from, or be related to, attempts to fix other problems that may exi= st in REGISTER. Given this, I prefer option #1. The need for a well-specified solution is= fairly urgent, given the persistent interoperability problems that could result from the continu= ed proliferation of adhoc solutions. If people feel it is useful to take on the issues that Dean describes (pers= onally, I'm skeptical), then that problem should be taken up separately. Dean Willis said: "I prefer option 2, given that the WG would take the requirements and not the solution mechanism from SIP Forum. This is our one chance to fix REGISTER, and at the same time fix the request-URI/parameter delivery problem. Let's not waste it on an incomplete solution. I think that we can reasonably deliver on the domain-registration requirement and at the same time solve (for devices that use the new technique) the problem of URI and parameter delivery during SIP routing. The "RUPDATE" approach I recently circulated (and that I would like to call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I should send a draft. Let's not be bashful. What we're talking about here is a replacement for the now-known-to-be-broken SIP REGISTER mechanism (and the registered-contact routing mechanism that depends on it). While not all that hard, getting it right is still beyond the scope of an AD-sponsored draft." --_000_F839FBA415E97B4DBD5BA437162E0603201BEC4ATK5EX14MBXW652w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft is attempting to provide a well specified a= lternative to the adhoc solutions that have been

deployed so far.   It builds on REGISTER as = it exists today, and therefore I don’t see how it would

benefit from, or be related to, attempts to fix other problems that may exist in REGISTER. 

 

Given this, I prefer option #1.   The need f= or a well-specified solution is fairly urgent, given

the persistent interoperability problems that could re= sult from the continued proliferation

of adhoc solutions.   

 

If people feel it is useful to take on the issues that= Dean describes (personally, I’m skeptical),

then that problem should be taken up separately. =

 

Dean Willis said:

 

“I prefer option 2, given that the WG would take the requirement=
s and not

the solution mechanism from SIP Forum.

 

This is our one chance to fix REGISTER, and at the same time fix the<= /span>

request-URI/parameter delivery problem. Let's not waste it on an

incomplete solution.

 

I think that we can reasonably deliver on the domain-registration<= /span>

requirement and at the same time solve (for devices that use the new<= /p>

technique) the problem of URI and parameter delivery during SIP routing.

The "RUPDATE" approach I recently circulated (and that I would like t= o

call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I

should send a draft.

 

Let's not be bashful. What we're talking about here is a replacement for

the now-known-to-be-broken SIP REGISTER mechanism (and the

registered-contact routing mechanism that depends on it). While not all

that hard, getting it right is still beyond the scope of an AD-sponsored

draft.”

 

--_000_F839FBA415E97B4DBD5BA437162E0603201BEC4ATK5EX14MBXW652w_-- From alan@sipstation.com Thu Oct 15 10:47: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 E5D9A3A68AF for ; Thu, 15 Oct 2009 10:47:33 -0700 (PDT) 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 veHRkOtZDdOV for ; Thu, 15 Oct 2009 10:47:33 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0DF033A6816 for ; Thu, 15 Oct 2009 10:47:33 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MyUQJ-000Oxz-L1; Thu, 15 Oct 2009 17:47:35 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/a3p5xA6W35NzfYdLm8bGbrK36HwUTiVM= Message-ID: <4AD76035.4060704@sipstation.com> Date: Thu, 15 Oct 2009 12:47:33 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 17:47:34 -0000 I agree with Bernard. We tend to do good work when we have a narrow scope and well understood use cases. A scope like fixing all that is wrong with REGISTER sounds like SIP 3.0 to me rather than work that relates to domain registration. I'd encourage everyone to read the draft and think about it a bit. I actually believe this approach makes some sense and is definitely the least ugly approach to solving this problem. You could argue that we shouldn't solve this problem in SIP, but no one is forced to implement anything, and it is really, really bad for SIP interop to have all these other solutions out there, as many of us have discovered. Thanks, Alan Bernard Aboba wrote: > > This draft is attempting to provide a well specified alternative to > the adhoc solutions that have been > > deployed so far. It builds on REGISTER as it exists today, and > therefore I don’t see how it would > > benefit from, or be related to, attempts to fix other problems that > may exist in REGISTER. > > Given this, I prefer option #1. The need for a well-specified solution > is fairly urgent, given > > the persistent interoperability problems that could result from the > continued proliferation > > of adhoc solutions. > > If people feel it is useful to take on the issues that Dean describes > (personally, I’m skeptical), > > then that problem should be taken up separately. > > Dean Willis said: > > “I prefer option 2, given that the WG would take the requirements and not > > the solution mechanism from SIP Forum. > > This is our one chance to fix REGISTER, and at the same time fix the > > request-URI/parameter delivery problem. Let's not waste it on an > > incomplete solution. > > I think that we can reasonably deliver on the domain-registration > > requirement and at the same time solve (for devices that use the new > > technique) the problem of URI and parameter delivery during SIP routing. > > The "RUPDATE" approach I recently circulated (and that I would like to > > call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I > > should send a draft. > > Let's not be bashful. What we're talking about here is a replacement for > > the now-known-to-be-broken SIP REGISTER mechanism (and the > > registered-contact routing mechanism that depends on it). While not all > > that hard, getting it right is still beyond the scope of an AD-sponsored > > draft.” > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Thu Oct 15 11:07: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 4507828C165 for ; Thu, 15 Oct 2009 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.385, 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 SQr-pTjBwdX1 for ; Thu, 15 Oct 2009 11:07:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6F45C3A69AE for ; Thu, 15 Oct 2009 11:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2770; q=dns/txt; s=rtpiport01001; t=1255630035; x=1256839635; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20DomainRegistration=20Draftdraft-kap lan-dispatch-domain-registration|Date:=20Thu,=2015=20Oct =202009=2014:07:16=20-0400|Message-ID:=20<4AD764D4.504070 1@cisco.com>|To:=20Bernard=20Aboba=20|CC:=20"dispatch@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=208bit |In-Reply-To:=20 |References:=20; bh=fr5lcO8NewlI6YnDy6RJYWaBu6uv3EGobquRDNLYb6A=; b=i0YXlzLpRsGELdhlp0EEeIjrNarvqKyGiiFlrDwXiOwSpVZ4EyH41Lkz TbZ4YoJW7PfJgeEsJzgkrq2L7NQjVpGwNf76QJe/ziFCcEYeN5ACEvlNS 3gB6LaqMpQ4r/4IbeDmJgz8CQUKq1hkQZjhKR1j59oSQVv1HxFrUwJVIk A=; 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: ApoEAPkA10pAZnwM/2dsb2JhbADBYZhJgkCBcAQ X-IronPort-AV: E=Sophos;i="4.44,567,1249257600"; d="scan'208";a="63278367" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Oct 2009 18:07:14 +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 n9FI7Eai021008; Thu, 15 Oct 2009 18:07:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 14:07:14 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 14:07:13 -0400 Message-ID: <4AD764D4.5040701@cisco.com> Date: Thu, 15 Oct 2009 14:07:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Oct 2009 18:07:13.0642 (UTC) FILETIME=[527D54A0:01CA4DC2] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 18:07:13 -0000 Bernard Aboba wrote: > This draft is attempting to provide a well specified alternative to the > adhoc solutions that have been > > deployed so far. It builds on REGISTER as it exists today, and > therefore I don’t see how it would > > benefit from, or be related to, attempts to fix other problems that may > exist in REGISTER. I've been trying to sit this discussion out. I see both pros and cons. While this solution builds on REGISTER as it exists today - in that it uses the REGISTER message - it doesn't at all build on the mechanisms behind REGISTER at all. Its updating a different routing mechanism. In an ideal world the solution to the problem this addresses would be reconsidered from scratch. That is what Dean is getting at. > Given this, I prefer option #1. The need for a well-specified solution > is fairly urgent, given I guess maybe the question is how urgent this is. Aren't the people that need this already doing *something*? How likely are they to move to this more standardized variant of their existing adhoc solutions? Thanks, Paul > the persistent interoperability problems that could result from the > continued proliferation > > of adhoc solutions. > > > > If people feel it is useful to take on the issues that Dean describes > (personally, I’m skeptical), > > then that problem should be taken up separately. > > > > Dean Willis said: > > > > “I prefer option 2, given that the WG would take the requirements and not > > the solution mechanism from SIP Forum. > > > > This is our one chance to fix REGISTER, and at the same time fix the > > request-URI/parameter delivery problem. Let's not waste it on an > > incomplete solution. > > > > I think that we can reasonably deliver on the domain-registration > > requirement and at the same time solve (for devices that use the new > > technique) the problem of URI and parameter delivery during SIP routing. > > The "RUPDATE" approach I recently circulated (and that I would like to > > call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I > > should send a draft. > > > > Let's not be bashful. What we're talking about here is a replacement for > > the now-known-to-be-broken SIP REGISTER mechanism (and the > > registered-contact routing mechanism that depends on it). While not all > > that hard, getting it right is still beyond the scope of an AD-sponsored > > draft.” > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jon.peterson@neustar.biz Thu Oct 15 12:20: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 BCD813A694D for ; Thu, 15 Oct 2009 12:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 4oA2wYjdiKjZ for ; Thu, 15 Oct 2009 12:20:21 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 8FBC33A6947 for ; Thu, 15 Oct 2009 12:20:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1255634401; x=1255720801; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=ginJtAhLueShru/jiQaoO7W5c9ugHMstjLn6bdXTDGK8eAK2GgXyFzaU2yOYqmVJvwC7LJqnhYTppg MWMiguTQ== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.18739421; Thu, 15 Oct 2009 15:20:00 -0400 Received: from 192.168.128.21 ([192.168.128.21]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Oct 2009 19:19:59 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 15 Oct 2009 12:19:57 -0700 From: Jon Peterson To: Paul Kyzivat , Bernard Aboba Message-ID: Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpNzHtAe72WW4tJa0GmAvdvBbWc+g== In-Reply-To: <4AD764D4.5040701@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 19:20:22 -0000 I believe Paul is correct that whatever the urgency of the problem this draft fixes, neither the problem nor the fix has any particular relevance t= o the existing semantics of the REGISTER method. >From my reading of Section 3, I gather this is intended to work for administrative domains that don't have domain names "at all." The place where I think this actually raises serious concerns for standardization is in the beginning of Section 4.1, where it is proposed that a UA register a domain name that "may only exist for the purposes of this mechanism", in other words, a textual string that is structured enough like a domain name to work in SIP but has not actually been assigned in the global DNS through a domain registrar. Providing I don't misunderstand the mechanism here, I see no way this differs from an "alt-root" of the DNS, and it looks like it gives rise to all of the same alt-root problems (e.g. Even if a name isn't in use in the DNS when you first provision it, via this mechanism what if someone later purchases that domain name and does put it to use in the DNS, which authority do you consult then to make a routing decision?). The fourth paragraph of 4.3.2 is pretty typical of such mechanisms. Even if they have tactical value in some deployment scenarios, I do not think the IETF should standardize alt-root schemes, and historically it has made statements very much to the contrary. Domain names are inexpensive and inexhaustible, and the notion that an SMB cannot afford one is extremely dubious. This stipulation can be removed without doing great violence to the mechanism. The argument for not using RFC3263 then becomes a weaker one, though - it would be that the SMB does not want to provide its own DNS infrastructure or pony up costs for DNS hosting. Probably the strongest remaining argument is that the SMB doesn't want to expose the IP address of its SIP domain publicly. That, however, could just as well be an argument for using private DNS with RFC3263. Explaining the pros and cons of this mechanism versus private DNS in the Alternatives section is probably a worthwhile exercise. Jon Peterson NeuStar, Inc. On 10/15/09 11:07 AM, "Paul Kyzivat" wrote: >=20 >=20 > Bernard Aboba wrote: >> This draft is attempting to provide a well specified alternative to the >> adhoc solutions that have been >>=20 >> deployed so far. It builds on REGISTER as it exists today, and >> therefore I don=B9t see how it would >>=20 >> benefit from, or be related to, attempts to fix other problems that may >> exist in REGISTER. >=20 > I've been trying to sit this discussion out. I see both pros and cons. >=20 > While this solution builds on REGISTER as it exists today - in that it > uses the REGISTER message - it doesn't at all build on the mechanisms > behind REGISTER at all. Its updating a different routing mechanism. >=20 > In an ideal world the solution to the problem this addresses would be > reconsidered from scratch. That is what Dean is getting at. >=20 >> Given this, I prefer option #1. The need for a well-specified solution >> is fairly urgent, given >=20 > I guess maybe the question is how urgent this is. Aren't the people that > need this already doing *something*? How likely are they to move to this > more standardized variant of their existing adhoc solutions? >=20 > Thanks, > Paul >=20 >> the persistent interoperability problems that could result from the >> continued proliferation >>=20 >> of adhoc solutions. >>=20 >> =20 >>=20 >> If people feel it is useful to take on the issues that Dean describes >> (personally, I=B9m skeptical), >>=20 >> then that problem should be taken up separately. >>=20 >> =20 >>=20 >> Dean Willis said: >>=20 >> =20 >>=20 >> =B3I prefer option 2, given that the WG would take the requirements and no= t >>=20 >> the solution mechanism from SIP Forum. >>=20 >> =20 >>=20 >> This is our one chance to fix REGISTER, and at the same time fix the >>=20 >> request-URI/parameter delivery problem. Let's not waste it on an >>=20 >> incomplete solution. >>=20 >> =20 >>=20 >> I think that we can reasonably deliver on the domain-registration >>=20 >> requirement and at the same time solve (for devices that use the new >>=20 >> technique) the problem of URI and parameter delivery during SIP routing. >>=20 >> The "RUPDATE" approach I recently circulated (and that I would like to >>=20 >> call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I >>=20 >> should send a draft. >>=20 >> =20 >>=20 >> Let's not be bashful. What we're talking about here is a replacement for >>=20 >> the now-known-to-be-broken SIP REGISTER mechanism (and the >>=20 >> registered-contact routing mechanism that depends on it). While not all >>=20 >> that hard, getting it right is still beyond the scope of an AD-sponsored >>=20 >> draft.=B2 >>=20 >> =20 >>=20 >>=20 >> ------------------------------------------------------------------------ >>=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 ben@nostrum.com Thu Oct 15 13:18:20 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 CFEC33A67A7 for ; Thu, 15 Oct 2009 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 4YRGJGTU9cCk for ; Thu, 15 Oct 2009 13:18:20 -0700 (PDT) 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 A0DF83A6405 for ; Thu, 15 Oct 2009 13:18:18 -0700 (PDT) Received: from [10.0.1.8] (adsl-68-94-15-159.dsl.rcsntx.swbell.net [68.94.15.159]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9FKIIVo065443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Oct 2009 15:18:19 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: Date: Thu, 15 Oct 2009 15:18:13 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9DD0F9FF-6881-4E11-8C6F-48F4EF5A8625@nostrum.com> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <1255575703.7009.405.camel@scott> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 68.94.15.159 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 20:18:20 -0000 On Oct 15, 2009, at 10:57 AM, Hadriel Kaplan wrote: > > Scott/Ben, > Can you describe what is controversial about the draft for you > personally? > Is it the idea of using a REGISTER request for something other than > just a single AoR? > Is it that a REGISTER updates a different logical local database on > the Registrar? > Is it the idea of allocating an option-tag? At a high level, it is that you propose using REGISTER as to carry a very specific piece of otherwise provisionable data. This piece seems more "hard-state" rather than "soft-state" It is not obvious to me that REGISTER is the right way to do this. Additionally, I am concerned about applying _any_ new semantics to REGISTER, as I think the method is fundamentally broken. So, I think there is considerable room for discussion on the following (I'll make my own list, thank you :-) ): 1) Is SIP the right protocol for this? 2) Is REGISTER the right method for this? Maybe PUBLISH would be better? Isn't this sort of like the bulk registration mechanism that was _always_ controversial whenever it came up? 3) Are we building specific applications (i.e. a way to provision virtual domains for IP-PBXs) vs providing flexible primitives (a way to dynamically self-provision hard-state routing info) 4) Are we getting the security aspects right? Don't get me wrong--I am not saying that the draft necessarily does these things wrong--I am saying that I expect there to be a variety of opinions on the matter--thus Richard's assertion that they are "non- controversial" seems off base. If we are going to _standardize_ such a mechanism, I think it deserves the same level of discussion as other things we put through the DISPATCH process. > > -hadriel > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Scott Lawrence >> Sent: Wednesday, October 14, 2009 11:02 PM >> >> REGISTER is already abused more than enough. >> >> I agree with Dean that this certainly should be controversial, and >> that >> a fast-track approval would not be appropriate. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Thu Oct 15 13:25: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 F20343A6949 for ; Thu, 15 Oct 2009 13:25:01 -0700 (PDT) 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 F6Z04ocKoysu for ; Thu, 15 Oct 2009 13:25:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 037033A6405 for ; Thu, 15 Oct 2009 13:25:00 -0700 (PDT) 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; Thu, 15 Oct 2009 16:25:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 16:25:03 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Thu, 15 Oct 2009 16:25:01 -0400 Thread-Topic: Domain Registration: semantics of REGISTER Thread-Index: AcpN1ZLKzh/yHBzcTvqBqD9gPtU3xg== 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] Domain Registration: semantics of REGISTER 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, 15 Oct 2009 20:25:02 -0000 Two people have now commented that using a REGISTER method for the purposes= of Domain Registration changes the semantics of REGISTER. My answer to th= at is "maybe", and "so what?". The reason we'd like an options-tag is spec= ifically because this *is* an extension, and we'd like to keep it clean/sep= arate from "normal" REGISTERs. There are *some* semantics of REGISTER that *are* identical: 1) The REGISTER is providing reachability information for subsequent SIP re= quest routing purposes. 2) The REGISTER includes additional reachability detail in Path and SIP-Out= bound-related fields. 3) The duration of the information has a lifetime (i.e., expires). 4) The information in the To-URI identifies the target to be reached. 5) The REGISTER's response may include additional detail for subsequent rou= ting purposes through a Service-Route header field. But, it's also different in that: a) The reachability information pertains to a whole domain, not just one Ao= R. b) The document, as written, defines a new, separate logical table from tha= t of AoR's, which gets updated instead. c) The document, as written, defines a Route-header-based routing mechanism= using that table, instead of request-uri replacement a la 3261. At the end of the day, sure we could go write up a new event-package and us= e PUBLISH to do this thing instead (because one could argue REGISTER is jus= t a specific form of a PUBLISH for the "aor-location" package). But then w= e'd have to get SIP-outbound, Path, Service-Route, and so on for this new P= UBLISH package. And what would be the point? How would that make it more = or less interoperable? -hadriel From HKaplan@acmepacket.com Thu Oct 15 13:46: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 D001B28C18B for ; Thu, 15 Oct 2009 13:46:37 -0700 (PDT) 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 AjEmGr6G7I6V for ; Thu, 15 Oct 2009 13:46:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7494228C17C for ; Thu, 15 Oct 2009 13:46:36 -0700 (PDT) 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; Thu, 15 Oct 2009 16:46:34 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 16:46:34 -0400 From: Hadriel Kaplan To: Jon Peterson , Paul Kyzivat , Bernard Aboba Date: Thu, 15 Oct 2009 16:46:34 -0400 Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpNzHtAe72WW4tJa0GmAvdvBbWc+gACnQdQ Message-ID: References: <4AD764D4.5040701@cisco.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 20:46:37 -0000 If you think it would help, I can certainly remove that "may only exist for= the purposes of this mechanism" piece. I have no problems even stipulatin= g that they MUST be valid DNS domain names, etc. Or even that they MUST be= sub-domains of the SSP's, if that would help. With regards to it creating to an alt-root or authority issues, of course i= t can. So can offering a web page to enter such information manually, or u= sing DynDNS to a private DNS server, or editing your local hostfile on your= PC. It's not the *purpose* of the Domain Registration mechanism to do tha= t - the fact that it can be abused to do so shouldn't keep us from issuing = a option-tag, should it? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Jon Peterson > Sent: Thursday, October 15, 2009 3:20 PM >=20 > From my reading of Section 3, I gather this is intended to work for > administrative domains that don't have domain names "at all." The place > where I think this actually raises serious concerns for standardization i= s > in the beginning of Section 4.1, where it is proposed that a UA register = a > domain name that "may only exist for the purposes of this mechanism", in > other words, a textual string that is structured enough like a domain nam= e > to work in SIP but has not actually been assigned in the global DNS > through > a domain registrar. >=20 > Providing I don't misunderstand the mechanism here, I see no way this > differs from an "alt-root" of the DNS, and it looks like it gives rise to > all of the same alt-root problems (e.g. Even if a name isn't in use in th= e > DNS when you first provision it, via this mechanism what if someone later > purchases that domain name and does put it to use in the DNS, which > authority do you consult then to make a routing decision?). The fourth > paragraph of 4.3.2 is pretty typical of such mechanisms. Even if they hav= e > tactical value in some deployment scenarios, I do not think the IETF > should > standardize alt-root schemes, and historically it has made statements ver= y > much to the contrary. Domain names are inexpensive and inexhaustible, and > the notion that an SMB cannot afford one is extremely dubious. >=20 > This stipulation can be removed without doing great violence to the > mechanism. The argument for not using RFC3263 then becomes a weaker one, > though - it would be that the SMB does not want to provide its own DNS > infrastructure or pony up costs for DNS hosting. Probably the strongest > remaining argument is that the SMB doesn't want to expose the IP address > of > its SIP domain publicly. That, however, could just as well be an argument > for using private DNS with RFC3263. Explaining the pros and cons of this > mechanism versus private DNS in the Alternatives section is probably a > worthwhile exercise. >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > On 10/15/09 11:07 AM, "Paul Kyzivat" wrote: >=20 > > > > > > Bernard Aboba wrote: > >> This draft is attempting to provide a well specified alternative to th= e > >> adhoc solutions that have been > >> > >> deployed so far. It builds on REGISTER as it exists today, and > >> therefore I don=B9t see how it would > >> > >> benefit from, or be related to, attempts to fix other problems that ma= y > >> exist in REGISTER. > > > > I've been trying to sit this discussion out. I see both pros and cons. > > > > While this solution builds on REGISTER as it exists today - in that it > > uses the REGISTER message - it doesn't at all build on the mechanisms > > behind REGISTER at all. Its updating a different routing mechanism. > > > > In an ideal world the solution to the problem this addresses would be > > reconsidered from scratch. That is what Dean is getting at. > > > >> Given this, I prefer option #1. The need for a well-specified > solution > >> is fairly urgent, given > > > > I guess maybe the question is how urgent this is. Aren't the people tha= t > > need this already doing *something*? How likely are they to move to thi= s > > more standardized variant of their existing adhoc solutions? > > > > Thanks, > > Paul > > > >> the persistent interoperability problems that could result from the > >> continued proliferation > >> > >> of adhoc solutions. > >> > >> > >> > >> If people feel it is useful to take on the issues that Dean describes > >> (personally, I=B9m skeptical), > >> > >> then that problem should be taken up separately. > >> > >> > >> > >> Dean Willis said: > >> > >> > >> > >> =B3I prefer option 2, given that the WG would take the requirements an= d > not > >> > >> the solution mechanism from SIP Forum. > >> > >> > >> > >> This is our one chance to fix REGISTER, and at the same time fix the > >> > >> request-URI/parameter delivery problem. Let's not waste it on an > >> > >> incomplete solution. > >> > >> > >> > >> I think that we can reasonably deliver on the domain-registration > >> > >> requirement and at the same time solve (for devices that use the new > >> > >> technique) the problem of URI and parameter delivery during SIP > routing. > >> > >> The "RUPDATE" approach I recently circulated (and that I would like to > >> > >> call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I > >> > >> should send a draft. > >> > >> > >> > >> Let's not be bashful. What we're talking about here is a replacement > for > >> > >> the now-known-to-be-broken SIP REGISTER mechanism (and the > >> > >> registered-contact routing mechanism that depends on it). While not al= l > >> > >> that hard, getting it right is still beyond the scope of an AD- > sponsored > >> > >> draft.=B2 > >> > >> > >> > >> > >> ----------------------------------------------------------------------= - > - > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From bernarda@microsoft.com Thu Oct 15 14:13: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 F29FE3A68C0 for ; Thu, 15 Oct 2009 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5cjDfiDK7RhT for ; Thu, 15 Oct 2009 14:13:53 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 333333A687C for ; Thu, 15 Oct 2009 14:13:53 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 15 Oct 2009 14:14:04 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Thu, 15 Oct 2009 14:13:55 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 15 Oct 2009 14:13:54 -0700 From: Bernard Aboba To: Jon Peterson , Paul Kyzivat Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpNzHtAe72WW4tJa0GmAvdvBbWc+gACr+EQ Date: Thu, 15 Oct 2009 21:13:55 +0000 Message-ID: References: <4AD764D4.5040701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 21:13:54 -0000 Paul said: "I guess maybe the question is how urgent this is. Aren't the people that need this already doing *something*? How likely are they to move to this more standardized variant of their existing adhoc solutions?" [BA] I know of at least two "implicit" REGISTER mechanisms that are deployed today. At least one of them is not documented, which=20 has resulted in debates as to exactly how it works and what scenarios are and are not supported. =20 We know from experience that creating a well-documented approach does not necessarily cause existing not-so-well documented approaches to=20 vanish. But it does offer the potential hope of a path to better=20 interoperability, whereas a reliance on undocumented mechanisms does not.=20 Jon Peterson said: "Providing I don't misunderstand the mechanism here, I see no way this differs from an "alt-root" of the DNS" [BA] It's important to distinguish between mechanism and policy. The draft doesn't talk much about policy, but I don't see why the right to=20 register a domain via the proposed mechanism couldn't be tied to ownership= =20 of the domain in question. Typically the domain in question is=20 owned by the service provider, so the SMB already has the right to=20 use it. =20 "I do not think the IETF should standardize alt-root schemes" [BA] I would agree -- but I doubt that this is the intent of the authors.=20 "Domain names are inexpensive and inexhaustible, and the notion that an SMB cannot afford one is extremely dubious." [BA] Given that the SMB is likely to be allocated a domain by the provider as part of the contract, we can probably assume that the SMB already "owns" an appropriate domain.=20 Given that, the choice is between standardized dynamic update mechanisms,=20 adhoc alternative schemes (e.g. DynDNS update protocol), and a purpose-buil= t=20 mechanism such as the one proposed in this draft.=20 "This stipulation can be removed without doing great violence to the mechanism. The argument for not using RFC3263 then becomes a weaker one, though - it would be that the SMB does not want to provide its own DNS infrastructure or pony up costs for DNS hosting." [BA] In my experience, DNS hosting costs are considerably less expensive than SIP trunking costs, so I doubt that's the concern. =20 "Explaining the pros and cons of this mechanism versus private DNS in the=20 Alternatives section is probably a worthwhile exercise." [BA] I agree. My understanding is that the larger issue is the operational implications of relying on standardized or adhoc dynamic DNS registration mechanisms. I myself own a domain whose A RR I dynamically register, yet I've been unable to find an inexpensive=20 service provider willing to deliver service to me using that domain;=20 whereas variants of REGISTER are widely supported.=20 From jon.peterson@neustar.biz Thu Oct 15 14:31: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 0DA513A6801 for ; Thu, 15 Oct 2009 14:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 bq+LX5TtCz93 for ; Thu, 15 Oct 2009 14:31:10 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 80ED73A62C1 for ; Thu, 15 Oct 2009 14:31:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1255642267; x=1255728667; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=dcSfSq6ym3EanUbpQ6SUh7RZggXmFBdWih5Wp3w03cQM07RzLvHM5nsFj4bKy9P5SYzau2HcMvQrNV JI6+xybQ== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.18742600; Thu, 15 Oct 2009 17:31:06 -0400 Received: from 192.168.128.21 ([192.168.128.21]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Oct 2009 21:31:02 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 15 Oct 2009 14:31:00 -0700 From: Jon Peterson To: Hadriel Kaplan , Paul Kyzivat , Bernard Aboba Message-ID: Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpNzHtAe72WW4tJa0GmAvdvBbWc+gACnQdQAAH2pqc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 21:31:12 -0000 It does help to state that they must be valid domain names assigned to the administrative domain in question. I think it would vastly improve the prospects that the IETF could work on this problem. > With regards to it creating to an alt-root or authority issues, of course= it > can. So can offering a web page to enter such information manually, or u= sing > DynDNS to a private DNS server, or editing your local hostfile on your PC= . > It's not the *purpose* of the Domain Registration mechanism to do that - = the > fact that it can be abused to do so shouldn't keep us from issuing a > option-tag, should it? To be clear, the way the draft is now written one could easily walk away with the impression that this is the purpose of the mechanism - one of the arguments for not using RFC3263 is that this mechanism works for domain names that haven't been assigned. Some of that motivation goes away if the mechanism is restricted to assigned domain names. The more subtle point here is that the risk of alt-roots lies in the possession of the same name by two administrative entities who potentially supply conflicting information to the directories used to route messages. The fault in the domain-registration draft (as written today) is not that i= t provides a means of registering names - as you say, that fault would be shared with any number of existing protocols - but that it implicitly creates a namespace managed by the back-end of that registration process, and a namespace that is explicitly permitted to conflict with the DNS by th= e text in the draft (nothing in the draft remotely suggests that this would b= e an "abuse" as you say above - in fact, it suggests the opposite, that this is a feature of the proposal!). The properties of that namespace is the problem from a standardization perspective, not the creation of any particular mechanism for populating a namespace. Jon Peterson NeuStar, Inc. > -hadriel >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Jon Peterson >> Sent: Thursday, October 15, 2009 3:20 PM >>=20 >> From my reading of Section 3, I gather this is intended to work for >> administrative domains that don't have domain names "at all." The place >> where I think this actually raises serious concerns for standardization = is >> in the beginning of Section 4.1, where it is proposed that a UA register= a >> domain name that "may only exist for the purposes of this mechanism", in >> other words, a textual string that is structured enough like a domain na= me >> to work in SIP but has not actually been assigned in the global DNS >> through >> a domain registrar. >>=20 >> Providing I don't misunderstand the mechanism here, I see no way this >> differs from an "alt-root" of the DNS, and it looks like it gives rise t= o >> all of the same alt-root problems (e.g. Even if a name isn't in use in t= he >> DNS when you first provision it, via this mechanism what if someone late= r >> purchases that domain name and does put it to use in the DNS, which >> authority do you consult then to make a routing decision?). The fourth >> paragraph of 4.3.2 is pretty typical of such mechanisms. Even if they ha= ve >> tactical value in some deployment scenarios, I do not think the IETF >> should >> standardize alt-root schemes, and historically it has made statements ve= ry >> much to the contrary. Domain names are inexpensive and inexhaustible, an= d >> the notion that an SMB cannot afford one is extremely dubious. >>=20 >> This stipulation can be removed without doing great violence to the >> mechanism. The argument for not using RFC3263 then becomes a weaker one, >> though - it would be that the SMB does not want to provide its own DNS >> infrastructure or pony up costs for DNS hosting. Probably the strongest >> remaining argument is that the SMB doesn't want to expose the IP address >> of >> its SIP domain publicly. That, however, could just as well be an argumen= t >> for using private DNS with RFC3263. Explaining the pros and cons of this >> mechanism versus private DNS in the Alternatives section is probably a >> worthwhile exercise. >>=20 >> Jon Peterson >> NeuStar, Inc. >>=20 >>=20 >> On 10/15/09 11:07 AM, "Paul Kyzivat" wrote: >>=20 >>>=20 >>>=20 >>> Bernard Aboba wrote: >>>> This draft is attempting to provide a well specified alternative to th= e >>>> adhoc solutions that have been >>>>=20 >>>> deployed so far. It builds on REGISTER as it exists today, and >>>> therefore I don=B9t see how it would >>>>=20 >>>> benefit from, or be related to, attempts to fix other problems that ma= y >>>> exist in REGISTER. >>>=20 >>> I've been trying to sit this discussion out. I see both pros and cons. >>>=20 >>> While this solution builds on REGISTER as it exists today - in that it >>> uses the REGISTER message - it doesn't at all build on the mechanisms >>> behind REGISTER at all. Its updating a different routing mechanism. >>>=20 >>> In an ideal world the solution to the problem this addresses would be >>> reconsidered from scratch. That is what Dean is getting at. >>>=20 >>>> Given this, I prefer option #1. The need for a well-specified >> solution >>>> is fairly urgent, given >>>=20 >>> I guess maybe the question is how urgent this is. Aren't the people tha= t >>> need this already doing *something*? How likely are they to move to thi= s >>> more standardized variant of their existing adhoc solutions? >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> the persistent interoperability problems that could result from the >>>> continued proliferation >>>>=20 >>>> of adhoc solutions. >>>>=20 >>>>=20 >>>>=20 >>>> If people feel it is useful to take on the issues that Dean describes >>>> (personally, I=B9m skeptical), >>>>=20 >>>> then that problem should be taken up separately. >>>>=20 >>>>=20 >>>>=20 >>>> Dean Willis said: >>>>=20 >>>>=20 >>>>=20 >>>> =B3I prefer option 2, given that the WG would take the requirements and >> not >>>>=20 >>>> the solution mechanism from SIP Forum. >>>>=20 >>>>=20 >>>>=20 >>>> This is our one chance to fix REGISTER, and at the same time fix the >>>>=20 >>>> request-URI/parameter delivery problem. Let's not waste it on an >>>>=20 >>>> incomplete solution. >>>>=20 >>>>=20 >>>>=20 >>>> I think that we can reasonably deliver on the domain-registration >>>>=20 >>>> requirement and at the same time solve (for devices that use the new >>>>=20 >>>> technique) the problem of URI and parameter delivery during SIP >> routing. >>>>=20 >>>> The "RUPDATE" approach I recently circulated (and that I would like to >>>>=20 >>>> call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I >>>>=20 >>>> should send a draft. >>>>=20 >>>>=20 >>>>=20 >>>> Let's not be bashful. What we're talking about here is a replacement >> for >>>>=20 >>>> the now-known-to-be-broken SIP REGISTER mechanism (and the >>>>=20 >>>> registered-contact routing mechanism that depends on it). While not al= l >>>>=20 >>>> that hard, getting it right is still beyond the scope of an AD- >> sponsored >>>>=20 >>>> draft.=B2 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ----------------------------------------------------------------------= - >> - >>>>=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 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Thu Oct 15 14:45: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 2CB303A681F for ; Thu, 15 Oct 2009 14:45:34 -0700 (PDT) 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 NGq2EJgumU6o for ; Thu, 15 Oct 2009 14:45:33 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5F13E3A6804 for ; Thu, 15 Oct 2009 14:45:33 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9FLjYFY022805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Oct 2009 16:45:35 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 16:45:28 -0500 References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 21:45:34 -0000 On Oct 15, 2009, at 10:23 AM, Hadriel Kaplan wrote: > > This is not our "one chance to fix REGISTER". This draft isn't > trying to "fix REGISTER". What's broken about REGISTER that needs a > fixin'? That is a deeply disingenuous response, as you've been there for most of the last several years debate on contact-routing, URI passing, and parameter passing. -- Dean From dean.willis@softarmor.com Thu Oct 15 14:49: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 28A7C3A6804 for ; Thu, 15 Oct 2009 14:49:22 -0700 (PDT) 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 KBOPCUv-bhdM for ; Thu, 15 Oct 2009 14:49:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 741DD3A67FA for ; Thu, 15 Oct 2009 14:49:21 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9FLnLWW022840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Oct 2009 16:49:23 -0500 Message-Id: <1893B790-4C7E-4B3F-B797-7B089A0D245C@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 16:49:16 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration: semantics of REGISTER 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, 15 Oct 2009 21:49:22 -0000 On Oct 15, 2009, at 3:25 PM, Hadriel Kaplan wrote: > > But, it's also different in that: > a) The reachability information pertains to a whole domain, not just > one AoR. As the use case has been explained to me, it's not even a domain that it pertains to; it's a mass off direct-inward-dial telephone numbers. Note that REGISTER never worked right for telephone numbers anyhow -- we kludged it by faking phone numbers inside SIP URIs. -- Dean From HKaplan@acmepacket.com Thu Oct 15 14:53: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 C9B063A6882 for ; Thu, 15 Oct 2009 14:53:07 -0700 (PDT) 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 Iq7E7of2h6oz for ; Thu, 15 Oct 2009 14:53:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 002113A6852 for ; Thu, 15 Oct 2009 14:53:06 -0700 (PDT) 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; Thu, 15 Oct 2009 17:53:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 17:53:09 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 15 Oct 2009 17:53:08 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpN4OEu3Z3GWOLHTq2fcY27pZcg1QAAFugg Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> 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: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 21:53:07 -0000 Well I really didn't mean for it to be disingenuous. (honest) The three things you mentioned, for example, do not mean to me the REGISTER= transaction mechanism is broken whatsoever. They have to do with how to r= oute to the entity that Registered, which is after the fact. In the Domain= Registration mechanism we side-step that whole issue, since we're not repl= acing the request-uri, but are just doing loose-routing. -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, October 15, 2009 5:45 PM >=20 > On Oct 15, 2009, at 10:23 AM, Hadriel Kaplan wrote: >=20 > > > > This is not our "one chance to fix REGISTER". This draft isn't > > trying to "fix REGISTER". What's broken about REGISTER that needs a > > fixin'? >=20 > That is a deeply disingenuous response, as you've been there for most > of the last several years debate on contact-routing, URI passing, and > parameter passing. >=20 > -- > Dean From david.middleton@nsn.com Thu Oct 15 15:06: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 B7C793A68ED for ; Thu, 15 Oct 2009 15:06:26 -0700 (PDT) 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 LBWdpgCPYsJS for ; Thu, 15 Oct 2009 15:06:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 688873A68CD for ; Thu, 15 Oct 2009 15:06:24 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9FM6OWG031553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 00:06:24 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9FM6NSO031254; Fri, 16 Oct 2009 00:06:23 +0200 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 00:06:23 +0200 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, 15 Oct 2009 17:06:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNQ+yHpZzhyoR1R2KbKYHzpwxdcwAa3r6gAAqzJdA= References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com><4AD62824.4030704@softarmor.com> <1255575703.7009.405.camel@scott> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Hadriel Kaplan" X-OriginalArrivalTime: 15 Oct 2009 22:06:23.0897 (UTC) FILETIME=[BBE87890:01CA4DE3] Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 22:06:26 -0000 Hadriel, With respect to the text in 4.3.1: If a matching SIP Domain Name is found and the Contact URI being=20 Registered matches one already in the DRT, the REGISTER updates the=20 entry. I suggest that the user portion of the REGISTER To: URI be used to determine whether to update an existing entry or add a new entry. This avoids errant multiple entries in case a changed contact URI is received (i.e. with a different IP Address) and the previous entry was not de-registered as might happen in the case of a network failure. In doing this, it should be stated that the user info portion MUST remain the same for a given connection path unless changed via manual configuration. While the problem I mentioned can happen for single user type UAs, the problem is magnified when it happens for a PBX so we should try to prevent it. Lastly, nothing is mentioned in the draft about Call-ID and CSeq (Ref. RFC 3261 Section 10.3) being used to determine if DRT entries should be removed or updated. Since REGISTER is being reused, an explicit statement is warranted. David From HKaplan@acmepacket.com Thu Oct 15 15:16: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 8E5483A682B for ; Thu, 15 Oct 2009 15:16:55 -0700 (PDT) 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 oTiQm1EPRRTB for ; Thu, 15 Oct 2009 15:16:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6CB4B3A67FA for ; Thu, 15 Oct 2009 15:16:54 -0700 (PDT) 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; Thu, 15 Oct 2009 18:16:56 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 18:16:56 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 15 Oct 2009 18:16:55 -0400 Thread-Topic: [dispatch] Domain Registration: semantics of REGISTER Thread-Index: AcpN4V1y1rH5YUUHQgSskIJCsM2wJgAAKGvA Message-ID: References: <1893B790-4C7E-4B3F-B797-7B089A0D245C@softarmor.com> In-Reply-To: <1893B790-4C7E-4B3F-B797-7B089A0D245C@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration: semantics of REGISTER 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, 15 Oct 2009 22:16:55 -0000 Inline... > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, October 15, 2009 5:49 PM > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Domain Registration: semantics of REGISTER >=20 >=20 > On Oct 15, 2009, at 3:25 PM, Hadriel Kaplan wrote: > > > > But, it's also different in that: > > a) The reachability information pertains to a whole domain, not just > > one AoR. >=20 > As the use case has been explained to me, it's not even a domain that > it pertains to; it's a mass off direct-inward-dial telephone numbers. The biggest use-case is undoubtedly for phone numbers. I would argue that'= s the biggest use-case for any extension/use of REGISTER and INVITEs, and f= or SIP in general really, currently. But luckily it doesn't matter. The Domain Registration really is providing= reachability for the domain, no matter its use-case. If you send a SIP re= quest to "sip:bob@enterprise.com" to ssp.com, and enterprise.com had Regist= ered its reachability info into ssp.com, then ssp.com will route the reques= t to enterprise.com using that Registered info. Obviously for DID numbers which are AoR's of another domain (like the SSP's= domain), the SSP can have local policy retargeting rules for all those DID= 's which retarget them to another domain, like the Enterprise's. That's ju= st normal 3261, nothing to see there. =20 -hadriel From HKaplan@acmepacket.com Thu Oct 15 15:29: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 96A023A686A for ; Thu, 15 Oct 2009 15:29:27 -0700 (PDT) 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 o5lTv0rwkqyT for ; Thu, 15 Oct 2009 15:29:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A54243A6407 for ; Thu, 15 Oct 2009 15:29:26 -0700 (PDT) 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; Thu, 15 Oct 2009 18:29:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 18:29:27 -0400 From: Hadriel Kaplan To: "Middleton, David (NSN - US/Boca Raton)" Date: Thu, 15 Oct 2009 18:29:27 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNQ+yHpZzhyoR1R2KbKYHzpwxdcwAa3r6gAAqzJdAAAsCjsA== Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com><4AD62824.4030704@softarmor.com> <1255575703.7009.405.camel@scott> 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: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 22:29:27 -0000 Inline... > -----Original Message----- > From: Middleton, David (NSN - US/Boca Raton) > [mailto:david.middleton@nsn.com] > Sent: Thursday, October 15, 2009 6:06 PM >=20 > Hadriel, >=20 > With respect to the text in 4.3.1: >=20 > If a matching SIP Domain Name is found and the Contact URI being > Registered matches one already in the DRT, the REGISTER updates the > entry. >=20 > I suggest that the user portion of the REGISTER To: URI be used to > determine whether to update an existing entry or add a new entry. This > avoids errant multiple entries in case a changed contact URI is received > (i.e. with a different IP Address) and the previous entry was not > de-registered as might happen in the case of a network failure. In > doing this, it should be stated that the user info portion MUST remain > the same for a given connection path unless changed via manual > configuration. While the problem I mentioned can happen for single user > type UAs, the problem is magnified when it happens for a PBX so we > should try to prevent it. Yeah we've debated that one, and I think the consensus was: use sip-outboun= d if you want to avoid that. Because really what it's asking for is reg-id= and such, and we wouldn't want to conflict with sip-outbound's own mechani= sms for doing that stuff. So while you're right of course that you'll end = up with two entries until the expires times out, it's not going to fail. W= hat I could do is say "for the same given q-value, use the most recently re= gistered/updated one first". How about that? =20 > Lastly, nothing is mentioned in the draft about Call-ID and CSeq (Ref. > RFC 3261 Section 10.3) being used to determine if DRT entries should be > removed or updated. Since REGISTER is being reused, an explicit > statement is warranted. Hmmm. I was kinda trying to avoid including an update for or copy of secti= on 10.3 in its entirety, and only do the "diff" part. Are you thinking the= Call-ID/CSeq checking of 10.3 should be different, or instead maybe that I= wasn't clear in the draft that it's only a "diff" of it? -hadriel From HKaplan@acmepacket.com Thu Oct 15 15:31: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 AC6AC3A68CD for ; Thu, 15 Oct 2009 15:31:22 -0700 (PDT) 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 PO6orYrZ6zox for ; Thu, 15 Oct 2009 15:31:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CDC253A686A for ; Thu, 15 Oct 2009 15:31:21 -0700 (PDT) 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; Thu, 15 Oct 2009 18:31:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Oct 2009 18:31:24 -0400 From: Hadriel Kaplan To: Jon Peterson Date: Thu, 15 Oct 2009 18:31:23 -0400 Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpNzHtAe72WW4tJa0GmAvdvBbWc+gACnQdQAAH2pqcAAg2IUA== 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 22:31:22 -0000 > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > Sent: Thursday, October 15, 2009 5:31 PM > To: Hadriel Kaplan; Paul Kyzivat; Bernard Aboba > Cc: dispatch@ietf.org > Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch- > domain-registration >=20 >=20 > It does help to state that they must be valid domain names assigned to th= e > administrative domain in question. I think it would vastly improve the > prospects that the IETF could work on this problem. No problemo - will do next round. > To be clear, the way the draft is now written one could easily walk away > with the impression that this is the purpose of the mechanism - one of th= e > arguments for not using RFC3263 is that this mechanism works for domain > names that haven't been assigned. Some of that motivation goes away if th= e > mechanism is restricted to assigned domain names. OK, I'll clear up why it's still motivating. -hadriel From pkyzivat@cisco.com Thu Oct 15 16:03: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 8C61E3A6885 for ; Thu, 15 Oct 2009 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 eftNXbUZ1w7F for ; Thu, 15 Oct 2009 16:03:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 654413A6811 for ; Thu, 15 Oct 2009 16:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1272; q=dns/txt; s=rtpiport02001; t=1255647807; x=1256857407; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20DomainRegistration=20Draftdraft-kap lan-dispatch-domain-registration|Date:=20Thu,=2015=20Oct =202009=2019:03:25=20-0400|Message-ID:=20<4AD7AA3D.807010 8@cisco.com>|To:=20Hadriel=20Kaplan=20|CC:=20Jon=20Peterson=20, =0D=0A=20=20=20=20=20=20=20=20"dispatch@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20 =09=20; bh=r9obXlz2qh+3myPRNR3jo0QwIavaOX4PoOVSF3+4cRY=; b=F1Cx5xgM6O+MC8RiEDsw/fZCUClNbklvvXZAO9k7s2SMaFeV8eJxsjN1 1GeBgykX3VY20SwSCtX6GE6t26gUsM0yaNX2fUwG3u1ip2w2zmx2/Mm/q Cy5W/c15Le57qIF+DH08bP3VoufZqvyy0CkJubGpNKM+Y4ql/vY+RaZ5l w=; 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: AqgEAItG10pAZnwM/2dsb2JhbAAvwD2YL4QwBA X-IronPort-AV: E=Sophos;i="4.44,568,1249257600"; d="scan'208";a="63343480" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Oct 2009 23:03:26 +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 n9FN3Qv8024112; Thu, 15 Oct 2009 23:03:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 19:03:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 19:03:25 -0400 Message-ID: <4AD7AA3D.8070108@cisco.com> Date: Thu, 15 Oct 2009 19:03:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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 X-OriginalArrivalTime: 15 Oct 2009 23:03:26.0013 (UTC) FILETIME=[B3A5EED0:01CA4DEB] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 23:03:24 -0000 I think this thread had substantiated that there *is* some controversy. Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >> Sent: Thursday, October 15, 2009 5:31 PM >> To: Hadriel Kaplan; Paul Kyzivat; Bernard Aboba >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch- >> domain-registration >> >> >> It does help to state that they must be valid domain names assigned to the >> administrative domain in question. I think it would vastly improve the >> prospects that the IETF could work on this problem. > > No problemo - will do next round. > > >> To be clear, the way the draft is now written one could easily walk away >> with the impression that this is the purpose of the mechanism - one of the >> arguments for not using RFC3263 is that this mechanism works for domain >> names that haven't been assigned. Some of that motivation goes away if the >> mechanism is restricted to assigned domain names. > > OK, I'll clear up why it's still motivating. > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jon.peterson@neustar.biz Thu Oct 15 16:41: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 7099C3A6944 for ; Thu, 15 Oct 2009 16:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 6doN9AaUapes for ; Thu, 15 Oct 2009 16:41:05 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 574A33A691D for ; Thu, 15 Oct 2009 16:41:05 -0700 (PDT) Received: from ([192.168.128.21]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.1222109; Thu, 15 Oct 2009 19:41:01 -0400 Message-ID: <4AD7B30C.8080106@neustar.biz> Date: Thu, 15 Oct 2009 16:41:00 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4AD7AA3D.8070108@cisco.com> In-Reply-To: <4AD7AA3D.8070108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 15 Oct 2009 23:41:07 -0000 I have been giving some thought to Cullen's original question of what to do with this document. Had it shown up without a built-in mechanism, but just as a set of proposed requirements, I would probably say, "Hmm. Provisioning for a routing systems used to determine the next hop to reach an administrative domain. Works for telephone numbers. Why wasn't this just submitted to DRINKS?" So, a fourth option would be to DISPATCH this to DRINKS for consideration as a charter item there. Given the overlap with other things considered in DRINKS, that might be preferable to spinning up a new effort of some kind, were that under consideration. I'd also have a bunch of comments about the proposed mechanism, including a perhaps predictable assessment of the relative merits of REGISTER and PUBLISH for this function, but if this document is going to get a WG home, that discussion belongs there. Jon Peterson NeuStar, Inc. Paul Kyzivat wrote: > I think this thread had substantiated that there *is* some controversy. > > Paul > > Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >>> Sent: Thursday, October 15, 2009 5:31 PM >>> To: Hadriel Kaplan; Paul Kyzivat; Bernard Aboba >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch- >>> domain-registration >>> >>> >>> It does help to state that they must be valid domain names assigned >>> to the >>> administrative domain in question. I think it would vastly improve the >>> prospects that the IETF could work on this problem. >> >> No problemo - will do next round. >> >> >>> To be clear, the way the draft is now written one could easily walk >>> away >>> with the impression that this is the purpose of the mechanism - one >>> of the >>> arguments for not using RFC3263 is that this mechanism works for domain >>> names that haven't been assigned. Some of that motivation goes away >>> if the >>> mechanism is restricted to assigned domain names. >> >> OK, I'll clear up why it's still motivating. >> >> -hadriel >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From richard@shockey.us Thu Oct 15 17:00:06 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 B19623A694C for ; Thu, 15 Oct 2009 17:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.644, 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 AwFvgJudYHCm for ; Thu, 15 Oct 2009 17:00:05 -0700 (PDT) Received: from outbound-mail-23.bluehost.com (outbound-mail-23.bluehost.com [69.89.21.18]) by core3.amsl.com (Postfix) with SMTP id 1B7DC3A681D for ; Thu, 15 Oct 2009 17:00:05 -0700 (PDT) Received: (qmail 32239 invoked by uid 0); 16 Oct 2009 00:00:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 16 Oct 2009 00:00:08 -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=UuxX2wrXiuFP5UhxCY1MQx7oYCucSpuFb39yj8X2pk/mJYz+dzwGEwHOgdaPGIiMXyut1uhJbxfq9hmzC61yrF4/4rDt5chcpphVTuVDk98fk3avT85WhEzh/oPxyEZG; 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 1MyaEp-0007k9-1P; Thu, 15 Oct 2009 18:00:08 -0600 From: "Richard Shockey" To: "'Jon Peterson'" , "'Paul Kyzivat'" References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> In-Reply-To: <4AD7B30C.8080106@neustar.biz> Date: Thu, 15 Oct 2009 20:00:02 -0400 Message-ID: <025201ca4df3$9d091410$d71b3c30$@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: AcpN8PrghiJIiTYKS0GrNrKbWzdWggAAh/RA 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, 'Hadriel Kaplan' Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 00:00:06 -0000 NO .. I don't think so. This is NOT a DRINKS issue and I cant possibly imagine any scenario where it would be. This is about SIP Trunking between S-PBX and a SSP. There are certainly provisioning issues that need to be dealt with but they are not even orthogonal to the problem at hand. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Jon Peterson > Sent: Thursday, October 15, 2009 7:41 PM > To: Paul Kyzivat > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch- > domain-registration > > > I have been giving some thought to Cullen's original question of what > to > do with this document. Had it shown up without a built-in mechanism, > but > just as a set of proposed requirements, I would probably say, "Hmm. > Provisioning for a routing systems used to determine the next hop to > reach an administrative domain. Works for telephone numbers. Why > wasn't > this just submitted to DRINKS?" > > So, a fourth option would be to DISPATCH this to DRINKS for > consideration as a charter item there. Given the overlap with other > things considered in DRINKS, that might be preferable to spinning up a > new effort of some kind, were that under consideration. > > I'd also have a bunch of comments about the proposed mechanism, > including a perhaps predictable assessment of the relative merits of > REGISTER and PUBLISH for this function, but if this document is going > to > get a WG home, that discussion belongs there. > > Jon Peterson > NeuStar, Inc. > > Paul Kyzivat wrote: > > I think this thread had substantiated that there *is* some > controversy. > > > > Paul > > > > Hadriel Kaplan wrote: > >> > >>> -----Original Message----- > >>> From: Jon Peterson [mailto:jon.peterson@neustar.biz] > >>> Sent: Thursday, October 15, 2009 5:31 PM > >>> To: Hadriel Kaplan; Paul Kyzivat; Bernard Aboba > >>> Cc: dispatch@ietf.org > >>> Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan- > dispatch- > >>> domain-registration > >>> > >>> > >>> It does help to state that they must be valid domain names > assigned > >>> to the > >>> administrative domain in question. I think it would vastly improve > the > >>> prospects that the IETF could work on this problem. > >> > >> No problemo - will do next round. > >> > >> > >>> To be clear, the way the draft is now written one could easily > walk > >>> away > >>> with the impression that this is the purpose of the mechanism - > one > >>> of the > >>> arguments for not using RFC3263 is that this mechanism works for > domain > >>> names that haven't been assigned. Some of that motivation goes > away > >>> if the > >>> mechanism is restricted to assigned domain names. > >> > >> OK, I'll clear up why it's still motivating. > >> > >> -hadriel > >> _______________________________________________ > >> 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 david.middleton@nsn.com Fri Oct 16 04:54: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 350DC28C205 for ; Fri, 16 Oct 2009 04:54:09 -0700 (PDT) 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 oMNUjlcwMvoR for ; Fri, 16 Oct 2009 04:54:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 0914F28B23E for ; Fri, 16 Oct 2009 04:54:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9GBs8Yt016859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 13:54:08 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9GBs87v019258; Fri, 16 Oct 2009 13:54:08 +0200 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 13:54:08 +0200 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, 16 Oct 2009 06:53:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpNQ+yHpZzhyoR1R2KbKYHzpwxdcwAa3r6gAAqzJdAAAsCjsAAb8Y0g References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com><4AD62824.4030704@softarmor.com> <1255575703.7009.405.camel@scott> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Hadriel Kaplan" X-OriginalArrivalTime: 16 Oct 2009 11:54:08.0428 (UTC) FILETIME=[5E467EC0:01CA4E57] Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 11:54:09 -0000 Inline -----Original Message----- From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Thursday, October 15, 2009 6:29 PM To: Middleton, David (NSN - US/Boca Raton) Cc: dispatch@ietf.org Subject: RE: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Inline... > -----Original Message----- > From: Middleton, David (NSN - US/Boca Raton) > [mailto:david.middleton@nsn.com] > Sent: Thursday, October 15, 2009 6:06 PM >=20 > Hadriel, >=20 > With respect to the text in 4.3.1: >=20 > If a matching SIP Domain Name is found and the Contact URI being > Registered matches one already in the DRT, the REGISTER updates the > entry. >=20 > I suggest that the user portion of the REGISTER To: URI be used to > determine whether to update an existing entry or add a new entry. This > avoids errant multiple entries in case a changed contact URI is received > (i.e. with a different IP Address) and the previous entry was not > de-registered as might happen in the case of a network failure. In > doing this, it should be stated that the user info portion MUST remain > the same for a given connection path unless changed via manual > configuration. While the problem I mentioned can happen for single user > type UAs, the problem is magnified when it happens for a PBX so we > should try to prevent it. Yeah we've debated that one, and I think the consensus was: use sip-outbound if you want to avoid that. Because really what it's asking for is reg-id and such, and we wouldn't want to conflict with sip-outbound's own mechanisms for doing that stuff. So while you're right of course that you'll end up with two entries until the expires times out, it's not going to fail. What I could do is say "for the same given q-value, use the most recently registered/updated one first". How about that? I don't like the q-value distinction. My thinking is that a distribution of traffic across all registered contacts with the same q-value should be allowed and that distinction would prevent that. Also, reg-id can't be guaranteed to be unique when multiple CPEs (e.g. PRI to SIP GW) register on behalf of the same PBX. > Lastly, nothing is mentioned in the draft about Call-ID and CSeq (Ref. > RFC 3261 Section 10.3) being used to determine if DRT entries should be > removed or updated. Since REGISTER is being reused, an explicit > statement is warranted. Hmmm. I was kinda trying to avoid including an update for or copy of section 10.3 in its entirety, and only do the "diff" part. Are you thinking the Call-ID/CSeq checking of 10.3 should be different, or instead maybe that I wasn't clear in the draft that it's only a "diff" of it? It isn't clear to me what the relationship with 10.3 is. My assumption was that Call-ID/Cseq checking were excluded because the draft only talks about comparing the Domain Name and Contact URI. -hadriel From ian.elz@ericsson.com Fri Oct 16 05: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 F0E893A6A37 for ; Fri, 16 Oct 2009 05:13:31 -0700 (PDT) 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 6rH5tv8NfnG8 for ; Fri, 16 Oct 2009 05:13:31 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E723D3A6837 for ; Fri, 16 Oct 2009 05:13:30 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-ae-4ad8636dc0dd Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8B.63.24026.D6368DA4; Fri, 16 Oct 2009 14:13:33 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 14:12:46 +0200 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, 16 Oct 2009 14:12:45 +0200 Message-ID: In-Reply-To: <55394D27-920E-48EB-966A-E01655D91F58@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D: Referencing Earlier Communications in SIP Requests Thread-Index: AcpOWfhcsTlzUXxNQvKipSCUWKNofw== References: <55394D27-920E-48EB-966A-E01655D91F58@cs.columbia.edu> From: "Ian Elz" To: "Kumiko Ono" , X-OriginalArrivalTime: 16 Oct 2009 12:12:46.0763 (UTC) FILETIME=[F8DADFB0:01CA4E59] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] I-D: Referencing Earlier Communications in SIP Requests 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, 16 Oct 2009 12:13:32 -0000 Kumiko, You have not considered the use of "in-Reply-To" which is already included in RFC3261. An extension to this is another option. Can you include information about how a B2BUA will support this functionality? Ian Elz=20 -----Original Message----- From: Kumiko Ono [mailto:kumiko@cs.columbia.edu]=20 Sent: 14 October 2009 23:10 To: dispatch@ietf.org Subject: [dispatch] I-D: Referencing Earlier Communications in SIP Requests Hi, We've submitted a new I-D, "Referencing Earlier Communications in SIP Requests." You can find it at http://tools.ietf.org/html/draft-ono-earlier-comm-references-00 . Abstract: This document defines a SIP header extension that refers to earlier SIP or non-SIP communication in SIP requests. For example, this extension allows users to correlate a SIP session with earlier sessions or email exchanges. The background is described in another I-D, "Using Cross-Media Relations to Reduce False Positives during SPIT Filtering." http://tools.ietf.org/html/draft-ono-cross-media-relations-00 Your comments or questions are very welcome. Thanks, Kumiko From HKaplan@acmepacket.com Fri Oct 16 06:58: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 337713A695E for ; Fri, 16 Oct 2009 06:58:32 -0700 (PDT) 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, J_CHICKENPOX_82=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 uV-OVLuNRJ9i for ; Fri, 16 Oct 2009 06:58:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 48D253A6939 for ; Fri, 16 Oct 2009 06:58:31 -0700 (PDT) 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; Fri, 16 Oct 2009 09:58:34 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Oct 2009 09:58:34 -0400 From: Hadriel Kaplan To: Jon Peterson , Paul Kyzivat Date: Fri, 16 Oct 2009 09:58:33 -0400 Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpN8QRg90ZgPE6xQWaXb1w5vYD7TgAdDgHg Message-ID: References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> In-Reply-To: <4AD7B30C.8080106@neustar.biz> 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: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 13:58:32 -0000 Yeah, I can see what you mean, but there really aren't even the 3 options i= n Cullen's email. We wanted to get an options-tag because we thought it wa= s "the right thing to do". ISTM the options-tag concept was put in place f= or this kind of circumstance, so that an extension can be cleanly indicated= and an incompatibility detected/negotiated. And since an options-tag requ= ires a standards-track, here we are. =20 Going the A-D route didn't mean we weren't open to edits/changes of the doc= ument's mechanism - we *want* people's feedback - just that we don't have t= ime for a WG charter, a requirements doc, fixing unrelated issues, etc. But if the consensus is that we can't go the A-D route, then we'll just go = with Option-3: submitting an Informational draft and go the individual subm= ission path. We'll get rid of the options-tag, and either just ask for a S= IP Header to do something similar, or not even that. =20 There's enough wiggle room in rfc3261 routing procedures that we can docume= nt this whole thing to just be a specific implementation of 3261-compliant = local-policy routing, based on the reachability information from a "normal"= 3261-compliant REGISTER'ed AoR. -hadriel > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > Sent: Thursday, October 15, 2009 7:41 PM >=20 > I have been giving some thought to Cullen's original question of what to > do with this document. Had it shown up without a built-in mechanism, but > just as a set of proposed requirements, I would probably say, "Hmm. > Provisioning for a routing systems used to determine the next hop to > reach an administrative domain. Works for telephone numbers. Why wasn't > this just submitted to DRINKS?" >=20 > So, a fourth option would be to DISPATCH this to DRINKS for > consideration as a charter item there. Given the overlap with other > things considered in DRINKS, that might be preferable to spinning up a > new effort of some kind, were that under consideration. >=20 > I'd also have a bunch of comments about the proposed mechanism, > including a perhaps predictable assessment of the relative merits of > REGISTER and PUBLISH for this function, but if this document is going to > get a WG home, that discussion belongs there. >=20 > Jon Peterson > NeuStar, Inc. >=20 From audet.francois@gmail.com Fri Oct 16 07:00: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 EE5823A68D2 for ; Fri, 16 Oct 2009 07:00:01 -0700 (PDT) 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 GRqt5CLnaimz for ; Fri, 16 Oct 2009 07:00:01 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C05D03A69E0 for ; Fri, 16 Oct 2009 07:00:00 -0700 (PDT) Received: by fxm18 with SMTP id 18so2441825fxm.37 for ; Fri, 16 Oct 2009 07:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=XPDGLFAry/eYJ5Uk0O9yAcINdYyeyZ6Ip436ZpTrV5U=; b=NdgLGvhWCjyUzWpeBZE2gPfnBESXTmszxiSnB1t/PvESAEm25w7ZP7UtbiTaWQvNmz 4b0mND2GzKsiWFPECNhM77q/p8Cc9Qf/axXWXNtap+mBPfkxctuh3+nIWa2Bss4T386z M2W8BqVa44CjY82S7xp38yCTwubCkzlYn0wy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fCK1YJ2wP0o7qxCdtVb25kiwP0M+i56b48DZzXkRHPm5Lpicmb3UK9XK9LqYRk/dO4 KT/z/gThjNAwNT4Vh81zm8I1woP3OVMilavMiMY8CnjjzVxWDhUM6KLIgrE4XBcZXTKd pP/2B0HXUlPYAMt0EZGcAKSwBcxjgxW6YNu+U= Received: by 10.204.26.206 with SMTP id f14mr1305462bkc.95.1255701599911; Fri, 16 Oct 2009 06:59:59 -0700 (PDT) Received: from ?192.168.15.101? (adsl-76-195-0-45.dsl.pltn13.sbcglobal.net [76.195.0.45]) by mx.google.com with ESMTPS id c28sm1638206fka.24.2009.10.16.06.59.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Oct 2009 06:59:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Francois Audet In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Date: Fri, 16 Oct 2009 06:59:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: <02986926-70A6-48CA-B17D-BAE6FDAFE69E@gmail.com> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Fri, 16 Oct 2009 08:23:25 -0700 Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 15:20:37 -0000 I believe the best course of action is option 1. The whole point of this is not to re-invent REGISTER. As others said, this may be something for SIP 3.0. The idea with option 1 is to formalize and harmonize a widely implemented (and useful) practice. On Oct 13, 2009, at 12:06 , Cullen Jennings wrote: > > The SIP Forum has recently sent us the draft > > http://www.ietf.org/id/draft-kaplan-dispatch-domain- > registration-00.txt > > This draft is pretty close to what several vendors are doing in some > existing deployments. In my AD roll I have been trying to figure out > how to progress this draft. Some people have asked me to AD sponsor > it. I see the ways this draft could more forward are: > > 1) AD sponsor. I'm willing to do this if there is consensus in > dispatch that this is a good way to move forward. > > 2) Use the dispatch WG to spin up a new WG to deal with this. > > 3) remove the options tag and go to the independent stream > > I expect that with both #1 and #2, the document will get roughly the > same review and #1 is less work for me and the IESG. What's your > thoughts on how we should move this forward? > > Thanks, Cullen > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Fri Oct 16 08:25: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 9FA853A68EA for ; Fri, 16 Oct 2009 08:25:52 -0700 (PDT) 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, J_CHICKENPOX_33=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 6RPJ8-FlP7Dd for ; Fri, 16 Oct 2009 08:25:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A9FF33A685B for ; Fri, 16 Oct 2009 08:25:51 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9GFPmvG030229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 10:25:51 -0500 Message-ID: <4AD89077.10906@softarmor.com> Date: Fri, 16 Oct 2009 10:25:43 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Hadriel Kaplan References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 15:25:52 -0000 Hadriel Kaplan wrote: > Well I really didn't mean for it to be disingenuous. (honest) The > three things you mentioned, for example, do not mean to me the > REGISTER transaction mechanism is broken whatsoever. They have to do > with how to route to the entity that Registered, which is after the > fact. In the Domain Registration mechanism we side-step that whole > issue, since we're not replacing the request-uri, but are just doing > loose-routing. > Exactly: the extension you have requires the node using the REGISTERed contact information to behave differently from how it would do it with "regular" contacts, yet does not AFAIK give that node a really clear way to know the difference. The proposed ROUTEUP (was RUPDATE) mechanism eliminates this. An exchanged route is something very clearly different from a registered contact. It has different content, different behavior at the storage-point (former registrar, where as you have noted it goes into a different table from Contacts), different behavior at the route-sourcing user agent or intermediary (both in sending the route and in handling a received message routed via the mechanism) and different behavior at the routing proxy that uses/inserts the route (requiring "loose routing", which does not change the contact URI rather than "contact routing" which does change the contact URI). It's almost completely totally different from REGISTER. We have no shortage of method namespace, so let's call it something besides REGISTER. While we're fixing the name, let's add a couple of needful things: 1) The ability to store multi-hop, rather than single-hop, routes. This makes the whole "outbound" problem immensely easier to deal with. 2) The ability to route to tel:URI target URIs as well as sip: target URIs. 3) The ability to send more than one route in a single request. 4) The ability to express an aggregation policy (prefix/postfix wildcards) in a route. This lets us target a range of phone numbers or all or part of a domain or subdomain with a single URI. 5) The ability to selectively respond from the route-receiving end (the "registrar") about authorization failures among multiple received routes. 6) Optionally, the ability for an upstream routing proxy to add itself o the route set. This could replace Service-Route, Path, and I think most of Outbound. The neat part is that once the basic mechanism is done, this whole line item could be added in another RFC, so it doesn't have to be in the base (we just have to not prevent it). Once its done, I see new installations using this mechanism as a replacement for REGISTER in all cases where there upstream path (former registrar, possibly also a former "outbound" proxy) supports it. The really neat thing about this is that this mechanism can be used in a fully backward compatible way (as far as a UA is concerned) between a proxy/registrar and a "further upstream" routing proxy like a telephony service provider proxy. Where the new mechanism is used all the way to the UA (and in some cases even without it) we also have a 100% solution to the target-URI and target-parameter problems, because we've gotten loose-routing rather than contact-routing on the whole path. It's simple, I think it fixes a large part of what is wrong with SIP, it doesn't require moving to SIP 3.0, and we pretty much know how to do it. And your draft is a pretty good start on getting it done. -- dean From dean.willis@softarmor.com Fri Oct 16 08:34: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 E8B7628C0F9 for ; Fri, 16 Oct 2009 08:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ExIXJENiJuFB for ; Fri, 16 Oct 2009 08:34:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 13D143A69C0 for ; Fri, 16 Oct 2009 08:34:35 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9GFXM7f030288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 10:33:24 -0500 Message-ID: <4AD8923C.1060209@softarmor.com> Date: Fri, 16 Oct 2009 10:33:16 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Shockey References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> <025201ca4df3$9d091410$d71b3c30$@us> In-Reply-To: <025201ca4df3$9d091410$d71b3c30$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, 'Hadriel Kaplan' Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 15:34:36 -0000 Richard Shockey wrote: > NO .. I don't think so. > > This is NOT a DRINKS issue and I cant possibly imagine any scenario where it > would be. This is about SIP Trunking between S-PBX and a SSP. There are > certainly provisioning issues that need to be dealt with but they are not > even orthogonal to the problem at hand. I spent some time talking with Rich yesterday, and we see it a bit differently. I do not see this as not just a SIP trunking problem. I see it entirely as a problem of dynamically associating SIP nodes (proxies and UAs) with a set of destination URIs at the SIP routing level. RFC 3261's REGISTER is one way of handling a subset of these cases. What we're really talking about is a more general mechanism than REGISTER. That said, such an extension mechanism is required in order to make the provisioning envisioned by DRINKS really useful. -- dean From dean.willis@softarmor.com Fri Oct 16 08:43: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 4CE9128C21B for ; Fri, 16 Oct 2009 08:43:29 -0700 (PDT) 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.050, 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 p3XDkLy12foT for ; Fri, 16 Oct 2009 08:43:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 268F028C0F9 for ; Fri, 16 Oct 2009 08:43:28 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9GFhRjv030412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 10:43:29 -0500 Message-ID: <4AD8949A.1080200@softarmor.com> Date: Fri, 16 Oct 2009 10:43:22 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Hadriel Kaplan References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 15:43:29 -0000 Hadriel Kaplan wrote: > Yeah, I can see what you mean, but there really aren't even the 3 > options in Cullen's email. We wanted to get an options-tag because > we thought it was "the right thing to do". ISTM the options-tag > concept was put in place for this kind of circumstance, so that an > extension can be cleanly indicated and an incompatibility > detected/negotiated. And since an options-tag requires a > standards-track, here we are. > > Going the A-D route didn't mean we weren't open to edits/changes of > the document's mechanism - we *want* people's feedback - just that we > don't have time for a WG charter, a requirements doc, fixing > unrelated issues, etc. DISPATCHing the draft to any extant working group eliminates the chartering phase. Or are you saying you also don't have time to fix the mechanism, and it's a case of "publish my extension as a standard or I'll game the process and publish it more-or-less as is some other way" > > But if the consensus is that we can't go the A-D route, then we'll > just go with Option-3: submitting an Informational draft and go the > individual submission path. We'll get rid of the options-tag, and > either just ask for a SIP Header to do something similar, or not even > that. The procss doesn't allow informational drafts to conflict with chartered work. SIPCORE has as a charter item: Jul 2009 Delivering request-URI and parameters to UAS via proxy to IESG (PS) So if we use domain routing as the basis for fixing request URI delivery (as you said, it allows a sidestep of the problem by using loose routing to the end), then this work is clearly in SIPCORE's charter domain. Problem solved: dispatch it to SIPCORE, change the method name (it just isn't REGSITER anymore), and add the bits needed to discuss how it fixes target and parameter delivery, and I hope add the simultaneous registration of other routes and things I mentioned in a separate email. -- dean From HKaplan@acmepacket.com Fri Oct 16 09:18: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 88D653A687D for ; Fri, 16 Oct 2009 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Xqc9M5s03kYU for ; Fri, 16 Oct 2009 09:18:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 66AA528C22E for ; Fri, 16 Oct 2009 09:18:15 -0700 (PDT) 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; Fri, 16 Oct 2009 12:18:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Oct 2009 12:18:16 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 16 Oct 2009 12:18:13 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpOdQWs2h8jW2M0SLqiNS0Iv7RHSwABXbPA Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> In-Reply-To: <4AD89077.10906@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 16:18:32 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 16, 2009 11:26 AM > To: Hadriel Kaplan >=20 > Hadriel Kaplan wrote: > > Well I really didn't mean for it to be disingenuous. (honest) The > > three things you mentioned, for example, do not mean to me the > > REGISTER transaction mechanism is broken whatsoever. They have to do > > with how to route to the entity that Registered, which is after the > > fact. In the Domain Registration mechanism we side-step that whole > > issue, since we're not replacing the request-uri, but are just doing > > loose-routing. > > >=20 > Exactly: the extension you have requires the node using the REGISTERed > contact information to behave differently from how it would do it with > "regular" contacts, yet does not AFAIK give that node a really clear way > to know the difference. Yes there is: the options-tag. Without that, it would just be based on con= figuration; i.e., the SSP Registrar would be provisioned to know that for d= omain "enterprise.com", it uses loose-routing (and the rest of the mechanis= m). =20 > We have no shortage of method namespace, so let's call it something > besides REGISTER. We have no shortage of method namespace, but we also have no shortage of op= tion-tag namespace. There is nothing about a "REGISTER" method name string= that ties it intrinsically with how the routing to the contact/path is per= formed. Nor to which specific local database table its contact/path info i= s stored into. =20 We chose to document a separate logical database in the draft just to make = it crystal clear that its behavior is something different, and to make it p= art of the 3263 lookup process instead of the 3261 AoR resolution lookup pr= ocess. That was done on purpose, because the ownership/authority model for= the AoR's of the Enterprise belong to the Enterprise - vs. belong to the S= SP. And that's the same reason we chose to Register a different Domain Nam= e, rather than do the implicit-registration hack of 3gpp. Thus, it follows= the same model as routing from one domain (the SSP's) to another (the Ente= rprise's). -hadriel From HKaplan@acmepacket.com Fri Oct 16 09:23: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 75DD53A691B for ; Fri, 16 Oct 2009 09:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 0zrPGp0izABm for ; Fri, 16 Oct 2009 09:23:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8E1B93A68C1 for ; Fri, 16 Oct 2009 09:23:55 -0700 (PDT) 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; Fri, 16 Oct 2009 12:23:58 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Oct 2009 12:23:56 -0400 From: Hadriel Kaplan To: Dean Willis , Richard Shockey Date: Fri, 16 Oct 2009 12:23:53 -0400 Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpOdgtDdYHzJx0OS2uoYFbWPbIHMwABldVw Message-ID: References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> <025201ca4df3$9d091410$d71b3c30$@us> <4AD8923C.1060209@softarmor.com> In-Reply-To: <4AD8923C.1060209@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 16:23:56 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 16, 2009 11:33 AM > To: Richard Shockey >=20 > I see it entirely as a problem of dynamically associating SIP nodes > (proxies and UAs) with a set of destination URIs at the SIP routing > level. RFC 3261's REGISTER is one way of handling a subset of these > cases. What we're really talking about is a more general mechanism than > REGISTER. >=20 > That said, such an extension mechanism is required in order to make the > provisioning envisioned by DRINKS really useful. Yes, I agree - in the long run. For example it could be something for a ne= w package to be done using PUBLISH or SUB/NOT, which would contain routes a= nd destinations and so on. But that's a much bigger work item than what we= need for the IP-PBX space, and we need it right now. It will take at leas= t 3-4 years to get something like what you're talking about done. We don't= have that kind of time for SIP Trunking. We're trying to get SIP Connect = 1.1 published in Q1-2010. -hadriel From HKaplan@acmepacket.com Fri Oct 16 09:44: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 F27B73A689C for ; Fri, 16 Oct 2009 09:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 4MqQtq69GuAs for ; Fri, 16 Oct 2009 09:44:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0B6CE3A683C for ; Fri, 16 Oct 2009 09:44:12 -0700 (PDT) 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; Fri, 16 Oct 2009 12:44:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Oct 2009 12:44:16 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 16 Oct 2009 12:44:06 -0400 Thread-Topic: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpOd4DM64GlLNkTRlKr6OwUH6zN7gABY/2w Message-ID: References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> <4AD8949A.1080200@softarmor.com> In-Reply-To: <4AD8949A.1080200@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 16:44:14 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 16, 2009 11:43 AM >=20 >=20 > DISPATCHing the draft to any extant working group eliminates the > chartering phase. It still requires a re-charter/charter-update/whatever-they-call-it for the= WG. > Or are you saying you also don't have time to fix the mechanism, and > it's a case of "publish my extension as a standard or I'll game the > process and publish it more-or-less as is some other way" No, it's not - I'm looking for constructive criticism to help improve it an= d get it published. But I/we need it to happen quickly. The history of th= is is such that we (in SIP-Connect) were not really intending to have to pu= blish an IETF draft to begin with. We were just going to do something simi= lar to 3GPP, and I wrote that original model up in draft-kaplan-dispatch-si= p-implicit-registrations-00, as an Informational "FYI" so to speak. But af= ter some more discussion in SIP Forum, we agreed to try to do what we thoug= ht would be a more general mechanism in a cleaner way, and that also led us= to decide to ask for an option-tag, which turned this thing into a standar= ds-track doc. It's not a "game the process" - I'm trying the process. > The procss doesn't allow informational drafts to conflict with chartered > work. > SIPCORE has as a charter item: > Jul 2009 Delivering request-URI and parameters to UAS via proxy to IESG > (PS) The Domain Registration mechanism does not resolve that problem. It's not = being used for the case that the problem exists: aor-resolution/routing. D= omain Registration is just a means of populating a local table for use in i= nter-domain routing, which is looked up prior to DNS - nothing to do with a= or-resolution/routing. > So if we use domain routing as the basis for fixing request URI delivery > (as you said, it allows a sidestep of the problem by using loose routing > to the end), then this work is clearly in SIPCORE's charter domain. The fact that Domain Registration uses loose-routing to sidestep the AoR-re= solution problem, doesn't mean that any future effort to fix the AoR-resolu= tion problem would conflict with Domain Registration. They are completely = orthogonal. The Domain Registration mechanism doesn't have the problem to = begin with. It uses an already existent solution to get around it: loose-r= outing, for a different scenario. -hadriel From pkyzivat@cisco.com Fri Oct 16 09:45: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 EF71628C0FE for ; Fri, 16 Oct 2009 09:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 969s5vmwRvFX for ; Fri, 16 Oct 2009 09:45:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9D7B73A689C for ; Fri, 16 Oct 2009 09:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3463; q=dns/txt; s=rtpiport02001; t=1255711518; x=1256921118; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Domain=20Registration=09Draft=20dra ft-kaplan-dispatch-domain-registration|Date:=20Fri,=2016 =20Oct=202009=2012:45:16=20-0400|Message-ID:=20<4AD8A31C. 6080504@cisco.com>|To:=20Hadriel=20Kaplan=20|CC:=20Dean=20Willis=20,=0D=0A=20=20=20=20=20=20=20=20"dispatch@ietf.org"=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20 <22A4515E-F613-49F3-8079-1142FB390113@cisco.com>=09<4AD62 824.4030704@softarmor.com>=09=09=09=09<4AD89077.10906@softarmor.com>=20; bh=3MuIOvK42CF6FPUPghNre7rlDG6Y5faq7dNOsL6uAgs=; b=fRr4Cj5jXdgZsW49N7AD5vDWtrvt/rQA0qv1JfEf1M1ug2L4KXlQx2Wq 9HX9EKrcvdxttD9tW9KnFi1dQ2AF0hlzbCYUWZxpGbAWQlbDc8l32kynQ x1S/W9qLomyqq4mx8N0hUWbq12DsUcbmVdslBpIuaGwJzE5yQ0mtLenEI 4=; 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: ApoEAD5A2EpAZnwM/2dsb2JhbADBFpgihDAE X-IronPort-AV: E=Sophos;i="4.44,574,1249257600"; d="scan'208";a="63459499" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Oct 2009 16:45:17 +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 n9GGjHgl008239; Fri, 16 Oct 2009 16:45:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 12:45:17 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 12:45:16 -0400 Message-ID: <4AD8A31C.6080504@cisco.com> Date: Fri, 16 Oct 2009 12:45:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hadriel Kaplan References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 16:45:16.0890 (UTC) FILETIME=[0A4A43A0:01CA4E80] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 16:45:15 -0000 I think there is a little more to the "use an option, or not" discussion: If you use an optional header, or just provisioning, rather than an option, then the registrar is bound to handle the REGISTER in a manner compliant with 3261. That means it must allow multiple contacts, update the location service, return all the registered contacts present in the location service, etc. It can *in addition* do other behavior that is optional based on whether or not it has the provisioning and/or understands the header. When it comes to routing of subsequent requests, it is again to be compliant with 3261. But there you have more wiggle room because 3261 gives broad latitude to a proxy about how to make its routing decisions. So if you choose to maintain this extra table, and check it first, before looking at the location service, then I think you can still be compliant. With an option tag, I *think* you can alter the basic behavior of the REGISTER. Whether that is good in this case is debatable. (As it is now being debated.) Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, October 16, 2009 11:26 AM >> To: Hadriel Kaplan >> >> Hadriel Kaplan wrote: >>> Well I really didn't mean for it to be disingenuous. (honest) The >>> three things you mentioned, for example, do not mean to me the >>> REGISTER transaction mechanism is broken whatsoever. They have to do >>> with how to route to the entity that Registered, which is after the >>> fact. In the Domain Registration mechanism we side-step that whole >>> issue, since we're not replacing the request-uri, but are just doing >>> loose-routing. >>> >> Exactly: the extension you have requires the node using the REGISTERed >> contact information to behave differently from how it would do it with >> "regular" contacts, yet does not AFAIK give that node a really clear way >> to know the difference. > > Yes there is: the options-tag. Without that, it would just be based on configuration; i.e., the SSP Registrar would be provisioned to know that for domain "enterprise.com", it uses loose-routing (and the rest of the mechanism). > > >> We have no shortage of method namespace, so let's call it something >> besides REGISTER. > > We have no shortage of method namespace, but we also have no shortage of option-tag namespace. There is nothing about a "REGISTER" method name string that ties it intrinsically with how the routing to the contact/path is performed. Nor to which specific local database table its contact/path info is stored into. > > We chose to document a separate logical database in the draft just to make it crystal clear that its behavior is something different, and to make it part of the 3263 lookup process instead of the 3261 AoR resolution lookup process. That was done on purpose, because the ownership/authority model for the AoR's of the Enterprise belong to the Enterprise - vs. belong to the SSP. And that's the same reason we chose to Register a different Domain Name, rather than do the implicit-registration hack of 3gpp. Thus, it follows the same model as routing from one domain (the SSP's) to another (the Enterprise's). > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From richard@shockey.us Fri Oct 16 10:07: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 A1AC028C0D8 for ; Fri, 16 Oct 2009 10:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.483, 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 YdzFu-bQ0KEY for ; Fri, 16 Oct 2009 10:07:07 -0700 (PDT) Received: from outbound-mail-158.bluehost.com (outbound-mail-158.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 9C0613A68F5 for ; Fri, 16 Oct 2009 10:07:07 -0700 (PDT) Received: (qmail 1511 invoked by uid 0); 16 Oct 2009 17:07:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 16 Oct 2009 17:07:11 -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=m0m0uhHJ7BVdceuzBJNlaJxCTttaLvAQmEgetUOBPz58Jzx8IdsFQtmARMyPa/GD0o+6EAXw7uoEvo4riDqraO1bqDxcW5a5n+SwkvM/kDNT7W5gBp2DguTX0TJGV6Sv; 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 1MyqGl-0000cO-GA; Fri, 16 Oct 2009 11:07:11 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Dean Willis'" References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> <4AD8949A.1080200@softarmor.com> In-Reply-To: Date: Fri, 16 Oct 2009 13:07:09 -0400 Message-ID: <01bc01ca4e83$193a3d90$4baeb8b0$@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: AcpOd4DM64GlLNkTRlKr6OwUH6zN7gABY/2wAADJL1A= 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 Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 17:07:08 -0000 Dean .. Hadriel is right here, again. Folks must remember that the SIPforum people that were involved in this effort are exactly the same people that generally inhabit this list. The SIPforum is not a SDO however we obviously spend a great deal of time and money trying to make SIP work better. SIPit for instance, is a formal SIPforum sponsored activity. The SIPconnect process is in that same spirit. For over 12 months now almost once a week on calls and several times face to face we have talked this problem out over and over again. Multiple approaches were considered and it was the near unanimous opinion of the participants that bringing this draft forward was " the right thing to do" tm. This technique is in the field NOW and this draft solves known interoperability issues. Should the IETF consider longer term solutions, of course but we are trying to fix a problem today. Furthermore as folks have noted there are substantive business issues here that this draft actually solves. It is specifically addresses issues in the SMB Market where SIPtrunking has started to deploy at ever increasing rates. The service enhancements and reduced costs of SIPtrunking are important here hence the use of the domain registration technique. I'm convinced, as were all of the participants in this process that bringing this draft forward enhances the interoperability of SIP and increases the deployment opportunities for SIPtrunking in the future by orders of magnitude. There is nothing in this discussion so far that makes me alter my belief that A. the draft is the "right thing to do" tm. B. It can and should go forward as AD sponsored. > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Friday, October 16, 2009 11:43 AM > > > > > > DISPATCHing the draft to any extant working group eliminates the > > chartering phase. > > It still requires a re-charter/charter-update/whatever-they-call-it > for the WG. > > > Or are you saying you also don't have time to fix the mechanism, and > > it's a case of "publish my extension as a standard or I'll game the > > process and publish it more-or-less as is some other way" > > No, it's not - I'm looking for constructive criticism to help improve > it and get it published. But I/we need it to happen quickly. The > history of this is such that we (in SIP-Connect) were not really > intending to have to publish an IETF draft to begin with. We were > just going to do something similar to 3GPP, and I wrote that original > model up in draft-kaplan-dispatch-sip-implicit-registrations-00, as an > Informational "FYI" so to speak. But after some more discussion in > SIP Forum, we agreed to try to do what we thought would be a more > general mechanism in a cleaner way, and that also led us to decide to > ask for an option-tag, which turned this thing into a standards-track > doc. It's not a "game the process" - I'm trying the process. > > > > The procss doesn't allow informational drafts to conflict with > chartered > > work. > > SIPCORE has as a charter item: > > Jul 2009 Delivering request-URI and parameters to UAS via proxy to > IESG > > (PS) > > The Domain Registration mechanism does not resolve that problem. It's > not being used for the case that the problem exists: aor- > resolution/routing. Domain Registration is just a means of populating > a local table for use in inter-domain routing, which is looked up > prior to DNS - nothing to do with aor-resolution/routing. > > > > So if we use domain routing as the basis for fixing request URI > delivery > > (as you said, it allows a sidestep of the problem by using loose > routing > > to the end), then this work is clearly in SIPCORE's charter domain. > > The fact that Domain Registration uses loose-routing to sidestep the > AoR-resolution problem, doesn't mean that any future effort to fix the > AoR-resolution problem would conflict with Domain Registration. They > are completely orthogonal. The Domain Registration mechanism doesn't > have the problem to begin with. It uses an already existent solution > to get around it: loose-routing, for a different scenario. > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ben@nostrum.com Fri Oct 16 11:29: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 32CC73A67D8 for ; Fri, 16 Oct 2009 11:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 MSSh3ND+fu6I for ; Fri, 16 Oct 2009 11:29:20 -0700 (PDT) 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 23BAA3A6929 for ; Fri, 16 Oct 2009 11:29:19 -0700 (PDT) Received: from dn3-109.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9GIT89H075403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Oct 2009 13:29:15 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: <4AD7AA3D.8070108@cisco.com> Date: Fri, 16 Oct 2009 13:29:06 -0500 Content-Transfer-Encoding: 7bit Message-Id: <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> References: <4AD7AA3D.8070108@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration 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, 16 Oct 2009 18:29:21 -0000 On Oct 15, 2009, at 6:03 PM, Paul Kyzivat wrote: > I think this thread had substantiated that there *is* some > controversy. > +1 We're already seeing a fair bit of technical discussion and give-and- take about the draft. That discussion belongs in a work group, even if you _don't_ include Dean's wish to fix REGISTER in general as part of the scope. If it were not for the time pressure, I think we would see lots of complaints that the draft went too quickly from requirements to mechanism. IMO, external time pressure is the _worst_ reason to circumvent DISPATCH on a draft. From HKaplan@acmepacket.com Fri Oct 16 14:03: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 B07D83A6817 for ; Fri, 16 Oct 2009 14:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 pCCb74A0W-mr for ; Fri, 16 Oct 2009 14:03:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B2D5E3A67A2 for ; Fri, 16 Oct 2009 14:03:02 -0700 (PDT) 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; Fri, 16 Oct 2009 17:03:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Oct 2009 17:03:03 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 16 Oct 2009 17:03:02 -0400 Thread-Topic: domain-registration to DRINKS (was: DomainRegistration Draft draft-kaplan-dispatch-domain-registration) Thread-Index: AcpOd4DM64GlLNkTRlKr6OwUH6zN7gALEOjg Message-ID: References: <4AD7AA3D.8070108@cisco.com> <4AD7B30C.8080106@neustar.biz> <4AD8949A.1080200@softarmor.com> In-Reply-To: <4AD8949A.1080200@softarmor.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 Cc: "dispatch@ietf.org" Subject: [dispatch] domain-registration to DRINKS (was: DomainRegistration Draft draft-kaplan-dispatch-domain-registration) 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, 16 Oct 2009 21:03:03 -0000 Thinking about this some more, seems to me Jon's right (as usual) that disp= atching this to DRINKS does kinda make sense - and rechartering ain't that = bad. :) So can we get a consensus call to DISPATCH it to DRINKS? -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 16, 2009 11:43 AM > To: Hadriel Kaplan > Cc: Jon Peterson; Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch- > domain-registration >=20 > Hadriel Kaplan wrote: > > Yeah, I can see what you mean, but there really aren't even the 3 > > options in Cullen's email. We wanted to get an options-tag because > > we thought it was "the right thing to do". ISTM the options-tag > > concept was put in place for this kind of circumstance, so that an > > extension can be cleanly indicated and an incompatibility > > detected/negotiated. And since an options-tag requires a > > standards-track, here we are. > > > > Going the A-D route didn't mean we weren't open to edits/changes of > > the document's mechanism - we *want* people's feedback - just that we > > don't have time for a WG charter, a requirements doc, fixing > > unrelated issues, etc. >=20 > DISPATCHing the draft to any extant working group eliminates the > chartering phase. >=20 > Or are you saying you also don't have time to fix the mechanism, and > it's a case of "publish my extension as a standard or I'll game the > process and publish it more-or-less as is some other way" >=20 > > > > But if the consensus is that we can't go the A-D route, then we'll > > just go with Option-3: submitting an Informational draft and go the > > individual submission path. We'll get rid of the options-tag, and > > either just ask for a SIP Header to do something similar, or not even > > that. >=20 > The procss doesn't allow informational drafts to conflict with chartered > work. >=20 > SIPCORE has as a charter item: >=20 > Jul 2009 Delivering request-URI and parameters to UAS via proxy to IESG > (PS) >=20 > So if we use domain routing as the basis for fixing request URI delivery > (as you said, it allows a sidestep of the problem by using loose routing > to the end), then this work is clearly in SIPCORE's charter domain. >=20 > Problem solved: dispatch it to SIPCORE, change the method name (it just > isn't REGSITER anymore), and add the bits needed to discuss how it fixes > target and parameter delivery, and I hope add the simultaneous > registration of other routes and things I mentioned in a separate email. >=20 > -- > dean From spencer@wonderhamster.org Fri Oct 16 21:51: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 3D67D3A67D9 for ; Fri, 16 Oct 2009 21:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 yaeKBFtEgzTw for ; Fri, 16 Oct 2009 21:51:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 485CD3A67A1 for ; Fri, 16 Oct 2009 21:51:58 -0700 (PDT) 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 0MQPjQ-1Mp4ZA2Ig8-00USlG; Sat, 17 Oct 2009 00:51:33 -0400 Message-ID: <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> From: "Spencer Dawkins" To: "Ben Campbell" , "Paul Kyzivat" References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> Date: Fri, 16 Oct 2009 23:51:24 -0500 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+7quXv79/hT+NkI/mTgaenSpCgbVDC+7nIvV1 zSKcEqfbCr1VWfH54fGapAGXaImoBbVWRxlfs2XKA3jOIQY/FM 8LiRIK9NSNAg6I1ZrVdHvyk4uoszk4r0G2tWVRifCE= Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 04:51:59 -0000 ----- Original Message ----- From: "Ben Campbell" To: "Paul Kyzivat" Cc: ; "Hadriel Kaplan" Sent: Friday, October 16, 2009 1:29 PM Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration > On Oct 15, 2009, at 6:03 PM, Paul Kyzivat wrote: > >> I think this thread had substantiated that there *is* some controversy. >> > > +1 > > We're already seeing a fair bit of technical discussion and give-and- take > about the draft. That discussion belongs in a work group, even if you > _don't_ include Dean's wish to fix REGISTER in general as part of the > scope. > > If it were not for the time pressure, I think we would see lots of > complaints that the draft went too quickly from requirements to > mechanism. IMO, external time pressure is the _worst_ reason to > circumvent DISPATCH on a draft. Hi, Ben, I may have misunderstood what you were saying, but if you're thinking that Hadriel is trying to circumvent DISPATCH, that's not how we got here. We were pretty far down the garden path with Cullen on asking him to AD-sponsor an Informational draft that defined a SIP header field that identified a domain registration, but we convinced ourselves that this really should be a SIP option tag, because we wanted the property that a registering SIP-PBX could cause a domain registration to fail (if that was the right answer) by Requiring a SIP option tag - with an unknown SIP header field, the service provider SIP proxy would just ignore it, and the SIP-PBX couldn't detect that "the REGISTER succeeded, but the domain wasn't registered". So we agreed (and agreed with Cullen) that this draft should specify a SIP option tag, even though this required a standards-track specification (the header field did not), and even though Cullen said he was not willing to AD-sponsor a standards-track specification without input from DISPATCH. We made the decision (in discussions with Cullen) to go to DISPATCH, which is the opposite of circumventing DISPATCH. I guess I should add one observation that I've been making privately. We're looking at deployed, undocumented, and inconsistent SIP-PBX behavior with SIP REGISTERs that carry no indication that something magic is happening behind the scenes. I see Hadriel's draft as an effort to "housebreak" this behavior, so that network operators, middleboxes, etc. at least get some clue that This Is Not Your Parent's REGISTER Operation, just by looking at a packet trace with WireShark. They can't know that today. That's why I supported it, when Cullen asked for input earlier this week. My experience with "housebreaking" pets and small children has been that the resulting behavior isn't perfect, but there is a lot less "waste" on the carpet after housebreaking - and that seemed like sufficient reason to housebreak pets and small children. That's kind of how I'm seeing domain registration - as an improvement. So I guess people can pop Hadriel across the muzzle with a rolled-up newspaper, but this still seems like the right thing to do, IMO. :-) Thanks, Spencer From HKaplan@acmepacket.com Sat Oct 17 06:31: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 819EE3A68B8 for ; Sat, 17 Oct 2009 06:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 AWQEmWiZP1R8 for ; Sat, 17 Oct 2009 06:31:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8036D3A6837 for ; Sat, 17 Oct 2009 06:31:54 -0700 (PDT) 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; Sat, 17 Oct 2009 09:31:58 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Oct 2009 09:31:58 -0400 From: Hadriel Kaplan To: Dean Willis Date: Sat, 17 Oct 2009 09:31:52 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpO8j7sV5TJsUM0QWuUSw5+dwDQEwAOniAQ Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> <1255760525.15650.4.camel@ubuntu.ubuntu-domain> In-Reply-To: <1255760525.15650.4.camel@ubuntu.ubuntu-domain> 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: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 13:31:55 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@sofarmor.com] > Sent: Saturday, October 17, 2009 2:22 AM > To: Hadriel Kaplan >=20 > > Yes there is: the options-tag. Without that, it would just be based on > configuration; i.e., the SSP Registrar would be provisioned to know that > for domain "enterprise.com", it uses loose-routing (and the rest of the > mechanism). >=20 > I think you misunderstand the OPTIONS tag. It's presence in Supported: > says the sender of the request supports the extension. In Require:, it > requires the receiver to support the extension. It NEVER says "I am > using this extension for this specific request". There needs to be > something "different" about the contact (or other parts of the request) > itself so that the registrar can handle it differently. While that may have been the semantic intention of that header field, some = option-tags clearly mean more than that - they mean "you must use this exte= nsion for this request". For example, rfc3262 100rel has that meaning: The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel. Ergo, it does not just mean "you gotta support the reliable response concep= t to accept this request", but rather "you gotta USE reliable responses for= this transaction to accept this request". You're right that the current Domain Registration draft doesn't say that as= explicitly as rfc3262 did, so I gotta go fix that - but that was the inten= tion... do what I mean not what I say ;) -hadriel=20 From ben@nostrum.com Sat Oct 17 08:07: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 8B6993A6827 for ; Sat, 17 Oct 2009 08:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 CoGIUE3+KC5Q for ; Sat, 17 Oct 2009 08:07:31 -0700 (PDT) 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 491CD3A680F for ; Sat, 17 Oct 2009 08:07:31 -0700 (PDT) Received: from [10.0.1.8] (adsl-68-94-15-159.dsl.rcsntx.swbell.net [68.94.15.159]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9HF7VcA070520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Oct 2009 10:07:32 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell X-Priority: 3 In-Reply-To: <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> Date: Sat, 17 Oct 2009 10:07:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 68.94.15.159 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 15:07:32 -0000 On Oct 16, 2009, at 11:51 PM, Spencer Dawkins wrote: > > ----- Original Message ----- From: "Ben Campbell" > To: "Paul Kyzivat" > Cc: ; "Hadriel Kaplan" > Sent: Friday, October 16, 2009 1:29 PM > Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch- > domain-registration > > >> On Oct 15, 2009, at 6:03 PM, Paul Kyzivat wrote: >> >>> I think this thread had substantiated that there *is* some >>> controversy. >>> >> >> +1 >> >> We're already seeing a fair bit of technical discussion and give- >> and- take about the draft. That discussion belongs in a work group, >> even if you _don't_ include Dean's wish to fix REGISTER in general >> as part of the scope. >> >> If it were not for the time pressure, I think we would see lots of >> complaints that the draft went too quickly from requirements to >> mechanism. IMO, external time pressure is the _worst_ reason to >> circumvent DISPATCH on a draft. > > Hi, Ben, > > I may have misunderstood what you were saying, but if you're > thinking that Hadriel is trying to circumvent DISPATCH, that's not > how we got here. Apologies--that was a bad word choice on my part. I understand that _this_ discussion is occurring on DISPATCH. I meant to refer to "being DISPATCHed to a work group" > > We were pretty far down the garden path with Cullen on asking him to > AD-sponsor an Informational draft that defined a SIP header field > that identified a domain registration, but we convinced ourselves > that this really should be a SIP option tag, because we wanted the > property that a registering SIP-PBX could cause a domain > registration to fail (if that was the right answer) by Requiring a > SIP option tag - with an unknown SIP header field, the service > provider SIP proxy would just ignore it, and the SIP-PBX couldn't > detect that "the REGISTER succeeded, but the domain wasn't > registered". > > So we agreed (and agreed with Cullen) that this draft should specify > a SIP option tag, even though this required a standards-track > specification (the header field did not), and even though Cullen > said he was not willing to AD-sponsor a standards-track > specification without input from DISPATCH. > > We made the decision (in discussions with Cullen) to go to DISPATCH, > which is the opposite of circumventing DISPATCH. > > I guess I should add one observation that I've been making > privately. We're looking at deployed, undocumented, and inconsistent > SIP-PBX behavior with SIP REGISTERs that carry no indication that > something magic is happening behind the scenes. I see Hadriel's > draft as an effort to "housebreak" this behavior, so that network > operators, middleboxes, etc. at least get some clue that This Is Not > Your Parent's REGISTER Operation, just by looking at a packet trace > with WireShark. They can't know that today. That's why I supported > it, when Cullen asked for input earlier this week. > > My experience with "housebreaking" pets and small children has been > that the resulting behavior isn't perfect, but there is a lot less > "waste" on the carpet after housebreaking - and that seemed like > sufficient reason to housebreak pets and small children. That's kind > of how I'm seeing domain registration - as an improvement. > > So I guess people can pop Hadriel across the muzzle with a rolled-up > newspaper, but this still seems like the right thing to do, IMO. > > :-) > > Thanks, > > Spencer From dean.willis@softarmor.com Sat Oct 17 08:09: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 3BF6A3A6827 for ; Sat, 17 Oct 2009 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 JPghb-iuV9pi for ; Sat, 17 Oct 2009 08:09:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6E7643A680F for ; Sat, 17 Oct 2009 08:09:03 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9HF94uh006706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Oct 2009 10:09:05 -0500 Message-ID: <4AD9DE0B.90800@softarmor.com> Date: Sat, 17 Oct 2009 10:08:59 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Hadriel Kaplan References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> <1255760525.15650.4.camel@ubuntu.ubuntu-domain> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Dean Willis Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 15:09:04 -0000 Hadriel Kaplan wrote: . For example, rfc3262 100rel > has that meaning: > > The UAS MUST send any non-100 provisional response reliably if the > initial request contained a Require header field with the option tag > 100rel. If the UAS is unwilling to do so, it MUST reject the initial > request with a 420 (Bad Extension) and include an Unsupported header > field containing the option tag 100rel. > > Ergo, it does not just mean "you gotta support the reliable response > concept to accept this request", but rather "you gotta USE reliable > responses for this transaction to accept this request". 3262 is badly, badly worded. Please don't use it as "the rule". The intent is that if the UAS is aware that the UAC supports 100rel, and the UAS supports 100rel, then the UAS will use 100rel. This is probably worth filing an errata on 3262. If the UAS supports 100rel, it should use it if the UAC indicated support for it in the request. The support should have been indicated in Supported. The difference is that if it is Require, then the UAS MUST reject the request if it does not support the extension, whereas if it is only in Supported, then the UAS may, if it does not support 100rel, respond non-reliably. -- Dean From dean.willis@softarmor.com Sat Oct 17 08:17: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 327573A6827 for ; Sat, 17 Oct 2009 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 8cO38Q9hQR6O for ; Sat, 17 Oct 2009 08:17:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 52DEE3A680F for ; Sat, 17 Oct 2009 08:17:16 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9HFHIeQ006784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Oct 2009 10:17:20 -0500 Message-ID: <4AD9DFF9.5060303@softarmor.com> Date: Sat, 17 Oct 2009 10:17:13 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Ben Campbell References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> In-Reply-To: <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 15:17:17 -0000 Ben Campbell wrote: >> I may have misunderstood what you were saying, but if you're thinking >> that Hadriel is trying to circumvent DISPATCH, that's not how we got >> here. > > Apologies--that was a bad word choice on my part. I understand that > _this_ discussion is occurring on DISPATCH. I meant to refer to "being > DISPATCHed to a work group" It's not just a matter of being DISPATCHed to a working group; it's a matter of being DISPATCHed to a working group that can process the task effectively. This requires that the draft be within the scope of the charter for the WG, and that the WG have effective change control over the draft, and that the IETF community as a whole be able to review the draft as it progresses. Remember, we pushed really hard on Phil Zimmermann about change control on his ZRTP draft. Could the IETF process change it if it needs changing? Since the answer seemed to be "no" (or at least in part because), we picked a different baseline document. We have to ask the same questions of anything coming in: What are you REALLY trying to solve? Is the proposed solution a effective way to solve it? Will you let us adapt the solution to make it as effective as reasonably possible within the IETF process? So far, with this draft, it looks like the authors have only the "tail of the tiger"; they haven't realized that the problem they're trying to solve is a sizable subset of a more geeral problem that we're close to solving. And they seem to be insisting that outside of minor word-smithing and editing-to-standard-form that the document is sacrosact and the proposed mechanism not alterable by the IETF. If it were anybody else, we'd refuse to engage under those terms. Should we be consistent? in our relationships with other organizations? -- Dean From HKaplan@acmepacket.com Sat Oct 17 08:20: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 2B7023A68AE for ; Sat, 17 Oct 2009 08:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 BcjCRMSnMQF9 for ; Sat, 17 Oct 2009 08:20:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 39AF33A6827 for ; Sat, 17 Oct 2009 08:20:28 -0700 (PDT) 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; Sat, 17 Oct 2009 11:20:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Oct 2009 11:20:29 -0400 From: Hadriel Kaplan To: Dean Willis Date: Sat, 17 Oct 2009 11:20:28 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpPO8j1qVxULuKBRuyNR0MyjwnEfAAAKLpQ Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> <1255760525.15650.4.camel@ubuntu.ubuntu-domain> <4AD9DE0B.90800@softarmor.com> In-Reply-To: <4AD9DE0B.90800@softarmor.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 Cc: "dispatch@ietf.org" , Dean Willis Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 15:20:29 -0000 Too late methinks - there are already devices out there that will fail the = transaction if the UAS does not actively use reliable responses for the INV= ITE request. (ie, they demand PRACK) I hate it myself, and think they're n= uts to prefer actually failing calls instead, but they're deployed. Regardless, if you'd prefer, we can add a uri-param to the To-URI to indica= te "this is a Domain being registered, not an AoR" and then the option-tag = would require support to understand that param. Acceptable? -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, October 17, 2009 11:09 AM > To: Hadriel Kaplan > Cc: Dean Willis; dispatch@ietf.org; Robert Sparks; Richard Shockey; Culle= n > Jennings; jon.peterson@neustar.biz > Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch- > domain-registration >=20 > Hadriel Kaplan wrote: > . For example, rfc3262 100rel > > has that meaning: > > > > The UAS MUST send any non-100 provisional response reliably if the > > initial request contained a Require header field with the option tag > > 100rel. If the UAS is unwilling to do so, it MUST reject the initial > > request with a 420 (Bad Extension) and include an Unsupported header > > field containing the option tag 100rel. > > > > Ergo, it does not just mean "you gotta support the reliable response > > concept to accept this request", but rather "you gotta USE reliable > > responses for this transaction to accept this request". >=20 > 3262 is badly, badly worded. Please don't use it as "the rule". >=20 > The intent is that if the UAS is aware that the UAC supports 100rel, and > the UAS supports 100rel, then the UAS will use 100rel. >=20 > This is probably worth filing an errata on 3262. If the UAS supports > 100rel, it should use it if the UAC indicated support for it in the > request. The support should have been indicated in Supported. The > difference is that if it is Require, then the UAS MUST reject the > request if it does not support the extension, whereas if it is only in > Supported, then the UAS may, if it does not support 100rel, respond > non-reliably. >=20 > -- > Dean From HKaplan@acmepacket.com Sat Oct 17 08: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 234D33A6934 for ; Sat, 17 Oct 2009 08:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 BegdIH8yQt+T for ; Sat, 17 Oct 2009 08:39:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 38A753A68DA for ; Sat, 17 Oct 2009 08:39:59 -0700 (PDT) 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; Sat, 17 Oct 2009 11:40:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Oct 2009 11:40:00 -0400 From: Hadriel Kaplan To: Dean Willis , Ben Campbell Date: Sat, 17 Oct 2009 11:39:53 -0400 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpPPPQp5eaWLM/xRPyRT8RatwPd2gAATglw Message-ID: References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> In-Reply-To: <4AD9DFF9.5060303@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 15:40:00 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, October 17, 2009 11:17 AM > To: Ben Campbell >=20 > It's not just a matter of being DISPATCHed to a working group; it's a > matter of being DISPATCHed to a working group that can process the task > effectively. This requires that the draft be within the scope of the > charter for the WG, and that the WG have effective change control over > the draft, and that the IETF community as a whole be able to review the > draft as it progresses. It was never my intention to avoid community review nor subvert change cont= rol. I was under the impression that even being "A-D sponsored" it would s= till be debatable/editable, go through a WGLC period, and through IESG proc= essing. No? The piece that would be "avoided" would be creating a WG, pas= sing its charter, going through a separate requirements stage if any, selec= ting an I-D to become a WG doc, etc. Certainly it assumes the proposed sol= ution is close to the final one, which you and two other people disagree wi= th. If we dispatch it to DRINKS, then I think that bypasses some of the extra d= elay and is a good compromise. Do you concur? =20 > So far, with this draft, it looks like the authors have only the "tail > of the tiger"; they haven't realized that the problem they're trying to > solve is a sizable subset of a more geeral problem that we're close to > solving. And they seem to be insisting that outside of minor > word-smithing and editing-to-standard-form that the document is > sacrosact and the proposed mechanism not alterable by the IETF.=20 No, that's not what I or anyone has said, afaik. What we've said is we don= 't have much time. Because of that, if the consensus is that the solution = we propose is not close to acceptable as a standards-track document in a wa= y which lets us publish it in short time, then we will go to plan B and cha= nge it to be a Individual-submission informational doc. To put it in your = analogy with Phil Zimmerman's draft, he had the choice of going the Individ= ual path instead. -hadriel From dean.willis@softarmor.com Sat Oct 17 08:54: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 348033A695A for ; Sat, 17 Oct 2009 08:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 gqE5JSiHhje5 for ; Sat, 17 Oct 2009 08:54:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 80DC33A6827 for ; Sat, 17 Oct 2009 08:54:51 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9HFsstq007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Oct 2009 10:54:55 -0500 Message-ID: <4AD9E8C8.10506@softarmor.com> Date: Sat, 17 Oct 2009 10:54:48 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Spencer Dawkins References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> In-Reply-To: <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 15:54:52 -0000 On Fri, 2009-10-16 at 23:51 -0500, Spencer Dawkins wrote: > I see Hadriel's draft as an effort to "housebreak" this > behavior, so that network operators, middleboxes, etc. at least get some > clue that This Is Not Your Parent's REGISTER Operation, just by looking at a > packet trace with WireShark. They can't know that today. Then why should we call it REGISTER? Wouldn't it be better to use a different request method name? -- Dean From audet.francois@gmail.com Sat Oct 17 09:04: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 6F22B3A695E for ; Sat, 17 Oct 2009 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 MFFDteDQk+jp for ; Sat, 17 Oct 2009 09:04:26 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 6A03A3A695A for ; Sat, 17 Oct 2009 09:04:26 -0700 (PDT) Received: by fxm18 with SMTP id 18so3492870fxm.37 for ; Sat, 17 Oct 2009 09:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=PSs7HqeEL1Osd2HYmLnmL1GjGrtH6sLtmdT/h3xvr2E=; b=jye53nCp7CePbVx56Hp3Kttc93JJFgkCKcfE00IBCrYCSmBVg2w9rj9J4iyWx9hqoB 4mzARPs6q0AJhFc5MBYUxwfbZ0UNt8Xz/r0nQ42yHtpY3p/zza0uiT/UENVXyF66atWc l3SQCnby7ewhasLy19qsVFs4JMnFkQutEQLCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=k1+/UsyRAnNzmh/RbCr1lh0wGuNZjW33l9TyxYj6P6AoGg6F99hjscCPOWq1xB9V4L m8xAN8n8CHHhFI8aOA3w9jVMCXU5hPG1mHLQ+3zRGf8jrZBF7/gpCslHQdBukA1jDOnZ SAIdgeQKfLto8aOxy1J8x0Dnzu7KPYPSIYUR0= Received: by 10.102.13.21 with SMTP id 21mr1269149mum.100.1255795467229; Sat, 17 Oct 2009 09:04:27 -0700 (PDT) Received: from ?192.168.15.100? (adsl-76-195-0-45.dsl.pltn13.sbcglobal.net [76.195.0.45]) by mx.google.com with ESMTPS id u26sm2566638mug.32.2009.10.17.09.04.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Oct 2009 09:04:26 -0700 (PDT) Message-Id: <8C8A23FF-CFA2-48B0-9CAE-AF95E0B61389@gmail.com> From: =?ISO-8859-1?Q?Fran=E7ois_AUDET?= To: Dean Willis In-Reply-To: <4AD9E8C8.10506@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 09:04:21 -0700 References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <4AD9E8C8.10506@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:04:27 -0000 Because it is widely deployed that way, and nobody is going to change their implementation drastically as it works fine today. On Oct 17, 2009, at 08:54 , Dean Willis wrote: > On Fri, 2009-10-16 at 23:51 -0500, Spencer Dawkins wrote: >> I see Hadriel's draft as an effort to "housebreak" this >> behavior, so that network operators, middleboxes, etc. at least get >> some >> clue that This Is Not Your Parent's REGISTER Operation, just by > looking at a >> packet trace with WireShark. They can't know that today. > > Then why should we call it REGISTER? Wouldn't it be better to use a > different request method name? > > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Sat Oct 17 09:05: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 ECECC3A68EA for ; Sat, 17 Oct 2009 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 tOb2lrcaKgbk for ; Sat, 17 Oct 2009 09:05:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 394B23A6859 for ; Sat, 17 Oct 2009 09:05:15 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9HG4pBD007194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Oct 2009 11:04:52 -0500 Message-ID: <4AD9EB1D.5090208@softarmor.com> Date: Sat, 17 Oct 2009 11:04:45 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Hadriel Kaplan References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> <1255760525.15650.4.camel@ubuntu.ubuntu-domain> <4AD9DE0B.90800@softarmor.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Dean Willis Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:05:16 -0000 Hadriel Kaplan wrote: > > Regardless, if you'd prefer, we can add a uri-param to the To-URI to > indicate "this is a Domain being registered, not an AoR" and then the > option-tag would require support to understand that param. > Acceptable? That would be better. The real question is what happens when a domain-registration request that is not marked with a Require for the option lands at a registrar that does not understand the extension. Will the non-domain registrar try to execute the REGISTER? What happens when it does? While you could say "If you are doing domain-registration, you must Require the option tag for this feature in every domain-registering request", this is inconsistent with the way we've traditionally used Require. It would be better yet to use something besides REGISTER as the request method name, or to put the registered routes into something that is not Contact and put only "safe" values in Contact. Or both -- this absolutely prevents the uncertainty condition. -- Dean From dean.willis@softarmor.com Sat Oct 17 09:08: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 1BED73A68EA for ; Sat, 17 Oct 2009 09:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 sgkDbuvz7Bxc for ; Sat, 17 Oct 2009 09:08:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 297583A6983 for ; Sat, 17 Oct 2009 09:08:30 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9HG8Wqg007229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Oct 2009 11:08:34 -0500 Message-ID: <4AD9EBFB.7070101@softarmor.com> Date: Sat, 17 Oct 2009 11:08:27 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Hadriel Kaplan References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:08:31 -0000 Hadriel Kaplan wrote: > If we dispatch it to DRINKS, then I think that bypasses some of the > extra delay and is a good compromise. Do you concur? That's true for any WG that it can fit into the charter of, including DRINKS and SIPCORE. I think you've got a hold of an absolutely critical, core piece of SIP functionality. You're either revising or replacing one of the fundamental SIP methods, dating to before RFC 2543. That says SIPCORE to me. > No, that's not what I or anyone has said, afaik. What we've said is > we don't have much time. Because of that, if the consensus is that > the solution we propose is not close to acceptable as a > standards-track document in a way which lets us publish it in short > time, then we will go to plan B and change it to be a > Individual-submission informational doc. To put it in your analogy > with Phil Zimmerman's draft, he had the choice of going the > Individual path instead. I believe that the same objections that might prevent you from making a "standards track" solution would also keep you from making an informational solution. You might not notice, but we've held even the info track documents to a high level of review. -- Dean From dean.willis@softarmor.com Sat Oct 17 09:12: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 B0E733A695A for ; Sat, 17 Oct 2009 09:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 2M5gfhGRHtNc for ; Sat, 17 Oct 2009 09:12:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 150363A6930 for ; Sat, 17 Oct 2009 09:12:15 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9HGCHA7007272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Oct 2009 11:12:19 -0500 Message-ID: <4AD9ECDC.1030502@softarmor.com> Date: Sat, 17 Oct 2009 11:12:12 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Fran=E7ois_AUDET?= References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <4AD9E8C8.10506@softarmor.com> <8C8A23FF-CFA2-48B0-9CAE-AF95E0B61389@gmail.com> In-Reply-To: <8C8A23FF-CFA2-48B0-9CAE-AF95E0B61389@gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:12:15 -0000 François AUDET wrote: > Because it is widely deployed that way, and nobody is going to change > their implementation drastically as it works fine today. >From a standards perspective, that's a really weak answer. If it's already widely deployed and works just fine, why should we standardize it? -- Dean From audet.francois@gmail.com Sat Oct 17 09:15: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 C69CB3A695E for ; Sat, 17 Oct 2009 09:15:26 -0700 (PDT) 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.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 pe6p0rZ710Zl for ; Sat, 17 Oct 2009 09:15:26 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id E17A23A6859 for ; Sat, 17 Oct 2009 09:15:25 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so713959eyd.51 for ; Sat, 17 Oct 2009 09:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=S69EBWg7VzFxdnZL+CkmpL8YdJtuLq2PeHQlBrfHJjU=; b=WC8HMrA041FQqBf+NmAFmO3lb8pNmDQQZ+ss7SYnQHJIwjFUPry+udiN3TMsAJwniS LKLDQUkPCOQX6vxYbthPDAQaW4r6GkFWz/ic7YvxKR1Q27tRnh12FpeGjwTX/wCVaUnc plzVSU/a99po78jNJycYlvHSvjxPdNsgYeXoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=s8SD1+amNy8J+uRbjOlqSYLWoPLVfdwRXWMrRYlaAE+oChSAPylEseo4/vBps4PaYB dgReStrkGAZosWAoePGy4/rF1xMjDOm1F/BGXjm7XxinXQkqUSUDluMzyOwxBDxqgNq4 j0D0DyGiKYicPzHQYuG/UwDJSDQBMvLsCwJVU= Received: by 10.216.86.204 with SMTP id w54mr1012431wee.54.1255796130432; Sat, 17 Oct 2009 09:15:30 -0700 (PDT) Received: from ?192.168.15.100? (adsl-76-195-0-45.dsl.pltn13.sbcglobal.net [76.195.0.45]) by mx.google.com with ESMTPS id m5sm6049122gve.11.2009.10.17.09.15.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Oct 2009 09:15:29 -0700 (PDT) Message-Id: From: =?ISO-8859-1?Q?Fran=E7ois_AUDET?= To: Dean Willis In-Reply-To: <4AD9ECDC.1030502@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 09:15:25 -0700 References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <4AD9E8C8.10506@softarmor.com> <8C8A23FF-CFA2-48B0-9CAE-AF95E0B61389@gmail.com> <4AD9ECDC.1030502@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:15:26 -0000 Because there are some interoperability glitches, but mostly because =20 today, it relies effectively on word-of-mouth: go talk to your local =20 SIP expert (TM). This is not scalable, especially for those of us on the receiving end =20= of the requests. On Oct 17, 2009, at 09:12 , Dean Willis wrote: > Fran=E7ois AUDET wrote: >> Because it is widely deployed that way, and nobody is going to change >> their implementation drastically as it works fine today. > > =46rom a standards perspective, that's a really weak answer. If it's > already widely deployed and works just fine, why should we =20 > standardize it? > > -- > Dean From HKaplan@acmepacket.com Sat Oct 17 09:18: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 6C3483A6855 for ; Sat, 17 Oct 2009 09:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_52=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 f5VPJ8RgzchW for ; Sat, 17 Oct 2009 09:18:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9005B3A6859 for ; Sat, 17 Oct 2009 09:18:43 -0700 (PDT) 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; Sat, 17 Oct 2009 12:18:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Oct 2009 12:18:46 -0400 From: Hadriel Kaplan To: Dean Willis , Spencer Dawkins Date: Sat, 17 Oct 2009 12:18:46 -0400 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpPQkub0Y6gvMjmStmoVIHlkr9eeAAAGCGA Message-ID: References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <4AD9E8C8.10506@softarmor.com> In-Reply-To: <4AD9E8C8.10506@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:18:44 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, October 17, 2009 11:55 AM > > On Fri, 2009-10-16 at 23:51 -0500, Spencer Dawkins wrote: > > I see Hadriel's draft as an effort to "housebreak" this > > behavior, so that network operators, middleboxes, etc. at least get som= e > > clue that This Is Not Your Parent's REGISTER Operation, just by > looking at a > > packet trace with WireShark. They can't know that today. >=20 > Then why should we call it REGISTER?=20 Well, it really is "registering" something. > Wouldn't it be better to use a > different request method name? I don't think so, for several reasons: =20 1) there is quite a bit of angst with new methods. I don't think it's any = news to folks that people believe it's a "big deal" to use a new method nam= e vs. a new option-tag, header, or param. 2) there're quite a number of extensions which would be needed or useful fo= r this, which are tied to REGISTER in their RFC text. For example: sip-out= bound, Path, Service-Route, reg-event. We would have to update the text. 3) the difference between domain-registration and aor-registrations for the= request transaction that does the registering is only in the specific DB i= t populates/updates. PUBLISH could be used instead, but populating reachab= ility information has a bunch of very specific needs, as provided by sip-ou= tbound and Path. -hadriel From HKaplan@acmepacket.com Sat Oct 17 09:34: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 879D53A6941 for ; Sat, 17 Oct 2009 09:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 mmm5Tuoo0px3 for ; Sat, 17 Oct 2009 09:34:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 162F63A6855 for ; Sat, 17 Oct 2009 09:34:08 -0700 (PDT) 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; Sat, 17 Oct 2009 12:34:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Oct 2009 12:34:09 -0400 From: Hadriel Kaplan To: Dean Willis Date: Sat, 17 Oct 2009 12:33:56 -0400 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpPRDRYCDcJou1NS3K44ppJSPD9CwAAYV+w Message-ID: References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> In-Reply-To: <4AD9EBFB.7070101@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 16:34:09 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, October 17, 2009 12:08 PM >=20 > I think you've got a hold of an absolutely critical, core piece of SIP > functionality. You're either revising or replacing one of the > fundamental SIP methods, dating to before RFC 2543. That says SIPCORE to > me. We're not updating 3261, 3262, or 3263. We're not revising or replacing RE= GISTER. We're extending, using an options-tag to indicate it. Otherwise w= hat you're saying is every extension that needs an options-tag for any requ= est Method name documented in 3261 needs to be in sipcore - including any a= pplying to INVITE. I don't think you want that. =20 > I believe that the same objections that might prevent you from making a > "standards track" solution would also keep you from making an > informational solution. You might not notice, but we've held even the > info track documents to a high level of review. There would be nothing to discuss. It wouldn't require an informational dr= aft to even be published. There's enough wiggle room in 3261 routing proce= dures and Registration procedures to avoid any need - the draft would effec= tively be an "FYI". Effectively it would be something along the lines of t= he older draft-kaplan-dispatch-sip-implicit-registrations-00. =20 We would register an AoR in a REGISTER transaction - for requests to that s= pecific AoR things would follow 3261 as is. For all intents, it's a fake A= oR. Internally, in the Registrar DB, that AoR's reachability information (= contact/path) would just not-so-coincidentally happen to be used for Route = header fields for that domain. Since that routing portion is effectively u= p to local policy (ie, implementations), it would comply with 3261 as well.= Nothing in 3261 demands that local policy routing results follow any pres= cribed data, so we'd just document that it happens to be data populated fro= m that AoR's reachability data. =20 There isn't even a need for a new header. We'd just try for one to help tr= oubleshooting and avoiding erroneous manual configuration. -hadriel From bernard_aboba@hotmail.com Sat Oct 17 12:48: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 435383A67DA for ; Sat, 17 Oct 2009 12:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_40=-0.185, 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 lrQUXNYmKGVr for ; Sat, 17 Oct 2009 12:48:29 -0700 (PDT) Received: from blu0-omc4-s18.blu0.hotmail.com (blu0-omc4-s18.blu0.hotmail.com [65.55.111.157]) by core3.amsl.com (Postfix) with ESMTP id 4FF913A66B4 for ; Sat, 17 Oct 2009 12:48:29 -0700 (PDT) Received: from BLU137-W20 ([65.55.111.135]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 12:48:34 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7f2ce1d5-328b-42f9-af0e-02be907f7b27_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sat, 17 Oct 2009 12:48:34 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2009 19:48:34.0527 (UTC) FILETIME=[CFCE3EF0:01CA4F62] Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 19:48:30 -0000 --_7f2ce1d5-328b-42f9-af0e-02be907f7b27_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean Willis said: "From a standards perspective=2C that's a really weak answer. If it's already widely deployed and works just fine=2C why should we standardize it?" To be clear=2C the mechanism described in draft-kaplan-dispatch-domain-regi= stration is *not* widely deployed. However=2C there are other "implicit re= gistration" approaches that are. These include approaches implemented in S= MB PBXes (not documented to my knowledge)=2C as well as an approach propose= d in 3GPP (documented). =20 The SMB approach (which is implemented in Asterisk=2C Response Point and ot= her SMB products) appears identical to an RFC 3261 reqistration request and= response on the wire. However=2C its effect at the service provider end i= s quite different. Typically the state at the service provider after compl= etion of the registration exchange is as if the provider had received "virt= ual" registration requests for each line=2C and had responded to them (alth= ough multiple responses are not seen on the wire). However=2C the exact ma= nner in which the "virtual" registration requests are synthesized from the = actual registration request is determined by the service provider=2C and ma= y differ between providers. For example=2C the registration request from w= hich the "virtual registrations" are derived may first be subject to transf= ormations such as those used in "far end nat traversal". As a result=2C a = given registration request may not be transformed into the same set of "vir= tual registration" requests by every service provider.=20 = --_7f2ce1d5-328b-42f9-af0e-02be907f7b27_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean Willis said:

"From a standards perspective=2C that's a really weak answer. If it's already widely deployed and works just fine=2C why should we standardize it?"

To be clear=2C the mechanism described in draft-kaplan-dispatch= -domain-registration is *not* widely deployed. =3B However=2C there are= other "implicit registration" approaches that are. =3B These include a= pproaches implemented in SMB PBXes (not documented to my knowledge)=2C as w= ell as an approach proposed in 3GPP (documented). =3B

The SMB a= pproach (which is implemented in Asterisk=2C Response Point and other SMB p= roducts) appears identical to an RFC 3261 reqistration request and response= on the wire. =3B However=2C its effect at the service provider end is = quite different. =3B Typically the state at the service provider after = completion of the registration exchange is as if the provider had received = "virtual" registration requests for each line=2C and had responded to them = (although multiple responses are not seen on the wire). =3B However=2C = the exact manner in which the "virtual" registration requests are synthesiz= ed from the actual registration request is determined by the service provid= er=2C and may differ between providers. =3B For example=2C the registra= tion request from which the "virtual registrations" are derived may first b= e subject to transformations such as those used in "far end nat traversal".=  =3B As a result=2C a given registration request may not be transformed= into the same set of "virtual registration" requests by every service prov= ider.


= --_7f2ce1d5-328b-42f9-af0e-02be907f7b27_-- From audet.francois@gmail.com Sat Oct 17 16:20: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 BB4333A67AA for ; Sat, 17 Oct 2009 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 ZH4wBxoVhqeB for ; Sat, 17 Oct 2009 16:20:54 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 52EC13A67A7 for ; Sat, 17 Oct 2009 16:20:54 -0700 (PDT) Received: by ewy4 with SMTP id 4so456723ewy.37 for ; Sat, 17 Oct 2009 16:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=4Ea7F8VgfiVK12UekvCNyBNXIabdnlbXDhI1YwpstQg=; b=D8lZ3oIAL7JkZoSQOIRyQj8uQFpiANZ4xFcRgZD5zVF7af55PUVOPtwR41nd4zBi88 4qG7K+zdJcG7cx2kMnR81opYEWyDQnNQERaO1vRHXKfQl6ouMSkmX7mEQwssVv4rhcrr hzNbJRnqfzfxd54q32PYY5Fu5GYovi6HGTbP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=t5WZt825BObcNA5sYGJvdXHBNmTyF/VEq7DFvPCrPJzrRF1AJjuLDtNN14nLChrmgL 0MnUCD3M6e9QPeVcFPQMY8INeAJfZdjaOpH/k+4Y/2I0EM4HbjjE4Atitvawcbi29QYu hN7E+wBDImcL7neJXvrDS0HF4kmAA7UNipB8M= Received: by 10.210.7.21 with SMTP id 21mr2976213ebg.66.1255821655969; Sat, 17 Oct 2009 16:20:55 -0700 (PDT) Received: from ?192.168.15.100? (adsl-75-36-217-101.dsl.pltn13.sbcglobal.net [75.36.217.101]) by mx.google.com with ESMTPS id 7sm8714595eyb.16.2009.10.17.16.20.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Oct 2009 16:20:55 -0700 (PDT) Message-Id: <5850900E-997F-4CE3-80DF-D7E647D947BE@gmail.com> From: =?ISO-8859-1?Q?Fran=E7ois_AUDET?= To: Bernard Aboba In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-489060525 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 16:20:50 -0700 References: X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 17 Oct 2009 23:20:55 -0000 --Apple-Mail-1-489060525 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Correct, since the draft actually doesn't actually define a mechanism. Implicit domain registration (with an arbitrary AOR) is widely deployed, both inside enterprises, as well as between an enterprise and a service provider. And not just for SMB. On Oct 17, 2009, at 12:48 , Bernard Aboba wrote: > Dean Willis said: > > "From a standards perspective, that's a really weak answer. If it's > already widely deployed and works just fine, why should we > standardize it?" > > To be clear, the mechanism described in draft-kaplan-dispatch-domain- > registration is *not* widely deployed. However, there are other > "implicit registration" approaches that are. These include > approaches implemented in SMB PBXes (not documented to my > knowledge), as well as an approach proposed in 3GPP (documented). > > The SMB approach (which is implemented in Asterisk, Response Point > and other SMB products) appears identical to an RFC 3261 > reqistration request and response on the wire. However, its effect > at the service provider end is quite different. Typically the state > at the service provider after completion of the registration > exchange is as if the provider had received "virtual" registration > requests for each line, and had responded to them (although multiple > responses are not seen on the wire). However, the exact manner in > which the "virtual" registration requests are synthesized from the > actual registration request is determined by the service provider, > and may differ between providers. For example, the registration > request from which the "virtual registrations" are derived may first > be subject to transformations such as those used in "far end nat > traversal". As a result, a given registration request may not be > transformed into the same set of "virtual registration" requests by > every service provider. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-1-489060525 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Correct, since the draft = actually doesn't actually define a = mechanism.

Implicit domain registration (with an = arbitrary AOR) is widely deployed, both inside enterprises, as well as = between an enterprise and a service = provider.

And not just for = SMB.

On Oct 17, 2009, at 12:48 , Bernard Aboba = wrote:

Dean Willis = said:

"=46rom a standards perspective, that's a really weak = answer. If it's already widely deployed and works just fine, why should = we standardize it?"

To be clear, the mechanism described in = draft-kaplan-dispatch-domain-registration is *not* widely = deployed.  However, there are other "implicit registration" = approaches that are.  These include approaches implemented in SMB = PBXes (not documented to my knowledge), as well as an approach proposed = in 3GPP (documented).  

The SMB approach = (which is implemented in Asterisk, Response Point and other SMB = products) appears identical to an RFC 3261 reqistration request and = response on the wire.  However, its effect at the service provider = end is quite different.  Typically the state at the service = provider after completion of the registration exchange is as if the = provider had received "virtual" registration requests for each line, and = had responded to them (although multiple responses are not seen on the = wire).  However, the exact manner in which the "virtual" = registration requests are synthesized from the actual registration = request is determined by the service provider, and may differ between = providers.  For example, the registration request from which the = "virtual registrations" are derived may first be subject to = transformations such as those used in "far end nat traversal".  As = a result, a given registration request may not be transformed into the = same set of "virtual registration" requests by every service = provider. 

dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch

= --Apple-Mail-1-489060525-- From dean.willis@softarmor.com Sun Oct 18 21:40: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 48C593A6807 for ; Sun, 18 Oct 2009 21:40:24 -0700 (PDT) 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 8AJVFKflube4 for ; Sun, 18 Oct 2009 21:40:23 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 192143A6778 for ; Sun, 18 Oct 2009 21:40:23 -0700 (PDT) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9J4eO1r018395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 18 Oct 2009 23:40:26 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Oct 2009 23:40:18 -0500 References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 04:40:24 -0000 On Oct 17, 2009, at 11:33 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Saturday, October 17, 2009 12:08 PM >> >> I think you've got a hold of an absolutely critical, core piece of >> SIP >> functionality. You're either revising or replacing one of the >> fundamental SIP methods, dating to before RFC 2543. That says >> SIPCORE to >> me. > > We're not updating 3261, 3262, or 3263. We're not revising or > replacing REGISTER. We're extending, using an options-tag to > indicate it. Otherwise what you're saying is every extension that > needs an options-tag for any request Method name documented in 3261 > needs to be in sipcore - including any applying to INVITE. I don't > think you want that. > I normally try not to say things like this, but . . . Bullshit. You're adding a raft of new functionality to REGISTER, abusing an option tag, requiring registrars to differentiate between AoR and domain registrations, adding a 2nd routing database to the proxy/ registrar, etc. -- Dean From john.elwell@siemens-enterprise.com Mon Oct 19 01:25:41 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 DC64F3A6935 for ; Mon, 19 Oct 2009 01:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_EQ_DE=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 kF2+oq8RPjms for ; Mon, 19 Oct 2009 01:25:41 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id D668E3A691F for ; Mon, 19 Oct 2009 01:25:40 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J8PiIB004382; Mon, 19 Oct 2009 10:25:44 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J8Pi4W023705; Mon, 19 Oct 2009 10:25:44 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Mon, 19 Oct 2009 10:25:43 +0200 From: "Elwell, John" To: Dean Willis , Hadriel Kaplan Date: Mon, 19 Oct 2009 10:25:37 +0200 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpPQ/3GpMy5Drm2T5WemeqXHLLGJgBT4xgw Message-ID: <7402509E63C5A145A6095D46C179A5B71477DD5A@DEMCHP99E35MSX.ww902.siemens.net> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> <1255760525.15650.4.camel@ubuntu.ubuntu-domain> <4AD9DE0B.90800@softarmor.com> <4AD9EB1D.5090208@softarmor.com> In-Reply-To: <4AD9EB1D.5090208@softarmor.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Dean Willis Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 08:25:42 -0000 I think this discussion is going down the rat hole of trying to find a way = of using "correctly" a mechanism that current practice already uses "incorr= ectly" in other contexts. It seems easier to go with the tide and use an op= tion tag in Require, as proposed in the draft. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 17 October 2009 17:05 > To: Hadriel Kaplan > Cc: dispatch@ietf.org; Dean Willis > Subject: Re: [dispatch] Domain Registration Draft=20 > draft-kaplan-dispatch-domain-registration >=20 > Hadriel Kaplan wrote: >=20 > >=20 > > Regardless, if you'd prefer, we can add a uri-param to the To-URI to > > indicate "this is a Domain being registered, not an AoR"=20 > and then the > > option-tag would require support to understand that param.=20 > > Acceptable? >=20 > That would be better. >=20 > The real question is what happens when a domain-registration request > that is not marked with a Require for the option lands at a registrar > that does not understand the extension. >=20 > Will the non-domain registrar try to execute the REGISTER?=20 > What happens > when it does? >=20 > While you could say "If you are doing domain-registration, you must > Require the option tag for this feature in every domain-registering > request", this is inconsistent with the way we've traditionally used > Require. >=20 > It would be better yet to use something besides REGISTER as=20 > the request > method name, or to put the registered routes into something=20 > that is not > Contact and put only "safe" values in Contact. Or both -- this > absolutely prevents the uncertainty condition. >=20 > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From john.elwell@siemens-enterprise.com Mon Oct 19 01:25: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 3B8A13A6973 for ; Mon, 19 Oct 2009 01:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.529 X-Spam-Level: X-Spam-Status: No, score=-5.529 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, HELO_EQ_DE=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 y6QD4ItoqDR9 for ; Mon, 19 Oct 2009 01:25:46 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 246063A6971 for ; Mon, 19 Oct 2009 01:25:45 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J8PoN8004523; Mon, 19 Oct 2009 10:25:50 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J8PoSx023774; Mon, 19 Oct 2009 10:25:50 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Mon, 19 Oct 2009 10:25:50 +0200 From: "Elwell, John" To: Dean Willis , Hadriel Kaplan Date: Mon, 19 Oct 2009 10:25:45 +0200 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpQdkxRtzqEVBeYTeObG4tIobaxFwAHxzPg Message-ID: <7402509E63C5A145A6095D46C179A5B71477DD5B@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 08:25:47 -0000 No, the draft is extending, not updating, RFC 3261, in the same way that RF= C 3262, and many other RFCs, extend RFC 3261. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 19 October 2009 05:40 > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch]=20 > DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration >=20 >=20 > On Oct 17, 2009, at 11:33 AM, Hadriel Kaplan wrote: >=20 > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Saturday, October 17, 2009 12:08 PM > >> > >> I think you've got a hold of an absolutely critical, core=20 > piece of =20 > >> SIP > >> functionality. You're either revising or replacing one of the > >> fundamental SIP methods, dating to before RFC 2543. That says =20 > >> SIPCORE to > >> me. > > > > We're not updating 3261, 3262, or 3263. We're not revising or =20 > > replacing REGISTER. We're extending, using an options-tag to =20 > > indicate it. Otherwise what you're saying is every extension that =20 > > needs an options-tag for any request Method name documented=20 > in 3261 =20 > > needs to be in sipcore - including any applying to INVITE. =20 > I don't =20 > > think you want that. > > >=20 > I normally try not to say things like this, but . . . >=20 > Bullshit. >=20 > You're adding a raft of new functionality to REGISTER, abusing an =20 > option tag, requiring registrars to differentiate between AoR and =20 > domain registrations, adding a 2nd routing database to the proxy/=20 > registrar, etc. >=20 > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From L.Liess@telekom.de Mon Oct 19 05:38: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 1B39F3A6997; Mon, 19 Oct 2009 05:38:57 -0700 (PDT) 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 GXzLTXqDLTJx; Mon, 19 Oct 2009 05:38:56 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 97FB73A6887; Mon, 19 Oct 2009 05:38:54 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 19 Oct 2009 14:38:56 +0200 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, 19 Oct 2009 14:38:55 +0200 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: Mon, 19 Oct 2009 14:38:54 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: AcpQq3YunVR8UxnZT5+ec/k+hRAeoQAAZzpQ From: To: , X-OriginalArrivalTime: 19 Oct 2009 12:38:55.0465 (UTC) FILETIME=[1F1D0D90:01CA50B9] Cc: anwars@avaya.com, R.Jesske@telekom.de Subject: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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: Mon, 19 Oct 2009 12:38:57 -0000 =20 Hi, We've re-submitted the Alert-Info URNs draft for DISPATCH http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns -00.txt . (The previous version od the draft was in BLISS and we had a presentation in BLISS at the last IETF.) We did some major changes, as suggested on the mailing list, e.g.: Added: =20 - Description of the interoperability problems for PBX-services (in the Introduction chapter)=20 - Requirements for the Alert-Info URNs mechanism=20 - Alert-Info URNs Indications for country-specific tones Changed:=20 - Initial IANA Registration mechanism to avoid combinatorial explosion of IANA values.=20 Many thanks for the comments and suggestions, Laura=20 =20 -----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, October 19, 2009 1:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Alert-Info URNs for the Session Initiation Protocol (SIP) Author(s) : D. Alexeitsev, et al. Filename : draft-liess-dispatch-alert-info-urns-00.txt Pages : 25 Date : 2009-10-19 The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns -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 pkyzivat@cisco.com Mon Oct 19 07: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 5CA8728C1B1 for ; Mon, 19 Oct 2009 07:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 NUZh0fWQqwK4 for ; Mon, 19 Oct 2009 07:01:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2669628C1B7 for ; Mon, 19 Oct 2009 07:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2956; q=dns/txt; s=rtpiport02001; t=1255960888; x=1257170488; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=09DomainRegistrationDraftdraft-kaplan -dispatch-domain-registration|Date:=20Mon,=2019=20Oct=202 009=2010:01:26=20-0400|Message-ID:=20<4ADC7136.9060200@ci sco.com>|To:=20Hadriel=20Kaplan=20|CC:=20Dean=20Willis=20,=0D =0A=20=20=20=20=20=20=20=20"dispatch@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20 =09<4AD7AA3D.8070108@cisco.com> =09<24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com>=09< 34D756FF40454C5EB485CA73316DDF42@china.huawei.com>=09<802 AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com>=09<4AD9DFF 9.5060303@softarmor.com>=09=09<4AD9EBFB.7070101@softarmor.com>=20 ; bh=KBsnUV2INBJuRLeJ3EE+kqtOinSqNTQnFOmuOQ6hnHY=; b=IvCI/clb9Fz1gY0EYmCouBFUixvz3Nl/wvZWESCtXu0Eu49+WOUV0Xp7 Ejurzp9L4Q6PX0XqC800M++eAqvcsrP9lc0rKHkeN4gn7y/ptJsytWIj1 W/QmY1Zpy1D8PMeHyi7+LN/8fJR/YOILE1DaAH5xhovc2yuQbGs+KOmQe s=; 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: ApoEADcO3EpAZnwN/2dsb2JhbADET5ZuhDEE X-IronPort-AV: E=Sophos;i="4.44,585,1249257600"; d="scan'208";a="63778588" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2009 14:01:27 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9JE1Rjv022700; Mon, 19 Oct 2009 14:01:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:01:27 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:01:26 -0400 Message-ID: <4ADC7136.9060200@cisco.com> Date: Mon, 19 Oct 2009 10:01:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hadriel Kaplan References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 14:01:26.0960 (UTC) FILETIME=[A66F3B00:01CA50C4] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 14:01:22 -0000 I continue to sit on the fence about this one: I understand and agree with what Hadriel is saying about this behavior falling within the latitude given to proxies on how they route things. Thus I think it is *conforming* for SIPForum or some other group to make an agreement about a convention that does things this way. But it is a hack. It is not a *clean* way to do it. I expect more from IETF approved documents. Maybe we are to the point with SIP where there is too much inertia to afford "clean", and that hacks are now the way forward. But if so, that is at least sad. Thanks, Paul Hadriel Kaplan wrote: >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Saturday, October 17, 2009 12:08 PM >> >> I think you've got a hold of an absolutely critical, core piece of SIP >> functionality. You're either revising or replacing one of the >> fundamental SIP methods, dating to before RFC 2543. That says SIPCORE to >> me. > > We're not updating 3261, 3262, or 3263. We're not revising or replacing REGISTER. We're extending, using an options-tag to indicate it. Otherwise what you're saying is every extension that needs an options-tag for any request Method name documented in 3261 needs to be in sipcore - including any applying to INVITE. I don't think you want that. > > >> I believe that the same objections that might prevent you from making a >> "standards track" solution would also keep you from making an >> informational solution. You might not notice, but we've held even the >> info track documents to a high level of review. > > There would be nothing to discuss. It wouldn't require an informational draft to even be published. There's enough wiggle room in 3261 routing procedures and Registration procedures to avoid any need - the draft would effectively be an "FYI". Effectively it would be something along the lines of the older draft-kaplan-dispatch-sip-implicit-registrations-00. > > We would register an AoR in a REGISTER transaction - for requests to that specific AoR things would follow 3261 as is. For all intents, it's a fake AoR. Internally, in the Registrar DB, that AoR's reachability information (contact/path) would just not-so-coincidentally happen to be used for Route header fields for that domain. Since that routing portion is effectively up to local policy (ie, implementations), it would comply with 3261 as well. Nothing in 3261 demands that local policy routing results follow any prescribed data, so we'd just document that it happens to be data populated from that AoR's reachability data. > > There isn't even a need for a new header. We'd just try for one to help troubleshooting and avoiding erroneous manual configuration. > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From hsinnrei@adobe.com Mon Oct 19 07:29: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 537E73A6778 for ; Mon, 19 Oct 2009 07:29:28 -0700 (PDT) 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 IDLl9I6HnE3n for ; Mon, 19 Oct 2009 07:29:27 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id 474D628C0F6 for ; Mon, 19 Oct 2009 07:29:26 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKStx3y9h00iDoshs4Wou0lrx5LWlleJz2@postini.com; Mon, 19 Oct 2009 07:29:34 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9JETSX3029880; Mon, 19 Oct 2009 07:29:29 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9JETRiq008830; Mon, 19 Oct 2009 07:29:27 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 19 Oct 2009 07:29:27 -0700 From: Henry Sinnreich To: Paul Kyzivat , Hadriel Kaplan Date: Mon, 19 Oct 2009 07:29:25 -0700 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpQxRE6DnnLe4jITxWOKaywWqqSdwAA31nl Message-ID: In-Reply-To: <4ADC7136.9060200@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C701E1F5665Chsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 14:29:28 -0000 --_000_C701E1F5665Chsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Maybe we are to the point with SIP where there is too much inertia to affo= rd "clean", >and that hacks are now the way >forward. But if so, that is at least sad. Agree and it makes one wonder how an Internet SIP architecture document wou= ld look like. Having in Mind something like REST http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Thanks, Henry On 10/19/09 9:01 AM, "Paul Kyzivat" wrote: I continue to sit on the fence about this one: I understand and agree with what Hadriel is saying about this behavior falling within the latitude given to proxies on how they route things. Thus I think it is *conforming* for SIPForum or some other group to make an agreement about a convention that does things this way. But it is a hack. It is not a *clean* way to do it. I expect more from IETF approved documents. Maybe we are to the point with SIP where there is too much inertia to afford "clean", and that hacks are now the way forward. But if so, that is at least sad. Thanks, Paul Hadriel Kaplan wrote: >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Saturday, October 17, 2009 12:08 PM >> >> I think you've got a hold of an absolutely critical, core piece of SIP >> functionality. You're either revising or replacing one of the >> fundamental SIP methods, dating to before RFC 2543. That says SIPCORE to >> me. > > We're not updating 3261, 3262, or 3263. We're not revising or replacing = REGISTER. We're extending, using an options-tag to indicate it. Otherwise= what you're saying is every extension that needs an options-tag for any re= quest Method name documented in 3261 needs to be in sipcore - including any= applying to INVITE. I don't think you want that. > > >> I believe that the same objections that might prevent you from making a >> "standards track" solution would also keep you from making an >> informational solution. You might not notice, but we've held even the >> info track documents to a high level of review. > > There would be nothing to discuss. It wouldn't require an informational = draft to even be published. There's enough wiggle room in 3261 routing pro= cedures and Registration procedures to avoid any need - the draft would eff= ectively be an "FYI". Effectively it would be something along the lines of= the older draft-kaplan-dispatch-sip-implicit-registrations-00. > > We would register an AoR in a REGISTER transaction - for requests to that= specific AoR things would follow 3261 as is. For all intents, it's a fake= AoR. Internally, in the Registrar DB, that AoR's reachability information= (contact/path) would just not-so-coincidentally happen to be used for Rout= e header fields for that domain. Since that routing portion is effectively= up to local policy (ie, implementations), it would comply with 3261 as wel= l. Nothing in 3261 demands that local policy routing results follow any pr= escribed data, so we'd just document that it happens to be data populated f= rom that AoR's reachability data. > > There isn't even a need for a new header. We'd just try for one to help = troubleshooting and avoiding erroneous manual configuration. > > -hadriel > _______________________________________________ > 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 --_000_C701E1F5665Chsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-r= egistration >Maybe we are to the point with SIP where there is too much inerti= a to afford "clean",
>and that hacks are now the way
>forward. But if so, that is at least sad.

Agree and it makes one wonder how an Internet SIP architecture document wou= ld look like.
Having in Mind something like REST
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.= htm

Thanks, Henry


On 10/19/09 9:01 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

I continue to sit on the fence about this o= ne:

I understand and agree with what Hadriel is saying about this behavior
falling within the latitude given to proxies on how they route things.
Thus I think it is *conforming* for SIPForum or some other group to make an agreement about a convention that does things this way.

But it is a hack. It is not a *clean* way to do it. I expect more from
IETF approved documents. Maybe we are to the point with SIP where there
is too much inertia to afford "clean", and that hacks are now the= way
forward. But if so, that is at least sad.

        Thanks,
        Paul

Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: Dean Willis [ma= ilto:dean.willis@softarmor.com]
>> Sent: Saturday, October 17, 2009 12:08 PM
>>
>> I think you've got a hold of an absolutely critical, core piece of= SIP
>> functionality. You're either revising or replacing one of the
>> fundamental SIP methods, dating to before RFC 2543. That says SIPC= ORE to
>> me.
>
> We're not updating 3261, 3262, or 3263.  We're not revising or re= placing REGISTER.  We're extending, using an options-tag to indicate i= t.  Otherwise what you're saying is every extension that needs an opti= ons-tag for any request Method name documented in 3261 needs to be in sipco= re - including any applying to INVITE.  I don't think you want that. >
>
>> I believe that the same objections that might prevent you from mak= ing a
>> "standards track" solution would also keep you from maki= ng an
>> informational solution. You might not notice, but we've held even = the
>> info track documents to a high level of review.
>
> There would be nothing to discuss.  It wouldn't require an inform= ational draft to even be published.  There's enough wiggle room in 326= 1 routing procedures and Registration procedures to avoid any need - the dr= aft would effectively be an "FYI".  Effectively it would be = something along the lines of the older draft-kaplan-dispatch-sip-implicit-r= egistrations-00.
>
> We would register an AoR in a REGISTER transaction - for requests to t= hat specific AoR things would follow 3261 as is.  For all intents, it'= s a fake AoR.  Internally, in the Registrar DB, that AoR's reachabilit= y information (contact/path) would just not-so-coincidentally happen to be = used for Route header fields for that domain.  Since that routing port= ion is effectively up to local policy (ie, implementations), it would compl= y with 3261 as well.  Nothing in 3261 demands that local policy routin= g results follow any prescribed data, so we'd just document that it happens= to be data populated from that AoR's reachability data.
>
> There isn't even a need for a new header.  We'd just try for one = to help troubleshooting and avoiding erroneous manual configuration.
>
> -hadriel
> _______________________________________________
> 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

--_000_C701E1F5665Chsinnreiadobecom_-- From spencer@wonderhamster.org Mon Oct 19 07:39: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 DA5073A680D for ; Mon, 19 Oct 2009 07:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, 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 Qs-hT+xLPV1x for ; Mon, 19 Oct 2009 07:39:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id F219A3A6832 for ; Mon, 19 Oct 2009 07:39:00 -0700 (PDT) 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 0LbcMV-1MYDHW1Nt5-00kTUc; Mon, 19 Oct 2009 10:39:07 -0400 Message-ID: <7ED0D30B566D472FAEF76B24609D7697@china.huawei.com> From: "Spencer Dawkins" To: References: <4AD7AA3D.8070108@cisco.com><24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> Date: Mon, 19 Oct 2009 09:38:59 -0500 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/LuRm9TSmDZTvHLBxVwxGsKaKF4EmKJfQZggK ieJOptgk9rw2wBEZ7wFBhyJHU0/Cfalz0HXJrE/lzDGePIESdO dR3SmevN89n5qsLvuxHM9QyjCfC/MYGDii6Lvyi5oQ= Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 14:39:02 -0000 I have a minor apology to make on-list. John Elwell pointed out in a private post that "housebreaking" in UK English means "burglary", not "teaching pets and small children how/when/where we deposit body wastes", so he was totally mystified by this part of my previous post: > I guess I should add one observation that I've been making privately. > We're looking at deployed, undocumented, and inconsistent SIP-PBX behavior > with SIP REGISTERs that carry no indication that something magic is > happening behind the scenes. I see Hadriel's draft as an effort to > "housebreak" this behavior, so that network operators, middleboxes, etc. > at least get some clue that This Is Not Your Parent's REGISTER Operation, > just by looking at a packet trace with WireShark. They can't know that > today. That's why I supported it, when Cullen asked for input earlier this > week. > > My experience with "housebreaking" pets and small children has been that > the resulting behavior isn't perfect, but there is a lot less "waste" on > the carpet after housebreaking - and that seemed like sufficient reason to > housebreak pets and small children. That's kind of how I'm seeing domain > registration - as an improvement. > > So I guess people can pop Hadriel across the muzzle with a rolled-up > newspaper, but this still seems like the right thing to do, IMO. > > :-) So if your $LOCALE means you were also mystified, I apologise, and if s/housebreaking/housetraining/g is clearer, please make the substitution retroactively. Thanks, Spencer From richard@shockey.us Mon Oct 19 09:33: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 C15F23A6861 for ; Mon, 19 Oct 2009 09:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.387, 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 8XqLbTVQ3w5I for ; Mon, 19 Oct 2009 09:33:32 -0700 (PDT) Received: from outbound-mail-103.bluehost.com (outbound-mail-103.bluehost.com [69.89.22.13]) by core3.amsl.com (Postfix) with SMTP id C28753A677E for ; Mon, 19 Oct 2009 09:33:32 -0700 (PDT) Received: (qmail 22095 invoked by uid 0); 19 Oct 2009 16:33:39 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 19 Oct 2009 16:33:39 -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=UywRv8SoqGifEKUNHIhDqcrl9JHanJuqvj0FSIpbaMRoErNRJlRiE7QAyO3JIUy2Llw1f2Scecz0f75q24M5PE9bL7eRHBfwvso0EyT7ZGDR+53Mjr12oB8z8Zei2SYp; 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 1MzvAx-0005bG-Iv; Mon, 19 Oct 2009 10:33:39 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Hadriel Kaplan'" References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> In-Reply-To: <4ADC7136.9060200@cisco.com> Date: Mon, 19 Oct 2009 12:33:36 -0400 Message-ID: <036201ca50d9$e8efb7b0$bacf2710$@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: AcpQxKs6J4E6b8poSLmdkwQ5NmYZRQAFIipA 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 Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 16:33:33 -0000 Paul please remember ..we are trying to fix something that is in the field right now and widely deployed that is causing interoperability problems. There are probably better ways to approach the bindings between PBX's and SSP's and the larger issues of provisioning but that is not what the draft is trying to accomplish and there is a substantial community here that is trying to do the right thing. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, October 19, 2009 10:01 AM > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch- > domain-registration > > I continue to sit on the fence about this one: > > I understand and agree with what Hadriel is saying about this behavior > falling within the latitude given to proxies on how they route things. > Thus I think it is *conforming* for SIPForum or some other group to > make > an agreement about a convention that does things this way. > > But it is a hack. It is not a *clean* way to do it. I expect more from > IETF approved documents. Maybe we are to the point with SIP where > there > is too much inertia to afford "clean", and that hacks are now the way > forward. But if so, that is at least sad. > > Thanks, > Paul > > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Saturday, October 17, 2009 12:08 PM > >> > >> I think you've got a hold of an absolutely critical, core piece of > SIP > >> functionality. You're either revising or replacing one of the > >> fundamental SIP methods, dating to before RFC 2543. That says > SIPCORE to > >> me. > > > > We're not updating 3261, 3262, or 3263. We're not revising or > replacing REGISTER. We're extending, using an options-tag to indicate > it. Otherwise what you're saying is every extension that needs an > options-tag for any request Method name documented in 3261 needs to be > in sipcore - including any applying to INVITE. I don't think you want > that. > > > > > >> I believe that the same objections that might prevent you from > making a > >> "standards track" solution would also keep you from making an > >> informational solution. You might not notice, but we've held even > the > >> info track documents to a high level of review. > > > > There would be nothing to discuss. It wouldn't require an > informational draft to even be published. There's enough wiggle room > in 3261 routing procedures and Registration procedures to avoid any > need - the draft would effectively be an "FYI". Effectively it would > be something along the lines of the older draft-kaplan-dispatch-sip- > implicit-registrations-00. > > > > We would register an AoR in a REGISTER transaction - for requests to > that specific AoR things would follow 3261 as is. For all intents, > it's a fake AoR. Internally, in the Registrar DB, that AoR's > reachability information (contact/path) would just not-so- > coincidentally happen to be used for Route header fields for that > domain. Since that routing portion is effectively up to local policy > (ie, implementations), it would comply with 3261 as well. Nothing in > 3261 demands that local policy routing results follow any prescribed > data, so we'd just document that it happens to be data populated from > that AoR's reachability data. > > > > There isn't even a need for a new header. We'd just try for one to > help troubleshooting and avoiding erroneous manual configuration. > > > > -hadriel > > _______________________________________________ > > 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 mdolly@att.com Mon Oct 19 09:39: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 908943A69B0 for ; Mon, 19 Oct 2009 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tFn+pa0BmF2K for ; Mon, 19 Oct 2009 09:39:02 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 64E7F3A677E for ; Mon, 19 Oct 2009 09:39:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-129.messagelabs.com!1255970348!6329631!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2956 invoked from network); 19 Oct 2009 16:39:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Oct 2009 16:39:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9JGd7NY016580; Mon, 19 Oct 2009 12:39:08 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9JGd3xb016539; Mon, 19 Oct 2009 12:39:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 19 Oct 2009 12:39:02 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4B2D@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpQxKs6J4E6b8poSLmdkwQ5NmYZRQAFIipAAABdiY8= From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 16:39:03 -0000 VGhpcyB0aGUgcmlnaHQgc29sdXRpb24ocGVyaW9kKSB0aGF0IHdpbGwgcmVzdWx0IGluIG1vcmUg SVAgZGVwbG95bWVudHMgLg0KDQpUaGlzIElFVEYgZGViYXRlIG9ubHkgZW1waGFzaXplIGl0cyBw bGFjZT8NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogZGlzcGF0Y2gtYm91 bmNlc0BpZXRmLm9yZyA8ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4NClRvOiAnUGF1bCBLeXpp dmF0JyA8cGt5eml2YXRAY2lzY28uY29tPjsgJ0hhZHJpZWwgS2FwbGFuJyA8SEthcGxhbkBhY21l cGFja2V0LmNvbT4NCkNjOiBkaXNwYXRjaEBpZXRmLm9yZyA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpT ZW50OiBNb24gT2N0IDE5IDEyOjMzOjM2IDIwMDkNClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdRG9t YWluUmVnaXN0cmF0aW9uRHJhZnRkcmFmdC1rYXBsYW4tZGlzcGF0Y2gtZG9tYWluLXJlZ2lzdHJh dGlvbg0KDQpQYXVsIHBsZWFzZSByZW1lbWJlciAuLndlIGFyZSB0cnlpbmcgdG8gZml4IHNvbWV0 aGluZyB0aGF0IGlzIGluIHRoZSBmaWVsZA0KcmlnaHQgbm93IGFuZCB3aWRlbHkgZGVwbG95ZWQg dGhhdCBpcyBjYXVzaW5nIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMuICANCg0KVGhlcmUgYXJl IHByb2JhYmx5IGJldHRlciB3YXlzIHRvIGFwcHJvYWNoIHRoZSBiaW5kaW5ncyBiZXR3ZWVuIFBC WCdzIGFuZA0KU1NQJ3MgYW5kIHRoZSBsYXJnZXIgaXNzdWVzIG9mIHByb3Zpc2lvbmluZyBidXQg dGhhdCBpcyBub3Qgd2hhdCB0aGUgZHJhZnQNCmlzIHRyeWluZyB0byBhY2NvbXBsaXNoIGFuZCB0 aGVyZSBpcyBhIHN1YnN0YW50aWFsIGNvbW11bml0eSBoZXJlIHRoYXQgaXMNCnRyeWluZyB0byBk byB0aGUgcmlnaHQgdGhpbmcuIA0KDQo+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAg RnJvbTogZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+ICBCZWhhbGYgT2YgUGF1bCBLeXppdmF0DQo+ICBTZW50OiBNb25kYXks IE9jdG9iZXIgMTksIDIwMDkgMTA6MDEgQU0NCj4gIFRvOiBIYWRyaWVsIEthcGxhbg0KPiAgQ2M6 IGRpc3BhdGNoQGlldGYub3JnDQo+ICBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBEb21haW5SZWdp c3RyYXRpb25EcmFmdGRyYWZ0LWthcGxhbi1kaXNwYXRjaC0NCj4gIGRvbWFpbi1yZWdpc3RyYXRp b24NCj4gIA0KPiAgSSBjb250aW51ZSB0byBzaXQgb24gdGhlIGZlbmNlIGFib3V0IHRoaXMgb25l Og0KPiAgDQo+ICBJIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggd2hhdCBIYWRyaWVsIGlzIHNh eWluZyBhYm91dCB0aGlzIGJlaGF2aW9yDQo+ICBmYWxsaW5nIHdpdGhpbiB0aGUgbGF0aXR1ZGUg Z2l2ZW4gdG8gcHJveGllcyBvbiBob3cgdGhleSByb3V0ZSB0aGluZ3MuDQo+ICBUaHVzIEkgdGhp bmsgaXQgaXMgKmNvbmZvcm1pbmcqIGZvciBTSVBGb3J1bSBvciBzb21lIG90aGVyIGdyb3VwIHRv DQo+ICBtYWtlDQo+ICBhbiBhZ3JlZW1lbnQgYWJvdXQgYSBjb252ZW50aW9uIHRoYXQgZG9lcyB0 aGluZ3MgdGhpcyB3YXkuDQo+ICANCj4gIEJ1dCBpdCBpcyBhIGhhY2suIEl0IGlzIG5vdCBhICpj bGVhbiogd2F5IHRvIGRvIGl0LiBJIGV4cGVjdCBtb3JlIGZyb20NCj4gIElFVEYgYXBwcm92ZWQg ZG9jdW1lbnRzLiBNYXliZSB3ZSBhcmUgdG8gdGhlIHBvaW50IHdpdGggU0lQIHdoZXJlDQo+ICB0 aGVyZQ0KPiAgaXMgdG9vIG11Y2ggaW5lcnRpYSB0byBhZmZvcmQgImNsZWFuIiwgYW5kIHRoYXQg aGFja3MgYXJlIG5vdyB0aGUgd2F5DQo+ICBmb3J3YXJkLiBCdXQgaWYgc28sIHRoYXQgaXMgYXQg bGVhc3Qgc2FkLg0KPiAgDQo+ICAJVGhhbmtzLA0KPiAgCVBhdWwNCj4gIA0KPiAgSGFkcmllbCBL YXBsYW4gd3JvdGU6DQo+ICA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgPj4gRnJv bTogRGVhbiBXaWxsaXMgW21haWx0bzpkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tXQ0KPiAgPj4g U2VudDogU2F0dXJkYXksIE9jdG9iZXIgMTcsIDIwMDkgMTI6MDggUE0NCj4gID4+DQo+ICA+PiBJ IHRoaW5rIHlvdSd2ZSBnb3QgYSBob2xkIG9mIGFuIGFic29sdXRlbHkgY3JpdGljYWwsIGNvcmUg cGllY2Ugb2YNCj4gIFNJUA0KPiAgPj4gZnVuY3Rpb25hbGl0eS4gWW91J3JlIGVpdGhlciByZXZp c2luZyBvciByZXBsYWNpbmcgb25lIG9mIHRoZQ0KPiAgPj4gZnVuZGFtZW50YWwgU0lQIG1ldGhv ZHMsIGRhdGluZyB0byBiZWZvcmUgUkZDIDI1NDMuIFRoYXQgc2F5cw0KPiAgU0lQQ09SRSB0bw0K PiAgPj4gbWUuDQo+ICA+DQo+ICA+IFdlJ3JlIG5vdCB1cGRhdGluZyAzMjYxLCAzMjYyLCBvciAz MjYzLiAgV2UncmUgbm90IHJldmlzaW5nIG9yDQo+ICByZXBsYWNpbmcgUkVHSVNURVIuICBXZSdy ZSBleHRlbmRpbmcsIHVzaW5nIGFuIG9wdGlvbnMtdGFnIHRvIGluZGljYXRlDQo+ICBpdC4gIE90 aGVyd2lzZSB3aGF0IHlvdSdyZSBzYXlpbmcgaXMgZXZlcnkgZXh0ZW5zaW9uIHRoYXQgbmVlZHMg YW4NCj4gIG9wdGlvbnMtdGFnIGZvciBhbnkgcmVxdWVzdCBNZXRob2QgbmFtZSBkb2N1bWVudGVk IGluIDMyNjEgbmVlZHMgdG8gYmUNCj4gIGluIHNpcGNvcmUgLSBpbmNsdWRpbmcgYW55IGFwcGx5 aW5nIHRvIElOVklURS4gIEkgZG9uJ3QgdGhpbmsgeW91IHdhbnQNCj4gIHRoYXQuDQo+ICA+DQo+ ICA+DQo+ICA+PiBJIGJlbGlldmUgdGhhdCB0aGUgc2FtZSBvYmplY3Rpb25zIHRoYXQgbWlnaHQg cHJldmVudCB5b3UgZnJvbQ0KPiAgbWFraW5nIGENCj4gID4+ICJzdGFuZGFyZHMgdHJhY2siIHNv bHV0aW9uIHdvdWxkIGFsc28ga2VlcCB5b3UgZnJvbSBtYWtpbmcgYW4NCj4gID4+IGluZm9ybWF0 aW9uYWwgc29sdXRpb24uIFlvdSBtaWdodCBub3Qgbm90aWNlLCBidXQgd2UndmUgaGVsZCBldmVu DQo+ICB0aGUNCj4gID4+IGluZm8gdHJhY2sgZG9jdW1lbnRzIHRvIGEgaGlnaCBsZXZlbCBvZiBy ZXZpZXcuDQo+ICA+DQo+ICA+IFRoZXJlIHdvdWxkIGJlIG5vdGhpbmcgdG8gZGlzY3Vzcy4gIEl0 IHdvdWxkbid0IHJlcXVpcmUgYW4NCj4gIGluZm9ybWF0aW9uYWwgZHJhZnQgdG8gZXZlbiBiZSBw dWJsaXNoZWQuICBUaGVyZSdzIGVub3VnaCB3aWdnbGUgcm9vbQ0KPiAgaW4gMzI2MSByb3V0aW5n IHByb2NlZHVyZXMgYW5kIFJlZ2lzdHJhdGlvbiBwcm9jZWR1cmVzIHRvIGF2b2lkIGFueQ0KPiAg bmVlZCAtIHRoZSBkcmFmdCB3b3VsZCBlZmZlY3RpdmVseSBiZSBhbiAiRllJIi4gIEVmZmVjdGl2 ZWx5IGl0IHdvdWxkDQo+ICBiZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSBvbGRl ciBkcmFmdC1rYXBsYW4tZGlzcGF0Y2gtc2lwLQ0KPiAgaW1wbGljaXQtcmVnaXN0cmF0aW9ucy0w MC4NCj4gID4NCj4gID4gV2Ugd291bGQgcmVnaXN0ZXIgYW4gQW9SIGluIGEgUkVHSVNURVIgdHJh bnNhY3Rpb24gLSBmb3IgcmVxdWVzdHMgdG8NCj4gIHRoYXQgc3BlY2lmaWMgQW9SIHRoaW5ncyB3 b3VsZCBmb2xsb3cgMzI2MSBhcyBpcy4gIEZvciBhbGwgaW50ZW50cywNCj4gIGl0J3MgYSBmYWtl IEFvUi4gIEludGVybmFsbHksIGluIHRoZSBSZWdpc3RyYXIgREIsIHRoYXQgQW9SJ3MNCj4gIHJl YWNoYWJpbGl0eSBpbmZvcm1hdGlvbiAoY29udGFjdC9wYXRoKSB3b3VsZCBqdXN0IG5vdC1zby0N Cj4gIGNvaW5jaWRlbnRhbGx5IGhhcHBlbiB0byBiZSB1c2VkIGZvciBSb3V0ZSBoZWFkZXIgZmll bGRzIGZvciB0aGF0DQo+ICBkb21haW4uICBTaW5jZSB0aGF0IHJvdXRpbmcgcG9ydGlvbiBpcyBl ZmZlY3RpdmVseSB1cCB0byBsb2NhbCBwb2xpY3kNCj4gIChpZSwgaW1wbGVtZW50YXRpb25zKSwg aXQgd291bGQgY29tcGx5IHdpdGggMzI2MSBhcyB3ZWxsLiAgTm90aGluZyBpbg0KPiAgMzI2MSBk ZW1hbmRzIHRoYXQgbG9jYWwgcG9saWN5IHJvdXRpbmcgcmVzdWx0cyBmb2xsb3cgYW55IHByZXNj cmliZWQNCj4gIGRhdGEsIHNvIHdlJ2QganVzdCBkb2N1bWVudCB0aGF0IGl0IGhhcHBlbnMgdG8g YmUgZGF0YSBwb3B1bGF0ZWQgZnJvbQ0KPiAgdGhhdCBBb1IncyByZWFjaGFiaWxpdHkgZGF0YS4N Cj4gID4NCj4gID4gVGhlcmUgaXNuJ3QgZXZlbiBhIG5lZWQgZm9yIGEgbmV3IGhlYWRlci4gIFdl J2QganVzdCB0cnkgZm9yIG9uZSB0bw0KPiAgaGVscCB0cm91Ymxlc2hvb3RpbmcgYW5kIGF2b2lk aW5nIGVycm9uZW91cyBtYW51YWwgY29uZmlndXJhdGlvbi4NCj4gID4NCj4gID4gLWhhZHJpZWwN Cj4gID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g ID4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+ICA+IGRpc3BhdGNoQGlldGYub3JnDQo+ICA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4gID4NCj4gIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICBkaXNwYXRj aCBtYWlsaW5nIGxpc3QNCj4gIGRpc3BhdGNoQGlldGYub3JnDQo+ICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNo QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo DQo= From BLINDSAY@nortel.com Mon Oct 19 09:43: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 140B23A6922 for ; Mon, 19 Oct 2009 09:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, MANGLED_REGSTR=2.3, 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 15uKnqZ05Qqj for ; Mon, 19 Oct 2009 09:43:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BB1813A6836 for ; Mon, 19 Oct 2009 09:43:42 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9JGhjO09386; Mon, 19 Oct 2009 16:43:46 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: Mon, 19 Oct 2009 12:43:40 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141B04CD7D@zcarhxm1.corp.nortel.com> In-Reply-To: <036201ca50d9$e8efb7b0$bacf2710$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpQxKs6J4E6b8poSLmdkwQ5NmYZRQAFIipAAABDfRA= References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> <036201ca50d9$e8efb7b0$bacf2710$@us> From: "Brian Lindsay" To: "Richard Shockey" , "Hadriel Kaplan" , Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 16:43:44 -0000 Hi, Would like to chime in and express support for standardization/formalization of a REGISTER-based solution to this problem, to address the SIP PBX problem space in a timely fashion by building on currently deployed approaches, rather than inventing something new. The draft should be DISPATCH'ed in a manner to best facilitate that. Thanks. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, October 19, 2009 12:34 PM To: 'Paul Kyzivat'; 'Hadriel Kaplan' Cc: dispatch@ietf.org Subject: Re: [dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registrati on Paul please remember ..we are trying to fix something that is in the field right now and widely deployed that is causing interoperability problems. =20 There are probably better ways to approach the bindings between PBX's and SSP's and the larger issues of provisioning but that is not what the draft is trying to accomplish and there is a substantial community here that is trying to do the right thing.=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, October 19, 2009 10:01 AM > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch- > domain-registration > =20 > I continue to sit on the fence about this one: > =20 > I understand and agree with what Hadriel is saying about this=20 > behavior falling within the latitude given to proxies on how they route things. > Thus I think it is *conforming* for SIPForum or some other group to =20 > make an agreement about a convention that does things this way. > =20 > But it is a hack. It is not a *clean* way to do it. I expect more=20 > from IETF approved documents. Maybe we are to the point with SIP=20 > where there is too much inertia to afford "clean", and that hacks=20 > are now the way forward. But if so, that is at least sad. > =20 > Thanks, > Paul > =20 > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Saturday, October 17, 2009 12:08 PM >> >> I think you've=20 > got a hold of an absolutely critical, core piece of SIP >>=20 > functionality. You're either revising or replacing one of the >>=20 > fundamental SIP methods, dating to before RFC 2543. That says SIPCORE > to >> me. > > > > We're not updating 3261, 3262, or 3263. We're not revising or =20 > replacing REGISTER. We're extending, using an options-tag to indicate > it. Otherwise what you're saying is every extension that needs an =20 > options-tag for any request Method name documented in 3261 needs to be > in sipcore - including any applying to INVITE. I don't think you want > that. > > > > > >> I believe that the same objections that might prevent you from =20 > making a >> "standards track" solution would also keep you from=20 > making an >> informational solution. You might not notice, but we've=20 > held even the >> info track documents to a high level of review. > > > > There would be nothing to discuss. It wouldn't require an =20 > informational draft to even be published. There's enough wiggle room > in 3261 routing procedures and Registration procedures to avoid any =20 > need - the draft would effectively be an "FYI". Effectively it would > be something along the lines of the older draft-kaplan-dispatch-sip- =20 > implicit-registrations-00. > > > > We would register an AoR in a REGISTER transaction - for requests=20 > to that specific AoR things would follow 3261 as is. For all=20 > intents, it's a fake AoR. Internally, in the Registrar DB, that=20 > AoR's reachability information (contact/path) would just not-so- =20 > coincidentally happen to be used for Route header fields for that =20 > domain. Since that routing portion is effectively up to local policy > (ie, implementations), it would comply with 3261 as well. Nothing in > 3261 demands that local policy routing results follow any prescribed > data, so we'd just document that it happens to be data populated from > that AoR's reachability data. > > > > There isn't even a need for a new header. We'd just try for one to > help troubleshooting and avoiding erroneous manual configuration. > > > > -hadriel > > _______________________________________________ > > 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jon.peterson@neustar.biz Mon Oct 19 11:39: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 083923A6781 for ; Mon, 19 Oct 2009 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.575, 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 nvTRWSWXn23p for ; Mon, 19 Oct 2009 11:39:29 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id D815F3A6946 for ; Mon, 19 Oct 2009 11:39:25 -0700 (PDT) Received: from ([192.168.128.150]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.1355808; Mon, 19 Oct 2009 14:39:28 -0400 Message-ID: <4ADCB260.1040108@neustar.biz> Date: Mon, 19 Oct 2009 11:39:28 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> In-Reply-To: <4ADC7136.9060200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 18:39:30 -0000 The question of whether or not the mechanism can (or should) be improved is entirely separable from whether or not it normatively updates RFC3261 or 3263. Well, even before that separation, we should quarantine the problem from the solution here: I'd say the problem should be able to live outside of SIPCORE, and if the eventual solution does entail a normative update to one of the SIPCORE specs, then certainly it must have gone down the wrong path. I see no serious bar to bringing this work to DRINKS. Once it does have a home, then we can see if the solution can be improved on the way through. Again, personally I'd have some few words to say in favor of doing this with PUBLISH. Jon Peterson NeuStar, Inc. Paul Kyzivat wrote: > > I continue to sit on the fence about this one: > > I understand and agree with what Hadriel is saying about this behavior > falling within the latitude given to proxies on how they route things. > Thus I think it is *conforming* for SIPForum or some other group to make > an agreement about a convention that does things this way. > > But it is a hack. It is not a *clean* way to do it. I expect more from > IETF approved documents. Maybe we are to the point with SIP where there > is too much inertia to afford "clean", and that hacks are now the way > forward. But if so, that is at least sad. > > Thanks, > Paul > > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Saturday, October 17, 2009 12:08 PM > >> > >> I think you've got a hold of an absolutely critical, core piece of SIP > >> functionality. You're either revising or replacing one of the > >> fundamental SIP methods, dating to before RFC 2543. That says > SIPCORE to > >> me. > > > > We're not updating 3261, 3262, or 3263. We're not revising or > replacing REGISTER. We're extending, using an options-tag to indicate > it. Otherwise what you're saying is every extension that needs an > options-tag for any request Method name documented in 3261 needs to be > in sipcore - including any applying to INVITE. I don't think you want > that. > > > > > >> I believe that the same objections that might prevent you from making a > >> "standards track" solution would also keep you from making an > >> informational solution. You might not notice, but we've held even the > >> info track documents to a high level of review. > > > > There would be nothing to discuss. It wouldn't require an > informational draft to even be published. There's enough wiggle room > in 3261 routing procedures and Registration procedures to avoid any > need - the draft would effectively be an "FYI". Effectively it would > be something along the lines of the older > draft-kaplan-dispatch-sip-implicit-registrations-00. > > > > We would register an AoR in a REGISTER transaction - for requests to > that specific AoR things would follow 3261 as is. For all intents, > it's a fake AoR. Internally, in the Registrar DB, that AoR's > reachability information (contact/path) would just > not-so-coincidentally happen to be used for Route header fields for > that domain. Since that routing portion is effectively up to local > policy (ie, implementations), it would comply with 3261 as well. > Nothing in 3261 demands that local policy routing results follow any > prescribed data, so we'd just document that it happens to be data > populated from that AoR's reachability data. > > > > There isn't even a need for a new header. We'd just try for one to > help troubleshooting and avoiding erroneous manual configuration. > > > > -hadriel > > _______________________________________________ > > 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 fluffy@cisco.com Mon Oct 19 11:43: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 02D4C3A69B0 for ; Mon, 19 Oct 2009 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=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 wP7P2EqK6hSi for ; Mon, 19 Oct 2009 11:43:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B7F253A69A6 for ; Mon, 19 Oct 2009 11:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=9456; q=dns/txt; s=sjiport01001; t=1255977815; x=1257187415; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Fwd:=20New=20Liaison=20Statement,=20"Cybersecurity=20i nformation=20exchange=20=20=20=20=20=20=20=20=20=20framew ork=20and=20related=20IETF=20activities"=20|Date:=20Mon, =2019=20Oct=202009=2012:43:32=20-0600|Message-Id:=20<3427 0D15-41CB-47AE-9EA4-25E9FD00DD6F@cisco.com>|To:=20dispatc h@ietf.org|Mime-Version:=201.0=20(Apple=20Message=20frame work=20v936)|References:=20<20091019172959.3FC963A693E@co re3.amsl.com>; bh=FXymA4QJwSgaeJHy+pUB4g+GI35TPMeex1WfA9mgA7A=; b=yz3V/d2SdQJ57beXpX9gvn9/IkQ250rpD8I9mC+ttltSEGUKl3kgWmlk rBn65f5/crO9V1uAwu4b1S1SDoIkR0K43rKgIDs8+Zi8yx8W6SKf+VjoO mWo2zvFJj5h0wFhzSMGUM17aCVOEudra50PFK1rCtqDFR9dXE+CxtOF0V s=; 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: ApwEAJtP3EqrR7Hu/2dsb2JhbACCJy3BepcKhDEEgVs X-IronPort-AV: E=Sophos;i="4.44,586,1249257600"; d="scan'208,217";a="258100495" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2009 18:43:34 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9JIhYWg022817 for ; Mon, 19 Oct 2009 18:43:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:43:34 -0400 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:43:33 -0400 Message-Id: <34270D15-41CB-47AE-9EA4-25E9FD00DD6F@cisco.com> From: Cullen Jennings To: dispatch@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: multipart/alternative; boundary=Apple-Mail-2-645221799 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 12:43:32 -0600 References: <20091019172959.3FC963A693E@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Oct 2009 18:43:33.0789 (UTC) FILETIME=[0F9C5CD0:01CA50EC] Subject: [dispatch] Fwd: New Liaison Statement, "Cybersecurity information exchange framework and related IETF activities" 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, 19 Oct 2009 18:43:31 -0000 --Apple-Mail-2-645221799 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI.... Begin forwarded message: > From: "Georges Sebek(ITU-T SG 17)" > Date: October 19, 2009 11:29:59 AM MDT (CA) > To: , , >, , , >, , , >, , , > > Cc: , "Cullen Jennings (fluffy)" >, , "Patrik Faltstrom (pfaltstr)" , >, , > Subject: New Liaison Statement, "Cybersecurity information > exchange framework and related IETF activities" > Reply-To: , > > > Title: Cybersecurity information exchange framework and related IETF > activities > Submission Date: 2009-10-19 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=600 > Please reply by 2010-03-31 > > From: Georges Sebek(ITU-T SG 17) > To: IETF SIP related Working Groups and IESG(shida@ntt-at.com, scott.lawrence@nortel.com > , richard@shockey.us, alexander.mayrhofer@enum.at, dguyton@telcordia.com > , br@brianrosen.net, dbryan@ethernot.org, > hisham.khartabil@gmail.com, ben@nostrum.com, > spencer@wonderhamster.org, theo@voip.co.uk, gonzalo.c) > Cc: rjsparks@nostrum.com > fluffy@cisco.com > iesg@ietf.org > paf@cisco.com > Reponse Contact: tsbsg17@itu.int > sebek@itu.int > Technical Contact: tony@yaanatech.com > Purpose: For comment > Body: Please find attached a liaison statement, COM 17-LS 53 agreed > to at the September 2009 ITU-T Study Group 17 (Security) meeting. It > has two attachments > Attachment(s): > COM 17-LS 53 (https://datatracker.ietf.org/documents/LIAISON/file715.pdf > ) > Draft Recommendation ITU-T X.cybex (https://datatracker.ietf.org/documents/LIAISON/file716.pdf > ) > Draft Recommendation ITU-T X.sips (https://datatracker.ietf.org/documents/LIAISON/file717.pdf > ) > > > > --Apple-Mail-2-645221799 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
From: = "Georges Sebek(ITU-T SG 17)" <tsbsg17@itu.int>
Date: = October 19, 2009 11:29:59 AM MDT (CA)
Cc: <rjsparks@nostrum.com>, = "Cullen Jennings (fluffy)" <fluffy@cisco.com>, <iesg@ietf.org>, "Patrik Faltstrom = (pfaltstr)" <paf@cisco.com>, = <tsbsg17@itu.int>, <sebek@itu.int>, <tony@yaanatech.com>
=
Subject: = New Liaison Statement, "Cybersecurity information = exchange      =     framework and related IETF activities" 
Reply-To: = <tsbsg17@itu.int>,= <sebek@itu.int>


Title: = Cybersecurity information exchange framework and related IETF = activities
Submission Date: 2009-10-19
URL of the IETF Web page: = https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D60= 0
Please reply by 2010-03-31

From: Georges Sebek(ITU-T = SG 17) <tsbsg17@itu.int>
= To: IETF SIP related Working Groups and IESG(shida@ntt-at.com, scott.lawrence@nortel.com, = richard@shockey.us, alexander.mayrhofer@enum.at, dguyton@telcordia.com, = br@brianrosen.net, dbryan@ethernot.org, hisham.khartabil@gmail.com,= ben@nostrum.com, spencer@wonderhamster.org, = theo@voip.co.uk, gonzalo.c)
= Cc: rjsparks@nostrum.com
= fluffy@cisco.com
iesg@ietf.org
paf@cisco.com
Reponse Contact: tsbsg17@itu.int
sebek@itu.int
Technical Contact: = tony@yaanatech.com
= Purpose: For comment
Body: Please find attached a liaison statement, = COM 17-LS 53 agreed to at the September 2009 ITU-T Study Group 17 = (Security) meeting. It has two attachments
Attachment(s):
=      COM 17-LS 53 (https:= //datatracker.ietf.org/documents/LIAISON/file715.pdf)
=      Draft Recommendation ITU-T X.cybex (https:= //datatracker.ietf.org/documents/LIAISON/file716.pdf)
=      Draft Recommendation ITU-T X.sips (https:= //datatracker.ietf.org/documents/LIAISON/file717.pdf)


=


= --Apple-Mail-2-645221799-- From john.elwell@siemens-enterprise.com Mon Oct 19 12:50: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 F2BAB28C131 for ; Mon, 19 Oct 2009 12:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_82=0.6, MANGLED_REGSTR=2.3, 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 0D88zGBYKeTk for ; Mon, 19 Oct 2009 12:50:28 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 350753A67B3 for ; Mon, 19 Oct 2009 12:50:24 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9JJoTqN008312; Mon, 19 Oct 2009 21:50:29 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9JJoShp010093; Mon, 19 Oct 2009 21:50:28 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Mon, 19 Oct 2009 21:50:28 +0200 From: "Elwell, John" To: Brian Lindsay , Richard Shockey , Hadriel Kaplan , "dispatch@ietf.org" Date: Mon, 19 Oct 2009 21:50:25 +0200 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpQxKs6J4E6b8poSLmdkwQ5NmYZRQAFIipAAABDfRAABpSkwA== Message-ID: <7402509E63C5A145A6095D46C179A5B71477DF45@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> <036201ca50d9$e8efb7b0$bacf2710$@us> <09B7DBFE70A9E24BBB21689DAD3A06141B04CD7D@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141B04CD7D@zcarhxm1.corp.nortel.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 19:50:30 -0000 REGISTER-based solutions are what exist in the field, unfortunately with sl= ight variations. The domain registration draft aims at standardising someth= ing pretty close to all of these, and therefore is not too much of an ask t= o get present deployments upgraded to support it. Although there are undoub= tedly other approaches to solving the problem, they are unlikely to cause p= resent service providers and PBXs to depart from their present REGISTER-bas= ed practice. I support what Brian, Richard and several others are saying. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Brian Lindsay > Sent: 19 October 2009 17:44 > To: Richard Shockey; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch]=20 > DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration >=20 > Hi, >=20 > Would like to chime in and express support for > standardization/formalization of a REGISTER-based solution to this > problem, to address the SIP PBX problem space in a timely fashion by > building on currently deployed approaches, rather than inventing > something new. The draft should be DISPATCH'ed in a manner to best > facilitate that. >=20 > Thanks. >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Richard Shockey > Sent: Monday, October 19, 2009 12:34 PM > To: 'Paul Kyzivat'; 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Subject: Re: > [dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain- > registrati > on >=20 > Paul please remember ..we are trying to fix something that is in the > field right now and widely deployed that is causing interoperability > problems. =20 >=20 > There are probably better ways to approach the bindings between PBX's > and SSP's and the larger issues of provisioning but that is=20 > not what the > draft is trying to accomplish and there is a substantial=20 > community here > that is trying to do the right thing.=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On >=20 > > Behalf Of Paul Kyzivat > > Sent: Monday, October 19, 2009 10:01 AM > > To: Hadriel Kaplan > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch]=20 > DomainRegistrationDraftdraft-kaplan-dispatch- > > domain-registration > > =20 > > I continue to sit on the fence about this one: > > =20 > > I understand and agree with what Hadriel is saying about this=20 > > behavior falling within the latitude given to proxies on how they > route things. > > Thus I think it is *conforming* for SIPForum or some other=20 > group to =20 > > make an agreement about a convention that does things this way. > > =20 > > But it is a hack. It is not a *clean* way to do it. I expect more=20 > > from IETF approved documents. Maybe we are to the point with SIP=20 > > where there is too much inertia to afford "clean", and that hacks=20 > > are now the way forward. But if so, that is at least sad. > > =20 > > Thanks, > > Paul > > =20 > > Hadriel Kaplan wrote: > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> Sent: Saturday, October 17, 2009 12:08 PM >> >> I=20 > think you've=20 > > got a hold of an absolutely critical, core piece of SIP >>=20 > > functionality. You're either revising or replacing one of the >>=20 > > fundamental SIP methods, dating to before RFC 2543. That=20 > says SIPCORE >=20 > > to >> me. > > > > > > We're not updating 3261, 3262, or 3263. We're not revising or =20 > > replacing REGISTER. We're extending, using an options-tag=20 > to indicate >=20 > > it. Otherwise what you're saying is every extension that needs an =20 > > options-tag for any request Method name documented in 3261=20 > needs to be >=20 > > in sipcore - including any applying to INVITE. I don't=20 > think you want >=20 > > that. > > > > > > > > >> I believe that the same objections that might prevent you from =20 > > making a >> "standards track" solution would also keep you from=20 > > making an >> informational solution. You might not notice,=20 > but we've=20 > > held even the >> info track documents to a high level of review. > > > > > > There would be nothing to discuss. It wouldn't require an =20 > > informational draft to even be published. There's enough=20 > wiggle room >=20 > > in 3261 routing procedures and Registration procedures to=20 > avoid any =20 > > need - the draft would effectively be an "FYI". =20 > Effectively it would >=20 > > be something along the lines of the older=20 > draft-kaplan-dispatch-sip- =20 > > implicit-registrations-00. > > > > > > We would register an AoR in a REGISTER transaction - for=20 > requests=20 > > to that specific AoR things would follow 3261 as is. For all=20 > > intents, it's a fake AoR. Internally, in the Registrar DB, that=20 > > AoR's reachability information (contact/path) would just not-so- =20 > > coincidentally happen to be used for Route header fields for that =20 > > domain. Since that routing portion is effectively up to=20 > local policy >=20 > > (ie, implementations), it would comply with 3261 as well. =20 > Nothing in > > 3261 demands that local policy routing results follow any=20 > prescribed >=20 > > data, so we'd just document that it happens to be data=20 > populated from >=20 > > that AoR's reachability data. > > > > > > There isn't even a need for a new header. We'd just try=20 > for one to >=20 > > help troubleshooting and avoiding erroneous manual configuration. > > > > > > -hadriel > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 richard@shockey.us Mon Oct 19 13:42: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 C44AD3A67FF for ; Mon, 19 Oct 2009 13:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.351, 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 wj92p+N84AuF for ; Mon, 19 Oct 2009 13:42:41 -0700 (PDT) Received: from outbound-mail-311.bluehost.com (outbound-mail-311.bluehost.com [67.222.54.4]) by core3.amsl.com (Postfix) with SMTP id AB06E3A6904 for ; Mon, 19 Oct 2009 13:42:41 -0700 (PDT) Received: (qmail 27858 invoked by uid 0); 19 Oct 2009 20:42:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 19 Oct 2009 20:42:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=CcznhkygKCB36x16Mkeldy8P0xfqZ6WLlfU7QJdOKp9VIvF1/u18bkOYqker6QpzqiunHauuVQGIAzxnOpRDvC8ZOVWQQ0H3yy7UszE4QJFeniO5N9W2OL0rZLvCZnut; 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 1Mzz44-0002yU-E5 for dispatch@ietf.org; Mon, 19 Oct 2009 14:42:48 -0600 From: "Richard Shockey" To: Date: Mon, 19 Oct 2009 16:42:45 -0400 Message-ID: <04dc01ca50fc$b6d1e4b0$2475ae10$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_04DD_01CA50DB.2FC044B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpQZDnKlUGwa9yRSeieNfmCjAWkdwAmF/Gg 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: [dispatch] FW: I-D Action:draft-roychowdhury-6lowappsip-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: Mon, 19 Oct 2009 20:42:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04DD_01CA50DB.2FC044B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For your reading pleasure... -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Sunday, October 18, 2009 10:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-roychowdhury-6lowappsip-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Motivation for SIP as an application protocol for 6lowpan devices Author(s) : A. Roychowdhury, S. Gouran Filename : draft-roychowdhury-6lowappsip-00.txt Pages : 10 Date : 2009-10-18 The Smart Grid [8] initiative is an effort in modernization of the electricity grid using communication technology with the primary goals of reducing energy consumption, reducing cost (utilities and consumers), increasing reliability and the creation of new services for all participants in the value chain. The core focus of this initiative is the specification of a 'Communications Overlay' network which can help facilitate intelligent communication (discovery, session establishment, routing, addressing to name a few) between various nodes of the heterogeneous Smart Grid network. Motivation for SIP as an application protocol for 6lowpan devices One of the 'network segments' of the Smart Grid network is the Home Area Network (HAN) and how residential and/or commercial devices (such as TV, washing machine, surveillance camera, etc.) interact with the smart meter/energy management system and vice-versa. This draft is an initial input for consideration of SIP as an appropriate application protocol for use inside devices that operate over low powered IP networks. The authors do NOT propose the use of SIP for all HAN devices. Rather, the authors believe that SIP is an appropriate protocol for certain categories of devices and therefore, the 6lowapp group should consider SIP as an appropriate protocol for the same. The final protocol that is ideal for a particular device communication will always be determined by the use-case(s) that are envisioned for the same. This draft does NOT discuss the use of SIP inside the smart meter (while the authors believe that the smart meter would also benefit from SIP, that is the scope of another draft and does not apply to the 6lowapp work). Therefore, in all diagrams and references, the authors have used the term 'Energy Management System (EMS)' to refer to the customer premise EMS that may or may not be the smart meter itself. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. The term EMS refers to the customer premise Energy Management System which may be the smart meter or an adjunct devices that communicates with the utility core network for the purposes of energy management and billing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roychowdhury-6lowappsip-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. ------=_NextPart_000_04DD_01CA50DB.2FC044B0 Content-Type: Message/External-body; name="draft-roychowdhury-6lowappsip-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-roychowdhury-6lowappsip-00.txt" Content-Type: text/plain Content-ID: <2009-10-18192833.I-D@ietf.org> ------=_NextPart_000_04DD_01CA50DB.2FC044B0 Content-Type: text/plain; name="ATT00377.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00377.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_04DD_01CA50DB.2FC044B0-- From pkyzivat@cisco.com Mon Oct 19 13:44: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 8DA8B3A6933; Mon, 19 Oct 2009 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 E1ub6bAJBiAE; Mon, 19 Oct 2009 13:44:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C093C3A6975; Mon, 19 Oct 2009 13:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4619; q=dns/txt; s=rtpiport02001; t=1255985054; x=1257194654; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20New=20version=20for=20the=20Alert-I nfo=20URNs=20draft:=09draft-liess-dispatch-alert-info-urn s-00.txt|Date:=20Mon,=2019=20Oct=202009=2016:44:03=20-040 0|Message-ID:=20<4ADCCF93.2070208@cisco.com>|To:=20L.Lies s@telekom.de|CC:=20dispatch@ietf.org,=20bliss@ietf.org, =20anwars@avaya.com,=20R.Jesske@telekom.de|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20< 40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost. t-com.de>|References:=20<40FB0FFB97588246A1BEFB05759DC8A0 038854EC@S4DE9JSAANI.ost.t-com.de>; bh=fupIlR0ByZHkOMTN6/M1E/nSm5T+7SlnyUaMQkPoNK4=; b=Q8CsLiesp0bkzOnW8sIUfUywg7pCFZgwpWPWVvILSQjCIByueuhZQ0T1 ql2gFx2nb1BLtjvvYXLEQWTquyPdUHUWdvXRw4xPKxkKoMZEOuAWBpW+P 9PAT/4bNlsu5fkboDwBvdHwSSjpW/hDRIV4t4XQ2pFwuS+yHlLo0V80pP M=; 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: ApoEAPdr3EqtJV2b/2dsb2JhbADDX5cYgjmBeAQ X-IronPort-AV: E=Sophos;i="4.44,587,1249257600"; d="scan'208";a="63854079" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2009 20:44:13 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id n9JKi7hd031437; Mon, 19 Oct 2009 20:44:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 16:44:11 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 16:44:11 -0400 Message-ID: <4ADCCF93.2070208@cisco.com> Date: Mon, 19 Oct 2009 16:44:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 20:44:11.0300 (UTC) FILETIME=[E980E640:01CA50FC] Cc: bliss@ietf.org, dispatch@ietf.org, R.Jesske@telekom.de, anwars@avaya.com Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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: Mon, 19 Oct 2009 20:44:08 -0000 This seems to be shaping up well. I think the requirements are quite clear now. I don't fully understand what is intended regarding combination of multiple alert URNs for a specific situation. Section 4.5 states: > finally, a short Albanian auto-callback tone could be indicated > Alert-Info: , > , . while section 7.3.6 states: > Alert URN Indications from the same group should not be combined. I could find no definition of what constitutes a "group". The first thing that comes to mind is "service" vs. "tone", but the above example violates that. It seems to me that you need some notion of orthogonal properties in order to define what can/cannot be combined. It would be good to have more detail about how a recipient should deal with multiple URNs. I'm also uncertain of what your intent is regarding top-level vs. additional indications. As specified, I believe a given "additional indication" name is always defined with regard to its parent, so that "short" as used in "normal.short" might mean something entirely different than "priority.short", or might not be defined for priority at all. Yet from the registration text in 7.3.2 it sounds like the intent is for priority, short, and delayed to be defined for all pbx-tones. If that is the intent, then I don't think the existing text meets that intent. I also wonder if the existing hierarchy will work well in practice, or if some other organization might not work better. For instance, it might be more convenient to specify ringing.fr with the clear understanding that if you don't know about ringing.fr you can just treat it as ringing. I'm also confused by PBX tones vs. Public telephone tones. In what way is "normal" different from "ringing"? I would think that PBX tones would be a superset of common pstn tones. A nit: in 4.3.2 I would expext the forward to be indicated, if at all, with a 181 rather than a 180. Thanks, Paul L.Liess@telekom.de wrote: > > Hi, > > We've re-submitted the Alert-Info URNs draft for DISPATCH > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns > -00.txt . (The previous version od the draft was in BLISS and we had a > presentation in BLISS at the last IETF.) > > We did some major changes, as suggested on the mailing list, e.g.: > Added: > - Description of the interoperability problems for PBX-services (in > the Introduction chapter) > - Requirements for the Alert-Info URNs mechanism > - Alert-Info URNs Indications for country-specific tones > Changed: > - Initial IANA Registration mechanism to avoid combinatorial explosion > of IANA values. > > > Many thanks for the comments and suggestions, > Laura > > > > > > -----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, October 19, 2009 1:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Alert-Info URNs for the Session Initiation > Protocol (SIP) > Author(s) : D. Alexeitsev, et al. > Filename : draft-liess-dispatch-alert-info-urns-00.txt > Pages : 25 > Date : 2009-10-19 > > The Session Initiation Protocol (SIP) supports the capability to > provide a reference to the alternative ringback tone (RBT) for > caller, or ring tone (RT) for callee using the Alert-Info header. > However, the reference addresses only the network resources with > specific rendering properties. There is currently no support for > predefined standard identifiers for ringback tones or semantic > indications without tied rendering. To overcome this limitations and > support new applications a family of the URNs is defined in this > specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns > -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 dworley@nortel.com Mon Oct 19 14:00: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 432983A6922 for ; Mon, 19 Oct 2009 14:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 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 KM9ygaKw3Hcb for ; Mon, 19 Oct 2009 14:00:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2D8933A67B8 for ; Mon, 19 Oct 2009 14:00:55 -0700 (PDT) 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 n9JL0t922181; Mon, 19 Oct 2009 21:00:55 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 17:00:54 -0400 From: "Dale Worley" To: Cullen Jennings In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 19 Oct 2009 17:00:53 -0400 Message-Id: <1255986053.3767.46.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: 19 Oct 2009 21:00:54.0274 (UTC) FILETIME=[3F529620:01CA50FF] Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 21:00:56 -0000 On Tue, 2009-10-13 at 13:06 -0600, Cullen Jennings wrote: > The SIP Forum has recently sent us the draft > > http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt Is there any way we can get the name of the activity changed to be something other than "domain registration"? "Domain registration" already has a well-defined meaning -- registering one's domain with the DNS system -- and this mechanism is intended only for situations where that is *not* being done. In addition, there is the SIP concept of registering the contact for an AOR, which adds a second meaning to "registration". Dale From spencer@wonderhamster.org Mon Oct 19 14:33: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 8DAB228C112 for ; Mon, 19 Oct 2009 14:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=0.239, 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 BGhWsTtPkGx3 for ; Mon, 19 Oct 2009 14:33:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B63AB3A659A for ; Mon, 19 Oct 2009 14:33:45 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lb441-1MXYr83zNx-00kCRw; Mon, 19 Oct 2009 17:33:47 -0400 Message-ID: From: "Spencer Dawkins" To: "Dale Worley" , "Cullen Jennings" References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1255986053.3767.46.camel@khone.us.nortel.com> Date: Mon, 19 Oct 2009 16:33:37 -0500 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/l0+nqGdUSHF6D1yC6YkvHFJYSBq4uDOE2H1U QA6Hq0TEJKwRSReedCNxeL4zBNkNlLXha+7pshnVYHWrI3oY+C /cibJkJYYp6iYZPYEa8qOJn981Dk7Zfo50bMMP5/Tc= Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain RegistrationDraft draft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 21:33:46 -0000 Without speaking for the draft author, I think "domain" is open for suggestions. The SIPconnect working group has gone through "registration" with no qualifier, "implicit registration", and I think "bulk registration" was also tossed in but sank without a ripple, so we're obviously not wedded to "domain". "registration" is harder for me to think of alternatives for, because we think we're achieving roughly the same end-game as per-AOR registration, and we're currently using the REGISTER method. But please make suggestions - my problem could easily be my own lack of imagination! Thanks, Spencer > On Tue, 2009-10-13 at 13:06 -0600, Cullen Jennings wrote: >> The SIP Forum has recently sent us the draft >> >> http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > Is there any way we can get the name of the activity changed to be > something other than "domain registration"? "Domain registration" > already has a well-defined meaning -- registering one's domain with the > DNS system -- and this mechanism is intended only for situations where > that is *not* being done. > > In addition, there is the SIP concept of registering the contact for an > AOR, which adds a second meaning to "registration". > > Dale From alan@sipstation.com Mon Oct 19 14:44: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 1DD3028C1BD for ; Mon, 19 Oct 2009 14:44:09 -0700 (PDT) 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 47v1OLeEyOEc for ; Mon, 19 Oct 2009 14:44:07 -0700 (PDT) Received: from outbound-mail-352.bluehost.com (outbound-mail-352.bluehost.com [66.147.249.13]) by core3.amsl.com (Postfix) with SMTP id CE6FB28C11A for ; Mon, 19 Oct 2009 14:44:06 -0700 (PDT) Received: (qmail 17360 invoked by uid 0); 19 Oct 2009 21:44:13 -0000 Received: from unknown (HELO host350.hostmonster.com) (66.147.240.150) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 19 Oct 2009 21:44:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sipstation.com; h=Received:References:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Mailer:Mime-Version:Subject:Date:Cc:X-Identified-User; b=ZhJ5SDVJk/wQk4M6kKErYZXUaQd3y34M3h5r3TK1ng1HAJwuVVAuXmEc8JfwNm08kCq38ND12a9YKTlUmmQKEm9gu1O//krPpIQCiymr6SAzcHYP1qE56h4gRVnJ+SB1; Received: from [166.189.246.148] (helo=[10.132.148.58]) by host350.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1N001T-0000uH-5B; Mon, 19 Oct 2009 15:44:13 -0600 References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> <4ADCB260.1040108@neustar.biz> Message-Id: <19E5A74F-5817-4AC2-9D5C-C1B80C8FF1F0@sipstation.com> From: Alan Johnston To: Jon Peterson In-Reply-To: <4ADCB260.1040108@neustar.biz> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Mon, 19 Oct 2009 16:44:17 -0500 X-Identified-User: {2451:host350.hostmonster.com:aeternus:sipstation.com} {sentby:smtp auth 166.189.246.148 authed with alan+sipstation.com} Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 19 Oct 2009 21:44:09 -0000 I agree 100% with Jon that SIPCORE and normative updates to RFC 326x would not be needed. I also have sympathies for a PUBLISH based mechanism. One could definitely define an interconnect event package which could have all kinds of interesting information in it besides just a URI (congestion information, alternate routes, services available, etc). This would be a good multi-year task for a working group. Unfortunately, this doesn't meet the needs for simple SIP trunking, where the mechanism must be REGISTER based for the reasons Hadriel oulined earlier. Thanks, Alan On Oct 19, 2009, at 1:39 PM, Jon Peterson wrote: > > The question of whether or not the mechanism can (or should) be > improved is entirely separable from whether or not it normatively > updates RFC3261 or 3263. Well, even before that separation, we > should quarantine the problem from the solution here: I'd say the > problem should be able to live outside of SIPCORE, and if the > eventual solution does entail a normative update to one of the > SIPCORE specs, then certainly it must have gone down the wrong path. > I see no serious bar to bringing this work to DRINKS. > > Once it does have a home, then we can see if the solution can be > improved on the way through. Again, personally I'd have some few > words to say in favor of doing this with PUBLISH. > > Jon Peterson > NeuStar, Inc. > > Paul Kyzivat wrote: >> >> I continue to sit on the fence about this one: >> >> I understand and agree with what Hadriel is saying about this >> behavior >> falling within the latitude given to proxies on how they route >> things. >> Thus I think it is *conforming* for SIPForum or some other group to >> make >> an agreement about a convention that does things this way. >> >> But it is a hack. It is not a *clean* way to do it. I expect more >> from >> IETF approved documents. Maybe we are to the point with SIP where >> there >> is too much inertia to afford "clean", and that hacks are now the way >> forward. But if so, that is at least sad. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >> >> -----Original Message----- >> >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> Sent: Saturday, October 17, 2009 12:08 PM >> >> >> >> I think you've got a hold of an absolutely critical, core piece >> of SIP >> >> functionality. You're either revising or replacing one of the >> >> fundamental SIP methods, dating to before RFC 2543. That says >> SIPCORE to >> >> me. >> > >> > We're not updating 3261, 3262, or 3263. We're not revising or >> replacing REGISTER. We're extending, using an options-tag to >> indicate it. Otherwise what you're saying is every extension that >> needs an options-tag for any request Method name documented in 3261 >> needs to be in sipcore - including any applying to INVITE. I don't >> think you want that. >> > >> > >> I believe that the same objections that might prevent you from >> making a >> >> "standards track" solution would also keep you from making an >> >> informational solution. You might not notice, but we've held >> even the >> >> info track documents to a high level of review. >> > >> > There would be nothing to discuss. It wouldn't require an >> informational draft to even be published. There's enough wiggle >> room in 3261 routing procedures and Registration procedures to >> avoid any need - the draft would effectively be an "FYI". >> Effectively it would be something along the lines of the older >> draft-kaplan-dispatch-sip-implicit-registrations-00. > >> > We would register an AoR in a REGISTER transaction - for requests >> to that specific AoR things would follow 3261 as is. For all >> intents, it's a fake AoR. Internally, in the Registrar DB, that >> AoR's reachability information (contact/path) would just not-so- >> coincidentally happen to be used for Route header fields for that >> domain. Since that routing portion is effectively up to local >> policy (ie, implementations), it would comply with 3261 as well. >> Nothing in 3261 demands that local policy routing results follow >> any prescribed data, so we'd just document that it happens to be >> data populated from that AoR's reachability data. > >> > There isn't even a need for a new header. We'd just try for one >> to help troubleshooting and avoiding erroneous manual configuration. >> > >> > -hadriel >> > _______________________________________________ >> > 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 >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Mon Oct 19 21:35: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 8BF693A6897 for ; Mon, 19 Oct 2009 21:35:42 -0700 (PDT) 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 hYh9SCzl6aSg for ; Mon, 19 Oct 2009 21:35:41 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B40BC3A68E4 for ; Mon, 19 Oct 2009 21:35:41 -0700 (PDT) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9K4YNNL029540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Oct 2009 23:34:25 -0500 Message-Id: <2BF7C0D9-BD3F-41A8-A891-A1454DA547F0@softarmor.com> From: Dean Willis To: Dale Worley In-Reply-To: <1255986053.3767.46.camel@khone.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 23:34:17 -0500 References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1255986053.3767.46.camel@khone.us.nortel.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 04:35:42 -0000 On Oct 19, 2009, at 4:00 PM, Dale Worley wrote: > On Tue, 2009-10-13 at 13:06 -0600, Cullen Jennings wrote: >> The SIP Forum has recently sent us the draft >> >> http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt > > Is there any way we can get the name of the activity changed to be > something other than "domain registration"? "Domain registration" > already has a well-defined meaning -- registering one's domain with > the > DNS system -- and this mechanism is intended only for situations where > that is *not* being done. > > In addition, there is the SIP concept of registering the contact for > an > AOR, which adds a second meaning to "registration". Indeed. REGISTER also has yet another meaning in the mobile phone world. It's a seriously overloaded term. What we are really talking about doing is dynamic route exchange, where the targets of the routes involved are "domains". We could call it "dynamic SIP domain routing", "SIP domain route exchange"', or, as I proposed, "SIP routing updates", which fits nicely with the proposed ROUTEUP method. The thing that the proponents of Hadriel's draft are missing is that the hacky part is not the registration of the routes. It's not even how the routes are used. The hacky part of the proposal is the way the routes are constructed so that they look like AORs, which allows them to be conveyed in a syntactically (but not semantically) correct REGISTER. This is a big hack. If we are taking this to a "standard", we need to make something that is less hacky, more regular, and possible to get "right". -- Dean From dean.willis@softarmor.com Mon Oct 19 22:00: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 DDD753A698A for ; Mon, 19 Oct 2009 22:00:33 -0700 (PDT) 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 HFlJxTpoFuy9 for ; Mon, 19 Oct 2009 22:00:33 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0463C3A6863 for ; Mon, 19 Oct 2009 22:00:32 -0700 (PDT) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9K50aJf029703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Oct 2009 00:00:38 -0500 Message-Id: <191269E7-30DA-435B-B2E3-6C3F5E4D5465@softarmor.com> From: Dean Willis To: Alan Johnston In-Reply-To: <19E5A74F-5817-4AC2-9D5C-C1B80C8FF1F0@sipstation.com> 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, 20 Oct 2009 00:00:30 -0500 References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> <4ADCB260.1040108@neustar.biz> <19E5A74F-5817-4AC2-9D5C-C1B80C8FF1F0@sipstation.com> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 05:00:34 -0000 On Oct 19, 2009, at 4:44 PM, Alan Johnston wrote: > I agree 100% with Jon that SIPCORE and normative updates to RFC 326x > would not be needed. > > I also have sympathies for a PUBLISH based mechanism. One could > definitely define an interconnect event package which could have all > kinds of interesting information in it besides just a URI > (congestion information, alternate routes, services available, > etc). This would be a good multi-year task for a working group. But a simple PUBLISH-based mechanism would require no more text than a REGISTER-based mechanism, while providing easy graft-on points for the more advanced features you mention here. If it can be done in IETF in the same time frame as hacking up REGISTER would require, what's your problem? > Unfortunately, this doesn't meet the needs for simple SIP trunking, > where the mechanism must be REGISTER based for the reasons Hadriel > oulined earlier. That argument just doesn't hold up. We're told that it has to be REGISTER because of the huge installed base for the mechanism. Yet clearly, none of the installed base does it exactly the way that the draft proposes to do it. Further, the draft's proposed approach breaks many of the rules about how SIP operates (like its bogus use of Require to invoke a feature, contextual overloading of Contact to mean something else, and so on). We know we made mistakes early in SIP, but you'd think we'd have learned something by now about how not to repeat them. This approach, however, operates by combining a handful of existing mistakes in a new and misguided way to make something even more convoluted than I had imagined possible. Impressive, but still not a good idea. -- Dean From john.elwell@siemens-enterprise.com Tue Oct 20 00:41: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 221853A67E1 for ; Tue, 20 Oct 2009 00:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HELO_EQ_DE=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 MQCv5tff+CCt for ; Tue, 20 Oct 2009 00:41:35 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 23BC83A6782 for ; Tue, 20 Oct 2009 00:41:34 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9K7f77m022450; Tue, 20 Oct 2009 09:41:07 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9K7f7pm025484; Tue, 20 Oct 2009 09:41:07 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Tue, 20 Oct 2009 09:41:06 +0200 From: "Elwell, John" To: Paul Kyzivat , "L.Liess@telekom.de" Date: Tue, 20 Oct 2009 09:41:04 +0200 Thread-Topic: [BLISS] [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: AcpQ/PApDBRz4JVPTcOGvT+G9PL4BgAWJcyg Message-ID: <7402509E63C5A145A6095D46C179A5B71477DF70@DEMCHP99E35MSX.ww902.siemens.net> References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> In-Reply-To: <4ADCCF93.2070208@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "anwars@avaya.com" , "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] [BLISS] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 20 Oct 2009 07:41:38 -0000 (I have removed the BLISS cross-post, by the way). I agree with the points Paul makes. In addition, I am concerned about some = of the values: 1. In 4.3.8, the value "short" is defined. This seems to have nothing to do= with the meaning of a tone, but the way it is rendered. So in one locale, = a short form of ring tone might denote low priority, say, whereas in anothe= r locale it might mean urgent, yet in a third locale it might mean some for= m of recall. Also, if my device renders tones visually, does displaying the= alert icon or message only for a short period make sense? Finally, what do= es "short" mean to an automaton? 2. Given that Alert-Info is defined only for use in an INVITE request or a = 180 response, how would values such as "busy", "intrusion" and "record" be = used? John =20 > -----Original Message----- > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf Of Paul Kyzivat > Sent: 19 October 2009 21:44 > To: L.Liess@telekom.de > Cc: bliss@ietf.org; dispatch@ietf.org; R.Jesske@telekom.de;=20 > anwars@avaya.com > Subject: Re: [BLISS] [dispatch] New version for the=20 > Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt >=20 > This seems to be shaping up well. I think the requirements are quite=20 > clear now. >=20 > I don't fully understand what is intended regarding combination of=20 > multiple alert URNs for a specific situation. Section 4.5 states: >=20 > > finally, a short Albanian auto-callback tone could be indicated > > Alert-Info: , > > , . >=20 > while section 7.3.6 states: >=20 > > Alert URN Indications from the same group should not be combined. >=20 > I could find no definition of what constitutes a "group". The first=20 > thing that comes to mind is "service" vs. "tone", but the=20 > above example=20 > violates that. It seems to me that you need some notion of orthogonal=20 > properties in order to define what can/cannot be combined. >=20 > It would be good to have more detail about how a recipient=20 > should deal=20 > with multiple URNs. >=20 > I'm also uncertain of what your intent is regarding top-level vs.=20 > additional indications. As specified, I believe a given "additional=20 > indication" name is always defined with regard to its parent, so that=20 > "short" as used in "normal.short" might mean something entirely=20 > different than "priority.short", or might not be defined for=20 > priority at=20 > all. >=20 > Yet from the registration text in 7.3.2 it sounds like the=20 > intent is for=20 > priority, short, and delayed to be defined for all pbx-tones.=20 > If that is=20 > the intent, then I don't think the existing text meets that intent. >=20 > I also wonder if the existing hierarchy will work well in=20 > practice, or=20 > if some other organization might not work better. For=20 > instance, it might=20 > be more convenient to specify ringing.fr with the clear understanding=20 > that if you don't know about ringing.fr you can just treat it=20 > as ringing. >=20 > I'm also confused by PBX tones vs. Public telephone tones. In=20 > what way=20 > is "normal" different from "ringing"? I would think that PBX=20 > tones would=20 > be a superset of common pstn tones. >=20 > A nit: in 4.3.2 I would expext the forward to be indicated,=20 > if at all,=20 > with a 181 rather than a 180. >=20 > Thanks, > Paul >=20 > L.Liess@telekom.de wrote: > > =20 > > Hi, > >=20 > > We've re-submitted the Alert-Info URNs draft for DISPATCH > >=20 > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > -info-urns > > -00.txt . (The previous version od the draft was in BLISS=20 > and we had a > > presentation in BLISS at the last IETF.) > >=20 > > We did some major changes, as suggested on the mailing list, e.g.: > > Added: =20 > > - Description of the interoperability problems for=20 > PBX-services (in > > the Introduction chapter)=20 > > - Requirements for the Alert-Info URNs mechanism=20 > > - Alert-Info URNs Indications for country-specific tones > > Changed:=20 > > - Initial IANA Registration mechanism to avoid=20 > combinatorial explosion > > of IANA values.=20 > >=20 > >=20 > > Many thanks for the comments and suggestions, > > Laura=20 > >=20 > >=20 > >=20 > > =20 > >=20 > > -----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, October 19, 2009 1:00 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >=20 > > Title : Alert-Info URNs for the Session Initiation > > Protocol (SIP) > > Author(s) : D. Alexeitsev, et al. > > Filename : draft-liess-dispatch-alert-info-urns-00.txt > > Pages : 25 > > Date : 2009-10-19 > >=20 > > The Session Initiation Protocol (SIP) supports the capability to > > provide a reference to the alternative ringback tone (RBT) for > > caller, or ring tone (RT) for callee using the Alert-Info header. > > However, the reference addresses only the network resources with > > specific rendering properties. There is currently no support for > > predefined standard identifiers for ringback tones or semantic > > indications without tied rendering. To overcome this=20 > limitations and > > support new applications a family of the URNs is defined in this > > specification. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > -info-urns > > -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. > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > = From BeckW@telekom.de Tue Oct 20 02:34: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 0335B28C105 for ; Tue, 20 Oct 2009 02:34:38 -0700 (PDT) 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 GpRzvA0hjGYd for ; Tue, 20 Oct 2009 02:34:36 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 1630528C119 for ; Tue, 20 Oct 2009 02:34:34 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 20 Oct 2009 11:34:21 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:34:21 +0200 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: Tue, 20 Oct 2009 11:34:20 +0200 Message-ID: <4A956CE47D1066408D5C7EB34368A5110530375D@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft-beck-oauth-sip-eval-00.txt; using OAUTH to authenticate SIP requests Thread-Index: AcpRaH+DUYP0jb35TraZsivGUkmyBA== From: To: X-OriginalArrivalTime: 20 Oct 2009 09:34:21.0272 (UTC) FILETIME=[80CB0D80:01CA5168] Subject: [dispatch] New draft-beck-oauth-sip-eval-00.txt; using OAUTH to authenticate SIP requests 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, 20 Oct 2009 09:34:38 -0000 Hi, In the ongoing struggle to combine SIP and the web, I submitted a draft = about the combination of SIP and OAUTH. The Open Authentication Protocol (OAUTH) provides a method for clients to access server resources on behalf of another party. This document evaluates OAUTH's suitability as an authentication mechanism for the Session Initiation Protocol (SIP) for use cases where web applications want to interact with SIP servers without sharing user credentials. http://www.ietf.org/internet-drafts/draft-beck-oauth-sip-eval-00.txt As usual with drafts combining standards of two different WGs, there's = the problem which WG is suited best. Wolfgang Beck -- Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 61516282832 (Tel.)=20 http://www.telekom.com=20 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 Erleben, was verbindet. From gonzalo.camarillo@ericsson.com Tue Oct 20 05:28: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 B00563A6910 for ; Tue, 20 Oct 2009 05:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.164, 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 3ot93DMP29Dc for ; Tue, 20 Oct 2009 05:28:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CC01F3A6841 for ; Tue, 20 Oct 2009 05:28:16 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-65-4addace76cea Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 39.9A.24026.7ECADDA4; Tue, 20 Oct 2009 14:28:23 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 14:27:14 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 14:27:13 +0200 Message-ID: <4ADDACA1.6070405@ericsson.com> Date: Tue, 20 Oct 2009 15:27:13 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF207AFBDE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD405111FCE@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF20809164@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF20809164@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Oct 2009 12:27:13.0804 (UTC) FILETIME=[A74DD4C0:01CA5180] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 20 Oct 2009 12:28:18 -0000 Hi, yes, it seems that a normative RFC would be more appropriate if we decide to work on this. Cheers, Gonzalo Mary Barnes wrote: > Hi Roland, > > This list is fine for this discussion. The needed feedback from the WG right now is whether folks find the problem statement adequate and if they believe that an informational document is sufficient to resolve the requirements and address the concerns for which this document is intended. Based on past discussions, it seemed that normative changes to RFC 3326 might be needed to resolve some of the issues raised. For example, this thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00491.html > > Once we get feedback on the mailing list that folks agree the problem statement and proposed work item (it seems there is sufficient interest in general in solving the problem), the WG chairs can discuss with the ADs the appropriate place to progress the work. > > Thanks, > Mary. > > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, October 12, 2009 5:17 PM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses > > Hi Mary, > So I would like to go with the informal approach. > > When I started the discussion on this issue in advance to the Stockholm meeting I've got only feedback from DISPATCH and BLISS but not from SIPCORE. > BLISS see this issue within their scope because it solves interoperability problems with the PSTN/ISDN. > DISPATCH discussed the draft which resulted in the new version. > > Question for me now is should I ask again on all lists who will be responsible. Or is there an other way to go? > > > Best Regards > > Roland > > > -----Ursprüngliche Nachricht----- > Von: Mary Barnes [mailto:mary.barnes@nortel.com] > Gesendet: Montag, 12. Oktober 2009 19:05 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses > > Hi Roland, > > If you are just adding clarifications to the existing RFC, then it can be an informational document, similar to the model for the SIPPING WG offer-answer document. If you are changing any normative statements, then you need at least a standards track document as an "Update" to RFC 3326. And "Update" could still be used even if normative functionality is not changed if the clarifications are far more understandable integrated into RFC 3326. > > For an informational document we would still need to determine whether it would be AD sponsored or need a mini-WG or fits within SIPCORE, for example. > > > Regards, > Mary. > > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Tuesday, October 06, 2009 9:01 AM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses > > > Hi Mary, > Thank you for your clarification. So I will wait for that discussion. > > With regard to your question I'm not really clear what the best way would be. > > This behaviour would complete the behaviour of RFC 3326. And RFC 3326 gives clear guidance what to do with the case for Reason in Responses, so it is my understanding to have an own document. So that is my proposal. > > Question is now if it should be an informal document. If this is sufficient I'm happy with that way if not we should change the status. I would be happy on comments on this. > > Thank you and Best Regards > > Roland > > > > -----Ursprüngliche Nachricht----- > Von: Mary Barnes [mailto:mary.barnes@nortel.com] > Gesendet: Sonntag, 4. Oktober 2009 00:51 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses > > Hi Roland, > > Just an initial point of clarification in that we don't charter work items for the DISPATCH WG. We evaluate the scope of a problem, define a clear problem statement and proposed work item(s) and then determine where/how the work should be done. > > One thing that needs clarification in your charter proposal is whether you are proposing an informational document or an updates to RFC 3326. The charter item seems to imply an informational document, but can you please clarify? > > If we can agree to work on the problem on the mailing list, then you wouldn't necessarily need agenda time. So, WG feedback is needed here. > > Thanks, > Mary. > > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Friday, October 02, 2009 12:51 AM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses > > > Dear all, > I see that after my renewal of the draft only some comments were given. > We see this as an important issue to keep interoperability between PSTN and SIP networks. > > Meanwhile there is also a request on putting a Reason Header within a 183 Progress due to the fact that it is possible to put a Q.850 cause value within an ACM including an indication that an announcement is played. > > This case would be valuable for a PSTN - SIP -PSTN passing without any use of SIP-T. > > The main used case is to put the Reason Header within 4xx, 5xx, 6xx and 199 to send an specific indication either back into an other PSTN or an Application Server that can put an announcement into the path based on the ISUP cause. > > But nevertheless I Would like to see this draft on the agenda and at least as an Woki Item within DISPATCH. > > Best regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftrag von Mary Barnes > Gesendet: Donnerstag, 1. Oktober 2009 15:56 > An: dispatch@ietf.org > Betreff: [dispatch] DISPATCH IETF-76 plans > > Hi all, > > Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. > The following summarizes the status of the topics that had been previously put forth - both prior to Sept. 7th deadline and up through the 21st. Obviously, we have to balance interest and willingness to contribute to the work (based on mailing list discussions) with the fact that some folks were more conscientious in meeting the deadlines. > > We received charter proposals (problem statements/deliverables) for the following, with the current status highlighted. > > o Overload (received prior to Sept. 16th) - separate mailing list setup. > Needs more discussion. > > o CBUS: some good discussion on problem statement. Needs more discussion. > > o Session recording: updated charter proposal based on IETF-75 feedback. > Need more WG feedback. Is this ready? > > o Disaggregated media: Good level of interest > > o SIP - XMPP: High level of WG interest. Propose a separate Mailing list and Adhoc at IETF-76. > > o Alert-info URNs: Good level of interest. > > o NGN Reason: Some interest. Needs more discussion and scoping. > > The above items are the current targets for IETF-76 discussions. Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. > If we schedule adhocs, we will try to have those announced around the time the agenda is finalized. > > As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those > deadlines: > * - 00 documents: Oct. 19th (just over 2 weeks) > * all other documents: Oct. 26th (just over 3 weeks) > > Please keep in mind that the focus of discussions should be the problem > statement, scope and proposed deliverables for the topic. > > We did not receive charter proposals for the following. The current status is summarized: > o Third-party authorization: Pre-IETF-75 problem statement had some discussion. But, no discussion since that time. > o Identity: Document available. Need further discussion and WG feedback to refine requirements, problem statement, scope and deliverables/milestones. > o Domain registrations in SIP: Problem statement posted, but no deliverables/milestones or document. > o Reference to an earlier communication: Problem statement posted, but no deliverables/milestones or document. > > As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available early enough for the WG to provide feedback - i.e., you do not have to wait for the pre-meeting deadlines, which are more in the way of drop dead dates than optimal dates. > > Please, let the chairs know if there are any concerns. > > Thanks, > Mary Barnes > DISPATCH WG 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 gonzalo.camarillo@ericsson.com Tue Oct 20 05:31: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 722CE3A694A for ; Tue, 20 Oct 2009 05:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 OynuTe9M4c6M for ; Tue, 20 Oct 2009 05:31:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E0FB23A691C for ; Tue, 20 Oct 2009 05:31:20 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-75-4addad9e3570 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F7.C3.04191.E9DADDA4; Tue, 20 Oct 2009 14:31:27 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 14:31:26 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 14:31:26 +0200 Message-ID: <4ADDAD9E.9060706@ericsson.com> Date: Tue, 20 Oct 2009 15:31:26 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mary Barnes References: <458913680910120207s4f06ddd6tbbccb6d11531c269@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF207AF8BA@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF207AF8BA@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 12:31:26.0484 (UTC) FILETIME=[3DE9BD40:01CA5181] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Xavier Marjou Subject: Re: [dispatch] Comments on cc-uui topic 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, 20 Oct 2009 12:31:22 -0000 Hi, as we mentioned in Stockholm, in order to fully understand how good (or bad) the idea of mini WGs is, we need to run a few experiments to see how it works. Cheers, Gonzalo Mary Barnes wrote: > Hi Xavier, > > Unfortunately, there are NO chartered items for RFCs in the DISPATCH WG > under the new model documented in RFC3427bis. If a work item fits under > the charter of an existing WG or an update to the charter of an existing > WG is reasonable given the nature of the topic, then no new WG is > required. However, for items that do not fit within an existing WG, the > choices are to either progress as an individual AD sponsored document or > to establish a "mini-WG" to complete the work. > > The idea behind the "mini-WG"s is that the milestones/deliverables are > quite clear from the beginning and in many cases there would be just one > or two deliverables, with the milestones established to complete the > work fairly quickly. If the milestones are not completed in a timely > manner, then a WG may be closed. The advantage of this approach, versus > the past approach of pushing many standards track documents into SIP and > keeping many informational documents spanning a broad range of topics in > SIPPING, is that these mini-WGs are very focused, which is the true > intent of IETF working groups. With this model, there is far less > potential for documents to languish. While it might seem this approach > adds additional overhead, the overhead in establishing a new WG is > fairly low and the burden of such is on the ADs ;) This also allows the > ADs to pull additional folks into leadership positions since these > smaller WGs are far more manageable and far less demanding timewise. > This model also allows the ADs to spread the work amongst multiple WG > chairs versus two chairs shepherding 20+ WG documents. > > This whole approach is in response to the perceived and in some cases > actual inefficiencies in completing work items in a timely manner in the > old SIPPING and SIP WGs - there are many examples of items that have > taken 5+ years to be published. This is a disservice to the community > and the folks that spent years working on the drafts as it has resulted > in RFCs that are no longer relevant to the industry. > > Regards, > Mary. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Xavier Marjou > Sent: Monday, October 12, 2009 4:07 AM > To: dispatch@ietf.org > Subject: [dispatch] Comments on cc-uui topic > > Hi all, > > Reading the minutes of IETF75, I see that there is a proposal to form a > "mini-WG" for draft-johnston-dispatch-sip-cc-uui-00.txt. > > My opinion is the following: > - draft-johnston-sipping-cc-uui should progress as a standard track RFC. > - do not create a dedicated WG for this specific topic since I believe > the amount of work left to finalize the draft would not justify it. > > Cheers, > Xavier > _______________________________________________ > 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 HKaplan@acmepacket.com Tue Oct 20 06:45: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 1CEFF3A69D8 for ; Tue, 20 Oct 2009 06:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 x+X5l1Ecjf5c for ; Tue, 20 Oct 2009 06:45:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E5FDB3A69BC for ; Tue, 20 Oct 2009 06:45:56 -0700 (PDT) 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, 20 Oct 2009 09:46:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Oct 2009 09:46:03 -0400 From: Hadriel Kaplan To: Dean Willis , Alan Johnston Date: Tue, 20 Oct 2009 09:46:02 -0400 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpRQkU1yYEFVGWvSPCj+/VnB7h4RwAR5sHw Message-ID: References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> <4ADCB260.1040108@neustar.biz> <19E5A74F-5817-4AC2-9D5C-C1B80C8FF1F0@sipstation.com> <191269E7-30DA-435B-B2E3-6C3F5E4D5465@softarmor.com> In-Reply-To: <191269E7-30DA-435B-B2E3-6C3F5E4D5465@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 13:45:58 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, October 20, 2009 1:01 AM > To: Alan Johnston >=20 > But a simple PUBLISH-based mechanism would require no more text than a > REGISTER-based mechanism, while providing easy graft-on points for the > more advanced features you mention here. If it can be done in IETF in > the same time frame as hacking up REGISTER would require, what's your > problem? As I've already mentioned, the REGISTER request has some already-defined me= chanisms which are necessary: sip-outbound and Path. Plus some that are ma= ybe not necessary, but at least useful: Service-Route and reg-event. Considering how long it took us to do sip-outbound, I'm fairly confident st= arting from scratch on a PUBLISH way of doing this will be a multi-year pro= ject. Furthermore, this isn't just about how long it takes to document it - it's = also about how long it takes to get it adopted. > > Unfortunately, this doesn't meet the needs for simple SIP trunking, > > where the mechanism must be REGISTER based for the reasons Hadriel > > oulined earlier. >=20 > That argument just doesn't hold up. We're told that it has to be > REGISTER because of the huge installed base for the mechanism. Yet > clearly, none of the installed base does it exactly the way that the > draft proposes to do it.=20 It's true the installed base doesn't use the exact mechanism in domain-regi= stration draft, but it's not far off for the IP-PBX side. The amount of in= stalled base which uses REGISTER, both on the IP-PBX side and the proxy/mid= dlebox and Registrar side is pretty darn big. We're trying to keep the cha= nges as minimal as possible. > Further, the draft's proposed approach breaks > many of the rules about how SIP operates (like its bogus use of > Require to invoke a feature, contextual overloading of Contact to mean > something else, and so on). Now you're sounding like a "deeply disingenuous response". It does NOT "br= eak many of the rules about how SIP operates". We're extending, which by d= efinition means doing something new SIP didn't do before. With regards to = the Require usage, I've already said if what you demand is a new header as = well, then let's debate that. The Contact, however, is not overloaded - it= means the same thing a Contact did in 3261 REGISTER. -hadriel From HKaplan@acmepacket.com Tue Oct 20 06:51: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 D468E3A69A7 for ; Tue, 20 Oct 2009 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 BpS4XvBivxVN for ; Tue, 20 Oct 2009 06:51:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F30E73A6997 for ; Tue, 20 Oct 2009 06:51:49 -0700 (PDT) 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, 20 Oct 2009 09:51:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Oct 2009 09:51:56 -0400 From: Hadriel Kaplan To: Dean Willis , Alan Johnston Date: Tue, 20 Oct 2009 09:51:55 -0400 Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpRQkU1yYEFVGWvSPCj+/VnB7h4RwASWcow Message-ID: References: <4AD7AA3D.8070108@cisco.com> <24A37E0B-E9D1-49D8-BFAD-B1C1AA09CD55@nostrum.com> <34D756FF40454C5EB485CA73316DDF42@china.huawei.com> <802AEA37-AC25-4DDD-BEFA-2463C00336B3@nostrum.com> <4AD9DFF9.5060303@softarmor.com> <4AD9EBFB.7070101@softarmor.com> <4ADC7136.9060200@cisco.com> <4ADCB260.1040108@neustar.biz> <19E5A74F-5817-4AC2-9D5C-C1B80C8FF1F0@sipstation.com> <191269E7-30DA-435B-B2E3-6C3F5E4D5465@softarmor.com> In-Reply-To: <191269E7-30DA-435B-B2E3-6C3F5E4D5465@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 13:51:50 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, October 20, 2009 1:01 AM >=20 > We know we made mistakes early in SIP, but you'd think we'd have > learned something by now about how not to repeat them. This approach, > however, operates by combining a handful of existing mistakes in a new > and misguided way to make something even more convoluted than I had > imagined possible. Impressive, but still not a good idea. Some of us feel the "mistakes" made include our history of expanding the pr= oblem being solved from being a focused one, to a large set of unrelated is= sues, resulting in large documents and years of time spent in the IETF to g= et published. You'd think we'd have learned something by now about how not to repeat that= . -hadriel From HKaplan@acmepacket.com Tue Oct 20 07:38:48 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 2F8F028C0F1 for ; Tue, 20 Oct 2009 07:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 dWol6Qy3ewbx for ; Tue, 20 Oct 2009 07:38:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CA3F428C0CF for ; Tue, 20 Oct 2009 07:38:43 -0700 (PDT) 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, 20 Oct 2009 10:38:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Oct 2009 10:38:50 -0400 From: Hadriel Kaplan To: Dean Willis , Dale Worley Date: Tue, 20 Oct 2009 10:38:50 -0400 Thread-Topic: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpRPs8QNnNnIEosQLCnGvt9o1kpWwATb+zA Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1255986053.3767.46.camel@khone.us.nortel.com> <2BF7C0D9-BD3F-41A8-A891-A1454DA547F0@softarmor.com> In-Reply-To: <2BF7C0D9-BD3F-41A8-A891-A1454DA547F0@softarmor.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 14:38:48 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Tuesday, October 20, 2009 12:34 AM >=20 > The thing that the proponents of Hadriel's draft are missing is that > the hacky part is not the registration of the routes. It's not even > how the routes are used. The hacky part of the proposal is the way the > routes are constructed so that they look like AORs, which allows them > to be conveyed in a syntactically (but not semantically) correct > REGISTER. This is a big hack. If we are taking this to a "standard", > we need to make something that is less hacky, more regular, and > possible to get "right". Huh. I assumed the part some folks thought was a "hack" was the fact we we= re using a REGISTER method. But you raise an interesting point - perhaps w= e should make the To-URI just the domain name without a user@ portion. The= From-URI would still be an AoR, namely one of the PBX itself. i.e., it wo= uld be like a third-party registration - "pbx@enterprise.com" is registerin= g the domain "enterprise.com". -hadriel From BLINDSAY@nortel.com Tue Oct 20 10:37: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 7C4343A68F4 for ; Tue, 20 Oct 2009 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=1.450, 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 77CYzYmIHhrA for ; Tue, 20 Oct 2009 10:37:56 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 523D43A68A8 for ; Tue, 20 Oct 2009 10:37:53 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9KHbru20991; Tue, 20 Oct 2009 17:37:53 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: Tue, 20 Oct 2009 13:37:37 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141B04DB1B@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DomainRegistration Draft draft-kaplan-dispatch-domain-registration Thread-Index: AcpRPs8QNnNnIEosQLCnGvt9o1kpWwATb+zAAAcvVpA= References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com><1255986053.3767.46.camel@khone.us.nortel.com><2BF7C0D9-BD3F-41A8-A891-A1454DA547F0@softarmor.com> From: "Brian Lindsay" To: "Hadriel Kaplan" Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistration Draft draft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 17:37:57 -0000 Hi Hadriel, I think leaving that aspect "as is" would be preferable in that it would be more compatible with in-the-wild implementations (and potentially some other standards) that support an "implicit" registration to accomplish exactly the same thing.=20 Thanks -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, October 20, 2009 10:39 AM To: Dean Willis; Worley, Dale (BL60:9D30) Cc: dispatch@ietf.org Subject: Re: [dispatch] DomainRegistration Draft draft-kaplan-dispatch-domain-registration > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Dean Willis > Sent: Tuesday, October 20, 2009 12:34 AM >=20 > The thing that the proponents of Hadriel's draft are missing is that=20 > the hacky part is not the registration of the routes. It's not even=20 > how the routes are used. The hacky part of the proposal is the way the > routes are constructed so that they look like AORs, which allows them=20 > to be conveyed in a syntactically (but not semantically) correct=20 > REGISTER. This is a big hack. If we are taking this to a "standard",=20 > we need to make something that is less hacky, more regular, and=20 > possible to get "right". Huh. I assumed the part some folks thought was a "hack" was the fact we were using a REGISTER method. But you raise an interesting point - perhaps we should make the To-URI just the domain name without a user@ portion. The From-URI would still be an AoR, namely one of the PBX itself. i.e., it would be like a third-party registration - "pbx@enterprise.com" is registering the domain "enterprise.com". -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From D.Hancock@CableLabs.com Tue Oct 20 11:28: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 564323A6944 for ; Tue, 20 Oct 2009 11:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.987 X-Spam-Level: X-Spam-Status: No, score=0.987 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_82=0.6, MANGLED_REGSTR=2.3] 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 aFBlKCI9R7vq for ; Tue, 20 Oct 2009 11:27:59 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 20D0C3A6899 for ; Tue, 20 Oct 2009 11:27:59 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9KIS6IQ011492 for ; Tue, 20 Oct 2009 12:28:06 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 20 Oct 2009 12:28:06 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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: Tue, 20 Oct 2009 12:28:06 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEEE7@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEEE4@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration Thread-Index: AcpRrz6G+cYKvG5cTcOAXp1VEHmuAgAABKFQ References: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEEE4@srvxchg3.cablelabs.com> From: "David Hancock" To: X-Approved: ondar Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration 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, 20 Oct 2009 18:28:00 -0000 I would like to add my voice to the chorus supporting the domain = registration draft. I also support Cullen's "AD sponsored" option to = progress it to RFC status.=20 The lack of a common standard in this area is costing operators that = deploy SIP-PBXs time and money - time in testing each new SIP-PBX = version to identify interworking issues, and money in deploying fix-up = boxes to make things work in the field. Domain registration is a = relatively small increment from what most SIP-PBXs do today, so I expect = (hope) it will quickly gain wide adoption. If we abandon the = domain-registration approach and go back to square one, then I'm afraid = it will unnecessarily delay adoption of a standard in this area. First, = there's the risk that it'll take a long time to agree on and document a = standard way of doing this. Second, there's the risk that the eventual = solution will be sufficiently divergent from what is supported in the = (growing) installed base that adoption will be slow. Meanwhile, = operators will have to continue bearing the cost of deploying SIP-PBXs = in the current "non standard" environment. David ________________________________________ From: "Brian Lindsay" To: "Richard Shockey" , "Hadriel Kaplan" , Date: Mon, 19 Oct 2009 12:43:40 -0400 Hi, =A0=A0 Would like to chime in and express support for standardization/formalization of a REGISTER-based solution to this problem, to address the SIP PBX problem space in a timely fashion by building on currently deployed approaches, rather than inventing something new. The draft should be DISPATCH'ed in a manner to best facilitate that. =A0 Thanks. -----Original Message----- From: dispatch-bounces at ietf.org [mailto:dispatch-bounces at ietf.org] = On Behalf Of Richard Shockey Sent: Monday, October 19, 2009 12:34 PM To: 'Paul Kyzivat'; 'Hadriel Kaplan' Cc: dispatch at ietf.org Subject: Re: [dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registrati on Paul please remember ..we are trying to fix something that is in the field right now and widely deployed that is causing interoperability problems.=A0=20 There are probably better ways to approach the bindings between PBX's and SSP's and the larger issues of provisioning but that is not what the draft is trying to accomplish and there is a substantial community here that is trying to do the right thing.=20 >=A0 -----Original Message----- >=A0 From: dispatch-bounces at ietf.org [mailto:dispatch-bounces at = ietf.org] On > Behalf Of Paul Kyzivat >=A0 Sent: Monday, October 19, 2009 10:01 AM >=A0 To: Hadriel Kaplan >=A0 Cc: dispatch at ietf.org >=A0 Subject: Re: [dispatch] = DomainRegistrationDraftdraft-kaplan-dispatch- >=A0 domain-registration >=A0=20 >=A0 I continue to sit on the fence about this one: >=A0=20 >=A0 I understand and agree with what Hadriel is saying about this=20 > behavior=A0 falling within the latitude given to proxies on how they route things. >=A0 Thus I think it is *conforming* for SIPForum or some other group = to=A0=20 > make=A0 an agreement about a convention that does things this way. >=A0=20 >=A0 But it is a hack. It is not a *clean* way to do it. I expect more=20 > from=A0 IETF approved documents. Maybe we are to the point with SIP=20 > where=A0 there=A0 is too much inertia to afford "clean", and that = hacks=20 > are now the way=A0 forward. But if so, that is at least sad. >=A0=20 >=A0 =A0=A0=A0=A0 Thanks, >=A0 =A0=A0=A0=A0 Paul >=A0=20 >=A0 Hadriel Kaplan wrote: >=A0 >> -----Original Message----- >=A0 >> From: Dean Willis [mailto:dean.willis at softarmor.com] >=A0 >> Sent: Saturday, October 17, 2009 12:08 PM=A0 >>=A0 >> I think = you've=20 > got a hold of an absolutely critical, core piece of=A0 SIP=A0 >>=20 > functionality. You're either revising or replacing one of the=A0 >>=20 > fundamental SIP methods, dating to before RFC 2543. That says=A0 = SIPCORE > to=A0 >> me. >=A0 > >=A0 > We're not updating 3261, 3262, or 3263.=A0 We're not revising = or=A0=20 > replacing REGISTER.=A0 We're extending, using an options-tag to = indicate > it.=A0 Otherwise what you're saying is every extension that needs = an=A0=20 > options-tag for any request Method name documented in 3261 needs to be > in sipcore - including any applying to INVITE.=A0 I don't think you = want > that. >=A0 > >=A0 > >=A0 >> I believe that the same objections that might prevent you = from=A0=20 > making a=A0 >> "standards track" solution would also keep you from=20 > making an=A0 >> informational solution. You might not notice, but = we've=20 > held even=A0 the=A0 >> info track documents to a high level of review. >=A0 > >=A0 > There would be nothing to discuss.=A0 It wouldn't require an=A0=20 > informational draft to even be published.=A0 There's enough wiggle = room > in 3261 routing procedures and Registration procedures to avoid any=A0 = > need - the draft would effectively be an "FYI".=A0 Effectively it = would > be something along the lines of the older = draft-kaplan-dispatch-sip-=A0=20 > implicit-registrations-00. >=A0 > >=A0 > We would register an AoR in a REGISTER transaction - for requests = > to=A0 that specific AoR things would follow 3261 as is.=A0 For all=20 > intents,=A0 it's a fake AoR.=A0 Internally, in the Registrar DB, that=20 > AoR's=A0 reachability information (contact/path) would just not-so-=A0 = > coincidentally happen to be used for Route header fields for that=A0=20 > domain.=A0 Since that routing portion is effectively up to local = policy > (ie, implementations), it would comply with 3261 as well.=A0 Nothing = in >=A0 3261 demands that local policy routing results follow any = prescribed > data, so we'd just document that it happens to be data populated from > that AoR's reachability data. >=A0 > >=A0 > There isn't even a need for a new header.=A0 We'd just try for = one to > help troubleshooting and avoiding erroneous manual configuration. >=A0 > >=A0 > -hadriel From dean.willis@softarmor.com Tue Oct 20 20:36: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 8AFED3A692C for ; Tue, 20 Oct 2009 20:36:33 -0700 (PDT) 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 mznETXfNkPrg for ; Tue, 20 Oct 2009 20:36:32 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9087D3A672F for ; Tue, 20 Oct 2009 20:36:32 -0700 (PDT) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9L3abDK006625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Oct 2009 22:36:39 -0500 Message-Id: <3204FD9E-B06F-4C05-B17F-7548076F8D26@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: 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, 20 Oct 2009 22:36:32 -0500 References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1255986053.3767.46.camel@khone.us.nortel.com> <2BF7C0D9-BD3F-41A8-A891-A1454DA547F0@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration 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, 21 Oct 2009 03:36:33 -0000 On Oct 20, 2009, at 9:38 AM, Hadriel Kaplan wrote: > Huh. I assumed the part some folks thought was a "hack" was the > fact we were using a REGISTER method. But you raise an interesting > point - perhaps we should make the To-URI just the domain name > without a user@ portion. The From-URI would still be an AoR, namely > one of the PBX itself. i.e., it would be like a third-party > registration - "pbx@enterprise.com" is registering the domain > "enterprise.com". > Yes, I do like this approach better. -- Dean From R.Jesske@telekom.de Tue Oct 20 22:39: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 2CF623A67D6 for ; Tue, 20 Oct 2009 22:39:21 -0700 (PDT) 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 fEK9cZURwSI4 for ; Tue, 20 Oct 2009 22:39:19 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 1DE713A67AA for ; Tue, 20 Oct 2009 22:39:18 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 21 Oct 2009 07:39:22 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:39:22 +0200 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: Wed, 21 Oct 2009 07:39:21 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4051B1C1A@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4ADDACA1.6070405@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Thread-Index: AcpRgNRKith1ZKmLTZGClEoQ63xjDAAjrPXQ References: <1ECE0EB50388174790F9694F77522CCF205954B0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050708F2@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF206283F0@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4050C5897@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF207AFBDE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD405111FCE@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF20809164@zrc2hxm0.corp.nortel.com> <4ADDACA1.6070405@ericsson.com> From: To: , X-OriginalArrivalTime: 21 Oct 2009 05:39:22.0540 (UTC) FILETIME=[D7B506C0:01CA5210] Cc: dispatch@ietf.org Subject: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses 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, 21 Oct 2009 05:39:21 -0000 Hi Gonzalo, Also a normative RFC is fine for me.=20 Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Gesendet: Dienstag, 20. Oktober 2009 14:27 An: Mary Barnes Cc: Jesske, Roland; dispatch@ietf.org Betreff: Re: [dispatch] DISPATCH IETF-76 plans - Reason in Responses Hi, yes, it seems that a normative RFC would be more appropriate if we=20 decide to work on this. Cheers, Gonzalo Mary Barnes wrote: > Hi Roland, >=20 > This list is fine for this discussion. The needed feedback from the WG = right now is whether folks find the problem statement adequate and if = they believe that an informational document is sufficient to resolve the = requirements and address the concerns for which this document is = intended. Based on past discussions, it seemed that normative changes = to RFC 3326 might be needed to resolve some of the issues raised. For = example, this thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00491.html >=20 > Once we get feedback on the mailing list that folks agree the problem = statement and proposed work item (it seems there is sufficient interest = in general in solving the problem), the WG chairs can discuss with the = ADs the appropriate place to progress the work. >=20 > Thanks, > Mary.=20 >=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Monday, October 12, 2009 5:17 PM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses >=20 > Hi Mary, > So I would like to go with the informal approach.=20 >=20 > When I started the discussion on this issue in advance to the = Stockholm meeting I've got only feedback from DISPATCH and BLISS but not = from SIPCORE. > BLISS see this issue within their scope because it solves = interoperability problems with the PSTN/ISDN. > DISPATCH discussed the draft which resulted in the new version. >=20 > Question for me now is should I ask again on all lists who will be = responsible. Or is there an other way to go?=20 >=20 >=20 > Best Regards >=20 > Roland >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Mary Barnes [mailto:mary.barnes@nortel.com] > Gesendet: Montag, 12. Oktober 2009 19:05 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses >=20 > Hi Roland, >=20 > If you are just adding clarifications to the existing RFC, then it can = be an informational document, similar to the model for the SIPPING WG = offer-answer document. If you are changing any normative statements, = then you need at least a standards track document as an "Update" to RFC = 3326. And "Update" could still be used even if normative functionality = is not changed if the clarifications are far more understandable = integrated into RFC 3326.=20 >=20 > For an informational document we would still need to determine whether = it would be AD sponsored or need a mini-WG or fits within SIPCORE, for = example. =20 >=20 >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Tuesday, October 06, 2009 9:01 AM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses >=20 >=20 > Hi Mary, > Thank you for your clarification. So I will wait for that discussion.=20 >=20 > With regard to your question I'm not really clear what the best way = would be. >=20 > This behaviour would complete the behaviour of RFC 3326. And RFC 3326 = gives clear guidance what to do with the case for Reason in Responses, = so it is my understanding to have an own document. So that is my = proposal. >=20 > Question is now if it should be an informal document. If this is = sufficient I'm happy with that way if not we should change the status. I = would be happy on comments on this. >=20 > Thank you and Best Regards >=20 > Roland >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Mary Barnes [mailto:mary.barnes@nortel.com] > Gesendet: Sonntag, 4. Oktober 2009 00:51 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: [dispatch] DISPATCH IETF-76 plans - Reason in Responses >=20 > Hi Roland, >=20 > Just an initial point of clarification in that we don't charter work = items for the DISPATCH WG. We evaluate the scope of a problem, define a = clear problem statement and proposed work item(s) and then determine = where/how the work should be done. =20 >=20 > One thing that needs clarification in your charter proposal is whether = you are proposing an informational document or an updates to RFC 3326. = The charter item seems to imply an informational document, but can you = please clarify? =20 >=20 > If we can agree to work on the problem on the mailing list, then you = wouldn't necessarily need agenda time. So, WG feedback is needed here.=20 >=20 > Thanks, > Mary.=20 >=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Friday, October 02, 2009 12:51 AM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Subject: AW: [dispatch] DISPATCH IETF-76 plans - Reason in Responses >=20 >=20 > Dear all, > I see that after my renewal of the draft only some comments were = given. > We see this as an important issue to keep interoperability between = PSTN and SIP networks. >=20 > Meanwhile there is also a request on putting a Reason Header within a = 183 Progress due to the fact that it is possible to put a Q.850 cause = value within an ACM including an indication that an announcement is = played. >=20 > This case would be valuable for a PSTN - SIP -PSTN passing without any = use of SIP-T. >=20 > The main used case is to put the Reason Header within 4xx, 5xx, 6xx = and 199 to send an specific indication either back into an other PSTN or = an Application Server that can put an announcement into the path based = on the ISUP cause. >=20 > But nevertheless I Would like to see this draft on the agenda and at = least as an Woki Item within DISPATCH. >=20 > Best regards >=20 > Roland =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Mary Barnes > Gesendet: Donnerstag, 1. Oktober 2009 15:56 > An: dispatch@ietf.org > Betreff: [dispatch] DISPATCH IETF-76 plans >=20 > Hi all,=20 >=20 > Per Gonzalo's reminder on Sept. 16th, charter proposals for the topics = to be handled/dispatched prior to and at IETF-76 were due on Sept. 21st. > The following summarizes the status of the topics that had been = previously put forth - both prior to Sept. 7th deadline and up through = the 21st. Obviously, we have to balance interest and willingness to = contribute to the work (based on mailing list discussions) with the fact = that some folks were more conscientious in meeting the deadlines.=20 >=20 > We received charter proposals (problem statements/deliverables) for = the following, with the current status highlighted. =20 >=20 > o Overload (received prior to Sept. 16th) - separate mailing list = setup. > Needs more discussion.=20 >=20 > o CBUS: some good discussion on problem statement. Needs more = discussion. >=20 > o Session recording: updated charter proposal based on IETF-75 = feedback. > Need more WG feedback. Is this ready? =20 >=20 > o Disaggregated media: Good level of interest=20 >=20 > o SIP - XMPP: High level of WG interest. Propose a separate Mailing = list and Adhoc at IETF-76.=20 >=20 > o Alert-info URNs: Good level of interest.=20 >=20 > o NGN Reason: Some interest. Needs more discussion and scoping.=20 >=20 > The above items are the current targets for IETF-76 discussions. = Based on those discussions, agenda time will be allocated, items = dispatched and adhocs scheduled as appropriate. Note, that the minimum = time we would allocate to a topic is 30 minutes and some may warrant 45 = minutes. > If we schedule adhocs, we will try to have those announced around the = time the agenda is finalized.=20 >=20 > As a reminder, the following are the cutoffs for drafts, so please = make sure that any drafts relevant to the topic are submitted prior to = those > deadlines: > * - 00 documents: Oct. 19th (just over 2 weeks) > * all other documents: Oct. 26th (just over 3 weeks) >=20 > Please keep in mind that the focus of discussions should be the = problem > statement, scope and proposed deliverables for the topic. =20 >=20 > We did not receive charter proposals for the following. The current = status is summarized: > o Third-party authorization: Pre-IETF-75 problem statement had some = discussion. But, no discussion since that time.=20 > o Identity: Document available. Need further discussion and WG = feedback to refine requirements, problem statement, scope and = deliverables/milestones.=20 > o Domain registrations in SIP: Problem statement posted, but no = deliverables/milestones or document.=20 > o Reference to an earlier communication: Problem statement posted, but = no deliverables/milestones or document.=20 >=20 > As a reminder, items can be dispatched without being discussed at a = f2f meeting and the most effective way to achieve this is to have = problem statements, scope of topics and any relevant documents available = early enough for the WG to provide feedback - i.e., you do not have to = wait for the pre-meeting deadlines, which are more in the way of drop = dead dates than optimal dates. =20 >=20 > Please, let the chairs know if there are any concerns. >=20 > Thanks, > Mary Barnes > DISPATCH WG 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 >=20 From salvatore.loreto@ericsson.com Wed Oct 21 00:59: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 C4DB33A695C for ; Wed, 21 Oct 2009 00:59:46 -0700 (PDT) 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 b2yT-K+ZhJw2 for ; Wed, 21 Oct 2009 00:59:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8ED903A67AB for ; Wed, 21 Oct 2009 00:59:45 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-f0-4adebf50f3b3 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 49.4E.24026.05FBEDA4; Wed, 21 Oct 2009 09:59:12 +0200 (CEST) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:59:05 +0200 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, 21 Oct 2009 09:59:04 +0200 Message-ID: <10CEDD6D91C2AD4F87003AB2D31631AC02071659@esealmw103.eemea.ericsson.se> In-Reply-To: <4ADD8EBD.5060003@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Disaggregate Media: updated charter proposal Thread-Index: AcpRbtY82LMMVz45TgCqPRsfhRfzrQAAUy2A References: <4AD46775.9060002@ericsson.com> <4ADD8EBD.5060003@ericsson.com> From: "Salvatore Loreto" To: X-OriginalArrivalTime: 21 Oct 2009 07:59:05.0519 (UTC) FILETIME=[5C5A1BF0:01CA5224] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: [dispatch] Disaggregate Media: updated 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: Wed, 21 Oct 2009 07:59:46 -0000 Hi there, Here a new/updated version of the charter proposal for Disaggregated Media. This version includes all the suggestions and comments received in the list discussion. Best regards Salvatore Loreto Disaggregated Media WG Charter ------------------------------ Disaggregated media refers to the ability for a user to create a=20 multimedia session combining different media streams coming from=20 different devices under his or her control so that they are treated=20 by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or=20 participate in) a given multimedia session. Consequently, the SIP=20 signaling to manage the multimedia session and the actual media=20 streams are typically co-located in the same device. In scenarios=20 involving disaggregated media, a user wants to establish a single=20 multimedia session combining different media streams coming from=20 different devices under his or her control. This creates a need to=20 coordinate the exchange of the those media streams within the multimedia session. =20 =20 There are a number of existing mechanisms that can be used to=20 coordinate different devices under user's control and to involve them=20 in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However the use of all those mechanisms requires the presence of a "master" device. That is, at least one among=20 the different devices under the control of the same user must support this mechanism and be able to become a controller for the other in the call.=20 Moreover, the "master" device is supposed to remain involved in the user's=20 session for its entire duration given that performing a handover of the master role is typically cumbersome and sometime impossible. The objective of this working group is to develop a framework for=20 Disaggregated Media in "loosely-coupled" scenarios, where no single=20 device needs to remain in the session for its entire duration and no single device needs to act as a master. The framework may describe the use of existing mechanisms (e.g., 3pcc),=20 extensions to them, and new mechanisms. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key design considerations for disaggregated media mechanism(s). The document will include use cases and functional requirements for the mechanism(s). 2. Specifications of new mechanisms or extensions to existing mechanisms if the need is identified in the framework. From salvatore.loreto@ericsson.com Wed Oct 21 06:48: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 195823A69E9 for ; Wed, 21 Oct 2009 06:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.527, 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 QRBatzMLdxKk for ; Wed, 21 Oct 2009 06:48:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D391A3A69D5 for ; Wed, 21 Oct 2009 06:48:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-18-4adf1109ce5e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 80.25.24026.9011FDA4; Wed, 21 Oct 2009 15:47:53 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 15:47:27 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 15:47:27 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BD68926BE; Wed, 21 Oct 2009 16:47:26 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8827A21A22; Wed, 21 Oct 2009 16:47:26 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3E37321A1F; Wed, 21 Oct 2009 16:47:26 +0300 (EEST) Message-ID: <4ADF10ED.1030303@ericsson.com> Date: Wed, 21 Oct 2009 16:47:25 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Kumiko Ono References: <55394D27-920E-48EB-966A-E01655D91F58@cs.columbia.edu> In-Reply-To: <55394D27-920E-48EB-966A-E01655D91F58@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 21 Oct 2009 13:47:27.0297 (UTC) FILETIME=[06C85310:01CA5255] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D: Referencing Earlier Communications in SIP Requests 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, 21 Oct 2009 13:48:17 -0000 Hi Kumiko, this draft could in same way be related to the discussions that is going on about session correlation, context-id and disaggregated media... one more reference in line cheers Sal Kumiko Ono wrote: > Hi, > > We've submitted a new I-D, "Referencing Earlier Communications in SIP > Requests." > You can find it at > http://tools.ietf.org/html/draft-ono-earlier-comm-references-00 . > > Abstract: > This document defines a SIP header extension that refers to earlier > SIP or non-SIP communication in SIP requests. For example, this > extension allows users to correlate a SIP session with earlier > sessions or email exchanges. > > The background is described in another I-D, "Using Cross-Media > Relations to Reduce False Positives during SPIT Filtering." > http://tools.ietf.org/html/draft-ono-cross-media-relations-00 [Sal] In Section 4, for web transaction you could also consider the "Web Linking" draft : draft-nottingham-http-link-header-06 using the HTTP Link header to convey the URI or URIs . > > Your comments or questions are very welcome. > > Thanks, > Kumiko > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From L.Liess@telekom.de Wed Oct 21 07:27: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 B37C63A6930 for ; Wed, 21 Oct 2009 07:27:31 -0700 (PDT) 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 bEYs2f4AOB4O for ; Wed, 21 Oct 2009 07:27:30 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id BB7DE3A677D for ; Wed, 21 Oct 2009 07:27:28 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 21 Oct 2009 16:26:27 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:26:16 +0200 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, 21 Oct 2009 16:26:15 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4ADCCF93.2070208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: AcpQ/PHrsKKAPcjBQ1ivncAEpqt5JQAckgOw References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> From: To: , X-OriginalArrivalTime: 21 Oct 2009 14:26:16.0437 (UTC) FILETIME=[730EE250:01CA525A] Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 21 Oct 2009 14:27:31 -0000 Paul,=20 Thank you very much for taking the time to look and comment the draft. After the changes we did shortly before the submission deadline, there are some inconsistecies and open items. We are aware of some of them and probably there are some we are not aware of. For the problems we are aware of, there are alternative solutions. In some cases, we did not have a clear opinion which way to go and we would like to hear others opinions. Please find comments inline:=20 >=20 > This seems to be shaping up well. I think the requirements are quite=20 > clear now. It's good to hear that we have achieved at least a smal stepp in the right direction :-). =20 >=20 > I don't fully understand what is intended regarding combination of=20 > multiple alert URNs for a specific situation. Section 4.5 states: >=20 > > finally, a short Albanian auto-callback tone could be indicated > > Alert-Info: , > > , . >=20 > while section 7.3.6 states: >=20 > > Alert URN Indications from the same group should not be combined. To avoid the combinatorial explosion of IANA values as Adam pointed out in his comment http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html , we decided to abandon the usage of sub-indications for the use cases we have in the draft and to register only discrete tokens as top-level registrations. (With county-specidfic ring and busy tones, we almost got the problem Adam talked about.) The sub-indications are no longer used in the current version of the draft.=20 We thougt about changing the template in chapter 3 from=20 alert-indication =3D top-level *("." sub-indication) top-level =3D let-dig [ *25let-dig-hyp let-dig ] sub-indication =3D let-dig [ *let-dig-hyp let-dig ] to just alert-indication=3D let-dig [ *let-dig-hyp let-dig ] But we are not sure if everyone would agree with this, so we would like to have feedback from the WG on this issue. =20 =20 There is an inconcistency concerning the alert indications "priority", "short" and "delayed": In chapter 4, they are now top-level indications in the alert-category "service", therefore in the same group eith "auto-callback". In chapter 7 there is a dedicated group for them "Additional Indications for PBX-tones" in the "tones" alert-category. We must have to decide which alternative to take. If we decide for the chapter 4 alternative, we must change either the combination rule or the example you complained about.=20 > I could find no definition of what constitutes a "group". The first=20 > thing that comes to mind is "service" vs. "tone", but the=20 > above example=20 > violates that. It seems to me that you need some notion of orthogonal=20 > properties in order to define what can/cannot be combined. It's true, it's quite impossible to guess from the text what I meant here. A group consists of the indications in one sub-chapter 7.3.1 to 7.3.5. I just looked for a way to avoid combinations of contradictory URNs, e.g. that is combined with or is combined with . If we agree that this kind of groups makes sense and we keep it, some definition needs to be added. But maybe there are better proposals in the WG about how to avoid combinations of contradictory indications? =20 >=20 > It would be good to have more detail about how a recipient=20 > should deal=20 > with multiple URNs. Yes. But I think we need to work in steps: -First we need to see if we have an aggreement on the new proposal about registering discrete tokens ("internal" and "priority" instead of "internal.priority").=20 -If this OK, we have to decide if we changed the template otr not.=20 -We need, I think, some rules to avoid combinations of URNs which are obviously contradictory. =20 >=20 > I'm also uncertain of what your intent is regarding top-level vs.=20 > additional indications. As specified, I believe a given "additional=20 > indication" name is always defined with regard to its parent, so that=20 > "short" as used in "normal.short" might mean something entirely=20 > different than "priority.short", or might not be defined for=20 > priority at=20 > all. We changed this in this version, see http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . If we do not agree on this change, we need another mean to avoid combinatorial explosion and the same time still being able to send country specific ringing tones, country specific busy tones and country specific whatever tones. =20 =20 >=20 > Yet from the registration text in 7.3.2 it sounds like the=20 > intent is for=20 > priority, short, and delayed to be defined for all pbx-tones.=20 > If that is=20 > the intent, then I don't think the existing text meets that intent. This should be achieved by sending two URNs, one from the group 7.3.1. "Indications for PBX-tones" and the second from the group 7.3.2. "Additional Indications for PBX-tones" e.g. and . =20 >=20 > I also wonder if the existing hierarchy will work well in=20 > practice, or=20 > if some other organization might not work better. For=20 > instance, it might=20 > be more convenient to specify ringing.fr with the clear understanding=20 > that if you don't know about ringing.fr you can just treat it=20 > as ringing. See above comments.=20 >=20 > I'm also confused by PBX tones vs. Public telephone tones. In=20 > what way=20 > is "normal" different from "ringing"? I would think that PBX=20 > tones would=20 > be a superset of common pstn tones. I think a PBX has ist own tones for normal, internal and external ringing, different from those of the public network.=20 I would keep the two worlds disjunct. E.g. , I have a sip handy which is attached sometimes to the pbx and sometimes to my public carrier at home, I may want the pbx ringing tone to be different from the ringing tone at home.=20 =20 >=20 > A nit: in 4.3.2 I would expext the forward to be indicated,=20 > if at all,=20 > with a 181 rather than a 180. My understanding is that the URN should be transmitted in the 180 ringing after the forwarded call has reached ist final destination and the phone is ringing at the UE, not in the 181 sent by the forwarding proxy when it decides to to forward the call. Also the RFC 3261 only allows Alert-Info in 180 responses. Or did I miss something here? Thanks a lot Laura >=20 > Thanks, > Paul >=20 > L.Liess@telekom.de wrote: > > =20 > > Hi, > >=20 > > We've re-submitted the Alert-Info URNs draft for DISPATCH > >=20 > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > -info-urns > > -00.txt . (The previous version od the draft was in BLISS=20 > and we had a > > presentation in BLISS at the last IETF.) > >=20 > > We did some major changes, as suggested on the mailing list, e.g.: > > Added: =20 > > - Description of the interoperability problems for=20 > PBX-services (in > > the Introduction chapter)=20 > > - Requirements for the Alert-Info URNs mechanism=20 > > - Alert-Info URNs Indications for country-specific tones > > Changed:=20 > > - Initial IANA Registration mechanism to avoid=20 > combinatorial explosion > > of IANA values.=20 > >=20 > >=20 > > Many thanks for the comments and suggestions, > > Laura=20 > >=20 > >=20 > >=20 > > =20 > >=20 > > -----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, October 19, 2009 1:00 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >=20 > > Title : Alert-Info URNs for the Session Initiation > > Protocol (SIP) > > Author(s) : D. Alexeitsev, et al. > > Filename : draft-liess-dispatch-alert-info-urns-00.txt > > Pages : 25 > > Date : 2009-10-19 > >=20 > > The Session Initiation Protocol (SIP) supports the capability to > > provide a reference to the alternative ringback tone (RBT) for > > caller, or ring tone (RT) for callee using the Alert-Info header. > > However, the reference addresses only the network resources with > > specific rendering properties. There is currently no support for > > predefined standard identifiers for ringback tones or semantic > > indications without tied rendering. To overcome this=20 > limitations and > > support new applications a family of the URNs is defined in this > > specification. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > -info-urns > > -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. > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 From pkyzivat@cisco.com Wed Oct 21 07:50: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 7EE5B3A6819 for ; Wed, 21 Oct 2009 07:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 ehSYBPDR3iPa for ; Wed, 21 Oct 2009 07:50:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B06BB3A67F0 for ; Wed, 21 Oct 2009 07:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3305; q=dns/txt; s=rtpiport02001; t=1256136608; x=1257346208; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20Disaggregate=20Media:=20updated=20c harter=20proposal|Date:=20Wed,=2021=20Oct=202009=2010:50: 07=20-0400|Message-ID:=20<4ADF1F9F.5090201@cisco.com>|To: =20Salvatore=20Loreto=20 |CC:=20dispatch@ietf.org,=20Gonzalo=20Camarillo=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<10CEDD 6D91C2AD4F87003AB2D31631AC02071659@esealmw103.eemea.erics son.se>|References:=20<4AD46775.9060002@ericsson.com>=20< 4ADD8EBD.5060003@ericsson.com>=20<10CEDD6D91C2AD4F87003AB 2D31631AC02071659@esealmw103.eemea.ericsson.se>; bh=F03j75VwE2l4FkC2Jhnua21nlTuaNwd/hVuGU8mBdFI=; b=M9iEBAx0GpbnnzgkNbjrkmDg906nc9i7m+oJBOO0JQJ6aXsE5bVo5+qR U7pMsd1SD+UUq8bXVMjkLU7KxKbR0HqAIzeL+TeVknuxjvdZcN79Zx+Tv Z1o6kU31JZOo1vNeQLGPw4sS5Q7OXRiVLaYYdkxW2Iz9sbvhfTop0VqEd k=; 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: ApoEAO+83kqtJV2Z/2dsb2JhbADDUJhXhDEE X-IronPort-AV: E=Sophos;i="4.44,597,1249257600"; d="scan'208";a="64168803" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2009 14:50:07 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id n9LEo7ia032409; Wed, 21 Oct 2009 14:50:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:50:07 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:50:07 -0400 Message-ID: <4ADF1F9F.5090201@cisco.com> Date: Wed, 21 Oct 2009 10:50:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4AD46775.9060002@ericsson.com> <4ADD8EBD.5060003@ericsson.com> <10CEDD6D91C2AD4F87003AB2D31631AC02071659@esealmw103.eemea.ericsson.se> In-Reply-To: <10CEDD6D91C2AD4F87003AB2D31631AC02071659@esealmw103.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 14:50:07.0103 (UTC) FILETIME=[C7CD30F0:01CA525D] Cc: dispatch@ietf.org, Gonzalo Camarillo Subject: Re: [dispatch] Disaggregate Media: updated 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: Wed, 21 Oct 2009 14:50:01 -0000 Salvatore Loreto wrote: > Hi there, > > Here a new/updated version of the charter proposal for Disaggregated > Media. > This version includes all the suggestions and comments received in the > list discussion. This sounds good to me. One part (highlighted inline below) is a little perjorative, but I can live with it. Thanks, Paul > Best regards > Salvatore Loreto > > > Disaggregated Media WG Charter > ------------------------------ > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams coming from > different devices under his or her control so that they are treated > by the far end of the session as a single media session. > > Generally, a given participant uses a single device to establish (or > participate in) a given multimedia session. Consequently, the SIP > signaling to manage the multimedia session and the actual media > streams are typically co-located in the same device. In scenarios > involving disaggregated media, a user wants to establish a single > multimedia session combining different media streams coming from > different devices under his or her control. This creates a need to > coordinate the exchange of the those media streams within the multimedia > > session. > > > There are a number of existing mechanisms that can be used to > coordinate different devices under user's control and to involve them > in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] > and SIP 3pcc [RFC3725]). However the use of all those mechanisms > requires the presence of a "master" device. That is, at least one among > the different devices under the control of the same user must support > this > mechanism and be able to become a controller for the other in the call. > Moreover, the "master" device is supposed to remain involved in the > user's > session for its entire duration given that performing a handover of the > master role is typically cumbersome and sometime impossible. Its this last sentence that I find perjorative. How hard something is is debatable, and needs to be considered in light of the alternatives. That hasn't been done yet. But this is a nit, since AFAICT it won't have any effect on the work of the group. > The objective of this working group is to develop a framework for > Disaggregated Media in "loosely-coupled" scenarios, where no single > device needs to remain in the session for its entire duration and > no single device needs to act as a master. > > The framework may describe the use of existing mechanisms (e.g., 3pcc), > extensions to them, and new mechanisms. > > Specifically, the proposed working group will develop the following > deliverables: > > 1. A framework document describing key design considerations for > disaggregated media mechanism(s). The document will include use > cases and functional requirements for the mechanism(s). > > 2. Specifications of new mechanisms or extensions to existing > mechanisms if the need is identified in the framework. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Wed Oct 21 12: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 980793A69DE for ; Wed, 21 Oct 2009 12:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 3-8PBS5FwoBV for ; Wed, 21 Oct 2009 12:42:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2457C3A6842 for ; Wed, 21 Oct 2009 12:42:49 -0700 (PDT) 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, 21 Oct 2009 15:42:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 21 Oct 2009 15:42:57 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Wed, 21 Oct 2009 15:42:56 -0400 Thread-Topic: To-URI in domain-registration Thread-Index: AcpShq/qoPxSbruXTN6NgIO7uxjk6w== 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] To-URI in domain-registration 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, 21 Oct 2009 19:42:53 -0000 Howdy, I'd like to get a consensus call on the question of what the To-URI should = be for the REGISTER request of a domain registration, before finishing the = next rev of the draft. This will affect quite a bit of text in the draft (= e.g., examples), and I think that the decision about that will also affect = whether we need more than a Require:option-tag as well. The choices right now are: 1) Mandate the To-URI be in the syntactical form of an AoR, including the u= ser@ portion, the same as the From-URI. Pros: closer to what current proprietary and other-SDO mechanisms do, on t= he wire. Therefore, presumably less of a change and less barrier to adopti= on. 2) Mandate the To-URI be a domain only (no user@), while the From-URI remai= ns the "AoR" of the PBX registering. Pros: semantically accurate (you're registering a domain, not an AoR), and= may obviate the need for a new header or param to indicate this new mechan= ism is being used. Can people please indicate which they'd prefer? Thanks! -hadriel From BLINDSAY@nortel.com Wed Oct 21 12:53: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 8F9B23A6A1F for ; Wed, 21 Oct 2009 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 5KEQSSrzeKRH for ; Wed, 21 Oct 2009 12:53:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 904A33A693E for ; Wed, 21 Oct 2009 12:53:15 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9LJrIg09656; Wed, 21 Oct 2009 19:53:18 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, 21 Oct 2009 15:53:10 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpShq/qoPxSbruXTN6NgIO7uxjk6wAAURsg References: From: "Brian Lindsay" To: "Hadriel Kaplan" , Subject: Re: [dispatch] To-URI in domain-registration 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, 21 Oct 2009 19:53:16 -0000 Hi Hadriel, Per my comment yesterday, I'd prefer (1). Thanks. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, October 21, 2009 3:43 PM To: dispatch@ietf.org Subject: [dispatch] To-URI in domain-registration Howdy, I'd like to get a consensus call on the question of what the To-URI should be for the REGISTER request of a domain registration, before finishing the next rev of the draft. This will affect quite a bit of text in the draft (e.g., examples), and I think that the decision about that will also affect whether we need more than a Require:option-tag as well. The choices right now are: 1) Mandate the To-URI be in the syntactical form of an AoR, including the user@ portion, the same as the From-URI. Pros: closer to what current proprietary and other-SDO mechanisms do, on the wire. Therefore, presumably less of a change and less barrier to adoption. 2) Mandate the To-URI be a domain only (no user@), while the From-URI remains the "AoR" of the PBX registering. Pros: semantically accurate (you're registering a domain, not an AoR), and may obviate the need for a new header or param to indicate this new mechanism is being used. Can people please indicate which they'd prefer? Thanks! -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Wed Oct 21 12:57: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 3E1CF3A681E for ; Wed, 21 Oct 2009 12:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_DE=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 bu-T3PEu18Ov for ; Wed, 21 Oct 2009 12:57:12 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 2EFC83A6833 for ; Wed, 21 Oct 2009 12:57:12 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJvIMP022233; Wed, 21 Oct 2009 21:57:18 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJvI6L019724; Wed, 21 Oct 2009 21:57:18 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 21 Oct 2009 21:57:17 +0200 From: "Elwell, John" To: Hadriel Kaplan , "dispatch@ietf.org" Date: Wed, 21 Oct 2009 21:57:12 +0200 Thread-Topic: To-URI in domain-registration Thread-Index: AcpShq/qoPxSbruXTN6NgIO7uxjk6wAAd/+Q Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E17@DEMCHP99E35MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] To-URI in domain-registration 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, 21 Oct 2009 19:57:13 -0000 Hadriel, I don't have a strong opinion either way, so in the interests of making pro= gress on this important document I will go with the majority. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 21 October 2009 20:43 > To: dispatch@ietf.org > Subject: [dispatch] To-URI in domain-registration >=20 > Howdy, > I'd like to get a consensus call on the question of what the=20 > To-URI should be for the REGISTER request of a domain=20 > registration, before finishing the next rev of the draft. =20 > This will affect quite a bit of text in the draft (e.g.,=20 > examples), and I think that the decision about that will also=20 > affect whether we need more than a Require:option-tag as well. >=20 > The choices right now are: > 1) Mandate the To-URI be in the syntactical form of an AoR,=20 > including the user@ portion, the same as the From-URI. > Pros: closer to what current proprietary and other-SDO=20 > mechanisms do, on the wire. Therefore, presumably less of a=20 > change and less barrier to adoption. > 2) Mandate the To-URI be a domain only (no user@), while the=20 > From-URI remains the "AoR" of the PBX registering. > Pros: semantically accurate (you're registering a=20 > domain, not an AoR), and may obviate the need for a new=20 > header or param to indicate this new mechanism is being used. >=20 > Can people please indicate which they'd prefer? >=20 > Thanks! > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From victor.pascual.avila@gmail.com Wed Oct 21 13:03: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 1DD483A69D8 for ; Wed, 21 Oct 2009 13:03:29 -0700 (PDT) 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 KPrb9sNQfYMs for ; Wed, 21 Oct 2009 13:03:28 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id E26573A68D0 for ; Wed, 21 Oct 2009 13:03:27 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so1616135eyd.51 for ; Wed, 21 Oct 2009 13:03:33 -0700 (PDT) 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=kXhFrj3zVEkGmqPBM62udp3Uukm7OgQVc2CYkUnIBs0=; b=tDymv/t07ksbLKBIsoxPLffb8LvCjbfAiVUZLfTf5/PX5dKwwKERv6LMG3MPpCtul1 5xAaR9dIAfy03L9Kg5YxFGOoOC6IdOEPmndrf76XxKFEjSRI/WZ29jqen7Jk2CFxiZqr 0cXYnYimm9IeT6LjO/+MaOWxG8oO3zIT/VasI= 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=EMGg7EnxRfrCabfEOklzSkUbJCPufkBCD1T51wmwnCd6bAxz6dpEKQFFPeKU1anjhq YnwKf4VvVEc8JwX0WmZUhKtNKwSt7Z/NUB2F3KNpq58TCP2c/Nozlf9z+dlFb6mO7DSy almxSM6qOkKOApisX1Nzso96IzT2I5txY8Cmk= MIME-Version: 1.0 Received: by 10.216.91.66 with SMTP id g44mr26385wef.121.1256155413367; Wed, 21 Oct 2009 13:03:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Oct 2009 22:03:33 +0200 Message-ID: <618e24240910211303y259c5d65yc12d28eeb1654f8@mail.gmail.com> From: Victor Pascual Avila To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] To-URI in domain-registration 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, 21 Oct 2009 20:03:29 -0000 Hadriel, I'd prefer option (1) Cheers, -Victor On Wed, Oct 21, 2009 at 9:42 PM, Hadriel Kaplan wr= ote: > Howdy, > I'd like to get a consensus call on the question of what the To-URI shoul= d be for the REGISTER request of a domain registration, before finishing th= e next rev of the draft. =C2=A0This will affect quite a bit of text in the = draft (e.g., examples), and I think that the decision about that will also = affect whether we need more than a Require:option-tag as well. > > The choices right now are: > 1) Mandate the To-URI be in the syntactical form of an AoR, including the= user@ portion, the same as the From-URI. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: closer to what current proprietary and o= ther-SDO mechanisms do, on the wire. =C2=A0Therefore, presumably less of a = change and less barrier to adoption. > 2) Mandate the To-URI be a domain only (no user@), while the From-URI rem= ains the "AoR" of the PBX registering. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: semantically accurate (you're registerin= g a domain, not an AoR), and may obviate the need for a new header or param= to indicate this new mechanism is being used. > > Can people please indicate which they'd prefer? > > Thanks! > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Victor Pascual =C3=81vila From D.Hancock@CableLabs.com Wed Oct 21 13:04: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 214EA3A6A0D for ; Wed, 21 Oct 2009 13:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 khGpet7gdc0J for ; Wed, 21 Oct 2009 13:04:26 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id F2BE03A67EC for ; Wed, 21 Oct 2009 13:04:25 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9LK4XID019313; Wed, 21 Oct 2009 14:04:33 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 21 Oct 2009 14:04:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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, 21 Oct 2009 14:04:33 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpShq/qoPxSbruXTN6NgIO7uxjk6wAAURsgAABifNA= References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com> From: "David Hancock" To: "Brian Lindsay" , "Hadriel Kaplan" , X-Approved: ondar Subject: Re: [dispatch] To-URI in domain-registration 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, 21 Oct 2009 20:04:27 -0000 Hadriel - I'd prefer option 1) as well. David > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Brian Lindsay > Sent: Wednesday, October 21, 2009 1:53 PM > To: Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration >=20 > Hi Hadriel, >=20 > Per my comment yesterday, I'd prefer (1). >=20 > Thanks. >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Wednesday, October 21, 2009 3:43 PM > To: dispatch@ietf.org > Subject: [dispatch] To-URI in domain-registration >=20 > Howdy, > I'd like to get a consensus call on the question of what the To-URI > should be for the REGISTER request of a domain registration, before > finishing the next rev of the draft. This will affect quite a bit of > text in the draft (e.g., examples), and I think that the decision about > that will also affect whether we need more than a Require:option-tag as > well. >=20 > The choices right now are: > 1) Mandate the To-URI be in the syntactical form of an AoR, including > the user@ portion, the same as the From-URI. > Pros: closer to what current proprietary and other-SDO > mechanisms do, on the wire. Therefore, presumably less of a change and > less barrier to adoption. > 2) Mandate the To-URI be a domain only (no user@), while the From-URI > remains the "AoR" of the PBX registering. > Pros: semantically accurate (you're registering a domain, not an > AoR), and may obviate the need for a new header or param to indicate > this new mechanism is being used. >=20 > Can people please indicate which they'd prefer? >=20 > Thanks! > -hadriel > _______________________________________________ > 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 richard@shockey.us Wed Oct 21 13:42: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 7920428C13F for ; Wed, 21 Oct 2009 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.322, 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 hEPJm7tJzrXI for ; Wed, 21 Oct 2009 13:42:17 -0700 (PDT) Received: from outbound-mail-315.bluehost.com (outbound-mail-315.bluehost.com [67.222.54.8]) by core3.amsl.com (Postfix) with SMTP id 5167728C137 for ; Wed, 21 Oct 2009 13:42:17 -0700 (PDT) Received: (qmail 28589 invoked by uid 0); 21 Oct 2009 20:42:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 21 Oct 2009 20:42:26 -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=WAW1bK4nCIg5hyMw9p+zuKM5TBRiXSVY15ECWBvnS6IAhLZJN4/kEeJhaomSTNwXrZlJJP0O1Viebjg3nLSwnsD54902ljczYQtxL0ANxTWJBY+9teKpN09zkExH8vZM; 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 1N0i0o-0007xo-0E for dispatch@ietf.org; Wed, 21 Oct 2009 14:42:26 -0600 From: "Richard Shockey" To: References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com> <9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> Date: Wed, 21 Oct 2009 16:42:18 -0400 Message-ID: <024101ca528e$fbd0a8b0$f371fa10$@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: AcpShq/qoPxSbruXTN6NgIO7uxjk6wAAURsgAABifNAAAVuFcA== 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] To-URI in domain-registration 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, 21 Oct 2009 20:42:18 -0000 +1 to Option 1) as well > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of David Hancock > Sent: Wednesday, October 21, 2009 4:05 PM > To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > > > Hadriel - I'd prefer option 1) as well. > > David > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > > Behalf Of Brian Lindsay > > Sent: Wednesday, October 21, 2009 1:53 PM > > To: Hadriel Kaplan; dispatch@ietf.org > > Subject: Re: [dispatch] To-URI in domain-registration > > > > Hi Hadriel, > > > > Per my comment yesterday, I'd prefer (1). > > > > Thanks. > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > > Behalf Of Hadriel Kaplan > > Sent: Wednesday, October 21, 2009 3:43 PM > > To: dispatch@ietf.org > > Subject: [dispatch] To-URI in domain-registration > > > > Howdy, > > I'd like to get a consensus call on the question of what the To-URI > > should be for the REGISTER request of a domain registration, before > > finishing the next rev of the draft. This will affect quite a bit > of > > text in the draft (e.g., examples), and I think that the decision > about > > that will also affect whether we need more than a Require:option-tag > as > > well. > > > > The choices right now are: > > 1) Mandate the To-URI be in the syntactical form of an AoR, > including > > the user@ portion, the same as the From-URI. > > Pros: closer to what current proprietary and other-SDO > > mechanisms do, on the wire. Therefore, presumably less of a change > and > > less barrier to adoption. > > 2) Mandate the To-URI be a domain only (no user@), while the From- > URI > > remains the "AoR" of the PBX registering. > > Pros: semantically accurate (you're registering a domain, not an > > AoR), and may obviate the need for a new header or param to indicate > > this new mechanism is being used. > > > > Can people please indicate which they'd prefer? > > > > Thanks! > > -hadriel > > _______________________________________________ > > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From BPenfield@acmepacket.com Wed Oct 21 13:55: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 117783A6A4C for ; Wed, 21 Oct 2009 13:55:55 -0700 (PDT) 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 cDjPZYrHTFkv for ; Wed, 21 Oct 2009 13:55:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1F9043A6A34 for ; Wed, 21 Oct 2009 13:55:54 -0700 (PDT) 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, 21 Oct 2009 16:56:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 21 Oct 2009 16:56:02 -0400 From: Bob Penfield To: Hadriel Kaplan , "dispatch@ietf.org" Date: Wed, 21 Oct 2009 16:56:01 -0400 Thread-Topic: To-URI in domain-registration Thread-Index: AcpShq/qoPxSbruXTN6NgIO7uxjk6wACXZ/g Message-ID: <429446390BA91242867940DBE798A06B73FC543578@mail> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] To-URI in domain-registration 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, 21 Oct 2009 20:55:55 -0000 I think option 2 is better because it is "do what I say" rather than "do wh= at I mean". I would keep the option tag since it's an extension and require= s different behavior in the registrar. cheers, (-:bob -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Hadriel Kaplan Sent: Wednesday, October 21, 2009 3:43 PM To: dispatch@ietf.org Subject: [dispatch] To-URI in domain-registration Howdy, I'd like to get a consensus call on the question of what the To-URI should = be for the REGISTER request of a domain registration, before finishing the = next rev of the draft. This will affect quite a bit of text in the draft (= e.g., examples), and I think that the decision about that will also affect = whether we need more than a Require:option-tag as well. The choices right now are: 1) Mandate the To-URI be in the syntactical form of an AoR, including the u= ser@ portion, the same as the From-URI. Pros: closer to what current proprietary and other-SDO mechanisms do, on t= he wire. Therefore, presumably less of a change and less barrier to adopti= on. 2) Mandate the To-URI be a domain only (no user@), while the From-URI remai= ns the "AoR" of the PBX registering. Pros: semantically accurate (you're registering a domain, not an AoR), and= may obviate the need for a new header or param to indicate this new mechan= ism is being used. Can people please indicate which they'd prefer? Thanks! -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From spencer@wonderhamster.org Wed Oct 21 14:28: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 69A8128C104 for ; Wed, 21 Oct 2009 14:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=1.010, 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 lJmBy17xGZOY for ; Wed, 21 Oct 2009 14:28:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8BB6328C100 for ; Wed, 21 Oct 2009 14:28:15 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MLveu-1MszUc2ncq-0087AQ; Wed, 21 Oct 2009 17:28:22 -0400 Message-ID: From: "Spencer Dawkins" To: "Bob Penfield" , "Hadriel Kaplan" , References: <429446390BA91242867940DBE798A06B73FC543578@mail> Date: Wed, 21 Oct 2009 16:28:10 -0500 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+l+j0FDG6qktBdqVa3TFyAOCzi406eT1MEf5o KP7WxGwP5hBXH0smo2RzZVdyOHwNL5V29aZM/TgAyML1rybrKk uf0QbV7j1UMmyKtUUNCJCQh71vwQrfgyxgaaNEixkc= Subject: Re: [dispatch] To-URI in domain-registration 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, 21 Oct 2009 21:28:16 -0000 On Bob's post - I'm also assuming that we'll keep the option tag, for roughly the reasons Bob listed. I believe Hadriel's question is intended to solve the question "how do I know that domain registration actually happened (as opposed to knowing that the other UA supports domain registration", raised on this list a couple of days ago - the guidance we got was not to rely on Requires as an indication that the extension was actually used). Hope this is helpful... Spencer >I think option 2 is better because it is "do what I say" rather than "do >what I mean". I would keep the option tag since it's an extension and >requires different behavior in the registrar. > > cheers, > (-:bob > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Wednesday, October 21, 2009 3:43 PM > To: dispatch@ietf.org > Subject: [dispatch] To-URI in domain-registration > > Howdy, > I'd like to get a consensus call on the question of what the To-URI should > be for the REGISTER request of a domain registration, before finishing the > next rev of the draft. This will affect quite a bit of text in the draft > (e.g., examples), and I think that the decision about that will also > affect whether we need more than a Require:option-tag as well. > > The choices right now are: > 1) Mandate the To-URI be in the syntactical form of an AoR, including the > user@ portion, the same as the From-URI. > Pros: closer to what current proprietary and other-SDO mechanisms do, on > the wire. Therefore, presumably less of a change and less barrier to > adoption. > 2) Mandate the To-URI be a domain only (no user@), while the From-URI > remains the "AoR" of the PBX registering. > Pros: semantically accurate (you're registering a domain, not an AoR), and > may obviate the need for a new header or param to indicate this new > mechanism is being used. > > Can people please indicate which they'd prefer? > > Thanks! > -hadriel > _______________________________________________ > 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 BPenfield@acmepacket.com Wed Oct 21 15:13: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 DF7603A68C2 for ; Wed, 21 Oct 2009 15:13:22 -0700 (PDT) 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 dD14VtmYOowz for ; Wed, 21 Oct 2009 15:13:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DA0213A6825 for ; Wed, 21 Oct 2009 15:13:21 -0700 (PDT) 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, 21 Oct 2009 18:13:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 21 Oct 2009 18:13:28 -0400 From: Bob Penfield To: Spencer Dawkins , Hadriel Kaplan , "dispatch@ietf.org" Date: Wed, 21 Oct 2009 18:13:26 -0400 Thread-Topic: option tag in domain-registration (was RE: [dispatch] To-URI in domain-registration) Thread-Index: AcpSlXL0RPvLiiwNSR6g5GoLFZceJgABTa1g Message-ID: <429446390BA91242867940DBE798A06B73FC54357F@mail> References: <429446390BA91242867940DBE798A06B73FC543578@mail> 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: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 21 Oct 2009 22:13:23 -0000 I understand that including the tag in a Require header does not mean that = the UAS will apply that extension. However, if the UAS does apply the exten= sion (if I understand the sentence below from section 8.2.4 correctly) it i= s suppose to include the tag in a Require header in the response. Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. =20 So wouldn't that mean that the UAC can know for sure that 'dreg" was applie= d if the response has "Require: dreg"? cheers, (-:bob -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 Sent: Wednesday, October 21, 2009 5:28 PM To: Bob Penfield; Hadriel Kaplan; dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration On Bob's post - I'm also assuming that we'll keep the option tag, for=20 roughly the reasons Bob listed. I believe Hadriel's question is intended to solve the question "how do I=20 know that domain registration actually happened (as opposed to knowing that= =20 the other UA supports domain registration", raised on this list a couple of= =20 days ago - the guidance we got was not to rely on Requires as an indication= =20 that the extension was actually used). Hope this is helpful... Spencer >I think option 2 is better because it is "do what I say" rather than "do=20 >what I mean". I would keep the option tag since it's an extension and=20 >requires different behavior in the registrar. > > cheers, > (-:bob > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: Wednesday, October 21, 2009 3:43 PM > To: dispatch@ietf.org > Subject: [dispatch] To-URI in domain-registration > > Howdy, > I'd like to get a consensus call on the question of what the To-URI shoul= d=20 > be for the REGISTER request of a domain registration, before finishing th= e=20 > next rev of the draft. This will affect quite a bit of text in the draft= =20 > (e.g., examples), and I think that the decision about that will also=20 > affect whether we need more than a Require:option-tag as well. > > The choices right now are: > 1) Mandate the To-URI be in the syntactical form of an AoR, including the= =20 > user@ portion, the same as the From-URI. > Pros: closer to what current proprietary and other-SDO mechanisms do, on= =20 > the wire. Therefore, presumably less of a change and less barrier to=20 > adoption. > 2) Mandate the To-URI be a domain only (no user@), while the From-URI=20 > remains the "AoR" of the PBX registering. > Pros: semantically accurate (you're registering a domain, not an AoR), an= d=20 > may obviate the need for a new header or param to indicate this new=20 > mechanism is being used. > > Can people please indicate which they'd prefer? > > Thanks! > -hadriel > _______________________________________________ > 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 From pkyzivat@cisco.com Wed Oct 21 15:56: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 464013A67EF for ; Wed, 21 Oct 2009 15:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.663 X-Spam-Level: X-Spam-Status: No, score=-6.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 GecMuTAWiTOx for ; Wed, 21 Oct 2009 15:56:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1BAC73A67B3 for ; Wed, 21 Oct 2009 15:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4036; q=dns/txt; s=sjiport03001; t=1256165779; x=1257375379; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20option=20tag=20in=20domain-registra tion=20(was=20RE:=20To-URI=0D=0A=20in=20domain-registrati on)|Date:=20Wed,=2021=20Oct=202009=2018:56:14=20-0400 |Message-ID:=20<4ADF918E.4060406@cisco.com>|To:=20Bob=20P enfield=20|CC:=20Spencer=20Dawk ins=20,=0D=0A=20=20=20=20=20 =20=20=20Hadriel=20Kaplan=20,=0D =0A=20=20=20=20=20=20=20=20"dispatch@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<429446 390BA91242867940DBE798A06B73FC54357F@mail>|References:=20 =09<4294 46390BA91242867940DBE798A06B73FC543578@mail>=09=20<429446390BA9 1242867940DBE798A06B73FC54357F@mail>; bh=8caREynTk3X+Q6A//jTrlqoKyMOcl3myXDwlQ/9yQo4=; b=iHFd6HUhNahAuzzyPjrZiye3vqCrWOKwa88LfduT+po5UCb4nTIdqyYr GpQ2MS/Ou0M0RIYWBXvXr2iFYJXvbe1TOanjHcYKCoEgfYC0/hYD3MILX yd8eGalFPVRw+5UK0eoko0qtpuooddZdEI2L+F/sO9eJ/6Ht4ga3E2Cey Y=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACMu30pAZnwN/2dsb2JhbADCeJhYhDME X-IronPort-AV: E=Sophos;i="4.44,600,1249257600"; d="scan'208";a="198121708" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2009 22:56:18 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9LMuI8t028994; Wed, 21 Oct 2009 22:56:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:56:18 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:56:17 -0400 Message-ID: <4ADF918E.4060406@cisco.com> Date: Wed, 21 Oct 2009 18:56:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bob Penfield References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> In-Reply-To: <429446390BA91242867940DBE798A06B73FC54357F@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 22:56:18.0007 (UTC) FILETIME=[B303E670:01CA52A1] Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 21 Oct 2009 22:56:11 -0000 Bob Penfield wrote: > I understand that including the tag in a Require header does not mean that the UAS will apply that extension. However, if the UAS does apply the extension (if I understand the sentence below from section 8.2.4 correctly) it is suppose to include the tag in a Require header in the response. > > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. > > So wouldn't that mean that the UAC can know for sure that 'dreg" was applied if the response has "Require: dreg"? I have always assumed that this means the response contains extensions that the UAC must understand in order to process the the response. E.g. extension headers in the response. I don't think it means what Bob is saying. So, if the response has a "Domain-Registration: active" in the response to REGISTER, and the UAC needs to process that and do something as a result (rather than just ignore the header) then the tag in the response makes sense. But if the response looks identical to one where no domain registration occurred, then I think not. Thanks, Paul > cheers, > (-:bob > > > > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Wednesday, October 21, 2009 5:28 PM > To: Bob Penfield; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > > On Bob's post - I'm also assuming that we'll keep the option tag, for > roughly the reasons Bob listed. > > I believe Hadriel's question is intended to solve the question "how do I > know that domain registration actually happened (as opposed to knowing that > the other UA supports domain registration", raised on this list a couple of > days ago - the guidance we got was not to rely on Requires as an indication > that the extension was actually used). > > Hope this is helpful... > > Spencer > > >> I think option 2 is better because it is "do what I say" rather than "do >> what I mean". I would keep the option tag since it's an extension and >> requires different behavior in the registrar. >> >> cheers, >> (-:bob >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Wednesday, October 21, 2009 3:43 PM >> To: dispatch@ietf.org >> Subject: [dispatch] To-URI in domain-registration >> >> Howdy, >> I'd like to get a consensus call on the question of what the To-URI should >> be for the REGISTER request of a domain registration, before finishing the >> next rev of the draft. This will affect quite a bit of text in the draft >> (e.g., examples), and I think that the decision about that will also >> affect whether we need more than a Require:option-tag as well. >> >> The choices right now are: >> 1) Mandate the To-URI be in the syntactical form of an AoR, including the >> user@ portion, the same as the From-URI. >> Pros: closer to what current proprietary and other-SDO mechanisms do, on >> the wire. Therefore, presumably less of a change and less barrier to >> adoption. >> 2) Mandate the To-URI be a domain only (no user@), while the From-URI >> remains the "AoR" of the PBX registering. >> Pros: semantically accurate (you're registering a domain, not an AoR), and >> may obviate the need for a new header or param to indicate this new >> mechanism is being used. >> >> Can people please indicate which they'd prefer? >> >> Thanks! >> -hadriel >> _______________________________________________ >> 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 > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Wed Oct 21 18:06: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 408E23A6847 for ; Wed, 21 Oct 2009 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.623 X-Spam-Level: X-Spam-Status: No, score=-6.623 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 b02qCy-7lVHA for ; Wed, 21 Oct 2009 18:06:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 88DDE3A63D3 for ; Wed, 21 Oct 2009 18:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=13278; q=dns/txt; s=sjiport05001; t=1256173610; x=1257383210; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20New=20version=20for=20the=20Alert-I nfo=20URNs=20draft:=09draft-liess-dispatch-alert-info-urn s-00.txt|Date:=20Wed,=2021=20Oct=202009=2021:06:48=20-040 0|Message-ID:=20<4ADFB028.3010604@cisco.com>|To:=20L.Lies s@telekom.de|CC:=20john.elwell@siemens-enterprise.com,=20 dispatch@ietf.org,=20anwars@avaya.com,=0D=0A=20=20=20=20 =20=20=20=20R.Jesske@telekom.de,=20alan@sipstation.com |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<40FB0FFB97588246A1BEFB05759DC8A003885F8F @S4DE9JSAANI.ost.t-com.de>|References:=20<40FB0FFB9758824 6A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de>=20<4A DCCF93.2070208@cisco.com>=20<40FB0FFB97588246A1BEFB05759D C8A003885F8F@S4DE9JSAANI.ost.t-com.de>; bh=0lLcBUUcgDy4FVFyCYUcQBf42/lZsMNa3CmnIOH/0dM=; b=na+2jtKRi/3Z9m/NXo75T6dpBYiw2xbwp4HZTwpeuU/jXvFzBaUzFjNb RobcB5wB5FvofUNX9u0SRr/aqtsQGsuRyiwvWsDq7LnN4x1R4CJlxTMnJ UPVbyXF9E0KNoAH5opvylt0DRGDfLZF7oXdLYLTJSzfLRXdT9PedPEdOM o=; 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: ApoEAOdM30qtJV2c/2dsb2JhbADCDZhYgj+BfgQ X-IronPort-AV: E=Sophos;i="4.44,601,1249257600"; d="scan'208";a="100220170" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2009 01:06:49 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id n9M16mkn029306; Thu, 22 Oct 2009 01:06:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 21:06:48 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 21:06:48 -0400 Message-ID: <4ADFB028.3010604@cisco.com> Date: Wed, 21 Oct 2009 21:06:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 01:06:48.0404 (UTC) FILETIME=[EE4BA940:01CA52B3] Cc: dispatch@ietf.org, R.Jesske@telekom.de, anwars@avaya.com Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 22 Oct 2009 01:06:42 -0000 responses inline L.Liess@telekom.de wrote: > Paul, > > Thank you very much for taking the time to look and comment the draft. > After the changes we did shortly before the submission deadline, there > are some inconsistecies and open items. We are aware of some of them and > probably there are some we are not aware of. For the problems we are > aware of, there are alternative solutions. In some cases, we did not > have a clear opinion which way to go and we would like to hear others > opinions. > > > Please find comments inline: > > > > > This seems to be shaping up well. I think the requirements are > quite > > clear now. > > It's good to hear that we have achieved at least a smal stepp in the > right direction :-). > > > > I don't fully understand what is intended regarding > combination of > > multiple alert URNs for a specific situation. Section 4.5 > states: > > > > > finally, a short Albanian auto-callback tone could be > indicated > > > Alert-Info: , > > > , . > > > > while section 7.3.6 states: > > > > > Alert URN Indications from the same group should not be > combined. > > > > To avoid the combinatorial explosion of IANA values as Adam pointed out > in his comment > http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html , we > decided to abandon the usage of sub-indications for the use cases we > have in the draft and to register only discrete tokens as top-level > registrations. (With county-specidfic ring and busy tones, we almost > got the problem Adam talked about.) The sub-indications are no longer > used in the current version of the draft. So, maybe that is the confusion. I didn't understand that from reading the text. > We thougt about changing the template in chapter 3 from > > alert-indication = top-level *("." sub-indication) > top-level = let-dig [ *25let-dig-hyp let-dig ] > sub-indication = let-dig [ *let-dig-hyp let-dig ] > > to just > alert-indication= let-dig [ *let-dig-hyp let-dig ] > > But we are not sure if everyone would agree with this, so we would like > to have feedback from the WG on this issue. I don't know yet. The alternative is apparently to have multiple URNs and interpret the combination. I'm having difficulty imagining how that would work. I have always assumed that in the end a URN would be "looked up" locally by the UA and resolved to *something* that it could render. I will keep an open mind, but I'll need a better explanation of how multiple URNs are to be combined into *something* that can be looked up. > There is an inconcistency concerning the alert indications "priority", > "short" and "delayed": In chapter 4, they are now top-level indications > in the alert-category "service", therefore in the same group eith > "auto-callback". In chapter 7 there is a dedicated group for them > "Additional Indications for PBX-tones" in the "tones" alert-category. > We must have to decide which alternative to take. If we decide for the > chapter 4 alternative, we must change either the combination rule or the > example you complained about. > > > > I could find no definition of what constitutes a "group". The > first > > thing that comes to mind is "service" vs. "tone", but the > > above example > > violates that. It seems to me that you need some notion of > orthogonal > > properties in order to define what can/cannot be combined. > > It's true, it's quite impossible to guess from the text what I meant > here. A group consists of the indications in one sub-chapter 7.3.1 to > 7.3.5. I just looked for a way to avoid combinations of contradictory > URNs, e.g. that is combined with > or is combined with > . If we agree that this kind of groups makes sense > and we keep it, some definition needs to be added. But maybe there are > better proposals in the WG about how to avoid combinations of > contradictory indications? It seems like what you must be doing is replacing a hierarchy with an N-dimensional matrix which is sparsely populated. That seems harder to deal with. > > It would be good to have more detail about how a recipient > > should deal > > with multiple URNs. > > Yes. But I think we need to work in steps: > -First we need to see if we have an aggreement on the new proposal > about registering discrete tokens ("internal" and "priority" instead of > "internal.priority"). > -If this OK, we have to decide if we changed the template otr not. > -We need, I think, some rules to avoid combinations of URNs which > are obviously contradictory. I don't think that works. I can't evaluate whether the approach works without a practical understanding of how it could be used. In the end I have to render *something*. And I have to choose what that is. While hierarchical names present a class of problems, its at least clear how to resolve them to something I have. > > I'm also uncertain of what your intent is regarding top-level > vs. > > additional indications. As specified, I believe a given > "additional > > indication" name is always defined with regard to its parent, > so that > > "short" as used in "normal.short" might mean something > entirely > > different than "priority.short", or might not be defined for > > priority at > > all. > > We changed this in this version, see > http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . If > we do not agree on this change, we need another mean to avoid > combinatorial explosion and the same time still being able to send > country specific ringing tones, country specific busy tones and country > specific whatever tones. I understand Adam's issue. I just don't (yet) understand how/if the alternative works. It seems that what you propose is a multidimensional space, where every point in that space is potentially rendered uniquely. But in practice values will often be supplied for some but not all of the dimensions. In that case we end up specifying some "slice" of the array. I guess in this case you could look to see what you would render for each point in the slice. If those are all identical, then you are in good shape. But if they are not, then what? Do you pick one of the points? That amounts to choosing a default value for each unspecified dimension. Is that the right answer? I also understand that this approach works great if all the renderings are audio, and each of the dimensions is an input to a synthesizer algorithm. But that pretty much only works for audio. If you have to render in user friendly text, or in flashes of light then it isn't going to work very well. Nor does it work for audio if you want to use unique sound clips for some or all of the cases. > > Yet from the registration text in 7.3.2 it sounds like the > > intent is for > > priority, short, and delayed to be defined for all pbx-tones. > > If that is > > the intent, then I don't think the existing text meets that > intent. > > This should be achieved by sending two URNs, one from the group 7.3.1. > "Indications for PBX-tones" and the second from the group 7.3.2. > "Additional Indications for PBX-tones" e.g. > and . > > > > > I also wonder if the existing hierarchy will work well in > > practice, or > > if some other organization might not work better. For > > instance, it might > > be more convenient to specify ringing.fr with the clear > understanding > > that if you don't know about ringing.fr you can just treat it > > as ringing. > > See above comments. > > > > > > I'm also confused by PBX tones vs. Public telephone tones. In > > what way > > is "normal" different from "ringing"? I would think that PBX > > tones would > > be a superset of common pstn tones. > > I think a PBX has ist own tones for normal, internal and external > ringing, different from those of the public network. I have a sip pbx phone on my desk. I don't have any distinction for internal vs. external, and have no clue how "normal" would be different from one or the other of those. I don't really desire any distinction on any of those terms. > I would keep the two worlds disjunct. E.g. , I have a sip handy which is > attached sometimes to the pbx and sometimes to my public carrier at > home, I may want the pbx ringing tone to be different from the ringing > tone at home. I don't really have any objection to a bunch of "names" for extra arbitrary ring types. The real issue is deciding when to use one or another. Is the assumption here that these will typically be inserted by some agent acting on behalf of the phone acting on them, rather than being inserted by "the other" party? IOW, *my* pbx decides that an incoming call from you is "internal" or "external" and inserts a suitable value by its policy, rather than *your* phone deciding the call is internal or external and inserting the value that I then render. It seems like you might have both models in mind. On one hand *my* pbx is deciding if the call to me is internal or external, but the other end is indicating it is a French phone rather than a US phone and so at least ringback should be french. > > A nit: in 4.3.2 I would expext the forward to be indicated, > > if at all, > > with a 181 rather than a 180. > > My understanding is that the URN should be transmitted in the 180 > ringing after the forwarded call has reached ist final destination and > the phone is ringing at the UE, not in the 181 sent by the forwarding > proxy when it decides to to forward the call. Also the RFC 3261 only > allows Alert-Info in 180 responses. Or did I miss something here? I checked, and you are right that A-I isn't allowed in 181. Sorry about that. But it seems like a mistake to me. The behavior you describe requires there to be a stateful agent in the network that is aware this has happened. In general there may be nothing in a position to perform that role. But in any case it is a nit. Thanks, Paul > Thanks a lot > Laura > >> Thanks, >> Paul >> >> L.Liess@telekom.de wrote: >>> >>> Hi, >>> >>> We've re-submitted the Alert-Info URNs draft for DISPATCH >>> >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert >> -info-urns >>> -00.txt . (The previous version od the draft was in BLISS >> and we had a >>> presentation in BLISS at the last IETF.) >>> >>> We did some major changes, as suggested on the mailing list, e.g.: >>> Added: >>> - Description of the interoperability problems for >> PBX-services (in >>> the Introduction chapter) >>> - Requirements for the Alert-Info URNs mechanism >>> - Alert-Info URNs Indications for country-specific tones >>> Changed: >>> - Initial IANA Registration mechanism to avoid >> combinatorial explosion >>> of IANA values. >>> >>> >>> Many thanks for the comments and suggestions, >>> Laura >>> >>> >>> >>> >>> >>> -----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, October 19, 2009 1:00 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Alert-Info URNs for the Session Initiation >>> Protocol (SIP) >>> Author(s) : D. Alexeitsev, et al. >>> Filename : draft-liess-dispatch-alert-info-urns-00.txt >>> Pages : 25 >>> Date : 2009-10-19 >>> >>> The Session Initiation Protocol (SIP) supports the capability to >>> provide a reference to the alternative ringback tone (RBT) for >>> caller, or ring tone (RT) for callee using the Alert-Info header. >>> However, the reference addresses only the network resources with >>> specific rendering properties. There is currently no support for >>> predefined standard identifiers for ringback tones or semantic >>> indications without tied rendering. To overcome this >> limitations and >>> support new applications a family of the URNs is defined in this >>> specification. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert >> -info-urns >>> -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 Oct 21 21:07: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 4CD953A6898 for ; Wed, 21 Oct 2009 21:07:56 -0700 (PDT) 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 B+LTqPPqj0Bo for ; Wed, 21 Oct 2009 21:07:55 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6E7DF3A686B for ; Wed, 21 Oct 2009 21:07:55 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9M47xKk017019; Wed, 21 Oct 2009 23:07:59 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Thu, 22 Oct 2009 04:08:00 -0000 (UTC) Message-ID: <2e03aec25441bdc898991e48e5bc2d16.squirrel@www.softarmor.com> In-Reply-To: <4ADF918E.4060406@cisco.com> References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> <4ADF918E.4060406@cisco.com> Date: Thu, 22 Oct 2009 04:08:00 -0000 (UTC) From: "Dean Willis" To: "Paul Kyzivat" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "dispatch@ietf.org" Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 22 Oct 2009 04:07:56 -0000 On Wed, October 21, 2009 10:56 pm, Paul Kyzivat wrote: > Bob Penfield wrote: >> I understand that including the tag in a Require header does not mean >> that the UAS will apply that extension. However, if the UAS does apply >> the extension (if I understand the sentence below from section 8.2.4 >> correctly) it is suppose to include the tag in a Require header in the >> response. >> >> Any extensions applied to a non-421 response MUST be listed in a >> Require header field included in the response. >> >> So wouldn't that mean that the UAC can know for sure that 'dreg" was >> applied if the response has "Require: dreg"? > > I have always assumed that this means the response contains extensions > that the UAC must understand in order to process the the response. E.g. > extension headers in the response. I don't think it means what Bob is > saying. While that makes more sense than what the text actually says, I think Bob is reading it correctly. Unfortunately, many of our options-tag-defining extensions don't seem return the option tag in the response correctly. This includes stuff I edited, like RFC 5373 (answer-mode), Paul's idea that the response contains extensions that the UAC must understand doesn't work, as the UAC has no way of rejecting a response because it doesn't understand an extension. All it could do would be discard-and-cancel, which is a bit awkward. -- Dean From dean.willis@softarmor.com Wed Oct 21 21:10: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 551633A686B for ; Wed, 21 Oct 2009 21:10:40 -0700 (PDT) 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 7d-FaJ8R-rDg for ; Wed, 21 Oct 2009 21:10:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 941DE3A6817 for ; Wed, 21 Oct 2009 21:10:39 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9M4Al7S017070; Wed, 21 Oct 2009 23:10:47 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Thu, 22 Oct 2009 04:10:47 -0000 (UTC) Message-ID: <603f3ddf31bb2db132672604352eef9f.squirrel@www.softarmor.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com> References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com> Date: Thu, 22 Oct 2009 04:10:47 -0000 (UTC) From: "Dean Willis" To: "Brian Lindsay" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration 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, 22 Oct 2009 04:10:40 -0000 Hadriel asked: > The choices right now are: > 1) Mandate the To-URI be in the syntactical form of an AoR, including > the user@ portion, the same as the From-URI. > Pros: closer to what current proprietary and other-SDO > mechanisms do, on the wire. Therefore, presumably less of a change and > less barrier to adoption. If you do #1, then we need some clarity on what goes into the user portion and how that affects authentication, etc. I suppose one could use a "reserved" username (like "domain"), but we don't really have a registry for that. -- Dean From dean.willis@softarmor.com Wed Oct 21 21:11: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 EDF7B3A6898 for ; Wed, 21 Oct 2009 21:11:46 -0700 (PDT) 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 C32nIBn5OcQL for ; Wed, 21 Oct 2009 21:11:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 36B0C3A686B for ; Wed, 21 Oct 2009 21:11:46 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9M4Brad017112; Wed, 21 Oct 2009 23:11:53 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Thu, 22 Oct 2009 04:11:53 -0000 (UTC) Message-ID: <190701c7e8016ab7e4b4c36dc684e9ce.squirrel@www.softarmor.com> In-Reply-To: <618e24240910211303y259c5d65yc12d28eeb1654f8@mail.gmail.com> References: <618e24240910211303y259c5d65yc12d28eeb1654f8@mail.gmail.com> Date: Thu, 22 Oct 2009 04:11:53 -0000 (UTC) From: "Dean Willis" To: "Victor Pascual Avila" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "dispatch@ietf.org" Subject: Re: [dispatch] To-URI in domain-registration 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, 22 Oct 2009 04:11:47 -0000 On Wed, October 21, 2009 8:03 pm, Victor Pascual Avila wrote: > Hadriel, > > I'd prefer option (1) What's better about it? Is it just that it's easier to implement because that's what you have already, or is there some sort of semantic advantage? -- Dean From dean.willis@softarmor.com Wed Oct 21 21:18: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 3800F3A69BB for ; Wed, 21 Oct 2009 21:18:28 -0700 (PDT) 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 YmYPO8L4BXhr for ; Wed, 21 Oct 2009 21:18:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6655D28C0D6 for ; Wed, 21 Oct 2009 21:18:27 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9M4IZfL017202; Wed, 21 Oct 2009 23:18:35 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Thu, 22 Oct 2009 04:18:35 -0000 (UTC) Message-ID: In-Reply-To: References: <429446390BA91242867940DBE798A06B73FC543578@mail> Date: Thu, 22 Oct 2009 04:18:35 -0000 (UTC) From: "Dean Willis" To: "Spencer Dawkins" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration 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, 22 Oct 2009 04:18:28 -0000 On Wed, October 21, 2009 9:28 pm, Spencer Dawkins wrote: > On Bob's post - I'm also assuming that we'll keep the option tag, for > roughly the reasons Bob listed. > > I believe Hadriel's question is intended to solve the question "how do I > know that domain registration actually happened (as opposed to knowing > that > the other UA supports domain registration", raised on this list a couple > of > days ago - the guidance we got was not to rely on Requires as an > indication > that the extension was actually used). No, I think Hadriel's question goes more to "How does the registrar know to do domain registration ratehr than AOR registration?" (at least that was the question I asked that I think lead to this discussion). If we go with #2, then it's easy: If the "To:" of the request is a fully-qualifed SIP URI (an AOR), the registrar does standard registration. If it's a naked domain, the registrar does the new domain registration. This lets us later say "And if it's a te;: URI, then do telephone registration", which could be a handy extension for many people. This is much better than using a Require option tag as a clue to engage the new behavior. The Require is there to make registrars that don't understand the extension fail the request instead of behaving in a surprising manner when they try to process the faux-AOR. -- Dean From spencer@wonderhamster.org Wed Oct 21 21:28: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 5867728C0F1 for ; Wed, 21 Oct 2009 21:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.557, 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 Evf9woZdKI9r for ; Wed, 21 Oct 2009 21:28:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 6CE1628C0D6 for ; Wed, 21 Oct 2009 21:28:27 -0700 (PDT) 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 0M2sXu-1M8AQw2Ucg-00soUL; Thu, 22 Oct 2009 00:28:29 -0400 Message-ID: <1E85E1AF6DC84ACB9F884E51B004BC7C@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" References: <429446390BA91242867940DBE798A06B73FC543578@mail> Date: Wed, 21 Oct 2009 23:28:17 -0500 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: V01U2FsdGVkX18jYKVsWEkG32j9uGG3KNHW/MT3PNJDYZdQg0y cVAnkn66dGJiQc8+hjehR3wHlgoO5Bs/uU7uFTEhNLKRxnXZnN RnP6e8fIrLTuB2RGRv8mfmQDPZXIkvjCc09cSm8Krc= Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration 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, 22 Oct 2009 04:28:28 -0000 I must be incoherent - what Dean said is exactly what I was trying to say. Require header field to actually require support, either domain-only To or some other header field to say that domain registration actually happened, and now we're talking about whether we key off domain-only To or some other header field. Spencer > On Wed, October 21, 2009 9:28 pm, Spencer Dawkins wrote: >> On Bob's post - I'm also assuming that we'll keep the option tag, for >> roughly the reasons Bob listed. >> >> I believe Hadriel's question is intended to solve the question "how do I >> know that domain registration actually happened (as opposed to knowing >> that >> the other UA supports domain registration", raised on this list a couple >> of >> days ago - the guidance we got was not to rely on Requires as an >> indication >> that the extension was actually used). > > No, I think Hadriel's question goes more to "How does the registrar know > to do domain registration ratehr than AOR registration?" (at least that > was the question I asked that I think lead to this discussion). > > If we go with #2, then it's easy: > > If the "To:" of the request is a fully-qualifed SIP URI (an AOR), the > registrar does standard registration. If it's a naked domain, the > registrar does the new domain registration. This lets us later say "And if > it's a te;: URI, then do telephone registration", which could be a handy > extension for many people. > > This is much better than using a Require option tag as a clue to engage > the new behavior. The Require is there to make registrars that don't > understand the extension fail the request instead of behaving in a > surprising manner when they try to process the faux-AOR. > > -- > Dean > > > From mdolly@att.com Wed Oct 21 21:34: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 83B1828C110 for ; Wed, 21 Oct 2009 21:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uT15AbjNNyuK for ; Wed, 21 Oct 2009 21:34:29 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 098D028C0F1 for ; Wed, 21 Oct 2009 21:34:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1256186077!5989320!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 569 invoked from network); 22 Oct 2009 04:34:37 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Oct 2009 04:34:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9M4YaMG022132; Thu, 22 Oct 2009 00:34:36 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9M4YXAI022121; Thu, 22 Oct 2009 00:34:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 22 Oct 2009 00:34:32 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4B4B@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpS0CNUUlFFtt7NQUWZcNaQTS87uAAANBvZ From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration 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, 22 Oct 2009 04:34:30 -0000 T2ssIHNvIGhvdyBtYW55IGxhcHMgYXJvdW5kIHRoZSByYXQgaG9sZSBkbyB3ZSBoYXZlIHRvIHRh a2UgdGlsbCB3ZSBjb252ZXJnZSBvbiBhIHNvbHV0aW9uPw0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQpGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIDxkaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnPg0KVG86IERlYW4gV2lsbGlzIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29t Pg0KQ2M6IGRpc3BhdGNoQGlldGYub3JnIDxkaXNwYXRjaEBpZXRmLm9yZz4NClNlbnQ6IFRodSBP Y3QgMjIgMDA6Mjg6MTcgMjAwOQ0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gVG8tVVJJIGluIGRv bWFpbi1yZWdpc3RyYXRpb24NCg0KSSBtdXN0IGJlIGluY29oZXJlbnQgLSB3aGF0IERlYW4gc2Fp ZCBpcyBleGFjdGx5IHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheS4NCg0KUmVxdWlyZSBoZWFkZXIg ZmllbGQgdG8gYWN0dWFsbHkgcmVxdWlyZSBzdXBwb3J0LCBlaXRoZXIgZG9tYWluLW9ubHkgVG8g b3IgDQpzb21lIG90aGVyIGhlYWRlciBmaWVsZCB0byBzYXkgdGhhdCBkb21haW4gcmVnaXN0cmF0 aW9uIGFjdHVhbGx5IGhhcHBlbmVkLCANCmFuZCBub3cgd2UncmUgdGFsa2luZyBhYm91dCB3aGV0 aGVyIHdlIGtleSBvZmYgZG9tYWluLW9ubHkgVG8gb3Igc29tZSBvdGhlciANCmhlYWRlciBmaWVs ZC4NCg0KU3BlbmNlcg0KDQoNCj4gT24gV2VkLCBPY3RvYmVyIDIxLCAyMDA5IDk6MjggcG0sIFNw ZW5jZXIgRGF3a2lucyB3cm90ZToNCj4+IE9uIEJvYidzIHBvc3QgLSBJJ20gYWxzbyBhc3N1bWlu ZyB0aGF0IHdlJ2xsIGtlZXAgdGhlIG9wdGlvbiB0YWcsIGZvcg0KPj4gcm91Z2hseSB0aGUgcmVh c29ucyBCb2IgbGlzdGVkLg0KPj4NCj4+IEkgYmVsaWV2ZSBIYWRyaWVsJ3MgcXVlc3Rpb24gaXMg aW50ZW5kZWQgdG8gc29sdmUgdGhlIHF1ZXN0aW9uICJob3cgZG8gSQ0KPj4ga25vdyB0aGF0IGRv bWFpbiByZWdpc3RyYXRpb24gYWN0dWFsbHkgaGFwcGVuZWQgKGFzIG9wcG9zZWQgdG8ga25vd2lu Zw0KPj4gdGhhdA0KPj4gdGhlIG90aGVyIFVBIHN1cHBvcnRzIGRvbWFpbiByZWdpc3RyYXRpb24i LCByYWlzZWQgb24gdGhpcyBsaXN0IGEgY291cGxlDQo+PiBvZg0KPj4gZGF5cyBhZ28gLSB0aGUg Z3VpZGFuY2Ugd2UgZ290IHdhcyBub3QgdG8gcmVseSBvbiBSZXF1aXJlcyBhcyBhbg0KPj4gaW5k aWNhdGlvbg0KPj4gdGhhdCB0aGUgZXh0ZW5zaW9uIHdhcyBhY3R1YWxseSB1c2VkKS4NCj4NCj4g Tm8sIEkgdGhpbmsgSGFkcmllbCdzIHF1ZXN0aW9uIGdvZXMgbW9yZSB0byAiSG93IGRvZXMgdGhl IHJlZ2lzdHJhciBrbm93DQo+IHRvIGRvIGRvbWFpbiByZWdpc3RyYXRpb24gcmF0ZWhyIHRoYW4g QU9SIHJlZ2lzdHJhdGlvbj8iIChhdCBsZWFzdCB0aGF0DQo+IHdhcyB0aGUgcXVlc3Rpb24gSSBh c2tlZCB0aGF0IEkgdGhpbmsgbGVhZCB0byB0aGlzIGRpc2N1c3Npb24pLg0KPg0KPiBJZiB3ZSBn byB3aXRoICMyLCB0aGVuIGl0J3MgZWFzeToNCj4NCj4gSWYgdGhlICJUbzoiIG9mIHRoZSByZXF1 ZXN0IGlzIGEgZnVsbHktcXVhbGlmZWQgU0lQIFVSSSAoYW4gQU9SKSwgdGhlDQo+IHJlZ2lzdHJh ciBkb2VzIHN0YW5kYXJkIHJlZ2lzdHJhdGlvbi4gSWYgaXQncyBhIG5ha2VkIGRvbWFpbiwgdGhl DQo+IHJlZ2lzdHJhciBkb2VzIHRoZSBuZXcgZG9tYWluIHJlZ2lzdHJhdGlvbi4gVGhpcyBsZXRz IHVzIGxhdGVyIHNheSAiQW5kIGlmDQo+IGl0J3MgYSB0ZTs6IFVSSSwgdGhlbiBkbyB0ZWxlcGhv bmUgcmVnaXN0cmF0aW9uIiwgd2hpY2ggY291bGQgYmUgYSBoYW5keQ0KPiBleHRlbnNpb24gZm9y IG1hbnkgcGVvcGxlLg0KPg0KPiBUaGlzIGlzIG11Y2ggYmV0dGVyIHRoYW4gdXNpbmcgYSBSZXF1 aXJlIG9wdGlvbiB0YWcgYXMgYSBjbHVlIHRvIGVuZ2FnZQ0KPiB0aGUgbmV3IGJlaGF2aW9yLiBU aGUgUmVxdWlyZSBpcyB0aGVyZSB0byBtYWtlIHJlZ2lzdHJhcnMgdGhhdCBkb24ndA0KPiB1bmRl cnN0YW5kIHRoZSBleHRlbnNpb24gZmFpbCB0aGUgcmVxdWVzdCBpbnN0ZWFkIG9mIGJlaGF2aW5n IGluIGENCj4gc3VycHJpc2luZyBtYW5uZXIgd2hlbiB0aGV5IHRyeSB0byBwcm9jZXNzIHRoZSBm YXV4LUFPUi4NCj4NCj4gLS0NCj4gRGVhbg0KPg0KPg0KPiANCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlz cGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlz cGF0Y2gNCg== From pkyzivat@cisco.com Thu Oct 22 06:16: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 856383A6A0C for ; Thu, 22 Oct 2009 06:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.622 X-Spam-Level: X-Spam-Status: No, score=-6.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 hmthH42OENcL for ; Thu, 22 Oct 2009 06:16:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 217B928B797 for ; Thu, 22 Oct 2009 06:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2285; q=dns/txt; s=rtpiport01001; t=1256217407; x=1257427007; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[dispatch]=20option=20tag=20in=20domain-registra tion=20(was=20RE:=20To-URI=0D=0A=20=20=20=20=20=20in=20do main-registration)|Date:=20Thu,=2022=20Oct=202009=2009:16 :34=20-0400|Message-ID:=20<4AE05B32.7010108@cisco.com> |To:=20Dean=20Willis=20|CC:=20 Bob=20Penfield=20,=0D=0A=20=20 =20=20=20=20=20=20"dispatch@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20Hadriel=20Kaplan=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<2e03ae c25441bdc898991e48e5bc2d16.squirrel@www.softarmor.com> |References:=20=20=20=20=20<429446390BA91242867940DBE798A06B73FC5 43578@mail>=20=20=20=20=20=20=20=20<429446390BA91242867940DBE79 8A06B73FC54357F@mail>=20=20=20=20<4ADF918E.4060406@cisco. com>=20<2e03aec25441bdc898991e48e5bc2d16.squirrel@www.sof tarmor.com>; bh=srq27URxDVakclFIzctcUNsrDa9sc9QpVDTS6x3poPA=; b=Nn5NCRLO715O2D02d7jimRhtMUcRbNIiCBN+AYPd5FwXs8bc3VmUTHIm 4RqhqWwVB4EAciZrp/1fJj2C/64nBuealANmgQjgl9THPR5Q0ueTvCzrV ZXJxT2A+D3TToYlrU++8lNXApJ5hoJ/rMOp+Rt7pwuaKyywsgzBwdTtf1 g=; 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: ApoEAO/330pAZnwN/2dsb2JhbADCWphjhD8E X-IronPort-AV: E=Sophos;i="4.44,605,1249257600"; d="scan'208";a="64344701" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 13:16:35 +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 n9MDGZva007581; Thu, 22 Oct 2009 13:16:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:16:35 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:16:34 -0400 Message-ID: <4AE05B32.7010108@cisco.com> Date: Thu, 22 Oct 2009 09:16:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> <4ADF918E.4060406@cisco.com> <2e03aec25441bdc898991e48e5bc2d16.squirrel@www.softarmor.com> In-Reply-To: <2e03aec25441bdc898991e48e5bc2d16.squirrel@www.softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 13:16:34.0852 (UTC) FILETIME=[E10D6640:01CA5319] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 22 Oct 2009 13:16:38 -0000 Dean Willis wrote: > On Wed, October 21, 2009 10:56 pm, Paul Kyzivat wrote: >> Bob Penfield wrote: >>> I understand that including the tag in a Require header does not mean >>> that the UAS will apply that extension. However, if the UAS does apply >>> the extension (if I understand the sentence below from section 8.2.4 >>> correctly) it is suppose to include the tag in a Require header in the >>> response. >>> >>> Any extensions applied to a non-421 response MUST be listed in a >>> Require header field included in the response. >>> >>> So wouldn't that mean that the UAC can know for sure that 'dreg" was >>> applied if the response has "Require: dreg"? >> I have always assumed that this means the response contains extensions >> that the UAC must understand in order to process the the response. E.g. >> extension headers in the response. I don't think it means what Bob is >> saying. > > While that makes more sense than what the text actually says, I think Bob > is reading it correctly. The quoted text says "Any extensions applied to a non-421 response". It doesn't say "applied to the request this response answers". > Unfortunately, many of our options-tag-defining > extensions don't seem return the option tag in the response correctly. > This includes stuff I edited, like RFC 5373 (answer-mode), > > Paul's idea that the response contains extensions that the UAC must > understand doesn't work, as the UAC has no way of rejecting a response > because it doesn't understand an extension. All it could do would be > discard-and-cancel, which is a bit awkward. Well, yes, that is all that could be done, but such is life. If there is a disagreement between the two parties about what is to be supported that may be all that is possible. Presumably the UAS doesn't apply something unless it believes the UAC will be able to support it, so this is the belt and suspenders approach. Note that this is the situation for a textbook case such as 100rel. The response that actually includes something that must be processed (the reliable response with its headers) includes the Require:100rel, while other responses that *don't* contain such features do *not* contain the Require:100rel. Thanks, Paul From BLINDSAY@nortel.com Fri Oct 23 06:38: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 D90D13A68B7 for ; Fri, 23 Oct 2009 06:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 i4YVIWh+NGiO for ; Fri, 23 Oct 2009 06:38:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F03E93A692E for ; Fri, 23 Oct 2009 06:38:14 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9NDcKl26163; Fri, 23 Oct 2009 13:38:20 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, 23 Oct 2009 09:38:15 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141B0F797E@zcarhxm1.corp.nortel.com> In-Reply-To: <190701c7e8016ab7e4b4c36dc684e9ce.squirrel@www.softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpSzdHkukZ7LG9gSBGXIE2Oid1imwBFy+gQ References: <618e24240910211303y259c5d65yc12d28eeb1654f8@mail.gmail.com> <190701c7e8016ab7e4b4c36dc684e9ce.squirrel@www.softarmor.com> From: "Brian Lindsay" To: "Dean Willis" , "Victor Pascual Avila" Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration 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, 23 Oct 2009 13:38:15 -0000 Hi, I think there is an aspect of backwards compatibility, with implicit registration models, by using option (1). For example, with the existing implicit reg model supported by PacketCable 2.0 (inherited from 3GPP/TISPAN), I believe one could setup implicit registration to effectively register the domain. Regards Brian -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, October 22, 2009 12:12 AM To: Victor Pascual Avila Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration On Wed, October 21, 2009 8:03 pm, Victor Pascual Avila wrote: > Hadriel, > > I'd prefer option (1) What's better about it? Is it just that it's easier to implement because that's what you have already, or is there some sort of semantic advantage? -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Fri Oct 23 06:55: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 573C83A67ED for ; Fri, 23 Oct 2009 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 AIl02ZJKueRh for ; Fri, 23 Oct 2009 06:55:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 37C123A67F1 for ; Fri, 23 Oct 2009 06:55:58 -0700 (PDT) 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; Fri, 23 Oct 2009 09:56:07 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Oct 2009 09:56:04 -0400 From: Hadriel Kaplan To: Brian Lindsay , Dean Willis , Victor Pascual Avila Date: Fri, 23 Oct 2009 09:55:31 -0400 Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpSzdHkukZ7LG9gSBGXIE2Oid1imwBFy+gQAABsb8A= Message-ID: References: <618e24240910211303y259c5d65yc12d28eeb1654f8@mail.gmail.com> <190701c7e8016ab7e4b4c36dc684e9ce.squirrel@www.softarmor.com> <09B7DBFE70A9E24BBB21689DAD3A06141B0F797E@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141B0F797E@zcarhxm1.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] To-URI in domain-registration 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, 23 Oct 2009 13:55:59 -0000 Along this thread, if we went with Option-1 to keep the To-URI looking like= an AoR, the draft could say in fact that it really does Register that AoR = in the normal Registrar AoR-Database, but that the Registrar would be provi= sioned to populate a Domain-Routing-Table based on the reachability info of= the AoR (contact/Path). But in my opinion the main advantage of Option-1 is really about reducing t= he implementation effort for IP-PBX's. That's not a small thing, though I = wonder how much effort it really is. It's important to note, too, that Domain Registration is different from "im= plicit-registration" in the sense that it's not just a short-cut from regis= tering all the phone numbers of the PBX separately. The PBX is given a dif= ferent domain, one for which it is authoritative for in the SIP sense. All= the language we have in RFC's around that applies, so that the PBX is resp= onsible for its own AoR's and such. It's really "peering" with the Service= Provider, as opposed to being a multiple subscriber UA's of the service pr= ovider. In that sense, I prefer Option-2, if for no other reason than it makes the = vendors understand that this is not just implicit-registration a la 3gpp/ti= span. (plus I think its semantically more accurate) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Brian Lindsay > Sent: Friday, October 23, 2009 9:38 AM >=20 > I think there is an aspect of backwards compatibility, with implicit > registration models, by using option (1). For example, with the existing > implicit reg model supported by PacketCable 2.0 (inherited from > 3GPP/TISPAN), I believe one could setup implicit registration to > effectively register the domain. >=20 > Regards > Brian >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Thursday, October 22, 2009 12:12 AM > To: Victor Pascual Avila > Cc: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration >=20 > On Wed, October 21, 2009 8:03 pm, Victor Pascual Avila wrote: > > Hadriel, > > > > I'd prefer option (1) >=20 > What's better about it? Is it just that it's easier to implement because > that's what you have already, or is there some sort of semantic > advantage? >=20 > -- > Dean >=20 >=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 HKaplan@acmepacket.com Fri Oct 23 06:57: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 B25963A6821 for ; Fri, 23 Oct 2009 06:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 xTXBx+xLgIIg for ; Fri, 23 Oct 2009 06:57:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BC6363A672E for ; Fri, 23 Oct 2009 06:57:35 -0700 (PDT) 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; Fri, 23 Oct 2009 09:57:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Oct 2009 09:57:45 -0400 From: Hadriel Kaplan To: Spencer Dawkins , Bob Penfield , "dispatch@ietf.org" Date: Fri, 23 Oct 2009 09:57:44 -0400 Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpSlXL0RPvLiiwNSR6g5GoLFZceJgBUyfIQ Message-ID: References: <429446390BA91242867940DBE798A06B73FC543578@mail> 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] To-URI in domain-registration 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, 23 Oct 2009 13:57:36 -0000 Right, I wasn't saying doing Option-2 of having only the domain in the To-U= RI would remove the need to do an option-tag. But I think it would remove = the need to have a new header or param.=20 -hadriel > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Wednesday, October 21, 2009 5:28 PM > To: Bob Penfield; Hadriel Kaplan; dispatch@ietf.org >=20 > On Bob's post - I'm also assuming that we'll keep the option tag, for > roughly the reasons Bob listed. >=20 > I believe Hadriel's question is intended to solve the question "how do I > know that domain registration actually happened (as opposed to knowing > that > the other UA supports domain registration", raised on this list a couple > of > days ago - the guidance we got was not to rely on Requires as an > indication > that the extension was actually used). >=20 > Hope this is helpful... >=20 > Spencer >=20 >=20 > >I think option 2 is better because it is "do what I say" rather than "do > >what I mean". I would keep the option tag since it's an extension and > >requires different behavior in the registrar. > > > > cheers, > > (-:bob > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Hadriel Kaplan > > Sent: Wednesday, October 21, 2009 3:43 PM > > To: dispatch@ietf.org > > Subject: [dispatch] To-URI in domain-registration > > > > Howdy, > > I'd like to get a consensus call on the question of what the To-URI > should > > be for the REGISTER request of a domain registration, before finishing > the > > next rev of the draft. This will affect quite a bit of text in the > draft > > (e.g., examples), and I think that the decision about that will also > > affect whether we need more than a Require:option-tag as well. > > > > The choices right now are: > > 1) Mandate the To-URI be in the syntactical form of an AoR, including > the > > user@ portion, the same as the From-URI. > > Pros: closer to what current proprietary and other-SDO mechanisms do, o= n > > the wire. Therefore, presumably less of a change and less barrier to > > adoption. > > 2) Mandate the To-URI be a domain only (no user@), while the From-URI > > remains the "AoR" of the PBX registering. > > Pros: semantically accurate (you're registering a domain, not an AoR), > and > > may obviate the need for a new header or param to indicate this new > > mechanism is being used. > > > > Can people please indicate which they'd prefer? > > > > Thanks! > > -hadriel > > _______________________________________________ > > 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 HKaplan@acmepacket.com Fri Oct 23 07:06: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 3F3673A67FC for ; Fri, 23 Oct 2009 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 eN9ICo-DzHf1 for ; Fri, 23 Oct 2009 07:06:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3B9E13A67E1 for ; Fri, 23 Oct 2009 07:06:30 -0700 (PDT) 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; Fri, 23 Oct 2009 10:06:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Oct 2009 10:06:37 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 23 Oct 2009 10:01:23 -0400 Thread-Topic: Using only a Require option-tag in Domain-Registration Thread-Index: AcpPO8j1qVxULuKBRuyNR0MyjwnEfADMnuTA Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <4AD62824.4030704@softarmor.com> <4AD89077.10906@softarmor.com> <1255760525.15650.4.camel@ubuntu.ubuntu-domain> <4AD9DE0B.90800@softarmor.com> In-Reply-To: <4AD9DE0B.90800@softarmor.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 Cc: "dispatch@ietf.org" , Dean Willis Subject: [dispatch] Using only a Require option-tag in Domain-Registration 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, 23 Oct 2009 14:06:31 -0000 BTW, with regards to being able to use an option-tag in a Require header to= mean more than just "I require you to support the following extension", bu= t to in fact mean "I require you to USE the following extension"... I have = been doing some digging, and it appears RFC 3262 is not the only one to do = that. RFC 3329 SIP Security Agreement does the following for the sec-agree tag: A server receiving an unprotected request that contains a Require or Proxy-Require header field with the value "sec-agree" MUST respond to the client with a 494 (Security Agreement Required) response. The server MUST add a Security-Server header field to this response listing the security mechanisms that the server supports. The server MUST add its list to the response even if there are no common security mechanisms in the client's and server's lists. The server's list MUST NOT depend on the contents of the client's list. And in Draft-sip-outbound-20 (the latest rev, soon to be RFC): If outbound registration succeeded, as indicated by the presence of the outbound option-tag in the Require header field of a successful registration response, the UA begins sending keep alives as described in Section 4.4. There is a counter-example: RFC 4488 has a norefersub option-tag but create= d a header just to say "do it" (that being: "Refer-Sub: false"). Although = one could argue that's not quite analogous to the case being done here, sin= ce it was useful in a Supported header. In the domain-registration case, i= t would actually be illogical to say "I require you to support me registeri= ng a domain in order to process this REGISTER request, but I'm not actually= registering a domain in this register request". -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, October 17, 2009 11:09 AM > To: Hadriel Kaplan > Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch- > domain-registration >=20 > Hadriel Kaplan wrote: > . For example, rfc3262 100rel > > has that meaning: > > > > The UAS MUST send any non-100 provisional response reliably if the > > initial request contained a Require header field with the option tag > > 100rel. If the UAS is unwilling to do so, it MUST reject the initial > > request with a 420 (Bad Extension) and include an Unsupported header > > field containing the option tag 100rel. > > > > Ergo, it does not just mean "you gotta support the reliable response > > concept to accept this request", but rather "you gotta USE reliable > > responses for this transaction to accept this request". >=20 > 3262 is badly, badly worded. Please don't use it as "the rule". >=20 > The intent is that if the UAS is aware that the UAC supports 100rel, and > the UAS supports 100rel, then the UAS will use 100rel. >=20 > This is probably worth filing an errata on 3262. If the UAS supports > 100rel, it should use it if the UAC indicated support for it in the > request. The support should have been indicated in Supported. The > difference is that if it is Require, then the UAS MUST reject the > request if it does not support the extension, whereas if it is only in > Supported, then the UAS may, if it does not support 100rel, respond > non-reliably. >=20 > -- > Dean From HKaplan@acmepacket.com Fri Oct 23 07:09: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 A4B6C3A6855 for ; Fri, 23 Oct 2009 07:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 MxGH1HthA4LA for ; Fri, 23 Oct 2009 07:09:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C9BB13A6842 for ; Fri, 23 Oct 2009 07:09:14 -0700 (PDT) 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; Fri, 23 Oct 2009 10:09:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Oct 2009 10:09:24 -0400 From: Hadriel Kaplan To: Dean Willis , Paul Kyzivat Date: Fri, 23 Oct 2009 10:09:14 -0400 Thread-Topic: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) Thread-Index: AcpSzUIsX1/3EOstTdu5QOb8iL1psQBHGLGg Message-ID: References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> <4ADF918E.4060406@cisco.com> <2e03aec25441bdc898991e48e5bc2d16.squirrel@www.softarmor.com> In-Reply-To: <2e03aec25441bdc898991e48e5bc2d16.squirrel@www.softarmor.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 Cc: Bob Penfield , "dispatch@ietf.org" Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 23 Oct 2009 14:09:15 -0000 Along this thread, if we decide that we need a new header as well as the op= tion-tag, because we chose Option-1 of using a AoR in the To-URI, then I wo= uld suggest we fix this problem once and for all. By that I mean submit ye= t another separate draft to create a new header called "Use-Extension" or s= ome such, which is a list of option-tags to be used on the request/response= it appears in, and an option-tag to go along with that draft to indicate s= upport for that header. =20 Not that I like the idea of another draft (or another header or option-tag = for that matter), but it seems silly to create a header like "Domain-Regist= ration: yes". -hadriel From dean.willis@softarmor.com Sat Oct 24 00:44: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 33FE33A68E6 for ; Sat, 24 Oct 2009 00:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 WhmwNso5JcV3 for ; Sat, 24 Oct 2009 00:44:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1D4EE3A68C1 for ; Sat, 24 Oct 2009 00:44:21 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9O7iQFW009213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Oct 2009 02:44:28 -0500 Message-ID: <4AE2B055.4060402@softarmor.com> Date: Sat, 24 Oct 2009 02:44:21 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Hadriel Kaplan References: <429446390BA91242867940DBE798A06B73FC543578@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bob Penfield , "dispatch@ietf.org" Subject: Re: [dispatch] To-URI in domain-registration 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, 24 Oct 2009 07:44:22 -0000 Hadriel Kaplan wrote: > Right, I wasn't saying doing Option-2 of having only the domain in > the To-URI would remove the need to do an option-tag. But I think it > would remove the need to have a new header or param. I agree. -- dean From dean.willis@softarmor.com Sat Oct 24 00:51: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 7CF833A6897 for ; Sat, 24 Oct 2009 00:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 6VkBKnTA3x7U for ; Sat, 24 Oct 2009 00:51:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A8BA83A67B6 for ; Sat, 24 Oct 2009 00:51:37 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9O7pJ7F009244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Oct 2009 02:51:21 -0500 Message-ID: <4AE2B1F2.9000803@softarmor.com> Date: Sat, 24 Oct 2009 02:51:14 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Hadriel Kaplan References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> <4ADF918E.4060406@cisco.com> <2e03aec25441bdc898991e48e5bc2d16.squirrel@www.softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bob Penfield , "dispatch@ietf.org" Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 24 Oct 2009 07:51:38 -0000 Hadriel Kaplan wrote: > Along this thread, if we decide that we need a new header as well as > the option-tag, because we chose Option-1 of using a AoR in the > To-URI, then I would suggest we fix this problem once and for all. > By that I mean submit yet another separate draft to create a new > header called "Use-Extension" or some such, which is a list of > option-tags to be used on the request/response it appears in, and an > option-tag to go along with that draft to indicate support for that > header. > > Not that I like the idea of another draft (or another header or > option-tag for that matter), but it seems silly to create a header > like "Domain-Registration: yes". This leads to the "named telco services" and the "service identification" argument that consumed the WG for a couple of years. See: http://tools.ietf.org/html/draft-ietf-sipping-service-identification-03 and http://tools.ietf.org/html/draft-drage-sipping-service-identification-03 -- Dean From L.Liess@telekom.de Sun Oct 25 10:06: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 A42F128C105 for ; Sun, 25 Oct 2009 10:06:54 -0700 (PDT) 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 c+zJnDZABD9Y for ; Sun, 25 Oct 2009 10:06:53 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id D3D6128C100 for ; Sun, 25 Oct 2009 10:06:52 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 25 Oct 2009 18:06:03 +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); Sun, 25 Oct 2009 18:06:03 +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: Sun, 25 Oct 2009 18:06:00 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0038BEE44@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477DF70@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [BLISS] [dispatch] New version for the Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt thread-index: AcpQ/PApDBRz4JVPTcOGvT+G9PL4BgAWJcygAGlYMIA= References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <7402509E63C5A145A6095D46C179A5B71477DF70@DEMCHP99E35MSX.ww902.siemens.net> From: To: , X-OriginalArrivalTime: 25 Oct 2009 17:06:03.0060 (UTC) FILETIME=[6EC87740:01CA5595] Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] [BLISS] New version for the Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-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: Sun, 25 Oct 2009 17:06:54 -0000 Hi John, Thank you very much for reading the draft and for the comments.=20 Please see answers inline: > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, October 20, 2009 9:41 AM > To: Paul Kyzivat; Liess, Laura > Cc: dispatch@ietf.org; Jesske, Roland; anwars@avaya.com > Subject: RE: [BLISS] [dispatch] New version for the=20 > Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt >=20 > (I have removed the BLISS cross-post, by the way). >=20 > I agree with the points Paul makes. In addition, I am=20 > concerned about some of the values: >=20 > 1. In 4.3.8, the value "short" is defined. This seems to have=20 > nothing to do with the meaning of a tone, but the way it is=20 > rendered. So in one locale, a short form of ring tone might=20 > denote low priority, say, whereas in another locale it might=20 > mean urgent, yet in a third locale it might mean some form of=20 > recall. Also, if my device renders tones visually, does=20 > displaying the alert icon or message only for a short period=20 > make sense? Finally, what does "short" mean to an automaton? I am not very familiar with PBXs, this is Alan's part, but my understanding is that the PBX tones URNs are inserted by the local PBX system (Proxy, Application server, maybe a UA directly connected to the PBX) and rendered by one UE of the same enterprise, so that, in generally, there is a common understanding about the meaning of "short". Maybe we could add a description about how itshould be used?=20 >=20 > 2. Given that Alert-Info is defined only for use in an INVITE=20 > request or a 180 response, how would values such as "busy",=20 > "intrusion" and "record" be used? This is true. I just did not think about it when I wrote this part. We should define only country ringing tones.=20 Thanks a lot Laura >=20 > John >=20 > =20 >=20 > > -----Original Message----- > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > On Behalf Of Paul Kyzivat > > Sent: 19 October 2009 21:44 > > To: L.Liess@telekom.de > > Cc: bliss@ietf.org; dispatch@ietf.org; R.Jesske@telekom.de;=20 > > anwars@avaya.com > > Subject: Re: [BLISS] [dispatch] New version for the=20 > > Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt > >=20 > > This seems to be shaping up well. I think the requirements=20 > are quite=20 > > clear now. > >=20 > > I don't fully understand what is intended regarding combination of=20 > > multiple alert URNs for a specific situation. Section 4.5 states: > >=20 > > > finally, a short Albanian auto-callback tone could be indicated > > > Alert-Info: , > > > , . > >=20 > > while section 7.3.6 states: > >=20 > > > Alert URN Indications from the same group should not=20 > be combined. > >=20 > > I could find no definition of what constitutes a "group". The first=20 > > thing that comes to mind is "service" vs. "tone", but the=20 > > above example=20 > > violates that. It seems to me that you need some notion of=20 > orthogonal=20 > > properties in order to define what can/cannot be combined. > >=20 > > It would be good to have more detail about how a recipient=20 > > should deal=20 > > with multiple URNs. > >=20 > > I'm also uncertain of what your intent is regarding top-level vs.=20 > > additional indications. As specified, I believe a given "additional=20 > > indication" name is always defined with regard to its=20 > parent, so that=20 > > "short" as used in "normal.short" might mean something entirely=20 > > different than "priority.short", or might not be defined for=20 > > priority at=20 > > all. > >=20 > > Yet from the registration text in 7.3.2 it sounds like the=20 > > intent is for=20 > > priority, short, and delayed to be defined for all pbx-tones.=20 > > If that is=20 > > the intent, then I don't think the existing text meets that intent. > >=20 > > I also wonder if the existing hierarchy will work well in=20 > > practice, or=20 > > if some other organization might not work better. For=20 > > instance, it might=20 > > be more convenient to specify ringing.fr with the clear=20 > understanding=20 > > that if you don't know about ringing.fr you can just treat it=20 > > as ringing. > >=20 > > I'm also confused by PBX tones vs. Public telephone tones. In=20 > > what way=20 > > is "normal" different from "ringing"? I would think that PBX=20 > > tones would=20 > > be a superset of common pstn tones. > >=20 > > A nit: in 4.3.2 I would expext the forward to be indicated,=20 > > if at all,=20 > > with a 181 rather than a 180. > >=20 > > Thanks, > > Paul > >=20 > > L.Liess@telekom.de wrote: > > > =20 > > > Hi, > > >=20 > > > We've re-submitted the Alert-Info URNs draft for DISPATCH > > >=20 > > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > > -info-urns > > > -00.txt . (The previous version od the draft was in BLISS=20 > > and we had a > > > presentation in BLISS at the last IETF.) > > >=20 > > > We did some major changes, as suggested on the mailing list, e.g.: > > > Added: =20 > > > - Description of the interoperability problems for=20 > > PBX-services (in > > > the Introduction chapter)=20 > > > - Requirements for the Alert-Info URNs mechanism=20 > > > - Alert-Info URNs Indications for country-specific tones > > > Changed:=20 > > > - Initial IANA Registration mechanism to avoid=20 > > combinatorial explosion > > > of IANA values.=20 > > >=20 > > >=20 > > > Many thanks for the comments and suggestions, > > > Laura=20 > > >=20 > > >=20 > > >=20 > > > =20 > > >=20 > > > -----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, October 19, 2009 1:00 PM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt=20 > > >=20 > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > >=20 > > > Title : Alert-Info URNs for the Session Initiation > > > Protocol (SIP) > > > Author(s) : D. Alexeitsev, et al. > > > Filename : draft-liess-dispatch-alert-info-urns-00.txt > > > Pages : 25 > > > Date : 2009-10-19 > > >=20 > > > The Session Initiation Protocol (SIP) supports the capability to > > > provide a reference to the alternative ringback tone (RBT) for > > > caller, or ring tone (RT) for callee using the Alert-Info header. > > > However, the reference addresses only the network resources with > > > specific rendering properties. There is currently no support for > > > predefined standard identifiers for ringback tones or semantic > > > indications without tied rendering. To overcome this=20 > > limitations and > > > support new applications a family of the URNs is defined in this > > > specification. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > > -info-urns > > > -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. > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > >=20 >=20 From john.elwell@siemens-enterprise.com Mon Oct 26 00:40: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 03EA828C172 for ; Mon, 26 Oct 2009 00:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_DE=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 CRRhiik92hMn for ; Mon, 26 Oct 2009 00:40:46 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 10EA33A682C for ; Mon, 26 Oct 2009 00:40:45 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9Q7er3F028325; Mon, 26 Oct 2009 08:40:54 +0100 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9Q7er5I029787; Mon, 26 Oct 2009 08:40:53 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Mon, 26 Oct 2009 08:40:52 +0100 From: "Elwell, John" To: "L.Liess@telekom.de" , "pkyzivat@cisco.com" Date: Mon, 26 Oct 2009 08:40:50 +0100 Thread-Topic: [BLISS] [dispatch] New version for the Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: AcpQ/PApDBRz4JVPTcOGvT+G9PL4BgAWJcygAGlYMIAAxQgz0A== Message-ID: <7402509E63C5A145A6095D46C179A5B7148B3259@DEMCHP99E35MSX.ww902.siemens.net> References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <7402509E63C5A145A6095D46C179A5B71477DF70@DEMCHP99E35MSX.ww902.siemens.net> <40FB0FFB97588246A1BEFB05759DC8A0038BEE44@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0038BEE44@S4DE9JSAANI.ost.t-com.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "anwars@avaya.com" , "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] [BLISS] New version for the Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-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: Mon, 26 Oct 2009 07:40:49 -0000 =20 > -----Original Message----- > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: 25 October 2009 17:06 > To: Elwell, John; pkyzivat@cisco.com > Cc: dispatch@ietf.org; R.Jesske@telekom.de; anwars@avaya.com;=20 > alan@sipstation.com > Subject: RE: [BLISS] [dispatch] New version for the=20 > Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt >=20 >=20 > Hi John, >=20 > Thank you very much for reading the draft and for the comments.=20 >=20 > Please see answers inline: >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >=20 > > Sent: Tuesday, October 20, 2009 9:41 AM > > To: Paul Kyzivat; Liess, Laura > > Cc: dispatch@ietf.org; Jesske, Roland; anwars@avaya.com > > Subject: RE: [BLISS] [dispatch] New version for the=20 > > Alert-Info URNs > draft:draft-liess-dispatch-alert-info-urns-00.txt > >=20 > > (I have removed the BLISS cross-post, by the way). > >=20 > > I agree with the points Paul makes. In addition, I am=20 > > concerned about some of the values: > >=20 > > 1. In 4.3.8, the value "short" is defined. This seems to have=20 > > nothing to do with the meaning of a tone, but the way it is=20 > > rendered. So in one locale, a short form of ring tone might=20 > > denote low priority, say, whereas in another locale it might=20 > > mean urgent, yet in a third locale it might mean some form of=20 > > recall. Also, if my device renders tones visually, does=20 > > displaying the alert icon or message only for a short period=20 > > make sense? Finally, what does "short" mean to an automaton? >=20 > I am not very familiar with PBXs, this is Alan's part, but my > understanding is that the PBX tones URNs are inserted by the local PBX > system (Proxy, Application server, maybe a UA directly=20 > connected to the > PBX) and rendered by one UE of the same enterprise, so that, in > generally, there is a common understanding about the meaning=20 > of "short". > Maybe we could add a description about how itshould be used?=20 [JRE] I agree it could be used in this way, but I thought the whole point o= f the draft was to define semantic names for ring tones, not names that sug= gest a particular means of rendering. John >=20 >=20 > >=20 > > 2. Given that Alert-Info is defined only for use in an INVITE=20 > > request or a 180 response, how would values such as "busy",=20 > > "intrusion" and "record" be used? >=20 > This is true. I just did not think about it when I wrote this part. We > should define only country ringing tones.=20 >=20 > Thanks a lot > Laura >=20 >=20 > >=20 > > John > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > > On Behalf Of Paul Kyzivat > > > Sent: 19 October 2009 21:44 > > > To: L.Liess@telekom.de > > > Cc: bliss@ietf.org; dispatch@ietf.org; R.Jesske@telekom.de;=20 > > > anwars@avaya.com > > > Subject: Re: [BLISS] [dispatch] New version for the=20 > > > Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt > > >=20 > > > This seems to be shaping up well. I think the requirements=20 > > are quite=20 > > > clear now. > > >=20 > > > I don't fully understand what is intended regarding=20 > combination of=20 > > > multiple alert URNs for a specific situation. Section 4.5 states: > > >=20 > > > > finally, a short Albanian auto-callback tone could=20 > be indicated > > > > Alert-Info: , > > > > , . > > >=20 > > > while section 7.3.6 states: > > >=20 > > > > Alert URN Indications from the same group should not=20 > > be combined. > > >=20 > > > I could find no definition of what constitutes a "group".=20 > The first=20 > > > thing that comes to mind is "service" vs. "tone", but the=20 > > > above example=20 > > > violates that. It seems to me that you need some notion of=20 > > orthogonal=20 > > > properties in order to define what can/cannot be combined. > > >=20 > > > It would be good to have more detail about how a recipient=20 > > > should deal=20 > > > with multiple URNs. > > >=20 > > > I'm also uncertain of what your intent is regarding top-level vs.=20 > > > additional indications. As specified, I believe a given=20 > "additional=20 > > > indication" name is always defined with regard to its=20 > > parent, so that=20 > > > "short" as used in "normal.short" might mean something entirely=20 > > > different than "priority.short", or might not be defined for=20 > > > priority at=20 > > > all. > > >=20 > > > Yet from the registration text in 7.3.2 it sounds like the=20 > > > intent is for=20 > > > priority, short, and delayed to be defined for all pbx-tones.=20 > > > If that is=20 > > > the intent, then I don't think the existing text meets=20 > that intent. > > >=20 > > > I also wonder if the existing hierarchy will work well in=20 > > > practice, or=20 > > > if some other organization might not work better. For=20 > > > instance, it might=20 > > > be more convenient to specify ringing.fr with the clear=20 > > understanding=20 > > > that if you don't know about ringing.fr you can just treat it=20 > > > as ringing. > > >=20 > > > I'm also confused by PBX tones vs. Public telephone tones. In=20 > > > what way=20 > > > is "normal" different from "ringing"? I would think that PBX=20 > > > tones would=20 > > > be a superset of common pstn tones. > > >=20 > > > A nit: in 4.3.2 I would expext the forward to be indicated,=20 > > > if at all,=20 > > > with a 181 rather than a 180. > > >=20 > > > Thanks, > > > Paul > > >=20 > > > L.Liess@telekom.de wrote: > > > > =20 > > > > Hi, > > > >=20 > > > > We've re-submitted the Alert-Info URNs draft for DISPATCH > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > > > -info-urns > > > > -00.txt . (The previous version od the draft was in BLISS=20 > > > and we had a > > > > presentation in BLISS at the last IETF.) > > > >=20 > > > > We did some major changes, as suggested on the mailing=20 > list, e.g.: > > > > Added: =20 > > > > - Description of the interoperability problems for=20 > > > PBX-services (in > > > > the Introduction chapter)=20 > > > > - Requirements for the Alert-Info URNs mechanism=20 > > > > - Alert-Info URNs Indications for country-specific tones > > > > Changed:=20 > > > > - Initial IANA Registration mechanism to avoid=20 > > > combinatorial explosion > > > > of IANA values.=20 > > > >=20 > > > >=20 > > > > Many thanks for the comments and suggestions, > > > > Laura=20 > > > >=20 > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > > -----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, October 19, 2009 1:00 PM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt=20 > > > >=20 > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts > > > > directories. > > > >=20 > > > > Title : Alert-Info URNs for the=20 > Session Initiation > > > > Protocol (SIP) > > > > Author(s) : D. Alexeitsev, et al. > > > > Filename :=20 > draft-liess-dispatch-alert-info-urns-00.txt > > > > Pages : 25 > > > > Date : 2009-10-19 > > > >=20 > > > > The Session Initiation Protocol (SIP) supports the capability to > > > > provide a reference to the alternative ringback tone (RBT) for > > > > caller, or ring tone (RT) for callee using the=20 > Alert-Info header. > > > > However, the reference addresses only the network resources with > > > > specific rendering properties. There is currently no=20 > support for > > > > predefined standard identifiers for ringback tones or semantic > > > > indications without tied rendering. To overcome this=20 > > > limitations and > > > > support new applications a family of the URNs is defined in this > > > > specification. > > > >=20 > > > > A URL for this Internet-Draft is: > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > > > -info-urns > > > > -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=20 > version of the > > > > Internet-Draft. > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 > = From dworley@nortel.com Mon Oct 26 11:18: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 3C17F28C12B for ; Mon, 26 Oct 2009 11:18:08 -0700 (PDT) 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 gwtJfGEIYord for ; Mon, 26 Oct 2009 11:18:07 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 04EC828C0FB for ; Mon, 26 Oct 2009 11:18:03 -0700 (PDT) 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 n9QIICD18738 for ; Mon, 26 Oct 2009 18:18:12 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:18:11 -0400 From: "Dale Worley" To: DISPATCH In-Reply-To: <20091026005148.196193A68EF@core3.amsl.com> References: <20091026005148.196193A68EF@core3.amsl.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 26 Oct 2009 14:18:11 -0400 Message-Id: <1256581091.3748.9.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: 26 Oct 2009 18:18:11.0937 (UTC) FILETIME=[AD686D10:01CA5668] 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: Mon, 26 Oct 2009 18:18:08 -0000 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 > successfuly submitted by Dale Worley and posted to the IETF > repository. > > 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 > > Abstract: > The "music on hold" feature is one of the most desired features of > telephone systems in the business environment. "Music on hold" is > where, when one party to a call has the call "on hold", that party's > telephone provides an audio stream (often music) to be heard by the > other party. Architectural features of SIP make it difficult to > implement music-on-hold in a way that is fully compliant with the > standards. The implementation of music-on-hold described in this > document is fully effective and standards-compliant, but has a number > of advantages over the methods previously documented. In particular, > it is less likely to produce peculiar user interface effects and more > likely to work in systems which perform authentication than the > method of RFC 5359. http://tools.ietf.org/html/draft-worley-service-example-04 From MILANPA@nortel.com Mon Oct 26 11:23: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 E38FD3A6ADC for ; Mon, 26 Oct 2009 11:23:43 -0700 (PDT) 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 EmdtnoeEurSG for ; Mon, 26 Oct 2009 11:23:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DD0DB3A6AC5 for ; Mon, 26 Oct 2009 11:23:42 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9QINpP21903 for ; Mon, 26 Oct 2009 18:23:52 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: Mon, 26 Oct 2009 18:23:50 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900B1CA540@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-01 Thread-Index: AcpWaMywSYKwfhDbRdmG2DPhC2vXXgAAD04Q From: "Milan Patel" To: "DISPATCH" Subject: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-01 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, 26 Oct 2009 18:23:44 -0000 Folks, I have submitted a new version of draft-patel-dispatch-cpc-oli-parameter with the following changes: - Clarified that the URI parameters are applicable to both tel and SIP URI schemes - changes the "oli" parameter name to "isup-oli" - included the text values for the "isup-oli" parameter - included the binary values for the "isup-oli" and "cpc" parameters Best regards, Milan -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 26 October 2009 18:18 To: Patel, Milan (MOP:EP10) Cc: r.jesske@telekom.de; mdolly@att.com Subject: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-01=20 A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-01.txt has been successfuly submitted by Milan Patel and posted to the IETF repository. Filename: draft-patel-dispatch-cpc-oli-parameter Revision: 01 Title: Uniform Resource Identifier (URI) Parameters for indicating the Calling Party's Catagory and Originating Line Identity Creation_date: 2009-10-26 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document defines two new URI parameters to describe the calling party's category and toll class of service originating line information which are parameters also used in SS7 ISUP and other telephony signalling protocols. The intended use of these URI parameters is for the tel URI and SIP URI address schemes. =20 The IETF Secretariat. From dworley@nortel.com Mon Oct 26 12:43: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 8877428C174 for ; Mon, 26 Oct 2009 12:43:08 -0700 (PDT) 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 dTCot2xH5j9j for ; Mon, 26 Oct 2009 12:43:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4E09828C146 for ; Mon, 26 Oct 2009 12:43:06 -0700 (PDT) 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 n9QJhDD11609; Mon, 26 Oct 2009 19:43:13 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:43:11 -0400 From: "Dale Worley" To: Bob Penfield In-Reply-To: <429446390BA91242867940DBE798A06B73FC54357F@mail> References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 26 Oct 2009 15:43:11 -0400 Message-Id: <1256586191.3748.25.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: 26 Oct 2009 19:43:11.0546 (UTC) FILETIME=[8D0301A0:01CA5674] Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 26 Oct 2009 19:43:09 -0000 On Wed, 2009-10-21 at 18:13 -0400, Bob Penfield wrote: > I understand that including the tag in a Require header does not mean > that the UAS will apply that extension. However, if the UAS does apply > the extension (if I understand the sentence below from section 8.2.4 > correctly) it is suppose to include the tag in a Require header in the > response. If the request has a tag in a Require header, than if the UAS does not understand the extension, the UAS will reject the request with a 421. There is no generic requirement that the request will trigger the mechanisms of the extension -- the presence of "Require" is orthogonal to the question of whether the extension causes something interesting to happen to the request. In particular, if "Require" is missing, the UAS will not process the request differently. (However, if an option-tag is present with "Supported", the definition of the extension may cause the request to be processed differently than it otherwise would be.) Dale From jhaluska@telcordia.com Mon Oct 26 13:08: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 C532328C35E for ; Mon, 26 Oct 2009 13:08:15 -0700 (PDT) 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 2B9EbCMZ2T4b for ; Mon, 26 Oct 2009 13:08:08 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by core3.amsl.com (Postfix) with ESMTP id 7912628C377 for ; Mon, 26 Oct 2009 13:08:07 -0700 (PDT) Received: from rrc-dte-ieg01.dte.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n9QK8Kdg000859 for ; Mon, 26 Oct 2009 16:08:20 -0400 (EDT) X-AuditID: 80601416-0000111400000554-3b-4ae601b02939 Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by rrc-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:08:16 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Mon, 26 Oct 2009 16:08:17 -0400 From: "Haluska, John J" To: "dispatch@ietf.org" Date: Mon, 26 Oct 2009 16:08:15 -0400 Thread-Topic: Requesting DISPATCH advice on draft-haluska-sipping-directory-assistance-09 Thread-Index: AcpWeA2WBVek9ZpOQ0qn5vfnJxC+pA== Message-ID: <8B6A9EC265011E4CB70F99C64426E8C205388882DD@rrc-dte-exmb2.dte.telcordia.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_8B6A9EC265011E4CB70F99C64426E8C205388882DDrrcdteexmb2dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Haluska, John J" , "gonzalo.camarillo@ericsson.com" Subject: [dispatch] Requesting DISPATCH advice on draft-haluska-sipping-directory-assistance-09 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, 26 Oct 2009 20:08:15 -0000 --_000_8B6A9EC265011E4CB70F99C64426E8C205388882DDrrcdteexmb2dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, We've been discussing with Cullen an AD-sponsored path for draft-haluska-si= pping-directory-assistance. Having received an extensive review from Spenc= er Dawkins (thanks Spencer), one comment was that we should consider breaki= ng up the 100+ page document into several more manageable documents, potent= ially organized into e.g., - a description of the services - a description of standards gaps - a set of call flows - a set of best current practices Cullen suggested that we talk to the DISPATCH working group to see what kin= d of split makes sense, he was thinking that possibly some material (e.g., = protocol gaps) might have the potential to become the basis of future work = in DISPATCH or other working groups. We'd definitely appreciate any advice on this from the DISPATCH working gro= up. A pointer to the announcement for the latest revision (-09) of the docu= ment is provided below. Again the input we're looking for is advice on splitting up the document. Thanks much, John Haluska =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: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D Action:draft-haluska-sipping-directory-assistance-09.txt X-RSN: 1/0/935/27107/30454 X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D30454 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Considerations for Information Services and Operator Services Using= SIP Author(s) : J. Haluska, et al. Filename : draft-haluska-sipping-directory-assistance-09.txt Pages : 109 Date : 2009-10-23 Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assista= nce-09.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ***** Click below to download the attachment(s) in this message: Attachment: draft_haluska_sipping_directory_assistance_09.txt (1K) --_000_8B6A9EC265011E4CB70F99C64426E8C205388882DDrrcdteexmb2dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

We’ve been discussing with Cullen an AD-sponsore= d path for draft-haluska-sipping-directory-assistance.  Having received an extensive review from Spencer Dawkins (thanks Spencer), one comment was tha= t we should consider breaking up the 100+ page document into several more manage= able documents, potentially organized into e.g.,

 

         =        - a description of the services

         =        - a description of standards gaps

         =        - a set of call flows

         =        - a set of best current practices

         =       

Cullen suggested that we talk to the DISPATCH working = group to see what kind of split makes sense, he was thinking that possibly some m= aterial (e.g., protocol gaps) might have the potential to become the basis of futur= e work in DISPATCH or other working groups.

 

We’d definitely appreciate any advice on this fr= om the DISPATCH working group. A pointer to the announcement for the latest revisi= on (-09) of the document is provided below.

 

Again the input we’re looking for is advice on s= plitting up the document.

 

 

Thanks much,

 

John Haluska

 

 

 

 

 

 =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: Internet-Drafts@ietf.org 
To: i-d-announce@ietf.org 
Reply-to: Internet-Drafts@ietf.org 
Subject: I-D Action:draft-haluska-sipping-directory-assistance-09.txt  = ;
X-RSN: 1/0/935/27107/30454 
X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D304= 54 
 
A New Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : Considerations for Information Services and Operator Services Using SIP 
Author(s) : J. Haluska, et al. 
Filename : draft-haluska-sipping-directory-assistance-09.txt 
Pages : 109 
Date : 2009-10-23 
 
Information Services are services whereby information is provided in <= br> response to user requests, and may include involvement of a human or <= br> automated agent. A popular existing Information Service is Directory <= br> Assistance (DA). Moving ahead, Information Services providers 
envision exciting multimedia services that support simultaneous 
voice and data interactions with full operator backup at any time 
during the call. Information Services providers are planning to 
migrate to SIP based platforms, which will enable such advanced 
services, while continuing to support traditional DA services. 
 
Operator Services are traditional PSTN services which often involve  providing human or automated assistance to a caller, and often 
require the specialized capabilities traditionally provided by an 
operator services switch. Market and/or regulatory factors in some  jurisdictions dictate that some subset of Operator Services continue <= br> to be provided going forward. 
 
This document aims to identify how Operator and Information Services <= br> can be implemented using existing or currently proposed SIP 
mechanisms, to identity existing protocol gaps, and to provide a set <= br> of Best Current Practices to facilitate interoperability. For 
Operator Services, the intention is to describe how current operator <= br> services can continue to be provided to PSTN based subscribers via a <= br> SIP based operator services architecture. It also looks at how 
current operator services might be provided to SIP based subscribers <= br> via such an architecture, but does not consider the larger question  of the need for or usefulness or suitability of each of these 
services for SIP based subscribers. 
 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assista= nce-09.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. 
_______________________________________________ 
I-D-Announce mailing list 
I-D-Announce@ietf.org 
https://www.ietf.org/mailman/listinfo/i-d-announce 
Internet-Draft directories: http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
 
***** 
Click below to download the attachment(s) in this message: 
Attachment: draft_haluska_sipping_directory_assistance_09.txt (1K) =

--_000_8B6A9EC265011E4CB70F99C64426E8C205388882DDrrcdteexmb2dt_-- From pkyzivat@cisco.com Mon Oct 26 13:25: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 B7B453A6B21 for ; Mon, 26 Oct 2009 13:25:49 -0700 (PDT) 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 yqzM5u-uJm5a for ; Mon, 26 Oct 2009 13:25:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5DFFC3A6B11 for ; Mon, 26 Oct 2009 13:25:48 -0700 (PDT) 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: ApoEAC+j5UpAZnwN/2dsb2JhbADCApc7gjkBBoF/BItZ X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="65004919" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2009 20:26:01 +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 n9QKQ1jU008851; Mon, 26 Oct 2009 20:26:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:26:01 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:26:00 -0400 Message-ID: <4AE605D6.1010402@cisco.com> Date: Mon, 26 Oct 2009 16:25:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Haluska, John J" References: <8B6A9EC265011E4CB70F99C64426E8C205388882DD@rrc-dte-exmb2.dte.telcordia.com> In-Reply-To: <8B6A9EC265011E4CB70F99C64426E8C205388882DD@rrc-dte-exmb2.dte.telcordia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Oct 2009 20:26:00.0391 (UTC) FILETIME=[8829A570:01CA567A] Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: Re: [dispatch] Requesting DISPATCH advice on draft-haluska-sipping-directory-assistance-09 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, 26 Oct 2009 20:25:49 -0000 Haluska, John J wrote: > Hello All, > > > > We’ve been discussing with Cullen an AD-sponsored path for > draft-haluska-sipping-directory-assistance. Having received an > extensive review from Spencer Dawkins (thanks Spencer), one comment was > that we should consider breaking up the 100+ page document into several > more manageable documents, potentially organized into e.g., > > > > - a description of the services > > - a description of standards gaps > > - a set of call flows > > - a set of best current practices That kind of a split sounds sensible to me. It also strikes me that this is starting to sound like a Bliss kind of thing. Thanks, Paul > Cullen suggested that we talk to the DISPATCH working group to see what > kind of split makes sense, he was thinking that possibly some material > (e.g., protocol gaps) might have the potential to become the basis of > future work in DISPATCH or other working groups. > > > > We’d definitely appreciate any advice on this from the DISPATCH working > group. A pointer to the announcement for the latest revision (-09) of > the document is provided below. > > > > Again the input we’re looking for is advice on splitting up the document. > > > > > > Thanks much, > > > > John Haluska > > > > > > > > > > > > = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = > = = = = = = > > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D Action:draft-haluska-sipping-directory-assistance-09.txt > X-RSN: 1/0/935/27107/30454 > X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=30454 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Considerations for Information Services and Operator Services > Using SIP > Author(s) : J. Haluska, et al. > Filename : draft-haluska-sipping-directory-assistance-09.txt > Pages : 109 > Date : 2009-10-23 > > Information Services are services whereby information is provided in > response to user requests, and may include involvement of a human or > automated agent. A popular existing Information Service is Directory > Assistance (DA). Moving ahead, Information Services providers > envision exciting multimedia services that support simultaneous > voice and data interactions with full operator backup at any time > during the call. Information Services providers are planning to > migrate to SIP based platforms, which will enable such advanced > services, while continuing to support traditional DA services. > > Operator Services are traditional PSTN services which often involve > providing human or automated assistance to a caller, and often > require the specialized capabilities traditionally provided by an > operator services switch. Market and/or regulatory factors in some > jurisdictions dictate that some subset of Operator Services continue > to be provided going forward. > > This document aims to identify how Operator and Information Services > can be implemented using existing or currently proposed SIP > mechanisms, to identity existing protocol gaps, and to provide a set > of Best Current Practices to facilitate interoperability. For > Operator Services, the intention is to describe how current operator > services can continue to be provided to PSTN based subscribers via a > SIP based operator services architecture. It also looks at how > current operator services might be provided to SIP based subscribers > via such an architecture, but does not consider the larger question > of the need for or usefulness or suitability of each of these > services for SIP based subscribers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assistance-09.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. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ***** > Click below to download the attachment(s) in this message: > Attachment: draft_haluska_sipping_directory_assistance_09.txt > > (1K) > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@nortel.com Mon Oct 26 13:31: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 678973A6AD9 for ; Mon, 26 Oct 2009 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 V4S2HC++qIzv for ; Mon, 26 Oct 2009 13:31:50 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 252393A67E1 for ; Mon, 26 Oct 2009 13:31:50 -0700 (PDT) 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 n9QKVxD24678 for ; Mon, 26 Oct 2009 20:31:59 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:31:57 -0400 From: "Dale Worley" To: DISPATCH In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 26 Oct 2009 16:31:56 -0400 Message-Id: <1256589116.3748.73.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: 26 Oct 2009 20:31:57.0027 (UTC) FILETIME=[5CBBFB30:01CA567B] Subject: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 26 Oct 2009 20:31:51 -0000 I think the proposal can be improved and controversy avoided by making three rather small changes: 1. Restrict (at least in principle) the domain name involved to be one that is properly owned or controlled by the SSP or PBX. 2. Replace the REGISTER method with a new method name. 3. Clarify that the RFC defines a mechanism for maintaining a "route to this domain" database, which may be used in various ways which are not specified by the RFC. (In particular, the SSP might use it to apply Route headers to requests, or it might use it to populate a DNS server, and then use RFC 3263 to route requests.) This loses no functionality and ensures that the database-updating remains uncoupled from the users of the database. Justifications for items 1 and 2: 1. Allowing arbitrary domain names leads to the alt-root controversy, etc. In addition, if the domain name is used only between the SSP and the PBX, and within the PBX's services, it is essentially arbitrary, in which case it might as well be a properly owned domain name. If the domain name is visible outside this region, it will have to be properly owned if we expect external elements to utilize it in accessing the PBX. In neither case is a private name space particularly useful. Of course, in practice, people will do whatever they want, but we avoid committing to support private name spaces in the future. 2. This change has more complex consequences, but I think the balance of facts is in its favor: a. It reduces the compatibility problems relative to the ad-hoc mechanisms currently deployed, since the new method makes it clear that the new, standardized mechanism is to be used. Conversely, elements wishing to remain compatible with a current ad-hoc use of REGISTER for this purpose can continue to do so. b. It avoids having to define an option-tag, as the *effect* of using a new method is the same as using an old method with a new option-tag: UASs that are unaware of the new mechanism will reject the request. (Thus demonstrating that the opinion that a new method is more radical than a new option-tag has no substance.) c. Specific mechanisms that are now defined for use with REGISTER can be recycled for use with the new method by simply referencing them in the RFC. And mechanisms that are now defined for use with REGISTER that are of no value with domain-registration (e.g., GRUU) are explicitly omitted. d. Using a new method avoids the dangerously ill-structured process of using one method for requesting multiple activities that are almost-but-not-quite the same. Let us compare the situation with that of REFER. At last count, there were five distinct uses of the REFER method. Each is distinguished by specific combinations of header fields and features of the context within which the REFER is received. This leads to several undesirable consequences: - The code at the UAS is no simpler, as there need to be five different code paths, one for each version of REFER. Currently, the dispatching is done by examining the context of the REFER, whereas if there were five methods, dispatching could be done by method name. - Because the rules for distinguishing the five cases are not explicit, implementers may easily make mistakes coding the dispatching. - Because the function of a REFER is determined by context, a REFER that is accidentally sent in a different context than which was intended may not be detected as an error and may cause inadvertent actions. - If there were separate method names, then each of the five code paths could continue to examine the context of the request, but as a validity check rather than as a dispatching decision. - Different uses of REFER have subtly different constraints on valid values for the various header fields. In the case of domain-registration REGISTERs, we are already discussing what the To-URI should be, which shows that the domain-registration REGISTER isn't really the same beast as the AOR REGISTER. And some extensions of REFER (e.g., GRUU) aren't to be used with domain-registration. We can expect further subtle differences to be discovered. e. The new method is freed from having to resemble REGISTER in aspects that are unnatural for the function of the new method. f. The claim that the new method is exactly like the old REGISTER except for the database that is populated is true in a psychological sense, but not in a coding sense -- Various details are different (the To/From headers do not have exactly the same format or interpretation, multiple Contacts are forbidden, and it's unlikely that the query formats are supported). And I doubt that there will be *any* implementation that will process the two functions with the *same* code, only with a differing parameter-value indicating the database to be updated. g. Using a new method puts the new mechanism beyond a large set of "ideological" arguments. (But most of the ideological arguments are abstract versions of the above practical considerations.) (This new method may actually *be* the RUPDATE proposed by Dean, but I haven't read into that, so I don't know.) Dale From dworley@nortel.com Mon Oct 26 13:34: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 4DF8C28C375 for ; Mon, 26 Oct 2009 13:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Hs+1xGJ7BY3y for ; Mon, 26 Oct 2009 13:34:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5B69328C35E for ; Mon, 26 Oct 2009 13:34:13 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9QKYMP15621; Mon, 26 Oct 2009 20:34:22 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:34:20 -0400 From: "Dale Worley" To: Bob Penfield In-Reply-To: <1256586191.3748.25.camel@khone.us.nortel.com> References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> <1256586191.3748.25.camel@khone.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 26 Oct 2009 16:34:20 -0400 Message-Id: <1256589260.3748.75.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: 26 Oct 2009 20:34:20.0750 (UTC) FILETIME=[B2665EE0:01CA567B] Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 26 Oct 2009 20:34:14 -0000 On Mon, 2009-10-26 at 15:43 -0400, Dale Worley wrote: > On Wed, 2009-10-21 at 18:13 -0400, Bob Penfield wrote: > > I understand that including the tag in a Require header does not mean > > that the UAS will apply that extension. However, if the UAS does apply > > the extension (if I understand the sentence below from section 8.2.4 > > correctly) it is suppose to include the tag in a Require header in the > > response. > > If the request has a tag in a Require header, than if the UAS does not > understand the extension, the UAS will reject the request with a 421. > There is no generic requirement that the request will trigger the > mechanisms of the extension -- the presence of "Require" is orthogonal > to the question of whether the extension causes something interesting to > happen to the request. In particular, if "Require" is missing, the UAS > will not process the request differently. > > (However, if an option-tag is present with "Supported", the definition > of the extension may cause the request to be processed differently than > it otherwise would be.) Yuck -- what I wrote is what was intended by RFC 3261, but which is violated by a few extensions, as Hadriel points out. Dale From dworley@nortel.com Mon Oct 26 13:35: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 394B63A680F for ; Mon, 26 Oct 2009 13:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 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 nhxyC5xixytl for ; Mon, 26 Oct 2009 13:35:33 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 564EB3A67CC for ; Mon, 26 Oct 2009 13:35:33 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9QKZfP16020; Mon, 26 Oct 2009 20:35:42 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:35:40 -0400 From: "Dale Worley" To: Spencer Dawkins In-Reply-To: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1255986053.3767.46.camel@khone.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 26 Oct 2009 16:35:40 -0400 Message-Id: <1256589340.3748.77.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: 26 Oct 2009 20:35:40.0783 (UTC) FILETIME=[E21A6FF0:01CA567B] Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain RegistrationDraft draft-kaplan-dispatch-domain-registration 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, 26 Oct 2009 20:35:34 -0000 On Mon, 2009-10-19 at 16:33 -0500, Spencer Dawkins wrote: > Without speaking for the draft author, I think "domain" is open for > suggestions. The SIPconnect working group has gone through "registration" > with no qualifier, "implicit registration", and I think "bulk registration" > was also tossed in but sank without a ripple, so we're obviously not wedded > to "domain". > > "registration" is harder for me to think of alternatives for, because we > think we're achieving roughly the same end-game as per-AOR registration, and > we're currently using the REGISTER method. But please make suggestions - my > problem could easily be my own lack of imagination! Perhaps "routing registration"? Dale From spencer@wonderhamster.org Mon Oct 26 13:43: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 60F773A67F4 for ; Mon, 26 Oct 2009 13:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.351, 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 J2WTqVGfjjoY for ; Mon, 26 Oct 2009 13:43:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 532B13A6784 for ; Mon, 26 Oct 2009 13:43:02 -0700 (PDT) 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 0MGkbR-1MyRo227H7-00E5es; Mon, 26 Oct 2009 16:43:14 -0400 Message-ID: <47788504F5544FA9A0225AED02FF018E@china.huawei.com> From: "Spencer Dawkins" To: "Haluska, John J" , References: <8B6A9EC265011E4CB70F99C64426E8C205388882DD@rrc-dte-exmb2.dte.telcordia.com> Date: Mon, 26 Oct 2009 15:43:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_079E_01CA5653.00A26F00" 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/+zWf9XRv3tn/E71IIJZZ826e4Ff8ctnIGJZa SKLgmFYruWF8bzC9ZOl4r7Lroe0fL1Mgt0YYfYAvaB2VwWZi4W UOjivWZQSJ3emntlW7neYrJxe76K8fF+BQfiMH4+bc= Cc: "Haluska, John J" , gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] Requesting DISPATCH advice on draft-haluska-sipping-directory-assistance-09 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, 26 Oct 2009 20:43:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_079E_01CA5653.00A26F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One minor addition to John's summary - I had some concerns about = handling people 100+ page documents, but I've gotten 100+ page documents = as a Gen-ART reviewer. I'm remembering PIM (which I got) and NFS4 (which = I did NOT get) as case studies... My larger concern was that some of the material was clearly descriptive = text (INFO), some was tagged as BCP, and some was headed towards = protocol gap analysis and solution (PS) - I thought a document split = would help reviewers focus on the kind of review that's needed for = specific parts of the proposal. So please do provide feedback on possible splits, and whether this is = helpful - nobody wants to make a serious editorial pass if it's not = necessary! Thanks, Spencer ----- Original Message -----=20 From: Haluska, John J=20 To: dispatch@ietf.org=20 Cc: mary.barnes@nortel.com ; gonzalo.camarillo@ericsson.com ; = fluffy@cisco.com ; spencer@wonderhamster.org ; Haluska, John J=20 Sent: Monday, October 26, 2009 3:08 PM Subject: Requesting DISPATCH advice on = draft-haluska-sipping-directory-assistance-09=20 Hello All, =20 We've been discussing with Cullen an AD-sponsored path for = draft-haluska-sipping-directory-assistance. Having received an = extensive review from Spencer Dawkins (thanks Spencer), one comment was = that we should consider breaking up the 100+ page document into several = more manageable documents, potentially organized into e.g.,=20 =20 - a description of the services - a description of standards gaps - a set of call flows - a set of best current practices =20 Cullen suggested that we talk to the DISPATCH working group to see = what kind of split makes sense, he was thinking that possibly some = material (e.g., protocol gaps) might have the potential to become the = basis of future work in DISPATCH or other working groups.=20 =20 We'd definitely appreciate any advice on this from the DISPATCH = working group. A pointer to the announcement for the latest revision = (-09) of the document is provided below. =20 Again the input we're looking for is advice on splitting up the = document. =20 =20 Thanks much, =20 John Haluska =20 =20 =20 =20 =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 =3D =3D =3D=20 From: Internet-Drafts@ietf.org=20 To: i-d-announce@ietf.org=20 Reply-to: Internet-Drafts@ietf.org=20 Subject: I-D Action:draft-haluska-sipping-directory-assistance-09.txt = X-RSN: 1/0/935/27107/30454=20 X-HREF: = http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D30454=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 =20 Title : Considerations for Information Services and Operator Services = Using SIP=20 Author(s) : J. Haluska, et al.=20 Filename : draft-haluska-sipping-directory-assistance-09.txt=20 Pages : 109=20 Date : 2009-10-23=20 =20 Information Services are services whereby information is provided in=20 response to user requests, and may include involvement of a human or=20 automated agent. A popular existing Information Service is Directory=20 Assistance (DA). Moving ahead, Information Services providers=20 envision exciting multimedia services that support simultaneous=20 voice and data interactions with full operator backup at any time=20 during the call. Information Services providers are planning to=20 migrate to SIP based platforms, which will enable such advanced=20 services, while continuing to support traditional DA services.=20 =20 Operator Services are traditional PSTN services which often involve=20 providing human or automated assistance to a caller, and often=20 require the specialized capabilities traditionally provided by an=20 operator services switch. Market and/or regulatory factors in some=20 jurisdictions dictate that some subset of Operator Services continue=20 to be provided going forward.=20 =20 This document aims to identify how Operator and Information Services=20 can be implemented using existing or currently proposed SIP=20 mechanisms, to identity existing protocol gaps, and to provide a set=20 of Best Current Practices to facilitate interoperability. For=20 Operator Services, the intention is to describe how current operator=20 services can continue to be provided to PSTN based subscribers via a=20 SIP based operator services architecture. It also looks at how=20 current operator services might be provided to SIP based subscribers=20 via such an architecture, but does not consider the larger question=20 of the need for or usefulness or suitability of each of these=20 services for SIP based subscribers.=20 =20 A URL for this Internet-Draft is:=20 = http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assis= tance-09.txt=20 =20 Internet-Drafts are also available by anonymous FTP at:=20 ftp://ftp.ietf.org/internet-drafts/=20 =20 Below is the data which will enable a MIME compliant mail reader=20 implementation to automatically retrieve the ASCII version of the=20 Internet-Draft.=20 _______________________________________________=20 I-D-Announce mailing list=20 I-D-Announce@ietf.org=20 https://www.ietf.org/mailman/listinfo/i-d-announce=20 Internet-Draft directories: http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 =20 *****=20 Click below to download the attachment(s) in this message:=20 Attachment: draft_haluska_sipping_directory_assistance_09.txt (1K)=20 ------=_NextPart_000_079E_01CA5653.00A26F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One minor addition to John's summary - I had some = concerns=20 about handling people 100+ page documents, but I've gotten 100+ page = documents=20 as a Gen-ART reviewer. I'm remembering PIM (which I got) and NFS4 (which = I did=20 NOT get) as case studies...
 
My larger concern was that some of the material was = clearly=20 descriptive text (INFO), some was tagged as BCP, and some was headed = towards=20 protocol gap analysis and solution (PS) - I thought a document split = would help=20 reviewers focus on the kind of review that's needed for specific parts = of the=20 proposal.
 
So please do provide feedback on possible splits, = and whether=20 this is helpful - nobody wants to make a serious editorial pass if = it's not=20 necessary!
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Haluska,=20 John J
Cc: mary.barnes@nortel.com ; gonzalo.camarillo@ericsson= .com=20 ; fluffy@cisco.com ; spencer@wonderhamster.org = ; Haluska,=20 John J
Sent: Monday, October 26, 2009 = 3:08=20 PM
Subject: Requesting DISPATCH = advice on=20 draft-haluska-sipping-directory-assistance-09

Hello All,

 

We=92ve been discussing with Cullen an = AD-sponsored path for=20 draft-haluska-sipping-directory-assistance.  Having received an = extensive=20 review from Spencer Dawkins (thanks Spencer), one comment was that we = should=20 consider breaking up the 100+ page document into several more = manageable=20 documents, potentially organized into e.g.,

 

         &= nbsp;     =20 - a description of the services

         &= nbsp;     =20 - a description of standards gaps

         &= nbsp;     =20 - a set of call flows

         &= nbsp;     =20 - a set of best current practices

         &= nbsp;     =20

Cullen suggested that we talk to the DISPATCH = working group=20 to see what kind of split makes sense, he was thinking that possibly = some=20 material (e.g., protocol gaps) might have the potential to become the = basis of=20 future work in DISPATCH or other working groups.

 

We=92d definitely appreciate any advice on this = from the=20 DISPATCH working group. A pointer to the announcement for the latest = revision=20 (-09) of the document is provided below.

 

Again the input we=92re looking for is advice on = splitting up=20 the document.

 

 

Thanks much,

 

John Haluska

 

 

 

 

 

 =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 =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =

From: Internet-Drafts@ietf.org 
To:=20 i-d-announce@ietf.org 
Reply-to:=20 Internet-Drafts@ietf.org 
Subject: I-D=20 Action:draft-haluska-sipping-directory-assistance-09.txt =  
X-RSN:=20 1/0/935/27107/30454 
X-HREF:=20 = http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D3= 0454 
 
A=20 New Internet-Draft is available from the on-line Internet-Drafts=20 directories. 
 
Title : Considerations for Information = Services and Operator Services Using SIP 
Author(s) : J. = Haluska, et=20 al. 
Filename :=20 draft-haluska-sipping-directory-assistance-09.txt 
Pages :=20 109 
Date : 2009-10-23 
 
Information Services = are=20 services whereby information is provided in 
response to user=20 requests, and may include involvement of a human or 
automated = agent.=20 A popular existing Information Service is = Directory 
Assistance (DA).=20 Moving ahead, Information Services providers 
envision = exciting=20 multimedia services that support simultaneous 
voice and data=20 interactions with full operator backup at any time 
during the = call.=20 Information Services providers are planning to 
migrate to SIP = based=20 platforms, which will enable such advanced 
services, while = continuing=20 to support traditional DA services. 
 
Operator = Services are=20 traditional PSTN services which often involve 
providing human = or=20 automated assistance to a caller, and often 
require the = specialized=20 capabilities traditionally provided by an 
operator services = switch.=20 Market and/or regulatory factors in some 
jurisdictions = dictate that=20 some subset of Operator Services continue 
to be provided = going=20 forward. 
 
This document aims to identify how = Operator and=20 Information Services 
can be implemented using existing or = currently=20 proposed SIP 
mechanisms, to identity existing protocol gaps, = and to=20 provide a set 
of Best Current Practices to facilitate=20 interoperability. For 
Operator Services, the intention is to = describe=20 how current operator 
services can continue to be provided to = PSTN=20 based subscribers via a 
SIP based operator services = architecture. It=20 also looks at how 
current operator services might be provided = to SIP=20 based subscribers 
via such an architecture, but does not = consider the=20 larger question 
of the need for or usefulness or suitability = of each=20 of these 
services for SIP based = subscribers. 
 
A URL=20 for this Internet-Draft=20 = is: 
http://www.ietf.org/internet-drafts/draft-haluska-sipping-di= rectory-assistance-09.txt 
 
Internet-Drafts=20 are also available by anonymous FTP=20 = at: 
ftp://ftp.ietf.org/internet-drafts/ 
 
Below= is=20 the data which will enable a MIME compliant mail=20 reader 
implementation to automatically retrieve the ASCII = version of=20 = the 
Internet-Draft. 
___________________________________= ____________ 
I-D-Announce=20 mailing=20 = list 
I-D-Announce@ietf.org 
https://www.ietf.org/mailman= /listinfo/i-d-announce 
Internet-Draft=20 directories: http://www.ietf.org/shadow.html 
or=20 = ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
 
***** <= BR>Click=20 below to download the attachment(s) in this message: 
Attachment:=20 draft_haluska_sipping_directory_assistance_09.txt=20 (1K) 

------=_NextPart_000_079E_01CA5653.00A26F00-- From dean.willis@softarmor.com Mon Oct 26 17:32: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 72A023A6860 for ; Mon, 26 Oct 2009 17:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 QqqStJqeKwdE for ; Mon, 26 Oct 2009 17:32:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 785B93A67E9 for ; Mon, 26 Oct 2009 17:32:06 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9R0WGUY007902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 19:32:18 -0500 Message-Id: <0D732C85-68AC-4591-9DA9-C2603349C0F3@softarmor.com> From: Dean Willis To: Dale Worley In-Reply-To: <1256589260.3748.75.camel@khone.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 19:32:11 -0500 References: <429446390BA91242867940DBE798A06B73FC543578@mail> <429446390BA91242867940DBE798A06B73FC54357F@mail> <1256586191.3748.25.camel@khone.us.nortel.com> <1256589260.3748.75.camel@khone.us.nortel.com> X-Mailer: Apple Mail (2.936) Cc: Bob Penfield , "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] option tag in domain-registration (was RE: To-URI in domain-registration) 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, 27 Oct 2009 00:32:07 -0000 On Oct 26, 2009, at 3:34 PM, Dale Worley wrote: > On Mon, 2009-10-26 at 15:43 -0400, Dale Worley wrote: >> On Wed, 2009-10-21 at 18:13 -0400, Bob Penfield wrote: >>> I understand that including the tag in a Require header does not >>> mean >>> that the UAS will apply that extension. However, if the UAS does >>> apply >>> the extension (if I understand the sentence below from section 8.2.4 >>> correctly) it is suppose to include the tag in a Require header in >>> the >>> response. >> >> If the request has a tag in a Require header, than if the UAS does >> not >> understand the extension, the UAS will reject the request with a 421. >> There is no generic requirement that the request will trigger the >> mechanisms of the extension -- the presence of "Require" is >> orthogonal >> to the question of whether the extension causes something >> interesting to >> happen to the request. In particular, if "Require" is missing, the >> UAS >> will not process the request differently. >> >> (However, if an option-tag is present with "Supported", the >> definition >> of the extension may cause the request to be processed differently >> than >> it otherwise would be.) > > Yuck -- what I wrote is what was intended by RFC 3261, but which is > violated by a few extensions, as Hadriel points out. > Yeah, but Bob was talking about the presence of a Require: option-tag in a RESPONSE, not a request. We seem to have violated that part of RFC 3261 even more frequently. -- Dean From dean.willis@softarmor.com Mon Oct 26 17:34: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 3A4803A67E9 for ; Mon, 26 Oct 2009 17:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 IpoTEhbWZWi6 for ; Mon, 26 Oct 2009 17:34:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5FBA828C18F for ; Mon, 26 Oct 2009 17:34:03 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9R0YEmP007917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 19:34:16 -0500 Message-Id: From: Dean Willis To: Dale Worley In-Reply-To: <1256589340.3748.77.camel@khone.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 19:34:08 -0500 References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1255986053.3767.46.camel@khone.us.nortel.com> <1256589340.3748.77.camel@khone.us.nortel.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Domain RegistrationDraft draft-kaplan-dispatch-domain-registration 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, 27 Oct 2009 00:34:04 -0000 On Oct 26, 2009, at 3:35 PM, Dale Worley wrote: > On Mon, 2009-10-19 at 16:33 -0500, Spencer Dawkins wrote: >> Without speaking for the draft author, I think "domain" is open for >> suggestions. The SIPconnect working group has gone through >> "registration" >> with no qualifier, "implicit registration", and I think "bulk >> registration" >> was also tossed in but sank without a ripple, so we're obviously >> not wedded >> to "domain". >> >> "registration" is harder for me to think of alternatives for, >> because we >> think we're achieving roughly the same end-game as per-AOR >> registration, and >> we're currently using the REGISTER method. But please make >> suggestions - my >> problem could easily be my own lack of imagination! > > Perhaps "routing registration"? Route update -- using a different request method than REGISTER, like maybe ROUTEUP. Or given the overload on UPDATE, maybe call it a "route advertisement", which is terminology that seems to have worked well in the routing world. Why do we think we're the first ones to encounter this design pattern? -- Dean From HKaplan@acmepacket.com Mon Oct 26 19:27: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 49F213A6947 for ; Mon, 26 Oct 2009 19:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 msfDDqDjJBgY for ; Mon, 26 Oct 2009 19:27:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 71FED3A68F2 for ; Mon, 26 Oct 2009 19:27:01 -0700 (PDT) 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; Mon, 26 Oct 2009 22:27:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Oct 2009 22:27:13 -0400 From: Hadriel Kaplan To: Dale Worley , DISPATCH Date: Mon, 26 Oct 2009 22:27:11 -0400 Thread-Topic: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method Thread-Index: AcpWe4KKp4uj4k0HSlSUe0PO1TUQwQAMFStg Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> In-Reply-To: <1256589116.3748.73.camel@khone.us.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 27 Oct 2009 02:27:02 -0000 Hi Dale, Inline... > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dale Worley > Sent: Monday, October 26, 2009 4:32 PM >=20 > I think the proposal can be improved and controversy avoided by making > three rather small changes: >=20 > 1. Restrict (at least in principle) the domain name involved to be one > that is properly owned or controlled by the SSP or PBX. Already done - see version 01 of the draft (submitted today). =20 > 2. Replace the REGISTER method with a new method name. This has already been discussed, and I tried to better summarize the reason= s why REGISTER is necessary in the draft-01 rev. =20 > 3. Clarify that the RFC defines a mechanism for maintaining a "route to > this domain" database, which may be used in various ways which are not > specified by the RFC. (In particular, the SSP might use it to apply > Route headers to requests, or it might use it to populate a DNS server, > and then use RFC 3263 to route requests.) This loses no functionality > and ensures that the database-updating remains uncoupled from the users > of the database. I'm not sure what that buys us. I don't think there's any controversy over= the "how to use the database" part. But more importantly, for interoperab= ility to be achieved I think it's critical we explain how it's used, since = it affects what requests routed by it look like to the party that Registere= d.=20 -hadriel From HKaplan@acmepacket.com Mon Oct 26 22:24: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 02C823A68F0 for ; Mon, 26 Oct 2009 22:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 AAci9iHJk87I for ; Mon, 26 Oct 2009 22:24:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E27123A67F2 for ; Mon, 26 Oct 2009 22:24:14 -0700 (PDT) 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, 27 Oct 2009 01:24:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Oct 2009 01:24:17 -0400 From: Hadriel Kaplan To: DISPATCH Date: Tue, 27 Oct 2009 01:24:11 -0400 Thread-Topic: I-D Action:draft-kaplan-dispatch-domain-registration-01.txt Thread-Index: AcpWlFhrkG0WAJKJRGCNE4U930+xQQAMPuBg 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_E6C2E8958BA59A4FB960963D475F7AC31A0A95C142mail_" MIME-Version: 1.0 Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-domain-registration-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, 27 Oct 2009 05:24:16 -0000 --_002_E6C2E8958BA59A4FB960963D475F7AC31A0A95C142mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - updated the draft to avoid alt-root DNS issues, and to describe the r= ationales for the choices in better detail. The To-URI issue is still open, as by my count it's about even in votes. -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: Monday, October 26, 2009 7:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-kaplan-dispatch-domain-registration-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Session Initiation Protocol (SIP) Domain > Registration > Author(s) : H. Kaplan > Filename : draft-kaplan-dispatch-domain-registration-01.txt > Pages : 17 > Date : 2009-10-26 >=20 > This document defines a means of providing reachability information > for a domain of SIP AoR's using a SIP REGISTER method transaction. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-domain- > registration-01.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_E6C2E8958BA59A4FB960963D475F7AC31A0A95C142mail_ Content-Type: text/plain; name="draft-kaplan-dispatch-domain-registration-01.url.txt" Content-Description: draft-kaplan-dispatch-domain-registration-01.url.txt Content-Disposition: attachment; filename="draft-kaplan-dispatch-domain-registration-01.url.txt"; size=109; creation-date="Mon, 26 Oct 2009 19:30:47 GMT"; modification-date="Mon, 26 Oct 2009 19:30:47 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_002_E6C2E8958BA59A4FB960963D475F7AC31A0A95C142mail_-- From shida@ntt-at.com Tue Oct 27 03:59: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 6D6493A67E6 for ; Tue, 27 Oct 2009 03:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.402, 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 A0M9gPlXu1yU for ; Tue, 27 Oct 2009 03:59:48 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.44.25]) by core3.amsl.com (Postfix) with SMTP id 970D83A68E9 for ; Tue, 27 Oct 2009 03:59:48 -0700 (PDT) Received: (qmail 11860 invoked from network); 27 Oct 2009 11:15:07 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway11.websitewelcome.com with SMTP; 27 Oct 2009 11:15:07 -0000 Received: from fl1-122-135-49-232.tky.mesh.ad.jp ([122.135.49.232]:56083 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2jmT-0003gm-RI; Tue, 27 Oct 2009 06:00:02 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Shida Schubert In-Reply-To: <1256581091.3748.9.camel@khone.us.nortel.com> Date: Tue, 27 Oct 2009 20:00:00 +0900 Content-Transfer-Encoding: 7bit Message-Id: <3623C7AE-6491-4D5A-8150-FC2A3E420A91@ntt-at.com> References: <20091026005148.196193A68EF@core3.amsl.com> <1256581091.3748.9.camel@khone.us.nortel.com> To: Dale Worley X-Mailer: Apple Mail (2.1076) 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: 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: Tue, 27 Oct 2009 10:59:49 -0000 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? Regards Shida On Oct 27, 2009, at 3:18 AM, Dale Worley wrote: > 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 >> successfuly submitted by Dale Worley and posted to the IETF >> repository. >> >> 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 >> >> Abstract: >> The "music on hold" feature is one of the most desired features of >> telephone systems in the business environment. "Music on hold" is >> where, when one party to a call has the call "on hold", that party's >> telephone provides an audio stream (often music) to be heard by the >> other party. Architectural features of SIP make it difficult to >> implement music-on-hold in a way that is fully compliant with the >> standards. The implementation of music-on-hold described in this >> document is fully effective and standards-compliant, but has a number >> of advantages over the methods previously documented. In particular, >> it is less likely to produce peculiar user interface effects and more >> 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 fluffy@cisco.com Tue Oct 27 06:12: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 1D43028C143 for ; Tue, 27 Oct 2009 06:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.093 X-Spam-Level: X-Spam-Status: No, score=-109.093 tagged_above=-999 required=5 tests=[AWL=1.506, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 9lpp2d4didd6 for ; Tue, 27 Oct 2009 06:12:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 969353A6782 for ; Tue, 27 Oct 2009 06:12:55 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEAAImO5kqQ/uCWe2dsb2JhbACbPAEBFiQGpHCYOII5AQaBfwSLYQ X-IronPort-AV: E=Sophos;i="4.44,633,1249257600"; d="scan'208";a="52877892" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2009 13:13:08 +0000 Received: from ams3-vpn-dhcp5824.cisco.com (ams3-vpn-dhcp5824.cisco.com [10.61.86.191]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RDD89v016121; Tue, 27 Oct 2009 13:13:08 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <8B6A9EC265011E4CB70F99C64426E8C205388882DD@rrc-dte-exmb2.dte.telcordia.com> Date: Tue, 27 Oct 2009 14:13:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B6A9EC265011E4CB70F99C64426E8C205388882DD@rrc-dte-exmb2.dte.telcordia.com> To: "Haluska, John J" X-Mailer: Apple Mail (2.1076) Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: Re: [dispatch] Requesting DISPATCH advice on draft-haluska-sipping-directory-assistance-09 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, 27 Oct 2009 13:12:57 -0000 When I see all the things that this includes, much of it normative in =20= behavior, I don't think AD sponsoring is a route we should take. Cullen On Oct 26, 2009, at 21:08 , Haluska, John J wrote: > Hello All, > > We=92ve been discussing with Cullen an AD-sponsored path for draft-=20 > haluska-sipping-directory-assistance. Having received an extensive =20= > review from Spencer Dawkins (thanks Spencer), one comment was that =20 > we should consider breaking up the 100+ page document into several =20 > more manageable documents, potentially organized into e.g., > > - a description of the services > - a description of standards gaps > - a set of call flows > - a set of best current practices > > Cullen suggested that we talk to the DISPATCH working group to see =20 > what kind of split makes sense, he was thinking that possibly some =20 > material (e.g., protocol gaps) might have the potential to become =20 > the basis of future work in DISPATCH or other working groups. > > We=92d definitely appreciate any advice on this from the DISPATCH =20 > working group. A pointer to the announcement for the latest revision =20= > (-09) of the document is provided below. > > Again the input we=92re looking for is advice on splitting up the =20 > document. > > > Thanks much, > > John Haluska > > > > > > =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 > =3D =3D =3D =3D =3D =3D =3D =3D > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D Action:draft-haluska-sipping-directory-assistance-09.txt > X-RSN: 1/0/935/27107/30454 > X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D3045= 4 > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > > Title : Considerations for Information Services and Operator =20 > Services Using SIP > Author(s) : J. Haluska, et al. > Filename : draft-haluska-sipping-directory-assistance-09.txt > Pages : 109 > Date : 2009-10-23 > > Information Services are services whereby information is provided in > response to user requests, and may include involvement of a human or > automated agent. A popular existing Information Service is Directory > Assistance (DA). Moving ahead, Information Services providers > envision exciting multimedia services that support simultaneous > voice and data interactions with full operator backup at any time > during the call. Information Services providers are planning to > migrate to SIP based platforms, which will enable such advanced > services, while continuing to support traditional DA services. > > Operator Services are traditional PSTN services which often involve > providing human or automated assistance to a caller, and often > require the specialized capabilities traditionally provided by an > operator services switch. Market and/or regulatory factors in some > jurisdictions dictate that some subset of Operator Services continue > to be provided going forward. > > This document aims to identify how Operator and Information Services > can be implemented using existing or currently proposed SIP > mechanisms, to identity existing protocol gaps, and to provide a set > of Best Current Practices to facilitate interoperability. For > Operator Services, the intention is to describe how current operator > services can continue to be provided to PSTN based subscribers via a > SIP based operator services architecture. It also looks at how > current operator services might be provided to SIP based subscribers > via such an architecture, but does not consider the larger question > of the need for or usefulness or suitability of each of these > services for SIP based subscribers. > > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assist= ance-09.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. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ***** > Click below to download the attachment(s) in this message: > Attachment: draft_haluska_sipping_directory_assistance_09.txt (1K) From dworley@nortel.com Tue Oct 27 12:50: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 D15FE3A6989 for ; Tue, 27 Oct 2009 12:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 xru8DxcDH-jZ for ; Tue, 27 Oct 2009 12:50:59 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ED5493A63EC for ; Tue, 27 Oct 2009 12:50:58 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9RJp4q23197; Tue, 27 Oct 2009 19:51:04 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 15:51:01 -0400 From: "Dale Worley" 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: Tue, 27 Oct 2009 15:51:00 -0400 Message-Id: <1256673060.3740.70.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: 27 Oct 2009 19:51:01.0991 (UTC) FILETIME=[CFD4F770:01CA573E] 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: Tue, 27 Oct 2009 19:50:59 -0000 On Tue, 2009-10-27 at 20:00 +0900, Shida Schubert wrote: > 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? In regard to this draft's subject matter, it is squarely in the realm that RFC 5359 attempts to describe. If the RFC was just an RFC, I would consider this draft to be independent. But since RFC 5359 has been christened BCP 144, I see this draft as updating the BCP for this realm of activity. Within that philosophy, this draft could be interpreted as replacing section 2.3 of RFC 5359 or as providing an additional "best" method, effectively being section 2.19. Although I favor the first approach, the working group may favor the second. Dale From L.Liess@telekom.de Wed Oct 28 02:22: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 B7C113A6819 for ; Wed, 28 Oct 2009 02:22:45 -0700 (PDT) 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 mFQEu1h+RX6N for ; Wed, 28 Oct 2009 02:22:44 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id B84CE3A699D for ; Wed, 28 Oct 2009 02:22:42 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 28 Oct 2009 10:22:50 +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); Wed, 28 Oct 2009 10:22:48 +0100 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, 28 Oct 2009 10:22:46 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4ADFB028.3010604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: AcpSs/G/q80D4xvJTaO0m48z9Bh8uwEdSMvg References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> From: To: X-OriginalArrivalTime: 28 Oct 2009 09:22:48.0811 (UTC) FILETIME=[375BE3B0:01CA57B0] Cc: anwars@avaya.com, dispatch@ietf.org Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 28 Oct 2009 09:22:45 -0000 You are right that discrete items and multiple URNs are much more complex than the original hierarchical URNs. Multiple URNs add a lot of new problems. But do you see other possibility to solve Adam's issue? In principle, we do not have the problem with the URN which we want to define in the current draft, if we drop chapter 4.2 and only define the ringback tones as country-specific. As John pointed out we can not send Alert-Info in a busy-response anyway.=20 Maybe we can restrict the IANA registration to Alert URNs which we know people intend to implement? This will probably reduce the number considerably, but the theoretical problem remains.=20 I will take this as an open issue for the dispatch meeting slides. I hope Adam will be there because it was his proposal to use combinations of discrete items rather than hierarchy. I am open for both and also for a new proposal.=20 Additional comments inline. >=20 > I have a sip pbx phone on my desk. I don't have any distinction for=20 > internal vs. external, and have no clue how "normal" would be=20 > different=20 > from one or the other of those. I don't really desire any=20 > distinction on=20 > any of those terms. The scenario you describe is also valid for me. I think it depends on the job they are doing if people using a PBX wants to know a call is internal or external. Call centres, sales people have other needs than we have and as far as I know customers often require these features from PBX-systems. I think Alan added this stuff to the draft because it is required by Avaya's customers.=20 >=20 > > I would keep the two worlds disjunct. E.g. , I have a sip=20 > handy which is > > attached sometimes to the pbx and sometimes to my public carrier at > > home, I may want the pbx ringing tone to be different from=20 > the ringing > > tone at home.=20 >=20 > I don't really have any objection to a bunch of "names" for extra=20 > arbitrary ring types. The real issue is deciding when to use one or=20 > another. Is the assumption here that these will typically be=20 > inserted by=20 > some agent acting on behalf of the phone acting on them, rather than=20 > being inserted by "the other" party? IOW, *my* pbx decides that an=20 > incoming call from you is "internal" or "external" and inserts a=20 > suitable value by its policy, rather than *your* phone=20 > deciding the call=20 > is internal or external and inserting the value that I then render.=20 >=20 > It seems like you might have both models in mind. On one hand=20 > *my* pbx=20 > is deciding if the call to me is internal or external, but=20 > the other end=20 > is indicating it is a French phone rather than a US phone and so at=20 > least ringback should be french. I don't see the contradiction here: external is inserted by the PBX-system in the INVITE to my phone if the caller is external. How could my phone decide if the caller is external or internal? If I call someone in France the French phone (or ist proxy) may insert the Alert-Info URN for france into the 180 ringing response.=20 These are for me two different scenarions. Or maybe I did not understand you correctly? I should probably change wording in the draft and use ringback instead of ringing in connection with country tones. The current text is often quite confusing. =20 >=20 > > > A nit: in 4.3.2 I would expext the forward to be indicated,=20 > > > if at all,=20 > > > with a 181 rather than a 180. > >=20 > > My understanding is that the URN should be transmitted in the 180 > > ringing after the forwarded call has reached ist final=20 > destination and > > the phone is ringing at the UE, not in the 181 sent by the=20 > forwarding > > proxy when it decides to to forward the call. Also the RFC 3261 only > > allows Alert-Info in 180 responses. Or did I miss something here? >=20 > I checked, and you are right that A-I isn't allowed in 181.=20 > Sorry about=20 > that. But it seems like a mistake to me. >=20 > The behavior you describe requires there to be a stateful=20 > agent in the=20 > network that is aware this has happened. In general there may=20 > be nothing=20 > in a position to perform that role. But in any case it is a nit. It's true, only a statefull proxy is able to insert this URN if it is send in 180 ringing.=20 But this is the scenario for which this particular A-I URN is defined.=20 The caller's UA renders a ringback=20 tone when it receives the 180, not earlier. The URN should tell the the caller's UA to render=20 a specific ringback *instead* of the ringback used for not forwarded calls.=20 In principle the 181 tells the caller's UA that the call has been forwarded and the UA may decide,=20 independent from the proxy, to notity the caller about this.=20 But this was my personal opinion and this one of Alan's use cases.=20 I am not sure he follows the discussion, so let me check with him.=20 Thank you Laura >=20 > Thanks, > Paul >=20 > > Thanks a lot > > Laura > >=20 > >> Thanks, > >> Paul > >> > >> L.Liess@telekom.de wrote: > >>> =20 > >>> Hi, > >>> > >>> We've re-submitted the Alert-Info URNs draft for DISPATCH > >>> > >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > >> -info-urns > >>> -00.txt . (The previous version od the draft was in BLISS=20 > >> and we had a > >>> presentation in BLISS at the last IETF.) > >>> > >>> We did some major changes, as suggested on the mailing list, e.g.: > >>> Added: =20 > >>> - Description of the interoperability problems for=20 > >> PBX-services (in > >>> the Introduction chapter)=20 > >>> - Requirements for the Alert-Info URNs mechanism=20 > >>> - Alert-Info URNs Indications for country-specific tones > >>> Changed:=20 > >>> - Initial IANA Registration mechanism to avoid=20 > >> combinatorial explosion > >>> of IANA values.=20 > >>> > >>> > >>> Many thanks for the comments and suggestions, > >>> Laura=20 > >>> > >>> > >>> > >>> =20 > >>> > >>> -----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, October 19, 2009 1:00 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt=20 > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> Title : Alert-Info URNs for the Session Initiation > >>> Protocol (SIP) > >>> Author(s) : D. Alexeitsev, et al. > >>> Filename : draft-liess-dispatch-alert-info-urns-00.txt > >>> Pages : 25 > >>> Date : 2009-10-19 > >>> > >>> The Session Initiation Protocol (SIP) supports the capability to > >>> provide a reference to the alternative ringback tone (RBT) for > >>> caller, or ring tone (RT) for callee using the Alert-Info header. > >>> However, the reference addresses only the network resources with > >>> specific rendering properties. There is currently no support for > >>> predefined standard identifiers for ringback tones or semantic > >>> indications without tied rendering. To overcome this=20 > >> limitations and > >>> support new applications a family of the URNs is defined in this > >>> specification. > >>> > >>> A URL for this Internet-Draft is: > >>> > >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > >> -info-urns > >>> -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 > >>> > >=20 >=20 From Simo.Veikkolainen@nokia.com Wed Oct 28 02:44: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 9A45028C0DF for ; Wed, 28 Oct 2009 02:44:50 -0700 (PDT) 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 eiql3oBwBkFA for ; Wed, 28 Oct 2009 02:44:49 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 908673A6931 for ; Wed, 28 Oct 2009 02:44:41 -0700 (PDT) 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 n9S9iXTp021624; Wed, 28 Oct 2009 11:44:52 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 11:44:27 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 11:44:14 +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); Wed, 28 Oct 2009 11:44:09 +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; Wed, 28 Oct 2009 10:44:08 +0100 From: To: Date: Wed, 28 Oct 2009 10:44:07 +0100 Thread-Topic: SIP-XMPP ad-hoc meeting being planned for Hiroshima Thread-Index: AcpXszGIruxAMCWWQYOACaLI6fFQQA== 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: 28 Oct 2009 09:44:09.0731 (UTC) FILETIME=[32D8C530:01CA57B3] X-Nokia-AV: Clean Cc: Markus.Isomaki@nokia.com Subject: [dispatch] SIP-XMPP ad-hoc meeting being planned for Hiroshima 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, 28 Oct 2009 09:44:50 -0000 Hello, Just wanted folks to know that we are in the process of planning an ad-hoc = meeting on SIP-XMPP coexistence discussed on this list earlier (see charter= proposal http://www.ietf.org/mail-archive/web/dispatch/current/msg00560.ht= ml). We are also setting up a separate email list for discussions on this t= opic. The time and date of the ad-hoc meeting will be announced as soon as we hav= e the details available. Most likely it will take place during one of the l= unch breaks during the week.=20 The main focus in the meeting is get all interested people in the same room= to discuss the problem statement, scope, and schedule of the work, i.e. th= e charter. We can initially discuss technical solutions as well if time all= ows.=20 So, please stay tuned for more details on the upcoming ad-hoc meeting. In t= he meantime, I will be posting a note with a summary of the technical issue= s discussed so far. Regards, Simo From Simo.Veikkolainen@nokia.com Wed Oct 28 04:31: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 C0A2B3A68F6 for ; Wed, 28 Oct 2009 04:31:50 -0700 (PDT) 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 ccOYfan3xT+S for ; Wed, 28 Oct 2009 04:31:49 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D17BA3A6837 for ; Wed, 28 Oct 2009 04:31:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9SBVtOC018664 for ; Wed, 28 Oct 2009 06:32:04 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:31:56 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:31:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:31:44 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 28 Oct 2009 12:31:43 +0100 From: To: Date: Wed, 28 Oct 2009 12:31:42 +0100 Thread-Topic: Technical issues on SIP/XMPP co-existence so far Thread-Index: AcpXwjkb/JzoD8QqQza3s7kri0vxQQ== 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: 28 Oct 2009 11:31:44.0924 (UTC) FILETIME=[3A710DC0:01CA57C2] X-Nokia-AV: Clean Subject: [dispatch] Technical issues on SIP/XMPP co-existence so far 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, 28 Oct 2009 11:31:50 -0000 Hi, I've tried to summarize the issues raised during the discussion on SIP-XMPP= co-existence charter proposal (http://www.ietf.org/mail-archive/web/dispat= ch/current/msg00560.html). Several folks participated in the discussion, s= o if I have missed any comments, please let me know. The purpose is the keep the list of issues as food for thought both for the= planned SIP-XMPP co-existence ad-hoc meeting in Hiroshima, and for whateve= r forum that (hopefully) follows as a result of the ad-hoc meeting. The following issues were raised on the DISPACH WG list: =20 - Relationship to disaggregated media. How is this work related to http://t= ools.ietf.org/html/draft-loreto-dispatch-disaggregated-media-00 ? - Relationship to SIP/XMPP interworking. There are several drafts (draft-sa= intandre-sip-xmpp-*) available that deal with SIP/XMPP interworking (protoc= ol translation). Should this work be handled together with the proposed SIP= -XMPP co-existence (using SIP and XMPP in a complementary fashion). - Video vs. voice. Video media should be included as an additional use case= in addition to voice media. - Multiparty. http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-i= m-01 talks only about one-to-one sessions. Should the scope also cover mult= iparty cases? - Call transfer. How should call transfer be considered in this work? - Real-time text. There are XMPP implementations that transmit text charact= er-by-character. Should standardizing such a feature be considered. If yes,= should it be part of this effort, or is a better home the XSF? - Call-id usage. Effects of B2BUA's to call-id and correlation id need to b= e considered. - Scope, other IM protocols. Are other IM protocols (than XMPP) in the scop= e of this work? - Learning addresses, vCard, E.164. What are the mechanisms for learning ot= her endpoints' addresses? Can vCard be used? Most SIP deployments use E.164= addresses. What are the effects of E.164 address format to this work? - How does correlation between IM and Jingle sessions work in XMPP? How doe= s XMPP negotiatie the use of Jingle? We can identify at least three categories on how to classify these issues. = There is no particular purpose for this categorization other than it might = help people to focus the discussion later on. * Role of SIP vs XMPP - What medias or modes of communication each one would support? - Disjoint vs. overlapping feature sets (esp. presence and IM)? - What to do about overlapping functionality? * Address correlation - How to find the user addresses in the other protocol domain? - Via directories, presence, specific query (e.g. SIP OPTIONS), session s= etup, IM conversation, etc. * Protocol translation - SIP/XMPP "gateway" functionality Regards, Simo From kpfleming@digium.com Wed Oct 28 07:03: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 4A49A3A6782 for ; Wed, 28 Oct 2009 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.33 X-Spam-Level: X-Spam-Status: No, score=-104.33 tagged_above=-999 required=5 tests=[AWL=0.977, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 DHAS5De3UhXY for ; Wed, 28 Oct 2009 07:03:08 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 2802928C10C for ; Wed, 28 Oct 2009 07:03:08 -0700 (PDT) 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 1N397S-0002da-N3 for dispatch@ietf.org; Wed, 28 Oct 2009 09:03:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id A850C29E0002 for ; Wed, 28 Oct 2009 09:03:22 -0500 (CDT) 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 wXeewRdQfCZt for ; Wed, 28 Oct 2009 09:03:22 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id D71E929E0001 for ; Wed, 28 Oct 2009 09:03:21 -0500 (CDT) Message-ID: <4AE84F28.3040008@digium.com> Date: Wed, 28 Oct 2009 09:03:20 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: DISPATCH References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> In-Reply-To: <1256589116.3748.73.camel@khone.us.nortel.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 28 Oct 2009 14:03:09 -0000 Dale Worley wrote: (/me hesitantly jumps into the fray) > d. Using a new method avoids the dangerously ill-structured process of > using one method for requesting multiple activities that are > almost-but-not-quite the same. > > Let us compare the situation with that of REFER. At last count, there > were five distinct uses of the REFER method. Each is distinguished by > specific combinations of header fields and features of the context > within which the REFER is received. This leads to several undesirable > consequences: > > - The code at the UAS is no simpler, as there need to be five different > code paths, one for each version of REFER. Currently, the dispatching > is done by examining the context of the REFER, whereas if there were > five methods, dispatching could be done by method name. > > - Because the rules for distinguishing the five cases are not explicit, > implementers may easily make mistakes coding the dispatching. > > - Because the function of a REFER is determined by context, a REFER that > is accidentally sent in a different context than which was intended may > not be detected as an error and may cause inadvertent actions. > > - If there were separate method names, then each of the five code paths > could continue to examine the context of the request, but as a validity > check rather than as a dispatching decision. > > - Different uses of REFER have subtly different constraints on valid > values for the various header fields. I agree with Dale's points here rather strongly; when writing the UAS code to handle requests, it is much more logical and straightforward to inspect option tags and header fields when the purpose of doing so is sanity checking and for subtly adjusting the behavior of the request. When the option tags and/or header field values are used to cause a different operation to be performed, the code gets much more complex and harder to maintain. On the UAC side, I can't see how the need to take the existing (pre-standard) code and modify it to use a new method name is going to be any more burden than modifying that same code to conform to the standard... since there are very few (if any) existing implementations that already conform to the proposed standard. The UAC side of this proposal is very easy to implement in either case. I haven't seen any comments in this thread about how the re-use of REGISTER for a different purpose would affect proxies in the route path; if a proxy has to inspect option tags and header values to decide how to route a request, that increases complexity as well, which is avoided if the request uses a different method. -- 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 pkyzivat@cisco.com Wed Oct 28 07:09:48 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 EEF7E3A698B for ; Wed, 28 Oct 2009 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 I5HVd2b58i80 for ; Wed, 28 Oct 2009 07:09:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DF42D3A687C for ; Wed, 28 Oct 2009 07:09:47 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOPs50pAZnwN/2dsb2JhbADCIZgvhD8E X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208";a="218710542" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2009 14:10:02 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SEA2ZV006910; Wed, 28 Oct 2009 14:10:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:10:02 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:10:02 -0400 Message-ID: <4AE850B9.80607@cisco.com> Date: Wed, 28 Oct 2009 10:10:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 14:10:02.0114 (UTC) FILETIME=[57353E20:01CA57D8] Cc: anwars@avaya.com, dispatch@ietf.org Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 28 Oct 2009 14:09:49 -0000 L.Liess@telekom.de wrote: > You are right that discrete items and multiple URNs are much more > complex than the original hierarchical URNs. Multiple URNs add a lot of > new problems. > But do you see other possibility to solve Adam's issue? Perhaps its a messy problem any way you cut it. My main concern is not with going this way, but that if this way is taken then it be made very clear how the various combinations are to be interpreted by the recipient. There ought to be some obvious algorithm to get from any valid combination to something to render. > In principle, we > do not have the problem with the URN which we want to define in the > current draft, if we drop chapter 4.2 and only define the ringback tones > as country-specific. As John pointed out we can not send Alert-Info in a > busy-response anyway. If it makes sense, I wouldn't exclude the possibility of extending the use of Alert-Info to additional messages. > Maybe we can restrict the IANA registration to Alert URNs which we know > people intend to implement? This will probably reduce the number > considerably, but the theoretical problem remains. AFAIK there is no reason why all the URNs have to be drawn from the same URN scheme. Some other organization can define their own URNs and start using them. But that works more easily if the Alert-Info URNs are mutually exclusive, so the recipient just chooses one it understands and renders that. But I guess it can still work in the multi-dimensional approach. Each URN that is understood must imply the values of one or more of those dimensions. > I will take this as an open issue for the dispatch meeting slides. I > hope Adam will be there because it was his proposal to use combinations > of discrete items rather than hierarchy. I am open for both and also for > a new proposal. > > Additional comments inline. > >> I have a sip pbx phone on my desk. I don't have any distinction for >> internal vs. external, and have no clue how "normal" would be >> different >> from one or the other of those. I don't really desire any >> distinction on >> any of those terms. > > The scenario you describe is also valid for me. I think it depends on > the job they are doing if people using a PBX wants to know a call is > internal or external. Call centres, sales people have other needs than > we have and as far as I know customers often require these features from > PBX-systems. I think Alan added this stuff to the draft because it is > required by Avaya's customers. > >>> I would keep the two worlds disjunct. E.g. , I have a sip >> handy which is >>> attached sometimes to the pbx and sometimes to my public carrier at >>> home, I may want the pbx ringing tone to be different from >> the ringing >>> tone at home. >> I don't really have any objection to a bunch of "names" for extra >> arbitrary ring types. The real issue is deciding when to use one or >> another. Is the assumption here that these will typically be >> inserted by >> some agent acting on behalf of the phone acting on them, rather than >> being inserted by "the other" party? IOW, *my* pbx decides that an >> incoming call from you is "internal" or "external" and inserts a >> suitable value by its policy, rather than *your* phone >> deciding the call >> is internal or external and inserting the value that I then render. >> >> It seems like you might have both models in mind. On one hand >> *my* pbx >> is deciding if the call to me is internal or external, but >> the other end >> is indicating it is a French phone rather than a US phone and so at >> least ringback should be french. > > I don't see the contradiction here: external is inserted by the > PBX-system in the INVITE to my phone if the caller is external. How > could my phone decide if the caller is external or internal? > If I call someone in France the French phone (or ist proxy) may insert > the Alert-Info URN for france into the 180 ringing response. > These are for me two different scenarions. Or maybe I did not understand > you correctly? I don't think it is a contradiction or a problem. But it affects the use cases. And it introduces the potential need for some added policy decisions about what to honor and what not to honor. In some cases a pbx acting on behalf of its phone users may want to replace an incoming Alert-Info, or add to it. And those replacements/additions may or may not be influenced by what was in the incoming Alert-Info. Its an environment rich with possibilities. I think its at least worth pointing out. Thanks, Paul From john.elwell@siemens-enterprise.com Wed Oct 28 07:37: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 1329A28C1B0 for ; Wed, 28 Oct 2009 07:37:47 -0700 (PDT) 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.223, BAYES_00=-2.599, HELO_EQ_DE=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 c76S1jQ1iCPS for ; Wed, 28 Oct 2009 07:37:45 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 72F2628C1BA for ; Wed, 28 Oct 2009 07:37:44 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9SEbujL013320; Wed, 28 Oct 2009 15:37:56 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9SEbuWI018720; Wed, 28 Oct 2009 15:37:56 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Wed, 28 Oct 2009 15:37:55 +0100 From: "Elwell, John" To: "Kevin P. Fleming" Date: Wed, 28 Oct 2009 15:38:01 +0100 Thread-Topic: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method Thread-Index: AcpX13f/PLIdwo/xSoWzf/QFxhHA2QAA9iRQ Message-ID: <7402509E63C5A145A6095D46C179A5B7148B374F@DEMCHP99E35MSX.ww902.siemens.net> References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> <4AE84F28.3040008@digium.com> In-Reply-To: <4AE84F28.3040008@digium.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 28 Oct 2009 14:37:47 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Kevin P. Fleming > Sent: 28 October 2009 14:03 > Cc: DISPATCH > Subject: Re: [dispatch]=20 > draft-kaplan-dispatch-domain-registration should use a=20 > different method >=20 > Dale Worley wrote: >=20 > (/me hesitantly jumps into the fray) >=20 > > d. Using a new method avoids the dangerously ill-structured=20 > process of > > using one method for requesting multiple activities that are > > almost-but-not-quite the same. > >=20 > > Let us compare the situation with that of REFER. At last=20 > count, there > > were five distinct uses of the REFER method. Each is=20 > distinguished by > > specific combinations of header fields and features of the context > > within which the REFER is received. This leads to several=20 > undesirable > > consequences: > >=20 > > - The code at the UAS is no simpler, as there need to be=20 > five different > > code paths, one for each version of REFER. Currently, the=20 > dispatching > > is done by examining the context of the REFER, whereas if there were > > five methods, dispatching could be done by method name. > >=20 > > - Because the rules for distinguishing the five cases are=20 > not explicit, > > implementers may easily make mistakes coding the dispatching. > >=20 > > - Because the function of a REFER is determined by context,=20 > a REFER that > > is accidentally sent in a different context than which was=20 > intended may > > not be detected as an error and may cause inadvertent actions. > >=20 > > - If there were separate method names, then each of the=20 > five code paths > > could continue to examine the context of the request, but=20 > as a validity > > check rather than as a dispatching decision. > >=20 > > - Different uses of REFER have subtly different constraints on valid > > values for the various header fields. >=20 > I agree with Dale's points here rather strongly; when writing the UAS > code to handle requests, it is much more logical and=20 > straightforward to > inspect option tags and header fields when the purpose of doing so is > sanity checking and for subtly adjusting the behavior of the request. > When the option tags and/or header field values are used to cause a > different operation to be performed, the code gets much more=20 > complex and > harder to maintain. >=20 > On the UAC side, I can't see how the need to take the existing > (pre-standard) code and modify it to use a new method name is going to > be any more burden than modifying that same code to conform to the > standard... since there are very few (if any) existing implementations > that already conform to the proposed standard. The UAC side of this > proposal is very easy to implement in either case. >=20 > I haven't seen any comments in this thread about how the re-use of > REGISTER for a different purpose would affect proxies in the=20 > route path; > if a proxy has to inspect option tags and header values to=20 > decide how to > route a request, that increases complexity as well, which is=20 > avoided if > the request uses a different method. [JRE] This is a very good point. If we use REGISTER, then proxies on the pa= th can behave exactly as they would for a normal registration, e.g., w.r.t.= Path and Outbound processing. Is that what we want? I believe so, because = the different behaviour required is at the registrar/proxy. If proxies alon= g the path need to behave differently, that might support the argument for = using a different method, but if they need to behave the same as for REGIST= ER, I think this is a very strong (perhaps compelling) argument for keeping= REGISTER. John >=20 > --=20 > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From HKaplan@acmepacket.com Wed Oct 28 08: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 EDDE23A67FD for ; Wed, 28 Oct 2009 08:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 aOuDAtBSeVAL for ; Wed, 28 Oct 2009 08:15:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EB7003A672E for ; Wed, 28 Oct 2009 08:14:59 -0700 (PDT) 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, 28 Oct 2009 11:15:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Oct 2009 11:15:14 -0400 From: Hadriel Kaplan To: "Kevin P. Fleming" Date: Wed, 28 Oct 2009 11:15:13 -0400 Thread-Topic: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method Thread-Index: AcpX13cE0TJJ6oSyR9SgGT/mAoz72gABNH5w Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> <4AE84F28.3040008@digium.com> In-Reply-To: <4AE84F28.3040008@digium.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 Cc: DISPATCH Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 28 Oct 2009 15:15:01 -0000 Hi Kevin,=20 The intent of the draft, and part of the rationale for using REGISTER in fa= ct, is that it's processing is NOT different. It's not different on Proxie= s, and it's not different on UAC's other than adding that tag string. It's= not even actually that different on UAS's - it's real "difference" to the = UAS/Registrar is the logical Database it updates, and the key it uses to lo= okup in that database. The "routing" portion of the draft, which uses the database and uses loose-= routing to reach the IP-PBX, is different than how 3261 routes to the AoR d= atabase populated by REGISTER. But that's not tied to the REGISTER request= method name, obviously. It's true that affecting a different database is a change for REGISTER. Bu= t if using a option-tag or header to indicate that is "more complex and har= der to maintain" than using a new method name, then we're in real trouble. = Because PUBLISH and SUBSCRIBE effectively do that with every different eve= nt package, without changing the method name, afaict.=20 -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Kevin P. Fleming > Sent: Wednesday, October 28, 2009 10:03 AM > Cc: DISPATCH >=20 > I agree with Dale's points here rather strongly; when writing the UAS > code to handle requests, it is much more logical and straightforward to > inspect option tags and header fields when the purpose of doing so is > sanity checking and for subtly adjusting the behavior of the request. > When the option tags and/or header field values are used to cause a > different operation to be performed, the code gets much more complex and > harder to maintain. > > On the UAC side, I can't see how the need to take the existing > (pre-standard) code and modify it to use a new method name is going to > be any more burden than modifying that same code to conform to the > standard... since there are very few (if any) existing implementations > that already conform to the proposed standard. The UAC side of this > proposal is very easy to implement in either case. >=20 > I haven't seen any comments in this thread about how the re-use of > REGISTER for a different purpose would affect proxies in the route path; > if a proxy has to inspect option tags and header values to decide how to > route a request, that increases complexity as well, which is avoided if > the request uses a different method. >=20 > -- > Kevin P. Fleming From kpfleming@digium.com Wed Oct 28 08: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 127133A6918 for ; Wed, 28 Oct 2009 08:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.656 X-Spam-Level: X-Spam-Status: No, score=-104.656 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 84zObxAh5BZP for ; Wed, 28 Oct 2009 08:40:01 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id D19C63A68FA for ; Wed, 28 Oct 2009 08:40:01 -0700 (PDT) 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 1N3Ad6-0004P6-At for dispatch@ietf.org; Wed, 28 Oct 2009 10:40:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 69E7629E0002 for ; Wed, 28 Oct 2009 10:40:06 -0500 (CDT) 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 pfQgFjd+hZS5 for ; Wed, 28 Oct 2009 10:40:05 -0500 (CDT) Received: from [10.24.20.235] (kildare.digium.internal [10.24.20.235]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 9CB8029E0001 for ; Wed, 28 Oct 2009 10:40:05 -0500 (CDT) Message-ID: <4AE865D4.1000102@digium.com> Date: Wed, 28 Oct 2009 10:40:04 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: DISPATCH References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> <4AE84F28.3040008@digium.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 Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 28 Oct 2009 15:40:03 -0000 Hadriel Kaplan wrote: > The intent of the draft, and part of the rationale for using REGISTER in fact, is that it's processing is NOT different. It's not different on Proxies, and it's not different on UAC's other than adding that tag string. It's not even actually that different on UAS's - it's real "difference" to the UAS/Registrar is the logical Database it updates, and the key it uses to lookup in that database. While I can't claim to speak authoritatively on this, I would strongly suspect that an actual SSP accepting domain registration requests *would* want to route them differently through their proxies. I can also envision cases where SBCs and other network elements would enforce different policies for domain registrations vs. normal AoR registrations. > It's true that affecting a different database is a change for REGISTER. But if using a option-tag or header to indicate that is "more complex and harder to maintain" than using a new method name, then we're in real trouble. Because PUBLISH and SUBSCRIBE effectively do that with every different event package, without changing the method name, afaict. I believe the difference is because for PUBLISH/SUBSCRIBE, the proxy/SBC/UAS/etc. processing the request is less likely to need to enforce different security/authorization policies based on the event package requested than it would be for domain registrations vs. AoR registrations. -- 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 richard@shockey.us Wed Oct 28 09:28: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 00C4328C219 for ; Wed, 28 Oct 2009 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 WIkSElkLzUiq for ; Wed, 28 Oct 2009 09:27:59 -0700 (PDT) Received: from outbound-mail-111.bluehost.com (outbound-mail-111.bluehost.com [69.89.18.7]) by core3.amsl.com (Postfix) with SMTP id 4AF1E28C1ED for ; Wed, 28 Oct 2009 09:27:58 -0700 (PDT) Received: (qmail 31512 invoked by uid 0); 28 Oct 2009 16:28:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 28 Oct 2009 16:28:10 -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=mrI7J3HPzD7bh6fzGMJaKJ7gYr0CnIYjdZTH2KLSm9stjYPT0LjevqLpcrdtnH4g1sLJFfkze11igWxXV7hdGLTWksnahdBRnUNBx0noRTp3pGujRPyTcV+B0uPFRjif; Received: from armoursquare.rice.iit.edu ([64.131.110.238] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3BNZ-0001Vg-L9; Wed, 28 Oct 2009 10:28:09 -0600 From: "Richard Shockey" To: "'Kevin P. Fleming'" References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> <4AE84F28.3040008@digium.com> In-Reply-To: <4AE84F28.3040008@digium.com> Date: Wed, 28 Oct 2009 12:28:07 -0400 Message-ID: <001201ca57eb$a284be60$e78e3b20$@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: AcpX12sbyyMSpx2mQb+gsXWSGCGrcAAE9rdQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 64.131.110.238 authed with richard+shockey.us} Cc: 'DISPATCH' Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 28 Oct 2009 16:28:00 -0000 > > On the UAC side, I can't see how the need to take the existing > (pre-standard) code and modify it to use a new method name is going to > be any more burden than modifying that same code to conform to the > standard... since there are very few (if any) existing implementations > that already conform to the proposed standard. The UAC side of this > proposal is very easy to implement in either case. There are LOTS of implementations of the REGISTER procedure in place right now. The purpose of the proposed draft is to fix the interoperability problems in the field right now while permitting a larger investigation how the larger issues can be addressed. > > I haven't seen any comments in this thread about how the re-use of > REGISTER for a different purpose would affect proxies in the route > path; > if a proxy has to inspect option tags and header values to decide how > to > route a request, that increases complexity as well, which is avoided > if > the request uses a different method. > > -- > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Wed Oct 28 09:36: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 19F7A28C222 for ; Wed, 28 Oct 2009 09:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 GeV7Ve0yJOgt for ; Wed, 28 Oct 2009 09:35:59 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 55A8228C206 for ; Wed, 28 Oct 2009 09:35:59 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SGa7uZ028172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 11:36:09 -0500 Message-ID: <4AE872F1.90108@softarmor.com> Date: Wed, 28 Oct 2009 11:36:01 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> <4AE850B9.80607@cisco.com> In-Reply-To: <4AE850B9.80607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: anwars@avaya.com, dispatch@ietf.org, L.Liess@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 28 Oct 2009 16:36:00 -0000 Paul Kyzivat wrote: > > But that works more easily if the Alert-Info URNs are mutually > exclusive, so the recipient just chooses one it understands and renders > that. > > But I guess it can still work in the multi-dimensional approach. Each > URN that is understood must imply the values of one or more of those > dimensions. this is starting to sound like multipart/related and multipart/alternative. Perhaps we are barking up the wrong tree, and alerts should be body parts selected by a new content-disposition? -- dean From HKaplan@acmepacket.com Wed Oct 28 09:43: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 62F533A68AC for ; Wed, 28 Oct 2009 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 BCfuDGXJBL3p for ; Wed, 28 Oct 2009 09:43:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 860773A685E for ; Wed, 28 Oct 2009 09:43:25 -0700 (PDT) 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, 28 Oct 2009 12:43:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Oct 2009 12:43:37 -0400 From: Hadriel Kaplan To: "Kevin P. Fleming" Date: Wed, 28 Oct 2009 12:43:37 -0400 Thread-Topic: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method Thread-Index: AcpX5QDLSAnyzfSSThKcsj07uuIOcgABk3mg Message-ID: References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> <4AE84F28.3040008@digium.com> <4AE865D4.1000102@digium.com> In-Reply-To: <4AE865D4.1000102@digium.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 Cc: DISPATCH Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method 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, 28 Oct 2009 16:43:39 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Kevin P. Fleming > Sent: Wednesday, October 28, 2009 11:40 AM >=20 > While I can't claim to speak authoritatively on this, I would strongly > suspect that an actual SSP accepting domain registration requests > *would* want to route them differently through their proxies. I can also > envision cases where SBCs and other network elements would enforce > different policies for domain registrations vs. normal AoR registrations. Sure, some functions a B2BUA may do for domain-registrations may be differe= nt than for aor-registrations, which is why it would be nice to get an opti= on-tag (and possibly header), instead of just defining this as an implement= ation agreement outside of the IETF without any changes on the wire from ao= r-registrations.=20 =20 > I believe the difference is because for PUBLISH/SUBSCRIBE, the > proxy/SBC/UAS/etc. processing the request is less likely to need to > enforce different security/authorization policies based on the event > package requested than it would be for domain registrations vs. AoR > registrations. I can't speak for others, but as just one data-point, at least for my compa= ny's SBC's the event-packages in PUB/SUB/NOT do or can affect processing in= several ways. And I'm pretty sure that indeed the domain-registration dra= ft will require changes on our product for some features. That's one of th= e reasons I have the option-tag be in a Require header, so it fails if the = UAS or B2BUA (being a UAS) doesn't support it. But a "Proxy", i.e a 3261 Proxy, would not afaik. -hadriel From pkyzivat@cisco.com Wed Oct 28 10:34: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 D67663A6A45 for ; Wed, 28 Oct 2009 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 SY8F5pMCBBAy for ; Wed, 28 Oct 2009 10:34:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 686893A69A7 for ; Wed, 28 Oct 2009 10:34:19 -0700 (PDT) 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: ApoEACsd6EpAZnwN/2dsb2JhbADCQ5gxhD8E X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="65374996" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2009 17:34:31 +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 n9SHYUx1023191; Wed, 28 Oct 2009 17:34:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:34:29 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:34:29 -0400 Message-ID: <4AE880A4.3060702@cisco.com> Date: Wed, 28 Oct 2009 13:34:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> <4AE850B9.80607@cisco.com> <4AE872F1.90108@softarmor.com> In-Reply-To: <4AE872F1.90108@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 17:34:29.0777 (UTC) FILETIME=[E74E1010:01CA57F4] Cc: anwars@avaya.com, dispatch@ietf.org, L.Liess@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 28 Oct 2009 17:34:38 -0000 Dean Willis wrote: > Paul Kyzivat wrote: > >> But that works more easily if the Alert-Info URNs are mutually >> exclusive, so the recipient just chooses one it understands and renders >> that. >> >> But I guess it can still work in the multi-dimensional approach. Each >> URN that is understood must imply the values of one or more of those >> dimensions. > > this is starting to sound like multipart/related and multipart/alternative. > > Perhaps we are barking up the wrong tree, and alerts should be body > parts selected by a new content-disposition? Did you imply a smiley on this message? On the off chance that you did not, its important that it be possible for intermediaries to add the Alert-Info, which pretty much excludes using body parts. Thanks, Paul From mary.barnes@nortel.com Wed Oct 28 12:25: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 9291228C212 for ; Wed, 28 Oct 2009 12:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029, 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 XFmWk44E8Dtm for ; Wed, 28 Oct 2009 12:25:17 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C159328C215 for ; Wed, 28 Oct 2009 12:25:15 -0700 (PDT) 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 n9SJPQx04972; Wed, 28 Oct 2009 19:25:26 GMT 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_01CA5804.5A93A6CA" Date: Wed, 28 Oct 2009 14:26:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF20BA3FB9@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda for IETF-76 DISPATCH WG session including adhocs Thread-Index: AcpYBIW8d9URKan0ShKIxNHsFEnysw== From: "Mary Barnes" To: Subject: [dispatch] Draft agenda for IETF-76 DISPATCH WG session including adhocs 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, 28 Oct 2009 19:25:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5804.5A93A6CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have uploaded a draft agenda for the DISPATCH WG session in Hiroshima: http://www.ietf.org/proceedings/09nov/agenda/dispatch.html It is a very packed agenda. To optimize the WG session it would be extremely helpful for folks to review the relevant charters and documents and post any additional concerns that haven't been discussed on the mailing list prior to the WG session. =20 Please note the 3 adhocs planned - the details will be provided as soon as available.=20 Please let us know if you have any concerns about the agenda or see any errors in terms of presenters/primes on or before Friday, October 30th.=20 Regards, Mary and Gonzalo DISPATCH WG chairs ------_=_NextPart_001_01CA5804.5A93A6CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft agenda for IETF-76 DISPATCH WG session including = adhocs

Hi all,

I have uploaded a draft agenda for the = DISPATCH WG session in Hiroshima:
http://www.ietf.org/proceedings/09nov/agenda/dispatch.html=

It is a very packed agenda.  To = optimize the WG session it would be extremely helpful for folks to = review the relevant charters and documents and post any additional = concerns that haven't been discussed on the mailing list prior to the WG = session. 

Please note the 3 adhocs planned - the = details will be provided as soon as available.

Please let us know if you have any = concerns about the agenda or see any errors in terms of = presenters/primes on or before Friday, October 30th.

Regards,
Mary and Gonzalo
DISPATCH WG chairs

------_=_NextPart_001_01CA5804.5A93A6CA-- From dean.willis@softarmor.com Wed Oct 28 17:55: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 CAFFA3A690F for ; Wed, 28 Oct 2009 17:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 vvk+VUUwiFEY for ; Wed, 28 Oct 2009 17:55:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 09D7B3A686A for ; Wed, 28 Oct 2009 17:55:34 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9T0sHjO031292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 19:54:18 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <4AE880A4.3060702@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 19:54:11 -0500 References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> <4AE850B9.80607@cisco.com> <4AE872F1.90108@softarmor.com> <4AE880A4.3060702@cisco.com> X-Mailer: Apple Mail (2.936) Cc: anwars@avaya.com, dispatch@ietf.org, L.Liess@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 29 Oct 2009 00:55:35 -0000 On Oct 28, 2009, at 12:34 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> Paul Kyzivat wrote: >>> But that works more easily if the Alert-Info URNs are mutually >>> exclusive, so the recipient just chooses one it understands and >>> renders >>> that. >>> >>> But I guess it can still work in the multi-dimensional approach. >>> Each >>> URN that is understood must imply the values of one or more of those >>> dimensions. >> this is starting to sound like multipart/related and multipart/ >> alternative. >> Perhaps we are barking up the wrong tree, and alerts should be body >> parts selected by a new content-disposition? > > Did you imply a smiley on this message? > > On the off chance that you did not, its important that it be > possible for intermediaries to add the Alert-Info, which pretty much > excludes using body parts. Not if the intermediaries are B2BUAs. I'm wondering about alert-info and authentication. Perhaps anything that can change the alerting model really OUGHT to be a B2BUA and capable of re-authenticating the request. -- Dean From john.elwell@siemens-enterprise.com Thu Oct 29 00:03: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 2962E3A68E3 for ; Thu, 29 Oct 2009 00:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=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 2ELjEofxwwxI for ; Thu, 29 Oct 2009 00:03:54 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 0D6563A635F for ; Thu, 29 Oct 2009 00:03:53 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9T748l6002980; Thu, 29 Oct 2009 08:04:08 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9T748CM006400; Thu, 29 Oct 2009 08:04:08 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Thu, 29 Oct 2009 08:04:07 +0100 From: "Elwell, John" To: DISPATCH Date: Thu, 29 Oct 2009 08:04:27 +0100 Thread-Topic: Ad hoc on SIP Identity Thread-Index: AcpX2vt9cHhpdfZDRMWjdvBQGbbSjA== Message-ID: <7402509E63C5A145A6095D46C179A5B7148B37DF@DEMCHP99E35MSX.ww902.siemens.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Victor Pascual Subject: [dispatch] Ad hoc on SIP Identity 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, 29 Oct 2009 07:03:55 -0000 We have not asked for agenda time in DISPATCH, but in order to get things m= oving again we and the chairs are organizing an ad hoc DISPATCH meeting on = the subject, probably last session on Monday. This is in parallel with MEDI= ACTRL, but has the advantage of being before the DISPATCH meeting on Tuesda= y morning, so the chairs can report back. A definite announcement on this w= ill follow later. The purpose is to discuss next steps, so I would like people to propose ide= as, preferably on the list prior to the ad hoc. Our own thoughts are as follows: 1. http://tools.ietf.org/id/draft-elwell-dispatch-identity-reqs-01.txt has = received some feedback, suggesting it is heading in the right direction. So= at least we have some written requirements. Are these a good starting poin= t, or do we need to make substantial changes or go about it in a different = way? 2. We have several expired drafts proposing solutions. These can roughly be= categorised as: - reducing the amount of signed information (to avoid the need for breaking= the signature when changing information en route); - signing a copy of certain information, so that if the original informatio= n is changed en route, the signature is still valid and the copy of the ori= ginal information is still available); - performing a return routability check of some form. Are any of these a suitable basis for more work? Are there any other approa= ches? 3. It is recognised that there are difficulties with E.164 numbers, in the = sense of what a domain can assert about an E.164 number. However, since E.1= 64-based SIP URIs are by far the most common (for voice at least), we shoul= d try to do something with these. 4. There seems to be a consensus we can't do much about PSTN interworking. = The most we can do for a call from PSTN is to provide some authentication o= f the gateway that asserts the calling number (based on the assertion recei= ved from PSTN). John and Victor From Leon.Portman@nice.com Thu Oct 29 02:49: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 A9D023A6984 for ; Thu, 29 Oct 2009 02:49:25 -0700 (PDT) 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 E7Zr+3Y+3ezM for ; Thu, 29 Oct 2009 02:49:24 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 3B4C73A6993 for ; Thu, 29 Oct 2009 02:49:24 -0700 (PDT) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 29 Oct 2009 09:01:54 +0200 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 29 Oct 2009 09:01:54 +0200 From: Leon Portman To: "dispatch@ietf.org" Date: Thu, 29 Oct 2009 09:01:53 +0200 Thread-Topic: [dispatch] New version for draft-rehor-dispatch-session-recording-req-00.txt Thread-Index: AcpYZbHrfUCnaCONRbWSfaO4+bXKLw== Message-ID: <07465C1D981ABC41A344374066AE1A2C37D6A2FDD0@TLVMBX01.nice.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_07465C1D981ABC41A344374066AE1A2C37D6A2FDD0TLVMBX01nicec_" MIME-Version: 1.0 Cc: "'Rajnish.Jain@ipc.com'" , "'HKaplan@acmepacket.com'" , "'krehor@cisco.com'" Subject: [dispatch] New version for draft-rehor-dispatch-session-recording-req-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, 29 Oct 2009 09:49:25 -0000 --_000_07465C1D981ABC41A344374066AE1A2C37D6A2FDD0TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We just uploaded updated draft for Session Recording Protocol requirements = document (http://tools.ietf.org/html/draft-rehor-dispatch-session-recording= -req-00). We added use cases, architecture diagrams and some additional req= uirements. Please read and comment. Next step will be producing first draft of the protocol itself. Regards Leon --_000_07465C1D981ABC41A344374066AE1A2C37D6A2FDD0TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We ju= st uploaded updated draft for Session Recording Protocol requirements document= (http://tools.ietf.org/html/draft-rehor-dispatch-session-recording-re= q-00). We added use cases, architecture diagrams and some additional requirements.= Please read and comment.

Next = step will be producing first draft of  the protocol itself.

=  

Regar= ds

=  

Leon<= o:p>

=  

--_000_07465C1D981ABC41A344374066AE1A2C37D6A2FDD0TLVMBX01nicec_-- From pkyzivat@cisco.com Thu Oct 29 06:05: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 6979D3A696B for ; Thu, 29 Oct 2009 06:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 e3RYpkc5XTiP for ; Thu, 29 Oct 2009 06:05:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 53EB73A68D8 for ; Thu, 29 Oct 2009 06:05:00 -0700 (PDT) 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: ApoEAGQv6UpAZnwM/2dsb2JhbADEXZgXhD0E X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="65518651" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 13:05:16 +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 n9TD5FCb018577; Thu, 29 Oct 2009 13:05:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:05:15 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:05:15 -0400 Message-ID: <4AE9930A.3040204@cisco.com> Date: Thu, 29 Oct 2009 09:05:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> <4AE850B9.80607@cisco.com> <4AE872F1.90108@softarmor.com> <4AE880A4.3060702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 13:05:15.0293 (UTC) FILETIME=[74E52CD0:01CA5898] Cc: anwars@avaya.com, dispatch@ietf.org, L.Liess@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 29 Oct 2009 13:05:01 -0000 Dean Willis wrote: > > On Oct 28, 2009, at 12:34 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >>> Paul Kyzivat wrote: >>>> But that works more easily if the Alert-Info URNs are mutually >>>> exclusive, so the recipient just chooses one it understands and renders >>>> that. >>>> >>>> But I guess it can still work in the multi-dimensional approach. Each >>>> URN that is understood must imply the values of one or more of those >>>> dimensions. >>> this is starting to sound like multipart/related and >>> multipart/alternative. >>> Perhaps we are barking up the wrong tree, and alerts should be body >>> parts selected by a new content-disposition? >> >> Did you imply a smiley on this message? >> >> On the off chance that you did not, its important that it be possible >> for intermediaries to add the Alert-Info, which pretty much excludes >> using body parts. > > Not if the intermediaries are B2BUAs. I'm wondering about alert-info > and authentication. Perhaps anything that can change the alerting model > really OUGHT to be a B2BUA and capable of re-authenticating the request. My philosophy has always been that a UA must be very careful about trusting Alert-Info unless it is in an environment where something it trusts is doing screening for it. The URN approach helps with this, because then the UA is only using the URN as a key into a database of of alerts that the UA is willing to render. But even so, some care is required. For instance, the "internal" vs. "external" ring choice would not be very effective if an arbitrary caller could decide whether it was internal or external. If that decision isn't made by the UA itself, then it needs to be made by something it trusts. That doesn't *necessarily* mean that the screening server must be a B2BUA. It could be a proxy if used in a controlled topology. The "sip pbx" implementations I'm familiar with *are* B2BUAs, but I think some are not. Also, even without trust, some info inserted by intermediaries might be acceptable to a UA. For instance, a proxy in front of the callee might insert an Alert-Info in the 180 indicating that the call was coming from France, proposing a French ringback tone. The caller, if it is capable of understanding that, may be willing to render it that way even though it doesn't know the callee or have any particular trust in it. Thanks, Paul From alan@sipstation.com Thu Oct 29 06:47: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 556BE3A6864 for ; Thu, 29 Oct 2009 06:47:34 -0700 (PDT) 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 EEPFF8tk3Z-U for ; Thu, 29 Oct 2009 06:47:32 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 81C9D3A696B for ; Thu, 29 Oct 2009 06:47:32 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N3VLt-000L8P-Oo; Thu, 29 Oct 2009 13:47:46 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/DXMDIdNPKLDfzh7hxKCOGU1zzGfGVF3E= Message-ID: <4AE99CFE.9030205@sipstation.com> Date: Thu, 29 Oct 2009 08:47:42 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> In-Reply-To: <4ADFB028.3010604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de, anwars@avaya.com Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 29 Oct 2009 13:47:34 -0000 Paul, Thanks for your comments on the draft. See mine below. Thanks, Alan Paul Kyzivat wrote: > responses inline > > L.Liess@telekom.de wrote: >> Paul, >> Thank you very much for taking the time to look and comment the draft. >> After the changes we did shortly before the submission deadline, there >> are some inconsistecies and open items. We are aware of some of them and >> probably there are some we are not aware of. For the problems we are >> aware of, there are alternative solutions. In some cases, we did not >> have a clear opinion which way to go and we would like to hear others >> opinions. >> >> >> Please find comments inline: >> > > This seems to be shaping up well. I think the >> requirements are >> quite > clear now. >> >> It's good to hear that we have achieved at least a smal stepp in the >> right direction :-). > > I don't fully understand what is >> intended regarding >> combination of > multiple alert URNs for a specific situation. >> Section 4.5 >> states: >> > > > finally, a short Albanian auto-callback tone could be >> indicated >> > > Alert-Info: , >> > > , . >> > > while section 7.3.6 states: >> > > > Alert URN Indications from the same group should not be >> combined. >> >> >> >> To avoid the combinatorial explosion of IANA values as Adam pointed out >> in his comment >> http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html , we >> decided to abandon the usage of sub-indications for the use cases we >> have in the draft and to register only discrete tokens as top-level >> registrations. (With county-specidfic ring and busy tones, we almost >> got the problem Adam talked about.) The sub-indications are no longer >> used in the current version of the draft. > > So, maybe that is the confusion. I didn't understand that from reading > the text. > >> We thougt about changing the template in chapter 3 from >> alert-indication = top-level *("." sub-indication) >> top-level = let-dig [ *25let-dig-hyp let-dig ] >> sub-indication = let-dig [ *let-dig-hyp let-dig ] >> >> to just >> alert-indication= let-dig [ *let-dig-hyp let-dig ] >> >> But we are not sure if everyone would agree with this, so we would like >> to have feedback from the WG on this issue. > > I don't know yet. The alternative is apparently to have multiple URNs > and interpret the combination. I'm having difficulty imagining how > that would work. I have always assumed that in the end a URN would be > "looked up" locally by the UA and resolved to *something* that it > could render. > > I will keep an open mind, but I'll need a better explanation of how > multiple URNs are to be combined into *something* that can be looked up. > >> There is an inconcistency concerning the alert indications "priority", >> "short" and "delayed": In chapter 4, they are now top-level indications >> in the alert-category "service", therefore in the same group eith >> "auto-callback". In chapter 7 there is a dedicated group for them >> "Additional Indications for PBX-tones" in the "tones" alert-category. >> We must have to decide which alternative to take. If we decide for the >> chapter 4 alternative, we must change either the combination rule or the >> example you complained about. >> >> > I could find no definition of what constitutes a "group". The >> first > thing that comes to mind is "service" vs. "tone", but the >> > above example > violates that. It seems to me that you need >> some notion of >> orthogonal > properties in order to define what can/cannot be >> combined. >> >> It's true, it's quite impossible to guess from the text what I meant >> here. A group consists of the indications in one sub-chapter 7.3.1 to >> 7.3.5. I just looked for a way to avoid combinations of contradictory >> URNs, e.g. that is combined with >> or is combined with >> . If we agree that this kind of groups makes sense >> and we keep it, some definition needs to be added. But maybe there are >> better proposals in the WG about how to avoid combinations of >> contradictory indications? > > It seems like what you must be doing is replacing a hierarchy with an > N-dimensional matrix which is sparsely populated. That seems harder to > deal with. > Perhaps, or perhaps not. Remember that this is just a suggestion, rather than a command about a ring or ringback. It is perfectly reasonable for UAs to simply ignore the Alert-Info. So, the sparse scenario, where a server puts in as much information as possible, possibly via multiple URNs, and the UA uses the ones it knows and ignores the rest. >> > It would be good to have more detail about how a recipient >> > should deal > with multiple URNs. >> >> Yes. But I think we need to work in steps: >> -First we need to see if we have an aggreement on the new proposal >> about registering discrete tokens ("internal" and "priority" instead of >> "internal.priority"). -If this OK, we have to decide if we changed >> the template otr not. -We need, I think, some rules to avoid >> combinations of URNs which >> are obviously contradictory. > > I don't think that works. I can't evaluate whether the approach works > without a practical understanding of how it could be used. In the end > I have to render *something*. And I have to choose what that is. While > hierarchical names present a class of problems, its at least clear how > to resolve them to something I have. > >> > I'm also uncertain of what your intent is regarding top-level >> vs. > additional indications. As specified, I believe a given >> "additional > indication" name is always defined with regard to >> its parent, >> so that > "short" as used in "normal.short" might mean something >> entirely > different than "priority.short", or might not be >> defined for > priority at > all. >> >> We changed this in this version, see >> http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . If >> we do not agree on this change, we need another mean to avoid >> combinatorial explosion and the same time still being able to send >> country specific ringing tones, country specific busy tones and country >> specific whatever tones. > > I understand Adam's issue. I just don't (yet) understand how/if the > alternative works. > > It seems that what you propose is a multidimensional space, where > every point in that space is potentially rendered uniquely. But in > practice values will often be supplied for some but not all of the > dimensions. In that case we end up specifying some "slice" of the > array. I guess in this case you could look to see what you would > render for each point in the slice. If those are all identical, then > you are in good shape. But if they are not, then what? Do you pick one > of the points? That amounts to choosing a default value for each > unspecified dimension. Is that the right answer? > > I also understand that this approach works great if all the renderings > are audio, and each of the dimensions is an input to a synthesizer > algorithm. But that pretty much only works for audio. If you have to > render in user friendly text, or in flashes of light then it isn't > going to work very well. Nor does it work for audio if you want to use > unique sound clips for some or all of the cases. > >> > Yet from the registration text in 7.3.2 it sounds like the >> > intent is for > priority, short, and delayed to be defined >> for all pbx-tones. > If that is > the intent, then I don't >> think the existing text meets that >> intent. >> >> This should be achieved by sending two URNs, one from the group 7.3.1. >> "Indications for PBX-tones" and the second from the group 7.3.2. >> "Additional Indications for PBX-tones" e.g. >> and . >> > > I also wonder if the existing hierarchy will work well in >> > practice, or > if some other organization might not work >> better. For > instance, it might > be more convenient to >> specify ringing.fr with the clear >> understanding > that if you don't know about ringing.fr you can >> just treat it > as ringing. >> >> See above comments. >> >> > > I'm also confused by PBX tones vs. Public telephone >> tones. In > what way > is "normal" different from "ringing"? >> I would think that PBX > tones would > be a superset of >> common pstn tones. >> >> I think a PBX has ist own tones for normal, internal and external >> ringing, different from those of the public network. > > I have a sip pbx phone on my desk. I don't have any distinction for > internal vs. external, and have no clue how "normal" would be > different from one or the other of those. I don't really desire any > distinction on any of those terms. Remember, the use case for normal is driven by shared appearances - we want to insert an appearance number parameter into the Alert-Info but we do not want to convey any particular Alert, so we use normal as a no-op. > >> I would keep the two worlds disjunct. E.g. , I have a sip handy which is >> attached sometimes to the pbx and sometimes to my public carrier at >> home, I may want the pbx ringing tone to be different from the ringing >> tone at home. > > I don't really have any objection to a bunch of "names" for extra > arbitrary ring types. The real issue is deciding when to use one or > another. Is the assumption here that these will typically be inserted > by some agent acting on behalf of the phone acting on them, rather > than being inserted by "the other" party? IOW, *my* pbx decides that > an incoming call from you is "internal" or "external" and inserts a > suitable value by its policy, rather than *your* phone deciding the > call is internal or external and inserting the value that I then render. I wonder if some of the confusion we are having is because we are not cleanly separating ring tones from ringback tones. I'm going to think a bit how we would structure this if we had separate registries or trees for these. For instance, the country specification would only make sense for ringback tones. Also, things like priority would only apply to ring tones, etc. > > > It seems like you might have both models in mind. On one hand *my* pbx > is deciding if the call to me is internal or external, but the other > end is indicating it is a French phone rather than a US phone and so > at least ringback should be french. > Right, this is mixing ring tone and ringback tone in your example, so while this seems confusing, there is no actual confusion in practice. >> > A nit: in 4.3.2 I would expext the forward to be indicated, >> > if at all, > with a 181 rather than a 180. >> >> My understanding is that the URN should be transmitted in the 180 >> ringing after the forwarded call has reached ist final destination and >> the phone is ringing at the UE, not in the 181 sent by the forwarding >> proxy when it decides to to forward the call. Also the RFC 3261 only >> allows Alert-Info in 180 responses. Or did I miss something here? > > I checked, and you are right that A-I isn't allowed in 181. Sorry > about that. But it seems like a mistake to me. > > The behavior you describe requires there to be a stateful agent in the > network that is aware this has happened. In general there may be > nothing in a position to perform that role. But in any case it is a nit. > > Thanks, > Paul > >> Thanks a lot >> Laura >> >>> Thanks, >>> Paul >>> >>> L.Liess@telekom.de wrote: >>>> >>>> Hi, >>>> >>>> We've re-submitted the Alert-Info URNs draft for DISPATCH >>>> >>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert >>> -info-urns >>>> -00.txt . (The previous version od the draft was in BLISS >>> and we had a >>>> presentation in BLISS at the last IETF.) >>>> >>>> We did some major changes, as suggested on the mailing list, e.g.: >>>> Added: - Description of the interoperability problems for >>> PBX-services (in >>>> the Introduction chapter) - Requirements for the Alert-Info URNs >>>> mechanism - Alert-Info URNs Indications for country-specific tones >>>> Changed: - Initial IANA Registration mechanism to avoid >>> combinatorial explosion >>>> of IANA values. >>>> >>>> Many thanks for the comments and suggestions, >>>> Laura >>>> >>>> >>>> >>>> -----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, October 19, 2009 1:00 PM >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Alert-Info URNs for the Session Initiation >>>> Protocol (SIP) >>>> Author(s) : D. Alexeitsev, et al. >>>> Filename : draft-liess-dispatch-alert-info-urns-00.txt >>>> Pages : 25 >>>> Date : 2009-10-19 >>>> >>>> The Session Initiation Protocol (SIP) supports the capability to >>>> provide a reference to the alternative ringback tone (RBT) for >>>> caller, or ring tone (RT) for callee using the Alert-Info header. >>>> However, the reference addresses only the network resources with >>>> specific rendering properties. There is currently no support for >>>> predefined standard identifiers for ringback tones or semantic >>>> indications without tied rendering. To overcome this >>> limitations and >>>> support new applications a family of the URNs is defined in this >>>> specification. >>>> >>>> A URL for this Internet-Draft is: >>>> >>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert >>> -info-urns >>>> -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 alan@sipstation.com Thu Oct 29 06:53: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 DB63F3A6AAB; Thu, 29 Oct 2009 06:53:23 -0700 (PDT) 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 1OnRU4rZe97c; Thu, 29 Oct 2009 06:53:22 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 4461A3A6ABE; Thu, 29 Oct 2009 06:53:22 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N3VRY-000NDI-PA; Thu, 29 Oct 2009 13:53:37 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/FTsT9OAmwQtvk92kjRUO7cCsDirP1x8s= Message-ID: <4AE99E5E.9090801@sipstation.com> Date: Thu, 29 Oct 2009 08:53:34 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> In-Reply-To: <4ADCCF93.2070208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org, dispatch@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de, anwars@avaya.com Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 29 Oct 2009 13:53:24 -0000 Paul, One comment below. Thanks, Alan Paul Kyzivat wrote: > This seems to be shaping up well. I think the requirements are quite > clear now. > > I don't fully understand what is intended regarding combination of > multiple alert URNs for a specific situation. Section 4.5 states: > >> finally, a short Albanian auto-callback tone could be indicated >> Alert-Info: , >> , . > > while section 7.3.6 states: > >> Alert URN Indications from the same group should not be combined. > > I could find no definition of what constitutes a "group". The first > thing that comes to mind is "service" vs. "tone", but the above > example violates that. It seems to me that you need some notion of > orthogonal properties in order to define what can/cannot be combined. > > It would be good to have more detail about how a recipient should deal > with multiple URNs. > > I'm also uncertain of what your intent is regarding top-level vs. > additional indications. As specified, I believe a given "additional > indication" name is always defined with regard to its parent, so that > "short" as used in "normal.short" might mean something entirely > different than "priority.short", or might not be defined for priority > at all. > > Yet from the registration text in 7.3.2 it sounds like the intent is > for priority, short, and delayed to be defined for all pbx-tones. If > that is the intent, then I don't think the existing text meets that > intent. As it has been pointed out, short, long, and delayed are not compatible with the semantic approach of this draft so I think we should remove them as they are currently. I need to investigate to see whether they have been used in the past as stand-ins for a particular service, or whether we need to define specific tones for them. Priority, I still think, is useful - we just need to figure out how to fit it in properly. > > I also wonder if the existing hierarchy will work well in practice, or > if some other organization might not work better. For instance, it > might be more convenient to specify ringing.fr with the clear > understanding that if you don't know about ringing.fr you can just > treat it as ringing. > > I'm also confused by PBX tones vs. Public telephone tones. In what way > is "normal" different from "ringing"? I would think that PBX tones > would be a superset of common pstn tones. > > A nit: in 4.3.2 I would expext the forward to be indicated, if at all, > with a 181 rather than a 180. > > Thanks, > Paul > > L.Liess@telekom.de wrote: >> >> Hi, >> >> We've re-submitted the Alert-Info URNs draft for DISPATCH >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns >> -00.txt . (The previous version od the draft was in BLISS and we had a >> presentation in BLISS at the last IETF.) >> >> We did some major changes, as suggested on the mailing list, e.g.: >> Added: - Description of the interoperability problems for >> PBX-services (in >> the Introduction chapter) - Requirements for the Alert-Info URNs >> mechanism - Alert-Info URNs Indications for country-specific tones >> Changed: - Initial IANA Registration mechanism to avoid >> combinatorial explosion >> of IANA values. >> >> Many thanks for the comments and suggestions, >> Laura >> >> >> >> -----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, October 19, 2009 1:00 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Alert-Info URNs for the Session Initiation >> Protocol (SIP) >> Author(s) : D. Alexeitsev, et al. >> Filename : draft-liess-dispatch-alert-info-urns-00.txt >> Pages : 25 >> Date : 2009-10-19 >> >> The Session Initiation Protocol (SIP) supports the capability to >> provide a reference to the alternative ringback tone (RBT) for >> caller, or ring tone (RT) for callee using the Alert-Info header. >> However, the reference addresses only the network resources with >> specific rendering properties. There is currently no support for >> predefined standard identifiers for ringback tones or semantic >> indications without tied rendering. To overcome this limitations and >> support new applications a family of the URNs is defined in this >> specification. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns >> -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 >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From audet.francois@gmail.com Thu Oct 29 06:58: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 267BA3A6883 for ; Thu, 29 Oct 2009 06:58:37 -0700 (PDT) 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 X26fYQZuqU2i for ; Thu, 29 Oct 2009 06:58:35 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by core3.amsl.com (Postfix) with ESMTP id CD62A3A6AC8 for ; Thu, 29 Oct 2009 06:58:34 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so275382gvc.15 for ; Thu, 29 Oct 2009 06:58:47 -0700 (PDT) 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=xmjKLVJmcQjmwp29jMeeDVudwSx5/M1ZYQvoE+iu45s=; b=rReeuBXAGIFvvNsGGM/DbpD5IrByHk1Iolzttehn+KKOqIU/WXbrAsIxJuTm8Hjvrf y+08CyO6l6A3+CLdKdih0jissfQ0jj8QnQwGnXQPh7z4nQyD4TprzdUC+dehes3kkKMm RP1P7zslgiy7FgXJdlOgQl4OaVbayy/DN+jB8= 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=gdfpHKkCQOcTRGIo7fzD7VmOy4VuGPkDUiUJlNCLCMGN9E1d7NBXySG55TLyg9lpWb 5ZIRVyKaN0/4A2hwx5XoKFWavXAwJZyVBZBsjx4/3avjraxn6JrK1zg538EDT/dlEEGf UbltbMnfN01YT0lcETuNScYul4ZzVSs9dqVy4= Received: by 10.103.64.19 with SMTP id r19mr48071muk.8.1256824727003; Thu, 29 Oct 2009 06:58:47 -0700 (PDT) Received: from ?192.168.15.102? (adsl-75-52-254-50.dsl.pltn13.sbcglobal.net [75.52.254.50]) by mx.google.com with ESMTPS id i5sm3836473mue.38.2009.10.29.06.58.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 06:58:45 -0700 (PDT) References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <4AE99CFE.9030205@sipstation.com> Message-Id: <5147C5BC-C186-4CFB-A604-F0FAF0162465@gmail.com> From: Francois AUDET To: Alan Johnston In-Reply-To: <4AE99CFE.9030205@sipstation.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: Thu, 29 Oct 2009 06:58:36 -0700 Cc: "anwars@avaya.com" , "dispatch@ietf.org" , "L.Liess@telekom.de" , "R.Jesske@telekom.de" Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 29 Oct 2009 13:58:37 -0000 What about reverting the tree order, so that you put the country id last, so you can ignore it if you don't care? Urn:tones.alerting.Albanian On Oct 29, 2009, at 6:47, Alan Johnston wrote: > Paul, > > Thanks for your comments on the draft. See mine below. > > Thanks, > Alan > > > Paul Kyzivat wrote: >> responses inline >> >> L.Liess@telekom.de wrote: >>> Paul, >>> Thank you very much for taking the time to look and comment the >>> draft. >>> After the changes we did shortly before the submission deadline, >>> there >>> are some inconsistecies and open items. We are aware of some of >>> them and >>> probably there are some we are not aware of. For the problems we are >>> aware of, there are alternative solutions. In some cases, we did not >>> have a clear opinion which way to go and we would like to hear >>> others >>> opinions. >>> >>> >>> Please find comments inline: >>> > > This seems to be shaping up well. I think the >>> requirements are >>> quite > clear now. >>> >>> It's good to hear that we have achieved at least a smal stepp in the >>> right direction :-). > > I don't fully understand what >>> is intended regarding >>> combination of > multiple alert URNs for a specific situation. >>> Section 4.5 >>> states: >>> > > > finally, a short Albanian auto-callback tone could >>> be >>> indicated >>> > > Alert-Info: , >>> > > , . >>> > > while section 7.3.6 states: >>> > > > Alert URN Indications from the same group should >>> not be >>> combined. >>> >>> >>> >>> To avoid the combinatorial explosion of IANA values as Adam >>> pointed out >>> in his comment >>> http://www.ietf.org/mail-archive/web/bliss/current/ >>> msg01027.html , we >>> decided to abandon the usage of sub-indications for the use cases >>> we >>> have in the draft and to register only discrete tokens as top-level >>> registrations. (With county-specidfic ring and busy tones, we >>> almost >>> got the problem Adam talked about.) The sub-indications are no >>> longer >>> used in the current version of the draft. >> >> So, maybe that is the confusion. I didn't understand that from >> reading the text. >> >>> We thougt about changing the template in chapter 3 from >>> alert-indication = top-level *("." sub-indication) >>> top-level = let-dig [ *25let-dig-hyp let-dig ] >>> sub-indication = let-dig [ *let-dig-hyp let-dig ] >>> >>> to just >>> alert-indication= let-dig [ *let-dig-hyp let-dig ] >>> >>> But we are not sure if everyone would agree with this, so we would >>> like >>> to have feedback from the WG on this issue. >> >> I don't know yet. The alternative is apparently to have multiple >> URNs and interpret the combination. I'm having difficulty imagining >> how that would work. I have always assumed that in the end a URN >> would be "looked up" locally by the UA and resolved to *something* >> that it could render. >> >> I will keep an open mind, but I'll need a better explanation of how >> multiple URNs are to be combined into *something* that can be >> looked up. >> >>> There is an inconcistency concerning the alert indications >>> "priority", >>> "short" and "delayed": In chapter 4, they are now top-level >>> indications >>> in the alert-category "service", therefore in the same group eith >>> "auto-callback". In chapter 7 there is a dedicated group for >>> them >>> "Additional Indications for PBX-tones" in the "tones" alert- >>> category. >>> We must have to decide which alternative to take. If we decide for >>> the >>> chapter 4 alternative, we must change either the combination rule >>> or the >>> example you complained about. >>> >>> > I could find no definition of what constitutes a "group". The >>> first > thing that comes to mind is "service" vs. "tone", but >>> the > above example > violates that. It seems to me that >>> you need some notion of >>> orthogonal > properties in order to define what can/cannot be >>> combined. >>> >>> It's true, it's quite impossible to guess from the text what I meant >>> here. A group consists of the indications in one sub-chapter 7.3.1 >>> to >>> 7.3.5. I just looked for a way to avoid combinations of >>> contradictory >>> URNs, e.g. that is combined with >>> or is combined with >>> . If we agree that this kind of groups makes >>> sense >>> and we keep it, some definition needs to be added. But maybe >>> there are >>> better proposals in the WG about how to avoid combinations of >>> contradictory indications? >> >> It seems like what you must be doing is replacing a hierarchy with >> an N-dimensional matrix which is sparsely populated. That seems >> harder to deal with. >> > > Perhaps, or perhaps not. Remember that this is just a suggestion, > rather than a command about a ring or ringback. It is perfectly > reasonable for UAs to simply ignore the Alert-Info. So, the sparse > scenario, where a server puts in as much information as possible, > possibly via multiple URNs, and the UA uses the ones it knows and > ignores the rest. > >>> > It would be good to have more detail about how a >>> recipient > should deal > with multiple URNs. >>> >>> Yes. But I think we need to work in steps: >>> -First we need to see if we have an aggreement on the new proposal >>> about registering discrete tokens ("internal" and "priority" >>> instead of >>> "internal.priority"). -If this OK, we have to decide if we >>> changed the template otr not. -We need, I think, some rules to >>> avoid combinations of URNs which >>> are obviously contradictory. >> >> I don't think that works. I can't evaluate whether the approach >> works without a practical understanding of how it could be used. In >> the end I have to render *something*. And I have to choose what >> that is. While hierarchical names present a class of problems, its >> at least clear how to resolve them to something I have. >> >>> > I'm also uncertain of what your intent is regarding top-level >>> vs. > additional indications. As specified, I believe a given >>> "additional > indication" name is always defined with regard >>> to its parent, >>> so that > "short" as used in "normal.short" might mean something >>> entirely > different than "priority.short", or might not be >>> defined for > priority at > all. >>> >>> We changed this in this version, see >>> http://www.ietf.org/mail-archive/web/bliss/current/ >>> msg01027.html . If >>> we do not agree on this change, we need another mean to avoid >>> combinatorial explosion and the same time still being able to send >>> country specific ringing tones, country specific busy tones and >>> country >>> specific whatever tones. >> >> I understand Adam's issue. I just don't (yet) understand how/if the >> alternative works. >> >> It seems that what you propose is a multidimensional space, where >> every point in that space is potentially rendered uniquely. But in >> practice values will often be supplied for some but not all of the >> dimensions. In that case we end up specifying some "slice" of the >> array. I guess in this case you could look to see what you would >> render for each point in the slice. If those are all identical, >> then you are in good shape. But if they are not, then what? Do you >> pick one of the points? That amounts to choosing a default value >> for each unspecified dimension. Is that the right answer? >> >> I also understand that this approach works great if all the >> renderings are audio, and each of the dimensions is an input to a >> synthesizer algorithm. But that pretty much only works for audio. >> If you have to render in user friendly text, or in flashes of light >> then it isn't going to work very well. Nor does it work for audio >> if you want to use unique sound clips for some or all of the cases. >> >>> > Yet from the registration text in 7.3.2 it sounds like >>> the > intent is for > priority, short, and delayed to be >>> defined for all pbx-tones. > If that is > the intent, then >>> I don't think the existing text meets that >>> intent. >>> >>> This should be achieved by sending two URNs, one from the group >>> 7.3.1. >>> "Indications for PBX-tones" and the second from the group 7.3.2. >>> "Additional Indications for PBX-tones" e.g. >>> >>> and . > > I also wonder if the >>> existing hierarchy will work well in > practice, or > if >>> some other organization might not work better. For > instance, >>> it might > be more convenient to specify ringing.fr with the >>> clear >>> understanding > that if you don't know about ringing.fr you >>> can just treat it > as ringing. >>> >>> See above comments. >>> >>> > > I'm also confused by PBX tones vs. Public telephone >>> tones. In > what way > is "normal" different from >>> "ringing"? I would think that PBX > tones would > be a >>> superset of common pstn tones. >>> >>> I think a PBX has ist own tones for normal, internal and external >>> ringing, different from those of the public network. >> >> I have a sip pbx phone on my desk. I don't have any distinction for >> internal vs. external, and have no clue how "normal" would be >> different from one or the other of those. I don't really desire any >> distinction on any of those terms. > > Remember, the use case for normal is driven by shared appearances - > we want to insert an appearance number parameter into the Alert-Info > but we do not want to convey any particular Alert, so we use normal > as a no-op. > >> >>> I would keep the two worlds disjunct. E.g. , I have a sip handy >>> which is >>> attached sometimes to the pbx and sometimes to my public carrier at >>> home, I may want the pbx ringing tone to be different from the >>> ringing >>> tone at home. >> >> I don't really have any objection to a bunch of "names" for extra >> arbitrary ring types. The real issue is deciding when to use one or >> another. Is the assumption here that these will typically be >> inserted by some agent acting on behalf of the phone acting on >> them, rather than being inserted by "the other" party? IOW, *my* >> pbx decides that an incoming call from you is "internal" or >> "external" and inserts a suitable value by its policy, rather than >> *your* phone deciding the call is internal or external and >> inserting the value that I then render. > > I wonder if some of the confusion we are having is because we are > not cleanly separating ring tones from ringback tones. I'm going to > think a bit how we would structure this if we had separate > registries or trees for these. For instance, the country > specification would only make sense for ringback tones. Also, > things like priority would only apply to ring tones, etc. > >> >> >> It seems like you might have both models in mind. On one hand *my* >> pbx is deciding if the call to me is internal or external, but the >> other end is indicating it is a French phone rather than a US phone >> and so at least ringback should be french. >> > > Right, this is mixing ring tone and ringback tone in your example, > so while this seems confusing, there is no actual confusion in > practice. > >>> > A nit: in 4.3.2 I would expext the forward to be >>> indicated, > if at all, > with a 181 rather than a 180. >>> >>> My understanding is that the URN should be transmitted in the 180 >>> ringing after the forwarded call has reached ist final destination >>> and >>> the phone is ringing at the UE, not in the 181 sent by the >>> forwarding >>> proxy when it decides to to forward the call. Also the RFC 3261 only >>> allows Alert-Info in 180 responses. Or did I miss something here? >> >> I checked, and you are right that A-I isn't allowed in 181. Sorry >> about that. But it seems like a mistake to me. >> >> The behavior you describe requires there to be a stateful agent in >> the network that is aware this has happened. In general there may >> be nothing in a position to perform that role. But in any case it >> is a nit. >> >> Thanks, >> Paul >> >>> Thanks a lot >>> Laura >>> >>>> Thanks, >>>> Paul >>>> >>>> L.Liess@telekom.de wrote: >>>>> Hi, >>>>> >>>>> We've re-submitted the Alert-Info URNs draft for DISPATCH >>>>> >>>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert >>>> -info-urns >>>>> -00.txt . (The previous version od the draft was in BLISS >>>> and we had a >>>>> presentation in BLISS at the last IETF.) >>>>> >>>>> We did some major changes, as suggested on the mailing list, e.g.: >>>>> Added: - Description of the interoperability problems for >>>> PBX-services (in >>>>> the Introduction chapter) - Requirements for the Alert-Info >>>>> URNs mechanism - Alert-Info URNs Indications for country- >>>>> specific tones >>>>> Changed: - Initial IANA Registration mechanism to avoid >>>> combinatorial explosion >>>>> of IANA values. >>>>> >>>>> Many thanks for the comments and suggestions, >>>>> Laura >>>>> >>>>> >>>>> -----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, October 19, 2009 1:00 PM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : Alert-Info URNs for the Session Initiation >>>>> Protocol (SIP) >>>>> Author(s) : D. Alexeitsev, et al. >>>>> Filename : draft-liess-dispatch-alert-info-urns-00.txt >>>>> Pages : 25 >>>>> Date : 2009-10-19 >>>>> >>>>> The Session Initiation Protocol (SIP) supports the capability to >>>>> provide a reference to the alternative ringback tone (RBT) for >>>>> caller, or ring tone (RT) for callee using the Alert-Info header. >>>>> However, the reference addresses only the network resources with >>>>> specific rendering properties. There is currently no support for >>>>> predefined standard identifiers for ringback tones or semantic >>>>> indications without tied rendering. To overcome this >>>> limitations and >>>>> support new applications a family of the URNs is defined in this >>>>> specification. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert >>>> -info-urns >>>>> -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 >>>>> >>> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu Oct 29 08:11: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 A01D83A6955 for ; Thu, 29 Oct 2009 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 jN6zSi3k1qQa for ; Thu, 29 Oct 2009 08:11:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 019533A6942 for ; Thu, 29 Oct 2009 08:11:38 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ5N6UqrR7H+/2dsb2JhbADGG5gThD0E X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="199860695" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2009 15:11:55 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TFBkRa010873; Thu, 29 Oct 2009 15:11:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:11:54 -0400 Received: from [161.44.182.250] ([161.44.182.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:11:54 -0400 Message-ID: <4AE9B0BA.7080008@cisco.com> Date: Thu, 29 Oct 2009 11:11:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Francois AUDET References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <4AE99CFE.9030205@sipstation.com> <5147C5BC-C186-4CFB-A604-F0FAF0162465@gmail.com> In-Reply-To: <5147C5BC-C186-4CFB-A604-F0FAF0162465@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 15:11:54.0483 (UTC) FILETIME=[265D8C30:01CA58AA] Cc: "anwars@avaya.com" , "dispatch@ietf.org" , "L.Liess@telekom.de" , "R.Jesske@telekom.de" Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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, 29 Oct 2009 15:11:39 -0000 Francois AUDET wrote: > What about reverting the tree order, so that you put the country id > last, so you can ignore it if you don't care? > > Urn:tones.alerting.Albanian Yeah, that had occurred to me. But I think Adam's point was that you can find other orderings that make more sense in other contexts: URN:tones.alerting.Albanian.short vs. URN:tones.alerting.short.Albanian It may actually be the case that a combination of a hierarchy for some things, and independent values (dimensions) for other things might work out. But I'm just thinking out loud. Thanks, Paul From L.Liess@telekom.de Fri Oct 30 08:34: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 BB3CA3A67B6 for ; Fri, 30 Oct 2009 08:34:44 -0700 (PDT) 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 K7QpRQ4QpQ8L for ; Fri, 30 Oct 2009 08:34:42 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id E20373A6782 for ; Fri, 30 Oct 2009 08:34:41 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 30 Oct 2009 16:34:52 +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); Fri, 30 Oct 2009 16:34:51 +0100 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, 30 Oct 2009 16:34:51 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00393B27D@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4AE99CFE.9030205@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: AcpYnm/62RAELIkdSJeUiJ+K5UcWVgA1LXqA References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <4AE99CFE.9030205@sipstation.com> From: To: X-OriginalArrivalTime: 30 Oct 2009 15:34:51.0856 (UTC) FILETIME=[85C1BD00:01CA5976] Cc: dispatch@ietf.org, anwars@avaya.com, R.Jesske@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-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: Fri, 30 Oct 2009 15:34:44 -0000 Alan, > I wonder if some of the confusion we are having is because we are not=20 > cleanly separating ring tones from ringback tones.=20 I fully agree with you. =20 What about defining a 3rd alert-category "ringback-tone" and register the country-codes only for this ()? And maybe rename the alert-category "tone" in "ring-tone" ? A "ring-tone" URN is only sent in INVITE, a "ringback-tone" URN is only sent in a 180 Ringing. =20 Or is something wrong with this?=20 Thanks a lot Laura =20 > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com]=20 > Sent: Thursday, October 29, 2009 2:48 PM > To: Paul Kyzivat > Cc: Liess, Laura; john.elwell@siemens-enterprise.com;=20 > dispatch@ietf.org; anwars@avaya.com; Jesske, Roland > Subject: Re: [dispatch] New version for the Alert-Info URNs=20 > draft: draft-liess-dispatch-alert-info-urns-00.txt >=20 > Paul, >=20 > Thanks for your comments on the draft. See mine below. >=20 > Thanks, > Alan >=20 >=20 > Paul Kyzivat wrote: > > responses inline > > > > L.Liess@telekom.de wrote: > >> Paul, > >> Thank you very much for taking the time to look and=20 > comment the draft. > >> After the changes we did shortly before the submission=20 > deadline, there > >> are some inconsistecies and open items. We are aware of=20 > some of them and > >> probably there are some we are not aware of. For the=20 > problems we are > >> aware of, there are alternative solutions. In some cases,=20 > we did not > >> have a clear opinion which way to go and we would like to=20 > hear others > >> opinions. > >> > >> > >> Please find comments inline: > >> > > This seems to be shaping up well. I think the=20 > >> requirements are > >> quite > clear now. > >> > >> It's good to hear that we have achieved at least a smal=20 > stepp in the > >> right direction :-). > > I don't fully=20 > understand what is=20 > >> intended regarding > >> combination of > multiple alert URNs for a specific situation.=20 > >> Section 4.5 > >> states: > >> > > > finally, a short Albanian auto-callback=20 > tone could be > >> indicated > >> > > Alert-Info: , > >> > > , . > >> > > while section 7.3.6 states: > >> > > > Alert URN Indications from the same group=20 > should not be > >> combined. > >> > >> > >> > >> To avoid the combinatorial explosion of IANA values as=20 > Adam pointed out > >> in his comment > >>=20 > http://www.ietf.org/mail-archive/web/bliss/current/msg01027.ht > ml , we > >> decided to abandon the usage of sub-indications for the=20 > use cases we > >> have in the draft and to register only discrete tokens as top-level > >> registrations. (With county-specidfic ring and busy=20 > tones, we almost > >> got the problem Adam talked about.) The sub-indications=20 > are no longer > >> used in the current version of the draft.=20 > > > > So, maybe that is the confusion. I didn't understand that=20 > from reading=20 > > the text. > > > >> We thougt about changing the template in chapter 3 from > >> alert-indication =3D top-level *("." = sub-indication) > >> top-level =3D let-dig [ *25let-dig-hyp let-dig ] > >> sub-indication =3D let-dig [ *let-dig-hyp let-dig ] > >> > >> to just > >> alert-indication=3D let-dig [ *let-dig-hyp let-dig ] > >> > >> But we are not sure if everyone would agree with this, so=20 > we would like > >> to have feedback from the WG on this issue. =20 > > > > I don't know yet. The alternative is apparently to have=20 > multiple URNs=20 > > and interpret the combination. I'm having difficulty imagining how=20 > > that would work. I have always assumed that in the end a=20 > URN would be=20 > > "looked up" locally by the UA and resolved to *something* that it=20 > > could render. > > > > I will keep an open mind, but I'll need a better explanation of how=20 > > multiple URNs are to be combined into *something* that can=20 > be looked up. > > > >> There is an inconcistency concerning the alert indications=20 > "priority", > >> "short" and "delayed": In chapter 4, they are now =20 > top-level indications > >> in the alert-category "service", therefore in the same group eith > >> "auto-callback". In chapter 7 there is a dedicated=20 > group for them > >> "Additional Indications for PBX-tones" in the "tones"=20 > alert-category. > >> We must have to decide which alternative to take. If we=20 > decide for the > >> chapter 4 alternative, we must change either the=20 > combination rule or the > >> example you complained about. > >> > >> > I could find no definition of what constitutes a "group". The > >> first > thing that comes to mind is "service" vs.=20 > "tone", but the=20 > >> > above example > violates that. It seems to me=20 > that you need=20 > >> some notion of > >> orthogonal > properties in order to define what can/cannot be=20 > >> combined. > >> > >> It's true, it's quite impossible to guess from the text=20 > what I meant > >> here. A group consists of the indications in one=20 > sub-chapter 7.3.1 to > >> 7.3.5. I just looked for a way to avoid combinations of=20 > contradictory > >> URNs, e.g. that is combined with > >> or is=20 > combined with > >> . If we agree that this kind of=20 > groups makes sense > >> and we keep it, some definition needs to be added. But=20 > maybe there are > >> better proposals in the WG about how to avoid combinations of > >> contradictory indications? > > > > It seems like what you must be doing is replacing a=20 > hierarchy with an=20 > > N-dimensional matrix which is sparsely populated. That=20 > seems harder to=20 > > deal with. > > >=20 > Perhaps, or perhaps not. Remember that this is just a suggestion,=20 > rather than a command about a ring or ringback. It is perfectly=20 > reasonable for UAs to simply ignore the Alert-Info. So, the sparse=20 > scenario, where a server puts in as much information as possible,=20 > possibly via multiple URNs, and the UA uses the ones it knows and=20 > ignores the rest. >=20 > >> > It would be good to have more detail about how a recipient=20 > >> > should deal > with multiple URNs. > >> > >> Yes. But I think we need to work in steps: > >> -First we need to see if we have an aggreement on the=20 > new proposal > >> about registering discrete tokens ("internal" and=20 > "priority" instead of > >> "internal.priority"). -If this OK, we have to decide if=20 > we changed=20 > >> the template otr not. -We need, I think, some rules to avoid=20 > >> combinations of URNs which > >> are obviously contradictory. =20 > > > > I don't think that works. I can't evaluate whether the=20 > approach works=20 > > without a practical understanding of how it could be used.=20 > In the end=20 > > I have to render *something*. And I have to choose what=20 > that is. While=20 > > hierarchical names present a class of problems, its at=20 > least clear how=20 > > to resolve them to something I have. > > > >> > I'm also uncertain of what your intent is regarding top-level > >> vs. > additional indications. As specified, I believe a given > >> "additional > indication" name is always defined with=20 > regard to=20 > >> its parent, > >> so that > "short" as used in "normal.short" might mean=20 > something > >> entirely > different than "priority.short", or might not be=20 > >> defined for > priority at > all. > >> > >> We changed this in this version, see > >>=20 > http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . If > >> we do not agree on this change, we need another mean to avoid > >> combinatorial explosion and the same time still being able to send > >> country specific ringing tones, country specific busy=20 > tones and country > >> specific whatever tones. =20 > > > > I understand Adam's issue. I just don't (yet) understand how/if the=20 > > alternative works. > > > > It seems that what you propose is a multidimensional space, where=20 > > every point in that space is potentially rendered uniquely. But in=20 > > practice values will often be supplied for some but not all of the=20 > > dimensions. In that case we end up specifying some "slice" of the=20 > > array. I guess in this case you could look to see what you would=20 > > render for each point in the slice. If those are all=20 > identical, then=20 > > you are in good shape. But if they are not, then what? Do=20 > you pick one=20 > > of the points? That amounts to choosing a default value for each=20 > > unspecified dimension. Is that the right answer? > > > > I also understand that this approach works great if all the=20 > renderings=20 > > are audio, and each of the dimensions is an input to a synthesizer=20 > > algorithm. But that pretty much only works for audio. If=20 > you have to=20 > > render in user friendly text, or in flashes of light then it isn't=20 > > going to work very well. Nor does it work for audio if you=20 > want to use=20 > > unique sound clips for some or all of the cases. > > > >> > Yet from the registration text in 7.3.2 it sounds like the=20 > >> > intent is for > priority, short, and delayed to=20 > be defined=20 > >> for all pbx-tones. > If that is > the intent, then I don't=20 > >> think the existing text meets that > >> intent. > >> > >> This should be achieved by sending two URNs, one from the=20 > group 7.3.1. > >> "Indications for PBX-tones" and the second from the group 7.3.2. > >> "Additional Indications for PBX-tones" e.g. =20 > > >> and .=20 > >> > > I also wonder if the existing hierarchy will=20 > work well in=20 > >> > practice, or > if some other organization might not work=20 > >> better. For > instance, it might > be more convenient to=20 > >> specify ringing.fr with the clear > >> understanding > that if you don't know about=20 > ringing.fr you can=20 > >> just treat it > as ringing. > >> > >> See above comments. > >> > >> > > I'm also confused by PBX tones vs. Public telephone=20 > >> tones. In > what way > is "normal" different from=20 > "ringing"?=20 > >> I would think that PBX > tones would > be a superset of=20 > >> common pstn tones. > >> > >> I think a PBX has ist own tones for normal, internal and external > >> ringing, different from those of the public network.=20 > > > > I have a sip pbx phone on my desk. I don't have any distinction for=20 > > internal vs. external, and have no clue how "normal" would be=20 > > different from one or the other of those. I don't really desire any=20 > > distinction on any of those terms. >=20 > Remember, the use case for normal is driven by shared=20 > appearances - we=20 > want to insert an appearance number parameter into the=20 > Alert-Info but we=20 > do not want to convey any particular Alert, so we use normal=20 > as a no-op. >=20 > > > >> I would keep the two worlds disjunct. E.g. , I have a sip=20 > handy which is > >> attached sometimes to the pbx and sometimes to my public carrier at > >> home, I may want the pbx ringing tone to be different from=20 > the ringing > >> tone at home.=20 > > > > I don't really have any objection to a bunch of "names" for extra=20 > > arbitrary ring types. The real issue is deciding when to use one or=20 > > another. Is the assumption here that these will typically=20 > be inserted=20 > > by some agent acting on behalf of the phone acting on them, rather=20 > > than being inserted by "the other" party? IOW, *my* pbx=20 > decides that=20 > > an incoming call from you is "internal" or "external" and inserts a=20 > > suitable value by its policy, rather than *your* phone deciding the=20 > > call is internal or external and inserting the value that I=20 > then render. >=20 > I wonder if some of the confusion we are having is because we are not=20 > cleanly separating ring tones from ringback tones. I'm going=20 > to think a=20 > bit how we would structure this if we had separate registries=20 > or trees=20 > for these. For instance, the country specification would only make=20 > sense for ringback tones. Also, things like priority would=20 > only apply=20 > to ring tones, etc. >=20 > > > > > > It seems like you might have both models in mind. On one=20 > hand *my* pbx=20 > > is deciding if the call to me is internal or external, but=20 > the other=20 > > end is indicating it is a French phone rather than a US=20 > phone and so=20 > > at least ringback should be french. > > >=20 > Right, this is mixing ring tone and ringback tone in your example, so=20 > while this seems confusing, there is no actual confusion in practice. >=20 > >> > A nit: in 4.3.2 I would expext the forward to be indicated,=20 > >> > if at all, > with a 181 rather than a 180. > >> > >> My understanding is that the URN should be transmitted in the 180 > >> ringing after the forwarded call has reached ist final=20 > destination and > >> the phone is ringing at the UE, not in the 181 sent by the=20 > forwarding > >> proxy when it decides to to forward the call. Also the RFC=20 > 3261 only > >> allows Alert-Info in 180 responses. Or did I miss something here? > > > > I checked, and you are right that A-I isn't allowed in 181. Sorry=20 > > about that. But it seems like a mistake to me. > > > > The behavior you describe requires there to be a stateful=20 > agent in the=20 > > network that is aware this has happened. In general there may be=20 > > nothing in a position to perform that role. But in any case=20 > it is a nit. > > > > Thanks, > > Paul > > > >> Thanks a lot > >> Laura > >> > >>> Thanks, > >>> Paul > >>> > >>> L.Liess@telekom.de wrote: > >>>> =20 > >>>> Hi, > >>>> > >>>> We've re-submitted the Alert-Info URNs draft for DISPATCH > >>>> > >>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > >>> -info-urns > >>>> -00.txt . (The previous version od the draft was in BLISS=20 > >>> and we had a > >>>> presentation in BLISS at the last IETF.) > >>>> > >>>> We did some major changes, as suggested on the mailing=20 > list, e.g.: > >>>> Added: - Description of the interoperability problems for=20 > >>> PBX-services (in > >>>> the Introduction chapter) - Requirements for the=20 > Alert-Info URNs=20 > >>>> mechanism - Alert-Info URNs Indications for=20 > country-specific tones > >>>> Changed: - Initial IANA Registration mechanism to avoid=20 > >>> combinatorial explosion > >>>> of IANA values. > >>>> > >>>> Many thanks for the comments and suggestions, > >>>> Laura > >>>> > >>>> > >>>> =20 > >>>> -----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, October 19, 2009 1:00 PM > >>>> To: i-d-announce@ietf.org > >>>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt > >>>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts > >>>> directories. > >>>> > >>>> Title : Alert-Info URNs for the Session Initiation > >>>> Protocol (SIP) > >>>> Author(s) : D. Alexeitsev, et al. > >>>> Filename : draft-liess-dispatch-alert-info-urns-00.txt > >>>> Pages : 25 > >>>> Date : 2009-10-19 > >>>> > >>>> The Session Initiation Protocol (SIP) supports the capability to > >>>> provide a reference to the alternative ringback tone (RBT) for > >>>> caller, or ring tone (RT) for callee using the Alert-Info header. > >>>> However, the reference addresses only the network resources with > >>>> specific rendering properties. There is currently no support for > >>>> predefined standard identifiers for ringback tones or semantic > >>>> indications without tied rendering. To overcome this=20 > >>> limitations and > >>>> support new applications a family of the URNs is defined in this > >>>> specification. > >>>> > >>>> A URL for this Internet-Draft is: > >>>> > >>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert > >>> -info-urns > >>>> -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 > >>>> > >> > > >=20 >=20 From david.middleton@nsn.com Fri Oct 30 10:40: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 75C143A6822 for ; Fri, 30 Oct 2009 10:40:53 -0700 (PDT) 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 MAHjU-E9vXH3 for ; Fri, 30 Oct 2009 10:40:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D6B083A6768 for ; Fri, 30 Oct 2009 10:40:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9UHf413015144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Oct 2009 18:41:04 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9UHf41Q023906 for ; Fri, 30 Oct 2009 18:41:04 +0100 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 18:41:04 +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, 30 Oct 2009 12:40:31 -0500 Message-ID: <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> In-Reply-To: <024101ca528e$fbd0a8b0$f371fa10$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpShq/qoPxSbruXTN6NgIO7uxjk6wAAURsgAABifNAAAVuFcAG+JnFg References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> From: "Middleton, David (NSN - US/Boca Raton)" To: X-OriginalArrivalTime: 30 Oct 2009 17:41:04.0143 (UTC) FILETIME=[273109F0:01CA5988] Subject: Re: [dispatch] To-URI in domain-registration 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, 30 Oct 2009 17:40:53 -0000 Some colleagues have pointed out an aspect that I had not considered = concerning the domain registration To: user part. There are cases where = an Enterprise has multiple PBXs that register and calls should be routed = to one of the PBXs based on which user is called. In other words, = instead of the Enterprise with multiple PBXs appearing as one logical = PBX, the Enterprise customer wants the service provider to take = responsibility for distributing the calls to the specific PBX that hosts = the called user. While this problem could be solved with a local policy to choose one of = several contacts it is not as clean an approach as being able to treat = each registration as a separate entity with it's own contact(s). While = one could propose that these be treated separately by making different = sub-domains, the Enterprise most assuredly will not want to publish this = sub-domain on business cards, etc. when using e-mail style addresses. = Besides, it would cause the address to change if the user moves from one = PBX to another as might happen with a physical move. Another aspect to consider is that the Enterprise user, in this = scenario, is only reachable via one registered "To: user@host". So not = having separate registrations would result in a more complex definition = and implementation of things like (a.) is there an unexpired binding and = (b.) picking appropriate contacts by q-value. I think this makes a strong case for having a user part in the To: = header and treating each unique user@host as a separate registration =E0 = la RFC 3264. In summary, I support Option 1) as well. - David =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Richard Shockey Sent: Wednesday, October 21, 2009 4:42 PM To: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration +1 to Option 1) as well > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of David Hancock > Sent: Wednesday, October 21, 2009 4:05 PM > To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > =20 > =20 > Hadriel - I'd prefer option 1) as well. > =20 > David > =20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > > Behalf Of Brian Lindsay > > Sent: Wednesday, October 21, 2009 1:53 PM > > To: Hadriel Kaplan; dispatch@ietf.org > > Subject: Re: [dispatch] To-URI in domain-registration > > > > Hi Hadriel, > > > > Per my comment yesterday, I'd prefer (1). > > > > Thanks. > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > > Behalf Of Hadriel Kaplan > > Sent: Wednesday, October 21, 2009 3:43 PM > > To: dispatch@ietf.org > > Subject: [dispatch] To-URI in domain-registration > > > > Howdy, > > I'd like to get a consensus call on the question of what the To-URI > > should be for the REGISTER request of a domain registration, before > > finishing the next rev of the draft. This will affect quite a bit > of > > text in the draft (e.g., examples), and I think that the decision > about > > that will also affect whether we need more than a = Require:option-tag > as > > well. > > > > The choices right now are: > > 1) Mandate the To-URI be in the syntactical form of an AoR, > including > > the user@ portion, the same as the From-URI. > > Pros: closer to what current proprietary and other-SDO > > mechanisms do, on the wire. Therefore, presumably less of a change > and > > less barrier to adoption. > > 2) Mandate the To-URI be a domain only (no user@), while the From- > URI > > remains the "AoR" of the PBX registering. > > Pros: semantically accurate (you're registering a domain, not an > > AoR), and may obviate the need for a new header or param to = indicate > > this new mechanism is being used. > > > > Can people please indicate which they'd prefer? > > > > Thanks! > > -hadriel > > _______________________________________________ > > 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 > _______________________________________________ > 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 pkyzivat@cisco.com Fri Oct 30 16:37: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 E0BBA3A688F for ; Fri, 30 Oct 2009 16:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 olAleZqD66nc for ; Fri, 30 Oct 2009 16:37:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B32003A67FB for ; Fri, 30 Oct 2009 16:37:01 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD4V60qrR7Hu/2dsb2JhbADIGpgzhDoE X-IronPort-AV: E=Sophos;i="4.44,656,1249257600"; d="scan'208";a="47505179" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2009 23:37:19 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9UNbIt2002852; Fri, 30 Oct 2009 23:37:19 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 19:37:18 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 19:37:18 -0400 Message-ID: <4AEB78AD.5070608@cisco.com> Date: Fri, 30 Oct 2009 19:37:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Middleton, David (NSN - US/Boca Raton)" References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> In-Reply-To: <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Oct 2009 23:37:18.0077 (UTC) FILETIME=[EB0C8AD0:01CA59B9] Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration 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, 30 Oct 2009 23:37:04 -0000 David, IIUC, you are proposing a case such as: - a customer of sp.net has domain cust.sp.net - the customer has two PBX systems, east and west. - you propose that they register, respectively To: east@cust.sp.net, and To: west@cust.sp.net. - then numbers assigned to the customer are routed something like: 1-212-555-88xx -> contact from east@cust.sp.net 1-408-555-88xx -> contact from west@cust.sp.net - also, routing for names be something like: bob@cust.sp.net -> contact from east@cust.sp.net carol@cust.sp.net -> " ted@cust.sp.net -> contact from west@cust.sp.net alice@cust.sp.net -> " others... Is that right? You then can't describe that as setting up routing paths for cust.sp.net. You are instead describing some entirely different routing algorithm based on the user part. Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in large part - at least for the numbers. You clearly don't find that acceptable for the names. If those names were exposed to end users I wouldn't find it acceptable either. (I want to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) The question is whether this is the best way to solve that problem. I think that solution won't be very acceptable to an SP, or to the customer of that SP. Having the SP provision every one of your users just isn't going to be popular with anyone. (Unless the SP gets a big enough per-user fee.) Its not quite as much of a problem with numbers, because they are likely to be managed in blocks. And the numbers are really owned/managed by the SP anyway so they are forced to do something about them. This is also a problem that is not unique to this SP interconnect mechanism. It is pretty much the same problem in any big company with a lot of sites, even if they have a private network connecting all the sites. What you need in this case is a proxy at the company domain level (cust.sp.net in this case perhaps) that has the roster of all usernames and a mapping to a subdomain - mapping bob@cust.sp.net to bob@east.cust.sp.net. Then, the company has one server registering To:cust.sp.net to provide this mapping, and other servers registering To:east.cust.sp.net, ... Thanks, Paul Middleton, David (NSN - US/Boca Raton) wrote: > Some colleagues have pointed out an aspect that I had not considered concerning the domain registration To: user part. There are cases where an Enterprise has multiple PBXs that register and calls should be routed to one of the PBXs based on which user is called. In other words, instead of the Enterprise with multiple PBXs appearing as one logical PBX, the Enterprise customer wants the service provider to take responsibility for distributing the calls to the specific PBX that hosts the called user. > > While this problem could be solved with a local policy to choose one of several contacts it is not as clean an approach as being able to treat each registration as a separate entity with it's own contact(s). While one could propose that these be treated separately by making different sub-domains, the Enterprise most assuredly will not want to publish this sub-domain on business cards, etc. when using e-mail style addresses. Besides, it would cause the address to change if the user moves from one PBX to another as might happen with a physical move. > > Another aspect to consider is that the Enterprise user, in this scenario, is only reachable via one registered "To: user@host". So not having separate registrations would result in a more complex definition and implementation of things like (a.) is there an unexpired binding and (b.) picking appropriate contacts by q-value. > > I think this makes a strong case for having a user part in the To: header and treating each unique user@host as a separate registration à la RFC 3264. > > In summary, I support Option 1) as well. > > - David > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Richard Shockey > Sent: Wednesday, October 21, 2009 4:42 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > > +1 to Option 1) as well > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of David Hancock >> Sent: Wednesday, October 21, 2009 4:05 PM >> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org >> Subject: Re: [dispatch] To-URI in domain-registration >> >> >> Hadriel - I'd prefer option 1) as well. >> >> David >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> > Behalf Of Brian Lindsay >> > Sent: Wednesday, October 21, 2009 1:53 PM >> > To: Hadriel Kaplan; dispatch@ietf.org >> > Subject: Re: [dispatch] To-URI in domain-registration >> > >> > Hi Hadriel, >> > >> > Per my comment yesterday, I'd prefer (1). >> > >> > Thanks. >> > >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> > Behalf Of Hadriel Kaplan >> > Sent: Wednesday, October 21, 2009 3:43 PM >> > To: dispatch@ietf.org >> > Subject: [dispatch] To-URI in domain-registration >> > >> > Howdy, >> > I'd like to get a consensus call on the question of what the To-URI >> > should be for the REGISTER request of a domain registration, before >> > finishing the next rev of the draft. This will affect quite a bit >> of >> > text in the draft (e.g., examples), and I think that the decision >> about >> > that will also affect whether we need more than a Require:option-tag >> as >> > well. >> > >> > The choices right now are: >> > 1) Mandate the To-URI be in the syntactical form of an AoR, >> including >> > the user@ portion, the same as the From-URI. >> > Pros: closer to what current proprietary and other-SDO >> > mechanisms do, on the wire. Therefore, presumably less of a change >> and >> > less barrier to adoption. >> > 2) Mandate the To-URI be a domain only (no user@), while the From- >> URI >> > remains the "AoR" of the PBX registering. >> > Pros: semantically accurate (you're registering a domain, not an >> > AoR), and may obviate the need for a new header or param to indicate >> > this new mechanism is being used. >> > >> > Can people please indicate which they'd prefer? >> > >> > Thanks! >> > -hadriel >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >