From R.Jesske@telekom.de Mon Feb 13 22:35:06 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3321E8078 for ; Mon, 13 Feb 2012 22:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joRnnyKOgVye for ; Mon, 13 Feb 2012 22:35:06 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB921E806B for ; Mon, 13 Feb 2012 22:35:05 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2012 07:35:03 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.157]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 14 Feb 2012 07:35:03 +0100 From: To: , , , , Date: Tue, 14 Feb 2012 07:35:02 +0100 Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: AczW43JvIPMtiOyUS1SN4CWkOJWOsAGSAoZAAIDPznAC7NLdMA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 06:35:07 -0000 Dear all, I would like to know if there were any assumptions made on the issue discus= sed over the last weeks. 1. Package parameter default 2. HEX encoding Is there any stuff that will go into the draft? Thank you and Best Regards Roland From thomas.belling@nsn.com Thu Feb 16 01:52:42 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F373921F84F6 for ; Thu, 16 Feb 2012 01:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFxlt+2AVOy2 for ; Thu, 16 Feb 2012 01:52:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0D521F84F5 for ; Thu, 16 Feb 2012 01:52:40 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1G9qWJ8003490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Feb 2012 10:52:32 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1G9qV5T025974; Thu, 16 Feb 2012 10:52:32 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 10:52:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2012 10:52:28 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: AczW43JvIPMtiOyUS1SN4CWkOJWOsAGSAoZAAIDPznAC7NLdMABrIuQA References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> From: "Belling, Thomas (NSN - DE/Munich)" To: , , , , X-OriginalArrivalTime: 16 Feb 2012 09:52:30.0572 (UTC) FILETIME=[B2C6CAC0:01CCEC90] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1855 X-purgate-ID: 151667::1329385953-000015E0-AB96968A/0-0/0-0 Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 09:52:42 -0000 Hi Roland, I commented on these issues on the cuss list. Here is my understanding = of the current state of the discussion. It was confirmed that isdn-uui is the default that is applicable when = the package "parameter" is absent. It was discovered that there is = related wording in the framework draft. However, in Keith=B4s isdn-uui = draft there is wording that a sender shall supply the package parameter, = which may be in contradiction. There was no response to my proposal to = change the isdn-uui draft in this respect. I believe Orange commented = the same thing independently. I hope this will be fixed in the next = version of Keith=B4s draft. I also commented that the definition of the hex encoding in the = framework draft is very unclear. There were positive responses and I = expect this to be improved in the next version of the framework draft. My proposal to allow only Upper-case characters in the hex encoding was = controversial. There were two voices in favor and two voices against = this. More opinions would help. There was also no very clear conclusion on my proposal to allow only = "token" (rather than "quoted string") for hex encoding. Again, more = opinions could help. Thomas -----Original Message----- From: ext R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Tuesday, February 14, 2012 7:35 AM To: celine.serrutvalette@orange.com; Belling, Thomas (NSN - DE/Munich); = pkyzivat@alum.mit.edu; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: AW: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Dear all, I would like to know if there were any assumptions made on the issue = discussed over the last weeks. 1. Package parameter default 2. HEX encoding Is there any stuff that will go into the draft? Thank you and Best Regards Roland From md3135@att.com Thu Feb 16 02:57:46 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BFA21F8571 for ; Thu, 16 Feb 2012 02:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP8pGl2zMqbu for ; Thu, 16 Feb 2012 02:57:42 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id EBC1221F84F2 for ; Thu, 16 Feb 2012 02:57:41 -0800 (PST) X-Env-Sender: md3135@att.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1329389860!15900559!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22705 invoked from network); 16 Feb 2012 10:57:40 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Feb 2012 10:57:40 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1GAwAb3009595; Thu, 16 Feb 2012 05:58:10 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1GAw417009556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 05:58:04 -0500 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint02.pst.cso.att.com (RSA Interceptor); Thu, 16 Feb 2012 05:57:18 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.48]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Thu, 16 Feb 2012 05:57:18 -0500 From: "DOLLY, MARTIN C" To: "Belling, Thomas (NSN - DE/Munich)" , "R.Jesske@telekom.de" , "celine.serrutvalette@orange.com" , "pkyzivat@alum.mit.edu" , "cuss@ietf.org" , "keith.drage@alcatel-lucent.com" Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: AczW43JvIPMtiOyUS1SN4CWkOJWOsAGSAoZAAIDPznAC7NLdMABrIuQAAAK/lYA= Date: Thu, 16 Feb 2012 10:57:17 +0000 Message-ID: References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.88.64] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 10:57:46 -0000 Greetings, Can the editors and WG chairs please respond to the queries in this thread? Thank you, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Bel= ling, Thomas (NSN - DE/Munich) Sent: Thursday, February 16, 2012 4:52 AM To: R.Jesske@telekom.de; celine.serrutvalette@orange.com; pkyzivat@alum.mit= .edu; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Hi Roland, I commented on these issues on the cuss list. Here is my understanding of t= he current state of the discussion. It was confirmed that isdn-uui is the default that is applicable when the p= ackage "parameter" is absent. It was discovered that there is related wordi= ng in the framework draft. However, in Keith=B4s isdn-uui draft there is wo= rding that a sender shall supply the package parameter, which may be in con= tradiction. There was no response to my proposal to change the isdn-uui dra= ft in this respect. I believe Orange commented the same thing independently= . I hope this will be fixed in the next version of Keith=B4s draft. I also commented that the definition of the hex encoding in the framework d= raft is very unclear. There were positive responses and I expect this to be= improved in the next version of the framework draft. My proposal to allow only Upper-case characters in the hex encoding was con= troversial. There were two voices in favor and two voices against this. Mor= e opinions would help. There was also no very clear conclusion on my proposal to allow only "token= " (rather than "quoted string") for hex encoding. Again, more opinions coul= d help. Thomas -----Original Message----- From: ext R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Tuesday, February 14, 2012 7:35 AM To: celine.serrutvalette@orange.com; Belling, Thomas (NSN - DE/Munich); pky= zivat@alum.mit.edu; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: AW: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Dear all, I would like to know if there were any assumptions made on the issue discus= sed over the last weeks. 1. Package parameter default 2. HEX encoding Is there any stuff that will go into the draft? Thank you and Best Regards Roland _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Thu Feb 16 05:40:20 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819221F8739 for ; Thu, 16 Feb 2012 05:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSHIrQbgxFuz for ; Thu, 16 Feb 2012 05:40:16 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 321E021F873A for ; Thu, 16 Feb 2012 05:40:16 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 56FD05D88E8; Thu, 16 Feb 2012 14:40:15 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 483525D88E3; Thu, 16 Feb 2012 14:40:15 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 14:40:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2012 14:40:13 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620233C232@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: AczW43JvIPMtiOyUS1SN4CWkOJWOsAGSAoZAAIDPznAC7NLdMABrIuQAAAK/lYAABQPYwA== References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net><843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr><580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> From: To: , , , , , X-OriginalArrivalTime: 16 Feb 2012 13:40:15.0197 (UTC) FILETIME=[838718D0:01CCECB0] Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 13:40:20 -0000 Hello, Yes, we would like, if possible, to get the feedbacks from the editors = on the different received comments made after reviewing the drafts = (draft-ietf-cuss-sip-uui-04.txt and also = draft-ietf-cuss-sip-uui-isdn-01.txt, cf cuss mailing list) in order to = have some exchanges on the different topics addressed and get a = conclusion for each of them.=20 Thanks in advance. Regards, Celine Serrut-Valette Orange Labs=20 -----Message d'origine----- De=A0: DOLLY, MARTIN C [mailto:md3135@att.com]=20 Envoy=E9=A0: jeudi 16 f=E9vrier 2012 11:57 =C0=A0: Belling, Thomas (NSN - DE/Munich); R.Jesske@telekom.de; = SERRUT-VALETTE Celine RD-CORE-ISS; pkyzivat@alum.mit.edu; cuss@ietf.org; = keith.drage@alcatel-lucent.com Objet=A0: RE: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Greetings, Can the editors and WG chairs please respond to the queries in this = thread? Thank you, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of = Belling, Thomas (NSN - DE/Munich) Sent: Thursday, February 16, 2012 4:52 AM To: R.Jesske@telekom.de; celine.serrutvalette@orange.com; = pkyzivat@alum.mit.edu; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Hi Roland, I commented on these issues on the cuss list. Here is my understanding = of the current state of the discussion. It was confirmed that isdn-uui is the default that is applicable when = the package "parameter" is absent. It was discovered that there is = related wording in the framework draft. However, in Keith=B4s isdn-uui = draft there is wording that a sender shall supply the package parameter, = which may be in contradiction. There was no response to my proposal to = change the isdn-uui draft in this respect. I believe Orange commented = the same thing independently. I hope this will be fixed in the next = version of Keith=B4s draft. I also commented that the definition of the hex encoding in the = framework draft is very unclear. There were positive responses and I = expect this to be improved in the next version of the framework draft. My proposal to allow only Upper-case characters in the hex encoding was = controversial. There were two voices in favor and two voices against = this. More opinions would help. There was also no very clear conclusion on my proposal to allow only = "token" (rather than "quoted string") for hex encoding. Again, more = opinions could help. Thomas -----Original Message----- From: ext R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Tuesday, February 14, 2012 7:35 AM To: celine.serrutvalette@orange.com; Belling, Thomas (NSN - DE/Munich); = pkyzivat@alum.mit.edu; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: AW: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Dear all, I would like to know if there were any assumptions made on the issue = discussed over the last weeks. 1. Package parameter default 2. HEX encoding Is there any stuff that will go into the draft? Thank you and Best Regards Roland _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Thu Feb 16 09:19:23 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128D121F87CA for ; Thu, 16 Feb 2012 09:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.907 X-Spam-Level: X-Spam-Status: No, score=-106.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vQY4dhKXQ4R for ; Thu, 16 Feb 2012 09:19:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2379221F887B for ; Thu, 16 Feb 2012 09:19:14 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q1GHJCEw017851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Feb 2012 11:19:13 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1GHJCkY025552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Feb 2012 11:19:12 -0600 Received: from shoonya.ih.lucent.com (shoonya-135185238235.ih.lucent.com [135.185.238.235] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id q1GHJCuX021778 for ; Thu, 16 Feb 2012 11:19:12 -0600 (CST) Message-ID: <4F3D3B95.10509@bell-labs.com> Date: Thu, 16 Feb 2012 11:23:33 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: cuss@ietf.org References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 17:19:23 -0000 On 02/16/2012 04:57 AM, DOLLY, MARTIN C wrote: > Greetings, > > Can the editors and WG chairs please respond to the queries in this > thread? Martin: As it so happened, Enrico and I had touched base with the editors of the two pending documents yesterday; the loose deadline for submitting the updated revisions to the drafts exoired yesterday [1]. A revision to the two drafts should appear soon on the list, which we hope will lead to a larger dialogue with the editors to close the comments in [2]. So ... please stay tuned. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00328.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00343.html 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/ From alan.b.johnston@gmail.com Fri Feb 17 07:45:50 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DED21F87B3 for ; Fri, 17 Feb 2012 07:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDz+hnUSXq+T for ; Fri, 17 Feb 2012 07:45:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A85C21F8792 for ; Fri, 17 Feb 2012 07:45:49 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5270806obb.31 for ; Fri, 17 Feb 2012 07:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JV8QqmoEreMQYefK5HLKiokbrXLgRJbJuy+3Hhc8k5w=; b=laMD25+bdbam0qfYYQ/sYpx6lAmZ3pAJ38URbsiszZfS5LAieK0r3pQUTXGMwWHTB3 nByL0NitYLABJ8ozbe2FjajgJZzG78hTeSYTnYsplc3GOAh3k8uaRNIVGirVAgH0jtg6 HLEpDRN5FwFjRPPqulB3Nsxjn7Qz/BxggRYqU= Received: by 10.182.48.36 with SMTP id i4mr3254568obn.72.1329493549033; Fri, 17 Feb 2012 07:45:49 -0800 (PST) Received: from [192.168.1.72] (99-58-71-98.lightspeed.stlsmo.sbcglobal.net. [99.58.71.98]) by mx.google.com with ESMTPS id g3sm3230362obk.6.2012.02.17.07.45.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 07:45:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Alan Johnston In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> Date: Fri, 17 Feb 2012 09:45:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> To: "Belling, Thomas (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1084) Cc: cuss@ietf.org Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 15:45:50 -0000 We are working on updates to the drafts. I think we can fix the ISDN package concern by changing the MUST to a = SHOULD. Since the absence of the package parameter implies the ISDN = package, there is no interoperability problem here. The hex encoding issue does have interoperability problems. Paul and I = have already explained why limiting hex letters to upper case is not a = good idea, nor is it commonly done. Also, it seems that every version of the mechanism draft (both the = working group draft and my individual draft), except one, has an example = showing lower case hex letters in it. There are existing = implementations that use lower case hex letters. I don't see how we can = change this now without causing even more problems. =20 - Alan - On Feb 16, 2012, at 3:52 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Hi Roland, >=20 > I commented on these issues on the cuss list. Here is my understanding = of the current state of the discussion. >=20 > It was confirmed that isdn-uui is the default that is applicable when = the package "parameter" is absent. It was discovered that there is = related wording in the framework draft. However, in Keith=B4s isdn-uui = draft there is wording that a sender shall supply the package parameter, = which may be in contradiction. There was no response to my proposal to = change the isdn-uui draft in this respect. I believe Orange commented = the same thing independently. I hope this will be fixed in the next = version of Keith=B4s draft. >=20 > I also commented that the definition of the hex encoding in the = framework draft is very unclear. There were positive responses and I = expect this to be improved in the next version of the framework draft. >=20 > My proposal to allow only Upper-case characters in the hex encoding = was controversial. There were two voices in favor and two voices against = this. More opinions would help. >=20 > There was also no very clear conclusion on my proposal to allow only = "token" (rather than "quoted string") for hex encoding. Again, more = opinions could help. >=20 > Thomas >=20 >=20 > -----Original Message----- > From: ext R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Tuesday, February 14, 2012 7:35 AM > To: celine.serrutvalette@orange.com; Belling, Thomas (NSN - = DE/Munich); pkyzivat@alum.mit.edu; cuss@ietf.org; = keith.drage@alcatel-lucent.com > Subject: AW: [cuss] proposed changes for = draft-ietf-cuss-sip-uui-04.txt >=20 > Dear all, > I would like to know if there were any assumptions made on the issue = discussed over the last weeks. >=20 > 1. Package parameter default > 2. HEX encoding >=20 > Is there any stuff that will go into the draft? >=20 > Thank you and Best Regards >=20 > Roland > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From thomas.belling@nsn.com Fri Feb 17 08:17:29 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9350521F8725 for ; Fri, 17 Feb 2012 08:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.766 X-Spam-Level: X-Spam-Status: No, score=-7.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC0lW736RCg3 for ; Fri, 17 Feb 2012 08:17:29 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6921F8716 for ; Fri, 17 Feb 2012 08:17:28 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1HGHGZJ013638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Feb 2012 17:17:16 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1HGHFvg020862; Fri, 17 Feb 2012 17:17:16 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 17:17:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 17:17:14 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F010B3C10@DEMUEXC014.nsn-intra.net> In-Reply-To: <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: AcztizpqZVTpGPuyS22/TjHIoDLHfAAA4Fjg References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Alan Johnston" X-OriginalArrivalTime: 17 Feb 2012 16:17:15.0753 (UTC) FILETIME=[9D079D90:01CCED8F] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3666 X-purgate-ID: 151667::1329495437-00007EDF-2BF71E33/0-0/0-0 Cc: cuss@ietf.org Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 16:17:29 -0000 Dear Alan, The argument "we do it like this in other protocols" brought forward = earlier was far from convincing in my view. However, for me your new = arguments that you are aware of existing implementations using lower = case characters and there are also such examples in some draft versions = is more compelling. Thomas -----Original Message----- From: ext Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Sent: Friday, February 17, 2012 4:46 PM To: Belling, Thomas (NSN - DE/Munich) Cc: R.Jesske@telekom.de; celine.serrutvalette@orange.com; = pkyzivat@alum.mit.edu; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt We are working on updates to the drafts. I think we can fix the ISDN package concern by changing the MUST to a = SHOULD. Since the absence of the package parameter implies the ISDN = package, there is no interoperability problem here. The hex encoding issue does have interoperability problems. Paul and I = have already explained why limiting hex letters to upper case is not a = good idea, nor is it commonly done. Also, it seems that every version of the mechanism draft (both the = working group draft and my individual draft), except one, has an example = showing lower case hex letters in it. There are existing = implementations that use lower case hex letters. I don't see how we can = change this now without causing even more problems. =20 - Alan - On Feb 16, 2012, at 3:52 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Hi Roland, >=20 > I commented on these issues on the cuss list. Here is my understanding = of the current state of the discussion. >=20 > It was confirmed that isdn-uui is the default that is applicable when = the package "parameter" is absent. It was discovered that there is = related wording in the framework draft. However, in Keith=B4s isdn-uui = draft there is wording that a sender shall supply the package parameter, = which may be in contradiction. There was no response to my proposal to = change the isdn-uui draft in this respect. I believe Orange commented = the same thing independently. I hope this will be fixed in the next = version of Keith=B4s draft. >=20 > I also commented that the definition of the hex encoding in the = framework draft is very unclear. There were positive responses and I = expect this to be improved in the next version of the framework draft. >=20 > My proposal to allow only Upper-case characters in the hex encoding = was controversial. There were two voices in favor and two voices against = this. More opinions would help. >=20 > There was also no very clear conclusion on my proposal to allow only = "token" (rather than "quoted string") for hex encoding. Again, more = opinions could help. >=20 > Thomas >=20 >=20 > -----Original Message----- > From: ext R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Tuesday, February 14, 2012 7:35 AM > To: celine.serrutvalette@orange.com; Belling, Thomas (NSN - = DE/Munich); pkyzivat@alum.mit.edu; cuss@ietf.org; = keith.drage@alcatel-lucent.com > Subject: AW: [cuss] proposed changes for = draft-ietf-cuss-sip-uui-04.txt >=20 > Dear all, > I would like to know if there were any assumptions made on the issue = discussed over the last weeks. >=20 > 1. Package parameter default > 2. HEX encoding >=20 > Is there any stuff that will go into the draft? >=20 > Thank you and Best Regards >=20 > Roland > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Fri Feb 17 08:49:29 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBDF21E8075 for ; Fri, 17 Feb 2012 08:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfHa2qXS0+KF for ; Fri, 17 Feb 2012 08:49:29 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 389DA21E8039 for ; Fri, 17 Feb 2012 08:49:28 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id b4K51i0031HzFnQ5B4pTSA; Fri, 17 Feb 2012 16:49:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id b4pT1i00W07duvL3a4pTbe; Fri, 17 Feb 2012 16:49:27 +0000 Message-ID: <4F3E8515.3070406@alum.mit.edu> Date: Fri, 17 Feb 2012 11:49:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Johnston References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> In-Reply-To: <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cuss@ietf.org Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 16:49:30 -0000 On 2/17/12 10:45 AM, Alan Johnston wrote: > We are working on updates to the drafts. > > I think we can fix the ISDN package concern by changing the MUST to a SHOULD. Since the absence of the package parameter implies the ISDN package, there is no interoperability problem here. > > The hex encoding issue does have interoperability problems. Paul and I have already explained why limiting hex letters to upper case is not a good idea, nor is it commonly done. > > Also, it seems that every version of the mechanism draft (both the working group draft and my individual draft), except one, has an example showing lower case hex letters in it. There are existing implementations that use lower case hex letters. I don't see how we can change this now without causing even more problems. > > - Alan - I am in full agreement with what Alan says above. Re token vs. quoted string: IMO it is better for implementation if this is viewed as a lexical issue, separated from the semantics. Specifically, the content of the parameter is the content of the parameter, quoted or not. The difference is that quoted strings can contain a larger range of characters than unquoted strings (tokens) can. So: - the quoted string "abcd" can also be represented as the token abcd, - but the quoted string "a b c d" cannot be represented as a token. So as long as the encoding is hex, which contains only characters that may appear in a token, the value can be represented either as a token or a quoted string. That means that the underlying implementation, after parsing the header, need not remember whether the parameter was represented as a quoted string or a token. Or we could simply not allow tokens at all - only allow quoted strings. I still think it would be useful to define a "string" encoding as an alternative to hex. I have seen a number of cases where the UUI value (including the discriminator byte) consisted of nothing but printable ascii characters. In such cases it would certainly make the messages easier to read. But that is only of major use in debugging and documentation of examples, so its not a major justification. So I am content to postpone or ignore that, since nobody else seemed enamored by this. Thanks, Paul From thomas.belling@nsn.com Fri Feb 17 09:28:48 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731A721F85EA for ; Fri, 17 Feb 2012 09:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.885 X-Spam-Level: X-Spam-Status: No, score=-7.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTQzEFycL+Fx for ; Fri, 17 Feb 2012 09:28:47 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B7C2021F854C for ; Fri, 17 Feb 2012 09:28:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1HHSZLP019697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Feb 2012 18:28:35 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1HHSXMZ007128; Fri, 17 Feb 2012 18:28:35 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 18:28:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 18:28:34 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F010B3C27@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F3E8515.3070406@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: AcztlB6j1WgGduVfRRSENJBNsY13pwABHneg References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> <4F3E8515.3070406@alum.mit.edu> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" , "Alan Johnston" X-OriginalArrivalTime: 17 Feb 2012 17:28:35.0279 (UTC) FILETIME=[93D375F0:01CCED99] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3232 X-purgate-ID: 151667::1329499716-00007EDF-B145D0D7/0-0/0-0 Cc: cuss@ietf.org Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 17:28:48 -0000 Dear Paul, It is understood that for future encodings that might e.g. allow to include a simple ASCII string as data, quoted string is required. > That means that the underlying implementation, after parsing the header, need not remember whether the > parameter was represented as a quoted string or a token. My proposal to use only token for hex encoding also did not put any such requirement on the implementation. > Or we could simply not allow tokens at all - only allow quoted strings. This would cause real backward compatibility issues. Thomas -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Friday, February 17, 2012 5:49 PM To: Alan Johnston Cc: Belling, Thomas (NSN - DE/Munich); R.Jesske@telekom.de; celine.serrutvalette@orange.com; cuss@ietf.org; keith.drage@alcatel-lucent.com Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt On 2/17/12 10:45 AM, Alan Johnston wrote: > We are working on updates to the drafts. > > I think we can fix the ISDN package concern by changing the MUST to a SHOULD. Since the absence of the package parameter implies the ISDN package, there is no interoperability problem here. > > The hex encoding issue does have interoperability problems. Paul and I have already explained why limiting hex letters to upper case is not a good idea, nor is it commonly done. > > Also, it seems that every version of the mechanism draft (both the working group draft and my individual draft), except one, has an example showing lower case hex letters in it. There are existing implementations that use lower case hex letters. I don't see how we can change this now without causing even more problems. > > - Alan - I am in full agreement with what Alan says above. Re token vs. quoted string: IMO it is better for implementation if this is viewed as a lexical issue, separated from the semantics. Specifically, the content of the parameter is the content of the parameter, quoted or not. The difference is that quoted strings can contain a larger range of characters than unquoted strings (tokens) can. So: - the quoted string "abcd" can also be represented as the token abcd, - but the quoted string "a b c d" cannot be represented as a token. So as long as the encoding is hex, which contains only characters that may appear in a token, the value can be represented either as a token or a quoted string. That means that the underlying implementation, after parsing the header, need not remember whether the parameter was represented as a quoted string or a token. Or we could simply not allow tokens at all - only allow quoted strings. I still think it would be useful to define a "string" encoding as an alternative to hex. I have seen a number of cases where the UUI value (including the discriminator byte) consisted of nothing but printable ascii characters. In such cases it would certainly make the messages easier to read. But that is only of major use in debugging and documentation of examples, so its not a major justification. So I am content to postpone or ignore that, since nobody else seemed enamored by this. Thanks, Paul From pkyzivat@alum.mit.edu Fri Feb 17 10:01:01 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEA521E80A2 for ; Fri, 17 Feb 2012 10:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNZ-aMY2xPfa for ; Fri, 17 Feb 2012 10:00:56 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B621F877A for ; Fri, 17 Feb 2012 10:00:56 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id b5ug1i0060SCNGk5560w1K; Fri, 17 Feb 2012 18:00:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id b60w1i00i07duvL3V60waz; Fri, 17 Feb 2012 18:00:56 +0000 Message-ID: <4F3E95D6.1070301@alum.mit.edu> Date: Fri, 17 Feb 2012 13:00:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> <4F3E8515.3070406@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57F010B3C27@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F010B3C27@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cuss@ietf.org Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 18:01:01 -0000 Thomas, I am not happy to establish a precedent that we can't refine a draft prior to publishing it as an RFC because of deployed implementations of earlier drafts. Drafts are called that because that is what they are - "drafts". There is no promise that backward compatibility will be maintained from one draft to the next. I also don't see much of a compatibility issue in these cases anyway. And both the upper/lower case hex issue and the token vs. quoted string issue present exactly the same challenges for your deployed systems. As long as the published version allows both lower and upper case, and both tokens and quoted strings, new implementations will *accept* what you say your deployed systems do. And its perfectly legal for new versions of those deployed systems to continue producing what they do now, so they will be backward compatible with their older versions. So all you need do is upgrade your deployed systems to be conforming to the published spec, and *then* they will be able to interoperate with implementations that never supported the "subset" that you have deployed. Thanks, Paul On 2/17/12 12:28 PM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Paul, > > It is understood that for future encodings that might e.g. allow to > include a simple ASCII string as data, quoted string is required. > >> That means that the underlying implementation, after parsing the > header, need not remember whether the >> parameter was represented as a quoted string or a token. > > My proposal to use only token for hex encoding also did not put any such > requirement on the implementation. > >> Or we could simply not allow tokens at all - only allow quoted > strings. > > This would cause real backward compatibility issues. > > Thomas > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, February 17, 2012 5:49 PM > To: Alan Johnston > Cc: Belling, Thomas (NSN - DE/Munich); R.Jesske@telekom.de; > celine.serrutvalette@orange.com; cuss@ietf.org; > keith.drage@alcatel-lucent.com > Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt > > On 2/17/12 10:45 AM, Alan Johnston wrote: >> We are working on updates to the drafts. >> >> I think we can fix the ISDN package concern by changing the MUST to a > SHOULD. Since the absence of the package parameter implies the ISDN > package, there is no interoperability problem here. >> >> The hex encoding issue does have interoperability problems. Paul and > I have already explained why limiting hex letters to upper case is not a > good idea, nor is it commonly done. >> >> Also, it seems that every version of the mechanism draft (both the > working group draft and my individual draft), except one, has an example > showing lower case hex letters in it. There are existing > implementations that use lower case hex letters. I don't see how we can > change this now without causing even more problems. >> >> - Alan - > > I am in full agreement with what Alan says above. > > Re token vs. quoted string: > > IMO it is better for implementation if this is viewed as a lexical > issue, separated from the semantics. Specifically, the content of the > parameter is the content of the parameter, quoted or not. The difference > is that quoted strings can contain a larger range of characters than > unquoted strings (tokens) can. So: > - the quoted string "abcd" can also be represented as the token abcd, > - but the quoted string "a b c d" cannot be represented as a token. > > So as long as the encoding is hex, which contains only characters that > may appear in a token, the value can be represented either as a token or > a quoted string. > > That means that the underlying implementation, after parsing the header, > need not remember whether the parameter was represented as a quoted > string or a token. > > Or we could simply not allow tokens at all - only allow quoted strings. > > I still think it would be useful to define a "string" encoding as an > alternative to hex. I have seen a number of cases where the UUI value > (including the discriminator byte) consisted of nothing but printable > ascii characters. In such cases it would certainly make the messages > easier to read. > > But that is only of major use in debugging and documentation of > examples, so its not a major justification. So I am content to postpone > or ignore that, since nobody else seemed enamored by this. > > Thanks, > Paul > From alan.b.johnston@gmail.com Fri Feb 17 12:50:07 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E0721E8072 for ; Fri, 17 Feb 2012 12:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30hfxWsUsK1R for ; Fri, 17 Feb 2012 12:50:06 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1492B21E8020 for ; Fri, 17 Feb 2012 12:50:06 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5640606obb.31 for ; Fri, 17 Feb 2012 12:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=qIjRBRBBLBng70OCPG/ygpjTx11pvatjn0IDN6oKogE=; b=PmpY05OpQQcvM6I8yFyL2zXeds8DwyIzWCb9X8YMts4Fdyi9lYGfPKHtqGO7PBEe2b vy9UL2SkbGx7kp/1U56Fus2hvXAqX4dW+zJu5rWO71KD1Torclq63+/uP6ASi5pw0Lq9 fD8dthf/qjrxIPx5eS0MNyuS9+ivuzJ9lhDDA= Received: by 10.182.118.33 with SMTP id kj1mr5800646obb.48.1329511805667; Fri, 17 Feb 2012 12:50:05 -0800 (PST) Received: from [192.168.1.72] (99-58-71-98.lightspeed.stlsmo.sbcglobal.net. [99.58.71.98]) by mx.google.com with ESMTPS id g2sm10659148obw.10.2012.02.17.12.50.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 12:50:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13--982720253 From: Alan Johnston In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> Date: Fri, 17 Feb 2012 14:49:57 -0600 Message-Id: References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: cuss@ietf.org Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 20:50:07 -0000 --Apple-Mail-13--982720253 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Celine, Are you looking for a adding a statement to the draft such as: A request or response may contain multiple User-to-User header fields = containing uui-data for different packages. A request or response may = also contain multiple User-to-User header fields containing uui-data for = the same package, if that package allows this. The rules for how many = User-to-User header fields of a package may be present in a request or a = response are defined for each package. - Alan - On Jan 5, 2012, at 11:05 AM, = wrote: > Hello, > =20 > Please find an additional comment on draft-ietf-cuss-sip-uui-04, I = hope it would not too late: > =20 > We would like to raise that it seems to us that it is not clear enough = that multiple User-to-User headers set to different package values are = allowed in the same message. There is a precision on how many = User-to-User headers can be present for a given package (=93The rules = for how many User-to-User header field of each package may be present in = a request or a response are defined for each package be present in a = request or a response are defined for each package.=94 in section 4.1), = but no precision on the possibility to have in parallel multiple = User-to-User headers set to different package values. Would it be = possible to give this possibility in the draft in a general way? > =20 > Regards, > =20 > Celine Serrut-Valette > Orange Labs > =20 > =20 > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de Martin.Huelsemann@telekom.de > Envoy=E9 : mardi 13 d=E9cembre 2011 14:58 > =C0 : MARJOU Xavier RD-CORE-LAN; cuss@ietf.org > Objet : Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 > =20 > Hi all, > =20 > for sure a package is used for a certain purpose. So I agree with = Xavier, for the solution itself it doesn't matter if the parameter name = is 'package' or 'purpose', however the name 'purpose' would provide a = certain degree of backward compatibility. > =20 > Regards, Martin > =20 > =20 > =20 > =20 > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag = von Xavier Marjou > Gesendet: Freitag, 9. Dezember 2011 15:50 > An: cuss@ietf.org > Betreff: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 >=20 > Hi, > =20 > Regarding draft-ietf-cuss-sip-uui-04, one modification I would like is = to rename the =93package=94 parameter name into =93purpose=94 which = existed until draft-ietf-cuss-sip-uui-00. The goal would to allow = compatibility with already deployed implementations that are based on = the draft-johnston individual draft (draft referenced since a long time = in 3GPP documents). There would be no change regarding the semantics: = the goal of the defined parameter is to indicate the purpose of the = application usage of UUI data and this can be fulfilled by a parameter = called =93purpose=94, in order to indicate how and why UUI data is used. > =20 > Cheers, > Xavier > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss --Apple-Mail-13--982720253 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Celine,

