From thomas.belling@nsn.com Thu Mar 1 02:20:52 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 8B2AA21F86B9 for ; Thu, 1 Mar 2012 02:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.839 X-Spam-Level: X-Spam-Status: No, score=-6.839 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 qwgfgS+6535l for ; Thu, 1 Mar 2012 02:20:51 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 82FAA21F8669 for ; Thu, 1 Mar 2012 02:20:45 -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 q21AKcbv019157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 11:20:38 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q21AKU6n001485; Thu, 1 Mar 2012 11:20:36 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 11:20: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: Thu, 1 Mar 2012 11:20:33 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F0113B3AC@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F4E404A.2040506@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Default content and encoding in ISDN package Thread-Index: Acz29IZtgpdaN1v5SzWWZuLDvAOjsAAn2Spg References: <4F4E404A.2040506@alum.mit.edu> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" , X-OriginalArrivalTime: 01 Mar 2012 10:20:35.0644 (UTC) FILETIME=[F0F0DFC0:01CCF794] 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: 3589 X-purgate-ID: 151667::1330597239-00007EDF-43D05965/0-0/0-0 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: Thu, 01 Mar 2012 10:20:52 -0000 Hi Paul, Compatibility consideration seem to be unknown terrain in IETF (not compatibility between draft versions but RFCs this time)??? Suppose at some stage another encoding is defined and a sender uses this to send isdn-uui contents. Then it would risk that a receiver only supporting the hex encoding cannot interpret it. So we need strict wording that the sender shall use hex encoding for isdn-uui contents. And what would be the point of having wording that suggest that a receiver may support other encodings for isdn-uui contents if they will never be sent? Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: Wednesday, February 29, 2012 4:12 PM 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 Thu Mar 1 05:53:59 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 8C09A21E862C for ; Thu, 1 Mar 2012 05:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.444 X-Spam-Level: X-Spam-Status: No, score=-109.444 tagged_above=-999 required=5 tests=[AWL=0.805, 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 DEmlnQS4DpSq for ; Thu, 1 Mar 2012 05:53:58 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70021E8626 for ; Thu, 1 Mar 2012 05:53:58 -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 q21DrmPC012325 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 1 Mar 2012 14:53:57 +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, 1 Mar 2012 14:53:37 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Thu, 1 Mar 2012 14:53:36 +0100 Thread-Topic: Compatibility: was Default content and encoding in ISDN package Thread-Index: Acz29IZtgpdaN1v5SzWWZuLDvAOjsAAn2SpgAAajZyA= Message-ID: References: <4F4E404A.2040506@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57F0113B3AC@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F0113B3AC@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [cuss] Compatibility: was 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: Thu, 01 Mar 2012 13:53:59 -0000 I've changed the name of the thread, because I think we do need a more gene= ral discussion of compatibility, both forward and backward. At the end of the day, Paul is hinting at that, and all protocols should co= nsider it. >From ITU-T Q.1400: "Forward compatibility mechanisms are defined as a scheme to enable a versi= on of a protocol to communicate effectively with and interwork with future = versions of the protocol. That is, a version of a protocol should not restr= ict future protocols from providing extra capabilities. Backward compatibility rules are defined as a scheme to ensure that future = versions of the protocol will be able to send protocol messages to the prev= ious version which will be understood and fully processed by the node suppo= rting the previous version. That is, future versions of a protocol must all= ow earlier versions to operate with it and not reduce the earlier version's= service level." At the moment the only defined compatibility mechanism defined is the packa= ge mechanism, i.e. if you want to define and use a new capability you defin= e a new package. This 1) clearly indicates the capability level that is nee= ded to be supported, 2) can be used in parallel with the older package wher= e it is not clear what is supported, 3) Using media feature tags can route = the call to the appropriate supporting capability. Do we need anything beyond this? Some compatibility mechanisms work by negotiating the capability support be= fore initiating the protocol exchange. However may of the use cases for UUI= transfer are dependent on transfer of the first data with the INVITE reque= st of a SIP dialog. Therefore it is impractical to perform that negotiation= before data is sent, except perhaps in a preliminary OPTIONS request. Other compatibility mechanisms divide the protocol into categories, e.g. - discard without notification - discard with notification - reject the entire request At the moment the UUI mechanism is entirely discard without notification. T= hat has been decided not on the need for a compatibility mechanism, but rat= her on the auxiliary nature of the data, i.e. if a discard occurs, we do no= t expect it to occur because I'm using an extension to an existing package = that the remote side does not understand, but rather because it has proved = technically impossible to transfer the data, i.e. I've sent too much data, = sent it at the wrong time, or sent it to something that cannot receive the = data. I'd represent at the moment that if we want extensibility within the packag= e, then we need to reevaluate this decision. Otherwise I believe we should limit extensibility to the package mechanism,= i.e. if we want a new encoding within a package, we should define a new pa= ckage that contains that new encoding. Whatever we decide, I think the generic mechanism document should include a= section discussing these issues. It does not seem to at the moment. Please discuss. Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Belling, Thomas (NSN - DE/Munich) > Sent: 01 March 2012 10:21 > To: ext Paul Kyzivat; cuss@ietf.org > Subject: Re: [cuss] Default content and encoding in ISDN package >=20 > Hi Paul, >=20 > Compatibility consideration seem to be unknown terrain in IETF (not > compatibility between draft versions but RFCs this time)??? >=20 > Suppose at some stage another encoding is defined and a sender uses this > to send isdn-uui contents. Then it would risk that a receiver only > supporting the hex encoding cannot interpret it. > So we need strict wording that the sender shall use hex encoding for > isdn-uui contents. > And what would be the point of having wording that suggest that a > receiver may support other encodings for isdn-uui contents if they will > never be sent? >=20 > Thomas >=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > ext Paul Kyzivat > Sent: Wednesday, February 29, 2012 4:12 PM > 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 > 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 > > >=20 > _______________________________________________ > 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 Mar 1 07:38:59 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 4389C21E80B8 for ; Thu, 1 Mar 2012 07:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.817 X-Spam-Level: X-Spam-Status: No, score=-6.817 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 fP7P5RkfS-mD for ; Thu, 1 Mar 2012 07:38:58 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C64CC21E808C for ; Thu, 1 Mar 2012 07:38:57 -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 q21FcaiM008512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 16:38:36 +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 q21FcZRd005416; Thu, 1 Mar 2012 16:38:36 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 16:38:34 +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: Thu, 1 Mar 2012 16:38:33 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F0113B60C@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Compatibility: was Default content and encoding in ISDNpackage Thread-Index: Acz29IZtgpdaN1v5SzWWZuLDvAOjsAAn2SpgAAajZyAABFiGsA== References: <4F4E404A.2040506@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57F0113B3AC@DEMUEXC014.nsn-intra.net> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 01 Mar 2012 15:38:34.0081 (UTC) FILETIME=[5C935510:01CCF7C1] 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: 8542 X-purgate-ID: 151667::1330616318-000015E0-3B5E589D/0-0/0-0 Subject: Re: [cuss] Compatibility: was Default content and encoding in ISDNpackage 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, 01 Mar 2012 15:38:59 -0000 Hi Keith, I believe the content and encoding parameters are also introduced only for forward compatibility (at least only a single value is applicable for each of those parameters for ISDN-UUI). But I agree that the main forward compatibility mechanism in the framework draft is the package parameter, and I could even imagine that the content and encoding parameters are not required at this stage, but could be defined by RFCs defining additional packages, if they really identify a need for such parameters. The ABNF allowing for a "generic-param" should allow for additional parameters to be defined at a later stage anyway. But I am also concerned that such fundamental redesigns at this stage could delay the approval of the draft even more and would thus suggest that we restrict ourselves to correction and smaller improvements. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext DRAGE, Keith (Keith) Sent: Thursday, March 01, 2012 2:54 PM To: cuss@ietf.org Subject: [cuss] Compatibility: was Default content and encoding in ISDNpackage I've changed the name of the thread, because I think we do need a more general discussion of compatibility, both forward and backward. At the end of the day, Paul is hinting at that, and all protocols should consider it. >From ITU-T Q.1400: "Forward compatibility mechanisms are defined as a scheme to enable a version of a protocol to communicate effectively with and interwork with future versions of the protocol. That is, a version of a protocol should not restrict future protocols from providing extra capabilities. Backward compatibility rules are defined as a scheme to ensure that future versions of the protocol will be able to send protocol messages to the previous version which will be understood and fully processed by the node supporting the previous version. That is, future versions of a protocol must allow earlier versions to operate with it and not reduce the earlier version's service level." At the moment the only defined compatibility mechanism defined is the package mechanism, i.e. if you want to define and use a new capability you define a new package. This 1) clearly indicates the capability level that is needed to be supported, 2) can be used in parallel with the older package where it is not clear what is supported, 3) Using media feature tags can route the call to the appropriate supporting capability. Do we need anything beyond this? Some compatibility mechanisms work by negotiating the capability support before initiating the protocol exchange. However may of the use cases for UUI transfer are dependent on transfer of the first data with the INVITE request of a SIP dialog. Therefore it is impractical to perform that negotiation before data is sent, except perhaps in a preliminary OPTIONS request. Other compatibility mechanisms divide the protocol into categories, e.g. - discard without notification - discard with notification - reject the entire request At the moment the UUI mechanism is entirely discard without notification. That has been decided not on the need for a compatibility mechanism, but rather on the auxiliary nature of the data, i.e. if a discard occurs, we do not expect it to occur because I'm using an extension to an existing package that the remote side does not understand, but rather because it has proved technically impossible to transfer the data, i.e. I've sent too much data, sent it at the wrong time, or sent it to something that cannot receive the data. I'd represent at the moment that if we want extensibility within the package, then we need to reevaluate this decision. Otherwise I believe we should limit extensibility to the package mechanism, i.e. if we want a new encoding within a package, we should define a new package that contains that new encoding. Whatever we decide, I think the generic mechanism document should include a section discussing these issues. It does not seem to at the moment. Please discuss. Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of Belling, Thomas (NSN - DE/Munich) > Sent: 01 March 2012 10:21 > To: ext Paul Kyzivat; cuss@ietf.org > Subject: Re: [cuss] Default content and encoding in ISDN package >=20 > Hi Paul, >=20 > Compatibility consideration seem to be unknown terrain in IETF (not=20 > compatibility between draft versions but RFCs this time)??? >=20 > Suppose at some stage another encoding is defined and a sender uses=20 > this to send isdn-uui contents. Then it would risk that a receiver=20 > only supporting the hex encoding cannot interpret it. > So we need strict wording that the sender shall use hex encoding for=20 > isdn-uui contents. > And what would be the point of having wording that suggest that a=20 > receiver may support other encodings for isdn-uui contents if they=20 > will never be sent? >=20 > Thomas >=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of ext Paul Kyzivat > Sent: Wednesday, February 29, 2012 4:12 PM > 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=20 > sender and the recipient support them? >=20 > I would be inclined to be a little less rigid about rejecting other=20 > encodings. (IOW I think that support for encodings should be=20 > 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=20 > > regard > to the "content" and "encoding" header field parameters and indicates=20 > the packages will define the default. In the ISDN package, the only=20 > 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 > > >=20 > _______________________________________________ > 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 Thu Mar 1 07:49: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 70AEA21E81F2 for ; Thu, 1 Mar 2012 07:49:23 -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 a+Cbd-74acJn for ; Thu, 1 Mar 2012 07:49:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4948021E81FF for ; Thu, 1 Mar 2012 07:49:21 -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 q21FmL5Q010315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 16:48:21 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q21FmKQa026976; Thu, 1 Mar 2012 16:48:21 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 16:48:14 +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: Thu, 1 Mar 2012 16:48:13 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F0113B61E@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Compatibility: was Default content and encoding in ISDNpackage Thread-Index: Acz29IZtgpdaN1v5SzWWZuLDvAOjsAAn2SpgAAajZyAABFiGsAAAke4g References: <4F4E404A.2040506@alum.mit.edu><1A8A7D59006A8240B27FF63C794CA57F0113B3AC@DEMUEXC014.nsn-intra.net> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 01 Mar 2012 15:48:14.0866 (UTC) FILETIME=[B6C01720:01CCF7C2] 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: 9114 X-purgate-ID: 151667::1330616901-000015E0-401A5275/0-0/0-0 Subject: Re: [cuss] Compatibility: was Default content and encoding in ISDNpackage 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, 01 Mar 2012 15:49:23 -0000 I forgot to add my conclusion: We should stick to the "package" as main forward compatibility mechanism. We already have guidelines for package design that say that applicable content values and encoding need to be considered when defining a package. Is that not enough clarification for those parameters? Thomas -----Original Message----- From: Belling, Thomas (NSN - DE/Munich)=20 Sent: Thursday, March 01, 2012 4:39 PM To: 'ext DRAGE, Keith (Keith)'; cuss@ietf.org Subject: RE: [cuss] Compatibility: was Default content and encoding in ISDNpackage Hi Keith, I believe the content and encoding parameters are also introduced only for forward compatibility (at least only a single value is applicable for each of those parameters for ISDN-UUI). But I agree that the main forward compatibility mechanism in the framework draft is the package parameter, and I could even imagine that the content and encoding parameters are not required at this stage, but could be defined by RFCs defining additional packages, if they really identify a need for such parameters. The ABNF allowing for a "generic-param" should allow for additional parameters to be defined at a later stage anyway. But I am also concerned that such fundamental redesigns at this stage could delay the approval of the draft even more and would thus suggest that we restrict ourselves to correction and smaller improvements. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext DRAGE, Keith (Keith) Sent: Thursday, March 01, 2012 2:54 PM To: cuss@ietf.org Subject: [cuss] Compatibility: was Default content and encoding in ISDNpackage I've changed the name of the thread, because I think we do need a more general discussion of compatibility, both forward and backward. At the end of the day, Paul is hinting at that, and all protocols should consider it. >From ITU-T Q.1400: "Forward compatibility mechanisms are defined as a scheme to enable a version of a protocol to communicate effectively with and interwork with future versions of the protocol. That is, a version of a protocol should not restrict future protocols from providing extra capabilities. Backward compatibility rules are defined as a scheme to ensure that future versions of the protocol will be able to send protocol messages to the previous version which will be understood and fully processed by the node supporting the previous version. That is, future versions of a protocol must allow earlier versions to operate with it and not reduce the earlier version's service level." At the moment the only defined compatibility mechanism defined is the package mechanism, i.e. if you want to define and use a new capability you define a new package. This 1) clearly indicates the capability level that is needed to be supported, 2) can be used in parallel with the older package where it is not clear what is supported, 3) Using media feature tags can route the call to the appropriate supporting capability. Do we need anything beyond this? Some compatibility mechanisms work by negotiating the capability support before initiating the protocol exchange. However may of the use cases for UUI transfer are dependent on transfer of the first data with the INVITE request of a SIP dialog. Therefore it is impractical to perform that negotiation before data is sent, except perhaps in a preliminary OPTIONS request. Other compatibility mechanisms divide the protocol into categories, e.g. - discard without notification - discard with notification - reject the entire request At the moment the UUI mechanism is entirely discard without notification. That has been decided not on the need for a compatibility mechanism, but rather on the auxiliary nature of the data, i.e. if a discard occurs, we do not expect it to occur because I'm using an extension to an existing package that the remote side does not understand, but rather because it has proved technically impossible to transfer the data, i.e. I've sent too much data, sent it at the wrong time, or sent it to something that cannot receive the data. I'd represent at the moment that if we want extensibility within the package, then we need to reevaluate this decision. Otherwise I believe we should limit extensibility to the package mechanism, i.e. if we want a new encoding within a package, we should define a new package that contains that new encoding. Whatever we decide, I think the generic mechanism document should include a section discussing these issues. It does not seem to at the moment. Please discuss. Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of Belling, Thomas (NSN - DE/Munich) > Sent: 01 March 2012 10:21 > To: ext Paul Kyzivat; cuss@ietf.org > Subject: Re: [cuss] Default content and encoding in ISDN package >=20 > Hi Paul, >=20 > Compatibility consideration seem to be unknown terrain in IETF (not=20 > compatibility between draft versions but RFCs this time)??? >=20 > Suppose at some stage another encoding is defined and a sender uses=20 > this to send isdn-uui contents. Then it would risk that a receiver=20 > only supporting the hex encoding cannot interpret it. > So we need strict wording that the sender shall use hex encoding for=20 > isdn-uui contents. > And what would be the point of having wording that suggest that a=20 > receiver may support other encodings for isdn-uui contents if they=20 > will never be sent? >=20 > Thomas >=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of ext Paul Kyzivat > Sent: Wednesday, February 29, 2012 4:12 PM > 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=20 > sender and the recipient support them? >=20 > I would be inclined to be a little less rigid about rejecting other=20 > encodings. (IOW I think that support for encodings should be=20 > 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=20 > > regard > to the "content" and "encoding" header field parameters and indicates=20 > the packages will define the default. In the ISDN package, the only=20 > 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 > > >=20 > _______________________________________________ > 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 Thu Mar 1 08:09:21 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 C1D6321E810D for ; Thu, 1 Mar 2012 08:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.784 X-Spam-Level: X-Spam-Status: No, score=-6.784 tagged_above=-999 required=5 tests=[AWL=-0.185, 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 ioNJJX+QMFY1 for ; Thu, 1 Mar 2012 08:09:21 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EC90C21E80DF for ; Thu, 1 Mar 2012 08:09:20 -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 q21G6xbL004513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 17:06:59 +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 q21G6xpR016954; Thu, 1 Mar 2012 17:06:59 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 17:06:55 +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: Thu, 1 Mar 2012 17:06:54 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F0113B63B@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Encoding of protocol discriminator in the uui-isdn package Thread-Index: Acz21fTq47Z7YSQ3TpOgK31SiHTBSQA7iCmw References: From: "Belling, Thomas (NSN - DE/Munich)" To: "ext DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 01 Mar 2012 16:06:55.0396 (UTC) FILETIME=[52A36640:01CCF7C5] 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: 2102 X-purgate-ID: 151667::1330618020-000044A2-E1DC898C/0-0/0-0 Subject: Re: [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: Thu, 01 Mar 2012 16:09:21 -0000 Hi Keith, Your own draft indeed already has wording about the protocol discriminator, and also some wording where the payload in encoded: 11. Coding requirements This document defines "isdn-uui" as a new value of the User-to-User "package" header field parameter. This document defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. A content value of "isdn-uui" indicates that the contents have a first octet that is a protocol discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] followed by uui-data that can be subject to a length limitation (before encoding or after decoding) that is generally 128 octets. In many other places in the draft you speak about "UUI for the ISDN package", "UUI", or "UUI data" I could live with this, as this is sufficiently clear for me. But I also have nothing against making the terminology within the draft even more consistent. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext DRAGE, Keith (Keith) Sent: Wednesday, February 29, 2012 12:33 PM To: cuss@ietf.org Subject: [cuss] Encoding of protocol discriminator in the uui-isdn package In trying to sort our whether we have adequately specified the protocol discriminator (I think we have), I notice that I have been using the term "payload" and "UUI payload" in the package draft. It looks to me like the mechanism draft uses the term "UUI data" to refer to 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 consistent assuming I see no objections. It may be worth checking the mechanism draft to ensure this term is used only in the context identified above in the mechanism draft (and therefore does not encompass the header field parameters as well). Responses? Keith _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Thu Mar 1 10:52: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 7558021E8080 for ; Thu, 1 Mar 2012 10:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77hgtzsWqbga for ; Thu, 1 Mar 2012 10:52:11 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 09A8F21E81C2 for ; Thu, 1 Mar 2012 10:52:10 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id gHE31i0051vXlb858JsBzM; Thu, 01 Mar 2012 18:52:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id gJsB1i00M07duvL3dJsBiE; Thu, 01 Mar 2012 18:52:11 +0000 Message-ID: <4F4FC559.3080203@alum.mit.edu> Date: Thu, 01 Mar 2012 13:52:09 -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> <4F4E5144.4010106@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: Thu, 01 Mar 2012 18:52:12 -0000 On 2/29/12 11:31 AM, DRAGE, Keith (Keith) wrote: > No I don't believe I am. > > All I am saying is that the same analysis of the issue and the resultant questions apply to both. That doesn't preclude people answering those questions I have asked with different answers. > > And certainly the handling is in two distinct and separate paragraphs at the moment, which can be independently modified. > > There are some commonalities - for example neither of of them have an equivalent in the ISDN protocols that they can be interworked to. I don't think there need be *any* relationship between the encoding parameter in sip and how the data is encoded in ISDN. There is only one choice of encoding in ISDN - binary. We could have any number of encodings in sip, so long as they can each be converted to/from the binary form used in ISDN. When going from sip to ISDN nothing more is needed. When going from ISDN to sip, one encoding needs to be selected. I don't have any particular problem with specifying that in this case hex is to be used. > And the other commonality is that they both probably need to be discussed from the wider viewpoint of what is the generic handling in this and all future packages. When I first proposed that we make provision for multiple encodings, I anticipated that we would be defining more than one initially. But there was not much interest in that. (Even though I've seen some evidence that an "ascii" encoding might be quite useful.) Whether other encodings will be desired for other content remains to be seen. I remain concerned that the ISDN package, while necessary for backward compatibility, is not a good model for interoperability for the future. It has no way to ensure that the sender and the recipient have a common understanding of the format of the information being passed. Ideally each application would use some combination of package and content names to handle that. But it seems people don't want to discuss that, at least yet. Thanks, Paul > 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 >> >> 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 pkyzivat@alum.mit.edu Thu Mar 1 11:02: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 D862D21E823D for ; Thu, 1 Mar 2012 11:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irD8xXUisTg6 for ; Thu, 1 Mar 2012 11:02:17 -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 F325721E8209 for ; Thu, 1 Mar 2012 11:02:16 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id gJTS1i0080QuhwU57K2DNt; Thu, 01 Mar 2012 19:02:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id gK2D1i00U07duvL3NK2DXq; Thu, 01 Mar 2012 19:02:13 +0000 Message-ID: <4F4FC7B4.1050603@alum.mit.edu> Date: Thu, 01 Mar 2012 14:02:12 -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: <4F4E404A.2040506@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57F0113B3AC@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F0113B3AC@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] 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: Thu, 01 Mar 2012 19:02:18 -0000 On 3/1/12 5:20 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Hi Paul, > > Compatibility consideration seem to be unknown terrain in IETF (not > compatibility between draft versions but RFCs this time)??? > > Suppose at some stage another encoding is defined and a sender uses this > to send isdn-uui contents. Then it would risk that a receiver only > supporting the hex encoding cannot interpret it. > So we need strict wording that the sender shall use hex encoding for > isdn-uui contents. > And what would be the point of having wording that suggest that a > receiver may support other encodings for isdn-uui contents if they will > never be sent? See my reply to Keith. Unfortunately, using UUI in the ISDN world requires a common understanding between sender and receiver of what data format is being conveyed. (In theory it seems that the protocol discriminator byte is intended to say *something* about the remainder of the data, but not much.) What encoding to use could just be part of that common understanding. While that isn't good, its perhaps not worse than it already is. But perhaps the difference is that when one end is sip and the other is really ISDN, then its the GW that needs to know the encoding but the endpoint that needs to know the format. So there is an added requirement for the sender to know the capabilities of the intervening GW. We could address this by defining a literal character encoding now in addition to the hex encoding, and expecting everything to support both. Thanks, Paul > Thomas > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > ext Paul Kyzivat > Sent: Wednesday, February 29, 2012 4:12 PM > 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 vkg@bell-labs.com Fri Mar 2 08:20: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 4D72321F8733 for ; Fri, 2 Mar 2012 08:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.91 X-Spam-Level: X-Spam-Status: No, score=-106.91 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 JOLz4un-rJXP for ; Fri, 2 Mar 2012 08:20:05 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8781821F869D for ; Fri, 2 Mar 2012 08:20:05 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q22GK4sP024139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Mar 2012 10:20:04 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22GK48m007764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 10:20:04 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q22GK4Hr011272 for ; Fri, 2 Mar 2012 10:20:04 -0600 (CST) Message-ID: <4F50F443.7090100@bell-labs.com> Date: Fri, 02 Mar 2012 10:24:35 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: cuss@ietf.org 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.9 Subject: [cuss] Agenda requests for CUSS@Paris IETF 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, 02 Mar 2012 16:20:06 -0000 Folks: It is that time of the year again ... Enrico and I are collecting agenda requests for the upcoming CUSS WG meeting at IETF 83. As usual, priority will be given to charter items, and to topics that have been already presented and discussed on the list. If you have requests for agenda slots at the Paris meeting, please send them to Enrico and me by March 12, identifying the draft, the length of the scheduled slot and the name of the speaker. The important deadlines to keep in mind are the following: 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -8) 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7) 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7) CUSS WG has been scheduled on 1230-1330 slot on Friday, March 30. 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 thomas.belling@nsn.com Mon Mar 5 01:44: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 0572521F8569 for ; Mon, 5 Mar 2012 01:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.77 X-Spam-Level: X-Spam-Status: No, score=-6.77 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 iG7a3JhT-oFO for ; Mon, 5 Mar 2012 01:44:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 64DFA21F8526 for ; Mon, 5 Mar 2012 01:44:44 -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 q259iej9000893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 10:44:40 +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 q259iQYD001039; Mon, 5 Mar 2012 10:44:38 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 10:44:14 +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: Mon, 5 Mar 2012 10:44:13 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F0117F85E@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F4FC7B4.1050603@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Default content and encoding in ISDN package Thread-Index: Acz33dShfkj6KhVwTy+muZAyLUZ8WQC1g9YA References: <4F4E404A.2040506@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57F0113B3AC@DEMUEXC014.nsn-intra.net> <4F4FC7B4.1050603@alum.mit.edu> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" X-OriginalArrivalTime: 05 Mar 2012 09:44:14.0106 (UTC) FILETIME=[864B97A0:01CCFAB4] 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: 5572 X-purgate-ID: 151667::1330940680-000044A2-B944CACE/0-0/0-0 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: Mon, 05 Mar 2012 09:44:49 -0000 Dear Paul, Your explanations were more related to the content than the mere encoding. You are right that in ISDN the protocol discriminator does not tell too much about the content, but we are emulating this service and (as you say) will frequently interwork withg ISDN devices where we can hardly do more. But to address this concern, we could consider a more liberal usage of the content parameter (e.g. with privat values) to say more about the content should the peer understand. This would be lost in ISUP interworking. Thomas -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Thursday, March 01, 2012 8:02 PM To: Belling, Thomas (NSN - DE/Munich) Cc: cuss@ietf.org Subject: Re: [cuss] Default content and encoding in ISDN package On 3/1/12 5:20 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Hi Paul, > > Compatibility consideration seem to be unknown terrain in IETF (not=20 > compatibility between draft versions but RFCs this time)??? > > Suppose at some stage another encoding is defined and a sender uses=20 > this to send isdn-uui contents. Then it would risk that a receiver=20 > only supporting the hex encoding cannot interpret it. > So we need strict wording that the sender shall use hex encoding for=20 > isdn-uui contents. > And what would be the point of having wording that suggest that a=20 > receiver may support other encodings for isdn-uui contents if they=20 > will never be sent? See my reply to Keith. Unfortunately, using UUI in the ISDN world requires a common understanding between sender and receiver of what data format is being conveyed. (In theory it seems that the protocol discriminator byte is intended to say *something* about the remainder of the data, but not much.) What encoding to use could just be part of that common understanding.=20 While that isn't good, its perhaps not worse than it already is. But perhaps the difference is that when one end is sip and the other is really ISDN, then its the GW that needs to know the encoding but the endpoint that needs to know the format. So there is an added requirement for the sender to know the capabilities of the intervening GW. We could address this by defining a literal character encoding now in addition to the hex encoding, and expecting everything to support both. Thanks, Paul > Thomas > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of ext Paul Kyzivat > Sent: Wednesday, February 29, 2012 4:12 PM > 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=20 > sender and the recipient support them? > > I would be inclined to be a little less rigid about rejecting other=20 > encodings. (IOW I think that support for encodings should be=20 > 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=20 > the packages will define the default. In the ISDN package, the only=20 > 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 thomas.belling@nsn.com Mon Mar 12 05:50: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 E972821F879B for ; Mon, 12 Mar 2012 05:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.748 X-Spam-Level: X-Spam-Status: No, score=-6.748 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 0mfvoHuv7rCb for ; Mon, 12 Mar 2012 05:50:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF9C21F878B for ; Mon, 12 Mar 2012 05:50:28 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2CCo5lx025481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 13:50:05 +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 q2CCndsF011187; Mon, 12 Mar 2012 13:49:59 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 13:49:58 +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_01CD004E.A1C1F5D5" Date: Mon, 12 Mar 2012 13:49:57 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F011E1B4B@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: When will new version of draft-ietf-cuss-sip-uui become available? Thread-Index: Ac0ATpkWW2ch63nRT7+nlsXDgGBJhw== From: "Belling, Thomas (NSN - DE/Munich)" To: "Alan Johnston" , , X-OriginalArrivalTime: 12 Mar 2012 12:49:58.0455 (UTC) FILETIME=[A1BC8C70:01CD004E] 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: 2929 X-purgate-ID: 151667::1331556607-000033AC-BAA2E802/0-0/0-0 Subject: [cuss] When will new version of draft-ietf-cuss-sip-uui become available? 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, 12 Mar 2012 12:50:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD004E.A1C1F5D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alan, all, Is there a plan to submit an updated version of this draft soon? Many thanks, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation=20 Nokia Siemens Networks =20 ------_=_NextPart_001_01CD004E.A1C1F5D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When will new version of draft-ietf-cuss-sip-uui become = available?

Dear Alan, = all,

Is there a plan to submit = an updated version of this draft soon?

Many thanks, Thomas

----------------------------------
Dr. Thomas Belling
3GPP Standardisation
Nokia Siemens = Networks 

------_=_NextPart_001_01CD004E.A1C1F5D5-- From internet-drafts@ietf.org Mon Mar 12 14:50:11 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 36ED021E8085; Mon, 12 Mar 2012 14:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 yPkO2gEznKsC; Mon, 12 Mar 2012 14:50:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0421F89B6; Mon, 12 Mar 2012 14:50:10 -0700 (PDT) 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: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:50:10 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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, 12 Mar 2012 21:50:11 -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 : A Mechanism for Transporting User to User Call Control I= nformation in SIP Author(s) : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-05.txt Pages : 17 Date : 2012-03-12 There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a certain application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt From alan.b.johnston@gmail.com Mon Mar 12 14:50:32 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 510FE21E80A5 for ; Mon, 12 Mar 2012 14:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 dvhMizbfHrpy for ; Mon, 12 Mar 2012 14:50:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72CF321E8089 for ; Mon, 12 Mar 2012 14:50:31 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3516338ghb.31 for ; Mon, 12 Mar 2012 14:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EbCwrc/Q7BgDzEdOHzPMycJR2ZPRHoLg7iwmfOgeyh0=; b=liL8hMBB0/tPrLMbB9gViIAexdAYSI/ILzxj4+KKPIxr+9V3+kJ3VRoZ3cyZ9nwoN6 Jv0MbTOo2HgAsdw5KVKWcQ3OD5nGIah5bFUonXDKm168BHJscDcVF2Q6CXZasJGdIwWG aoM1R8UX0nfjA+fCRDIhPZfi9uolnyi72CHqLwWZfNvnugUGpI2IzFf72gzND9WQbsCt 5J6wENeySCv7S0X2xMvbuPro2jXZgOHjMG5frpAZU/AGsetLYtKPOZsHaPOW0ciplDoi sIvVIOvyCAuN28ceDmZFfxXLsF/3Jdi0iv6UFVEhwHw9isM9XZ42T76gvl1icWigIZxI Zd/Q== Received: by 10.60.26.166 with SMTP id m6mr9058343oeg.45.1331589030967; Mon, 12 Mar 2012 14:50:30 -0700 (PDT) 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 gl4sm22449509obb.23.2012.03.12.14.50.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 14:50:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alan Johnston In-Reply-To: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> Date: Mon, 12 Mar 2012 16:50:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> To: Shida Schubert X-Mailer: Apple Mail (2.1084) Cc: cuss@ietf.org Subject: Re: [cuss] Review of draft-ietf-cuss-sip-uui 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, 12 Mar 2012 21:50:32 -0000 Shida, Thanks very much for the review. I believe I have addressed your issues = in the -05 version. See a few comments below. - Alan - On Nov 28, 2011, at 7:10 PM, Shida Schubert wrote: >=20 > I was asked by chairs of this WG to review=20 > draft-ietf-cuss-sip-uui.=20 >=20 > Below are my comments=20 >=20 > ** OVERALL *** >=20 > The draft talks a lot about escaping the header.=20 > We used the same terminology in rfc4244bis, but=20 > after some discussion decided with "including/include". >=20 > I think the reason was due to the fact that 3261 doesn't=20 > use "escape" in that context.=20 Done. >=20 > I didn't see any issue with how the rfc4244bis is used. Great! >=20 > ** TECHNICAL *** >=20 > 1. Will the behavior of the device be affected if the=20 > source of UUI data is different from the assumed entity? > I am assuming it doesn't as the inserterthere is an a priori = understanding ... of the UUI=20 > data doesn't seem too be so important from the draft.=20 Not really, although I did put in some text in the security = considerations saying a UA can apply policy to the processing of UUI = data based on who inserted it. >=20 > 2. I think there is little or no text about the behavior=20 > of entity receiving UUI data, encoding or package=20 > that it doesn't understand. I am assuming it simply =20 > ignores it but, I think this should be explicitly=20 > stated somewhere in normative language.=20 I added a statement saying unknown packages and encodings should be = ignored. >=20 > 3. Section 3 talks about UUI header being removed=20 > by proxy/intermediary. But it is mute about intermediary=20 > adding UUI header, leaving room for them to add it.=20 > So what would happen if intermediary adds UUI header?=20 > Who is the inserter? What does that mean? If we don't=20 > see any use for intermediary adding the header, I think=20 > we should say MUST NOT for intermediary.=20 Well, this would be tricky to write in a way that doesn't confuse. The = spec is clear that UUI is between UAs, not between anyone else. = However, UUI data included in a 3xx could be inserted by a proxy that = recurses on the 3xx, but it isn't really the proxy that is inserting it. = I >=20 > 4. I think normative text surrounding redirecting entity=20 > adding user-to-user info be added.=20 I added a SHOULD level statement. >=20 > 5. When UAS redirects the request with=20 > User-to-User: foo;package=3D1;encoding=3Dhex to a=20 > contact with a User-to-User:bar;package=3D1;encoding=3Dhex.=20 >=20 > I am assuming that you will end up with=20 >=20 > User-to-User: foo;package=3D1;encoding=3Dhex, = bar;package=3D1,encoding=3Dhex >=20 > You end up with two uui data from two different entity.=20 > Is this going to pose problem?=20 This is a very good point. I don't think the mechanism itself should be = definitive on this. But packages must say how to handle this. I even = think that the same content with multiple encodings seems like a good = idea, except for the ISDN service where it isn't backwards compatible. = There is new text in Section 5 about this. >=20 > I guess if 4244bis was supported, this would be=20 > logged and one can see that the latter was added by=20 > an UAS which redirected the request.. Do we need to=20 > add some text regarding this? Are the last value more=20 > important than the one added by the originator of the=20 > request? I don't think so. Having History-Info to sort it out is about the best = we can do. >=20 > ** NITS *** > Section 1 >=20 > OLD : there is an a priori understanding ... > NEW : there is a priori understanding ... I kept the old text as I think it is right - the RFC editor will have = the final say, of course. >=20 > Section 5 >=20 > OLD : SIP UUI mechanism must publish a standard track. > NEW : SIP UUI mechanism MUST publish a standard tack. >=20 > OLD : some use case example examples. > NEW : some use case examples.=20 >=20 > OLD : Hex encoded UUI data must have an even... > NEW : Hex encoded UUI data MUST have an even.. >=20 > OLD : New "encoding" values must reference... > NEW : New "encoding" values MUST reference.. >=20 > OLD : New "content" values must describe... > NEW : New "content" values MUST describe.. >=20 > I hope this helps.=20 Very much - thanks! >=20 > Regards > Shida=20 >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Mon Mar 12 14:50:45 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 032F121E808E for ; Mon, 12 Mar 2012 14:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 yXg0w+f0xj02 for ; Mon, 12 Mar 2012 14:50:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7073821E8090 for ; Mon, 12 Mar 2012 14:50:42 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3545587ggm.31 for ; Mon, 12 Mar 2012 14:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cfwWyRGBKrqRoGZbU+9Y6JwrYnoOSCacX9XjXNzYqyE=; b=oq1tOCIAQovhjHuSCs8IGnGPyov+aPDkacb2w4JQ9nwh1fasD6Ys5zj6useS+Ou4Oe bdhdYo7s2fDkpEyKqdOOBDvXMFsmc9EJrFAOHXRgKywctWUyzcgm2xVx4nuyVIHI6OeV rVSsu9s+WWazf3MQ29WZ5hA9Nu3LjE3uy6Vj+hBMrhGkY8AcoQHetvnSB2rVyNV3EDPB 8QZkbiUF3YKyp2uXdlfWxDN4dm2nT8QpEPqKQVbA1RiNAqerICYHikU/fqUp8NNIEVi2 wtgJRWOqXDsBLffBi5a3doq+KTRKP8703jXEO5Ms5RhVtQXOdxKR2g1ouxuYVErwsbit AjMg== Received: by 10.182.136.41 with SMTP id px9mr9471497obb.21.1331589041973; Mon, 12 Mar 2012 14:50:41 -0700 (PDT) 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 gl4sm22449509obb.23.2012.03.12.14.50.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 14:50:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alan Johnston In-Reply-To: Date: Mon, 12 Mar 2012 16:50:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1084) Cc: "cuss@ietf.org" Subject: Re: [cuss] Review of draft-ietf-cuss-sip-uui 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, 12 Mar 2012 21:50:45 -0000 Martin, Thanks very much for the review. I think I have addressed your comments = in the -05 version. See a few comments below. - Alan - On Jan 10, 2012, at 9:32 AM, DOLLY, MARTIN C wrote: > Greetings, >=20 >=20 > I was asked by chairs of this WG to review=20 > draft-ietf-cuss-sip-uui.=20 >=20 > Below are my comments, build on Shida's comments posted on 11/29/2011 >=20 > The concept of "escaping" needs to be added to Section 4 Normative = Definition, and an illustrative example would be helpful. There was an example in an earlier version of the draft (-00) but I = disappeared. I have added it back in. >=20 > UUI can be communicated between an UE and an Application Server acting = as a B2BUA, as meets the UAC-UAS requirement, so I believe a statement = explicitly stating that should be added to the overview. Well, in SIP terms, a B2BUA is just a UA, so I don't think it needs to = be explicitly stated. Do you have a particular place in the document = where you think this would be best included? >=20 > Complex call center communications can have multiple (3-4) = redirections/referrals, so a multiple redirection/referral example would = be helpful. I don't currently have any call flows in this document - I just refer to = the ones in the requirements document. I did add a note saying that = multiple redirections are quite possible. >=20 > Is it possible to have multiple UUI headers, either with the same data = content encoded differently or with different data content? >=20 Yes, I put in text saying that each package must define rules for this = situation. > What is an intermediary, if it is not a proxy? It is a proxy, or a border element ( a proxy that sometimes doesn't = behave as a proxy). I think I use the terms the same as they were used = in the requirements draft. >=20 > Terminology: the document has UUIs being communicated between UACs and = UASs and between endpoints, which is it? Good catch: I now just say UAs. >=20 > Considering the same data content could be encoded differently, does = this result in multiple UUI packages? And if so, could they be defined = in the same RFC? Yes, I put in a note indicating this. >=20 > Regards, >=20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 >=20 >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From internet-drafts@ietf.org Mon Mar 12 16:31: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 5F6A821E81FB; Mon, 12 Mar 2012 16:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 VMYU-U9pC5kO; Mon, 12 Mar 2012 16:31:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2E221E81DE; Mon, 12 Mar 2012 16:31:30 -0700 (PDT) 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: <20120312233130.19850.53797.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:31:30 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-03.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, 12 Mar 2012 23:31:31 -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-03.txt Pages : 18 Date : 2012-03-12 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-03.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-03.txt From keith.drage@alcatel-lucent.com Mon Mar 12 16:34: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 3CACA21E8202 for ; Mon, 12 Mar 2012 16:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.455 X-Spam-Level: X-Spam-Status: No, score=-109.455 tagged_above=-999 required=5 tests=[AWL=0.794, 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 JxjZZFtdQ6jw for ; Mon, 12 Mar 2012 16:34:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23D21E81FB for ; Mon, 12 Mar 2012 16:34:27 -0700 (PDT) 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 q2CNYPj2023133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 13 Mar 2012 00:34:25 +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; Tue, 13 Mar 2012 00:34:25 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Tue, 13 Mar 2012 00:34:24 +0100 Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-03.txt Thread-Index: Ac0AqFK+ei7/ga1QS/ytVbOIqB91FQAAA02w Message-ID: References: <20120312233130.19850.53797.idtracker@ietfa.amsl.com> In-Reply-To: <20120312233130.19850.53797.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-03.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, 12 Mar 2012 23:34:28 -0000 I've posted a new version of this. The changes are very few and are limited to the couple of mails I posted to= the list a week or so ago. The revision of the main mechanism draft has appeared so late that I have n= ot had time to review it for consistency, therefore that task still needs t= o be performed. There is also one outstanding comment from Paul Kyzivat which we still need= to decide what to do with. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 12 March 2012 23:32 > To: i-d-announce@ietf.org > Cc: cuss@ietf.org > Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-03.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-03.txt > Pages : 18 > Date : 2012-03-12 >=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-03.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-03.txt >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From thomas.belling@nsn.com Tue Mar 13 04:24:15 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 DB76121F86AF for ; Tue, 13 Mar 2012 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.74 X-Spam-Level: X-Spam-Status: No, score=-6.74 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 LDv3RdSBaOOU for ; Tue, 13 Mar 2012 04:24:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 99B2821F86AB for ; Tue, 13 Mar 2012 04:24:14 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2DBO6au029683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Mar 2012 12:24:06 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2DBO4EJ015078; Tue, 13 Mar 2012 12:24:06 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 12:23:49 +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: Tue, 13 Mar 2012 12:23:34 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F011E1FEB@DEMUEXC014.nsn-intra.net> In-Reply-To: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt Thread-Index: Ac0Amh4vX6gyNYF7ReuA9y6Rd+g7RgAaW+Mg References: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> From: "Belling, Thomas (NSN - DE/Munich)" To: , "ext Alan Johnston" X-OriginalArrivalTime: 13 Mar 2012 11:23:49.0979 (UTC) FILETIME=[C37F72B0:01CD010B] 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: 6857 X-purgate-ID: 151667::1331637846-000044A2-7B9972DA/0-0/0-0 Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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, 13 Mar 2012 11:24:16 -0000 Dear Alan, unfortunately you forgot to improve the hex encoding definition. I paste in relevant parts of an my old email proposal on the email list plus Paul's replies. As nobody else replied on those points I were confident that they were acceptable: > Dear all > > Checking draft-ietf-cuss-sip-uui-04, I found that the definition of hex encoding could be improved: > > What came closest to a definition of the encoding was the following: > > " > 5. Guidelines for UUI Packages > ... > This specification defines only the value of "hex" for the "encoding" > parameter. Hex encoding, as used for UUI data is defined to use only > the characters 0-9, A-F, or a-f. Hex encoded UUI data must have an > even number of octets, and is considered invalid if has an odd > number. Hex encoding is normally done as a token, although quoted- > string is permitted, in which case the quotes are ignored. Hex > encoding yields a sequence of octets, one octet per two hex digits, > in the same order, with the first digit of each pair defining the > high order four bits of the octet and the second digit providing the > low order four bits. > " > > > I see a couple of issues: > > 1. This seems to be in a strange place within the draft to define the hex encoding. I would rather suggest a dedicated subclause "4.x Hex encoding definition" Seems reasonable. > 2. "Hex encoding yields a sequence of octets, one octet per two hex digits" > I believe it is rather the other way round: "Hex encoding of a series of octets of binary data yields a series of hexadecimal digits, two hexadecimal digits for each octet of binary data.". Hexadecimal digits seem to be called "octets" throughout the text, which is highly confusing. I agree. > 3. "Hex encoded UUI data must have an even number of octets, and is considered invalid if has an odd number." This is a similar problem, and the text is quite ambiguous: Does "octet" refer to the binary data to be encoded or the result of the encoding? The text only makes sense if "octet" is understood as the result of encoding. Speaking about "characters" or "hexadecimal digits" rather than "octets" would remove this ambiguity. I agree. > 4. Lack of normative language ("MUST") > In the mean time I discovered some additional related issues: 5. "Hex encoding yields a sequence of octets, one octet per two hex digits, in the same order, with the first digit of each pair defining the high order four bits of the octet and the second digit providing the low order four bits." This text says that the most significant four bytes always come first in the binary data. However, this depends on the nature of the binary data and cannot be defined here. It is enough to state that the first bits in the binary UUI data shall be mapped to the first Hex digit. This also makes an interworking box to ISUP much simpler. 6. It is unclear how 4 bits of binary data are mapped to a hex digit: Shall the first or last bit of the binary data be most significant for the purpose of that mapping? I assume the first bit. 7. The text seems to assume that the binary data to be encoded have a full octet length without stating so. I added such a statement. For discussion: if we also want to allow for other lengths of binary data, we may want to define some padding (e.g. with Zero bits) to the next octet boundary. Unfortunately I could imagine that this sometimes leads to ambiguities when decoding. I understand that some other of my old related proposals (only upper-case characters and token) were controversial, so I do not include them in my text proposal below. To sum up, a text proposal: 4.x Hex encoding definition This specification defines only the value of "hex" for the "encoding" parameter. It is used to encode binary UUI data with a length that terminates at an octet boundary. Each octet of binary data to be represented in the hex encoding MUST be mapped to two hexadecimal digits (represented by ASCII characters 0-9, A-F and a-f), each representing four bits within the octet. The four bits appearing first in the binary UUI data MUST be mapped to the first hexadecimal digit and the four subsequent bits in the binary UUI data MUST be mapped to the second hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the bit appearing first in the binary UUI data shall be most significant.=20 Thus, Hex encoded UUI data must have an even number of hexadecimal digits, and MUST be considered invalid if has an odd number. Hex encoding is normally done as a token, although quoted- string is permitted, in which case the quotes MUST be ignored. =20 As another issue, you now have much procedural text, in particular related to redirection, in your "Syntax" clause 4.1. What about placing this in a new subclause 4.x instead? Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org Sent: Monday, March 12, 2012 10:50 PM To: i-d-announce@ietf.org Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. Title : A Mechanism for Transporting User to User Call Control Information in SIP Author(s) : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-05.txt Pages : 17 Date : 2012-03-12 There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a certain application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Tue Mar 13 10:44: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 9EADF21E8053 for ; Tue, 13 Mar 2012 10:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 O4mVN9IhonNz for ; Tue, 13 Mar 2012 10:44:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79D2721E8049 for ; Tue, 13 Mar 2012 10:44:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so954475ghb.31 for ; Tue, 13 Mar 2012 10:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+uAzNRQ2P8LFr5m/e3UVtExYkmDdl0lTftC2xAL0Nd4=; b=pqa45PjMV3Bh361/JTWrb1XjbAPIIeQbOD28sJRA/paNTbr9cKLiUHCNrJRqWiOgP0 W7lB/+nKqLMO3wWEILG6QLYQp7F7Ur61lbQoKy/Z8Z7ETh4qKWaKNQDm1i6FP10kzu5t mOs1sBGTtiiAD1te14XoQG/eF+Vh5Jr59AyeSBgrN9KAyBQ0CJBzr46vZANBX7WT2OQd wfFicOw0f4VBqJmilnweASkiHlTwtOlw2Kk6SpPz8/T3Cb6yX0CiBRkCUtjAFLPEXNLB 0NmkVliFJ6B/96v5xIYBHrRfteP1mzRAFu0LK6MwTmFhaVI1wt6wCXLkA3Zxgujxh2Fd +LMQ== MIME-Version: 1.0 Received: by 10.182.4.176 with SMTP id l16mr8474572obl.43.1331660684834; Tue, 13 Mar 2012 10:44:44 -0700 (PDT) Received: by 10.182.192.41 with HTTP; Tue, 13 Mar 2012 10:44:44 -0700 (PDT) In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F011E1FEB@DEMUEXC014.nsn-intra.net> References: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> <1A8A7D59006A8240B27FF63C794CA57F011E1FEB@DEMUEXC014.nsn-intra.net> Date: Tue, 13 Mar 2012 12:44:44 -0500 Message-ID: From: Alan Johnston To: "Belling, Thomas (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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, 13 Mar 2012 17:44:46 -0000 Thomas, Yes, you are right - I was concentrating on the reviews and forgot about this thread. I'll propose some text for hex coding so we can discuss it on the list. - Alan - On Tue, Mar 13, 2012 at 6:23 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Alan, > > unfortunately you forgot to improve the hex encoding definition. I paste > in relevant parts of an my old email proposal on the email list plus > Paul's replies. As nobody else replied on those points I were confident > that they were acceptable: > >> Dear all >> >> Checking draft-ietf-cuss-sip-uui-04, I found that the definition of > hex encoding could be improved: >> >> What came closest to a definition of the encoding was the following: >> >> " >> 5. =A0Guidelines for UUI Packages >> ... >> =A0 =A0 This specification defines only the value of "hex" for the > "encoding" >> =A0 =A0 parameter. =A0Hex encoding, as used for UUI data is defined to u= se > only >> =A0 =A0 the characters 0-9, A-F, or a-f. =A0Hex encoded UUI data must ha= ve > an >> =A0 =A0 even number of octets, and is considered invalid if has an odd >> =A0 =A0 number. =A0Hex encoding is normally done as a token, although > quoted- >> =A0 =A0 string is permitted, in which case the quotes are ignored. =A0He= x >> =A0 =A0 encoding yields a sequence of octets, one octet per two hex > digits, >> =A0 =A0 in the same order, with the first digit of each pair defining th= e >> =A0 =A0 high order four bits of the octet and the second digit providing > the >> =A0 =A0 low order four bits. >> " >> >> >> I see a couple of issues: >> >> 1. This seems to be in a strange place within the draft to define the > hex encoding. I would rather suggest a dedicated subclause "4.x Hex > encoding definition" > > Seems reasonable. > >> 2. "Hex encoding yields a sequence of octets, one octet per two hex > digits" >> I believe it is rather the other way round: "Hex encoding of a series > of octets of binary data yields a series of hexadecimal digits, two > hexadecimal digits for each octet of binary data.". Hexadecimal digits > seem to be called "octets" throughout the text, which is highly > confusing. > > I agree. > >> 3. "Hex encoded UUI data must have an even number of octets, and is > considered invalid if has an odd number." This is a similar problem, and > the text is quite ambiguous: Does "octet" refer to the binary data to be > encoded or the result of the encoding? The text only makes sense if > "octet" is understood as the result of encoding. Speaking about > "characters" or "hexadecimal digits" rather than "octets" would remove > this ambiguity. > > I agree. > >> 4. Lack of normative language ("MUST") >> > > > In the mean time I discovered some additional related issues: > > 5. "Hex encoding yields a sequence of octets, one octet per two hex > digits, > in the same order, with the first digit of each pair defining the > high order four bits of the octet and the second digit providing the > low order four bits." > This text says that the most significant four bytes always come first in > the binary data. > However, this depends on the nature of the binary data and cannot be > defined here. > It is enough to state that the first bits in the binary UUI data shall > be mapped to the first > Hex digit. This also makes an interworking box to ISUP much simpler. > > 6. It is unclear how 4 bits of binary data are mapped to a hex digit: > Shall the first or last bit > of the binary data be most significant for the purpose of that mapping? > I assume the first bit. > > 7. The text seems to assume that the binary data to be encoded have a > full octet length without stating so. > I added such a statement. > For discussion: if we also want to allow for other lengths of binary > data, > we may want to define some padding (e.g. with Zero bits) to the next > octet boundary. Unfortunately I could > imagine that this sometimes leads to ambiguities when decoding. > > > I understand that some other of my old related proposals (only > upper-case characters and token) were controversial, > so I do not include them in my text proposal below. > > > To sum up, a text proposal: > > 4.x Hex encoding definition > =A0 =A0This specification defines only the value of "hex" for the > "encoding" > =A0 =A0parameter. =A0It is used to encode binary UUI data with a length t= hat > =A0 =A0terminates at an octet boundary. Each octet of binary data to be > =A0 =A0represented in the hex encoding MUST be mapped to two hexadecimal > digits > =A0 =A0(represented by ASCII characters 0-9, A-F and a-f), each > representing > =A0 =A0four bits within the octet. The four bits appearing first in the > binary UUI > =A0 =A0data MUST be mapped to the first hexadecimal digit and the four > subsequent > =A0 =A0bits in the binary UUI data MUST be mapped to the second > =A0 =A0hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the > bit > =A0 =A0appearing first in the binary UUI data shall be most significant. > =A0 =A0Thus, Hex encoded UUI data must have an even number > =A0 =A0of hexadecimal digits, and MUST be considered invalid if has an od= d > =A0 =A0number. Hex encoding is normally done as a token, although quoted- > =A0 =A0string is permitted, in which case the quotes MUST be ignored. > > > > > As another issue, you now have much procedural text, in particular > related to redirection, in your "Syntax" clause 4.1. What about placing > this in a new subclause 4.x instead? > > > Thomas > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: Monday, March 12, 2012 10:50 PM > To: i-d-announce@ietf.org > Cc: cuss@ietf.org > Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Call Control UUI Service > for SIP Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Mechanism for Transporting U= ser to User Call > Control Information in SIP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Rafferty > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-cuss-sip-uui-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 There is a class of applications which benefit from using SIP to > =A0 exchange User to User Information (UUI) data during session > =A0 establishment. =A0This information, known as call control UUI data, i= s > =A0 a small piece of data inserted by an application initiating the > =A0 session, and utilized by an application accepting the session. =A0The > =A0 rules which apply for a certain application are defined by a UUI > =A0 package. =A0This UUI data is opaque to SIP and its function is > =A0 unrelated to any basic SIP function. =A0This document defines a new S= IP > =A0 header field, User-to-User, to transport UUI data, along with an > =A0 extension mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From shida@ntt-at.com Wed Mar 14 03:42:04 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 5903721F85FF for ; Wed, 14 Mar 2012 03:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 JP5xGxBHrHMY for ; Wed, 14 Mar 2012 03:42:03 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B26A121F85FB for ; Wed, 14 Mar 2012 03:42:03 -0700 (PDT) Received: from [119.242.41.127] (port=58066 helo=[192.168.1.14]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S7leb-00040B-I6; Wed, 14 Mar 2012 05:42:01 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 14 Mar 2012 19:42:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3E518A2B-D213-4C23-8FEA-9EDE3CBA208A@ntt-at.com> References: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> To: Alan Johnston X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-119-242-41-127.tky.mesh.ad.jp ([192.168.1.14]) [119.242.41.127]:58066 X-Source-Auth: shida@agnada.com X-Email-Count: 5 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: cuss@ietf.org Subject: Re: [cuss] Review of draft-ietf-cuss-sip-uui 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, 14 Mar 2012 10:42:04 -0000 Alan; I checked the updates and your comments.=20 I have no more comments.=20 It looks good to me.=20 Thanks & Regards Shida On Mar 13, 2012, at 6:50 AM, Alan Johnston wrote: > Shida, >=20 > Thanks very much for the review. I believe I have addressed your = issues in the -05 version. See a few comments below. >=20 > - Alan - >=20 >=20 > On Nov 28, 2011, at 7:10 PM, Shida Schubert wrote: >=20 >>=20 >> I was asked by chairs of this WG to review=20 >> draft-ietf-cuss-sip-uui.=20 >>=20 >> Below are my comments=20 >>=20 >> ** OVERALL *** >>=20 >> The draft talks a lot about escaping the header.=20 >> We used the same terminology in rfc4244bis, but=20 >> after some discussion decided with "including/include". >>=20 >> I think the reason was due to the fact that 3261 doesn't=20 >> use "escape" in that context.=20 >=20 > Done. >=20 >>=20 >> I didn't see any issue with how the rfc4244bis is used. >=20 > Great! >=20 >>=20 >> ** TECHNICAL *** >>=20 >> 1. Will the behavior of the device be affected if the=20 >> source of UUI data is different from the assumed entity? >> I am assuming it doesn't as the inserterthere is an a priori = understanding ... of the UUI=20 >> data doesn't seem too be so important from the draft.=20 >=20 > Not really, although I did put in some text in the security = considerations saying a UA can apply policy to the processing of UUI = data based on who inserted it. >=20 >>=20 >> 2. I think there is little or no text about the behavior=20 >> of entity receiving UUI data, encoding or package=20 >> that it doesn't understand. I am assuming it simply =20 >> ignores it but, I think this should be explicitly=20 >> stated somewhere in normative language.=20 >=20 > I added a statement saying unknown packages and encodings should be = ignored. >=20 >>=20 >> 3. Section 3 talks about UUI header being removed=20 >> by proxy/intermediary. But it is mute about intermediary=20 >> adding UUI header, leaving room for them to add it.=20 >> So what would happen if intermediary adds UUI header?=20 >> Who is the inserter? What does that mean? If we don't=20 >> see any use for intermediary adding the header, I think=20 >> we should say MUST NOT for intermediary.=20 >=20 > Well, this would be tricky to write in a way that doesn't confuse. = The spec is clear that UUI is between UAs, not between anyone else. = However, UUI data included in a 3xx could be inserted by a proxy that = recurses on the 3xx, but it isn't really the proxy that is inserting it. = I >=20 >>=20 >> 4. I think normative text surrounding redirecting entity=20 >> adding user-to-user info be added.=20 >=20 > I added a SHOULD level statement. >=20 >>=20 >> 5. When UAS redirects the request with=20 >> User-to-User: foo;package=3D1;encoding=3Dhex to a=20 >> contact with a User-to-User:bar;package=3D1;encoding=3Dhex.=20 >>=20 >> I am assuming that you will end up with=20 >>=20 >> User-to-User: foo;package=3D1;encoding=3Dhex, = bar;package=3D1,encoding=3Dhex >>=20 >> You end up with two uui data from two different entity.=20 >> Is this going to pose problem?=20 >=20 > This is a very good point. I don't think the mechanism itself should = be definitive on this. But packages must say how to handle this. I = even think that the same content with multiple encodings seems like a = good idea, except for the ISDN service where it isn't backwards = compatible. There is new text in Section 5 about this. >=20 >>=20 >> I guess if 4244bis was supported, this would be=20 >> logged and one can see that the latter was added by=20 >> an UAS which redirected the request.. Do we need to=20 >> add some text regarding this? Are the last value more=20 >> important than the one added by the originator of the=20 >> request? >=20 > I don't think so. Having History-Info to sort it out is about the = best we can do. >=20 >>=20 >> ** NITS *** >> Section 1 >>=20 >> OLD : there is an a priori understanding ... >> NEW : there is a priori understanding ... >=20 > I kept the old text as I think it is right - the RFC editor will have = the final say, of course. >=20 >>=20 >> Section 5 >>=20 >> OLD : SIP UUI mechanism must publish a standard track. >> NEW : SIP UUI mechanism MUST publish a standard tack. >>=20 >> OLD : some use case example examples. >> NEW : some use case examples.=20 >>=20 >> OLD : Hex encoded UUI data must have an even... >> NEW : Hex encoded UUI data MUST have an even.. >>=20 >> OLD : New "encoding" values must reference... >> NEW : New "encoding" values MUST reference.. >>=20 >> OLD : New "content" values must describe... >> NEW : New "content" values MUST describe.. >>=20 >> I hope this helps.=20 >=20 > Very much - thanks! >=20 >>=20 >> Regards >> Shida=20 >>=20 >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >=20 From enrico.marocco@telecomitalia.it Wed Mar 14 08:36:40 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 89D4421F879B for ; Wed, 14 Mar 2012 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.275 X-Spam-Level: X-Spam-Status: No, score=-101.275 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 2elR4Y9mEJYp for ; Wed, 14 Mar 2012 08:36:40 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9132521F8766 for ; Wed, 14 Mar 2012 08:36:39 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 14 Mar 2012 16:36:36 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 14 Mar 2012 16:36:35 +0100 Message-ID: <4F60BB7D.1040100@telecomitalia.it> Date: Wed, 14 Mar 2012 16:38:37 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "cuss@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060802030601090101090101" X-TI-Disclaimer: Disclaimer1 Subject: [cuss] Draft agenda posted 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, 14 Mar 2012 15:36:40 -0000 --------------ms060802030601090101090101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks, the preliminary agenda for the next face-to-face meeting (currently scheduled for Fri, March 30, 11:30-12:30) has been posted and is now available at: http://www.ietf.org/proceedings/83/agenda/agenda-83-cuss.ht= ml Please take a look and feel free to suggest any changes. --=20 Ciao, Enrico --------------ms060802030601090101090101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINfjCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHQjCCBiqgAwIBAgIDAt9AMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTEwODIyMDYyNDA2 WhcNMTIwODIyMDM0MDM3WjB8MSAwHgYDVQQNExc0OTAyNDItOU1QZVJYRnFlVVU0QUMybTEo MCYGA1UEAwwfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEuMCwGCSqGSIb3DQEJ ARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALl4L3Uj7TJrMbll5JAyphws2AMR67q3D2FH0JmRqQ5r+ujqaxyeHcrx Kclu2tz/D3SPtZAlcDOclxpEDbpxXlMpo+3DsbNweNgSF6mnyRDYU2ay3qO54ENz21GZ64bl ZRsMI6KsGnxm7sORWLUdx229ijARs3aQD1js9bidUJsnxg26UvnwpJ8eGoFiCLzzsQXUD+OL 3TXEGrTzt+B2RDb13TIOe085T8jzBh08wNKPTDmKjxy5m35Xn8QfRy8b93d0wUs98Fst5iND EgHEHc9CwurwLYrOd/1ZkbfAoRi7kRQ0Ih4wKkP+Lkww/0qHEIrrgW+aVmGjkQ0nidAaE+sC AwEAAaOCA7owggO2MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUYgEiK9qxBHth8ziqydxV7QYZn1QwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVs ZWNvbWl0YWxpYS5pdDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUF BwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVz IGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0 aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAF4gnxCzZVmINcZh7ZMB6G1+8/kV6pLqDxyUidalFSJ8KLwJxrxhESOb+E7d JHxZBuJFH1NBXuVn+MI7rqa/HI7PkLJjkHhMH8ay7jhR2VVMIFYAqRn9O22oDDw2iEigYkgo HcHP1vD5rtydbGr6mCcHOtWCk5B7FqEoMYTQRO1F6szoqORVaajVtZeSwtVAMufV20tohyUL hpOH5lZDblsej2XueyJVqD8RYSUJp7w4eMpr5CTP9QdNBS0cca83JA070JMudV+ozG6ADIBx mGPrWyPv7PmjBBGIXxPJJRxDsDyJBYhs+qh6fZWNl6WZkQNepkn7IAUB0+0ggds992kxggPQ MIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30AwCQYF Kw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwMzE0MTUzODM3WjAjBgkqhkiG9w0BCQQxFgQUnuUcAzlibP5GrMSYsg5DZaf29HYwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAt9AMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30Aw DQYJKoZIhvcNAQEBBQAEggEAKZ6POZep+dm8Lv8mOfhETWR5Lz6k2e1mGxeZVD24buWrwVJj MbYexiNGQZ47IiQCK4VHbzl0pVarhnrqPKi+GXqTsNFpq/omCzXasgeCFTU3jwzivFBKaq0a /JM0ylk2n67j44w4kcp2AstoqQF8VVKTjNbprpJoY2qmJSwpMOXEb4TNEE+reTLagnXy/pNj 8t//zLP7yZ2MI8cmlZZx0nTjCDqP0TXxQi86Fj3fqsaaXq8lUYrF84r39GqOD6d2DGuf+ThH Y+k3FSetqju/1V51hq0Da6cw8monXXDaLQeEYJgf2bQgTkDpb+1qxA6t5sgvHIjFzXY8BXfl GezPdAAAAAAAAA== --------------ms060802030601090101090101-- From celine.serrutvalette@orange.com Mon Mar 26 06:06: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 9603F21E8095 for ; Mon, 26 Mar 2012 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 mI+8RGVDvRPj for ; Mon, 26 Mar 2012 06:06:17 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1195721E808E for ; Mon, 26 Mar 2012 06:06:11 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3E5CA44179; Mon, 26 Mar 2012 15:07:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C8B14A44178; Mon, 26 Mar 2012 15:07:40 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 15:06:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 15:06:07 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202447EC8@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt Thread-Index: Ac0Amh2uMmCBxubPTtaKk2rX75jYSQKsYmGQAAEB64A= References: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> From: To: , X-OriginalArrivalTime: 26 Mar 2012 13:06:09.0701 (UTC) FILETIME=[366D6D50:01CD0B51] Cc: cuss@ietf.org Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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, 26 Mar 2012 13:06:18 -0000 Hello, I would have 2 comments (related to my 2 previous comments on the former = version -04) on your updated draft-ietf-cuss-sip-uui-05: - 1/ in section 4.1, it's indicated that "Multiple User-to-User header = fields MAY be present in a request or response" but it doesn't clarify = if it could be using the same or different packages. As you proposed = before in your reply, would it be possible to indicate that "Multiple = User-to-User header fields MAY be present in a request or response, = containing uui-data for the same or for different packages"? - 2/ in section 4.1, the example "User-to-User: = 56a390f3d2b7310023a;encoding=3Dhex;purpose=3Dfoo;content=3Dbar" contains = the "purpose" parameter in replacement of the "package" parameter. Would = it be possible to extend the use of the "purpose" parameter to the rest = of the document? Indeed, "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. For that, it will be necessary to change the definition of the parameter = in section 4 as follows: The "package" parameter identifies the package which defines the = generation and usage of the UUI data for a particular application. =3D=3D> The "purpose" parameter identifies the purpose of the package which = defines the generation and usage of the UUI data for a particular = application.=20 Thank you in advance. Best Regards, Celine serrut-valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de internet-drafts@ietf.org Envoy=E9=A0: lundi 12 mars 2012 22:50 =C0=A0: i-d-announce@ietf.org Cc=A0: cuss@ietf.org Objet=A0: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Call Control UUI Service = for SIP Working Group of the IETF. Title : A Mechanism for Transporting User to User Call = Control Information in SIP Author(s) : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-05.txt Pages : 17 Date : 2012-03-12 There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a certain application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Tue Mar 27 02:57:39 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 C4DDF21E80B2 for ; Tue, 27 Mar 2012 02:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.607 X-Spam-Level: X-Spam-Status: No, score=-109.607 tagged_above=-999 required=5 tests=[AWL=0.642, 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 ZvoEWvBDA7-k for ; Tue, 27 Mar 2012 02:57:39 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id E714C21E800E for ; Tue, 27 Mar 2012 02:57:38 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2R9v8YU011309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 27 Mar 2012 11:57:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 27 Mar 2012 11:57:34 +0200 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Tue, 27 Mar 2012 11:57:33 +0200 Thread-Topic: Some comments on draft-ietf-cuss-sip-uui-05 Thread-Index: Ac0MAAeW1kpHoab3Qna40hnqQ0RXCg== 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] Some comments on draft-ietf-cuss-sip-uui-05 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, 27 Mar 2012 09:57:39 -0000 1) Section 1 Overview I think the first paragraph here needs rewriting. It implies that the funct= ion of this document is to provide the ISDN service, whereas it is this doc= ument plus the ISDN package that provides that. It could be trying to say i= s that we are developing this capability because the ISDN has something sim= ilar, but it doesn't say that at the moment. 2) Throughout the document replace "UUI header field" with "User-to-User he= ader field". 3) I think we need some more words generally on compatibility and extendibi= lity. Obviously the primary means of extendibility is to define a new package, an= d either to use it in parallel or in place of another package. But is it possible for an updated RFC to extend the number of values of eit= her the "encoding" header field parameter or the "content" header field par= ameter within an existing package. The net effect of this on an older implementation is that it will have to d= iscard the information that it does not understand.=20 It is possible that an application using a package could handle this loss o= f data at the application layer itself, either by negotiation of capabiliti= es within the application layer itself, or where the information discarded = is not important. I'll admit that the use case for this is not compulsive, particularly if we= wish the UUIdata that may have been discarded to have some impact on SIP c= all control. Either way we should indicate the possibility or not in the draft. I would = suggest having a separate section that covers compatibility and extendibili= ty. 4) Section 4 " If not present, the content MUST be assumed to be unknown as it is in the ISDN UUI Service. Newly defined UUI packages MUST define a new "content" value." The way this has been treated in the ISDN package is that the package defin= es the default value that is the understanding if it is not present. This i= s not reflected by this text so one of the documents needs to change. Regards Keith From alan.b.johnston@gmail.com Wed Mar 28 04:15:38 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 8EA1221E801A for ; Wed, 28 Mar 2012 04:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.521 X-Spam-Level: X-Spam-Status: No, score=-103.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 DyM3K0liRuAg for ; Wed, 28 Mar 2012 04:15:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD8EC21E8019 for ; Wed, 28 Mar 2012 04:15:37 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1423701obb.31 for ; Wed, 28 Mar 2012 04:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UkCZNdza/sbs+guC+YM3/71rwRpUUFXn/mebEYm0SQM=; b=iCXHO7frLBibkGLzHQPgH/aMH5CMfpvgGMAB4yTdnoUvhyrcJd0lBRMcjmq6XxvjLy kiP5owlp3lR0LPfbkhIWNYfGuI6KNTtIkatC7fX0X5WsHtbjudXn9Ai6s+mqWO8TG/gr va0YAjlGBKapY6oyBJWRspds30yiRJBgc9ltR3b/1Uw+WdjMAUbnh1WCr7kLU7g3YzLg F7hmr4ibQtiENrfiIGEd+m6PvaeY8eVOcnV2wBXFNFVKkpkuKn2/9Y7DOwalBlkDZOIe K/pKrQkfNpf6n0FhLyRHXND3OzbP1NEP0DC/FhJyov75MPSpmZv+/jJUZyfBr1K0sBxB zHrg== MIME-Version: 1.0 Received: by 10.60.3.9 with SMTP id 9mr36452242oey.49.1332933337311; Wed, 28 Mar 2012 04:15:37 -0700 (PDT) Received: by 10.182.217.6 with HTTP; Wed, 28 Mar 2012 04:15:37 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202447EC8@ftrdmel0.rd.francetelecom.fr> References: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> <843DA8228A1BA74CA31FB4E111A5C46202447EC8@ftrdmel0.rd.francetelecom.fr> Date: Wed, 28 Mar 2012 06:15:37 -0500 Message-ID: From: Alan Johnston To: celine.serrutvalette@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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: Wed, 28 Mar 2012 11:15:38 -0000 Celine, On #1, I'm fine calling out that the multiple UUI data elements can be for the same or different packages. On #2, it was a cut-and-paste error that left the "purpose" parameter. The next version will change this to "package", so we will not be using "purpose" going forward. - Alan - On Mon, Mar 26, 2012 at 8:06 AM, wrote: > Hello, > > I would have 2 comments (related to my 2 previous comments on the former = version -04) on your updated draft-ietf-cuss-sip-uui-05: > > - 1/ in section 4.1, it's indicated that "Multiple User-to-User header fi= elds MAY be present in a request or response" but it doesn't clarify if it = could be using the same or different packages. As you proposed before in yo= ur reply, would it be possible to indicate that "Multiple User-to-User head= er fields MAY be present in a request or response, containing uui-data for = the same or for different packages"? > > - 2/ in section 4.1, the example "User-to-User: 56a390f3d2b7310023a;encod= ing=3Dhex;purpose=3Dfoo;content=3Dbar" contains the "purpose" parameter in = replacement of the "package" parameter. Would it be possible to extend the = use of the "purpose" parameter to the rest of the document? Indeed, "purpos= e" is a relevant name if the parameter is defined as to indicate the purpos= e of the package mechanism used to convey the IUU data. Moreover it has the= benefit to be backward compatible with historical draft-johnston-sipping-c= c-uui-08 on which some implementations are based. > For that, it will be necessary to change the definition of the parameter = in section 4 as follows: > > The "package" parameter identifies the package which defines the generati= on and usage of the UUI data for a particular application. > > =3D=3D> > > The "purpose" parameter identifies the purpose of the package which defin= es the generation and usage of the UUI data for a particular application. > > > Thank you in advance. > Best Regards, > > Celine serrut-valette > Orange Labs > > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de= internet-drafts@ietf.org > Envoy=E9=A0: lundi 12 mars 2012 22:50 > =C0=A0: i-d-announce@ietf.org > Cc=A0: cuss@ietf.org > Objet=A0: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Call Control UUI Service for SIP Wo= rking Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Mechanism for Transporting U= ser to User Call Control Information in SIP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Rafferty > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-cuss-sip-uui-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 There is a class of applications which benefit from using SIP to > =A0 exchange User to User Information (UUI) data during session > =A0 establishment. =A0This information, known as call control UUI data, i= s > =A0 a small piece of data inserted by an application initiating the > =A0 session, and utilized by an application accepting the session. =A0The > =A0 rules which apply for a certain application are defined by a UUI > =A0 package. =A0This UUI data is opaque to SIP and its function is > =A0 unrelated to any basic SIP function. =A0This document defines a new S= IP > =A0 header field, User-to-User, to transport UUI data, along with an > =A0 extension mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Wed Mar 28 04:16:30 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 B756921F89B5 for ; Wed, 28 Mar 2012 04:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 0EXokNKRYhFv for ; Wed, 28 Mar 2012 04:16:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB721F89AA for ; Wed, 28 Mar 2012 04:16:29 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1424854obb.31 for ; Wed, 28 Mar 2012 04:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t4FWDkkTN5PIJa229RvINY/03miQjIhMCW98NzWUUvg=; b=lnM6LVm2DA0HG4kMZ775qbInO6CGZB0CVDiPfu65llwLzgjuJIf9xLVmIp/iVEs9FW BexTz4OHN9wWAubpT3IBJecBUO4AQsVFp4e47LusPjzRTTlGuhoq5vf0/NTgepxrtdjA 0e8saoNystEu+dvr+/vp+wdoIgIUPXaISTe0KBU7B0yh5UxMQM+rwIAJ/D4iiU+LDlWU 3TOmdOekPj2Ze/6VQSgR+FwhpVf8EMcYQ+OThDlF7CXvYctIivN0+xtjfBT471vhmWk9 Fyy15sE+3cmnuOrRCwrqUSrQMrbJVwBwf8gmEGb03VEAsxmVv/uDvZJGxhhvJZT9Dw6U xRrA== MIME-Version: 1.0 Received: by 10.60.9.232 with SMTP id d8mr36341661oeb.66.1332933389422; Wed, 28 Mar 2012 04:16:29 -0700 (PDT) Received: by 10.182.217.6 with HTTP; Wed, 28 Mar 2012 04:16:29 -0700 (PDT) In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F011E1FEB@DEMUEXC014.nsn-intra.net> References: <20120312215010.29495.80634.idtracker@ietfa.amsl.com> <1A8A7D59006A8240B27FF63C794CA57F011E1FEB@DEMUEXC014.nsn-intra.net> Date: Wed, 28 Mar 2012 06:16:29 -0500 Message-ID: From: Alan Johnston To: "Belling, Thomas (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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: Wed, 28 Mar 2012 11:16:30 -0000 Thomas, My apologies for missing the proposed text at the end of your mail. Your text looks fine - we will include it in the next version. - Alan - On Tue, Mar 13, 2012 at 6:23 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Alan, > > unfortunately you forgot to improve the hex encoding definition. I paste > in relevant parts of an my old email proposal on the email list plus > Paul's replies. As nobody else replied on those points I were confident > that they were acceptable: > >> Dear all >> >> Checking draft-ietf-cuss-sip-uui-04, I found that the definition of > hex encoding could be improved: >> >> What came closest to a definition of the encoding was the following: >> >> " >> 5. =A0Guidelines for UUI Packages >> ... >> =A0 =A0 This specification defines only the value of "hex" for the > "encoding" >> =A0 =A0 parameter. =A0Hex encoding, as used for UUI data is defined to u= se > only >> =A0 =A0 the characters 0-9, A-F, or a-f. =A0Hex encoded UUI data must ha= ve > an >> =A0 =A0 even number of octets, and is considered invalid if has an odd >> =A0 =A0 number. =A0Hex encoding is normally done as a token, although > quoted- >> =A0 =A0 string is permitted, in which case the quotes are ignored. =A0He= x >> =A0 =A0 encoding yields a sequence of octets, one octet per two hex > digits, >> =A0 =A0 in the same order, with the first digit of each pair defining th= e >> =A0 =A0 high order four bits of the octet and the second digit providing > the >> =A0 =A0 low order four bits. >> " >> >> >> I see a couple of issues: >> >> 1. This seems to be in a strange place within the draft to define the > hex encoding. I would rather suggest a dedicated subclause "4.x Hex > encoding definition" > > Seems reasonable. > >> 2. "Hex encoding yields a sequence of octets, one octet per two hex > digits" >> I believe it is rather the other way round: "Hex encoding of a series > of octets of binary data yields a series of hexadecimal digits, two > hexadecimal digits for each octet of binary data.". Hexadecimal digits > seem to be called "octets" throughout the text, which is highly > confusing. > > I agree. > >> 3. "Hex encoded UUI data must have an even number of octets, and is > considered invalid if has an odd number." This is a similar problem, and > the text is quite ambiguous: Does "octet" refer to the binary data to be > encoded or the result of the encoding? The text only makes sense if > "octet" is understood as the result of encoding. Speaking about > "characters" or "hexadecimal digits" rather than "octets" would remove > this ambiguity. > > I agree. > >> 4. Lack of normative language ("MUST") >> > > > In the mean time I discovered some additional related issues: > > 5. "Hex encoding yields a sequence of octets, one octet per two hex > digits, > in the same order, with the first digit of each pair defining the > high order four bits of the octet and the second digit providing the > low order four bits." > This text says that the most significant four bytes always come first in > the binary data. > However, this depends on the nature of the binary data and cannot be > defined here. > It is enough to state that the first bits in the binary UUI data shall > be mapped to the first > Hex digit. This also makes an interworking box to ISUP much simpler. > > 6. It is unclear how 4 bits of binary data are mapped to a hex digit: > Shall the first or last bit > of the binary data be most significant for the purpose of that mapping? > I assume the first bit. > > 7. The text seems to assume that the binary data to be encoded have a > full octet length without stating so. > I added such a statement. > For discussion: if we also want to allow for other lengths of binary > data, > we may want to define some padding (e.g. with Zero bits) to the next > octet boundary. Unfortunately I could > imagine that this sometimes leads to ambiguities when decoding. > > > I understand that some other of my old related proposals (only > upper-case characters and token) were controversial, > so I do not include them in my text proposal below. > > > To sum up, a text proposal: > > 4.x Hex encoding definition > =A0 =A0This specification defines only the value of "hex" for the > "encoding" > =A0 =A0parameter. =A0It is used to encode binary UUI data with a length t= hat > =A0 =A0terminates at an octet boundary. Each octet of binary data to be > =A0 =A0represented in the hex encoding MUST be mapped to two hexadecimal > digits > =A0 =A0(represented by ASCII characters 0-9, A-F and a-f), each > representing > =A0 =A0four bits within the octet. The four bits appearing first in the > binary UUI > =A0 =A0data MUST be mapped to the first hexadecimal digit and the four > subsequent > =A0 =A0bits in the binary UUI data MUST be mapped to the second > =A0 =A0hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the > bit > =A0 =A0appearing first in the binary UUI data shall be most significant. > =A0 =A0Thus, Hex encoded UUI data must have an even number > =A0 =A0of hexadecimal digits, and MUST be considered invalid if has an od= d > =A0 =A0number. Hex encoding is normally done as a token, although quoted- > =A0 =A0string is permitted, in which case the quotes MUST be ignored. > > > > > As another issue, you now have much procedural text, in particular > related to redirection, in your "Syntax" clause 4.1. What about placing > this in a new subclause 4.x instead? > > > Thomas > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: Monday, March 12, 2012 10:50 PM > To: i-d-announce@ietf.org > Cc: cuss@ietf.org > Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Call Control UUI Service > for SIP Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Mechanism for Transporting U= ser to User Call > Control Information in SIP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Rafferty > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-cuss-sip-uui-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 There is a class of applications which benefit from using SIP to > =A0 exchange User to User Information (UUI) data during session > =A0 establishment. =A0This information, known as call control UUI data, i= s > =A0 a small piece of data inserted by an application initiating the > =A0 session, and utilized by an application accepting the session. =A0The > =A0 rules which apply for a certain application are defined by a UUI > =A0 package. =A0This UUI data is opaque to SIP and its function is > =A0 unrelated to any basic SIP function. =A0This document defines a new S= IP > =A0 header field, User-to-User, to transport UUI data, along with an > =A0 extension mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Thu Mar 29 02:50: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 CF91621F888A for ; Thu, 29 Mar 2012 02:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 5ETPmidw-5y3 for ; Thu, 29 Mar 2012 02:50:11 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1021F8879 for ; Thu, 29 Mar 2012 02:50:11 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D2A7D16C0B9; Thu, 29 Mar 2012 11:50:06 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C379F16C0B2; Thu, 29 Mar 2012 11:50:06 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 11:50:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 11:50:04 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462024485AD@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt Thread-Index: Ac0M1BuO0xe8YttWTpKgdNJscFxqIgAuIXMA References: <20120312215010.29495.80634.idtracker@ietfa.amsl.com><843DA8228A1BA74CA31FB4E111A5C46202447EC8@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 29 Mar 2012 09:50:06.0742 (UTC) FILETIME=[52659360:01CD0D91] Cc: cuss@ietf.org Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.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, 29 Mar 2012 09:50:13 -0000 Hello, Thank you for your answer and your future modifications in next version = of the draft. Regarding the name of the parameter, we do not understand what the issue = is to come back to the previous parameter name "purpose" because this = does not invalidate the concept of package mechanism which is still = valid with this change and, at the same time, this allows to avoid a = backward compatibility issue with draft-johnston-sipping-cc-uui-08 on = which several implementations are based.=20 For that, the definition of the parameter needs to be modified in = section 4 as follows: The "package" parameter identifies the package which defines the = generation and usage of the UUI data for a particular application. =3D=3D> The "purpose" parameter identifies the purpose of the package which = defines the generation and usage of the UUI data for a particular = application. Thank you in advance. Best Regards. Celine serrut-valette Orange Labs -----Message d'origine----- De=A0: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Envoy=E9=A0: mercredi 28 mars 2012 13:16 =C0=A0: SERRUT-VALETTE Celine RD-CORE-ISS Cc=A0: keith.drage@alcatel-lucent.com; cuss@ietf.org Objet=A0: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt Celine, On #1, I'm fine calling out that the multiple UUI data elements can be for the same or different packages. On #2, it was a cut-and-paste error that left the "purpose" parameter. The next version will change this to "package", so we will not be using "purpose" going forward. - Alan - On Mon, Mar 26, 2012 at 8:06 AM, = wrote: > Hello, > > I would have 2 comments (related to my 2 previous comments on the = former version -04) on your updated draft-ietf-cuss-sip-uui-05: > > - 1/ in section 4.1, it's indicated that "Multiple User-to-User header = fields MAY be present in a request or response" but it doesn't clarify = if it could be using the same or different packages. As you proposed = before in your reply, would it be possible to indicate that "Multiple = User-to-User header fields MAY be present in a request or response, = containing uui-data for the same or for different packages"? > > - 2/ in section 4.1, the example "User-to-User: = 56a390f3d2b7310023a;encoding=3Dhex;purpose=3Dfoo;content=3Dbar" contains = the "purpose" parameter in replacement of the "package" parameter. Would = it be possible to extend the use of the "purpose" parameter to the rest = of the document? Indeed, "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. > For that, it will be necessary to change the definition of the = parameter in section 4 as follows: > > The "package" parameter identifies the package which defines the = generation and usage of the UUI data for a particular application. > > =3D=3D> > > The "purpose" parameter identifies the purpose of the package which = defines the generation and usage of the UUI data for a particular = application. > > > Thank you in advance. > Best Regards, > > Celine serrut-valette > Orange Labs > > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de internet-drafts@ietf.org > Envoy=E9=A0: lundi 12 mars 2012 22:50 > =C0=A0: i-d-announce@ietf.org > Cc=A0: cuss@ietf.org > Objet=A0: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Call Control UUI Service = for SIP Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Mechanism for = Transporting User to User Call Control Information in SIP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Rafferty > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: = draft-ietf-cuss-sip-uui-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 There is a class of applications which benefit from using SIP to > =A0 exchange User to User Information (UUI) data during session > =A0 establishment. =A0This information, known as call control UUI = data, is > =A0 a small piece of data inserted by an application initiating the > =A0 session, and utilized by an application accepting the session. = =A0The > =A0 rules which apply for a certain application are defined by a UUI > =A0 package. =A0This UUI data is opaque to SIP and its function is > =A0 unrelated to any basic SIP function. =A0This document defines a = new SIP > =A0 header field, User-to-User, to transport UUI data, along with an > =A0 extension mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.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-05.txt > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss