From atle.monrad@ericsson.com Sun Jan 5 23:57:07 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 C30311ACCE0 for ; Sun, 5 Jan 2014 23:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.46 X-Spam-Level: * X-Spam-Status: No, score=1.46 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 uGAnhj5N8V7R for ; Sun, 5 Jan 2014 23:57:05 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 35A331AC4C1 for ; Sun, 5 Jan 2014 23:57:04 -0800 (PST) X-AuditID: c1b4fb32-b7f2b8e0000073bf-74-52ca61c7e144 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A7.FB.29631.7C16AC25; Mon, 6 Jan 2014 08:56:56 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.164]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0347.000; Mon, 6 Jan 2014 08:56:23 +0100 From: Atle Monrad To: "celine.serrutvalette@orange.com" , "DRAGE, Keith (Keith)" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIAgqUng Date: Mon, 6 Jan 2014 07:56:22 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C2664CB@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> In-Reply-To: <11023_1387205849_52AF14D9_11023_2363_1_F8BE5641EC3C954DA088A8350BDDFA480FF883@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvre6JxFNBBrufs1tsmHiOzeJG+wtm i6eNZxkdmD1an+1l9Viy5CeTR8uzk2wBzFFcNimpOZllqUX6dglcGT13prIVTIipOPT8GnsD 41rvLkZODgkBE4lPt38xQthiEhfurWfrYuTiEBI4wSix+PgbJghnMaNE//5VTCBVbAI6Eud+ 3mEFSYgILGWU6FvZxAqSEBawlJh38CkLiC0iYCXx7M4rJgjbTeL4j7NANgcHi4CKxIdTqSAm r4C3RMM8Toj575kkzh27ALaMU6CNUWJ37zJ2kCJGAVmJuU28IGOYBcQlbj2ZzwRxqYDEkj3n mSFsUYmXj/+xQthKEmsPb2eBqNeTuDF1ChuErS2xbOFrsHpeAUGJkzOfsExgFJ2FZOwsJC2z kLTMQtKygJFlFaNkcWpxcW66kYFebnpuiV5qUWZycXF+nl5x6iZGYBQd3PLbaAfjyT32hxil OViUxHmvs9YECQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCsXDVDfdvmP9ODPL8Iqp5Kuj3N yOYHI+Mrx1KWxbcmx277YPBPpU7RKkYnvDvs6mJfqw0nX3N3PJndZ97wPZvlOtsC+7pzzy5x xnVrirx9ZdG2fVLrQb/J/bFRUdui7Nat785XWpRl/09kfURTgZjsgklbb0/qrF8aPXHdnAXr X/0saug7U5ynxFKckWioxVxUnAgAMuJMkHACAAA= 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: Mon, 06 Jan 2014 07:57:07 -0000 Folks Personally I think that Keith has answered this in a previous mail, but for= the record; can I assume that the comments from Celine need no further rep= ly before the draft can continue its journey towards RFC? I would also be happy to understand the timeline for the remaining steps of= this draft. On: Note just an editorial comment: in section 16 about changes, "ISDNinterwork= " purpose value should be replaced by "isdn-interwork". As this section will be removed by the RFC editor, I am not really sure tha= t a new version need to be produced to add this nit. Cheers /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 celine.serrutvalette= @orange.com Sent: 16. desember 2013 15:57 To: DRAGE, Keith (Keith); cuss@ietf.org Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Hello, Thank you for the update of the ISDN draft. I have just some comments or questions below on your answers to my previous= comments: 1/ The text about "isdn-interwork" is in section 8 "UAS requirements" but i= t is also applicable to other sections, for instance to section 7 "UAC requ= irements" (when UAC receives UUI in responses), so could it be replicated i= n section 7 "UAC requirements" or only put once in section 11 "Coding requi= rements" in order to be global, as you prefer? Note just an editorial comment: in section 16 about changes, "ISDNinterwork= " purpose value should be replaced by "isdn-interwork". 2/A/ I agree with your comment on "originating user". But I think it would = be better to clarify the expected behavior by UAS [respectively by UAC] on = reception of User-to-User that is not with the "purpose" parameter to "isdn= -uui", or with no "purpose" parameter, in a request [respectively in a resp= onse], as follows: =20 "When receiving UUI, when a User-to-User header field is received in a requ= est that is not from the originating user with the "purpose" header field p= arameter to "isdn-uui", or with no "purpose" header field parameter, the UA= C MUST discard this header field." =3D> this sentence of the draft is ok bu= t "UAC" should be replaced by "UAS", isn't it? Because it's the UAS that re= ceives the request containing UUI sent by UAC (same comment for sentences b= eginning by "When receiving UUI, when multiple User-to-User header [...]", = it seems to me that "UAS" and "UAC" are inverted). "When receiving UUI, when a User-to-User header field is received in a resp= onse that is not with the "purpose" header field parameter to "isdn-uui", o= r with no "purpose" header field parameter, the UAC MUST discard this heade= r field." =3D> this sentence could be added in order to specify the UAC beh= avior when it receives unexpected UUI in a response from the UAS. 2/B/ Yes the sentence "When sending UUI for the ISDN package, the UAS SHOUL= D set the User-to-User "purpose" header field parameter to "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 "purpose" h= eader field is included, the UAC MUST set the User-to-User "purpose" header= field parameter to "isdn-uui"." is only present in section 7 but not in se= ction 8, why? (first sentence aims at recommending to include a purpose par= ameter using a SHOULD whereas second sentence clarifies the required value = using a MUST) =20 Thank you for your clarifications. Best regards =20 Celine Serrut-Valette Orange Labs -----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); cuss@ietf.= org Objet=A0: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn See below. I will issue the version without the last two changes, but if the discussio= n identifies some other text with which the group agrees, a new version can= always be issued. Regards 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=20 > 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=20 > stick to the initial approach (cf=20 > 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",=20 > this value is implemented by some vendors. Therefore, it is=20 > RECOMMENDED to support parsing and interpreting 'isdn-interwork' the=20 > same way as 'isdn-uui' when receiving." >=20 This one has been dealt with in a separate dialog, and the text agreed as a= result of that dialog incorporated. > 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=20 > 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 from = the originating user. This requirement was drafted because UUS1 in ISDN can only be originated fr= om the originating user and therefore this is a unidirectional requirement. Therefore I do not see the need for an equivalent procedure in clause 7. > 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 Section 8 includes: The UAS MAY include the User-to-User header field in responses to 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 "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 header field for this package in any SIP request or response. Does this not effectively say that. > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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,=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 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Tue Jan 7 05:48:48 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 6EF1D1AE04F for ; Tue, 7 Jan 2014 05:48:48 -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 ABZLoUlDkzBe for ; Tue, 7 Jan 2014 05:48:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 922D01AE042 for ; Tue, 7 Jan 2014 05:48:42 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 07D583B4158; Tue, 7 Jan 2014 14:48:33 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DEDDC4C05D; Tue, 7 Jan 2014 14:48:32 +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.0158.001; Tue, 7 Jan 2014 14:48:32 +0100 From: To: Atle Monrad , "DRAGE, Keith (Keith)" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIAgqUnggAH1f1A= Date: Tue, 7 Jan 2014 13:48:31 +0000 Message-ID: <14435_1389102512_52CC05B0_14435_11595_1_F8BE5641EC3C954DA088A8350BDDFA48101186@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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> <7D2F7D7ADBA812449F25F4A69922881C2664CB@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C2664CB@ESESSMB203.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] 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: 2014.1.7.124814 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: Tue, 07 Jan 2014 13:48:48 -0000 Hello and Happy New Year, No, we would like to get answers to our questions or propositions of modifi= cations (mail below of 16th Dec.). OK with your comment on "ISDNinterwork".=20 Best regards =20 Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: Atle Monrad [mailto:atle.monrad@ericsson.com]=20 Envoy=E9=A0: lundi 6 janvier 2014 08:56 =C0=A0: SERRUT VALETTE Celine IMT/OLN; DRAGE, Keith (Keith); cuss@ietf.org Objet=A0: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Folks Personally I think that Keith has answered this in a previous mail, but for= the record; can I assume that the comments from Celine need no further rep= ly before the draft can continue its journey towards RFC? I would also be happy to understand the timeline for the remaining steps of= this draft. On: Note just an editorial comment: in section 16 about changes, "ISDNinterwork= " purpose value should be replaced by "isdn-interwork". As this section will be removed by the RFC editor, I am not really sure tha= t a new version need to be produced to add this nit. Cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation Ericss= on -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of celine.serrutvalette= @orange.com Sent: 16. desember 2013 15:57 To: DRAGE, Keith (Keith); cuss@ietf.org Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Hello, Thank you for the update of the ISDN draft. I have just some comments or questions below on your answers to my previous= comments: 1/ The text about "isdn-interwork" is in section 8 "UAS requirements" but i= t is also applicable to other sections, for instance to section 7 "UAC requ= irements" (when UAC receives UUI in responses), so could it be replicated i= n section 7 "UAC requirements" or only put once in section 11 "Coding requi= rements" in order to be global, as you prefer? Note just an editorial comment: in section 16 about changes, "ISDNinterwork= " purpose value should be replaced by "isdn-interwork". 2/A/ I agree with your comment on "originating user". But I think it would = be better to clarify the expected behavior by UAS [respectively by UAC] on = reception of User-to-User that is not with the "purpose" parameter to "isdn= -uui", or with no "purpose" parameter, in a request [respectively in a resp= onse], as follows:=20=20 "When receiving UUI, when a User-to-User header field is received in a requ= est that is not from the originating user with the "purpose" header field p= arameter to "isdn-uui", or with no "purpose" header field parameter, the UA= C MUST discard this header field." =3D> this sentence of the draft is ok bu= t "UAC" should be replaced by "UAS", isn't it? Because it's the UAS that re= ceives the request containing UUI sent by UAC (same comment for sentences b= eginning by "When receiving UUI, when multiple User-to-User header [...]", = it seems to me that "UAS" and "UAC" are inverted). "When receiving UUI, when a User-to-User header field is received in a resp= onse that is not with the "purpose" header field parameter to "isdn-uui", o= r with no "purpose" header field parameter, the UAC MUST discard this heade= r field." =3D> this sentence could be added in order to specify the UAC beh= avior when it receives unexpected UUI in a response from the UAS. 2/B/ Yes the sentence "When sending UUI for the ISDN package, the UAS SHOUL= D set the User-to-User "purpose" header field parameter to "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 "purpose" h= eader field is included, the UAC MUST set the User-to-User "purpose" header= field parameter to "isdn-uui"." is only present in section 7 but not in se= ction 8, why? (first sentence aims at recommending to include a purpose par= ameter using a SHOULD whereas second sentence clarifies the required value = using a MUST)=20=20 Thank you for your clarifications. Best regards =20 Celine Serrut-Valette Orange Labs -----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); cuss@ietf.= org Objet=A0: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn See below. I will issue the version without the last two changes, but if the discussio= n identifies some other text with which the group agrees, a new version can= always be issued. Regards 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=20 > 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=20 > stick to the initial approach (cf=20 > 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",=20 > this value is implemented by some vendors. Therefore, it is=20 > RECOMMENDED to support parsing and interpreting 'isdn-interwork' the=20 > same way as 'isdn-uui' when receiving." >=20 This one has been dealt with in a separate dialog, and the text agreed as a= result of that dialog incorporated. > 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=20 > 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 from = the originating user. This requirement was drafted because UUS1 in ISDN can only be originated fr= om the originating user and therefore this is a unidirectional requirement. Therefore I do not see the need for an equivalent procedure in clause 7. > 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 Section 8 includes: The UAS MAY include the User-to-User header field in responses to 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 "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 header field for this package in any SIP request or response. Does this not effectively say that. > 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=20 > 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=20 > 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=20 > 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=20 > All comments are appreciated, even if it is a simple one-liner saying=20 > 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=20 > 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,=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 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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. From vkg@bell-labs.com Wed Jan 8 15:25:21 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 584011AD945 for ; Wed, 8 Jan 2014 15:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Rsk2YmhKvM8A for ; Wed, 8 Jan 2014 15:25:18 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6471AD93D for ; Wed, 8 Jan 2014 15:25:18 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s08NP6Tu013116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2014 17:25:06 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s08NP6Xn007228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jan 2014 17:25:06 -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 s08NP3Hg005742; Wed, 8 Jan 2014 17:25:03 -0600 (CST) Message-ID: <52CDDE77.5070208@bell-labs.com> Date: Wed, 08 Jan 2014 17:25:43 -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.2.0 MIME-Version: 1.0 To: celine.serrutvalette@orange.com, "DRAGE, Keith (Keith)" , "cuss@ietf.org" 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> <7D2F7D7ADBA812449F25F4A69922881C2664CB@ESESSMB203.ericsson.se> <14435_1389102512_52CC05B0_14435_11595_1_F8BE5641EC3C954DA088A8350BDDFA48101186@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <14435_1389102512_52CC05B0_14435_11595_1_F8BE5641EC3C954DA088A8350BDDFA48101186@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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.12 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, 08 Jan 2014 23:25:21 -0000 On 01/07/2014 07:48 AM, celine.serrutvalette@orange.com wrote: > Hello and Happy New Year, > > No, we would like to get answers to our questions or propositions of > modifications (mail below of 16th Dec.). OK with your comment on > "ISDNinterwork". [...] Keith, Celine: Can you please let us know what the status of this is. Are the changes simple enough to be folded in an -07? We need to finish this up so I can proceed with my shepherd writeup. 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 atle.monrad@ericsson.com Wed Jan 8 15:37:49 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 A80BF1ADBCD for ; Wed, 8 Jan 2014 15:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 lH220xqeruFk for ; Wed, 8 Jan 2014 15:37:48 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id DEB701AD8F5 for ; Wed, 8 Jan 2014 15:37:45 -0800 (PST) X-AuditID: c1b4fb32-b7f2b8e0000073bf-c1-52cde13f50a9 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 08.C4.29631.F31EDC25; Thu, 9 Jan 2014 00:37:35 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.164]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 00:37:35 +0100 From: Atle Monrad To: "Vijay K. Gurbani" , "celine.serrutvalette@orange.com" , "DRAGE, Keith (Keith)" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIAgqUnggAH1f1CAAiXHgIAAEbog Date: Wed, 8 Jan 2014 23:37:34 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C269A39@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> <7D2F7D7ADBA812449F25F4A69922881C2664CB@ESESSMB203.ericsson.se> <14435_1389102512_52CC05B0_14435_11595_1_F8BE5641EC3C954DA088A8350BDDFA48101186@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52CDDE77.5070208@bell-labs.com> In-Reply-To: <52CDDE77.5070208@bell-labs.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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvja79w7NBBss6VSw2TDzHZnGj/QWz xdPGs4wWDWvkHFg8Wp/tZfXou+zisWTJTyaPlmcn2QJYorhsUlJzMstSi/TtErgy3q38wFIw h6diRecC9gbGL5xdjJwcEgImEhP3LmaDsMUkLtxbD2RzcQgJnGCUOD/5EiuEs5hR4vSJRkaQ KjYBHYlzP++AJUQEzjJKPN34E6xdWMBSYt7BpywgtoiAlcSzO6+YIOwoiVOrO8BsFgEViVcT ZrOC2LwC3hL7nvUxQmy4yCKx7tpMsCJOAV2JZY9uAQ3l4GAUkJWY28QLEmYWEJe49WQ+E8Sp AhJL9pxnhrBFJV4+/scKYStJrD28nQWiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRj ZyFpmYWkZRaSlgWMLKsYJYtTi4tz040M9HLTc0v0Uosyk4uL8/P0ilM3MQLj6uCW30Y7GE/u sT/EKM3BoiTOe521JkhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo39Q+pXj68OXhSw4s/7P 5N2Tt66QUG35xH/w9rV6/R+fU5c/LCjd81iW5daOVyyX9rxbtbTT4Gb8gv/hb/rmmNcoHvvy Te7S1Zd1t2SSpkm71Mq9dXsXtbAjSvrzkvrWZeU3utzl0oqDlyhrmizwCPZ+eKCIPzFPaMP5 +F8vem9H7HDZLdynxKnEUpyRaKjFXFScCADCCV4aeQIAAA== 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, 08 Jan 2014 23:37:49 -0000 Vijay As said previously, in my view Keith has given his view on this on Dec 16th= , and nobody have given any support in either way.=20 Anyway, if more text is needed I think this is not too complicated and can= be done in -07. I do hope that people find some minutes to answer so we don't lose the mome= ntum but get the remaining work done.=20 thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@bell-labs.com]=20 Sent: 9. januar 2014 00:26 To: celine.serrutvalette@orange.com; DRAGE, Keith (Keith); cuss@ietf.org Cc: Atle Monrad Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn On 01/07/2014 07:48 AM, celine.serrutvalette@orange.com wrote: > Hello and Happy New Year, > > No, we would like to get answers to our questions or propositions of=20 > modifications (mail below of 16th Dec.). OK with your comment on=20 > "ISDNinterwork". [...] Keith, Celine: Can you please let us know what the status of this is. Are the changes simple enough to be folded in an -07? We need to finish this up so I can proceed with my shepherd writeup. 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 Jan 9 07:36:51 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 13A621AE3EC for ; Thu, 9 Jan 2014 07:36:51 -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 jU9BGjj4U7iz for ; Thu, 9 Jan 2014 07:36:48 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B660F1AE30B for ; Thu, 9 Jan 2014 07:36:48 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s09Faagg026457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Jan 2014 09:36:36 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s09FaapY019977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Jan 2014 09:36:36 -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 s09FaM8O011103; Thu, 9 Jan 2014 09:36:22 -0600 (CST) Message-ID: <52CEC21F.5010607@bell-labs.com> Date: Thu, 09 Jan 2014 09:37:03 -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.2.0 MIME-Version: 1.0 To: Atle Monrad , "celine.serrutvalette@orange.com" , "DRAGE, Keith (Keith)" , "cuss@ietf.org" 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> <7D2F7D7ADBA812449F25F4A69922881C2664CB@ESESSMB203.ericsson.se> <14435_1389102512_52CC05B0_14435_11595_1_F8BE5641EC3C954DA088A8350BDDFA48101186@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52CDDE77.5070208@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C269A39@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C269A39@ESESSMB203.ericsson.se> 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.12 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: Thu, 09 Jan 2014 15:36:51 -0000 On 01/08/2014 05:37 PM, Atle Monrad wrote: > Vijay > > As said previously, in my view Keith has given his view on this on > Dec 16th, and nobody have given any support in either way. > > Anyway, if more text is needed I think this is not too complicated > and can be done in -07. Atle: Indeed, my impression is that Celine's changes are editorial and can be incorporated in -07, however, I'd like the ISDN document editor to confirm --- or refute --- this. Keith, please let us know. > I do hope that people find some minutes to answer so we don't lose > the momentum but get the remaining work done. I agree; I'd like to finish as soon as possible as well. 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 keith.drage@alcatel-lucent.com Fri Jan 24 08:16:07 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 1A3D41A04BE for ; Fri, 24 Jan 2014 08:16:07 -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 HbZ19xO9iTV4 for ; Fri, 24 Jan 2014 08:15:59 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1531A0010 for ; Fri, 24 Jan 2014 08:15:59 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0OGFu2W000128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jan 2014 10:15:57 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0OGFtKK006110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 17:15:55 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 24 Jan 2014 17:15:55 +0100 From: "DRAGE, Keith (Keith)" To: "celine.serrutvalette@orange.com" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIA9c+Jw Date: Fri, 24 Jan 2014 16:15:54 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B122C80@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> In-Reply-To: <11023_1387205849_52AF14D9_11023_2363_1_F8BE5641EC3C954DA088A8350BDDFA480FF883@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.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 24 Jan 2014 16:16:08 -0000 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]=20 > 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=20 > to my previous comments: >=20 > 1/ The text about "isdn-interwork" is in section 8 "UAS=20 > requirements" but it is also applicable to other sections,=20 > for instance to section 7 "UAC requirements" (when UAC=20 > receives UUI in responses), so could it be replicated in=20 > section 7 "UAC requirements" or only put once in section 11=20 > "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=20 > think it would be better to clarify the expected behavior by=20 > UAS [respectively by UAC] on reception of User-to-User that=20 > is not with the "purpose" parameter to "isdn-uui", or with no=20 > "purpose" parameter, in a request [respectively in a=20 > response], as follows: =20 >=20 > "When receiving UUI, when a User-to-User header field is=20 > received in a request that is not from the originating user=20 > with the "purpose" header field parameter to "isdn-uui", or=20 > with no "purpose" header field parameter, the UAC MUST=20 > discard this header field." =3D> this sentence of the draft is=20 > ok but "UAC" should be replaced by "UAS", isn't it? Because=20 > it's the UAS that receives the request containing UUI sent by=20 > UAC (same comment for sentences beginning by "When receiving=20 > UUI, when multiple User-to-User header [...]", it seems to me=20 > 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=20 > received in a response that is not with the "purpose" header=20 > field parameter to "isdn-uui", or with no "purpose" header=20 > field parameter, the UAC MUST discard this header field." =3D>=20 > this sentence could be added in order to specify the UAC=20 > behavior when it receives unexpected UUI in a 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,=20 > the UAS SHOULD set the User-to-User "purpose" header field=20 > parameter to "isdn-uui". Non-inclusion of the "purpose"=20 > [...]" is well present in both sections 7 and 8.=20 > But the sentence "When sending UUI for the ISDN package, if=20 > the "purpose" header field is included, the UAC MUST set the=20 > User-to-User "purpose" header field parameter to "isdn-uui"."=20 > is only present in section 7 but not in section 8, why?=20 > (first sentence aims at recommending to include a purpose=20 > parameter using a SHOULD whereas second sentence clarifies=20 > the required value using a MUST) =20 >=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=20 > the discussion identifies some other text with which the=20 > group agrees, a new version can always be issued. >=20 > Regards >=20 > Keith=20 >=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=20 > parameter value:=20 > >=20 > > The discussions on the "[cuss] "isdn-uui" versus=20 > "isdn-network"" email=20 > > 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=20 > propose to=20 > > stick to the initial approach (cf=20 > > 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=20 > progress",=20 > > this value is implemented by some vendors. Therefore, it is=20 > > RECOMMENDED to support parsing and interpreting=20 > 'isdn-interwork' the=20 > > same way as 'isdn-uui' when receiving." > >=20 > This one has been dealt with in a separate dialog, and the=20 > text agreed 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=20 > received in a=20 > > 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=20 > never be 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 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=20 > "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 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=20 > parameter to "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=20 > User-to-User 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=20 > could wonder=20 > > 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=20 > account before=20 > > 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]=20 > De la part=20 > > 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=20 > one-liner saying=20 > > 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,=20 > please identify=20 > > 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=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 > > _______________________________________________ > > 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=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 R.Jesske@telekom.de Fri Jan 24 08:45:32 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 D66621A003D for ; Fri, 24 Jan 2014 08:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 c8aRdUzxfoe9 for ; Fri, 24 Jan 2014 08:45:29 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35D1A0023 for ; Fri, 24 Jan 2014 08:45:27 -0800 (PST) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jan 2014 17:45:25 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 24 Jan 2014 17:45:25 +0100 From: To: , , Date: Fri, 24 Jan 2014 17:45:15 +0100 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIA9c+JwgAATXZA= Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8F0F8FF3@HE113667.emea1.cds.t-internal.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> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B122C80@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 24 Jan 2014 16:45:33 -0000 Hello Celine, Hello Keith, Hopefully we can finalize these issues, and you are satisfied with the argu= ments 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 backward direction = is based on that "request". So UUS will never be started within an answer. Pls. see the regarding itu-t= specifications. So seen from this fact I would like to see the same behavior within SIP. So= I support the arguments from Keith. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von 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 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 celine.serrutvalette@orange.com Mon Jan 27 02:50:38 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 7AE331A01E1 for ; Mon, 27 Jan 2014 02:50:38 -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 RJad36LszNCg for ; Mon, 27 Jan 2014 02:50:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7B71A01CC for ; Mon, 27 Jan 2014 02:50:35 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 354942AC822; Mon, 27 Jan 2014 11:50:32 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E51B6180063; Mon, 27 Jan 2014 11:50:31 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 27 Jan 2014 11:50:31 +0100 From: To: "DRAGE, Keith (Keith)" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIA9c+JwgARUx/A= Date: Mon, 27 Jan 2014 10:50:30 +0000 Message-ID: <21523_1390819832_52E639F7_21523_6617_1_F8BE5641EC3C954DA088A8350BDDFA481176AE@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] 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: 2014.1.26.232114 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: Mon, 27 Jan 2014 10:50:38 -0000 Hello, Thank you very much for your answers and the planned modifications, they ar= e ok for me, we can close this dialog. Best regards Celine Serrut-Valette Orange Labs PS: Just a small question for my better understanding, but it does not real= ly matter: In 2/A/ (UAC behavior when it receives UUI in a response), you wrote "As re= gards the reception with a different header field parameter value, this cou= ld well be destined for a different, as yet undefined package." =3D> is thi= s not the same point for UAS when it receives UUI in requests (already in t= he draft)? What is the difference?=20=20 -----Message d'origine----- De=A0: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Envoy=E9=A0: vendredi 24 janvier 2014 17:16 =C0=A0: SERRUT VALETTE Celine IMT/OLN; cuss@ietf.org Objet=A0: 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=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= =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 ___________________________________________________________________________= ______________________________________________ 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. From celine.serrutvalette@orange.com Mon Jan 27 02:50:42 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 B25631A01E1 for ; Mon, 27 Jan 2014 02:50:42 -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 c81WfpB4C9oF for ; Mon, 27 Jan 2014 02:50:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id CDA561A01CC for ; Mon, 27 Jan 2014 02:50:38 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 5CC923B423C; Mon, 27 Jan 2014 11:50:36 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 42C8D38403C; Mon, 27 Jan 2014 11:50:36 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 27 Jan 2014 11:50:35 +0100 From: To: "R.Jesske@telekom.de" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgBuD74CAAKM9IIA9c+JwgAATXZCABFFKoA== Date: Mon, 27 Jan 2014 10:50:34 +0000 Message-ID: <24284_1390819836_52E639FC_24284_11527_1_F8BE5641EC3C954DA088A8350BDDFA481176B5@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8F0F8FF3@HE113667.emea1.cds.t-internal.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.5] 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: 2014.1.26.232114 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: Mon, 27 Jan 2014 10:50:42 -0000 Hello, Thank you for your answer, yes we can finalize these issues. Just for information, the proposal in 1/ was not to address the case where = UUS would start within an answer (as you said, not possible), but to addres= s the following case: a/ A conformant UAC sends in INVITE a UUI with "isdn-uui" purpose parameter= value b/ A non-conformant UAS receives it, either it discards it (as suggested by= Keith below) or it accepts the UUI data regardless of the purpose paramete= r value (behavior not really specified in draft-johnston-sipping-cc-uui-09)= , let's suppose the latter c/ The non-conformant UAS sends back in answer a UUI with "isdn-interwork" = purpose parameter value=20 d/ The conformant UAC will thus receive in answer a purpose parameter set t= o "isdn-interwork" Best regards Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Envoy=E9=A0: vendredi 24 janvier 2014 17:45 =C0=A0: keith.drage@alcatel-lucent.com; SERRUT VALETTE Celine IMT/OLN; cuss= @ietf.org Objet=A0: AW: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Hello Celine, Hello Keith, Hopefully we can finalize these issues, and you are satisfied with the argu= ments 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 backward direction = is based on that "request". So UUS will never be started within an answer. Pls. see the regarding itu-t= specifications. So seen from this fact I would like to see the same behavior within SIP. So= I support the arguments from Keith. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von 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 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" > 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" > 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=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 > "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= =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 ___________________________________________________________________________= ______________________________________________ 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. From internet-drafts@ietf.org Mon Jan 27 05:25:22 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 CDB3B1A020E; Mon, 27 Jan 2014 05:25:22 -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 byCKe7ZS0nAw; Mon, 27 Jan 2014 05:25:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B70261A020A; Mon, 27 Jan 2014 05:25:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127132520.462.38078.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 05:25:20 -0800 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-12.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: Mon, 27 Jan 2014 13:25:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Working = Group of the IETF. Title : A Mechanism for Transporting User to User Call Co= ntrol Information in SIP Authors : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-12.txt Pages : 19 Date : 2014-01-27 Abstract: There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-12 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 alan.b.johnston@gmail.com Mon Jan 27 05:29:04 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 B04641A0213; Mon, 27 Jan 2014 05:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Fukego9Uc0EO; Mon, 27 Jan 2014 05:29:02 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6F21A020E; Mon, 27 Jan 2014 05:29:02 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so5717236pdj.31 for ; Mon, 27 Jan 2014 05:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AEqX5waXIlRUAG/JnS/qqraFYulwql7A1AFeryhnnoU=; b=gK+ZCXSKAS63gpeZsTnfVcSY70/g8aLOnmmbAHxXJ4DTuM93JWZLGOEaJ41m3NK19E ifP13O3sJX/qdiyNIm3nzAgTnIV0qHKyuIm+Gk5icDtOiv8Zah0FjJf7SF13tb2IACGJ gmb6BImzwC88UW67YrLSv8eFUCd3jD3rf27BoDvJl7ydthzEcURNWYCPNgEmj9h2ayMz 9SQLQLm6pTlaSZhrGgPUGX2N6aiiDd+Ewxzzh1OA4UHv1T+6z5QGNfO49gtuElt1frHO wEKW+nJgHr04EIA2+RZLcra6EGA6nddQ4Hz+3MP1DdfGw4M5iwg6WDxkJdAsbIPxC/Zz /qJQ== MIME-Version: 1.0 X-Received: by 10.66.188.203 with SMTP id gc11mr29882894pac.63.1390829334072; Mon, 27 Jan 2014 05:28:54 -0800 (PST) Received: by 10.68.168.132 with HTTP; Mon, 27 Jan 2014 05:28:53 -0800 (PST) In-Reply-To: <519920BA.9040308@joelhalpern.com> References: <5195550A.3000608@nostrum.com> <519920BA.9040308@joelhalpern.com> Date: Mon, 27 Jan 2014 07:28:53 -0600 Message-ID: From: Alan Johnston To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7bf0c66466bdf204f0f3b0b0 Cc: gen-art@ietf.org, draft-ietf-cuss-sip-uui-all@tools.ietf.org, "cuss@ietf.org" Subject: Re: [cuss] [Gen-art] review: draft-ietf-cuss-sip-uui-10 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, 27 Jan 2014 13:29:04 -0000 --047d7bf0c66466bdf204f0f3b0b0 Content-Type: text/plain; charset=ISO-8859-1 Joel, Thanks for your review of the document. We have made the changes you suggested in your review in the -12 version. http://www.ietf.org/id/draft-ietf-cuss-sip-uui-12.txt Let us know if there are any other issues. - Alan - On Sun, May 19, 2013 at 1:58 PM, Joel M. Halpern wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-cuss-sip-uui-10 > A Mechanism for Transporting User to User > Call Control Information in SIP > Reviewer: Joel M. Halpern > Review Date: 19-May-2013 > IETF LC End Date: 29-May-2013 > IESG Telechat date: N/A > > Summary: This document is nearly ready for publication as a Proposed > Standard > > Major issues: > > Minor issues: > The requirements discussions for redirection and referral (second > paragraph of section 3, in regards REQ-3) includes what appears to be > normative requirements on redirecting devices. > a) This would seem to belong in section 4 on Normative Definition. > b) It would seem that there ought to be some discussion of what happens > with redirecting devices that do not understand this new UUI. (I presume > things work, but I don't see how.) > > Nits/editorial comments: > In section 8.2, given that this is a WG document, should the "the > authors believe" actually be "the WG believes"? Or even, given IETF rough > consensus on this document, "the IETF believes"? > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > --047d7bf0c66466bdf204f0f3b0b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,