Are you = looking for a adding a statement to the draft such = as:

A request or response may contain multiple = User-to-User header fields containing uui-data for different packages. =  A request or response may also contain multiple User-to-User = header fields containing uui-data for the same package, if that package = allows this.  The rules for how many User-to-User header fields of = a package may be present in a request or a response are defined for = each package.

- Alan = -



Hello,
 
Please = find an additional comment on draft-ietf-cuss-sip-uui-04, I hope it = would not too late:
 
We = would like to raise that it seems to us that it is not clear enough that = multiple User-to-User headers set to different package values are = allowed in the same message. There is a precision on how many = User-to-User headers can be present for a given package (=93The rules = for how many User-to-User header field of each package may be present in = a request or a response are defined for each package be present in a = request or a response are defined for each package.=94 in section 4.1), = but no precision on the possibility to have in parallel multiple = User-to-User headers set to different package values. Would it be = possible to give this possibility in the draft in a general = way?
 
 
Celine = Serrut-Valette
Orange Labs
De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org= ] De la part = de  mardi 13 d=E9cembre 2011 = 14:58
=C0 : MARJOU Xavier = RD-CORE-LAN; cuss@ietf.org
Objet : Re: [cuss] "package" vs = "purpose" name in = draft-ietf-cuss-sip-uui-04
 
 
for sure a package is = used for a certain purpose. So I agree with Xavier, for the solution = itself it doesn't matter if the parameter name is 'package' or = 'purpose', however the name 'purpose' would provide a certain degree of = backward compatibility.
 
 

Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org= ] Im Auftrag = von Xavier = Marjou
Gesendet: Freitag, 9. Dezember 2011 = 15:50
An: cuss@ietf.org
Betreff: [cuss] "package" vs = "purpose" name in draft-ietf-cuss-sip-uui-04

 
Regarding = draft-ietf-cuss-sip-uui-04, one modification I would like is to rename = the =93package=94 parameter name into =93purpose=94 which existed until = draft-ietf-cuss-sip-uui-00. The goal would to allow compatibility with = already deployed implementations that are based on the draft-johnston = individual draft (draft referenced since a long time in 3GPP documents). = There would be no change regarding 
 
