From atle.monrad@ericsson.com Wed Feb 5 01:38:11 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49A71A00B7 for ; Wed, 5 Feb 2014 01:38:11 -0800 (PST) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqfBFRBRdxuK for ; Wed, 5 Feb 2014 01:38:07 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id ED3CF1A00B3 for ; Wed, 5 Feb 2014 01:38:06 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-e5-52f2067db297 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.FB.04249.D7602F25; Wed, 5 Feb 2014 10:38:05 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.97]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 10:38:05 +0100 From: Atle Monrad To: "DRAGE, Keith (Keith)" , "celine.serrutvalette@orange.com" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIA9c+JwgBJ5CFA= Date: Wed, 5 Feb 2014 09:38:04 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C167933EE@ESESSMB203.ericsson.se> References: <5283CECB.8050804@bell-labs.com> <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <949EF20990823C4C85C18D59AA11AD8B0F9917@FR712WXCHMBA11.zeu.alcatel-lucent.com> <11023_1387205849_52AF14D9_11023_2363_1_F8BE5641EC3C954DA088A8350BDDFA480FF883@PEXCVZYM13.corporate.adroot.infra.ftgroup> <949EF20990823C4C85C18D59AA11AD8B122C80@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B122C80@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW4t26cgg2lP9Sw2TDzHZnGj/QWz xdPGs4wWU/tsHVg8Wp/tZfVYsuQnk8fkjbNYPFqenWQLYInisklJzcksSy3St0vgyuh7FFGw s6CiZd8T9gbGpuguRk4OCQETiUl3X7FB2GISF+6tB7K5OIQEjjBKdF9pYodwFjFK/Ht/EKyK TUBH4tzPO6wgCRGBpYwSh+/dYgVJMAuESqy90w5mCwtYSsw7+JQFxBYRsJJ4ducVE4TtJ/H9 7WQwm0VAReLa2U6wGl4BX4ldO/5DbTvALLH6+0OwIk6BaIlLF9YCFXFwMArISsxt4oXYJS5x 68l8JoizBSSW7DnPDGGLSrx8/I8VwlaSaFzyBOo2PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJ jGKzkIydhaRlFpKWWUhaFjCyrGLkKE4tTspNNzLYxAiMpoNbflvsYLz81+YQozQHi5I478e3 zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKXXV0/3VrD6F7xN41u79crrrls6j/3Yf/P5 9zrG6uXx9br/mrN3Jbq+YS2cfzv/0FK/l3viHT5GiRWF75sfffH0qQmHWgIvzzS3m1fx9Yxi 1hOxBCaR0zt4XOfdXr88TuGCTd6560evvrQKTBd7dtR1keub37Oi5HdFqVfIdej2nmHa+eT8 vzIlluKMREMt5qLiRABIUPhvdAIAAA== Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:38:11 -0000 Keith Celine is fine with your explanations as is.=20 Could you please share your working version of the draft with the public AS= AP ?? This holds up finalization of the two cuss-drafts, and even if we now have = sorted out all the issues, I would like to see the drafts completed soon. As you know, 3GPP does not see this work as finalized until also our IETF-d= ependencies are completed. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: 24. januar 2014 17:16 To: celine.serrutvalette@orange.com; cuss@ietf.org Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn See below - changes are made to my working version, which I will submit in = due course when this dialog is closed.=20 Keith > -----Original Message----- > From: celine.serrutvalette@orange.com=20 > [mailto:celine.serrutvalette@orange.com] > Sent: 16 December 2013 14:57 > To: DRAGE, Keith (Keith); cuss@ietf.org > Subject: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > Hello, >=20 > Thank you for the update of the ISDN draft. > I have just some comments or questions below on your answers to my=20 > previous comments: >=20 > 1/ The text about "isdn-interwork" is in section 8 "UAS requirements"=20 > but it is also applicable to other sections, for instance to section 7=20 > "UAC requirements" (when UAC receives UUI in responses), so could it=20 > be replicated in section 7 "UAC requirements" or only put once in=20 > section 11 "Coding requirements" in order to be global, as you prefer? > Note just an editorial comment: in section 16 about changes,=20 > "ISDNinterwork" purpose value should be replaced by "isdn-interwork". >=20 A conformant UAC (i.e. according to this version of the id package) generat= es "isdn-uui" as the purpose parameter as part of the header field that inv= okes the service. A non-conformant UAC will not have been implemented accor= ding to this specification. A non-conformant UAS receiving a "isdn-uui" purpose parameter when it expec= ts the "isdn-interwork" purpose parameter will not understand it and theref= ore presumably will discard. The only previous version that might respond i= s an implementation that was implemented before the purpose parameter was d= efined, which is going back a long way. The UAS cannot invoke the service b= ut can only respond to what it receives from a conformant UAC. Therefore I do not see how a conformant UAC can receive a purpose parameter= set to "isdn-interwork". Change made, but as this part will be discarded on publication not strictly= necessary. > 2/A/ I agree with your comment on "originating user". But I think it=20 > would be better to clarify the expected behavior by UAS [respectively=20 > by UAC] on reception of User-to-User that is not with the "purpose"=20 > parameter to "isdn-uui", or with no "purpose" parameter, in a request=20 > [respectively in a response], as follows: >=20 > "When receiving UUI, when a User-to-User header field is received in a=20 > request that is not from the originating user with the "purpose"=20 > header field parameter to "isdn-uui", or with no "purpose" header=20 > field parameter, the UAC MUST discard this header field." =3D> this=20 > sentence of the draft is ok but "UAC" should be replaced by "UAS",=20 > isn't it? Because it's the UAS that receives the request containing=20 > UUI sent by UAC (same comment for sentences beginning by "When=20 > receiving UUI, when multiple User-to-User header [...]", it seems to=20 > me that "UAS" and "UAC" are inverted). >=20 Two changes UAC to UAS made in section 8. > "When receiving UUI, when a User-to-User header field is received in a=20 > response that is not with the "purpose" header field parameter to=20 > "isdn-uui", or with no "purpose" header field parameter, the UAC MUST=20 > discard this header field." =3D> this sentence could be added in order=20 > to specify the UAC behavior when it receives unexpected UUI in a=20 > response from the UAS. >=20 Difficult one this. For the non-inclusion, we have a "SHOULD" on the sendin= g to allow for earlier implementations that do not understand the "purpose"= header field parameter. On that basis, reception of the UUI header field w= ithout a "purpose" header field parameter should be permitted. As regards the reception with a different header field parameter value, thi= s could well be destined for a different, as yet undefined package. In section 9 we say the following which was meant to cover this: " Processing for User-to-User header fields sent or received with values other than this value are outside the scope of this document, and the appropriate package document for that value applies." On that basis I believe nothing is required to be changed. > 2/B/ Yes the sentence "When sending UUI for the ISDN package, the UAS=20 > SHOULD set the User-to-User "purpose" header field parameter to=20 > "isdn-uui". Non-inclusion of the "purpose" > [...]" is well present in both sections 7 and 8.=20 > But the sentence "When sending UUI for the ISDN package, if the=20 > "purpose" header field is included, the UAC MUST set the User-to-User=20 > "purpose" header field parameter to "isdn-uui"." > is only present in section 7 but not in section 8, why?=20 > (first sentence aims at recommending to include a purpose parameter=20 > using a SHOULD whereas second sentence clarifies the required value=20 > using a MUST) >=20 Looks like this is correct. Added. > Thank you for your clarifications. >=20 > Best regards > =20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De=A0: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Envoy=E9=A0: lundi 16 d=E9cembre 2013 04:25 > =C0=A0: SERRUT VALETTE Celine IMT/OLN; Gurbani, Vijay K (Vijay);=20 > cuss@ietf.org Objet=A0: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > See below. >=20 > I will issue the version without the last two changes, but if the=20 > discussion identifies some other text with which the group agrees, a=20 > new version can always be issued. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of=20 > > celine.serrutvalette@orange.com > > Sent: 28 November 2013 16:01 > > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn > >=20 > > Hello, > >=20 > > Please find below some comments: > >=20 > > 1/ About "isdn-interwork" versus "isdn-uui" purpose > parameter value:=20 > >=20 > > The discussions on the "[cuss] "isdn-uui" versus > "isdn-network"" email > > thread confirmed that there is still support from other cuss=20 > > participants for addressing the use of the "isdn-network" parameter=20 > > value. So, we don't think the document can be published without=20 > > addressing this issue. We also understand that at least one company=20 > > would not accept replacing "RECOMMEND" with "MUST", so we > propose to > > stick to the initial approach (cf > > http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm > > l ) and add the following text in section 11: > >=20 > > "The 'isdn-interwork' value for purpose parameter was used in=20 > > Internet-Drafts that have led to the publication of the present RFC. > > Although these documents had no other status than "work in > progress", > > this value is implemented by some vendors. Therefore, it is=20 > > RECOMMENDED to support parsing and interpreting > 'isdn-interwork' the > > same way as 'isdn-uui' when receiving." > >=20 > This one has been dealt with in a separate dialog, and the text agreed=20 > as a result of that dialog incorporated. >=20 > > 2/ About UAC and UAS procedures: > >=20 > > After having compared the UAC and UAS procedures in sections > > 7 and 8, I noticed that 2 UAC procedures could be replicated as UAS=20 > > procedures as well, so I would suggest to add in section 7: > > "When receiving UUI, when a User-to-User header field is > received in a > > response that is not from the originating user with the "purpose" > > header field parameter to "isdn-uui", or with no "purpose" header=20 > > field parameter, the UAS MUST discard this header field." > > (this procedure seems not present for UAS) > >=20 > Section 7 is the UAC procedures, and therefore material will never be=20 > from the originating user. >=20 > This requirement was drafted because UUS1 in ISDN can only be=20 > originated from the originating user and therefore this is a=20 > unidirectional requirement. >=20 > Therefore I do not see the need for an equivalent procedure in clause=20 > 7. >=20 > > And to add in section 8: > > "When sending UUI for the ISDN package, if the "purpose"=20 > > header field is included, the UAS MUST set the User-to-User > "purpose"=20 > > header field parameter to "isdn-uui"." > > (this procedure is present for UAS but not so explicitly written) > >=20 >=20 > Section 8 includes: >=20 > The UAS MAY include the User-to-User header field in responses to=20 > the > initial INVITE request, or the BYE requests or responses for the > dialog, only where the original INVITE request included a User-to- > User header field with the "purpose" header field parameter to=20 > "isdn- > uui", or where no "purpose" header field parameter was included. > When sending UUI for the ISDN package, the UAS SHOULD set the User- > to-User "purpose" header field parameter to "isdn-uui". Non- > inclusion of the "purpose" header field parameter is permitted, but > this is primarily to allow earlier implementations to support this > package. The UAS MUST NOT include more than one User-to-User=20 > header > field for this package in any SIP request or response. >=20 > Does this not effectively say that. >=20 >=20 > > It could be worthwhile to add them in order to be symmetric when a=20 > > procedure is common to both UAC and UAS, otherwise people > could wonder > > if it means that they are just missing or if it means that they are=20 > > not applicable. > >=20 > >=20 > > We would like these 1/ and 2/ comments to be taken into > account before > > the ISDN draft becomes a RFC. > > Thank you in advance. > >=20 > > Best regards > >=20 > > Celine Serrut-Valette > > Orange Labs > >=20 > > -----Message d'origine----- > > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] > De la part > > de Vijay K. Gurbani Envoy=E9=A0: mercredi 13 novembre > > 2013 20:11 =C0=A0: cuss@ietf.org Objet=A0: [cuss] WGLC for=20 > > draft-ietf-cuss-sip-uui-isdn > >=20 > > Folks: Enrico and I will like to announce a WGLC for the ISDN draft=20 > > [1]. > >=20 > > The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. > >=20 > > We will appreciate your comments on the draft, posted to the list. =20 > > All comments are appreciated, even if it is a simple > one-liner saying > > that you believe the draft is ready, or conversely, that it is not=20 > > ready (and why). > >=20 > > As you review the draft, as part of your WGLC review, > please identify > > any issues that may exist in regard to compatibility with=20 > > draft-ietf-cuss-uui (the mechanism draft). > >=20 > > Thank you. > >=20 > > [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ > >=20 > > Vijay K. Gurbani and Enrico Marocco > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > >=20 > > ______________________________________________________________ > > ___________________________________________________________ > >=20 > > Ce message et ses pieces jointes peuvent contenir des informations=20 > > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > > par erreur, veuillez le signaler a l'expediteur et le > detruire ainsi > > que les pieces jointes. Les messages electroniques etant > susceptibles > > d'alteration, Orange decline toute responsabilite si ce > message a ete > > altere, deforme ou falsifie. Merci. > >=20 > > This message and its attachments may contain confidential or=20 > > privileged information that may be protected by law; they > should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the > sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages > that have > > been modified, changed or falsified. > > Thank you. > >=20 > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > >=20 >=20 > ______________________________________________________________ > ___________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 >=20 _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Mon Feb 10 06:34:44 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000801A05FC for ; Mon, 10 Feb 2014 06:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqmNYm28GZRl for ; Mon, 10 Feb 2014 06:34:42 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F01A02E2 for ; Mon, 10 Feb 2014 06:34:41 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1AEYbow028675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 08:34:37 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s1AEYb7x008061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Feb 2014 08:34:37 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s1AEYYQE018755; Mon, 10 Feb 2014 08:34:34 -0600 (CST) Message-ID: <52F8E3B9.9010202@bell-labs.com> Date: Mon, 10 Feb 2014 08:35:37 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Drage, Keith (Keith)" 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 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: cuss@ietf.org Subject: [cuss] New version of ISDN draft X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:34:44 -0000 Keith: What is the status of the ISDN draft? Is a version going to appear before the cutoff date? Please advise ASAP. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From vkg@bell-labs.com Thu Feb 13 06:44:34 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DE1A02C1 for ; Thu, 13 Feb 2014 06:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67htgfnDLa2J for ; Thu, 13 Feb 2014 06:44:32 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD51A02BE for ; Thu, 13 Feb 2014 06:44:32 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1DEiU33002500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Feb 2014 08:44:30 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s1DEiT3x008666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Feb 2014 08:44:30 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s1DEi2ns013734; Thu, 13 Feb 2014 08:44:03 -0600 (CST) Message-ID: <52FCDA72.5070803@bell-labs.com> Date: Thu, 13 Feb 2014 08:45:06 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Drage, Keith (Keith)" 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 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: cuss@ietf.org Subject: [cuss] Any chance of getting the ISDN draft out by Friday? X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:44:34 -0000 Keith: As you are well aware, the deadline for draft submission is Friday. Any chance of getting a new revision of the ISDN draft out by then? Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Feb 14 12:31:50 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0B61A037C for ; Fri, 14 Feb 2014 12:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE6hlvbjTIZ2 for ; Fri, 14 Feb 2014 12:31:44 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9791A02F5 for ; Fri, 14 Feb 2014 12:31:44 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1EKVeQU022555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 14:31:41 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EKVe2D026297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 21:31:40 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 21:31:40 +0100 From: "DRAGE, Keith (Keith)" To: "celine.serrutvalette@orange.com" , "R.Jesske@telekom.de" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIA9c+JwgAATXZCABFFKoIAc8ScQ Date: Fri, 14 Feb 2014 20:31:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B132ACE@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <5283CECB.8050804@bell-labs.com> <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <949EF20990823C4C85C18D59AA11AD8B0F9917@FR712WXCHMBA11.zeu.alcatel-lucent.com> <11023_1387205849_52AF14D9_11023_2363_1_F8BE5641EC3C954DA088A8350BDDFA480FF883@PEXCVZYM13.corporate.adroot.infra.ftgroup> <949EF20990823C4C85C18D59AA11AD8B122C80@FR712WXCHMBA11.zeu.alcatel-lucent.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8F0F8FF3@HE113667.emea1.cds.t-internal.com> <24284_1390819836_52E639FC_24284_11527_1_F8BE5641EC3C954DA088A8350BDDFA481176B5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <24284_1390819836_52E639FC_24284_11527_1_F8BE5641EC3C954DA088A8350BDDFA481176B5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/j0C7KfsH5C7F-kO5uCJvW7QjQSE Cc: "cuss@ietf.org" Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:31:48 -0000 It is obviously difficult to identify what a non-conformant UAC will do, bu= t in my view, if a UAC is set up to receive packages, then it should only r= espond to the packages it is sent up to receive. Thus it must either ignore= the package name or ignore the entire UUI. Regards Keith=20 > -----Original Message----- > From: celine.serrutvalette@orange.com=20 > [mailto:celine.serrutvalette@orange.com]=20 > Sent: 27 January 2014 10:51 > To: R.Jesske@telekom.de > Cc: DRAGE, Keith (Keith); cuss@ietf.org > Subject: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > Hello, >=20 > Thank you for your answer, yes we can finalize these issues. > Just for information, the proposal in 1/ was not to address=20 > the case where UUS would start within an answer (as you said,=20 > not possible), but to address the following case: > a/ A conformant UAC sends in INVITE a UUI with "isdn-uui"=20 > purpose parameter value b/ A non-conformant UAS receives it,=20 > either it discards it (as suggested by Keith below) or it=20 > accepts the UUI data regardless of the purpose parameter=20 > value (behavior not really specified in=20 > draft-johnston-sipping-cc-uui-09), let's suppose the latter=20 > c/ The non-conformant UAS sends back in answer a UUI with=20 > "isdn-interwork" purpose parameter value d/ The conformant=20 > UAC will thus receive in answer a purpose parameter set to=20 > "isdn-interwork" >=20 > Best regards >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De=A0: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Envoy=E9=A0 > : vendredi 24 janvier 2014 17:45 =C0=A0:=20 > keith.drage@alcatel-lucent.com; SERRUT VALETTE Celine=20 > IMT/OLN; cuss@ietf.org Objet=A0: AW: [cuss] WGLC for=20 > draft-ietf-cuss-sip-uui-isdn >=20 > Hello Celine, > Hello Keith, > Hopefully we can finalize these issues, and you are satisfied=20 > with the arguments from Keith. > I see the facts also as Keith it does. > UUS in PSTN is started with a IAM (See Q.737.1) and the=20 > backward direction is based on that "request". > So UUS will never be started within an answer. Pls. see the=20 > regarding itu-t specifications. > So seen from this fact I would like to see the same behavior=20 > within SIP. So I support the arguments from Keith. >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von=20 > DRAGE, Keith (Keith) > Gesendet: Freitag, 24. Januar 2014 17:16 > An: celine.serrutvalette@orange.com; cuss@ietf.org > Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > See below - changes are made to my working version, which I=20 > will submit in due course when this dialog is closed.=20 >=20 > Keith >=20 > > -----Original Message----- > > From: celine.serrutvalette@orange.com=20 > > [mailto:celine.serrutvalette@orange.com] > > Sent: 16 December 2013 14:57 > > To: DRAGE, Keith (Keith); cuss@ietf.org > > Subject: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn > >=20 > > Hello, > >=20 > > Thank you for the update of the ISDN draft. > > I have just some comments or questions below on your answers to my=20 > > previous comments: > >=20 > > 1/ The text about "isdn-interwork" is in section 8 "UAS=20 > requirements"=20 > > but it is also applicable to other sections, for instance=20 > to section 7=20 > > "UAC requirements" (when UAC receives UUI in responses), so=20 > could it=20 > > be replicated in section 7 "UAC requirements" or only put once in=20 > > section 11 "Coding requirements" in order to be global, as=20 > you prefer? > > Note just an editorial comment: in section 16 about changes,=20 > > "ISDNinterwork" purpose value should be replaced by=20 > "isdn-interwork". > >=20 > A conformant UAC (i.e. according to this version of the id=20 > package) generates "isdn-uui" as the purpose parameter as=20 > part of the header field that invokes the service. A=20 > non-conformant UAC will not have been implemented according=20 > to this specification. >=20 > A non-conformant UAS receiving a "isdn-uui" purpose parameter=20 > when it expects the "isdn-interwork" purpose parameter will=20 > not understand it and therefore presumably will discard. The=20 > only previous version that might respond is an implementation=20 > that was implemented before the purpose parameter was=20 > defined, which is going back a long way. The UAS cannot=20 > invoke the service but can only respond to what it receives=20 > from a conformant UAC. >=20 > Therefore I do not see how a conformant UAC can receive a=20 > purpose parameter set to "isdn-interwork". >=20 > Change made, but as this part will be discarded on=20 > publication not strictly necessary. >=20 > > 2/A/ I agree with your comment on "originating user". But I=20 > think it=20 > > would be better to clarify the expected behavior by UAS=20 > [respectively=20 > > by UAC] on reception of User-to-User that is not with the "purpose" > > parameter to "isdn-uui", or with no "purpose" parameter, in=20 > a request=20 > > [respectively in a response], as follows: > >=20 > > "When receiving UUI, when a User-to-User header field is=20 > received in a=20 > > request that is not from the originating user with the "purpose" > > header field parameter to "isdn-uui", or with no "purpose" header=20 > > field parameter, the UAC MUST discard this header field." =3D> this=20 > > sentence of the draft is ok but "UAC" should be replaced by "UAS",=20 > > isn't it? Because it's the UAS that receives the request containing=20 > > UUI sent by UAC (same comment for sentences beginning by "When=20 > > receiving UUI, when multiple User-to-User header [...]", it=20 > seems to=20 > > me that "UAS" and "UAC" are inverted). > >=20 > Two changes UAC to UAS made in section 8. >=20 > > "When receiving UUI, when a User-to-User header field is=20 > received in a=20 > > response that is not with the "purpose" header field parameter to=20 > > "isdn-uui", or with no "purpose" header field parameter,=20 > the UAC MUST=20 > > discard this header field." =3D> this sentence could be added=20 > in order=20 > > to specify the UAC behavior when it receives unexpected UUI in a=20 > > response from the UAS. > >=20 > Difficult one this. For the non-inclusion, we have a "SHOULD"=20 > on the sending to allow for earlier implementations that do=20 > not understand the "purpose" header field parameter. On that=20 > basis, reception of the UUI header field without a "purpose"=20 > header field parameter should be permitted. >=20 > As regards the reception with a different header field=20 > parameter value, this could well be destined for a different,=20 > as yet undefined package. >=20 > In section 9 we say the following which was meant to cover this: >=20 > " Processing for User-to-User header fields sent or received with > values other than this value are outside the scope of this=20 > document, > and the appropriate package document for that value applies." >=20 > On that basis I believe nothing is required to be changed. >=20 > > 2/B/ Yes the sentence "When sending UUI for the ISDN=20 > package, the UAS=20 > > SHOULD set the User-to-User "purpose" header field parameter to=20 > > "isdn-uui". Non-inclusion of the "purpose" > > [...]" is well present in both sections 7 and 8.=20 > > But the sentence "When sending UUI for the ISDN package, if the=20 > > "purpose" header field is included, the UAC MUST set the=20 > User-to-User=20 > > "purpose" header field parameter to "isdn-uui"." > > is only present in section 7 but not in section 8, why?=20 > > (first sentence aims at recommending to include a purpose parameter=20 > > using a SHOULD whereas second sentence clarifies the required value=20 > > using a MUST) > >=20 > Looks like this is correct. Added. >=20 > > Thank you for your clarifications. > >=20 > > Best regards > > =20 > > Celine Serrut-Valette > > Orange Labs > >=20 > > -----Message d'origine----- > > De=A0: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Envoy=E9=A0: lundi 16 d=E9cembre 2013 04:25 > > =C0=A0: SERRUT VALETTE Celine IMT/OLN; Gurbani, Vijay K (Vijay);=20 > > cuss@ietf.org Objet=A0: RE: [cuss] WGLC for=20 > draft-ietf-cuss-sip-uui-isdn > >=20 > > See below. > >=20 > > I will issue the version without the last two changes, but if the=20 > > discussion identifies some other text with which the group=20 > agrees, a=20 > > new version can always be issued. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of=20 > > > celine.serrutvalette@orange.com > > > Sent: 28 November 2013 16:01 > > > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > > > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn > > >=20 > > > Hello, > > >=20 > > > Please find below some comments: > > >=20 > > > 1/ About "isdn-interwork" versus "isdn-uui" purpose > > parameter value:=20 > > >=20 > > > The discussions on the "[cuss] "isdn-uui" versus > > "isdn-network"" email > > > thread confirmed that there is still support from other cuss=20 > > > participants for addressing the use of the "isdn-network"=20 > parameter=20 > > > value. So, we don't think the document can be published without=20 > > > addressing this issue. We also understand that at least=20 > one company=20 > > > would not accept replacing "RECOMMEND" with "MUST", so we > > propose to > > > stick to the initial approach (cf > > > http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm > > > l ) and add the following text in section 11: > > >=20 > > > "The 'isdn-interwork' value for purpose parameter was used in=20 > > > Internet-Drafts that have led to the publication of the=20 > present RFC. > > > Although these documents had no other status than "work in > > progress", > > > this value is implemented by some vendors. Therefore, it is=20 > > > RECOMMENDED to support parsing and interpreting > > 'isdn-interwork' the > > > same way as 'isdn-uui' when receiving." > > >=20 > > This one has been dealt with in a separate dialog, and the=20 > text agreed=20 > > as a result of that dialog incorporated. > >=20 > > > 2/ About UAC and UAS procedures: > > >=20 > > > After having compared the UAC and UAS procedures in sections > > > 7 and 8, I noticed that 2 UAC procedures could be=20 > replicated as UAS=20 > > > procedures as well, so I would suggest to add in section 7: > > > "When receiving UUI, when a User-to-User header field is > > received in a > > > response that is not from the originating user with the "purpose" > > > header field parameter to "isdn-uui", or with no "purpose" header=20 > > > field parameter, the UAS MUST discard this header field." > > > (this procedure seems not present for UAS) > > >=20 > > Section 7 is the UAC procedures, and therefore material=20 > will never be=20 > > from the originating user. > >=20 > > This requirement was drafted because UUS1 in ISDN can only be=20 > > originated from the originating user and therefore this is a=20 > > unidirectional requirement. > >=20 > > Therefore I do not see the need for an equivalent procedure=20 > in clause=20 > > 7. > >=20 > > > And to add in section 8: > > > "When sending UUI for the ISDN package, if the "purpose"=20 > > > header field is included, the UAS MUST set the User-to-User > > "purpose"=20 > > > header field parameter to "isdn-uui"." > > > (this procedure is present for UAS but not so explicitly written) > > >=20 > >=20 > > Section 8 includes: > >=20 > > The UAS MAY include the User-to-User header field in=20 > responses to=20 > > the > > initial INVITE request, or the BYE requests or responses for the > > dialog, only where the original INVITE request included=20 > a User-to- > > User header field with the "purpose" header field parameter to > > "isdn- > > uui", or where no "purpose" header field parameter was included. > > When sending UUI for the ISDN package, the UAS SHOULD=20 > set the User- > > to-User "purpose" header field parameter to "isdn-uui". Non- > > inclusion of the "purpose" header field parameter is=20 > permitted, but > > this is primarily to allow earlier implementations to=20 > support this > > package. The UAS MUST NOT include more than one User-to-User=20 > > header > > field for this package in any SIP request or response. > >=20 > > Does this not effectively say that. > >=20 > >=20 > > > It could be worthwhile to add them in order to be=20 > symmetric when a=20 > > > procedure is common to both UAC and UAS, otherwise people > > could wonder > > > if it means that they are just missing or if it means=20 > that they are=20 > > > not applicable. > > >=20 > > >=20 > > > We would like these 1/ and 2/ comments to be taken into > > account before > > > the ISDN draft becomes a RFC. > > > Thank you in advance. > > >=20 > > > Best regards > > >=20 > > > Celine Serrut-Valette > > > Orange Labs > > >=20 > > > -----Message d'origine----- > > > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] > > De la part > > > de Vijay K. Gurbani Envoy=E9=A0: mercredi 13 novembre > > > 2013 20:11 =C0=A0: cuss@ietf.org Objet=A0: [cuss] WGLC for=20 > > > draft-ietf-cuss-sip-uui-isdn > > >=20 > > > Folks: Enrico and I will like to announce a WGLC for the=20 > ISDN draft=20 > > > [1]. > > >=20 > > > The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. > > >=20 > > > We will appreciate your comments on the draft, posted to=20 > the list. =20 > > > All comments are appreciated, even if it is a simple > > one-liner saying > > > that you believe the draft is ready, or conversely, that=20 > it is not=20 > > > ready (and why). > > >=20 > > > As you review the draft, as part of your WGLC review, > > please identify > > > any issues that may exist in regard to compatibility with=20 > > > draft-ietf-cuss-uui (the mechanism draft). > > >=20 > > > Thank you. > > >=20 > > > [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ > > >=20 > > > Vijay K. Gurbani and Enrico Marocco > > > _______________________________________________ > > > cuss mailing list > > > cuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/cuss > > >=20 > > > ______________________________________________________________ > > > ___________________________________________________________ > > >=20 > > > Ce message et ses pieces jointes peuvent contenir des=20 > informations=20 > > > confidentielles ou privilegiees et ne doivent donc pas etre > > diffuses, > > > exploites ou copies sans autorisation. Si vous avez recu=20 > ce message=20 > > > par erreur, veuillez le signaler a l'expediteur et le > > detruire ainsi > > > que les pieces jointes. Les messages electroniques etant > > susceptibles > > > d'alteration, Orange decline toute responsabilite si ce > > message a ete > > > altere, deforme ou falsifie. Merci. > > >=20 > > > This message and its attachments may contain confidential or=20 > > > privileged information that may be protected by law; they > > should not > > > be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the > > sender and > > > delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages > > that have > > > been modified, changed or falsified. > > > Thank you. > > >=20 > > > _______________________________________________ > > > cuss mailing list > > > cuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/cuss > > >=20 > >=20 > > ______________________________________________________________ > > ___________________________________________________________ > >=20 > > Ce message et ses pieces jointes peuvent contenir des informations=20 > > confidentielles ou privilegiees et ne doivent donc pas etre=20 > diffuses,=20 > > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > > par erreur, veuillez le signaler a l'expediteur et le=20 > detruire ainsi=20 > > que les pieces jointes. Les messages electroniques etant=20 > susceptibles=20 > > d'alteration, Orange decline toute responsabilite si ce=20 > message a ete=20 > > altere, deforme ou falsifie. Merci. > >=20 > > This message and its attachments may contain confidential or=20 > > privileged information that may be protected by law; they=20 > should not=20 > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the=20 > sender and=20 > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages=20 > that have=20 > > been modified, changed or falsified. > > Thank you. > >=20 > >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 > ______________________________________________________________ > ___________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des=20 > informations confidentielles ou privilegiees et ne doivent=20 > donc pas etre diffuses, exploites ou copies sans=20 > autorisation. Si vous avez recu ce message par erreur,=20 > veuillez le signaler a l'expediteur et le detruire ainsi que=20 > les pieces jointes. Les messages electroniques etant=20 > susceptibles d'alteration, Orange decline toute=20 > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they=20 > should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the=20 > sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages=20 > that have been modified, changed or falsified. > Thank you. >=20 > = From nobody Fri Feb 14 12:33:47 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C530C1A03E0; Fri, 14 Feb 2014 12:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z38olZBJSvrD; Fri, 14 Feb 2014 12:33:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C601C1A02C0; Fri, 14 Feb 2014 12:33:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214203343.23521.22013.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:33:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/L1s1FwQ97VkCBnXi0M3xB4_MTN0 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-07.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:33:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. Title : Interworking ISDN Call Control User Information with SIP Authors : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-07.txt Pages : 20 Date : 2014-02-14 Abstract: The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-isdn-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:42:19 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0AE1A03D6 for ; Fri, 14 Feb 2014 12:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5LpiJliQ19U for ; Fri, 14 Feb 2014 12:42:09 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 323411A03B9 for ; Fri, 14 Feb 2014 12:42:08 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1EKg5Lm000353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Feb 2014 14:42:06 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EKg4aZ031870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 21:42:04 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 21:42:04 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Thread-Topic: New Version Notification for draft-ietf-cuss-sip-uui-isdn-07.txt Thread-Index: AQHPKcQSsKbbkZ7LnEqML6P4scmlR5q1NmHA Date: Fri, 14 Feb 2014 20:42:04 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B132B06@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/6js9XYOJTHXdd_WwlSzTQV9acnE Subject: [cuss] FW: New Version Notification for draft-ietf-cuss-sip-uui-isdn-07.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:42:16 -0000 I have just submitted the -07 version. The changes since the last version are: In the UAS requirements section, a new requirement has been added to set the purpose parameter to "uui-isdn" if it is included. This matches an equivalent requirement for the UAC. In the UAS requirements section, two instances of UAC have been corrected to UAS. Regards Keith Drage=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 14 February 2014 20:34 To: Alan Johnston; DRAGE, Keith (Keith); DRAGE, Keith (Keith); Alan Johnsto= n Subject: New Version Notification for draft-ietf-cuss-sip-uui-isdn-07.txt A new version of I-D, draft-ietf-cuss-sip-uui-isdn-07.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ietf-cuss-sip-uui-isdn Revision: 07 Title: Interworking ISDN Call Control User Information with SIP Document date: 2014-02-14 Group: cuss Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui= -isdn-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-is= dn/ Htmlized: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-= isdn-07 Abstract: The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Feb 17 07:49:59 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CD11A020C for ; Mon, 17 Feb 2014 07:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTR4q0B_n1Hd for ; Mon, 17 Feb 2014 07:49:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1ED1A024B for ; Mon, 17 Feb 2014 07:49:54 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2FBAD3B417B; Mon, 17 Feb 2014 16:49:51 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1161D27C0B9; Mon, 17 Feb 2014 16:49:51 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 16:49:50 +0100 From: To: "DRAGE, Keith (Keith)" Thread-Topic: [cuss] draft-ietf-cuss-sip-uui-isdn-07.txt Thread-Index: AQHPK/fk4VSeB5wHAUyZ792NLI9H1A== Date: Mon, 17 Feb 2014 15:49:49 +0000 Message-ID: <1799_1392652191_53022F9F_1799_1154_1_F8BE5641EC3C954DA088A8350BDDFA48124E0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <949EF20990823C4C85C18D59AA11AD8B132B06@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B132B06@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/uGGrW1ntWfEqfF_SN4YSvHhE3Pg Cc: "cuss@ietf.org" Subject: Re: [cuss] draft-ietf-cuss-sip-uui-isdn-07.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:49:57 -0000 Hello, It is ok for us, note just that there's still a wrong occurrence of "UAS" i= nstead of "UAC" in section 7 in the sentence "When receiving UUI, when mult= iple User-to-User header [...]", this could be updated in a next or final v= ersion of the ISDN draft (just to remember). When receiving UUI, when multiple User-to-User header fields are received in the same response with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAS MUST discard all these header fields. =3D> should be replaced by "UAC". Regards, Celine serrut-valette=20 Orange Labs (reminder: "(same comment for sentences beginning by "When receiving UUI, w= hen multiple User-to-User header [...]", it seems to me that "UAS" and "UAC= " are inverted)" =3D> well changed in section 8 but not done in section 7). -----Message d'origine----- De=A0: cuss [mailto:cuss-bounces@ietf.org] De la part de DRAGE, Keith (Keit= h) Envoy=E9=A0: vendredi 14 f=E9vrier 2014 21:42 =C0=A0: cuss@ietf.org Objet=A0: [cuss] FW: New Version Notification for draft-ietf-cuss-sip-uui-i= sdn-07.txt I have just submitted the -07 version. The changes since the last version are: In the UAS requirements section, a new requirement has been added to set the purpose parameter to "uui-isdn" if it is included. This matches an equivalent requirement for the UAC. In the UAS requirements section, two instances of UAC have been corrected to UAS. Regards Keith Drage=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 14 February 2014 20:34 To: Alan Johnston; DRAGE, Keith (Keith); DRAGE, Keith (Keith); Alan Johnston Subject: New Version Notification for draft-ietf-cuss-sip-uui-isdn-07.txt A new version of I-D, draft-ietf-cuss-sip-uui-isdn-07.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ietf-cuss-sip-uui-isdn Revision: 07 Title: Interworking ISDN Call Control User Information with SIP Document date: 2014-02-14 Group: cuss Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui= -isdn-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-is= dn/ Htmlized: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-= isdn-07 Abstract: The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you.