From internet-drafts@ietf.org Tue Jan 3 11:02: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 1672F5E8032; Tue, 3 Jan 2012 11:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 NZcM8F7-mMOw; Tue, 3 Jan 2012 11:02:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766A85E802D; Tue, 3 Jan 2012 11:02:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103190210.17904.17406.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 11:02:10 -0800 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-09.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, 03 Jan 2012 19:02: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 : Problem Statement and Requirements for Transporting User= to User Call Control Information in SIP Author(s) : Alan Johnston Laura Liess Filename : draft-ietf-cuss-sip-uui-reqs-09.txt Pages : 12 Date : 2012-01-03 This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-09.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-reqs-09.txt From celine.serrutvalette@orange.com Thu Jan 5 09:04: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 7B38521F87DF for ; Thu, 5 Jan 2012 09:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwZsLKE0jkVD for ; Thu, 5 Jan 2012 09:04:14 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8D721F87B9 for ; Thu, 5 Jan 2012 09:04:14 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A22F25D8954 for ; Thu, 5 Jan 2012 18:04:11 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 97CEF5D893A for ; Thu, 5 Jan 2012 18:04:11 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 18:04:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 18:04:10 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021ABDF3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EEA1CF4.4050902@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Expert review of sip-uui-isdn draft underway Thread-Index: Acy7RC2xXFlGIcK9TNa956tuUgl0AgQgQXng References: <4EEA1CF4.4050902@bell-labs.com> From: To: X-OriginalArrivalTime: 05 Jan 2012 17:04:11.0391 (UTC) FILETIME=[0B84A0F0:01CCCBCC] Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:04:15 -0000 Hello and Happy New Year, Please find our comments on draft-ietf-cuss-sip-uui-isdn-01: **Section 3.1** C1: "to control the request and granting of the service, as in USS2 and = UUS3" =3D> just an editorial comment, "USS2" should be replaced by = "UUS2". C2: "Only a single user information package can be transported in each = message" =3D> in order to avoid any misunderstanding, it would be = clearer to indicate that this restriction concerns "isdn-uui" package, = so it would be in-line with section 6 where this precision is given and = with section 5 where another package could be used (enhanced package) in = parallel with "isdn-uui". Otherwise, without this clarification, it = could be understood as no other package is allowed. Proposal: "Only a single user information package set to "isdn-uui" can = be transported in each message". **Section 5** C3: "the endpoint can carry the UUI data both as ISDN and as some other = package in parallel" =3D> it would be suitable to explicitly indicate = that ISDN UUI and other types of UUI using other packages are conveyed = either in the same or in different messages. Proposal: "the endpoint can carry the UUI data both as ISDN UUI and as = other types of UUI defined in other packages, in parallel in the same or = in different messages". **Section 7** C4: "The UAC MUST only use this package of the UUI mechanism extension = in association with the initial INVITE method and the BYE method = relating to an INVITE dialog. Usage on transactions associated with any = other type of dialog, or on methods not associated with a dialog is = precluded." =3D> The first sentence indicates that User-to-User header = can only be conveyed in initial INVITE request, its responses, BYE = request and its responses (which is consistent with the definition of = UUS1) whereas the scope of the second sentence is wider because it means = that other methods within the INVITE-initiated dialog (e.g. UPDATE) can = be used to convey UUI, although only initial INVITE and BYE methods are = allowed. Proposal: "The UAC MUST only use this package [...]. Usage on = transactions associated with any other type of dialog, or on methods not = associated with a dialog, or on methods related to an INVITE dialog but = different from initial INVITE or BYE methods is precluded." C5: "If the UAC wishes to user or permit the sending of UUI data at any = point in the dialog, the UAC MUST include in the INVITE request for that = dialog a User-to-User header field with an "package" header field = parameter set to "isdn-uui". This initial header field constitutes the = implicit request to use the UUI service, and is therefore included even = when there is no data except the protocol discriminator octet to send at = that point in time." =3D> the use of User-to-User header even with no = uui data in INVITE request for implicit request should be a possibility = but not a requirement since the uui option tag has been created for that = purpose and allows as well to declare and negotiate the uui capacity. Proposal: replace "MUST" by "MAY" in the above sentences. C6: "The UAC MUST NOT include the User-to-User header field with an = "package" header field parameter set to "isdn-uui" in any message of an = INVITE dialog if the original INVITE request did not include the = User-to-User header field with an "package" header field parameter set = to "isdn-uui".") =3D> it should be allowed to include a User-to-User = header even if no User-to-User header was present in INVITE request = since the negotiation of the uui capacity can be done by uui option tag = instead. Proposal: replace "MUST" by "MAY" in the above sentence. C7: "Because for the ISDN UUI service, the service is service 1 = implicit, the inclusion of the "uui" option tag in a Supported header = field conveys no additional information over and above the presence of = the User-to-User header field with the "package" header field parameter = to "isdn-uui" in the INVITE request. While there is no harm in including = the "uui" option tag, and strictly it should be included if the = extension is supported, it performs no function" =3D> it should be = possible, in order to declare/negotiate the uui capability, to use the = uui option tag instead of the inclusion of User-to-User header even with = no uui data, at least by indicating both possibilities. Proposal: "While there is no harm in including the "uui" option tag, and = strictly it should be included if the extension is supported, it = performs no function when User-to-User header is included in INVITE = request for implicit request. Otherwise, the uui option tag is used to = indicate that a UA supports and understands the User-to-User header = field." C8: "When sending UUI for the ISDN package, the UAS MUST set the = User-to-User "package" header field parameter to "isdn-uui" and "When = receiving UUI, when a User-to-User header field is received in a request = that is not from the originating user with the "package" header field = parameter to "isdn-uui", the UAC MUST discard this header fields." =3D> = this requires the presence of package parameter (with value set to = "isdn-uui"). In order to be consistent with draft-ietf-cuss-sip-uui-04 = ("If the "package" parameter is not present, interworking with the ISDN = UUI Service MUST be assumed"), it would be necessary to add that when = package parameter is not present, its default value "isdn-uui" must be = assumed. Proposal (in reception): "When receiving UUI, when a User-to-User header = field is received in a request that is not from the originating user = with the "package" header field parameter to "isdn-uui", the UAC MUST = discard this header fields. When receiving UUI, if no package header = field parameter is present, the UAC must assume its default value = "isdn-uui"". Proposal (in emission): "When sending UUI for the ISDN package, if the = UAS includes a User-to-User "package" header field parameter, it MUST = set it to "isdn-uui". C9: As done in Section 8 for UAS, it would be relevant to indicate the = behavior of the UAC when a User-to-User header field is received in a = response that is not with the "package" header field parameter to = "isdn-uui" (discarded?). **Section 8** C4, C6 and C8 comments are also applicable in this section. **Section 13** C10: "This document adds the following row to the "UUI packages" = sub-registry of the SIP parameter registry: Value: isdn-uui" =3D> it = would be suitable to rename the value of package parameter from = "isdn-uui" into "isdn-interwork". The goal would to allow compatibility = with already deployed implementations that are based on the = draft-johnston individual draft (draft referenced since a long time in = 3GPP documents). There would be no change regarding the meaning because = the definitions of "isdn-interwork" and "isdn-uui" values are exactly = the same, for ISDN interworking scenarios ("which is to interoperate = with ISDN User to User Signaling (UUS)"). Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de Vijay K. Gurbani Envoy=E9=A0: jeudi 15 d=E9cembre 2011 17:15 =C0=A0: cuss@ietf.org Objet=A0: [cuss] Expert review of sip-uui-isdn draft underway Folks: Celine Serrutvalette has agreed to perform an expert review of the UUI ISDN draft (thanks, Celine). The expert review is due Jan-10-2012. The token for a second expert review of the SIP mechanism draft is with Martin Dolly. I suspect that once both these expert reviews are in, Enrico and I will ask the editors to modify their respective drafts and proceed to WGLC. Until then, y'all have a nice holiday season. - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Thu Jan 5 09:06:02 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 1982621F87B9 for ; Thu, 5 Jan 2012 09:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvkpzIW2l+bW for ; Thu, 5 Jan 2012 09:06:00 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B370E21F875F for ; Thu, 5 Jan 2012 09:05:59 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 980D3A441AE for ; Thu, 5 Jan 2012 18:07:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 89A50A441AD for ; Thu, 5 Jan 2012 18:07:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 18:05: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_01CCCBCC.4B3F4081" Date: Thu, 5 Jan 2012 18:05:57 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021ABDF4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 Thread-Index: Acy2gfZXLh2YFRFdRFyeuzOb5HWbtQDFlVmABItflfA= References: <9762ACF04FA26B4388476841256BDE020115A56F577B@HE111543.emea1.cds.t-internal.com> From: To: X-OriginalArrivalTime: 05 Jan 2012 17:05:58.0674 (UTC) FILETIME=[4B76B720:01CCCBCC] Subject: Re: [cuss] "package" vs "purpose" name in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:06:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCBCC.4B3F4081 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Please find an additional comment on draft-ietf-cuss-sip-uui-04, I hope = it would not too late:=20 =20 We would like to raise that it seems to us that it is not clear enough = that multiple User-to-User headers set to different package values are = allowed in the same message. There is a precision on how many = User-to-User headers can be present for a given package ("The rules for = how many User-to-User header field of each package may be present in a = request or a response are defined for each package be present in a = request or a response are defined for each package." in section 4.1), = but no precision on the possibility to have in parallel multiple = User-to-User headers set to different package values. Would it be = possible to give this possibility in the draft in a general way? =20 Regards, =20 Celine Serrut-Valette Orange Labs =20 =20 De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de = Martin.Huelsemann@telekom.de Envoy=E9 : mardi 13 d=E9cembre 2011 14:58 =C0 : MARJOU Xavier RD-CORE-LAN; cuss@ietf.org Objet : Re: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 =20 Hi all, =20 for sure a package is used for a certain purpose. So I agree with = Xavier, for the solution itself it doesn't matter if the parameter name = is 'package' or 'purpose', however the name 'purpose' would provide a = certain degree of backward compatibility. =20 Regards, Martin =20 =20 =20 =20 =09 ________________________________ Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag = von Xavier Marjou Gesendet: Freitag, 9. Dezember 2011 15:50 An: cuss@ietf.org Betreff: [cuss] "package" vs "purpose" name in = draft-ietf-cuss-sip-uui-04 Hi, =20 Regarding draft-ietf-cuss-sip-uui-04, one modification I would like is = to rename the "package" parameter name into "purpose" which existed = until draft-ietf-cuss-sip-uui-00. The goal would to allow compatibility = with already deployed implementations that are based on the = draft-johnston individual draft (draft referenced since a long time in = 3GPP documents). There would be no change regarding the semantics: the = goal of the defined parameter is to indicate the purpose of the = application usage of UUI data and this can be fulfilled by a parameter = called "purpose", in order to indicate how and why UUI data is used. =20 Cheers, Xavier ------_=_NextPart_001_01CCCBCC.4B3F4081 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

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

 

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

 