Cheers,
Date: Fri, 17 Feb 2012 23:21:19 +0100 Thread-Topic: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thread-Index: Acztnh63BP0n47QkSoyr8aVl9q8jpwAIlK3j Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA29@ESESSCMS0356.eemea.ericsson.se> References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC89BC9@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F01078600@DEMUEXC014.nsn-intra.net> <35B89E6F-E7F3-4531-AA7B-923E832EEAE1@gmail.com> <4F3E8515.3070406@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57F010B3C27@DEMUEXC014.nsn-intra.net>, <4F3E95D6.1070301@alum.mit.edu> In-Reply-To: <4F3E95D6.1070301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "cuss@ietf.org" Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 22:21:23 -0000 Hi Paul, In general I agree with you. People, when implementing drafts, need to be a= ware that things may change. But, in this case, the main problem is that the work has been going on fore= ver. We can argue about the reaons, and I am not putting blames on anyone, = simply identifying a fact. How long can we expect people to wait until they start to implement and dep= loy things? Regards, Christer ________________________________________ From: cuss-bounces@ietf.org [cuss-bounces@ietf.org] On Behalf Of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Friday, February 17, 2012 8:00 PM To: Belling, Thomas (NSN - DE/Munich) Cc: cuss@ietf.org Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt Thomas, I am not happy to establish a precedent that we can't refine a draft prior to publishing it as an RFC because of deployed implementations of earlier drafts. Drafts are called that because that is what they are - "drafts". There is no promise that backward compatibility will be maintained from one draft to the next. I also don't see much of a compatibility issue in these cases anyway. And both the upper/lower case hex issue and the token vs. quoted string issue present exactly the same challenges for your deployed systems. As long as the published version allows both lower and upper case, and both tokens and quoted strings, new implementations will *accept* what you say your deployed systems do. And its perfectly legal for new versions of those deployed systems to continue producing what they do now, so they will be backward compatible with their older versions. So all you need do is upgrade your deployed systems to be conforming to the published spec, and *then* they will be able to interoperate with implementations that never supported the "subset" that you have deployed. Thanks, Paul On 2/17/12 12:28 PM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Paul, > > It is understood that for future encodings that might e.g. allow to > include a simple ASCII string as data, quoted string is required. > >> That means that the underlying implementation, after parsing the > header, need not remember whether the >> parameter was represented as a quoted string or a token. > > My proposal to use only token for hex encoding also did not put any such > requirement on the implementation. > >> Or we could simply not allow tokens at all - only allow quoted > strings. > > This would cause real backward compatibility issues. > > Thomas > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, February 17, 2012 5:49 PM > To: Alan Johnston > Cc: Belling, Thomas (NSN - DE/Munich); R.Jesske@telekom.de; > celine.serrutvalette@orange.com; cuss@ietf.org; > keith.drage@alcatel-lucent.com > Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt > > On 2/17/12 10:45 AM, Alan Johnston wrote: >> We are working on updates to the drafts. >> >> I think we can fix the ISDN package concern by changing the MUST to a > SHOULD. Since the absence of the package parameter implies the ISDN > package, there is no interoperability problem here. >> >> The hex encoding issue does have interoperability problems. Paul and > I have already explained why limiting hex letters to upper case is not a > good idea, nor is it commonly done. >> >> Also, it seems that every version of the mechanism draft (both the > working group draft and my individual draft), except one, has an example > showing lower case hex letters in it. There are existing > implementations that use lower case hex letters. I don't see how we can > change this now without causing even more problems. >> >> - Alan - > > I am in full agreement with what Alan says above. > > Re token vs. quoted string: > > IMO it is better for implementation if this is viewed as a lexical > issue, separated from the semantics. Specifically, the content of the > parameter is the content of the parameter, quoted or not. The difference > is that quoted strings can contain a larger range of characters than > unquoted strings (tokens) can. So: > - the quoted string "abcd" can also be represented as the token abcd, > - but the quoted string "a b c d" cannot be represented as a token. > > So as long as the encoding is hex, which contains only characters that > may appear in a token, the value can be represented either as a token or > a quoted string. > > That means that the underlying implementation, after parsing the header, > need not remember whether the parameter was represented as a quoted > string or a token. > > Or we could simply not allow tokens at all - only allow quoted strings. > > I still think it would be useful to define a "string" encoding as an > alternative to hex. I have seen a number of cases where the UUI value > (including the discriminator byte) consisted of nothing but printable > ascii characters. In such cases it would certainly make the messages > easier to read. > > But that is only of major use in debugging and documentation of > examples, so its not a major justification. So I am content to postpone > or ignore that, since nobody else seemed enamored by this. > > Thanks, > Paul > _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Tue Feb 21 18:17:56 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD721F8796 for ; Tue, 21 Feb 2012 18:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.799 X-Spam-Level: X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQiuUcKDvrCZ for ; Tue, 21 Feb 2012 18:17:54 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3C55E21F87CF for ; Tue, 21 Feb 2012 18:17:54 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1M2HqfM027490 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Feb 2012 03:17:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 22 Feb 2012 03:17:51 +0100 From: "DRAGE, Keith (Keith)" To: "celine.serrutvalette@orange.com" , "cuss@ietf.org" Date: Wed, 22 Feb 2012 03:17:50 +0100 Thread-Topic: [cuss] Expert review of sip-uui-isdn draft underway Thread-Index: Acy7RC2xXFlGIcK9TNa956tuUgl0AgQgQXngACp8PjA= Message-ID: References: <4EEA1CF4.4050902@bell-labs.com> <843DA8228A1BA74CA31FB4E111A5C462021ABDF3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462021ABDF3@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 02:17:56 -0000 My comments below indicating my proposed handing. I'll take this as I'ved i= ndicated for the next draft unless I see alternative proposals or objection= s from members of the working group in the next 5 days or so. Suggest if commenting to these that those items agreed with are removed. If I've missed anything do please let me know. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > celine.serrutvalette@orange.com > Sent: 05 January 2012 17:04 > To: cuss@ietf.org > Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway >=20 > Hello and Happy New Year, >=20 > Please find our comments on draft-ietf-cuss-sip-uui-isdn-01: >=20 > **Section 3.1** > C1: "to control the request and granting of the service, as in USS2 and > UUS3" =3D> just an editorial comment, "USS2" should be replaced by "UUS2"= . >=20 OK > C2: "Only a single user information package can be transported in each > message" =3D> in order to avoid any misunderstanding, it would be clearer= to > indicate that this restriction concerns "isdn-uui" package, so it would b= e > in-line with section 6 where this precision is given and with section 5 > where another package could be used (enhanced package) in parallel with > "isdn-uui". Otherwise, without this clarification, it could be understood > as no other package is allowed. > Proposal: "Only a single user information package set to "isdn-uui" can b= e > transported in each message". This sentence is talking about the ISDN service and how that works and its = constraints, where there is no package concept. The sentence predates the u= se of the term "package" as part of the protocol and I guess it would be be= tter to remove the term here to avoid confusion. I think just removing the = word works best: "Only a single user information can be transported in each= message." >=20 > **Section 5** > C3: "the endpoint can carry the UUI data both as ISDN and as some other > package in parallel" =3D> it would be suitable to explicitly indicate tha= t > ISDN UUI and other types of UUI using other packages are conveyed either > in the same or in different messages. >=20 >=20 > Proposal: "the endpoint can carry the UUI data both as ISDN UUI and as > other types of UUI defined in other packages, in parallel in the same or > in different messages". I propose adding "depending on the needs of the application" (after same or= in different), otherwise I propose to follow the proposal here. >=20 > **Section 7** > C4: "The UAC MUST only use this package of the UUI mechanism extension in > association with the initial INVITE method and the BYE method relating to > an INVITE dialog. Usage on transactions associated with any other type of > dialog, or on methods not associated with a dialog is precluded." =3D> Th= e > first sentence indicates that User-to-User header can only be conveyed in > initial INVITE request, its responses, BYE request and its responses > (which is consistent with the definition of UUS1) whereas the scope of th= e > second sentence is wider because it means that other methods within the > INVITE-initiated dialog (e.g. UPDATE) can be used to convey UUI, although > only initial INVITE and BYE methods are allowed. > Proposal: "The UAC MUST only use this package [...]. Usage on transaction= s > associated with any other type of dialog, or on methods not associated > with a dialog, or on methods related to an INVITE dialog but different > from initial INVITE or BYE methods is precluded." >=20 I propose to follow this, except to make the proposal a separate sentence: = "Usage on other methods within the INVITE dialog, and on re-INVITE transact= ions with the INVITE dialog, is also precluded." > C5: "If the UAC wishes to user or permit the sending of UUI data at any > point in the dialog, the UAC MUST include in the INVITE request for that > dialog a User-to-User header field with an "package" header field > parameter set to "isdn-uui". This initial header field constitutes the > implicit request to use the UUI service, and is therefore included even > when there is no data except the protocol discriminator octet to send at > that point in time." =3D> the use of User-to-User header even with no uui > data in INVITE request for implicit request should be a possibility but > not a requirement since the uui option tag has been created for that > purpose and allows as well to declare and negotiate the uui capacity. > Proposal: replace "MUST" by "MAY" in the above sentences. >=20 I guess when I wrote the above requirement, I was working on what I underst= ood the uui mechanism draft would say, because at that time it was not avai= lable. So we need to evaluate what we need to say. I agree that based on the current mechanism draft, on receipt without a "pa= ckage" header field parameter "uui-isdn" has to be assumed. For sending, I believe an explicit indication would at least be good practi= ce. I also believe it would be confusing if for example a media feature tag= indicating "sip.uui-isdn" was included but a package header field paramete= r was not. Would changing the "MUST" to a "SHOULD be an appropriate solution", along w= ith some additional clarification. I would propose the text as follows: " If the UAC wishes to use or permit the sending of UUI data at any point i= n the dialog, the UAC MUST include in the INVITE request for that dialog a = User-to-User header field. The UAC SHOULD set the "package" header field pa= rameter to "isdn-uui". Non-inclusion of the "package" header field paramete= r is permitted, but this is primarily to allow earlier implementations to s= upport this package. This initial header field constitutes the implicit req= uest to use the UUI service, and is therefore included even when there is n= o data except the protocol discriminator octet to send at that point in tim= e." This is also going to result in a number of changes where reception of the = "package" field is specified, to encompass the non-inclusion with the same = meaning, I propose not to elaborate these here. > C6: "The UAC MUST NOT include the User-to-User header field with an > "package" header field parameter set to "isdn-uui" in any message of an > INVITE dialog if the original INVITE request did not include the User-to- > User header field with an "package" header field parameter set to "isdn- > uui".") =3D> it should be allowed to include a User-to-User header even i= f > no User-to-User header was present in INVITE request since the negotiatio= n > of the uui capacity can be done by uui option tag instead. > Proposal: replace "MUST" by "MAY" in the above sentence. I think "MAY" is the wrong solution to this comment. If there is an entirel= y different "package" header field parameter, continuing to assume this is = "isdn-uui" would be inappropriate. Propose rewording to: " The UAC MUST NOT include the User-to-User header field with an "package" = header field parameter set to "isdn-uui", or with no "package" header field= parameter", in any message of an INVITE dialog if the original INVITE requ= est did not include the User-to-User header field, either with an "package"= header field parameter set to "isdn-uui", or with no "package" header fiel= d parameter included." >=20 > C7: "Because for the ISDN UUI service, the service is service 1 implicit, > the inclusion of the "uui" option tag in a Supported header field conveys > no additional information over and above the presence of the User-to-User > header field with the "package" header field parameter to "isdn-uui" in > the INVITE request. While there is no harm in including the "uui" option > tag, and strictly it should be included if the extension is supported, it > performs no function" =3D> it should be possible, in order to > declare/negotiate the uui capability, to use the uui option tag instead o= f > the inclusion of User-to-User header even with no uui data, at least by > indicating both possibilities. > Proposal: "While there is no harm in including the "uui" option tag, and > strictly it should be included if the extension is supported, it performs > no function when User-to-User header is included in INVITE request for > implicit request. Otherwise, the uui option tag is used to indicate that = a > UA supports and understands the User-to-User header field." >=20 I believe this comment is incorrect. While this would work in the absence of ISDN interworking, if ISDN interwor= king was involved they there would be an extra complication to the interwor= king. In ISDN it is the presence of the user-to-user information parameter = / information element in ISDN IAM / DSS1 SETUP message that indicates the r= equest for the service. That is why it is called implicit. The presence of = data implicitly requests the service. If we follow the proposal above, we effectively give the gateway two altern= ates to map an empty user-user received from ISDN, and have to deal with bo= th those alternatives when received in SIP at the gateway. Moreover, in the ISDN there is no such thing as an empty user user, as it s= till has to contain the protocol discriminator. I quote for example Q.957.1= : " Service 1 may be implicitly requested by including a User-to-user infor= mation element of variable length as specified in 4.5/Q.931 [1] in the SETU= P message, transferred across the user network interface at the calling sid= e as described in 5.1.1/Q.931 [1]. This information element is transported = by the network and delivered unchanged in the User-to-user information elem= ent included in the SETUP message transferred across the user network inter= face at the called side as described in 5.2.1/Q.931 [1]. For activation pur= poses, this information element must be at least three octets long, as defi= ned in 4.5/Q.931 [1]." There are requirements elsewhere in the i-d to include the protocol discrim= inator as the minimum contents of the uuidata. > C8: "When sending UUI for the ISDN package, the UAS MUST set the User-to- > User "package" header field parameter to "isdn-uui" and "When receiving > UUI, when a User-to-User header field is received in a request that is no= t > from the originating user with the "package" header field parameter to > "isdn-uui", the UAC MUST discard this header fields." =3D> this requires = the > presence of package parameter (with value set to "isdn-uui"). In order to > be consistent with draft-ietf-cuss-sip-uui-04 ("If the "package" paramete= r > is not present, interworking with the ISDN UUI Service MUST be assumed"), > it would be necessary to add that when package parameter is not present, > its default value "isdn-uui" must be assumed. > Proposal (in reception): "When receiving UUI, when a User-to-User header > field is received in a request that is not from the originating user with > the "package" header field parameter to "isdn-uui", the UAC MUST discard > this header fields. When receiving UUI, if no package header field > parameter is present, the UAC must assume its default value "isdn-uui"". > Proposal (in emission): "When sending UUI for the ISDN package, if the UA= S > includes a User-to-User "package" header field parameter, it MUST set it > to "isdn-uui". >=20 Does the following work?: " When receiving UUI, when a User-to-User header field is received in a req= uest that is not from the originating user with the "package" header field = parameter to "isdn-uui", or with no "package" header field parameter, the U= AC MUST discard this header field." This is one of the many changes to encompass the non-receipt of the header = field parameter. > C9: As done in Section 8 for UAS, it would be relevant to indicate the > behavior of the UAC when a User-to-User header field is received in a > response that is not with the "package" header field parameter to "isdn- > uui" (discarded?). >=20 > **Section 8** > C4, C6 and C8 comments are also applicable in this section. >=20 I will address in accordance with any agreement on the comments above. > **Section 13** > C10: "This document adds the following row to the "UUI packages" sub- > registry of the SIP parameter registry: Value: isdn-uui" =3D> it would be > suitable to rename the value of package parameter from "isdn-uui" into > "isdn-interwork". The goal would to allow compatibility with already > deployed implementations that are based on the draft-johnston individual > draft (draft referenced since a long time in 3GPP documents). There would > be no change regarding the meaning because the definitions of "isdn- > interwork" and "isdn-uui" values are exactly the same, for ISDN > interworking scenarios ("which is to interoperate with ISDN User to User > Signaling (UUS)"). >=20 This is driven directly from the mechanism draft, so I will follow whatever= it states there. > 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: jeudi 15 d=E9cembre 2011 17:15 > =C0=A0: cuss@ietf.org > Objet=A0: [cuss] Expert review of sip-uui-isdn draft underway >=20 > Folks: Celine Serrutvalette has agreed to perform an expert review of > the UUI ISDN draft (thanks, Celine). >=20 > The expert review is due Jan-10-2012. >=20 > The token for a second expert review of the SIP mechanism draft is > with Martin Dolly. >=20 > I suspect that once both these expert reviews are in, Enrico and I > will ask the editors to modify their respective drafts and proceed > to WGLC. >=20 > Until then, y'all have a nice holiday season. >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From thomas.belling@nsn.com Thu Feb 23 09:11:36 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC70221F8751 for ; Thu, 23 Feb 2012 09:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.674 X-Spam-Level: X-Spam-Status: No, score=-6.674 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiJ6PpwOTiMC for ; Thu, 23 Feb 2012 09:11:11 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4AB21F8701 for ; Thu, 23 Feb 2012 09:11:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1NHB1vJ005814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Feb 2012 18:11:01 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1NHB1N2001956; Thu, 23 Feb 2012 18:11:01 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 18:11:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 18:11:00 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F010FD0F6@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Expert review of sip-uui-isdn draft underway Thread-Index: Acy7RC2xXFlGIcK9TNa956tuUgl0AgQgQXngACp8PjAJdzAYMA== References: <4EEA1CF4.4050902@bell-labs.com><843DA8228A1BA74CA31FB4E111A5C462021ABDF3@ftrdmel0.rd.francetelecom.fr> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext DRAGE, Keith (Keith)" , , X-OriginalArrivalTime: 23 Feb 2012 17:11:00.0961 (UTC) FILETIME=[1DE1CD10:01CCF24E] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 17503 X-purgate-ID: 151667::1330017061-000015E0-09997840/0-0/0-0 Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 17:11:38 -0000 Dear Keith, Celine, You wrote > > C6: "The UAC MUST NOT include the User-to-User header field with an=20 > > "package" header field parameter set to "isdn-uui" in any message of = > > an INVITE dialog if the original INVITE request did not include the=20 > > User-to- User header field with an "package" header field parameter=20 > > set to "isdn- > > uui".") =3D> it should be allowed to include a User-to-User header = even=20 > > if no User-to-User header was present in INVITE request since the=20 > > negotiation of the uui capacity can be done by uui option tag = instead. > > Proposal: replace "MUST" by "MAY" in the above sentence. > > I think "MAY" is the wrong solution to this comment. If there is an = entirely different "package" header > field parameter, continuing to assume this is "isdn-uui" would be = inappropriate. > > Propose rewording to: > > " The UAC MUST NOT include the User-to-User header field with an = "package" header field parameter > set to "isdn-uui", or with no "package" header field parameter", in = any message of an INVITE dialog > if the original INVITE request did not include the User-to-User = header field, either with an "package" > header field parameter set to "isdn-uui", or with no "package" header = field parameter included." In my understanding the scope of this draft is UUS1 implicit. We should thus aim to have comparable behavior to the ISUP service. In my understanding (based on Q.737.1, quotation below) of ISUP UUS1 = implicit, UUS can be included in an ISUP response even if none was in = the IAM. If I am correct, neither the original wording nor the proposed rewording = of Keith allows for a proper interworking of the service. We should = rather also allow "isdn-uui" within a User-to-User header in SIP = responses irrespective of what was contained in the SIP request.=20 FYI I paste in the text from Q.737.1 I deem relevant: 1.1.5.2.1.1.3 Transfer of user-to-user information User-to-user information may be contained in any of the messages that = may be transferred in the call set-up and call release phases, independently of whether the service is = requested implicitly or explicitly, provided that the explicit service 1 has not been rejected = or the request for the implicit service 1 has not been discarded. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of = ext DRAGE, Keith (Keith) Sent: Wednesday, February 22, 2012 3:18 AM To: celine.serrutvalette@orange.com; cuss@ietf.org Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway My comments below indicating my proposed handing. I'll take this as = I'ved indicated for the next draft unless I see alternative proposals or = objections from members of the working group in the next 5 days or so. Suggest if commenting to these that those items agreed with are removed. If I've missed anything do please let me know. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of celine.serrutvalette@orange.com > Sent: 05 January 2012 17:04 > To: cuss@ietf.org > Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway >=20 > Hello and Happy New Year, >=20 > Please find our comments on draft-ietf-cuss-sip-uui-isdn-01: >=20 > **Section 3.1** > C1: "to control the request and granting of the service, as in USS2=20 > and UUS3" =3D> just an editorial comment, "USS2" should be replaced by = "UUS2". >=20 OK > C2: "Only a single user information package can be transported in each = > message" =3D> in order to avoid any misunderstanding, it would be=20 > clearer to indicate that this restriction concerns "isdn-uui" package, = > so it would be in-line with section 6 where this precision is given=20 > and with section 5 where another package could be used (enhanced=20 > package) in parallel with "isdn-uui". Otherwise, without this=20 > clarification, it could be understood as no other package is allowed. > Proposal: "Only a single user information package set to "isdn-uui"=20 > can be transported in each message". This sentence is talking about the ISDN service and how that works and = its constraints, where there is no package concept. The sentence = predates the use of the term "package" as part of the protocol and I = guess it would be better to remove the term here to avoid confusion. I = think just removing the word works best: "Only a single user information = can be transported in each message." >=20 > **Section 5** > C3: "the endpoint can carry the UUI data both as ISDN and as some=20 > other package in parallel" =3D> it would be suitable to explicitly=20 > indicate that ISDN UUI and other types of UUI using other packages are = > conveyed either in the same or in different messages. >=20 >=20 > Proposal: "the endpoint can carry the UUI data both as ISDN UUI and as = > other types of UUI defined in other packages, in parallel in the same=20 > or in different messages". I propose adding "depending on the needs of the application" (after same = or in different), otherwise I propose to follow the proposal here. >=20 > **Section 7** > C4: "The UAC MUST only use this package of the UUI mechanism extension = > in association with the initial INVITE method and the BYE method=20 > relating to an INVITE dialog. Usage on transactions associated with=20 > any other type of dialog, or on methods not associated with a dialog=20 > is precluded." =3D> The first sentence indicates that User-to-User=20 > header can only be conveyed in initial INVITE request, its responses,=20 > BYE request and its responses (which is consistent with the definition = > of UUS1) whereas the scope of the second sentence is wider because it=20 > means that other methods within the INVITE-initiated dialog (e.g.=20 > UPDATE) can be used to convey UUI, although only initial INVITE and = BYE methods are allowed. > Proposal: "The UAC MUST only use this package [...]. Usage on=20 > transactions associated with any other type of dialog, or on methods=20 > not associated with a dialog, or on methods related to an INVITE=20 > dialog but different from initial INVITE or BYE methods is precluded." >=20 I propose to follow this, except to make the proposal a separate = sentence: "Usage on other methods within the INVITE dialog, and on = re-INVITE transactions with the INVITE dialog, is also precluded." > C5: "If the UAC wishes to user or permit the sending of UUI data at=20 > any point in the dialog, the UAC MUST include in the INVITE request=20 > for that dialog a User-to-User header field with an "package" header=20 > field parameter set to "isdn-uui". This initial header field=20 > constitutes the implicit request to use the UUI service, and is=20 > therefore included even when there is no data except the protocol=20 > discriminator octet to send at that point in time." =3D> the use of=20 > User-to-User header even with no uui data in INVITE request for=20 > implicit request should be a possibility but not a requirement since=20 > the uui option tag has been created for that purpose and allows as = well to declare and negotiate the uui capacity. > Proposal: replace "MUST" by "MAY" in the above sentences. >=20 I guess when I wrote the above requirement, I was working on what I = understood the uui mechanism draft would say, because at that time it = was not available. So we need to evaluate what we need to say. I agree that based on the current mechanism draft, on receipt without a = "package" header field parameter "uui-isdn" has to be assumed. For sending, I believe an explicit indication would at least be good = practice. I also believe it would be confusing if for example a media = feature tag indicating "sip.uui-isdn" was included but a package header = field parameter was not. Would changing the "MUST" to a "SHOULD be an appropriate solution", = along with some additional clarification. I would propose the text as follows: " If the UAC wishes to use or permit the sending of UUI data at any = point in the dialog, the UAC MUST include in the INVITE request for that = dialog a User-to-User header field. The UAC SHOULD set the "package" = header field parameter to "isdn-uui". Non-inclusion of the "package" = header field parameter is permitted, but this is primarily to allow = earlier implementations to support this package. This initial header = field constitutes the implicit request to use the UUI service, and is = therefore included even when there is no data except the protocol = discriminator octet to send at that point in time." This is also going to result in a number of changes where reception of = the "package" field is specified, to encompass the non-inclusion with = the same meaning, I propose not to elaborate these here. > C6: "The UAC MUST NOT include the User-to-User header field with an=20 > "package" header field parameter set to "isdn-uui" in any message of=20 > an INVITE dialog if the original INVITE request did not include the=20 > User-to- User header field with an "package" header field parameter=20 > set to "isdn- > uui".") =3D> it should be allowed to include a User-to-User header = even=20 > if no User-to-User header was present in INVITE request since the=20 > negotiation of the uui capacity can be done by uui option tag instead. > Proposal: replace "MUST" by "MAY" in the above sentence. I think "MAY" is the wrong solution to this comment. If there is an = entirely different "package" header field parameter, continuing to = assume this is "isdn-uui" would be inappropriate. Propose rewording to: " The UAC MUST NOT include the User-to-User header field with an = "package" header field parameter set to "isdn-uui", or with no "package" = header field parameter", in any message of an INVITE dialog if the = original INVITE request did not include the User-to-User header field, = either with an "package" header field parameter set to "isdn-uui", or = with no "package" header field parameter included." >=20 > C7: "Because for the ISDN UUI service, the service is service 1=20 > implicit, the inclusion of the "uui" option tag in a Supported header=20 > field conveys no additional information over and above the presence of = > the User-to-User header field with the "package" header field=20 > parameter to "isdn-uui" in the INVITE request. While there is no harm=20 > in including the "uui" option tag, and strictly it should be included=20 > if the extension is supported, it performs no function" =3D> it should = > be possible, in order to declare/negotiate the uui capability, to use=20 > the uui option tag instead of the inclusion of User-to-User header=20 > even with no uui data, at least by indicating both possibilities. > Proposal: "While there is no harm in including the "uui" option tag,=20 > and strictly it should be included if the extension is supported, it=20 > performs no function when User-to-User header is included in INVITE=20 > request for implicit request. Otherwise, the uui option tag is used to = > indicate that a UA supports and understands the User-to-User header = field." >=20 I believe this comment is incorrect. While this would work in the absence of ISDN interworking, if ISDN = interworking was involved they there would be an extra complication to = the interworking. In ISDN it is the presence of the user-to-user = information parameter / information element in ISDN IAM / DSS1 SETUP = message that indicates the request for the service. That is why it is = called implicit. The presence of data implicitly requests the service. If we follow the proposal above, we effectively give the gateway two = alternates to map an empty user-user received from ISDN, and have to = deal with both those alternatives when received in SIP at the gateway. Moreover, in the ISDN there is no such thing as an empty user user, as = it still has to contain the protocol discriminator. I quote for example = Q.957.1: " Service 1 may be implicitly requested by including a = User-to-user information element of variable length as specified in = 4.5/Q.931 [1] in the SETUP message, transferred across the user network = interface at the calling side as described in 5.1.1/Q.931 [1]. This = information element is transported by the network and delivered = unchanged in the User-to-user information element included in the SETUP = message transferred across the user network interface at the called side = as described in 5.2.1/Q.931 [1]. For activation purposes, this = information element must be at least three octets long, as defined in = 4.5/Q.931 [1]." There are requirements elsewhere in the i-d to include the protocol = discriminator as the minimum contents of the uuidata. > C8: "When sending UUI for the ISDN package, the UAS MUST set the=20 > User-to- User "package" header field parameter to "isdn-uui" and "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 "package"=20 > header field parameter to "isdn-uui", the UAC MUST discard this header = > fields." =3D> this requires the presence of package parameter (with=20 > value set to "isdn-uui"). In order to be consistent with=20 > draft-ietf-cuss-sip-uui-04 ("If the "package" parameter is not=20 > present, interworking with the ISDN UUI Service MUST be assumed"), it=20 > would be necessary to add that when package parameter is not present, = its default value "isdn-uui" must be assumed. > Proposal (in reception): "When receiving UUI, when a User-to-User=20 > header field is received in a request that is not from the originating = > user with the "package" header field parameter to "isdn-uui", the UAC=20 > MUST discard this header fields. When receiving UUI, if no package=20 > header field parameter is present, the UAC must assume its default = value "isdn-uui"". > Proposal (in emission): "When sending UUI for the ISDN package, if the = > UAS includes a User-to-User "package" header field parameter, it MUST=20 > set it to "isdn-uui". >=20 Does the following work?: " When receiving UUI, when a User-to-User header field is received in a = request that is not from the originating user with the "package" header = field parameter to "isdn-uui", or with no "package" header field = parameter, the UAC MUST discard this header field." This is one of the many changes to encompass the non-receipt of the = header field parameter. > C9: As done in Section 8 for UAS, it would be relevant to indicate the = > behavior of the UAC when a User-to-User header field is received in a=20 > response that is not with the "package" header field parameter to=20 > "isdn- uui" (discarded?). >=20 > **Section 8** > C4, C6 and C8 comments are also applicable in this section. >=20 I will address in accordance with any agreement on the comments above. > **Section 13** > C10: "This document adds the following row to the "UUI packages" sub-=20 > registry of the SIP parameter registry: Value: isdn-uui" =3D> it would = > be suitable to rename the value of package parameter from "isdn-uui"=20 > into "isdn-interwork". The goal would to allow compatibility with=20 > already deployed implementations that are based on the draft-johnston=20 > individual draft (draft referenced since a long time in 3GPP=20 > documents). There would be no change regarding the meaning because the = > definitions of "isdn- interwork" and "isdn-uui" values are exactly the = > same, for ISDN interworking scenarios ("which is to interoperate with=20 > ISDN User to User Signaling (UUS)"). >=20 This is driven directly from the mechanism draft, so I will follow = whatever it states there. > 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: jeudi 15 d=E9cembre 2011 17:15 = =C0=A0:=20 > cuss@ietf.org Objet=A0: [cuss] Expert review of sip-uui-isdn draft=20 > underway >=20 > Folks: Celine Serrutvalette has agreed to perform an expert review of=20 > the UUI ISDN draft (thanks, Celine). >=20 > The expert review is due Jan-10-2012. >=20 > The token for a second expert review of the SIP mechanism draft is=20 > with Martin Dolly. >=20 > I suspect that once both these expert reviews are in, Enrico and I=20 > will ask the editors to modify their respective drafts and proceed to=20 > WGLC. >=20 > Until then, y'all have a nice holiday season. >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Thu Feb 23 09:45:57 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD2921F8723 for ; Thu, 23 Feb 2012 09:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.91 X-Spam-Level: X-Spam-Status: No, score=-108.91 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdVi6v8rVIgy for ; Thu, 23 Feb 2012 09:45:55 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C8F2221F871E for ; Thu, 23 Feb 2012 09:45:53 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1NHjp6i017057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Feb 2012 18:45:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 23 Feb 2012 18:45:51 +0100 From: "DRAGE, Keith (Keith)" To: "Belling, Thomas (NSN - DE/Munich)" , "celine.serrutvalette@orange.com" , "cuss@ietf.org" Date: Thu, 23 Feb 2012 18:45:43 +0100 Thread-Topic: [cuss] Expert review of sip-uui-isdn draft underway Thread-Index: Acy7RC2xXFlGIcK9TNa956tuUgl0AgQgQXngACp8PjAJdzAYMAAA5k0g Message-ID: References: <4EEA1CF4.4050902@bell-labs.com><843DA8228A1BA74CA31FB4E111A5C462021ABDF3@ftrdmel0.rd.francetelecom.fr> <1A8A7D59006A8240B27FF63C794CA57F010FD0F6@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F010FD0F6@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 17:45:57 -0000 I think the answer is in the text you extracted in the words: " the request= for the implicit service 1 has not been discarded." But to give you some quotes from the ISDN service description, ITU-T Recomm= endation Q.257.1. "2.2.7 implicit request: The UUS supplementary service is considered as im= plicitly requested when no explicit request for the UUS supplementary servi= ce is made and UUI is sent by the user when originating a call." Section: 3.2.1.1 "Service 1 can be activated by means of an implicit request or an explicit = request. Service 1 is implicitly requested when UUI is included when origin= ating a call. The served user shall be given an explicit response (acceptan= ce or rejection) to an explicit request. An explicit request can include UU= I." And from ITU-T Recommendation Q.737.1: "Service 1 may be requested implicitly by the presence of the user-to-user = information parameter in the initial address message. An implicit request i= s "non-essential" by default. ... On call set-up, the initial address message will contain the user-to-user i= nformation parameter. The user-to-user information will be received from ca= ll control and will be transported across the network and delivered unchang= ed to the terminating call control for the called user. The user-to-user in= dicators parameter will not be sent. The reception of a user-to-user information parameter in a backward call co= ntrol message from the terminating call control is an implicit indication o= f the acceptance of service 1." I could make further quotes from ITU-T Recommendation Q.957.1 and ITU-T Rec= ommendation Q.87.1 but they are all consistent in requiring the implicit re= quest in the origination. The stage 2 seems even more emphatic with FEAs fo= r checking the service is active on every data transfer. There are only two types of requesting the service, implicit or explicit - = there is no other type. Given that both implicit and explicit requests both= refer to information included in the origination of the call (i.e. IAM or = SETUP) that is the only options available. I agree the implicit request can be empty of data, but that still means it = contains the information element identifier, the length, and the protocol d= iscriminator (which is a mandatory octet for the information element). Therefore for the ISDN package, an implicit request must be in the first me= ssage, and that implicit request must be able to transport 1 octet of proto= col discriminator. Regards Keith > -----Original Message----- > From: Belling, Thomas (NSN - DE/Munich) [mailto:thomas.belling@nsn.com] > Sent: 23 February 2012 17:11 > To: DRAGE, Keith (Keith); celine.serrutvalette@orange.com; cuss@ietf.org > Subject: RE: [cuss] Expert review of sip-uui-isdn draft underway > > Dear Keith, Celine, > > You wrote > > > > C6: "The UAC MUST NOT include the User-to-User header field with an > > > "package" header field parameter set to "isdn-uui" in any message of > > > an INVITE dialog if the original INVITE request did not include the > > > User-to- User header field with an "package" header field parameter > > > set to "isdn- > > > uui".") =3D> it should be allowed to include a User-to-User header ev= en > > > if no User-to-User header was present in INVITE request since the > > > negotiation of the uui capacity can be done by uui option tag instead= . > > > Proposal: replace "MUST" by "MAY" in the above sentence. > > > > I think "MAY" is the wrong solution to this comment. If there is an > entirely different "package" header > > field parameter, continuing to assume this is "isdn-uui" would be > inappropriate. > > > > Propose rewording to: > > > > " The UAC MUST NOT include the User-to-User header field with an > "package" header field parameter > > set to "isdn-uui", or with no "package" header field parameter", in an= y > message of an INVITE dialog > > if the original INVITE request did not include the User-to-User header > field, either with an "package" > > header field parameter set to "isdn-uui", or with no "package" header > field parameter included." > > In my understanding the scope of this draft is UUS1 implicit. > We should thus aim to have comparable behavior to the ISUP service. > In my understanding (based on Q.737.1, quotation below) of ISUP UUS1 > implicit, UUS can be included in an ISUP response even if none was in the > IAM. > > If I am correct, neither the original wording nor the proposed rewording > of Keith allows for a proper interworking of the service. We should rathe= r > also allow "isdn-uui" within a User-to-User header in SIP responses > irrespective of what was contained in the SIP request. > > > FYI I paste in the text from Q.737.1 I deem relevant: > > 1.1.5.2.1.1.3 Transfer of user-to-user information > User-to-user information may be contained in any of the messages that may > be transferred in the call > set-up and call release phases, independently of whether the service is > requested implicitly or > explicitly, provided that the explicit service 1 has not been rejected or > the request for the implicit > service 1 has not been discarded. > > > Thomas > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > ext DRAGE, Keith (Keith) > Sent: Wednesday, February 22, 2012 3:18 AM > To: celine.serrutvalette@orange.com; cuss@ietf.org > Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway > > My comments below indicating my proposed handing. I'll take this as I'ved > indicated for the next draft unless I see alternative proposals or > objections from members of the working group in the next 5 days or so. > > Suggest if commenting to these that those items agreed with are removed. > > If I've missed anything do please let me know. > > Regards > > Keith > > > -----Original Message----- > > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf > > Of celine.serrutvalette@orange.com > > Sent: 05 January 2012 17:04 > > To: cuss@ietf.org > > Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway > > > > Hello and Happy New Year, > > > > Please find our comments on draft-ietf-cuss-sip-uui-isdn-01: > > > > **Section 3.1** > > C1: "to control the request and granting of the service, as in USS2 > > and UUS3" =3D> just an editorial comment, "USS2" should be replaced by > "UUS2". > > > OK > > > C2: "Only a single user information package can be transported in each > > message" =3D> in order to avoid any misunderstanding, it would be > > clearer to indicate that this restriction concerns "isdn-uui" package, > > so it would be in-line with section 6 where this precision is given > > and with section 5 where another package could be used (enhanced > > package) in parallel with "isdn-uui". Otherwise, without this > > clarification, it could be understood as no other package is allowed. > > Proposal: "Only a single user information package set to "isdn-uui" > > can be transported in each message". > > This sentence is talking about the ISDN service and how that works and it= s > constraints, where there is no package concept. The sentence predates the > use of the term "package" as part of the protocol and I guess it would be > better to remove the term here to avoid confusion. I think just removing > the word works best: "Only a single user information can be transported i= n > each message." > > > > > **Section 5** > > C3: "the endpoint can carry the UUI data both as ISDN and as some > > other package in parallel" =3D> it would be suitable to explicitly > > indicate that ISDN UUI and other types of UUI using other packages are > > conveyed either in the same or in different messages. > > > > > > Proposal: "the endpoint can carry the UUI data both as ISDN UUI and as > > other types of UUI defined in other packages, in parallel in the same > > or in different messages". > > I propose adding "depending on the needs of the application" (after same > or in different), otherwise I propose to follow the proposal here. > > > > > **Section 7** > > C4: "The UAC MUST only use this package of the UUI mechanism extension > > in association with the initial INVITE method and the BYE method > > relating to an INVITE dialog. Usage on transactions associated with > > any other type of dialog, or on methods not associated with a dialog > > is precluded." =3D> The first sentence indicates that User-to-User > > header can only be conveyed in initial INVITE request, its responses, > > BYE request and its responses (which is consistent with the definition > > of UUS1) whereas the scope of the second sentence is wider because it > > means that other methods within the INVITE-initiated dialog (e.g. > > UPDATE) can be used to convey UUI, although only initial INVITE and BYE > methods are allowed. > > Proposal: "The UAC MUST only use this package [...]. Usage on > > transactions associated with any other type of dialog, or on methods > > not associated with a dialog, or on methods related to an INVITE > > dialog but different from initial INVITE or BYE methods is precluded." > > > I propose to follow this, except to make the proposal a separate sentence= : > "Usage on other methods within the INVITE dialog, and on re-INVITE > transactions with the INVITE dialog, is also precluded." > > > > C5: "If the UAC wishes to user or permit the sending of UUI data at > > any point in the dialog, the UAC MUST include in the INVITE request > > for that dialog a User-to-User header field with an "package" header > > field parameter set to "isdn-uui". This initial header field > > constitutes the implicit request to use the UUI service, and is > > therefore included even when there is no data except the protocol > > discriminator octet to send at that point in time." =3D> the use of > > User-to-User header even with no uui data in INVITE request for > > implicit request should be a possibility but not a requirement since > > the uui option tag has been created for that purpose and allows as well > to declare and negotiate the uui capacity. > > Proposal: replace "MUST" by "MAY" in the above sentences. > > > I guess when I wrote the above requirement, I was working on what I > understood the uui mechanism draft would say, because at that time it was > not available. So we need to evaluate what we need to say. > > I agree that based on the current mechanism draft, on receipt without a > "package" header field parameter "uui-isdn" has to be assumed. > > For sending, I believe an explicit indication would at least be good > practice. I also believe it would be confusing if for example a media > feature tag indicating "sip.uui-isdn" was included but a package header > field parameter was not. > > Would changing the "MUST" to a "SHOULD be an appropriate solution", along > with some additional clarification. > > I would propose the text as follows: > > " If the UAC wishes to use or permit the sending of UUI data at any point > in the dialog, the UAC MUST include in the INVITE request for that dialog > a User-to-User header field. The UAC SHOULD set the "package" header fiel= d > parameter to "isdn-uui". Non-inclusion of the "package" header field > parameter is permitted, but this is primarily to allow earlier > implementations to support this package. This initial header field > constitutes the implicit request to use the UUI service, and is therefore > included even when there is no data except the protocol discriminator > octet to send at that point in time." > > This is also going to result in a number of changes where reception of th= e > "package" field is specified, to encompass the non-inclusion with the sam= e > meaning, I propose not to elaborate these here. > > > C6: "The UAC MUST NOT include the User-to-User header field with an > > "package" header field parameter set to "isdn-uui" in any message of > > an INVITE dialog if the original INVITE request did not include the > > User-to- User header field with an "package" header field parameter > > set to "isdn- > > uui".") =3D> it should be allowed to include a User-to-User header even > > if no User-to-User header was present in INVITE request since the > > negotiation of the uui capacity can be done by uui option tag instead. > > Proposal: replace "MUST" by "MAY" in the above sentence. > > I think "MAY" is the wrong solution to this comment. If there is an > entirely different "package" header field parameter, continuing to assume > this is "isdn-uui" would be inappropriate. > > Propose rewording to: > > " The UAC MUST NOT include the User-to-User header field with an "package= " > header field parameter set to "isdn-uui", or with no "package" header > field parameter", in any message of an INVITE dialog if the original > INVITE request did not include the User-to-User header field, either with > an "package" header field parameter set to "isdn-uui", or with no > "package" header field parameter included." > > > > > C7: "Because for the ISDN UUI service, the service is service 1 > > implicit, the inclusion of the "uui" option tag in a Supported header > > field conveys no additional information over and above the presence of > > the User-to-User header field with the "package" header field > > parameter to "isdn-uui" in the INVITE request. While there is no harm > > in including the "uui" option tag, and strictly it should be included > > if the extension is supported, it performs no function" =3D> it should > > be possible, in order to declare/negotiate the uui capability, to use > > the uui option tag instead of the inclusion of User-to-User header > > even with no uui data, at least by indicating both possibilities. > > Proposal: "While there is no harm in including the "uui" option tag, > > and strictly it should be included if the extension is supported, it > > performs no function when User-to-User header is included in INVITE > > request for implicit request. Otherwise, the uui option tag is used to > > indicate that a UA supports and understands the User-to-User header > field." > > > I believe this comment is incorrect. > > While this would work in the absence of ISDN interworking, if ISDN > interworking was involved they there would be an extra complication to th= e > interworking. In ISDN it is the presence of the user-to-user information > parameter / information element in ISDN IAM / DSS1 SETUP message that > indicates the request for the service. That is why it is called implicit. > The presence of data implicitly requests the service. > > If we follow the proposal above, we effectively give the gateway two > alternates to map an empty user-user received from ISDN, and have to deal > with both those alternatives when received in SIP at the gateway. > > Moreover, in the ISDN there is no such thing as an empty user user, as it > still has to contain the protocol discriminator. I quote for example > Q.957.1: " Service 1 may be implicitly requested by including a User-to- > user information element of variable length as specified in 4.5/Q.931 [1] > in the SETUP message, transferred across the user network interface at th= e > calling side as described in 5.1.1/Q.931 [1]. This information element is > transported by the network and delivered unchanged in the User-to-user > information element included in the SETUP message transferred across the > user network interface at the called side as described in 5.2.1/Q.931 [1]= . > For activation purposes, this information element must be at least three > octets long, as defined in 4.5/Q.931 [1]." > > There are requirements elsewhere in the i-d to include the protocol > discriminator as the minimum contents of the uuidata. > > > C8: "When sending UUI for the ISDN package, the UAS MUST set the > > User-to- User "package" header field parameter to "isdn-uui" and "When > > receiving UUI, when a User-to-User header field is received in a > > request that is not from the originating user with the "package" > > header field parameter to "isdn-uui", the UAC MUST discard this header > > fields." =3D> this requires the presence of package parameter (with > > value set to "isdn-uui"). In order to be consistent with > > draft-ietf-cuss-sip-uui-04 ("If the "package" parameter is not > > present, interworking with the ISDN UUI Service MUST be assumed"), it > > would be necessary to add that when package parameter is not present, > its default value "isdn-uui" must be assumed. > > Proposal (in reception): "When receiving UUI, when a User-to-User > > header field is received in a request that is not from the originating > > user with the "package" header field parameter to "isdn-uui", the UAC > > MUST discard this header fields. When receiving UUI, if no package > > header field parameter is present, the UAC must assume its default valu= e > "isdn-uui"". > > Proposal (in emission): "When sending UUI for the ISDN package, if the > > UAS includes a User-to-User "package" header field parameter, it MUST > > set it to "isdn-uui". > > > Does the following work?: > > " When receiving UUI, when a User-to-User header field is received in a > request that is not from the originating user with the "package" header > field parameter to "isdn-uui", or with no "package" header field > parameter, the UAC MUST discard this header field." > > This is one of the many changes to encompass the non-receipt of the heade= r > field parameter. > > > C9: As done in Section 8 for UAS, it would be relevant to indicate the > > behavior of the UAC when a User-to-User header field is received in a > > response that is not with the "package" header field parameter to > > "isdn- uui" (discarded?). > > > > **Section 8** > > C4, C6 and C8 comments are also applicable in this section. > > > > I will address in accordance with any agreement on the comments above. > > > **Section 13** > > C10: "This document adds the following row to the "UUI packages" sub- > > registry of the SIP parameter registry: Value: isdn-uui" =3D> it would > > be suitable to rename the value of package parameter from "isdn-uui" > > into "isdn-interwork". The goal would to allow compatibility with > > already deployed implementations that are based on the draft-johnston > > individual draft (draft referenced since a long time in 3GPP > > documents). There would be no change regarding the meaning because the > > definitions of "isdn- interwork" and "isdn-uui" values are exactly the > > same, for ISDN interworking scenarios ("which is to interoperate with > > ISDN User to User Signaling (UUS)"). > > > > This is driven directly from the mechanism draft, so I will follow > whatever it states there. > > > > Regards, > > > > Celine Serrut-Valette > > Orange Labs > > > > -----Message d'origine----- > > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part > > de Vijay K. Gurbani Envoy=E9 : jeudi 15 d=E9cembre 2011 17:15 =C0 : > > cuss@ietf.org Objet : [cuss] Expert review of sip-uui-isdn draft > > underway > > > > Folks: Celine Serrutvalette has agreed to perform an expert review of > > the UUI ISDN draft (thanks, Celine). > > > > The expert review is due Jan-10-2012. > > > > The token for a second expert review of the SIP mechanism draft is > > with Martin Dolly. > > > > I suspect that once both these expert reviews are in, Enrico and I > > will ask the editors to modify their respective drafts and proceed to > > WGLC. > > > > Until then, y'all have a nice holiday season. > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > > Web: http://ect.bell-labs.com/who/vkg/ > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From thomas.belling@nsn.com Fri Feb 24 01:01:29 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7521F871C for ; Fri, 24 Feb 2012 01:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZKyzeDq-3Qj for ; Fri, 24 Feb 2012 01:01:27 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6521F87CA for ; Fri, 24 Feb 2012 01:01:26 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1O91Jr2028614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Feb 2012 10:01:19 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1O91INA031813; Fri, 24 Feb 2012 10:01:19 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 10:01:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 10:01:16 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F010FD24A@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Expert review of sip-uui-isdn draft underway Thread-Index: Acy7RC2xXFlGIcK9TNa956tuUgl0AgQgQXngACp8PjAJdzAYMAAA5k0gACC4AUA= References: <4EEA1CF4.4050902@bell-labs.com><843DA8228A1BA74CA31FB4E111A5C462021ABDF3@ftrdmel0.rd.francetelecom.fr> <1A8A7D59006A8240B27FF63C794CA57F010FD0F6@DEMUEXC014.nsn-intra.net> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext DRAGE, Keith (Keith)" , , X-OriginalArrivalTime: 24 Feb 2012 09:01:17.0912 (UTC) FILETIME=[DEA21580:01CCF2D2] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 21523 X-purgate-ID: 151667::1330074079-00007EDF-C657D6B0/0-0/0-0 Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 09:01:29 -0000 Thanks Keith, Seems I was mistaken. Your proposed rewording thus is fine for me. Thomas -----Original Message----- From: ext DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Thursday, February 23, 2012 6:46 PM To: Belling, Thomas (NSN - DE/Munich); celine.serrutvalette@orange.com; = cuss@ietf.org Subject: RE: [cuss] Expert review of sip-uui-isdn draft underway I think the answer is in the text you extracted in the words: " the = request for the implicit service 1 has not been discarded." But to give you some quotes from the ISDN service description, ITU-T = Recommendation Q.257.1. "2.2.7 implicit request: The UUS supplementary service is considered as = implicitly requested when no explicit request for the UUS supplementary = service is made and UUI is sent by the user when originating a call." Section: 3.2.1.1 "Service 1 can be activated by means of an implicit request or an = explicit request. Service 1 is implicitly requested when UUI is included = when originating a call. The served user shall be given an explicit = response (acceptance or rejection) to an explicit request. An explicit = request can include UUI." And from ITU-T Recommendation Q.737.1: "Service 1 may be requested implicitly by the presence of the = user-to-user information parameter in the initial address message. An = implicit request is "non-essential" by default. ... On call set-up, the initial address message will contain the = user-to-user information parameter. The user-to-user information will be = received from call control and will be transported across the network = and delivered unchanged to the terminating call control for the called = user. The user-to-user indicators parameter will not be sent. The reception of a user-to-user information parameter in a backward call = control message from the terminating call control is an implicit = indication of the acceptance of service 1." I could make further quotes from ITU-T Recommendation Q.957.1 and ITU-T = Recommendation Q.87.1 but they are all consistent in requiring the = implicit request in the origination. The stage 2 seems even more = emphatic with FEAs for checking the service is active on every data = transfer. There are only two types of requesting the service, implicit or explicit = - there is no other type. Given that both implicit and explicit requests = both refer to information included in the origination of the call (i.e. = IAM or SETUP) that is the only options available. I agree the implicit request can be empty of data, but that still means = it contains the information element identifier, the length, and the = protocol discriminator (which is a mandatory octet for the information = element). Therefore for the ISDN package, an implicit request must be in the first = message, and that implicit request must be able to transport 1 octet of = protocol discriminator. Regards Keith > -----Original Message----- > From: Belling, Thomas (NSN - DE/Munich)=20 > [mailto:thomas.belling@nsn.com] > Sent: 23 February 2012 17:11 > To: DRAGE, Keith (Keith); celine.serrutvalette@orange.com;=20 > cuss@ietf.org > Subject: RE: [cuss] Expert review of sip-uui-isdn draft underway > > Dear Keith, Celine, > > You wrote > > > > C6: "The UAC MUST NOT include the User-to-User header field with=20 > > > an "package" header field parameter set to "isdn-uui" in any=20 > > > message of an INVITE dialog if the original INVITE request did not = > > > include the > > > User-to- User header field with an "package" header field=20 > > > parameter set to "isdn- > > > uui".") =3D> it should be allowed to include a User-to-User header = > > > even if no User-to-User header was present in INVITE request since = > > > the negotiation of the uui capacity can be done by uui option tag = instead. > > > Proposal: replace "MUST" by "MAY" in the above sentence. > > > > I think "MAY" is the wrong solution to this comment. If there is an > entirely different "package" header > > field parameter, continuing to assume this is "isdn-uui" would be > inappropriate. > > > > Propose rewording to: > > > > " The UAC MUST NOT include the User-to-User header field with an > "package" header field parameter > > set to "isdn-uui", or with no "package" header field parameter", in = > > any > message of an INVITE dialog > > if the original INVITE request did not include the User-to-User=20 > > header > field, either with an "package" > > header field parameter set to "isdn-uui", or with no "package"=20 > > header > field parameter included." > > In my understanding the scope of this draft is UUS1 implicit. > We should thus aim to have comparable behavior to the ISUP service. > In my understanding (based on Q.737.1, quotation below) of ISUP UUS1=20 > implicit, UUS can be included in an ISUP response even if none was in=20 > the IAM. > > If I am correct, neither the original wording nor the proposed=20 > rewording of Keith allows for a proper interworking of the service. We = > should rather also allow "isdn-uui" within a User-to-User header in=20 > SIP responses irrespective of what was contained in the SIP request. > > > FYI I paste in the text from Q.737.1 I deem relevant: > > 1.1.5.2.1.1.3 Transfer of user-to-user information User-to-user=20 > information may be contained in any of the messages that may be=20 > transferred in the call set-up and call release phases, independently=20 > of whether the service is requested implicitly or explicitly, provided = > that the explicit service 1 has not been rejected or the request for=20 > the implicit service 1 has not been discarded. > > > Thomas > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of ext DRAGE, Keith (Keith) > Sent: Wednesday, February 22, 2012 3:18 AM > To: celine.serrutvalette@orange.com; cuss@ietf.org > Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway > > My comments below indicating my proposed handing. I'll take this as=20 > I'ved indicated for the next draft unless I see alternative proposals=20 > or objections from members of the working group in the next 5 days or = so. > > Suggest if commenting to these that those items agreed with are = removed. > > If I've missed anything do please let me know. > > Regards > > Keith > > > -----Original Message----- > > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf = > > Of celine.serrutvalette@orange.com > > Sent: 05 January 2012 17:04 > > To: cuss@ietf.org > > Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway > > > > Hello and Happy New Year, > > > > Please find our comments on draft-ietf-cuss-sip-uui-isdn-01: > > > > **Section 3.1** > > C1: "to control the request and granting of the service, as in USS2=20 > > and UUS3" =3D> just an editorial comment, "USS2" should be replaced = by > "UUS2". > > > OK > > > C2: "Only a single user information package can be transported in=20 > > each message" =3D> in order to avoid any misunderstanding, it would = be=20 > > clearer to indicate that this restriction concerns "isdn-uui"=20 > > package, so it would be in-line with section 6 where this precision=20 > > is given and with section 5 where another package could be used=20 > > (enhanced > > package) in parallel with "isdn-uui". Otherwise, without this=20 > > clarification, it could be understood as no other package is = allowed. > > Proposal: "Only a single user information package set to "isdn-uui" > > can be transported in each message". > > This sentence is talking about the ISDN service and how that works and = > its constraints, where there is no package concept. The sentence=20 > predates the use of the term "package" as part of the protocol and I=20 > guess it would be better to remove the term here to avoid confusion. I = > think just removing the word works best: "Only a single user=20 > information can be transported in each message." > > > > > **Section 5** > > C3: "the endpoint can carry the UUI data both as ISDN and as some=20 > > other package in parallel" =3D> it would be suitable to explicitly=20 > > indicate that ISDN UUI and other types of UUI using other packages=20 > > are conveyed either in the same or in different messages. > > > > > > Proposal: "the endpoint can carry the UUI data both as ISDN UUI and=20 > > as other types of UUI defined in other packages, in parallel in the=20 > > same or in different messages". > > I propose adding "depending on the needs of the application" (after=20 > same or in different), otherwise I propose to follow the proposal = here. > > > > > **Section 7** > > C4: "The UAC MUST only use this package of the UUI mechanism=20 > > extension in association with the initial INVITE method and the BYE=20 > > method relating to an INVITE dialog. Usage on transactions=20 > > associated with any other type of dialog, or on methods not=20 > > associated with a dialog is precluded." =3D> The first sentence=20 > > indicates that User-to-User header can only be conveyed in initial=20 > > INVITE request, its responses, BYE request and its responses (which=20 > > is consistent with the definition of UUS1) whereas the scope of the=20 > > second sentence is wider because it means that other methods within = the INVITE-initiated dialog (e.g. > > UPDATE) can be used to convey UUI, although only initial INVITE and=20 > > BYE > methods are allowed. > > Proposal: "The UAC MUST only use this package [...]. Usage on=20 > > transactions associated with any other type of dialog, or on methods = > > not associated with a dialog, or on methods related to an INVITE=20 > > dialog but different from initial INVITE or BYE methods is = precluded." > > > I propose to follow this, except to make the proposal a separate = sentence: > "Usage on other methods within the INVITE dialog, and on re-INVITE=20 > transactions with the INVITE dialog, is also precluded." > > > > C5: "If the UAC wishes to user or permit the sending of UUI data at=20 > > any point in the dialog, the UAC MUST include in the INVITE request=20 > > for that dialog a User-to-User header field with an "package" header = > > field parameter set to "isdn-uui". This initial header field=20 > > constitutes the implicit request to use the UUI service, and is=20 > > therefore included even when there is no data except the protocol=20 > > discriminator octet to send at that point in time." =3D> the use of=20 > > User-to-User header even with no uui data in INVITE request for=20 > > implicit request should be a possibility but not a requirement since = > > the uui option tag has been created for that purpose and allows as=20 > > well > to declare and negotiate the uui capacity. > > Proposal: replace "MUST" by "MAY" in the above sentences. > > > I guess when I wrote the above requirement, I was working on what I=20 > understood the uui mechanism draft would say, because at that time it=20 > was not available. So we need to evaluate what we need to say. > > I agree that based on the current mechanism draft, on receipt without=20 > a "package" header field parameter "uui-isdn" has to be assumed. > > For sending, I believe an explicit indication would at least be good=20 > practice. I also believe it would be confusing if for example a media=20 > feature tag indicating "sip.uui-isdn" was included but a package=20 > header field parameter was not. > > Would changing the "MUST" to a "SHOULD be an appropriate solution",=20 > along with some additional clarification. > > I would propose the text as follows: > > " If the UAC wishes to use or permit the sending of UUI data at any=20 > point in the dialog, the UAC MUST include in the INVITE request for=20 > that dialog a User-to-User header field. The UAC SHOULD set the=20 > "package" header field parameter to "isdn-uui". Non-inclusion of the=20 > "package" header field parameter is permitted, but this is primarily=20 > to allow earlier implementations to support this package. This initial = > header field constitutes the implicit request to use the UUI service,=20 > and is therefore included even when there is no data except the=20 > protocol discriminator octet to send at that point in time." > > This is also going to result in a number of changes where reception of = > the "package" field is specified, to encompass the non-inclusion with=20 > the same meaning, I propose not to elaborate these here. > > > C6: "The UAC MUST NOT include the User-to-User header field with an=20 > > "package" header field parameter set to "isdn-uui" in any message of = > > an INVITE dialog if the original INVITE request did not include the > > User-to- User header field with an "package" header field parameter=20 > > set to "isdn- > > uui".") =3D> it should be allowed to include a User-to-User header=20 > > even if no User-to-User header was present in INVITE request since=20 > > the negotiation of the uui capacity can be done by uui option tag = instead. > > Proposal: replace "MUST" by "MAY" in the above sentence. > > I think "MAY" is the wrong solution to this comment. If there is an=20 > entirely different "package" header field parameter, continuing to=20 > assume this is "isdn-uui" would be inappropriate. > > Propose rewording to: > > " The UAC MUST NOT include the User-to-User header field with an = "package" > header field parameter set to "isdn-uui", or with no "package" header=20 > field parameter", in any message of an INVITE dialog if the original=20 > INVITE request did not include the User-to-User header field, either=20 > with an "package" header field parameter set to "isdn-uui", or with no = > "package" header field parameter included." > > > > > C7: "Because for the ISDN UUI service, the service is service 1=20 > > implicit, the inclusion of the "uui" option tag in a Supported=20 > > header field conveys no additional information over and above the=20 > > presence of the User-to-User header field with the "package" header=20 > > field parameter to "isdn-uui" in the INVITE request. While there is=20 > > no harm in including the "uui" option tag, and strictly it should be = > > included if the extension is supported, it performs no function" = =3D>=20 > > it should be possible, in order to declare/negotiate the uui=20 > > capability, to use the uui option tag instead of the inclusion of=20 > > User-to-User header even with no uui data, at least by indicating = both possibilities. > > Proposal: "While there is no harm in including the "uui" option tag, = > > and strictly it should be included if the extension is supported, it = > > performs no function when User-to-User header is included in INVITE=20 > > request for implicit request. Otherwise, the uui option tag is used=20 > > to indicate that a UA supports and understands the User-to-User=20 > > header > field." > > > I believe this comment is incorrect. > > While this would work in the absence of ISDN interworking, if ISDN=20 > interworking was involved they there would be an extra complication to = > the interworking. In ISDN it is the presence of the user-to-user=20 > information parameter / information element in ISDN IAM / DSS1 SETUP=20 > message that indicates the request for the service. That is why it is = called implicit. > The presence of data implicitly requests the service. > > If we follow the proposal above, we effectively give the gateway two=20 > alternates to map an empty user-user received from ISDN, and have to=20 > deal with both those alternatives when received in SIP at the gateway. > > Moreover, in the ISDN there is no such thing as an empty user user, as = > it still has to contain the protocol discriminator. I quote for=20 > example > Q.957.1: " Service 1 may be implicitly requested by including a=20 > User-to- user information element of variable length as specified in=20 > 4.5/Q.931 [1] in the SETUP message, transferred across the user=20 > network interface at the calling side as described in 5.1.1/Q.931 [1]. = > This information element is transported by the network and delivered=20 > unchanged in the User-to-user information element included in the=20 > SETUP message transferred across the user network interface at the = called side as described in 5.2.1/Q.931 [1]. > For activation purposes, this information element must be at least=20 > three octets long, as defined in 4.5/Q.931 [1]." > > There are requirements elsewhere in the i-d to include the protocol=20 > discriminator as the minimum contents of the uuidata. > > > C8: "When sending UUI for the ISDN package, the UAS MUST set the > > User-to- User "package" header field parameter to "isdn-uui" and=20 > > "When receiving UUI, when a User-to-User header field is received in = > > a request that is not from the originating user with the "package" > > header field parameter to "isdn-uui", the UAC MUST discard this=20 > > header fields." =3D> this requires the presence of package parameter = > > (with value set to "isdn-uui"). In order to be consistent with > > draft-ietf-cuss-sip-uui-04 ("If the "package" parameter is not=20 > > present, interworking with the ISDN UUI Service MUST be assumed"),=20 > > it would be necessary to add that when package parameter is not=20 > > present, > its default value "isdn-uui" must be assumed. > > Proposal (in reception): "When receiving UUI, when a User-to-User=20 > > header field is received in a request that is not from the=20 > > originating user with the "package" header field parameter to=20 > > "isdn-uui", the UAC MUST discard this header fields. When receiving=20 > > UUI, if no package header field parameter is present, the UAC must=20 > > assume its default value > "isdn-uui"". > > Proposal (in emission): "When sending UUI for the ISDN package, if=20 > > the UAS includes a User-to-User "package" header field parameter, it = > > MUST set it to "isdn-uui". > > > Does the following work?: > > " When receiving UUI, when a User-to-User header field is received in=20 > a request that is not from the originating user with the "package"=20 > header field parameter to "isdn-uui", or with no "package" header=20 > field parameter, the UAC MUST discard this header field." > > This is one of the many changes to encompass the non-receipt of the=20 > header field parameter. > > > C9: As done in Section 8 for UAS, it would be relevant to indicate=20 > > the behavior of the UAC when a User-to-User header field is received = > > in a response that is not with the "package" header field parameter=20 > > to > > "isdn- uui" (discarded?). > > > > **Section 8** > > C4, C6 and C8 comments are also applicable in this section. > > > > I will address in accordance with any agreement on the comments above. > > > **Section 13** > > C10: "This document adds the following row to the "UUI packages"=20 > > sub- registry of the SIP parameter registry: Value: isdn-uui" =3D> = it=20 > > would be suitable to rename the value of package parameter from = "isdn-uui" > > into "isdn-interwork". The goal would to allow compatibility with=20 > > already deployed implementations that are based on the=20 > > draft-johnston individual draft (draft referenced since a long time=20 > > in 3GPP documents). There would be no change regarding the meaning=20 > > because the definitions of "isdn- interwork" and "isdn-uui" values=20 > > are exactly the same, for ISDN interworking scenarios ("which is to=20 > > interoperate with ISDN User to User Signaling (UUS)"). > > > > This is driven directly from the mechanism draft, so I will follow=20 > whatever it states there. > > > > Regards, > > > > Celine Serrut-Valette > > Orange Labs > > > > -----Message d'origine----- > > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = > > de Vijay K. Gurbani Envoy=E9 : jeudi 15 d=E9cembre 2011 17:15 =C0 : > > cuss@ietf.org Objet : [cuss] Expert review of sip-uui-isdn draft=20 > > underway > > > > Folks: Celine Serrutvalette has agreed to perform an expert review=20 > > of the UUI ISDN draft (thanks, Celine). > > > > The expert review is due Jan-10-2012. > > > > The token for a second expert review of the SIP mechanism draft is=20 > > with Martin Dolly. > > > > I suspect that once both these expert reviews are in, Enrico and I=20 > > will ask the editors to modify their respective drafts and proceed=20 > > to WGLC. > > > > Until then, y'all have a nice holiday season. > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > Email: vkg@{bell-labs.com,acm.org} / = vijay.gurbani@alcatel-lucent.com > > Web: http://ect.bell-labs.com/who/vkg/ > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Sat Feb 25 15:46:56 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEAD21F8504 for ; Sat, 25 Feb 2012 15:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.641 X-Spam-Level: X-Spam-Status: No, score=-108.641 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6FIIQXtKpxN for ; Sat, 25 Feb 2012 15:46:56 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8451C21F8522 for ; Sat, 25 Feb 2012 15:46:54 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1PNkqVX006580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 26 Feb 2012 00:46:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 26 Feb 2012 00:46:52 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Sun, 26 Feb 2012 00:46:51 +0100 Thread-Topic: Open issue in draft-ietf-cuss-sip-uui-isdn-01 Thread-Index: Acz0EIG1aP4HIjWxRjuZd81gVqASBg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [cuss] Open issue in draft-ietf-cuss-sip-uui-isdn-01 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 25 Feb 2012 23:46:56 -0000 Currently we have the following text in the draft: "ISDN conferencing allows the user to still exchange user-to-user data afte= r the conference is created. As far as UUS1 is concerned, this means that w= hen an individual party clears, those clearing messages can still contain u= ser-to-user data. As a conferee this is sent to the conference controller. = As the conference controller, as this effectively clears the conference, it= can be broadcast to all conferees, or sent to individual conferees [OPEN I= SSUE - CHECK THIS IN THE PROTOCOL - DOES IT REQUIRE EXPLICIT]." "The ISDN three-party supplementary service is similar in many ways to conf= erencing, but is signalled using a different mechanism. This means that on = clearing, the controller using UUS1 implicit does have the choice of sendin= g data to either or both remote users." Investigation of the ISDN service description in ITU-T Recommendation I.257= .1 reveals: "6.7 Conference services 6.7.1 Conference Calling (CONF) For a conference, only service 3 shall be available. NOTE 1 - However, on calls which are set up to potential conferees outside = the conference, service 1 and/or service 2 may be available. In the following paragraphs, references to the UUS supplementary service re= fer only to service 3. The UUS supplementary service cannot be activated by the conference control= ler, nor by a conferee, for communication between the participants in the c= onference. When a user is added to the conference and the UUS supplementary service ha= s been activated on the call between the conference controller and that use= r, the UUS supplementary service shall remain activated for communication b= etween the conference controller and that conferee. If the UUS supplementary service has been activated for communication betwe= en the conference controller and a conferee, then when a private communicat= ion is created with that party, the UUS supplementary service shall remain = activated for the private communication. NOTE 2 - Once this private communication is created, it is considered as a = separate call and therefore the normal procedures for the UUS supplementary= service apply. UUI can be sent by the conference controller to conferees individually, or = broadcast to all conferees. UUI can be received by the conference controlle= r from any of the conferees. The network shall identify the conferee sendin= g the UUI to the conference controller. The same limitations on the amount of UUI which can be transferred between = two users shall apply to communications between the conference controller a= nd the conference. Conferees can send UUI to and receive UUI from the conference controller. U= UI shall not be transferred between the conferees in association with the c= onference. 6.7.2 Three-Party (3PTY) During the three-way conversation, the served user of the three party suppl= ementary service can send UUI separately to each remote party of the three = party supplementary service, and the served user of the three party supplem= entary service can receive UUI separately from each remote party of the thr= ee party supplementary service. UUI shall not be transferred between the re= mote parties of the three party supplementary service." Thus for the normal ISDN conference service there is no UUS1 service and th= erefore no UUS1 implicit service. Operation in the ISDN three party service is dependent on being able to dis= tinguish two independent signalling relationships at the conferencing user.= This is not possible in SIP, no real direct equivalent of the ISDN three p= arty service exists in SIP (unless the conferencing is performed in the ser= ved user's UE). It is therefore proposed to rewrite the text as follows: "ISDN conferencing allows the user to still exchange user-to-user data afte= r the conference is created. As far as UUS1 is concerned, it is not permitt= ed." "The ISDN three-party supplementary service is similar in many ways to conf= erencing, but is signalled using a different mechanism. This means that on = clearing, the controller using UUS1 implicit does have the choice of sendin= g data to either or both remote users. Because SIP conferencing cannot comp= letely emulate the ISDN three-party supplementary service at the served use= r, UUS1 implicit is not possible." From celine.serrutvalette@orange.com Mon Feb 27 08:05:28 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A282F21F87B0 for ; Mon, 27 Feb 2012 08:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVZ6ZaK-PQVo for ; Mon, 27 Feb 2012 08:05:26 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5961221F879C for ; Mon, 27 Feb 2012 08:05:25 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AD7B75D892C; Mon, 27 Feb 2012 17:05:24 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9B4965D892B; Mon, 27 Feb 2012 17:05:24 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 17:05:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF569.9CC97CAC" Date: Mon, 27 Feb 2012 17:05:22 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462023838BC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 Thread-Index: Aczttc2jZnyaNL0mTq22+UiOMym+UwHsrzVA References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 27 Feb 2012 16:05:24.0364 (UTC) FILETIME=[9D23C4C0:01CCF569] Cc: cuss@ietf.org Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 16:05:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF569.9CC97CAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Thanks a lot for your answer. Your proposal gives the expected = clarification on multiple User-to-User headers in the draft. =20 Could you, if possible, give us your feedback on the first point raised = by Xavier Marjou in December regarding the name of the parameter to = indicate the purpose of the application usage of UUI? Indeed, moving = back to the initial parameter name "purpose" would allow compatibility = with already deployed implementations and would not change anything in = the semantics and the meaning of the parameter. Thanks in advance for = your feedback. =20 Regards, =20 Celine Serrut-Valette Orange Labs =20 De : Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Envoy=E9 : vendredi 17 f=E9vrier 2012 21:50 =C0 : SERRUT-VALETTE Celine RD-CORE-ISS Cc : cuss@ietf.org Objet : Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 =20 Celine, =20 Are you looking for a adding a statement to the draft such as: =20 A request or response may contain multiple User-to-User header fields = containing uui-data for different packages. A request or response may = also contain multiple User-to-User header fields containing uui-data for = the same package, if that package allows this. The rules for how many = User-to-User header fields of a package may be present in a request or a = response are defined for each package. =20 - Alan - =20 =20 On Jan 5, 2012, at 11:05 AM, = wrote: Hello, =20 Please find an additional comment on draft-ietf-cuss-sip-uui-04, I hope = it would not too late: =20 We would like to raise that it seems to us that it is not clear enough = that multiple User-to-User headers set to different package values are = allowed in the same message. There is a precision on how many = User-to-User headers can be present for a given package ("The rules for = how many User-to-User header field of each package may be present in a = request or a response are defined for each package be present in a = request or a response are defined for each package." in section 4.1), = but no precision on the possibility to have in parallel multiple = User-to-User headers set to different package values. Would it be = possible to give this possibility in the draft in a general way? =20 Regards, =20 Celine Serrut-Valette Orange Labs =20 =20 De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de = Martin.Huelsemann@telekom.de Envoy=E9 : mardi 13 d=E9cembre 2011 14:58 =C0 : MARJOU Xavier RD-CORE-LAN; cuss@ietf.org Objet : Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 =20 Hi all, =20 for sure a package is used for a certain purpose. So I agree with = Xavier, for the solution itself it doesn't matter if the parameter name = is 'package' or 'purpose', however the name 'purpose' would provide a = certain degree of backward compatibility. =20 Regards, Martin =20 =20 =20 =20 =09 ________________________________ Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag = von Xavier Marjou Gesendet: Freitag, 9. Dezember 2011 15:50 An: cuss@ietf.org Betreff: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 Hi, =20 Regarding draft-ietf-cuss-sip-uui-04, one modification I would like is = to rename the "package" parameter name into "purpose" which existed = until draft-ietf-cuss-sip-uui-00. The goal would to allow compatibility = with already deployed implementations that are based on the = draft-johnston individual draft (draft referenced since a long time in = 3GPP documents). There would be no change regarding the semantics: the = goal of the defined parameter is to indicate the purpose of the = application usage of UUI data and this can be fulfilled by a parameter = called "purpose", in order to indicate how and why UUI data is used. =20 Cheers, Xavier _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss =20 ------_=_NextPart_001_01CCF569.9CC97CAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Thanks a lot = for your answer. Your proposal gives the expected clarification on = multiple User-to-User headers in the draft.

 