Thanks for your review of the doc= ument. =A0We have made the changes you suggested in your review in the -12 = version. =A0


Let us know if there are any other issues.
- Alan -


On Sun, May 19, 2013 at 1:58 PM, Joel M. Halpern <jmh@joel= halpern.com> wrote:
I am the assigned Gen-ART reviewer for this draft. For bac= kground on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtf= aq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-cuss-sip-uui-10
=A0 =A0 A Mechanism for Transporting User to User
=A0 =A0 =A0 =A0 Call Control Information in SIP
Reviewer: Joel M. Halpern
Review Date: 19-May-2013
IETF LC End Date: 29-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Proposed Standa= rd

Major issues:

Minor issues:
=A0 =A0 The requirements discussions for redirection and referral (second p= aragraph of section 3, in regards REQ-3) includes what appears to be normat= ive requirements on redirecting devices.
a) This would seem to belong in section 4 on Normative Definition.
b) It would seem that there ought to be some discussion of what happens wit= h redirecting devices that do not understand this new UUI. (I presume thing= s work, but I don't see how.)

Nits/editorial comments:
=A0 =A0 In section 8.2, given that this is a WG document, should the "= the authors believe" actually be "the WG believes"? =A0Or ev= en, given IETF rough consensus on this document, "the IETF believes&qu= ot;?
_______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cuss

--047d7bf0c66466bdf204f0f3b0b0-- From vkg@bell-labs.com Mon Jan 27 07:05:05 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 91F8B1A0230 for ; Mon, 27 Jan 2014 07:05:05 -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 XYabDNZPIzsP for ; Mon, 27 Jan 2014 07:05:04 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 31D541A0143 for ; Mon, 27 Jan 2014 07:05:03 -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 s0RF50K8012625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Jan 2014 09:05:01 -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 s0RF50UO014274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jan 2014 09:05:00 -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 s0RF4gGt003640; Mon, 27 Jan 2014 09:04:42 -0600 (CST) Message-ID: <52E675BF.20203@bell-labs.com> Date: Mon, 27 Jan 2014 09:05:35 -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.2.0 MIME-Version: 1.0 To: celine.serrutvalette@orange.com, "DRAGE, Keith (Keith)" 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> <21523_1390819832_52E639F7_21523_6617_1_F8BE5641EC3C954DA088A8350BDDFA481176AE@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <21523_1390819832_52E639F7_21523_6617_1_F8BE5641EC3C954DA088A8350BDDFA481176AE@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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: 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: Mon, 27 Jan 2014 15:05:05 -0000 On 01/27/2014 04:50 AM, celine.serrutvalette@orange.com wrote: > Hello, > > Thank you very much for your answers and the planned modifications, > they are ok for me, we can close this dialog. Celine: Excellent. Thank you for your attention to the draft. Keith: Can you kindly review a version and submit it with the changes agreed upon. I will finish the shepherd writeup and move the draft ahead as soon as a new version appears. 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 jmh@joelhalpern.com Mon Jan 27 10:16:26 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 B83701A001E; Mon, 27 Jan 2014 10:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 GM-epQnU6wHm; Mon, 27 Jan 2014 10:16:25 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 07AFD1A022F; Mon, 27 Jan 2014 10:16:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D5E3C1004C9; Mon, 27 Jan 2014 10:16:22 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id EBCB11004C7; Mon, 27 Jan 2014 10:16:21 -0800 (PST) Message-ID: <52E6A274.5020307@joelhalpern.com> Date: Mon, 27 Jan 2014 13:16:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alan Johnston References: <5195550A.3000608@nostrum.com> <519920BA.9040308@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, draft-ietf-cuss-sip-uui-all@tools.ietf.org, "cuss@ietf.org" Subject: Re: [cuss] [Gen-art] review: draft-ietf-cuss-sip-uui-10 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, 27 Jan 2014 18:16:26 -0000 Thank you Alan. Those changes fully address my comments. Yours, Joel On 1/27/14 8:28 AM, Alan Johnston wrote: > Joel, > > Thanks for your review of the document. We have made the changes you > suggested in your review in the -12 version. > > http://www.ietf.org/id/draft-ietf-cuss-sip-uui-12.txt > > Let us know if there are any other issues. > > - Alan - > > > On Sun, May 19, 2013 at 1:58 PM, Joel M. Halpern > wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > >. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-cuss-sip-uui-10 > A Mechanism for Transporting User to User > Call Control Information in SIP > Reviewer: Joel M. Halpern > Review Date: 19-May-2013 > IETF LC End Date: 29-May-2013 > IESG Telechat date: N/A > > Summary: This document is nearly ready for publication as a Proposed > Standard > > Major issues: > > Minor issues: > The requirements discussions for redirection and referral > (second paragraph of section 3, in regards REQ-3) includes what > appears to be normative requirements on redirecting devices. > a) This would seem to belong in section 4 on Normative Definition. > b) It would seem that there ought to be some discussion of what > happens with redirecting devices that do not understand this new > UUI. (I presume things work, but I don't see how.) > > Nits/editorial comments: > In section 8.2, given that this is a WG document, should the > "the authors believe" actually be "the WG believes"? Or even, given > IETF rough consensus on this document, "the IETF believes"? > _________________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/__listinfo/cuss > > >