Regards,

 

Celine = Serrut-Valette

Orange = Labs

 

 

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

 

Hi= all,

 

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

 

Re= gards, Martin

 

 

 

 

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

H= i,

 

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

 

Cheers,=

Xavier<= /o:p>

------_=_NextPart_001_01CCCBCC.4B3F4081-- From md3135@att.com Tue Jan 10 07:32: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 8D13221F8613 for ; Tue, 10 Jan 2012 07:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImgC+ZcPAj7U for ; Tue, 10 Jan 2012 07:32:28 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id DEBBE21F860E for ; Tue, 10 Jan 2012 07:32:27 -0800 (PST) X-Env-Sender: md3135@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1326209547!9808109!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1090 invoked from network); 10 Jan 2012 15:32:27 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jan 2012 15:32:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0AFWs1m003693; Tue, 10 Jan 2012 10:32:56 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0AFWnWQ003343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 10:32:49 -0500 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 10 Jan 2012 10:32:08 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0339.001; Tue, 10 Jan 2012 10:32:07 -0500 From: "DOLLY, MARTIN C" To: "cuss@ietf.org" Thread-Topic: [cuss] Review of draft-ietf-cuss-sip-uui Thread-Index: AQHMrnW6wiL6Ha3jW0aClQVuxEeTXJYF/CLA Date: Tue, 10 Jan 2012 15:32:07 +0000 Message-ID: References: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> In-Reply-To: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.43.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [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: Tue, 10 Jan 2012 15:32:28 -0000 Greetings, I was asked by chairs of this WG to review=20 draft-ietf-cuss-sip-uui.=20 Below are my comments, build on Shida's comments posted on 11/29/2011 The concept of "escaping" needs to be added to Section 4 Normative Definiti= on, and an illustrative example would be helpful. 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 explicit= ly stating that should be added to the overview. Complex call center communications can have multiple (3-4) redirections/ref= errals, so a multiple redirection/referral example would be helpful. Is it possible to have multiple UUI headers, either with the same data cont= ent encoded differently or with different data content? What is an intermediary, if it is not a proxy? Terminology: the document has UUIs being communicated between UACs and UASs= and between endpoints, which is it? Considering the same data content could be encoded differently, does this r= esult in multiple UUI packages? And if so, could they be defined in the sam= e RFC? Regards, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 From vkg@bell-labs.com Fri Jan 13 12:34:33 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 E50B621F8566 for ; Fri, 13 Jan 2012 12:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 UfhBJHZSACdr for ; Fri, 13 Jan 2012 12:34:33 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 563B521F8574 for ; Fri, 13 Jan 2012 12:34:32 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0DKYVVl002890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jan 2012 14:34:31 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0DKYUfE000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jan 2012 14:34:31 -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 q0DKYSbu024084; Fri, 13 Jan 2012 14:34:28 -0600 (CST) Message-ID: <4F10963F.3030801@bell-labs.com> Date: Fri, 13 Jan 2012 14:38:23 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Johnston , "Drage, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: cuss@ietf.org Subject: [cuss] Moving pending drafts ahead 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, 13 Jan 2012 20:34:34 -0000 Keith, Alan: The expert review for the two remaining drafts has now been completed, thanks to Celine, Martin and Shida. Celine reviewed draft-ietf-cuss-sip-uui-04; her review is at [1,2]. Shida and Martin reviewed draft-ietf-cuss-sip-uui, both from the SIP perspective and from adherence to H-I. Shida's review is at [3] and Martin's is at [4]. Enrico and I would urge you to kindly respond to the comments during expert review and issue updates to the draft addressing these comments. We will subsequently like to call for a WGLC on the revision. Can you please let the WG know if you are able to issue a revision by Feb-15-2012? That will give the WG enough time to discuss the revision and call for WGLC. If there are any contentious issues and WGLC cannot be a state we can contemplate, then we should think of holding an virtual interim meeting, or try to solve the issue during face-to-face time in Paris. It'll be nice to know by middle of February where the WG stands on moving the drafts ahead. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00325.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00326.html [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00317.html [4] http://www.ietf.org/mail-archive/web/cuss/current/msg00327.html Thank you, Vijay K. Gurbani and Enrico Marocco From iesg-secretary@ietf.org Tue Jan 17 08:02: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 B166C21F8621; Tue, 17 Jan 2012 08:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 srLwqdW6heSi; Tue, 17 Jan 2012 08:02:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6121F868C; Tue, 17 Jan 2012 08:02:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120117160212.23033.63795.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 08:02:12 -0800 Cc: cuss mailing list , cuss chair , RFC Editor Subject: [cuss] Document Action: 'Problem Statement and Requirements for Transporting User to User Call Control Information in SIP' to Informational RFC (draft-ietf-cuss-sip-uui-reqs-09.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, 17 Jan 2012 16:02:12 -0000 The IESG has approved the following document: - 'Problem Statement and Requirements for Transporting User to User Call Control Information in SIP' (draft-ietf-cuss-sip-uui-reqs-09.txt) as an Informational RFC This document is the product of the Call Control UUI Service for SIP Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/ Technical Summary This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. Working Group Summary The working group consensus on this document is solid. Two WGLCs were held to ensure that all comments and feedback were accounted for. Document Quality This is a requirement document, as such there aren't any implementation details to list. That said, the document has received a positive nod from major service provider and equipment vendors. Personnel Vijay Gurbani is the document's shepherd. Gonzalo Camarillo is the responsible AD. From thomas.belling@nsn.com Thu Jan 19 09:25:53 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 1B5EE21F86C5 for ; Thu, 19 Jan 2012 09:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 k7RZGub8miNf for ; Thu, 19 Jan 2012 09:25: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 12C6B21F86B0 for ; Thu, 19 Jan 2012 09:25:50 -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 q0JHPneI017278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Jan 2012 18:25:49 +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 q0JHPnWk001628 for ; Thu, 19 Jan 2012 18:25:49 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 18:25: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2012 18:25:46 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Definition of hex encoding in draft-ietf-cuss-sip-uui-04 Thread-Index: AczWz1Io/t2CiFM0Sby3gzrMZq+lEQ== From: "Belling, Thomas (NSN - DE/Munich)" To: X-OriginalArrivalTime: 19 Jan 2012 17:25:49.0211 (UTC) FILETIME=[62DCBEB0:01CCD6CF] Subject: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:25:53 -0000 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.=A0 Guidelines for UUI Packages ... =A0=A0 This specification defines only the value of "hex" for the = "encoding" =A0=A0 parameter.=A0 Hex encoding, as used for UUI data is defined to = use only =A0=A0 the characters 0-9, A-F, or a-f.=A0 Hex encoded UUI data must = have an =A0=A0 even number of octets, and is considered invalid if has an odd =A0=A0 number.=A0 Hex encoding is normally done as a token, although = quoted- =A0=A0 string is permitted, in which case the quotes are ignored.=A0 Hex =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 the =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" 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. 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. 4. Lack of normative language ("MUST") 5. Allowing minor characters: In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old = versions of the predecessor draft-johnston and provide our own = definition of hex encoding (in the lack of any definition within the = draft). This 3GPP/TISPAN definition seems to be largely aligned, but = allows only major characters. This has been in those specs already for = some years and might be implemented; operators raised such concerns when = we discussed updating our references. It would make life simpler for us = if you also only allow major characters. Besides, implementations would = become slightly simpler. 6. Allowing "quoted-string" encoding. Earlier versions of predecessor draft-johnston that might be in the = field (see above) allowed only "token". Again, it would improve backward = compatibility and slightly simplify implementations if only "token" is = allowed for "hex" encoding. (It is fine to keep "quoted-string" for = other encodings.) 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. 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 and A-F), each representing four bits within the octet. The four most significant bits MUST be mapped to the first hexadecimal digit and the four least significant bits MUST be mapped to the second hexadecimal digit. Thus, Hex encoded UUI data must have an even = number of hexadecimal digits, and MUST be considered invalid if has an odd number. For "hex" encoding, "uui-data" MUST be encoded as "token". BR, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation=20 Nokia Siemens Networks From thomas.belling@nsn.com Thu Jan 19 09:52:56 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8EF21F861A for ; Thu, 19 Jan 2012 09:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 Pi2jD02Y2o6K for ; Thu, 19 Jan 2012 09:52:55 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9C821F8608 for ; Thu, 19 Jan 2012 09:52:42 -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 q0JHqf4U026276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Jan 2012 18:52:41 +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 q0JHqf0A026986 for ; Thu, 19 Jan 2012 18:52:41 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 18:52:41 +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_01CCD6D3.23B5E1CF" Date: Thu, 19 Jan 2012 18:52:40 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Assuming "package=isdn-uui" as default if package parameter is omitted? Thread-Index: AczW0vUJXupG30tMRVer0S6gk1JBPQ== From: "Belling, Thomas (NSN - DE/Munich)" To: X-OriginalArrivalTime: 19 Jan 2012 17:52:41.0387 (UTC) FILETIME=[23CB47B0:01CCD6D3] Subject: [cuss] Assuming "package=isdn-uui" as default if package parameter is omitted? 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, 19 Jan 2012 17:52:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD6D3.23B5E1CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions (-02 and -03) of the predecessor draft-johnston. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references in 3GPP.=20 The "package" parameter of the "User-to-User" SIP header was not yet defined in those versions.=20 A User-to-User header sent by interworking entities complaint with current version ETSI TISPAN TS 183 036 and 3GPP TS 29.163 would only contain the "encoding=3Dhex" parameter, but no "package=3Disdn-uui". Contents of "uui-data" would be aligned with what is now defined for "package=3Disdn-uui". It would thus greatly enhance backward compatibility, if draft-ietf-cuss-sip-uui-04 could be updated to state that "package=3Disdn-uui" is the default to be assumed if package parameter = is omitted in the "User-to-User" SIP header. (draft-ietf-cuss-sip-uui might also require some related updates.) BR, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation=20 Nokia Siemens Networks =20 ------_=_NextPart_001_01CCD6D3.23B5E1CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Assuming "package=3Disdn-uui" as default if package = parameter is omitted?

In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base = currently on old versions (-02 and -03) of the predecessor draft-johnston. This has been in those specs already for some years = and might be implemented; operators raised such concerns when we = discussed updating our references in 3GPP.

The “package” parameter of = the “User-to-User” SIP header was not yet defined in those versions.

A User-to-User = header = sent by interworking entities complaint = with current version ETSI TISPAN TS 183 036 and 3GPP = TS 29.163 = would only contain the “encoding=3Dhex” parameter, but no = "package=3Disdn-uui". Contents of “uui-data” would be aligned with what is now defined for "package=3Disdn-uui".

It = would thus greatly enhance backward = compatibility, if draft-ietf-cuss-sip-uui-04 could be updated to state = that "package=3Disdn-uui" is the default = to be = assumed if = package parameter is omitted in the “User-to-User” SIP header.

(draft-ietf-cuss-sip-uui might also require some related = updates.)


BR, Thomas

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

------_=_NextPart_001_01CCD6D3.23B5E1CF-- From alan.b.johnston@gmail.com Thu Jan 19 10:13:55 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FBE21F85EF for ; Thu, 19 Jan 2012 10:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 5j+duevvoC6z for ; Thu, 19 Jan 2012 10:13:54 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4CF21F85CE for ; Thu, 19 Jan 2012 10:13:54 -0800 (PST) Received: by obbwc12 with SMTP id wc12so248450obb.31 for ; Thu, 19 Jan 2012 10:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iC9rA315V2fC5CE9TE4X9nVbzLyq9mKmGyp6iB3Dosc=; b=okM8a+2wQS0w1jTttQg1D4DLlf7CFGgWJ3Z4uAx71Pni4Iubbm4SMI2nrQHL1uLvL/ Ekj1sGi0t3ftBLU2/0WYqoFZHrPgb0JRF6qgAXTKMVAafDQHFZcR6XdUTyJF+RpctpLy ddtjq9jWtzzfE3dDhorf0veXE2eVYd1LK4g70= MIME-Version: 1.0 Received: by 10.182.150.66 with SMTP id ug2mr23827308obb.68.1326996830825; Thu, 19 Jan 2012 10:13:50 -0800 (PST) Received: by 10.182.75.136 with HTTP; Thu, 19 Jan 2012 10:13:50 -0800 (PST) In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> Date: Thu, 19 Jan 2012 12:13:50 -0600 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] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 18:13:55 -0000 Thomas, Thank you for the detailed feedback. We definitely want to get the definition of hex encoding correct, and have it be very clear. I'm working on an update to the draft now. I'll post the edited text on hex encoding on the list before I submit. In the meantime, perhaps some others want to comment on your proposal. - Alan - On Thu, Jan 19, 2012 at 11:25 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear all > > Checking draft-ietf-cuss-sip-uui-04, I found that the definition of hex e= ncoding could be improved: > > What came closest to a definition of the encoding was the following: > > " > 5.=A0 Guidelines for UUI Packages > ... > =A0=A0 This specification defines only the value of "hex" for the "encodi= ng" > =A0=A0 parameter.=A0 Hex encoding, as used for UUI data is defined to use= only > =A0=A0 the characters 0-9, A-F, or a-f.=A0 Hex encoded UUI data must have= an > =A0=A0 even number of octets, and is considered invalid if has an odd > =A0=A0 number.=A0 Hex encoding is normally done as a token, although quot= ed- > =A0=A0 string is permitted, in which case the quotes are ignored.=A0 Hex > =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 the > =A0=A0 high order four bits of the octet and the second digit providing t= he > =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 d= efinition" > > > 2. "Hex encoding yields a sequence of octets, one octet per two hex digit= s" > 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 hexadecima= l digits for each octet of binary data.". Hexadecimal digits seem to be cal= led "octets" throughout the text, which is highly confusing. > > > 3. "Hex encoded UUI data must have an even number of octets, and is consi= dered invalid if has an odd number." This is a similar problem, and the tex= t is quite ambiguous: Does "octet" refer to the binary data to be encoded o= r the result of the encoding? The text only makes sense if "octet" is under= stood as the result of encoding. Speaking about "characters" or "hexadecima= l digits" rather than "octets" would remove this ambiguity. > > > 4. Lack of normative language ("MUST") > > > 5. Allowing minor characters: > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old ve= rsions of the predecessor draft-johnston and provide our own definition of = hex encoding (in the lack of any definition within the draft). This 3GPP/TI= SPAN definition seems to be largely aligned, but allows only major characte= rs. This has been in those specs already for some years and might be implem= ented; operators raised such concerns when we discussed updating our refere= nces. It would make life simpler for us if you also only allow major charac= ters. Besides, implementations would become slightly simpler. > > > 6. Allowing "quoted-string" encoding. > Earlier versions of predecessor draft-johnston that might be in the field= (see above) allowed only "token". Again, it would improve backward compati= bility and slightly simplify implementations if only "token" is allowed for= "hex" encoding. (It is fine to keep "quoted-string" for other encodings.) > > > > To sum up, a text proposal: > > 4.x Hex encoding definition > =A0 This specification defines only the value of "hex" for the "encoding" > =A0 parameter. =A0It is used to encode binary UUI data. > =A0 Each octet of binary data to be represented in the hex encoding MUST > =A0 be mapped to two hexadecimal digits (represented by ASCII characters > =A0 0-9 and A-F), each representing four bits within the octet. The four > =A0 most significant bits MUST be mapped to the first hexadecimal digit > =A0 and the four least significant bits MUST be mapped to the second > =A0 hexadecimal digit. Thus, Hex encoded UUI data must have an even numbe= r > =A0 of hexadecimal digits, and MUST be considered invalid if has an odd > =A0 number. For "hex" encoding, "uui-data" MUST be encoded as "token". > > > > BR, Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Thu Jan 19 11:49:19 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 93F6621F85AC for ; Thu, 19 Jan 2012 11:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 kEfc-gojjILM for ; Thu, 19 Jan 2012 11:49:19 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0153921F8559 for ; Thu, 19 Jan 2012 11:49:18 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id PPTH1i0051ei1Bg54XpKqB; Thu, 19 Jan 2012 19:49:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id PXpK1i00407duvL3kXpKQA; Thu, 19 Jan 2012 19:49:19 +0000 Message-ID: <4F1873BD.1020302@alum.mit.edu> Date: Thu, 19 Jan 2012 14:49:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cuss@ietf.org References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [cuss] Assuming "package=isdn-uui" as default if package parameter is omitted? 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, 19 Jan 2012 19:49:19 -0000 I am ok with making this the default. Thanks, Paul On 1/19/12 12:52 PM, Belling, Thomas (NSN - DE/Munich) wrote: > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old > versions(-02 and -03)of the predecessor draft-johnston. This has been in > those specs already for some years and might be implemented; operators > raised such concerns when we discussed updating our referencesin 3GPP. > > The“package”parameter of the“User-to-User”SIP headerwas not yet defined > in those versions. > > A User-to-User header sentbyinterworking entities complaint with current > versionETSI TISPAN TS 183 036 and 3GPP TS 29.163would only contain > the“encoding=hex”parameter, but > no"package=isdn-uui".Contentsof“uui-data”would bealignedwithwhat is now > defined for"package=isdn-uui". > > It wouldthusgreatly enhance backward > compatibility,ifdraft-ietf-cuss-sip-uui-04could be updated to state > that"package=isdn-uui"is the defaultto be assumedif package parameter is > omittedin the“User-to-User”SIP header. > > (draft-ietf-cuss-sip-uui might also require some related updates.) > > > BR, Thomas > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Thu Jan 19 12:12:03 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A576921F86C9 for ; Thu, 19 Jan 2012 12:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed86pihJhxGN for ; Thu, 19 Jan 2012 12:12:03 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id B47F421F86B4 for ; Thu, 19 Jan 2012 12:12:02 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PWh31i0041YDfWL5BYC2tS; Thu, 19 Jan 2012 20:12:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id PYC21i00W07duvL3gYC2zM; Thu, 19 Jan 2012 20:12:02 +0000 Message-ID: <4F18790F.5090508@alum.mit.edu> Date: Thu, 19 Jan 2012 15:11:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cuss@ietf.org References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 20:12:03 -0000 On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: > 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") > > > 5. Allowing minor characters: My "minor characters" do you mean "lower case" characters? > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. I just find this distinctly unfriendly. Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do? (As an implementer I would always support both cases even if the spec didn't require it - unless I was writing a conformance test.) > 6. Allowing "quoted-string" encoding. > Earlier versions of predecessor draft-johnston that might be in the field (see above) allowed only "token". Again, it would improve backward compatibility and slightly simplify implementations if only "token" is allowed for "hex" encoding. (It is fine to keep "quoted-string" for other encodings.) I would rather not see this change made. But I won't fight if it is. Thanks, Paul > 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. > 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 and A-F), each representing four bits within the octet. The four > most significant bits MUST be mapped to the first hexadecimal digit > and the four least significant bits MUST be mapped to the second > hexadecimal digit. Thus, Hex encoded UUI data must have an even number > of hexadecimal digits, and MUST be considered invalid if has an odd > number. For "hex" encoding, "uui-data" MUST be encoded as "token". > > > > BR, Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From thomas.belling@nsn.com Fri Jan 20 01:35: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 8DC8E21F85F6 for ; Fri, 20 Jan 2012 01:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IncxkVUWCeZb for ; Fri, 20 Jan 2012 01:35:55 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E532221F85DB for ; Fri, 20 Jan 2012 01:35:54 -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 q0K9ZiLT021735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 10:35:44 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0K9Zges017400; Fri, 20 Jan 2012 10:35:44 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 10:35:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2012 10:35:37 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F18790F.5090508@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 Thread-Index: AczW5p5SwImbwnyoRgi2OfCxXXRM+QAbPpGA References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> <4F18790F.5090508@alum.mit.edu> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" , X-OriginalArrivalTime: 20 Jan 2012 09:35:38.0531 (UTC) FILETIME=[DE665730:01CCD756] Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 09:35:59 -0000 Thanks, Paul Replies are below. >> 5. Allowing minor characters: > By "minor characters" do you mean "lower case" characters? Yes >> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. > I just find this distinctly unfriendly. > Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do? > (As an implementer I would always support both cases even if the spec didn't require it - unless I was writing a conformance test.) I believe this is a real problem: In 3GPP a couple of operators raised general concerns about backward compatibility, and CRs to update references to the latest version of the drafts had to be postponed for this reason. This is why I believe something might already be rolled out or be very close to be rolled out. The issue of only "upper case" characters was not yet specifically discussed, though. But from 3GPP and TISPAN specs it is currently absolutely clear that only upper case is allowed. I agree with your robust implementation principle that a receiver should be tolerant. Unfortunately we cannot be sure that this is true with respect to "lower case" characters for rolled out receivers. (And the other half of the robust implementation principle is that the sender should accurately follow the standards. This is what I was aiming at.) >> 6. Allowing "quoted-string" encoding. >> Earlier versions of predecessor draft-johnston that might be in the=20 >> field (see above) allowed only "token". Again, it would improve=20 >> backward compatibility and slightly simplify implementations if only=20 >> "token" is allowed for "hex" encoding. (It is fine to keep=20 >> "quoted-string" for other encodings.) > I would rather not see this change made. > But I won't fight if it is. This is a very similar issue. Without backward compatibility considerations, I would also be fine with allowing both.=20 Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: Thursday, January 19, 2012 9:12 PM To: cuss@ietf.org Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: > 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") > > > 5. Allowing minor characters: My "minor characters" do you mean "lower case" characters? > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. I just find this distinctly unfriendly. Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do? (As an implementer I would always support both cases even if the spec didn't require it - unless I was writing a conformance test.) > 6. Allowing "quoted-string" encoding. > Earlier versions of predecessor draft-johnston that might be in the=20 > field (see above) allowed only "token". Again, it would improve=20 > backward compatibility and slightly simplify implementations if only=20 > "token" is allowed for "hex" encoding. (It is fine to keep=20 > "quoted-string" for other encodings.) I would rather not see this change made. But I won't fight if it is. Thanks, Paul > 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. > 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 and A-F), each representing four bits within the octet. The four > most significant bits MUST be mapped to the first hexadecimal digit > and the four least significant bits MUST be mapped to the second > hexadecimal digit. Thus, Hex encoded UUI data must have an even number > of hexadecimal digits, and MUST be considered invalid if has an odd > number. For "hex" encoding, "uui-data" MUST be encoded as "token". > > > > BR, Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > _______________________________________________ > 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 jan.van.geel@belgacom.be Fri Jan 20 04:44: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 986C521F8588 for ; Fri, 20 Jan 2012 04:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHkSuh8HZQn6 for ; Fri, 20 Jan 2012 04:44:05 -0800 (PST) Received: from mx14.belgacom.be (mx14.belgacom.be [195.13.15.234]) by ietfa.amsl.com (Postfix) with ESMTP id C9C5721F8587 for ; Fri, 20 Jan 2012 04:44:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="33484043" Received: from unknown (HELO A03008.BGC.NET) ([10.121.129.162]) by mx14.belgacom.be with ESMTP; 20 Jan 2012 13:44:02 +0100 X-TM-IMSS-Message-ID: <08f3962d0001d50f@belgacom.be> Received: from A04028.BGC.NET ([10.121.135.25]) by belgacom.be ([10.121.129.162]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 08f3962d0001d50f ; Fri, 20 Jan 2012 13:44:01 +0100 Received: from AE7211.BGC.NET (45.223.1.30) by A04028.BGC.NET (10.121.135.25) with Microsoft SMTP Server (TLS) id 14.1.323.0; Fri, 20 Jan 2012 13:44:00 +0100 Received: from CMS03.BGC.NET ([169.254.1.96]) by AE7211.BGC.NET ([45.223.1.30]) with mapi; Fri, 20 Jan 2012 13:44:00 +0100 From: "VAN GEEL Jan (SDV/PSE)" To: ext Paul Kyzivat , "cuss@ietf.org" Date: Fri, 20 Jan 2012 13:44:00 +0100 Thread-Topic: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 Thread-Index: AczW5p5SwImbwnyoRgi2OfCxXXRM+QAbPpGAAAbw6sA= Message-ID: <208EAE1DFA28FC419529619ABB8622441BC00D79B6@CMS03.BGC.NET> References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net><4F18790F.5090508@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 12:44:06 -0000 Paul, Maybe to help understanding my concern: At present we implemented the following encoding (as described in ETSI TISP= AN TS 183 036) in a media gateway controller (interworking gateway between = IMS and legacy ISDN): The format of the uuidata field shall be the hexadecimal representa= tion of binary data coded in ascii alphanumeric characters. For example, the 8- bit binary value 0011- 1111 is 3F i= n hexadecimal. To code this in ascii, one 8- bit byte containing the ascii code for the character '3' (0011- 0011 or= 033H) and one 8- bit byte containing the ascii code for the character 'F' (0100- 0110 or 046H) are required. For e= ach byte value, the high-order hexadecimal digit is always the first digit of the pair of hexadecimal digits. The as= cii letters used for the hex digits shall always be capital form. My understanding is that the latest draft-ietf-cuss-sip-uui-04 specifies th= e encoding slightly different and also allows lower case. In fact during our testing we experienced that an ISDN converter implemente= d the encoding slightly different and the result is that the UUS doesn't interwork with legacy ISDN. If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state by 3G= PP and ETSI any MGCF or ISDN gateway implementing this version will be inco= mpatible with our existing implementation. Unfortunately not all implementers have your attitude of implementing of bu= ilding robust implementations coping with unrequired stuff. In order to hel= p them building interoperable and compatible products some backward compati= bility should be ensured. Therefore I would propose to include the text with the encoding example abo= ve in the draft so that it is very clear how it should be done. Kind regards Jan Van Geel IT and Network Specialist Belgacom SDE/SDV/PSE/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Bel= ling, Thomas (NSN - DE/Munich) Sent: 20 January 2012 10:36 To: ext Paul Kyzivat; cuss@ietf.org Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-0= 4 Thanks, Paul Replies are below. >> 5. Allowing minor characters: > By "minor characters" do you mean "lower case" characters? Yes >> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definiti= on of hex encoding (in the lack of any definition within the draft). This 3= GPP/TISPAN definition seems to be largely aligned, but allows only major ch= aracters. This has been in those specs already for some years and might be = implemented; operators raised such concerns when we discussed updating our = references. It would make life simpler for us if you also only allow major = characters. Besides, implementations would become slightly simpler. > I just find this distinctly unfriendly. > Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do? > (As an implementer I would always support both cases even if the spec didn't require it - unless I was writing a conformance test.) I believe this is a real problem: In 3GPP a couple of operators raised general concerns about backward compat= ibility, and CRs to update references to the latest version of the drafts h= ad to be postponed for this reason. This is why I believe something might a= lready be rolled out or be very close to be rolled out. The issue of only "upper case" characters was not yet specifically discusse= d, though. But from 3GPP and TISPAN specs it is currently absolutely clear = that only upper case is allowed. I agree with your robust implementation principle that a receiver should be= tolerant. Unfortunately we cannot be sure that this is true with respect t= o "lower case" characters for rolled out receivers. (And the other half of = the robust implementation principle is that the sender should accurately fo= llow the standards. This is what I was aiming at.) >> 6. Allowing "quoted-string" encoding. >> Earlier versions of predecessor draft-johnston that might be in the >> field (see above) allowed only "token". Again, it would improve >> backward compatibility and slightly simplify implementations if only >> "token" is allowed for "hex" encoding. (It is fine to keep >> "quoted-string" for other encodings.) > I would rather not see this change made. > But I won't fight if it is. This is a very similar issue. Without backward compatibility considerations= , I would also be fine with allowing both. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext= Paul Kyzivat Sent: Thursday, January 19, 2012 9:12 PM To: cuss@ietf.org Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: > 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 encodin= g 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 hexadec= imal 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 th= e text is quite ambiguous: Does "octet" refer to the binary data to be enco= ded or the result of the encoding? The text only makes sense if "octet" is = understood as the result of encoding. Speaking about "characters" or "hexad= ecimal digits" rather than "octets" would remove this ambiguity. I agree. > 4. Lack of normative language ("MUST") > > > 5. Allowing minor characters: My "minor characters" do you mean "lower case" characters? > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definition o= f hex encoding (in the lack of any definition within the draft). This 3GPP/= TISPAN definition seems to be largely aligned, but allows only major charac= ters. This has been in those specs already for some years and might be impl= emented; operators raised such concerns when we discussed updating our refe= rences. It would make life simpler for us if you also only allow major char= acters. Besides, implementations would become slightly simpler. I just find this distinctly unfriendly. Is this a real problem, or a theoretical one? What do the existing implemen= tations of the above specs actually do? (As an implementer I would always support both cases even if the spec didn'= t require it - unless I was writing a conformance test.) > 6. Allowing "quoted-string" encoding. > Earlier versions of predecessor draft-johnston that might be in the > field (see above) allowed only "token". Again, it would improve > backward compatibility and slightly simplify implementations if only > "token" is allowed for "hex" encoding. (It is fine to keep > "quoted-string" for other encodings.) I would rather not see this change made. But I won't fight if it is. Thanks, Paul > 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. > 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 and A-F), each representing four bits within the octet. The four > most significant bits MUST be mapped to the first hexadecimal digit > and the four least significant bits MUST be mapped to the second > hexadecimal digit. Thus, Hex encoded UUI data must have an even number > of hexadecimal digits, and MUST be considered invalid if has an odd > number. For "hex" encoding, "uui-data" MUST be encoded as "token". > > > > BR, Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > _______________________________________________ > 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 ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer/ From pkyzivat@alum.mit.edu Fri Jan 20 08:12:33 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 5D84D21F8648 for ; Fri, 20 Jan 2012 08:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwofWADZmYwf for ; Fri, 20 Jan 2012 08:12:32 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id D018421F851C for ; Fri, 20 Jan 2012 08:12:31 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id PsCY1i0040SCNGk5DsCYUq; Fri, 20 Jan 2012 16:12:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id PsCX1i00607duvL3VsCX1H; Fri, 20 Jan 2012 16:12:32 +0000 Message-ID: <4F199277.5000303@alum.mit.edu> Date: Fri, 20 Jan 2012 11:12:39 -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: "VAN GEEL Jan (SDV/PSE)" References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net><4F18790F.5090508@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> <208EAE1DFA28FC419529619ABB8622441BC00D79B6@CMS03.BGC.NET> In-Reply-To: <208EAE1DFA28FC419529619ABB8622441BC00D79B6@CMS03.BGC.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cuss@ietf.org" Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 16:12:33 -0000 On 1/20/12 7:44 AM, VAN GEEL Jan (SDV/PSE) wrote: > Paul, > > Maybe to help understanding my concern: > > At present we implemented the following encoding (as described in ETSI TISPAN TS 183 036) in a media gateway controller (interworking gateway between IMS and legacy ISDN): Anybody who implements a *draft* before it becomes an RFC should be aware that things can change before it becomes an RFC. If we felt we couldn't change a draft once somebody has implemented it we would never get anything right. It is painful to be on the bleeding edge, but that is the way it is. In this case, IIRC, the draft never specified defined the hex encoding at all, until the current definition was added. If ETSI TISPAN decided to define the encoding, it could have at least proposed it as a change to the draft - *before* implementing it. That would have provoked a discussion and probably confronted this issue at that time. > The format of the uuidata field shall be the hexadecimal representation of binary data coded in ascii alphanumeric > characters. For example, the 8- bit binary value 0011- 1111 is 3F in hexadecimal. To code this in ascii, one 8- bit > byte containing the ascii code for the character '3' (0011- 0011 or 033H) and one 8- bit byte containing the ascii > code for the character 'F' (0100- 0110 or 046H) are required. For each byte value, the high-order hexadecimal digit > is always the first digit of the pair of hexadecimal digits. The ascii letters used for the hex digits shall always be > capital form. > > My understanding is that the latest draft-ietf-cuss-sip-uui-04 specifies the encoding slightly different and also allows lower case. > In fact during our testing we experienced that an ISDN converter implemented the encoding slightly different and the result is that the > UUS doesn't interwork with legacy ISDN. > > If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state by 3GPP and ETSI any MGCF or ISDN gateway implementing this version will be incompatible with our existing implementation. > > Unfortunately not all implementers have your attitude of implementing of building robust implementations coping with unrequired stuff. In order to help them building interoperable and compatible products some backward compatibility should be ensured. The Postel maxim is often mentioned in ietf: be conservative in what you do, be liberal in what you accept from others. I agree with this in principle, even though in practice it isn't as helpful as one might like. (It only works to the extent that everyone agrees on what the liberal interpretation is.) But in this case I don't think there is a lot of controversy over what the liberal interpretation might be. So tell me - what will a liberal implementer do when decoding the value "3f"? Will it reject the entire message? (I find that hard to believe.) Will it treat the "f" as something other than 1111? (what?) Will it ignore the "f"? (Maybe, but that would be stupid.) > Therefore I would propose to include the text with the encoding example above in the draft so that it is very clear how it should be done. I am fine with examples. Thanks, Paul > Kind regards > > Jan Van Geel > IT and Network Specialist > Belgacom SDE/SDV/PSE/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be > > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Belling, Thomas (NSN - DE/Munich) > Sent: 20 January 2012 10:36 > To: ext Paul Kyzivat; cuss@ietf.org > Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 > > Thanks, Paul > > Replies are below. > >>> 5. Allowing minor characters: > >> By "minor characters" do you mean "lower case" characters? > > Yes > >>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on > old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. > >> I just find this distinctly unfriendly. >> Is this a real problem, or a theoretical one? What do the existing > implementations of the above specs actually do? >> (As an implementer I would always support both cases even if the spec > didn't require it - unless I was writing a conformance test.) > > I believe this is a real problem: > In 3GPP a couple of operators raised general concerns about backward compatibility, and CRs to update references to the latest version of the drafts had to be postponed for this reason. This is why I believe something might already be rolled out or be very close to be rolled out. > The issue of only "upper case" characters was not yet specifically discussed, though. But from 3GPP and TISPAN specs it is currently absolutely clear that only upper case is allowed. > > I agree with your robust implementation principle that a receiver should be tolerant. Unfortunately we cannot be sure that this is true with respect to "lower case" characters for rolled out receivers. (And the other half of the robust implementation principle is that the sender should accurately follow the standards. This is what I was aiming at.) > > >>> 6. Allowing "quoted-string" encoding. >>> Earlier versions of predecessor draft-johnston that might be in the >>> field (see above) allowed only "token". Again, it would improve >>> backward compatibility and slightly simplify implementations if only >>> "token" is allowed for "hex" encoding. (It is fine to keep >>> "quoted-string" for other encodings.) > >> I would rather not see this change made. >> But I won't fight if it is. > > This is a very similar issue. Without backward compatibility considerations, I would also be fine with allowing both. > > > Thomas > > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext Paul Kyzivat > Sent: Thursday, January 19, 2012 9:12 PM > To: cuss@ietf.org > Subject: Re: [cuss] Definition of hex encoding in > draft-ietf-cuss-sip-uui-04 > > On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: >> 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") >> >> >> 5. Allowing minor characters: > > My "minor characters" do you mean "lower case" characters? > >> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old > versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. > > I just find this distinctly unfriendly. > Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do? > (As an implementer I would always support both cases even if the spec didn't require it - unless I was writing a conformance test.) > >> 6. Allowing "quoted-string" encoding. >> Earlier versions of predecessor draft-johnston that might be in the >> field (see above) allowed only "token". Again, it would improve >> backward compatibility and slightly simplify implementations if only >> "token" is allowed for "hex" encoding. (It is fine to keep >> "quoted-string" for other encodings.) > > I would rather not see this change made. > But I won't fight if it is. > > Thanks, > Paul > >> 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. >> 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 and A-F), each representing four bits within the octet. The > four >> most significant bits MUST be mapped to the first hexadecimal > digit >> and the four least significant bits MUST be mapped to the second >> hexadecimal digit. Thus, Hex encoded UUI data must have an even > number >> of hexadecimal digits, and MUST be considered invalid if has an > odd >> number. For "hex" encoding, "uui-data" MUST be encoded as "token". >> >> >> >> BR, Thomas >> >> >> ---------------------------------- >> Dr. Thomas Belling >> 3GPP Standardisation >> Nokia Siemens Networks >> >> _______________________________________________ >> 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 > > ***** Disclaimer ***** > http://www.belgacom.be/maildisclaimer/ > From alan.b.johnston@gmail.com Fri Jan 20 08:27:01 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2721F84E0 for ; Fri, 20 Jan 2012 08:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.571 X-Spam-Level: X-Spam-Status: No, score=-104.571 tagged_above=-999 required=5 tests=[AWL=1.028, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qduc0Q0UTxGw for ; Fri, 20 Jan 2012 08:27:00 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 606EC21F84DF for ; Fri, 20 Jan 2012 08:27:00 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1101978obb.31 for ; Fri, 20 Jan 2012 08:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xJrnoYtFbSk+wfU+BmJw20+9e8ejmlhcE7GrcDQjuYg=; b=a0szC1CxAqbMe+H2V5dIlL0EmO1q7OG0CYu1z7afFHFHmiip7ek9JjdQ5XAC9+r6MR aZD7LPyMuUvYJkB8C/juKYZuaZESHP+/4S/vC588rjgdsNofX4JBf7w17MrQ262Kf31J /XMJquMdd9yTwWDADKQFG+yHZs0kN5zQYdqwQ= MIME-Version: 1.0 Received: by 10.182.42.37 with SMTP id k5mr27220684obl.40.1327076820032; Fri, 20 Jan 2012 08:27:00 -0800 (PST) Received: by 10.182.75.136 with HTTP; Fri, 20 Jan 2012 08:26:59 -0800 (PST) In-Reply-To: <4F199277.5000303@alum.mit.edu> References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> <4F18790F.5090508@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> <208EAE1DFA28FC419529619ABB8622441BC00D79B6@CMS03.BGC.NET> <4F199277.5000303@alum.mit.edu> Date: Fri, 20 Jan 2012 10:26:59 -0600 Message-ID: From: Alan Johnston To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 16:27:01 -0000 I have to agree with Paul, here. Hex encoding in IETF standards always seems to allow upper and lower, including RFC 3261. In places where case is significant, I think lowercase is more commonly specified than uppercase. I think we need to continue to allow upper and lower case a-f for hex encod= ing. - Alan - On Fri, Jan 20, 2012 at 10:12 AM, Paul Kyzivat wrot= e: > On 1/20/12 7:44 AM, VAN GEEL Jan (SDV/PSE) wrote: >> >> Paul, >> >> Maybe to help understanding my concern: >> >> At present we implemented the following encoding (as described in ETSI >> TISPAN TS 183 036) in a media gateway controller (interworking gateway >> between IMS and legacy ISDN): > > > Anybody who implements a *draft* before it becomes an RFC should be aware > that things can change before it becomes an RFC. If we felt we couldn't > change a draft once somebody has implemented it we would never get anythi= ng > right. It is painful to be on the bleeding edge, but that is the way it i= s. > > In this case, IIRC, the draft never specified defined the hex encoding at > all, until the current definition was added. If ETSI TISPAN decided to > define the encoding, it could have at least proposed it as a change to th= e > draft - *before* implementing it. That would have provoked a discussion a= nd > probably confronted this issue at that time. > >> =A0 =A0 =A0 =A0 The format of the uuidata field shall be the hexadecimal >> representation of binary data coded in ascii alphanumeric >> =A0 =A0 =A0 =A0 characters. For example, the 8- bit binary value 0011- 1= 111 is 3F >> in hexadecimal. To code this in ascii, one 8- bit >> =A0 =A0 =A0 =A0 byte containing the ascii code for the character '3' (00= 11- 0011 >> or 033H) and one 8- bit byte containing the ascii >> =A0 =A0 =A0 =A0 code for the character 'F' (0100- 0110 or 046H) are requ= ired. For >> each byte value, the high-order hexadecimal digit >> =A0 =A0 =A0 =A0 is always the first digit of the pair of hexadecimal dig= its. The >> ascii letters used for the hex digits shall always be >> =A0 =A0 =A0 =A0 capital form. >> >> My understanding is that the latest draft-ietf-cuss-sip-uui-04 specifies >> the encoding slightly different and also allows lower case. >> In fact during our testing we experienced that an ISDN converter >> implemented the encoding slightly different and the result is that the >> UUS doesn't interwork with legacy ISDN. >> >> If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state by >> 3GPP and ETSI any MGCF or ISDN gateway implementing this version will be >> incompatible with our existing implementation. >> >> Unfortunately not all implementers have your attitude of implementing of >> building robust implementations coping with unrequired stuff. In order t= o >> help them building interoperable and compatible products some backward >> compatibility should be ensured. > > > The Postel maxim is often mentioned in ietf: be conservative in what you = do, > be liberal in what you accept from others. > > I agree with this in principle, even though in practice it isn't as helpf= ul > as one might like. (It only works to the extent that everyone agrees on w= hat > the liberal interpretation is.) But in this case I don't think there is a > lot of controversy over what the liberal interpretation might be. > > So tell me - what will a liberal implementer do when decoding the value > "3f"? > Will it reject the entire message? (I find that hard to believe.) > Will it treat the "f" as something other than 1111? (what?) > Will it ignore the "f"? (Maybe, but that would be stupid.) > >> Therefore I would propose to include the text with the encoding example >> above in the draft so that it is very clear how it should be done. > > > I am fine with examples. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Kind regards >> >> Jan Van Geel >> IT and Network Specialist >> Belgacom SDE/SDV/PSE/FVC >> Tel: +32 2 202 1035 >> Tel: +32 2 207 9032 >> Email : jan.van.geel@belgacom.be >> >> >> >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> Belling, Thomas (NSN - DE/Munich) >> Sent: 20 January 2012 10:36 >> To: ext Paul Kyzivat; cuss@ietf.org >> Subject: Re: [cuss] Definition of hex encoding in >> draft-ietf-cuss-sip-uui-04 >> >> Thanks, Paul >> >> Replies are below. >> >>>> 5. Allowing minor characters: >> >> >>> By "minor characters" do you mean "lower case" characters? >> >> >> Yes >> >>>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on >> >> old versions of the predecessor draft-johnston and provide our own >> definition of hex encoding (in the lack of any definition within the dra= ft). >> This 3GPP/TISPAN definition seems to be largely aligned, but allows only >> major characters. This has been in those specs already for some years an= d >> might be implemented; operators raised such concerns when we discussed >> updating our references. It would make life simpler for us if you also o= nly >> allow major characters. Besides, implementations would become slightly >> simpler. >> >>> I just find this distinctly unfriendly. >>> Is this a real problem, or a theoretical one? What do the existing >> >> implementations of the above specs actually do? >>> >>> (As an implementer I would always support both cases even if the spec >> >> didn't require it - unless I was writing a conformance test.) >> >> I believe this is a real problem: >> In 3GPP a couple of operators raised general concerns about backward >> compatibility, and CRs to update references to the latest version of the >> drafts had to be postponed for this reason. This is why I believe someth= ing >> might already be rolled out or be very close to be rolled out. >> The issue of only "upper case" characters was not yet specifically >> discussed, though. But from 3GPP and TISPAN specs it is currently absolu= tely >> clear that only upper case is allowed. >> >> I agree with your robust implementation principle that a receiver should >> be tolerant. Unfortunately we cannot be sure that this is true with resp= ect >> to "lower case" characters for rolled out receivers. (And the other half= of >> the robust implementation principle is that the sender should accurately >> follow the standards. This is what I was aiming at.) >> >> >>>> 6. Allowing "quoted-string" encoding. >>>> Earlier versions of predecessor draft-johnston that might be in the >>>> field (see above) allowed only "token". Again, it would improve >>>> backward compatibility and slightly simplify implementations if only >>>> "token" is allowed for "hex" encoding. (It is fine to keep >>>> "quoted-string" for other encodings.) >> >> >>> I would rather not see this change made. >>> But I won't fight if it is. >> >> >> This is a very similar issue. Without backward compatibility >> considerations, I would also be fine with allowing both. >> >> >> Thomas >> >> >> >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> ext Paul Kyzivat >> Sent: Thursday, January 19, 2012 9:12 PM >> To: cuss@ietf.org >> Subject: Re: [cuss] Definition of hex encoding in >> draft-ietf-cuss-sip-uui-04 >> >> On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: >>> >>> 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 = use >> >> only >>> >>> =A0 =A0 the characters 0-9, A-F, or a-f. =A0Hex encoded UUI data must h= ave >> >> 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. =A0H= ex >>> =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 t= he >>> =A0 =A0 high order four bits of the octet and the second digit providin= g >> >> 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 s= eem >> 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 "oct= et" >> 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") >>> >>> >>> 5. Allowing minor characters: >> >> >> My "minor characters" do you mean "lower case" characters? >> >>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old >> >> versions of the predecessor draft-johnston and provide our own definitio= n >> of hex encoding (in the lack of any definition within the draft). This >> 3GPP/TISPAN definition seems to be largely aligned, but allows only majo= r >> characters. This has been in those specs already for some years and migh= t be >> implemented; operators raised such concerns when we discussed updating o= ur >> references. It would make life simpler for us if you also only allow maj= or >> characters. Besides, implementations would become slightly simpler. >> >> I just find this distinctly unfriendly. >> Is this a real problem, or a theoretical one? What do the existing >> implementations of the above specs actually do? >> (As an implementer I would always support both cases even if the spec >> didn't require it - unless I was writing a conformance test.) >> >>> 6. Allowing "quoted-string" encoding. >>> Earlier versions of predecessor draft-johnston that might be in the >>> field (see above) allowed only "token". Again, it would improve >>> backward compatibility and slightly simplify implementations if only >>> "token" is allowed for "hex" encoding. (It is fine to keep >>> "quoted-string" for other encodings.) >> >> >> I would rather not see this change made. >> But I won't fight if it is. >> >> =A0 =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 =A0 Paul >> >>> To sum up, a text proposal: >>> >>> 4.x Hex encoding definition >>> =A0 =A0 This specification defines only the value of "hex" for the >> >> "encoding" >>> >>> =A0 =A0 parameter. =A0It is used to encode binary UUI data. >>> =A0 =A0 Each octet of binary data to be represented in the hex encoding >> >> MUST >>> >>> =A0 =A0 be mapped to two hexadecimal digits (represented by ASCII >> >> characters >>> >>> =A0 =A0 0-9 and A-F), each representing four bits within the octet. The >> >> four >>> >>> =A0 =A0 most significant bits MUST be mapped to the first hexadecimal >> >> digit >>> >>> =A0 =A0 and the four least significant bits MUST be mapped to the secon= d >>> =A0 =A0 hexadecimal digit. Thus, Hex encoded UUI data must have an even >> >> number >>> >>> =A0 =A0 of hexadecimal digits, and MUST be considered invalid if has an >> >> odd >>> >>> =A0 =A0 number. For "hex" encoding, "uui-data" MUST be encoded as "toke= n". >>> >>> >>> >>> BR, Thomas >>> >>> >>> ---------------------------------- >>> Dr. Thomas Belling >>> 3GPP Standardisation >>> Nokia Siemens Networks >>> >>> _______________________________________________ >>> 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 >> >> ***** =A0Disclaimer ***** >> http://www.belgacom.be/maildisclaimer/ >> > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From thomas.belling@nsn.com Fri Jan 20 08:38:10 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 158EC21F8646 for ; Fri, 20 Jan 2012 08:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oewAatJrMafU for ; Fri, 20 Jan 2012 08:38:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC7521F869E for ; Fri, 20 Jan 2012 08:38:03 -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 q0KGbjad010100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 17:37:45 +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 q0KGbjDT017737; Fri, 20 Jan 2012 17:37:45 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 17:37:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2012 17:37:44 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57FF08D6C@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F199277.5000303@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 Thread-Index: AczXjlQgduIgwuCISlS8fu6zFDu3SwAAKYRg References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net><4F18790F.5090508@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> <208EAE1DFA28FC419529619ABB8622441BC00D79B6@CMS03.BGC.NET> <4F199277.5000303@alum.mit.edu> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" , "VAN GEEL Jan (SDV/PSE)" X-OriginalArrivalTime: 20 Jan 2012 16:37:45.0362 (UTC) FILETIME=[D65E0F20:01CCD791] Cc: cuss@ietf.org Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 16:38:10 -0000 Hi Paul, I hoped that we could avoid making this a matter of principle: Yes, you are right this encoding stuff should have been raised in IETF and not simply included in 3GPP and TISPAN. But a part of the problem is also that IETF required several years to complete this one User-to-User SIP header. This is why implementations are out by now. In 3GPP and TISPAN we have fixed time plans (in 3GPP about one release a year), as demanded by our operator customers who desire features to become available in a reasonable amount of time. (If 3GPP starts to expect that IETF requires significantly longer time frames to stabilize work, this makes adoption of ongoing IETF work in 3GPP quite complicated.) For CUSS, in the worst case some companies in TISPAN and 3GPP might object that 3GPP updates to your latest drafts, leading to divergent usages of the User-to-User header. Let us rather be pragmatic here and understand each other needs rather than digging in the history to find who is to blame. Obviously, things did not go as well as desirable, but luckily the fix is quite simple and harmless: The changes in the encoding I suggest are quite minor. Thomas -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Friday, January 20, 2012 5:13 PM To: VAN GEEL Jan (SDV/PSE) Cc: cuss@ietf.org; Belling, Thomas (NSN - DE/Munich) Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 On 1/20/12 7:44 AM, VAN GEEL Jan (SDV/PSE) wrote: > Paul, > > Maybe to help understanding my concern: > > At present we implemented the following encoding (as described in ETSI TISPAN TS 183 036) in a media gateway controller (interworking gateway between IMS and legacy ISDN): Anybody who implements a *draft* before it becomes an RFC should be aware that things can change before it becomes an RFC. If we felt we couldn't change a draft once somebody has implemented it we would never get anything right. It is painful to be on the bleeding edge, but that is the way it is. In this case, IIRC, the draft never specified defined the hex encoding at all, until the current definition was added. If ETSI TISPAN decided to define the encoding, it could have at least proposed it as a change to the draft - *before* implementing it. That would have provoked a discussion and probably confronted this issue at that time. > The format of the uuidata field shall be the hexadecimal representation of binary data coded in ascii alphanumeric > characters. For example, the 8- bit binary value 0011- 1111 is 3F in hexadecimal. To code this in ascii, one 8- bit > byte containing the ascii code for the character '3' (0011- 0011 or 033H) and one 8- bit byte containing the ascii > code for the character 'F' (0100- 0110 or 046H) are required. For each byte value, the high-order hexadecimal digit > is always the first digit of the pair of hexadecimal digits. The ascii letters used for the hex digits shall always be > capital form. > > My understanding is that the latest draft-ietf-cuss-sip-uui-04 specifies the encoding slightly different and also allows lower case. > In fact during our testing we experienced that an ISDN converter=20 > implemented the encoding slightly different and the result is that the UUS doesn't interwork with legacy ISDN. > > If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state by 3GPP and ETSI any MGCF or ISDN gateway implementing this version will be incompatible with our existing implementation. > > Unfortunately not all implementers have your attitude of implementing of building robust implementations coping with unrequired stuff. In order to help them building interoperable and compatible products some backward compatibility should be ensured. The Postel maxim is often mentioned in ietf: be conservative in what you do, be liberal in what you accept from others. I agree with this in principle, even though in practice it isn't as helpful as one might like. (It only works to the extent that everyone agrees on what the liberal interpretation is.) But in this case I don't think there is a lot of controversy over what the liberal interpretation might be. So tell me - what will a liberal implementer do when decoding the value "3f"? Will it reject the entire message? (I find that hard to believe.) Will it treat the "f" as something other than 1111? (what?) Will it ignore the "f"? (Maybe, but that would be stupid.) > Therefore I would propose to include the text with the encoding example above in the draft so that it is very clear how it should be done. I am fine with examples. Thanks, Paul > Kind regards > > Jan Van Geel > IT and Network Specialist > Belgacom SDE/SDV/PSE/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be > > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of Belling, Thomas (NSN - DE/Munich) > Sent: 20 January 2012 10:36 > To: ext Paul Kyzivat; cuss@ietf.org > Subject: Re: [cuss] Definition of hex encoding in=20 > draft-ietf-cuss-sip-uui-04 > > Thanks, Paul > > Replies are below. > >>> 5. Allowing minor characters: > >> By "minor characters" do you mean "lower case" characters? > > Yes > >>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on > old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. > >> I just find this distinctly unfriendly. >> Is this a real problem, or a theoretical one? What do the existing > implementations of the above specs actually do? >> (As an implementer I would always support both cases even if the spec > didn't require it - unless I was writing a conformance test.) > > I believe this is a real problem: > In 3GPP a couple of operators raised general concerns about backward compatibility, and CRs to update references to the latest version of the drafts had to be postponed for this reason. This is why I believe something might already be rolled out or be very close to be rolled out. > The issue of only "upper case" characters was not yet specifically discussed, though. But from 3GPP and TISPAN specs it is currently absolutely clear that only upper case is allowed. > > I agree with your robust implementation principle that a receiver=20 > should be tolerant. Unfortunately we cannot be sure that this is true=20 > with respect to "lower case" characters for rolled out receivers. (And > the other half of the robust implementation principle is that the=20 > sender should accurately follow the standards. This is what I was=20 > aiming at.) > > >>> 6. Allowing "quoted-string" encoding. >>> Earlier versions of predecessor draft-johnston that might be in the=20 >>> field (see above) allowed only "token". Again, it would improve=20 >>> backward compatibility and slightly simplify implementations if only >>> "token" is allowed for "hex" encoding. (It is fine to keep=20 >>> "quoted-string" for other encodings.) > >> I would rather not see this change made. >> But I won't fight if it is. > > This is a very similar issue. Without backward compatibility considerations, I would also be fine with allowing both. > > > Thomas > > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of ext Paul Kyzivat > Sent: Thursday, January 19, 2012 9:12 PM > To: cuss@ietf.org > Subject: Re: [cuss] Definition of hex encoding in > draft-ietf-cuss-sip-uui-04 > > On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: >> 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") >> >> >> 5. Allowing minor characters: > > My "minor characters" do you mean "lower case" characters? > >> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on=20 >> old > versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler. > > I just find this distinctly unfriendly. > Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do? > (As an implementer I would always support both cases even if the spec=20 > didn't require it - unless I was writing a conformance test.) > >> 6. Allowing "quoted-string" encoding. >> Earlier versions of predecessor draft-johnston that might be in the=20 >> field (see above) allowed only "token". Again, it would improve=20 >> backward compatibility and slightly simplify implementations if only=20 >> "token" is allowed for "hex" encoding. (It is fine to keep=20 >> "quoted-string" for other encodings.) > > I would rather not see this change made. > But I won't fight if it is. > > Thanks, > Paul > >> 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. >> 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 and A-F), each representing four bits within the octet. The > four >> most significant bits MUST be mapped to the first hexadecimal > digit >> and the four least significant bits MUST be mapped to the second >> hexadecimal digit. Thus, Hex encoded UUI data must have an even > number >> of hexadecimal digits, and MUST be considered invalid if has an > odd >> number. For "hex" encoding, "uui-data" MUST be encoded as "token". >> >> >> >> BR, Thomas >> >> >> ---------------------------------- >> Dr. Thomas Belling >> 3GPP Standardisation >> Nokia Siemens Networks >> >> _______________________________________________ >> 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 > > ***** Disclaimer ***** > http://www.belgacom.be/maildisclaimer/ > From James.Rafferty@dialogic.com Fri Jan 20 10:37:47 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 56FC021F859E for ; Fri, 20 Jan 2012 10:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEPl3DmgqBmX for ; Fri, 20 Jan 2012 10:37:46 -0800 (PST) Received: from outbound.dialogic.com (outbound.dialogic.com [173.210.122.27]) by ietfa.amsl.com (Postfix) with ESMTP id C808121F8587 for ; Fri, 20 Jan 2012 10:37:45 -0800 (PST) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht01.dialogic.com ([::1]) with mapi; Fri, 20 Jan 2012 13:37:45 -0500 From: James Rafferty To: Alan Johnston , Paul Kyzivat Date: Fri, 20 Jan 2012 13:37:43 -0500 Thread-Topic: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 Thread-Index: AczXkFoIGrxSZ6sdRWi8fAL2Va+qaAAEOYOw Message-ID: <54633A5E61DC84429CB9FE3D9143C721168D7906@MBX.dialogic.com> References: <1A8A7D59006A8240B27FF63C794CA57FF08979@DEMUEXC014.nsn-intra.net> <4F18790F.5090508@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF08ACC@DEMUEXC014.nsn-intra.net> <208EAE1DFA28FC419529619ABB8622441BC00D79B6@CMS03.BGC.NET> <4F199277.5000303@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cuss@ietf.org" Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:37:47 -0000 I also agree with Paul and Alan. The earlier versions of UUI support in th= e IETF have been internet drafts, and the implementers always need to be aw= are that the standards track version may vary from earlier drafts, so the c= oncept of needing backward compatibility to a non-standard internet draft d= oes not apply. =20 In the case of the ETSI implementation, if the IETF approach allows both lo= wer and upper case hex, there is nothing to say that the ETSI implementatio= n won't still work (i.e. the IETF UUI recipient could still decode it), jus= t that this non-IETF implementation is not as flexible in its support for i= ncoming UUI that includes lower case hex. =20 James -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Ala= n Johnston Sent: Friday, January 20, 2012 11:27 AM To: Paul Kyzivat Cc: cuss@ietf.org Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-0= 4 I have to agree with Paul, here. Hex encoding in IETF standards always see= ms to allow upper and lower, including RFC 3261. In places where case is s= ignificant, I think lowercase is more commonly specified than uppercase. I think we need to continue to allow upper and lower case a-f for hex encod= ing. - Alan - On Fri, Jan 20, 2012 at 10:12 AM, Paul Kyzivat wrot= e: > On 1/20/12 7:44 AM, VAN GEEL Jan (SDV/PSE) wrote: >> >> Paul, >> >> Maybe to help understanding my concern: >> >> At present we implemented the following encoding (as described in=20 >> ETSI TISPAN TS 183 036) in a media gateway controller (interworking=20 >> gateway between IMS and legacy ISDN): > > > Anybody who implements a *draft* before it becomes an RFC should be=20 > aware that things can change before it becomes an RFC. If we felt we=20 > couldn't change a draft once somebody has implemented it we would=20 > never get anything right. It is painful to be on the bleeding edge, but t= hat is the way it is. > > In this case, IIRC, the draft never specified defined the hex encoding=20 > at all, until the current definition was added. If ETSI TISPAN decided=20 > to define the encoding, it could have at least proposed it as a change=20 > to the draft - *before* implementing it. That would have provoked a=20 > discussion and probably confronted this issue at that time. > >> =A0 =A0 =A0 =A0 The format of the uuidata field shall be the hexadecimal= =20 >> representation of binary data coded in ascii alphanumeric >> =A0 =A0 =A0 =A0 characters. For example, the 8- bit binary value 0011- 1= 111=20 >> is 3F in hexadecimal. To code this in ascii, one 8- bit >> =A0 =A0 =A0 =A0 byte containing the ascii code for the character '3' (00= 11-=20 >> 0011 or 033H) and one 8- bit byte containing the ascii >> =A0 =A0 =A0 =A0 code for the character 'F' (0100- 0110 or 046H) are requ= ired.=20 >> For each byte value, the high-order hexadecimal digit >> =A0 =A0 =A0 =A0 is always the first digit of the pair of hexadecimal dig= its.=20 >> The ascii letters used for the hex digits shall always be >> =A0 =A0 =A0 =A0 capital form. >> >> My understanding is that the latest draft-ietf-cuss-sip-uui-04=20 >> specifies the encoding slightly different and also allows lower case. >> In fact during our testing we experienced that an ISDN converter=20 >> implemented the encoding slightly different and the result is that=20 >> the UUS doesn't interwork with legacy ISDN. >> >> If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state=20 >> by 3GPP and ETSI any MGCF or ISDN gateway implementing this version=20 >> will be incompatible with our existing implementation. >> >> Unfortunately not all implementers have your attitude of implementing=20 >> of building robust implementations coping with unrequired stuff. In=20 >> order to help them building interoperable and compatible products=20 >> some backward compatibility should be ensured. > > > The Postel maxim is often mentioned in ietf: be conservative in what=20 > you do, be liberal in what you accept from others. > > I agree with this in principle, even though in practice it isn't as=20 > helpful as one might like. (It only works to the extent that everyone=20 > agrees on what the liberal interpretation is.) But in this case I=20 > don't think there is a lot of controversy over what the liberal interpret= ation might be. > > So tell me - what will a liberal implementer do when decoding the=20 > value "3f"? > Will it reject the entire message? (I find that hard to believe.) Will=20 > it treat the "f" as something other than 1111? (what?) Will it ignore=20 > the "f"? (Maybe, but that would be stupid.) > >> Therefore I would propose to include the text with the encoding=20 >> example above in the draft so that it is very clear how it should be don= e. > > > I am fine with examples. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Kind regards >> >> Jan Van Geel >> IT and Network Specialist >> Belgacom SDE/SDV/PSE/FVC >> Tel: +32 2 202 1035 >> Tel: +32 2 207 9032 >> Email : jan.van.geel@belgacom.be >> >> >> >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 >> Of Belling, Thomas (NSN - DE/Munich) >> Sent: 20 January 2012 10:36 >> To: ext Paul Kyzivat; cuss@ietf.org >> Subject: Re: [cuss] Definition of hex encoding in >> draft-ietf-cuss-sip-uui-04 >> >> Thanks, Paul >> >> Replies are below. >> >>>> 5. Allowing minor characters: >> >> >>> By "minor characters" do you mean "lower case" characters? >> >> >> Yes >> >>>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on >> >> old versions of the predecessor draft-johnston and provide our own=20 >> definition of hex encoding (in the lack of any definition within the dra= ft). >> This 3GPP/TISPAN definition seems to be largely aligned, but allows=20 >> only major characters. This has been in those specs already for some=20 >> years and might be implemented; operators raised such concerns when=20 >> we discussed updating our references. It would make life simpler for=20 >> us if you also only allow major characters. Besides, implementations=20 >> would become slightly simpler. >> >>> I just find this distinctly unfriendly. >>> Is this a real problem, or a theoretical one? What do the existing >> >> implementations of the above specs actually do? >>> >>> (As an implementer I would always support both cases even if the=20 >>> spec >> >> didn't require it - unless I was writing a conformance test.) >> >> I believe this is a real problem: >> In 3GPP a couple of operators raised general concerns about backward=20 >> compatibility, and CRs to update references to the latest version of=20 >> the drafts had to be postponed for this reason. This is why I believe=20 >> something might already be rolled out or be very close to be rolled out. >> The issue of only "upper case" characters was not yet specifically=20 >> discussed, though. But from 3GPP and TISPAN specs it is currently=20 >> absolutely clear that only upper case is allowed. >> >> I agree with your robust implementation principle that a receiver=20 >> should be tolerant. Unfortunately we cannot be sure that this is true=20 >> with respect to "lower case" characters for rolled out receivers.=20 >> (And the other half of the robust implementation principle is that=20 >> the sender should accurately follow the standards. This is what I was=20 >> aiming at.) >> >> >>>> 6. Allowing "quoted-string" encoding. >>>> Earlier versions of predecessor draft-johnston that might be in the=20 >>>> field (see above) allowed only "token". Again, it would improve=20 >>>> backward compatibility and slightly simplify implementations if=20 >>>> only "token" is allowed for "hex" encoding. (It is fine to keep=20 >>>> "quoted-string" for other encodings.) >> >> >>> I would rather not see this change made. >>> But I won't fight if it is. >> >> >> This is a very similar issue. Without backward compatibility=20 >> considerations, I would also be fine with allowing both. >> >> >> Thomas >> >> >> >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 >> Of ext Paul Kyzivat >> Sent: Thursday, January 19, 2012 9:12 PM >> To: cuss@ietf.org >> Subject: Re: [cuss] Definition of hex encoding in >> draft-ietf-cuss-sip-uui-04 >> >> On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote: >>> >>> 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 = use >> >> only >>> >>> =A0 =A0 the characters 0-9, A-F, or a-f. =A0Hex encoded UUI data must h= ave >> >> 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. =A0H= ex >>> =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=20 >>> the >>> =A0 =A0 high order four bits of the octet and the second digit providin= g >> >> 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=20 >>> the >> >> hex encoding. I would rather suggest a dedicated subclause "4.x Hex=20 >> 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=20 >>> series >> >> of octets of binary data yields a series of hexadecimal digits, two=20 >> hexadecimal digits for each octet of binary data.". Hexadecimal=20 >> digits seem to be called "octets" throughout the text, which is highly c= onfusing. >> >> 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,=20 >> and the text is quite ambiguous: Does "octet" refer to the binary=20 >> data to be encoded or the result of the encoding? The text only makes se= nse if "octet" >> is understood as the result of encoding. Speaking about "characters"=20 >> or "hexadecimal digits" rather than "octets" would remove this ambiguity= . >> >> I agree. >> >>> 4. Lack of normative language ("MUST") >>> >>> >>> 5. Allowing minor characters: >> >> >> My "minor characters" do you mean "lower case" characters? >> >>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on=20 >>> old >> >> versions of the predecessor draft-johnston and provide our own=20 >> definition of hex encoding (in the lack of any definition within the=20 >> draft). This 3GPP/TISPAN definition seems to be largely aligned, but=20 >> allows only major characters. This has been in those specs already=20 >> for some years and might be implemented; operators raised such=20 >> concerns when we discussed updating our references. It would make=20 >> life simpler for us if you also only allow major characters. Besides, im= plementations would become slightly simpler. >> >> I just find this distinctly unfriendly. >> Is this a real problem, or a theoretical one? What do the existing=20 >> implementations of the above specs actually do? >> (As an implementer I would always support both cases even if the spec=20 >> didn't require it - unless I was writing a conformance test.) >> >>> 6. Allowing "quoted-string" encoding. >>> Earlier versions of predecessor draft-johnston that might be in the=20 >>> field (see above) allowed only "token". Again, it would improve=20 >>> backward compatibility and slightly simplify implementations if only=20 >>> "token" is allowed for "hex" encoding. (It is fine to keep=20 >>> "quoted-string" for other encodings.) >> >> >> I would rather not see this change made. >> But I won't fight if it is. >> >> =A0 =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 =A0 Paul >> >>> To sum up, a text proposal: >>> >>> 4.x Hex encoding definition >>> =A0 =A0 This specification defines only the value of "hex" for the >> >> "encoding" >>> >>> =A0 =A0 parameter. =A0It is used to encode binary UUI data. >>> =A0 =A0 Each octet of binary data to be represented in the hex encoding >> >> MUST >>> >>> =A0 =A0 be mapped to two hexadecimal digits (represented by ASCII >> >> characters >>> >>> =A0 =A0 0-9 and A-F), each representing four bits within the octet. The >> >> four >>> >>> =A0 =A0 most significant bits MUST be mapped to the first hexadecimal >> >> digit >>> >>> =A0 =A0 and the four least significant bits MUST be mapped to the secon= d >>> =A0 =A0 hexadecimal digit. Thus, Hex encoded UUI data must have an even >> >> number >>> >>> =A0 =A0 of hexadecimal digits, and MUST be considered invalid if has an >> >> odd >>> >>> =A0 =A0 number. For "hex" encoding, "uui-data" MUST be encoded as "toke= n". >>> >>> >>> >>> BR, Thomas >>> >>> >>> ---------------------------------- >>> Dr. Thomas Belling >>> 3GPP Standardisation >>> Nokia Siemens Networks >>> >>> _______________________________________________ >>> 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 >> >> ***** =A0Disclaimer ***** >> http://www.belgacom.be/maildisclaimer/ >> > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From thomas.belling@nsn.com Fri Jan 27 11:50:19 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 8925821F864C for ; Fri, 27 Jan 2012 11:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 JVQxd7tfZFXO for ; Fri, 27 Jan 2012 11:50:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 70AEC21F85F3 for ; Fri, 27 Jan 2012 11:50:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0RJoBl2025897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2012 20:50:11 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0RJo98W024395; Fri, 27 Jan 2012 20:50:10 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 20:49:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2012 20:49:24 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F1873BD.1020302@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Assuming "package=isdn-uui" as default if package parameter is omitted? Thread-Index: AczW43JvIPMtiOyUS1SN4CWkOJWOsAGSAoZA References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net> <4F1873BD.1020302@alum.mit.edu> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" , , "ext DRAGE, Keith (Keith)" X-OriginalArrivalTime: 27 Jan 2012 19:49:25.0303 (UTC) FILETIME=[C5C20C70:01CCDD2C] Subject: Re: [cuss] Assuming "package=isdn-uui" as default if package parameter is omitted? 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, 27 Jan 2012 19:50:20 -0000 Thanks Paul, I checked the specs in this respect and they seem to be in conflict: >From draft-ietf-cuss-sip-uui-04.txt 4. Normative Definition =20 ... The "package" parameter identifies the package which defines the generation and usage of the UUI data for a particular application. For the case of interworking with the ISDN UUI Service, the ISDN UUI Service interworking package is used. If the "package" parameter is not present, interworking with the ISDN UUI Service MUST be assumed. =20 This seems to be fine. >From draft-ietf-cuss-sip-uui-isdn-01: 7. UAC requirements ... When sending UUI for the ISDN package, the UAC MUST set the User-to- User "package" header field parameter to "isdn-uui". =20 I believe this place should be changed. I also noticed another inconsistency: >From draft-ietf-cuss-sip-uui-04.txt 4. Normative Definition =20 ... The "content" parameter identifies the actual content of the UUI data. If not present, the content MUST be assumed to be unknown as it is in the ISDN UUI Service. =20 I believe this should be corrected as draft-ietf-cuss-sip-uui-isdn-01 defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: Thursday, January 19, 2012 8:49 PM To: cuss@ietf.org Subject: Re: [cuss] Assuming "package=3Disdn-uui" as default if package parameter is omitted? I am ok with making this the default. Thanks, Paul On 1/19/12 12:52 PM, Belling, Thomas (NSN - DE/Munich) wrote: > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old > versions(-02 and -03)of the predecessor draft-johnston. This has been=20 > in those specs already for some years and might be implemented;=20 > operators raised such concerns when we discussed updating our referencesin 3GPP. > > The"package"parameter of the"User-to-User"SIP headerwas not yet=20 > defined in those versions. > > A User-to-User header sentbyinterworking entities complaint with=20 > current versionETSI TISPAN TS 183 036 and 3GPP TS 29.163would only=20 > contain the"encoding=3Dhex"parameter, but=20 > no"package=3Disdn-uui".Contentsof"uui-data"would bealignedwithwhat is=20 > now defined for"package=3Disdn-uui". > > It wouldthusgreatly enhance backward > compatibility,ifdraft-ietf-cuss-sip-uui-04could be updated to state=20 > that"package=3Disdn-uui"is the defaultto be assumedif package = parameter=20 > is omittedin the"User-to-User"SIP header. > > (draft-ietf-cuss-sip-uui might also require some related updates.) > > > BR, Thomas > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > > > _______________________________________________ > 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 celine.serrutvalette@orange.com Mon Jan 30 01:21: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 4C9D021F8630 for ; Mon, 30 Jan 2012 01:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V3wyjlGKDME for ; Mon, 30 Jan 2012 01:21:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2992221F862F for ; Mon, 30 Jan 2012 01:21:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9ECB55D88E3; Mon, 30 Jan 2012 10:21:27 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 929835D86E2; Mon, 30 Jan 2012 10:21:27 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 10:21:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2012 10:21:25 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202274FC0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Assuming "package=isdn-uui" as default if package parameter is omitted? Thread-Index: AczW43JvIPMtiOyUS1SN4CWkOJWOsAGSAoZAAIDPznA= References: <1A8A7D59006A8240B27FF63C794CA57FF08980@DEMUEXC014.nsn-intra.net><4F1873BD.1020302@alum.mit.edu> <1A8A7D59006A8240B27FF63C794CA57FF7C226@DEMUEXC014.nsn-intra.net> From: To: , , , X-OriginalArrivalTime: 30 Jan 2012 09:21:27.0348 (UTC) FILETIME=[8B2F9F40:01CCDF30] Subject: Re: [cuss] Assuming "package=isdn-uui" as default if package parameter is omitted? 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, 30 Jan 2012 09:21:30 -0000 Hello, We support this comment, we also have raised this inconsistency in our = list of remarks after reviewing draft-ietf-cuss-sip-uui-isdn-01 (C8 = comment in = http://www.ietf.org/mail-archive/web/cuss/current/msg00325.html). We = hope that draft-ietf-cuss-sip-uui-isdn-01 will be changed to be = consistent with draft-ietf-cuss-sip-uui-04.txt on this topic. Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de Belling, Thomas (NSN - DE/Munich) Envoy=E9=A0: vendredi 27 janvier 2012 20:49 =C0=A0: ext Paul Kyzivat; cuss@ietf.org; ext DRAGE, Keith (Keith) Objet=A0: Re: [cuss] Assuming "package=3Disdn-uui" as default if = packageparameter is omitted? Thanks Paul, I checked the specs in this respect and they seem to be in conflict: >From draft-ietf-cuss-sip-uui-04.txt 4. Normative Definition =20 ... The "package" parameter identifies the package which defines the generation and usage of the UUI data for a particular application. For the case of interworking with the ISDN UUI Service, the ISDN UUI Service interworking package is used. If the "package" parameter is not present, interworking with the ISDN UUI Service MUST be assumed. =20 This seems to be fine. >From draft-ietf-cuss-sip-uui-isdn-01: 7. UAC requirements ... When sending UUI for the ISDN package, the UAC MUST set the User-to- User "package" header field parameter to "isdn-uui". =20 I believe this place should be changed. I also noticed another inconsistency: >From draft-ietf-cuss-sip-uui-04.txt 4. Normative Definition =20 ... The "content" parameter identifies the actual content of the UUI data. If not present, the content MUST be assumed to be unknown as it is in the ISDN UUI Service. =20 I believe this should be corrected as draft-ietf-cuss-sip-uui-isdn-01 defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: Thursday, January 19, 2012 8:49 PM To: cuss@ietf.org Subject: Re: [cuss] Assuming "package=3Disdn-uui" as default if package parameter is omitted? I am ok with making this the default. Thanks, Paul On 1/19/12 12:52 PM, Belling, Thomas (NSN - DE/Munich) wrote: > In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old > versions(-02 and -03)of the predecessor draft-johnston. This has been=20 > in those specs already for some years and might be implemented;=20 > operators raised such concerns when we discussed updating our referencesin 3GPP. > > The"package"parameter of the"User-to-User"SIP headerwas not yet=20 > defined in those versions. > > A User-to-User header sentbyinterworking entities complaint with=20 > current versionETSI TISPAN TS 183 036 and 3GPP TS 29.163would only=20 > contain the"encoding=3Dhex"parameter, but=20 > no"package=3Disdn-uui".Contentsof"uui-data"would bealignedwithwhat is=20 > now defined for"package=3Disdn-uui". > > It wouldthusgreatly enhance backward > compatibility,ifdraft-ietf-cuss-sip-uui-04could be updated to state=20 > that"package=3Disdn-uui"is the defaultto be assumedif package = parameter=20 > is omittedin the"User-to-User"SIP header. > > (draft-ietf-cuss-sip-uui might also require some related updates.) > > > BR, Thomas > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > > > _______________________________________________ > 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