Could you, = if possible, give us your feedback on the first point raised by Xavier = Marjou in December regarding the name of the parameter t= o indicate the purpose of the application usage of UUI? Indeed, = moving back to the initial parameter name “purpose” would = allow compatibility with already = deployed implementations and would not change anything in the = semantics and the meaning of the parameter. Thanks in advance for your = feedback.<= /span>

 

Regards,=

 

Celine = Serrut-Valette

Orange = Labs

 

De : Alan = Johnston [mailto:alan.b.johnston@gmail.com]
Envoy=E9 : = vendredi 17 f=E9vrier 2012 21:50
=C0 : SERRUT-VALETTE = Celine RD-CORE-ISS
Cc : = cuss@ietf.org
Objet : Re: [cuss] "package" vs = "purpose" name in = draft-ietf-cuss-sip-uui-04

 

Celine,

 

Are you looking for a adding a statement to the draft = such as:

 

A = request or response may contain multiple User-to-User header fields = containing uui-data for different packages.  A request or response = may also contain multiple User-to-User header fields containing uui-data = for the same package, if that package allows this.  The rules for = how many User-to-User header fields of a package may be present in = a request or a response are defined for each = package.

 

- = Alan -

 

 



Hello,

 

Please find an = additional comment on draft-ietf-cuss-sip-uui-04, I hope it would not = too late:

 

We would like to raise = that it seems to us that it is not clear enough that multiple = User-to-User headers set to different package values are allowed in the = same message. There is a precision on how many User-to-User headers can = be present for a given package (“The rules for how many = User-to-User header field of each package may be present in a request or = a response are defined for each package be present in a request or a = response are defined for each package.” in section 4.1), but no = precision on the possibility to have in parallel multiple User-to-User = headers set to different package values. Would it be possible to give = this possibility in the draft in a general way?

 

Regards,

 <= /p>

Celine = Serrut-Valette

Orange = Labs

 

 

De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org]=  De la part = de Martin.Huelsemann@telekom.de=
Envoy=E9 : mardi 13 d=E9cembre 2011 = 14:58
=C0 : MARJOU Xavier = RD-CORE-LAN; cuss@ietf.org
Objet : Re: [cuss] = "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04

 

Hi= all,

 

fo= r sure a package is used for a certain purpose. So I agree with Xavier, = for the solution itself it doesn't matter if the parameter name is = 'package' or 'purpose', however the name 'purpose' would provide a = certain degree of backward = compatibility.

 

Re= gards, Martin

 

 

 

 

Von:<= /b> cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org]=  Im Auftrag von Xavier = Marjou
Gesendet: Freitag, 9. Dezember 2011 = 15:50
An: cuss@ietf.org
Betreff: [cuss] "package" vs = "purpose" name in = draft-ietf-cuss-sip-uui-04

H= i,

 

R= egarding draft-ietf-cuss-sip-uui-04, one modification I would like is to = rename the “package” parameter name into = “purpose” which existed until draft-ietf-cuss-sip-uui-00. = The goal would to allow compatibility with already deployed = implementations that are based on the draft-johnston individual draft = (draft referenced since a long time in 3GPP documents). There would be = no change regarding t= he semantics: the goal of the defined parameter is to indicate the = purpose of the application usage of UUI data and this can be fulfilled = by a parameter called “purpose”, in order to indicate how = and why UUI data is used.

 

Cheers,

Xavier

_______________________________________________
cuss= mailing list
cuss@ietf.org
https://www.ietf.org/= mailman/listinfo/cuss

 

------_=_NextPart_001_01CCF569.9CC97CAC-- From keith.drage@alcatel-lucent.com Mon Feb 27 09:39:18 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0221F8780 for ; Mon, 27 Feb 2012 09:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.379 X-Spam-Level: X-Spam-Status: No, score=-109.379 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqZz+KE4hlrD for ; Mon, 27 Feb 2012 09:39:18 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id C9C7221F87B8 for ; Mon, 27 Feb 2012 09:39:17 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1RHVhPR007777 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Feb 2012 18:31:43 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 27 Feb 2012 18:31:43 +0100 From: "DRAGE, Keith (Keith)" To: "celine.serrutvalette@orange.com" , "alan.b.johnston@gmail.com" Date: Mon, 27 Feb 2012 18:31:42 +0100 Thread-Topic: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 Thread-Index: Aczttc2jZnyaNL0mTq22+UiOMym+UwHsrzVAAAIOt1A= Message-ID: References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462023838BC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462023838BC@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "cuss@ietf.org" Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 17:39:19 -0000 The answers I gave were obviously from the perspective of the editor of the= ISDN package draft. As regards the naming of the header field parameter, I regard the prime sou= rce of this as the ABNF which appears in the generic mechanism draft, and t= he ISDN package draft will follow whatever the generic mechanism draft stat= es. Obviously this cannot appear in the ISDN package draft until that determina= tion has been made. I would note that the name of the parameter has varied over the years so it= is very specific to version an implementation has been build against: draft-johnston-sipping-cc-uui-00, -01 no parameters at all draft-johnston-sipping-cc-uui-02, -03, -04, -05, -06, -07 only the encoding header field parameter draft-johnston-sipping-cc-uui-08, -09, draft-johnston-cuss-sip-uui-00, -01,= draft-ietf-cuss-sip-uui-00 encoding, content and purpose header field parameters draft-ietf-cuss-sip-uui-01, 02 "purpose" changed to "app" draft-ietf-cuss-sip-uui-03, -04 "app" changed to "package" One thing to note with regard to interoperability is that all versions that= have contained a parameter of any form have shown examples with lower case= hex encodings. So which version or versions are we trying to main compatib= ility with? At the end of the day, I personally do not mind what it is called - but we = do need a parameter (with an appropriate name) to cater for the package con= cept (which is written into the charter) and I would certainly resist going= back to the "app" name which caused the name to be used in the document wi= th two different semantics. Regards Keith ________________________________________ From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of cel= ine.serrutvalette@orange.com Sent: 27 February 2012 16:05 To: alan.b.johnston@gmail.com Cc: cuss@ietf.org Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-= 04 Hello, Thanks a lot for your answer. Your proposal gives the expected clarificatio= n on multiple User-to-User headers in the draft. Could you, if possible, give us your feedback on the first point raised by = Xavier Marjou in December regarding the name of the parameter to indicate t= he purpose of the application usage of UUI? Indeed, moving back to the init= ial parameter name "purpose" would allow compatibility with already deploye= d implementations and would not change anything in the semantics and the me= aning of the parameter. Thanks in advance for your feedback. Regards, Celine Serrut-Valette Orange Labs De=A0: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Envoy=E9=A0: vendredi 17 f=E9vrier 2012 21:50 =C0=A0: SERRUT-VALETTE Celine RD-CORE-ISS Cc=A0: cuss@ietf.org Objet=A0: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui= -04 Celine, Are you looking for a adding a statement to the draft such as: A request or response may contain multiple User-to-User header fields conta= ining uui-data for different packages. =A0A request or response may also co= ntain multiple User-to-User header fields containing uui-data for the same = package, if that package allows this. =A0The rules for how many User-to-Use= r header fields of a package may be present in a=A0request or a response ar= e defined for each package. - Alan - On Jan 5, 2012, at 11:05 AM, wrote: Hello, =A0 Please find an additional comment on draft-ietf-cuss-sip-uui-04, I hope it = would not too late: =A0 We would like to raise that it seems to us that it is not clear enough that= multiple User-to-User headers set to different package values are allowed = in the same message. There is a precision on how many User-to-User headers = can be present for a given package ("The rules for how many User-to-User he= ader field of each package may be present in a request or a response are de= fined for each package be present in a request or a response are defined fo= r each package." in section 4.1), but no precision on the possibility to ha= ve in parallel multiple User-to-User headers set to different package value= s. Would it be possible to give this possibility in the draft in a general = way? =A0 Regards, =A0 Celine Serrut-Valette Orange Labs =A0 =A0 De=A0:=A0cuss-bounces@ietf.org=A0[mailto:cuss-bounces@ietf.org]=A0De la par= t de=A0Martin.Huelsemann@telekom.de Envoy=E9=A0:=A0mardi 13 d=E9cembre 2011 14:58 =C0=A0:=A0MARJOU Xavier RD-CORE-LAN;=A0cuss@ietf.org Objet=A0:=A0Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-u= ui-04 =A0 Hi all, =A0 for sure a package is used for a certain purpose. So I agree with Xavier, f= or the solution itself it doesn't matter if the parameter name is 'package'= or 'purpose', however the name 'purpose' would provide a certain degree of= backward compatibility. =A0 Regards, Martin =A0 =A0 =A0 =A0 ________________________________________ Von:=A0cuss-bounces@ietf.org=A0[mailto:cuss-bounces@ietf.org]=A0Im Auftrag = von=A0Xavier Marjou Gesendet:=A0Freitag, 9. Dezember 2011 15:50 An:=A0cuss@ietf.org Betreff:=A0[cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 Hi, =A0 Regarding draft-ietf-cuss-sip-uui-04, one modification I would like is to r= ename the "package" parameter name into "purpose" which existed until draft= -ietf-cuss-sip-uui-00. The goal would to allow compatibility with already d= eployed implementations that are based on the draft-johnston individual dra= ft (draft referenced since a long time in 3GPP documents). There would be n= o change regarding=A0the semantics: the goal of the defined parameter is to= indicate the purpose of the application usage of UUI data and this can be = fulfilled by a parameter called "purpose", in order to indicate how and why= UUI data is used. =A0 Cheers, Xavier _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From internet-drafts@ietf.org Mon Feb 27 09:41:37 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA44621F87BD; Mon, 27 Feb 2012 09:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-f8fLotqofQ; Mon, 27 Feb 2012 09:41:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1365621F87BF; Mon, 27 Feb 2012 09:41:37 -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.00 Message-ID: <20120227174137.18268.6411.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 09:41:37 -0800 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-02.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 17:41:37 -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 Work= ing Group of the IETF. Title : Interworking ISDN Call Control User Information with SIP Author(s) : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-02.txt Pages : 18 Date : 2012-02-27 The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-02.txt From keith.drage@alcatel-lucent.com Mon Feb 27 09:49:49 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C4421F85AD for ; Mon, 27 Feb 2012 09:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.413 X-Spam-Level: X-Spam-Status: No, score=-109.413 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfHyig0j1J8z for ; Mon, 27 Feb 2012 09:49:48 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2321B21F844C for ; Mon, 27 Feb 2012 09:49:47 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1RHnk04005763 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 27 Feb 2012 18:49:46 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 27 Feb 2012 18:49:46 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Mon, 27 Feb 2012 18:49:45 +0100 Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-02.txt Thread-Index: Acz1dxzmYKpoCfdTRo6pyBg8z6Aa9QAAFpug Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [cuss] FW: I-D Action: draft-ietf-cuss-sip-uui-isdn-02.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 17:49:49 -0000 I have just posted a new version of this document based on the proposals I = made last week. http://www.ietf.org/id/draft-ietf-cuss-sip-uui-isdn-02.txt=20 The changes are summarized as follows: Changes since made in the creation of the draft-ietf-cuss-sip-uui-isdn-02 version from the draft-ietf-cuss-sip-uui-isdn-01 version. The inclusion of the "package" header field parameter has be downgraded to "RECOMMENDED", with the purpose stated as being for interworking. Changes have been made to the procedures at the receiving side to allow for the non-inclusion of the "package" header field parameter. The effect of this is that the absence of the "package" header field parameter means by default the use of the "uui-isdn" package. Clarification that the package is not to be used on re-INVITE transactions or on other transations within an INVITE dialog. Further clarification on using this package in conjunction with other packages. Closure of the remaining open issue relating to use of UUS1 in conjunction with the ISDN conference service - UUS1 is not possible after the conference is created. A number of editorial changes have been made. Differences from the previous version can be more fully identified here (or= using any of the other differences tools on the tools page): http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-cuss-si= p-uui-isdn-02.txt=20 Obviously the contents are dependent on any changes currently being discuss= ed on the mechanism draft, so I expect to issue another version if revision= s there require it. In any case, any comments or issues are welcome. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 27 February 2012 17:42 > To: i-d-announce@ietf.org > Cc: cuss@ietf.org > Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Call Control UUI Service fo= r > SIP Working Group of the IETF. >=20 > Title : Interworking ISDN Call Control User Information > with SIP > Author(s) : Keith Drage > Alan Johnston > Filename : draft-ietf-cuss-sip-uui-isdn-02.txt > Pages : 18 > Date : 2012-02-27 >=20 > The motivation and use cases for interworking and transporting ITU-T > DSS1 User-user information element data in SIP are described in the > "Problem Statement and Requirements for Transporting User to User > Call Control Information in SIP" document. As networks move to SIP > it is important that applications requiring this data can continue to > function in SIP networks as well as the ability to interwork with > this ISDN service for end-to- end transparency. This document > defines a usage of the User-to-User header field to enable > interworking with this ISDN service. >=20 > This document covers the interworking with both public ISDN and > private ISDN capabilities, so the potential interworking with QSIG > will also be addressed. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-02.txt >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Mon Feb 27 09:51:56 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B712421F878E for ; Mon, 27 Feb 2012 09:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvrlrZozLevb for ; Mon, 27 Feb 2012 09:51:55 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56121F8783 for ; Mon, 27 Feb 2012 09:51:55 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1912849obb.31 for ; Mon, 27 Feb 2012 09:51:54 -0800 (PST) Received-SPF: pass (google.com: domain of alan.b.johnston@gmail.com designates 10.182.231.38 as permitted sender) client-ip=10.182.231.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of alan.b.johnston@gmail.com designates 10.182.231.38 as permitted sender) smtp.mail=alan.b.johnston@gmail.com; dkim=pass header.i=alan.b.johnston@gmail.com Received: from mr.google.com ([10.182.231.38]) by 10.182.231.38 with SMTP id td6mr5267339obc.47.1330365114960 (num_hops = 1); Mon, 27 Feb 2012 09:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IaUGjUd0OhW6bbNQ31yEFozmiMCCOBpFTOfv+41lgic=; b=uQpZ62lI22gdsx294euZdwSZJBiEGH+5HMLkgz9MeAhkxcwg+7h2dFYrrHPBNAlHf9 miuy5sLhf6vI0iQkKFNi6ZHg99zN+US+mZwVZVINKW7HPCcW6ad/LUFzrvChAt/FqPMG yon/HqCkVrMwzS6O7A5SZCvmSb/E/+mNknSwQ= MIME-Version: 1.0 Received: by 10.182.231.38 with SMTP id td6mr4704821obc.47.1330365114882; Mon, 27 Feb 2012 09:51:54 -0800 (PST) Received: by 10.182.37.166 with HTTP; Mon, 27 Feb 2012 09:51:54 -0800 (PST) In-Reply-To: References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462023838BC@ftrdmel0.rd.francetelecom.fr> Date: Mon, 27 Feb 2012 11:51:54 -0600 Message-ID: From: Alan Johnston To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 17:51:57 -0000 Keith is right - we have changed the parameter names a bunch of times to try to find ones that were a good fit. Package seems to be a good fit. I would be very reluctant to change it back to any of the other old ones. If there is a new name that is an even better fit, then I'm open to that, but it would have to be a really good name! - Alan - On Mon, Feb 27, 2012 at 11:31 AM, DRAGE, Keith (Keith) wrote: > The answers I gave were obviously from the perspective of the editor of t= he ISDN package draft. > > As regards the naming of the header field parameter, I regard the prime s= ource of this as the ABNF which appears in the generic mechanism draft, and= the ISDN package draft will follow whatever the generic mechanism draft st= ates. > > Obviously this cannot appear in the ISDN package draft until that determi= nation has been made. > > I would note that the name of the parameter has varied over the years so = it is very specific to version an implementation has been build against: > > draft-johnston-sipping-cc-uui-00, -01 > > no parameters at all > > draft-johnston-sipping-cc-uui-02, -03, -04, -05, -06, -07 > > only the encoding header field parameter > > draft-johnston-sipping-cc-uui-08, -09, draft-johnston-cuss-sip-uui-00, -0= 1, draft-ietf-cuss-sip-uui-00 > > encoding, content and purpose header field parameters > > draft-ietf-cuss-sip-uui-01, 02 > > "purpose" changed to "app" > > draft-ietf-cuss-sip-uui-03, -04 > > "app" changed to "package" > > One thing to note with regard to interoperability is that all versions th= at have contained a parameter of any form have shown examples with lower ca= se hex encodings. So which version or versions are we trying to main compat= ibility with? > > At the end of the day, I personally do not mind what it is called - but w= e do need a parameter (with an appropriate name) to cater for the package c= oncept (which is written into the charter) and I would certainly resist goi= ng back to the "app" name which caused the name to be used in the document = with two different semantics. > > Regards > > Keith > > > ________________________________________ > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of c= eline.serrutvalette@orange.com > Sent: 27 February 2012 16:05 > To: alan.b.johnston@gmail.com > Cc: cuss@ietf.org > Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uu= i-04 > > Hello, > > Thanks a lot for your answer. Your proposal gives the expected clarificat= ion on multiple User-to-User headers in the draft. > > Could you, if possible, give us your feedback on the first point raised b= y Xavier Marjou in December regarding the name of the parameter to indicate= the purpose of the application usage of UUI? Indeed, moving back to the in= itial parameter name "purpose" would allow compatibility with already deplo= yed implementations and would not change anything in the semantics and the = meaning of the parameter. Thanks in advance for your feedback. > > Regards, > > Celine Serrut-Valette > Orange Labs > > De=A0: Alan Johnston [mailto:alan.b.johnston@gmail.com] > Envoy=E9=A0: vendredi 17 f=E9vrier 2012 21:50 > =C0=A0: SERRUT-VALETTE Celine RD-CORE-ISS > Cc=A0: cuss@ietf.org > Objet=A0: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-u= ui-04 > > Celine, > > Are you looking for a adding a statement to the draft such as: > > A request or response may contain multiple User-to-User header fields con= taining uui-data for different packages. =A0A request or response may also = contain multiple User-to-User header fields containing uui-data for the sam= e package, if that package allows this. =A0The rules for how many User-to-U= ser header fields of a package may be present in a=A0request or a response = are defined for each package. > > - Alan - > > > On Jan 5, 2012, at 11:05 AM, wrote: > > Hello, > > Please find an additional comment on draft-ietf-cuss-sip-uui-04, I hope i= t would not too late: > > We would like to raise that it seems to us that it is not clear enough th= at multiple User-to-User headers set to different package values are allowe= d in the same message. There is a precision on how many User-to-User header= s can be present for a given package ("The rules for how many User-to-User = header field of each package may be present in a request or a response are = defined for each package be present in a request or a response are defined = for each package." in section 4.1), but no precision on the possibility to = have in parallel multiple User-to-User headers set to different package val= ues. Would it be possible to give this possibility in the draft in a genera= l way? > > Regards, > > Celine Serrut-Valette > Orange Labs > > > De=A0:=A0cuss-bounces@ietf.org=A0[mailto:cuss-bounces@ietf.org]=A0De la p= art de=A0Martin.Huelsemann@telekom.de > Envoy=E9=A0:=A0mardi 13 d=E9cembre 2011 14:58 > =C0=A0:=A0MARJOU Xavier RD-CORE-LAN;=A0cuss@ietf.org > Objet=A0:=A0Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip= -uui-04 > > Hi all, > > for sure a package is used for a certain purpose. So I agree with Xavier,= for the solution itself it doesn't matter if the parameter name is 'packag= e' or 'purpose', however the name 'purpose' would provide a certain degree = of backward compatibility. > > Regards, Martin > > > > > ________________________________________ > Von:=A0cuss-bounces@ietf.org=A0[mailto:cuss-bounces@ietf.org]=A0Im Auftra= g von=A0Xavier Marjou > Gesendet:=A0Freitag, 9. Dezember 2011 15:50 > An:=A0cuss@ietf.org > Betreff:=A0[cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-= 04 > Hi, > > Regarding draft-ietf-cuss-sip-uui-04, one modification I would like is to= rename the "package" parameter name into "purpose" which existed until dra= ft-ietf-cuss-sip-uui-00. The goal would to allow compatibility with already= deployed implementations that are based on the draft-johnston individual d= raft (draft referenced since a long time in 3GPP documents). There would be= no change regarding=A0the semantics: the goal of the defined parameter is = to indicate the purpose of the application usage of UUI data and this can b= e fulfilled by a parameter called "purpose", in order to indicate how and w= hy UUI data is used. > > Cheers, > Xavier > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From pkyzivat@alum.mit.edu Mon Feb 27 09:59:09 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7C21F87A8 for ; Mon, 27 Feb 2012 09:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGFRN3vgicmr for ; Mon, 27 Feb 2012 09:59:09 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85421F879E for ; Mon, 27 Feb 2012 09:59:08 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id f5vi1i0041YDfWL5A5z9Q4; Mon, 27 Feb 2012 17:59:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id f5z91i01207duvL3g5z9EL; Mon, 27 Feb 2012 17:59:09 +0000 Message-ID: <4F4BC46B.5070407@alum.mit.edu> Date: Mon, 27 Feb 2012 12:59:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cuss@ietf.org References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462023838BC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 17:59:09 -0000 On 2/27/12 12:51 PM, Alan Johnston wrote: > Package seems to be a good fit. I would be very reluctant to change > it back to any of the other old ones. If there is a new name that is > an even better fit, then I'm open to that, but it would have to be a > really good name! XYZZY ? :-) Thanks, Paul From celine.serrutvalette@orange.com Tue Feb 28 05:07:31 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0625921F85D5 for ; Tue, 28 Feb 2012 05:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ss30K+qjvl9 for ; Tue, 28 Feb 2012 05:07:30 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id A565321F85D9 for ; Tue, 28 Feb 2012 05:07:27 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6CA88E307F9; Tue, 28 Feb 2012 14:08:26 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 64D40E307F8; Tue, 28 Feb 2012 14:08:26 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 14:07:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2012 14:07:25 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202383A66@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 Thread-Index: Acz1eH+Yl73MK/5nSzK4MqIqabY8SwAn5Mng References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com><843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr><843DA8228A1BA74CA31FB4E111A5C462023838BC@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 28 Feb 2012 13:07:26.0392 (UTC) FILETIME=[EAFC4B80:01CCF619] Cc: cuss@ietf.org Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 13:07:31 -0000 Hello, Thank you for your answers.=20 We think that what is important is the definition we give to the = parameter and the fact that its name matches to this definition, more = than the name itself. "purpose" is a relevant name if the parameter is = defined as to indicate the purpose of the package mechanism used to = convey the IUU data. Moreover it has the benefit to be backward = compatible with historical draft-johnston-sipping-cc-uui-08 on which = some implementations are based. Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Envoy=E9=A0: lundi 27 f=E9vrier 2012 18:52 =C0=A0: DRAGE, Keith (Keith) Cc=A0: SERRUT-VALETTE Celine RD-CORE-ISS; cuss@ietf.org Objet=A0: Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 Keith is right - we have changed the parameter names a bunch of times to try to find ones that were a good fit. Package seems to be a good fit. I would be very reluctant to change it back to any of the other old ones. If there is a new name that is an even better fit, then I'm open to that, but it would have to be a really good name! - Alan - On Mon, Feb 27, 2012 at 11:31 AM, DRAGE, Keith (Keith) wrote: > The answers I gave were obviously from the perspective of the editor = of the ISDN package draft. > > As regards the naming of the header field parameter, I regard the = prime source of this as the ABNF which appears in the generic mechanism = draft, and the ISDN package draft will follow whatever the generic = mechanism draft states. > > Obviously this cannot appear in the ISDN package draft until that = determination has been made. > > I would note that the name of the parameter has varied over the years = so it is very specific to version an implementation has been build = against: > > draft-johnston-sipping-cc-uui-00, -01 > > no parameters at all > > draft-johnston-sipping-cc-uui-02, -03, -04, -05, -06, -07 > > only the encoding header field parameter > > draft-johnston-sipping-cc-uui-08, -09, draft-johnston-cuss-sip-uui-00, = -01, draft-ietf-cuss-sip-uui-00 > > encoding, content and purpose header field parameters > > draft-ietf-cuss-sip-uui-01, 02 > > "purpose" changed to "app" > > draft-ietf-cuss-sip-uui-03, -04 > > "app" changed to "package" > > One thing to note with regard to interoperability is that all versions = that have contained a parameter of any form have shown examples with = lower case hex encodings. So which version or versions are we trying to = main compatibility with? > > At the end of the day, I personally do not mind what it is called - = but we do need a parameter (with an appropriate name) to cater for the = package concept (which is written into the charter) and I would = certainly resist going back to the "app" name which caused the name to = be used in the document with two different semantics. > > Regards > > Keith > > > ________________________________________ > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf = Of celine.serrutvalette@orange.com > Sent: 27 February 2012 16:05 > To: alan.b.johnston@gmail.com > Cc: cuss@ietf.org > Subject: Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 > > Hello, > > Thanks a lot for your answer. Your proposal gives the expected = clarification on multiple User-to-User headers in the draft. > > Could you, if possible, give us your feedback on the first point = raised by Xavier Marjou in December regarding the name of the parameter = to indicate the purpose of the application usage of UUI? Indeed, moving = back to the initial parameter name "purpose" would allow compatibility = with already deployed implementations and would not change anything in = the semantics and the meaning of the parameter. Thanks in advance for = your feedback. > > Regards, > > Celine Serrut-Valette > Orange Labs > > De=A0: Alan Johnston [mailto:alan.b.johnston@gmail.com] > Envoy=E9=A0: vendredi 17 f=E9vrier 2012 21:50 > =C0=A0: SERRUT-VALETTE Celine RD-CORE-ISS > Cc=A0: cuss@ietf.org > Objet=A0: Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 > > Celine, > > Are you looking for a adding a statement to the draft such as: > > A request or response may contain multiple User-to-User header fields = containing uui-data for different packages. =A0A request or response may = also contain multiple User-to-User header fields containing uui-data for = the same package, if that package allows this. =A0The rules for how many = User-to-User header fields of a package may be present in a=A0request or = a response are defined for each package. > > - Alan - > > > On Jan 5, 2012, at 11:05 AM, = wrote: > > Hello, > > Please find an additional comment on draft-ietf-cuss-sip-uui-04, I = hope it would not too late: > > We would like to raise that it seems to us that it is not clear enough = that multiple User-to-User headers set to different package values are = allowed in the same message. There is a precision on how many = User-to-User headers can be present for a given package ("The rules for = how many User-to-User header field of each package may be present in a = request or a response are defined for each package be present in a = request or a response are defined for each package." in section 4.1), = but no precision on the possibility to have in parallel multiple = User-to-User headers set to different package values. Would it be = possible to give this possibility in the draft in a general way? > > Regards, > > Celine Serrut-Valette > Orange Labs > > > De=A0:=A0cuss-bounces@ietf.org=A0[mailto:cuss-bounces@ietf.org]=A0De = la part de=A0Martin.Huelsemann@telekom.de > Envoy=E9=A0:=A0mardi 13 d=E9cembre 2011 14:58 > =C0=A0:=A0MARJOU Xavier RD-CORE-LAN;=A0cuss@ietf.org > Objet=A0:=A0Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 > > Hi all, > > for sure a package is used for a certain purpose. So I agree with = Xavier, for the solution itself it doesn't matter if the parameter name = is 'package' or 'purpose', however the name 'purpose' would provide a = certain degree of backward compatibility. > > Regards, Martin > > > > > ________________________________________ > Von:=A0cuss-bounces@ietf.org=A0[mailto:cuss-bounces@ietf.org]=A0Im = Auftrag von=A0Xavier Marjou > Gesendet:=A0Freitag, 9. Dezember 2011 15:50 > An:=A0cuss@ietf.org > Betreff:=A0[cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 > Hi, > > Regarding draft-ietf-cuss-sip-uui-04, one modification I would like is = to rename the "package" parameter name into "purpose" which existed = until draft-ietf-cuss-sip-uui-00. The goal would to allow compatibility = with already deployed implementations that are based on the = draft-johnston individual draft (draft referenced since a long time in = 3GPP documents). There would be no change regarding=A0the semantics: the = goal of the defined parameter is to indicate the purpose of the = application usage of UUI data and this can be fulfilled by a parameter = called "purpose", in order to indicate how and why UUI data is used. > > Cheers, > Xavier > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Wed Feb 29 03:35:55 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC6821F87A9 for ; Wed, 29 Feb 2012 03:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.472 X-Spam-Level: X-Spam-Status: No, score=-109.472 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgJjHIWoFJ4y for ; Wed, 29 Feb 2012 03:35:55 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id BDAB321F8843 for ; Wed, 29 Feb 2012 03:35:53 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1TBZp4M004130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 29 Feb 2012 12:35:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 29 Feb 2012 12:35:51 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Wed, 29 Feb 2012 12:33:28 +0100 Thread-Topic: Encoding of protocol discriminator in the uui-isdn package Thread-Index: Acz21fTq47Z7YSQ3TpOgK31SiHTBSQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [cuss] Encoding of protocol discriminator in the uui-isdn package X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 11:35:55 -0000 In trying to sort our whether we have adequately specified the protocol dis= criminator (I think we have), I notice that I have been using the term "pay= load" and "UUI payload" in the package draft. It looks to me like the mechanism draft uses the term "UUI data" to refer t= o the material that goes in the ABNF construct=20 "uui-data =3D token / quoted-string" I propose to replace the ISDN package terminology with "UUI data" to be con= sistent assuming I see no objections. It may be worth checking the mechanism draft to ensure this term is used on= ly in the context identified above in the mechanism draft (and therefore do= es not encompass the header field parameters as well). Responses? Keith From keith.drage@alcatel-lucent.com Wed Feb 29 03:46:36 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A715621F8895 for ; Wed, 29 Feb 2012 03:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.499 X-Spam-Level: X-Spam-Status: No, score=-107.499 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gfvv5fnqibQ for ; Wed, 29 Feb 2012 03:46:36 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id B2C4921F8899 for ; Wed, 29 Feb 2012 03:46:35 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1TBjuRg023254 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 29 Feb 2012 12:46:32 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 29 Feb 2012 12:46:17 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Wed, 29 Feb 2012 12:46:16 +0100 Thread-Topic: Default content and encoding in ISDN package Thread-Index: Acz2177gmBvK+bO7SYC04GbTYjilmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [cuss] Default content and encoding in ISDN package X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 11:46:36 -0000 The mechanism draft uses the term default a number of times in regard to th= e "content" and "encoding" header field parameters and indicates the packag= es will define the default. In the ISDN package, the only point this really= gets mentioned is in the IANA registration, although it is otherwise cover= ed. I proposed to amend the following section 9 text: When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". As below: The default and only content defined for this package is "isdn-uui".=20 When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". The default and only encoding defined for this package is "hex".=20 When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". Does anybody have objections to this change, or indeed a better wording? Regards Keith From pkyzivat@alum.mit.edu Wed Feb 29 07:12:12 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF6A21F865D for ; Wed, 29 Feb 2012 07:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlpYFsFpU8+j for ; Wed, 29 Feb 2012 07:12:12 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0BABB21F8603 for ; Wed, 29 Feb 2012 07:12:11 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id frAa1i0081swQuc57rCC2M; Wed, 29 Feb 2012 15:12:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id frCC1i00P07duvL3brCCXo; Wed, 29 Feb 2012 15:12:12 +0000 Message-ID: <4F4E404A.2040506@alum.mit.edu> Date: Wed, 29 Feb 2012 10:12:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cuss] Default content and encoding in ISDN package X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 15:12:12 -0000 Before further tweaking the wording, I'll ask a question: Suppose we eventually define other encodings. Is there any reason that those other encodings could not be used with isdn-uui, assuming the sender and the recipient support them? I would be inclined to be a little less rigid about rejecting other encodings. (IOW I think that support for encodings should be orthogonal to support for different content values.) Thanks, Paul On 2/29/12 6:46 AM, DRAGE, Keith (Keith) wrote: > The mechanism draft uses the term default a number of times in regard to the "content" and "encoding" header field parameters and indicates the packages will define the default. In the ISDN package, the only point this really gets mentioned is in the IANA registration, although it is otherwise covered. I proposed to amend the following section 9 text: > > When sending UUI, the sending SIP entity MAY, but need not, include a > "content" header field with a value set to "isdn-uui". A receiving > SIP entity MUST ignore a received User-to-User header field if the > "content" header field parameter is present and the value is some > other value that "isdn-uui". > > When sending UUI, the sending SIP entity MAY, but need not, include > an "encoding" header field with a value set to "hex". A receiving > SIP entity MUST ignore a received User-to-User header field if the > "encoding" header field parameter is present and the value is some > other value that "hex". > > As below: > > The default and only content defined for this package is "isdn-uui". > When sending UUI, the sending SIP entity MAY, but need not, include a > "content" header field with a value set to "isdn-uui". A receiving > SIP entity MUST ignore a received User-to-User header field if the > "content" header field parameter is present and the value is some > other value that "isdn-uui". > > The default and only encoding defined for this package is "hex". > When sending UUI, the sending SIP entity MAY, but need not, include > an "encoding" header field with a value set to "hex". A receiving > SIP entity MUST ignore a received User-to-User header field if the > "encoding" header field parameter is present and the value is some > other value that "hex". > > Does anybody have objections to this change, or indeed a better wording? > > Regards > > Keith > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Wed Feb 29 08:10:24 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4475121F86C6 for ; Wed, 29 Feb 2012 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.458 X-Spam-Level: X-Spam-Status: No, score=-107.458 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK1Yw036CpFY for ; Wed, 29 Feb 2012 08:10:23 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 05B0121F8566 for ; Wed, 29 Feb 2012 08:10:22 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1TGA7dO018334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Feb 2012 17:10:16 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 29 Feb 2012 17:09:48 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "cuss@ietf.org" Date: Wed, 29 Feb 2012 17:09:47 +0100 Thread-Topic: [cuss] Default content and encoding in ISDN package Thread-Index: Acz29JGOJubG7WJQTI2L1Yp0Y/mstAAAeyqw Message-ID: References: <4F4E404A.2040506@alum.mit.edu> In-Reply-To: <4F4E404A.2040506@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [cuss] Default content and encoding in ISDN package X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 16:10:24 -0000 At the moment additional valued are not needed for the ISDN package, and I = don't see how they would be used in the future given the constraint on inte= rworking - what is sent must be interworkable. The current wording of the generic document is that the package (and theref= ore the package document) should define which content values and which enco= ding values can be used, and which is the default. So in terms of the words I proposed to change that change would appear to b= e needed. You question is a different issue on text that was already in the -00 versi= on of the author draft. In response to that, I guess there are three considerations: 1) If the content or encoding is something I do not understand at all, then= the text as written is the only possible action. For example, I should not= treat a received content value of "xxxx" as if it was "uui-isdn". 2) If the content or encoding is something defined as applicable in another= package, that is also implemented by the UA, then I guess the question is = can the UA place a sufficiently valid interpretation on that in order to re= nder it? I am not entirely convinced it can but seek other opinions. 3) If the content or encoding is something defined as applicable in a updat= e or replacement RFC for the same package, then we surely need some rules f= or that occurring in the generic mechanism draft. What are those rules? We have agreed in the past that extensions to both these values have to be = defined by RFC (general). I'd also note that the general principle of this package (uui-isdn) at leas= t is throw away if it does not meet the rules or cannot be interworked. Thr= ow away if too long. Throw away if in wrong message. Etc. If you wanted to = do something else for many of these, doesn't that make it a different packa= ge. What does the working group want? Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 29 February 2012 15:12 > To: cuss@ietf.org > Subject: Re: [cuss] Default content and encoding in ISDN package >=20 > Before further tweaking the wording, I'll ask a question: >=20 > Suppose we eventually define other encodings. Is there any reason that > those other encodings could not be used with isdn-uui, assuming the > sender and the recipient support them? >=20 > I would be inclined to be a little less rigid about rejecting other > encodings. (IOW I think that support for encodings should be orthogonal > to support for different content values.) >=20 > Thanks, > Paul >=20 >=20 > On 2/29/12 6:46 AM, DRAGE, Keith (Keith) wrote: > > The mechanism draft uses the term default a number of times in regard t= o > the "content" and "encoding" header field parameters and indicates the > packages will define the default. In the ISDN package, the only point thi= s > really gets mentioned is in the IANA registration, although it is > otherwise covered. I proposed to amend the following section 9 text: > > > > When sending UUI, the sending SIP entity MAY, but need not, include > a > > "content" header field with a value set to "isdn-uui". A receiving > > SIP entity MUST ignore a received User-to-User header field if the > > "content" header field parameter is present and the value is some > > other value that "isdn-uui". > > > > When sending UUI, the sending SIP entity MAY, but need not, include > > an "encoding" header field with a value set to "hex". A receiving > > SIP entity MUST ignore a received User-to-User header field if the > > "encoding" header field parameter is present and the value is some > > other value that "hex". > > > > As below: > > > > The default and only content defined for this package is "isdn-uui"= . > > When sending UUI, the sending SIP entity MAY, but need not, include > a > > "content" header field with a value set to "isdn-uui". A receiving > > SIP entity MUST ignore a received User-to-User header field if the > > "content" header field parameter is present and the value is some > > other value that "isdn-uui". > > > > The default and only encoding defined for this package is "hex". > > When sending UUI, the sending SIP entity MAY, but need not, include > > an "encoding" header field with a value set to "hex". A receiving > > SIP entity MUST ignore a received User-to-User header field if the > > "encoding" header field parameter is present and the value is some > > other value that "hex". > > > > Does anybody have objections to this change, or indeed a better wording= ? > > > > Regards > > > > Keith > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Wed Feb 29 08:24:41 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3E21F8599 for ; Wed, 29 Feb 2012 08:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77-atBbzU97e for ; Wed, 29 Feb 2012 08:24:37 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6445221F8598 for ; Wed, 29 Feb 2012 08:24:37 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id fr0G1i00227AodY51sQdWJ; Wed, 29 Feb 2012 16:24:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id fsQd1i01e07duvL3fsQdxi; Wed, 29 Feb 2012 16:24:37 +0000 Message-ID: <4F4E5144.4010106@alum.mit.edu> Date: Wed, 29 Feb 2012 11:24:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4F4E404A.2040506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cuss@ietf.org" Subject: Re: [cuss] Default content and encoding in ISDN package X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 16:24:41 -0000 Keith, You seem to be treating "content" and "encoding" analogously below. IMO they are of a different character and need to be considered independently. (I see significant parallels between content/encoding and MIME Content-Type/Content-Encoding.) In particular, I would hope that an implementation that supports both multiple content values and multiple encoding values would implement them independently, so that any supported encoding could be used with any supported content. Thanks, Paul On 2/29/12 11:09 AM, DRAGE, Keith (Keith) wrote: > At the moment additional valued are not needed for the ISDN package, and I don't see how they would be used in the future given the constraint on interworking - what is sent must be interworkable. > > The current wording of the generic document is that the package (and therefore the package document) should define which content values and which encoding values can be used, and which is the default. > > So in terms of the words I proposed to change that change would appear to be needed. > > You question is a different issue on text that was already in the -00 version of the author draft. > > In response to that, I guess there are three considerations: > > 1) If the content or encoding is something I do not understand at all, then the text as written is the only possible action. For example, I should not treat a received content value of "xxxx" as if it was "uui-isdn". > > 2) If the content or encoding is something defined as applicable in another package, that is also implemented by the UA, then I guess the question is can the UA place a sufficiently valid interpretation on that in order to render it? I am not entirely convinced it can but seek other opinions. > > 3) If the content or encoding is something defined as applicable in a update or replacement RFC for the same package, then we surely need some rules for that occurring in the generic mechanism draft. What are those rules? > > We have agreed in the past that extensions to both these values have to be defined by RFC (general). > > I'd also note that the general principle of this package (uui-isdn) at least is throw away if it does not meet the rules or cannot be interworked. Throw away if too long. Throw away if in wrong message. Etc. If you wanted to do something else for many of these, doesn't that make it a different package. > > What does the working group want? > > Regards > > Keith > > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 29 February 2012 15:12 >> To: cuss@ietf.org >> Subject: Re: [cuss] Default content and encoding in ISDN package >> >> Before further tweaking the wording, I'll ask a question: >> >> Suppose we eventually define other encodings. Is there any reason that >> those other encodings could not be used with isdn-uui, assuming the >> sender and the recipient support them? >> >> I would be inclined to be a little less rigid about rejecting other >> encodings. (IOW I think that support for encodings should be orthogonal >> to support for different content values.) >> >> Thanks, >> Paul >> >> >> On 2/29/12 6:46 AM, DRAGE, Keith (Keith) wrote: >>> The mechanism draft uses the term default a number of times in regard to >> the "content" and "encoding" header field parameters and indicates the >> packages will define the default. In the ISDN package, the only point this >> really gets mentioned is in the IANA registration, although it is >> otherwise covered. I proposed to amend the following section 9 text: >>> >>> When sending UUI, the sending SIP entity MAY, but need not, include >> a >>> "content" header field with a value set to "isdn-uui". A receiving >>> SIP entity MUST ignore a received User-to-User header field if the >>> "content" header field parameter is present and the value is some >>> other value that "isdn-uui". >>> >>> When sending UUI, the sending SIP entity MAY, but need not, include >>> an "encoding" header field with a value set to "hex". A receiving >>> SIP entity MUST ignore a received User-to-User header field if the >>> "encoding" header field parameter is present and the value is some >>> other value that "hex". >>> >>> As below: >>> >>> The default and only content defined for this package is "isdn-uui". >>> When sending UUI, the sending SIP entity MAY, but need not, include >> a >>> "content" header field with a value set to "isdn-uui". A receiving >>> SIP entity MUST ignore a received User-to-User header field if the >>> "content" header field parameter is present and the value is some >>> other value that "isdn-uui". >>> >>> The default and only encoding defined for this package is "hex". >>> When sending UUI, the sending SIP entity MAY, but need not, include >>> an "encoding" header field with a value set to "hex". A receiving >>> SIP entity MUST ignore a received User-to-User header field if the >>> "encoding" header field parameter is present and the value is some >>> other value that "hex". >>> >>> Does anybody have objections to this change, or indeed a better wording? >>> >>> Regards >>> >>> Keith >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>> >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Wed Feb 29 08:32:03 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5250621F8644 for ; Wed, 29 Feb 2012 08:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.419 X-Spam-Level: X-Spam-Status: No, score=-109.419 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar4tsp5jivwS for ; Wed, 29 Feb 2012 08:32:02 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 261BD21F86D5 for ; Wed, 29 Feb 2012 08:32:01 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1TGVuVC027173 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Feb 2012 17:31:57 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 29 Feb 2012 17:31:56 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Wed, 29 Feb 2012 17:31:55 +0100 Thread-Topic: [cuss] Default content and encoding in ISDN package Thread-Index: Acz2/qdEtBOwi4heQrOY8JjG1vLluwAAFeqQ Message-ID: References: <4F4E404A.2040506@alum.mit.edu> <4F4E5144.4010106@alum.mit.edu> In-Reply-To: <4F4E5144.4010106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "cuss@ietf.org" Subject: Re: [cuss] Default content and encoding in ISDN package X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 16:32:03 -0000 No I don't believe I am. All I am saying is that the same analysis of the issue and the resultant qu= estions apply to both. That doesn't preclude people answering those questio= ns I have asked with different answers. And certainly the handling is in two distinct and separate paragraphs at th= e moment, which can be independently modified. There are some commonalities - for example neither of of them have an equiv= alent in the ISDN protocols that they can be interworked to. And the other commonality is that they both probably need to be discussed f= rom the wider viewpoint of what is the generic handling in this and all fut= ure packages. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 29 February 2012 16:25 > To: DRAGE, Keith (Keith) > Cc: cuss@ietf.org > Subject: Re: [cuss] Default content and encoding in ISDN package >=20 > Keith, >=20 > You seem to be treating "content" and "encoding" analogously below. > IMO they are of a different character and need to be considered > independently. (I see significant parallels between content/encoding and > MIME Content-Type/Content-Encoding.) >=20 > In particular, I would hope that an implementation that supports both > multiple content values and multiple encoding values would implement > them independently, so that any supported encoding could be used with > any supported content. >=20 > Thanks, > Paul >=20 > On 2/29/12 11:09 AM, DRAGE, Keith (Keith) wrote: > > At the moment additional valued are not needed for the ISDN package, an= d > I don't see how they would be used in the future given the constraint on > interworking - what is sent must be interworkable. > > > > The current wording of the generic document is that the package (and > therefore the package document) should define which content values and > which encoding values can be used, and which is the default. > > > > So in terms of the words I proposed to change that change would appear > to be needed. > > > > You question is a different issue on text that was already in the -00 > version of the author draft. > > > > In response to that, I guess there are three considerations: > > > > 1) If the content or encoding is something I do not understand at all, > then the text as written is the only possible action. For example, I > should not treat a received content value of "xxxx" as if it was "uui- > isdn". > > > > 2) If the content or encoding is something defined as applicable in > another package, that is also implemented by the UA, then I guess the > question is can the UA place a sufficiently valid interpretation on that > in order to render it? I am not entirely convinced it can but seek other > opinions. > > > > 3) If the content or encoding is something defined as applicable in a > update or replacement RFC for the same package, then we surely need some > rules for that occurring in the generic mechanism draft. What are those > rules? > > > > We have agreed in the past that extensions to both these values have to > be defined by RFC (general). > > > > I'd also note that the general principle of this package (uui-isdn) at > least is throw away if it does not meet the rules or cannot be > interworked. Throw away if too long. Throw away if in wrong message. Etc. > If you wanted to do something else for many of these, doesn't that make i= t > a different package. > > > > What does the working group want? > > > > Regards > > > > Keith > > > > > >> -----Original Message----- > >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf O= f > >> Paul Kyzivat > >> Sent: 29 February 2012 15:12 > >> To: cuss@ietf.org > >> Subject: Re: [cuss] Default content and encoding in ISDN package > >> > >> Before further tweaking the wording, I'll ask a question: > >> > >> Suppose we eventually define other encodings. Is there any reason that > >> those other encodings could not be used with isdn-uui, assuming the > >> sender and the recipient support them? > >> > >> I would be inclined to be a little less rigid about rejecting other > >> encodings. (IOW I think that support for encodings should be orthogona= l > >> to support for different content values.) > >> > >> Thanks, > >> Paul > >> > >> > >> On 2/29/12 6:46 AM, DRAGE, Keith (Keith) wrote: > >>> The mechanism draft uses the term default a number of times in regard > to > >> the "content" and "encoding" header field parameters and indicates the > >> packages will define the default. In the ISDN package, the only point > this > >> really gets mentioned is in the IANA registration, although it is > >> otherwise covered. I proposed to amend the following section 9 text: > >>> > >>> When sending UUI, the sending SIP entity MAY, but need not, > include > >> a > >>> "content" header field with a value set to "isdn-uui". A > receiving > >>> SIP entity MUST ignore a received User-to-User header field if > the > >>> "content" header field parameter is present and the value is som= e > >>> other value that "isdn-uui". > >>> > >>> When sending UUI, the sending SIP entity MAY, but need not, > include > >>> an "encoding" header field with a value set to "hex". A > receiving > >>> SIP entity MUST ignore a received User-to-User header field if > the > >>> "encoding" header field parameter is present and the value is > some > >>> other value that "hex". > >>> > >>> As below: > >>> > >>> The default and only content defined for this package is "isdn- > uui". > >>> When sending UUI, the sending SIP entity MAY, but need not, > include > >> a > >>> "content" header field with a value set to "isdn-uui". A > receiving > >>> SIP entity MUST ignore a received User-to-User header field if > the > >>> "content" header field parameter is present and the value is som= e > >>> other value that "isdn-uui". > >>> > >>> The default and only encoding defined for this package is "hex". > >>> When sending UUI, the sending SIP entity MAY, but need not, > include > >>> an "encoding" header field with a value set to "hex". A > receiving > >>> SIP entity MUST ignore a received User-to-User header field if > the > >>> "encoding" header field parameter is present and the value is > some > >>> other value that "hex". > >>> > >>> Does anybody have objections to this change, or indeed a better > wording? > >>> > >>> Regards > >>> > >>> Keith > >>> _______________________________________________ > >>> cuss mailing list > >>> cuss@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cuss > >>> > >> > >> _______________________________________________ > >> cuss mailing list > >> cuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/cuss > >