From vkg@bell-labs.com Mon Nov 11 09:39:12 2013 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 8C89221E820E for ; Mon, 11 Nov 2013 09:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejmkFnJZsSGP for ; Mon, 11 Nov 2013 09:39:06 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAB521E8201 for ; Mon, 11 Nov 2013 09:38:52 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rABHcf18003008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Nov 2013 11:38:41 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rABHcf86028474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Nov 2013 11:38:41 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rABHcfOb029466 for ; Mon, 11 Nov 2013 11:38:41 -0600 (CST) Message-ID: <5281161C.1060404@bell-labs.com> Date: Mon, 11 Nov 2013 11:38:36 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [cuss] "isdn-uui" versus "isdn-network" 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, 11 Nov 2013 17:39:12 -0000 Folks: The forward movement of draft-ietf-cuss-sip-uui-isdn has been bogged down. While the issue that stopped its movement is not as grandiose as the MTI discussion on the rtcweb WG (thankfully!), nonetheless, it must get resolved to proceed further. At issue is the fact that draft-ietf-cuss-sip-uui-isdn uses the value of "isdn-uui" for the "purpose" header field parameter. Older versions of the draft used the value "isdn-network". Consequently, there are some implementations that use "isdn-network" and doubtlessly, for some valid reasons these implementations are not amenable to change. Therefore, it was proposed that a note be added that allows senders to use either "isdn-network" or "isdn-uui" and the receiver be prepared to receive either of the value. The big question was whether this note appear as informative or normative? If normative, then the ABNF would need to modified to support "isdn- network" generation as well. If informative, then this note sets a precedence that parameters defined in Work In Progress Internet-Drafts be supported in perpetuity. The argument for not supporting "isdn- network" by updating the ABNF is that it introduces a certain amount of uncertainty: how does a sender decide which representation of the parameter to send out? It can randomly choose one, of course, but this just seems a bad protocol design pattern. The chairs, the AD, the draft author and a few WG members had a a hallway conversation in the Vancouver IETF to close this issue. The outcome of this conversation is that "isdn-network" is an artifact that draft-ietf-cuss-sip-uui-isdn is NOT required to carry on forward. Allowing the daft to support an older representation simply sets a precedent that will engender a tough ride as the draft sails through the IESG. As such, "isdn-uui" is the only legal value. We will now proceed to issue a WGLC on the draft. Thanks, Vijay K. Gurbani and Enrico Marocco. From vkg@bell-labs.com Wed Nov 13 11:11:18 2013 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 244EB21E80CA for ; Wed, 13 Nov 2013 11:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPKC6vPrwB80 for ; Wed, 13 Nov 2013 11:11:12 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 95FE321E80A8 for ; Wed, 13 Nov 2013 11:11:12 -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 rADJBBJh008304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Nov 2013 13:11:12 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rADJBB3o032663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Nov 2013 13:11:11 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rADJBBIe001676 for ; Wed, 13 Nov 2013 13:11:11 -0600 (CST) Message-ID: <5283CECB.8050804@bell-labs.com> Date: Wed, 13 Nov 2013 13:11:07 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 19:11:18 -0000 Folks: Enrico and I will like to announce a WGLC for the ISDN draft [1]. The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. We will appreciate your comments on the draft, posted to the list. All comments are appreciated, even if it is a simple one-liner saying that you believe the draft is ready, or conversely, that it is not ready (and why). As you review the draft, as part of your WGLC review, please identify any issues that may exist in regard to compatibility with draft-ietf-cuss-uui (the mechanism draft). Thank you. [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ Vijay K. Gurbani and Enrico Marocco From bruno.chatras@orange.com Wed Nov 20 08:51:40 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB01ADFFE for ; Wed, 20 Nov 2013 08:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpwED-h_XlOV for ; Wed, 20 Nov 2013 08:51:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C31AE086 for ; Wed, 20 Nov 2013 08:51:37 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 81825C0675; Wed, 20 Nov 2013 17:51:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 6A184C8058; Wed, 20 Nov 2013 17:51:30 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 17:51:30 +0100 From: To: "Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT0/rnx1aTdzE2fpUK6uaPrRZouX5ew Date: Wed, 20 Nov 2013 16:51:28 +0000 Message-ID: <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5281161C.1060404@bell-labs.com> In-Reply-To: <5281161C.1060404@bell-labs.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 16:51:41 -0000 Vijay, I don't know who had been invited to the hallway conversation you mentioned= but to be honest, I'm really surprised by the decision made.=20 Indeed, there were no objections on the cuss list to the latest wording (in= formative) proposed on Sept 12 for the text to be added to the document and= I don't really understand why the proposal was not implemented right away = in the I-D actually!=20 http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html Moreover, all people who have been active on this topic on the cuss mailing= list either supported the addition of an informative text or have asked qu= estions for clarification. I have not seen any explicit objection. So, how can a hallway conversation lead to such a U-turn?=20 Furthermore, I'd like to understand why people have concerns with adding th= e proposed informative statement in the CUSS document but seem to be happy = with a similar note in draft-ietf-bfcpbis-rfc4583bis Note: In [15] 'm-stream' was erroneously used in Section 10. Although the example was non-normative, it is implemented by some vendors and occurs in cases where the endpoint is willing to act as an server. Therefore, it is RECOMMENDED to support parsing and interpreting 'm-stream' the same way as 'mstrm' when receiving. Bruno > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de > Vijay K. Gurbani > Envoy=E9=A0: lundi 11 novembre 2013 18:39 > =C0=A0: cuss@ietf.org > Objet=A0: [cuss] "isdn-uui" versus "isdn-network" >=20 > Folks: >=20 > The forward movement of draft-ietf-cuss-sip-uui-isdn has been bogged down. > While the issue that stopped its movement is not as grandiose as the MTI > discussion on the rtcweb WG (thankfully!), nonetheless, it must get resol= ved > to proceed further. >=20 > At issue is the fact that draft-ietf-cuss-sip-uui-isdn uses the value of > "isdn-uui" for the "purpose" header field parameter. Older versions of t= he > draft used the value "isdn-network". Consequently, there are some > implementations that use "isdn-network" and doubtlessly, for some valid > reasons these implementations are not amenable to change. >=20 > Therefore, it was proposed that a note be added that allows senders to use > either "isdn-network" or "isdn-uui" and the receiver be prepared to recei= ve > either of the value. >=20 > The big question was whether this note appear as informative or normative? >=20 > If normative, then the ABNF would need to modified to support "isdn- > network" generation as well. If informative, then this note sets a > precedence that parameters defined in Work In Progress Internet-Drafts be > supported in perpetuity. The argument for not supporting "isdn- network"= by > updating the ABNF is that it introduces a certain amount of > uncertainty: how does a sender decide which representation of the paramet= er > to send out? It can randomly choose one, of course, but this just seems a > bad protocol design pattern. >=20 > The chairs, the AD, the draft author and a few WG members had a a hallway > conversation in the Vancouver IETF to close this issue. >=20 > The outcome of this conversation is that "isdn-network" is an artifact th= at > draft-ietf-cuss-sip-uui-isdn is NOT required to carry on forward. > Allowing the daft to support an older representation simply sets a preced= ent > that will engender a tough ride as the draft sails through the IESG. >=20 > As such, "isdn-uui" is the only legal value. >=20 > We will now proceed to issue a WGLC on the draft. >=20 > Thanks, >=20 > Vijay K. Gurbani and Enrico Marocco. > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From vkg@bell-labs.com Wed Nov 20 14:48:42 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1AD1AE1F4 for ; Wed, 20 Nov 2013 14:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnj2BAd1uUqc for ; Wed, 20 Nov 2013 14:48:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 135491AE4F0 for ; Wed, 20 Nov 2013 14:48:39 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAKMmWM3001304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Nov 2013 16:48:33 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rAKMmWpq020845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 16:48:32 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rAKMmV5R028782; Wed, 20 Nov 2013 16:48:31 -0600 (CST) Message-ID: <528D3C40.1080308@bell-labs.com> Date: Wed, 20 Nov 2013 16:48:32 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: bruno.chatras@orange.com, "cuss@ietf.org" References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:48:43 -0000 On 11/20/2013 10:51 AM, bruno.chatras@orange.com wrote: > Vijay, > > I don't know who had been invited to the hallway conversation you > mentioned but to be honest, I'm really surprised by the decision > made. Bruno: Rest assured that no one was explicitly invited or implicitly precluded in the hallway conversation. Since the chairs, the AD, the authors and some working group members were physically at the same space and time in Vancouver, it seemed appropriate to look into what was holding the draft back. > Indeed, there were no objections on the cuss list to the latest > wording (informative) proposed on Sept 12 for the text to be added to > the document and I don't really understand why the proposal was not > implemented right away in the I-D actually! > http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html As to why the proposal of Sept 12 was not implemented in the draft right away, I will have to defer to the author, but my understanding, as you write below, is that there was enough of a gray area that the authors did not quite know how to proceed. > Moreover, all people who have been active on this topic on the cuss > mailing list either supported the addition of an informative text or > have asked questions for clarification. I have not seen any explicit > objection. > > So, how can a hallway conversation lead to such a U-turn? The seeming U-turn stems from the fact that either the note being added be normative or informative. If informative, then then this note sets a precedence that parameters defined in Work In Progress Internet-Drafts be supported in perpetuity. If normative, then the ABNF has to be updated and all implementations must not bear the burden of allocating the same semantic meaning to two syntactically different headers. This just seems bad protocol design. The expedient thing was to take a position and go with WGLC on the understanding that if the position is not preferable, then this will be hashed on the mailing list (essentially what we are doing now). That said, I will take my chair hat off and address what you write next as an individual contributor. > Furthermore, I'd like to understand why people have concerns with > adding the proposed informative statement in the CUSS document but > seem to be happy with a similar note in > draft-ietf-bfcpbis-rfc4583bis > > Note: In [15] 'm-stream' was erroneously used in Section 10. > Although the example was non-normative, it is implemented by some > vendors and occurs in cases where the endpoint is willing to act as > an server. Therefore, it is RECOMMENDED to support parsing and > interpreting 'm-stream' the same way as 'mstrm' when receiving. I have no idea why the bfcpbis working group agreed to alias 'm-stream' to 'mstrm', but it is certainly their prerogative. However, does that mean that we do the same in cuss working group? Alias header names just mean that implementations have to add more parsing machinery to handle the same outcome for a parsed token. Having written a SIP parser, I am all for making SIP parsing as much deterministic as possible. My personal (i.e., not as chair) preference is to have one header name. Now, back to my role as a chair. If you'd like to maintain "isdn-network" as an alias for "isdn-uui", then we need to seek consensus on the list with the understanding that the note moves to normative and the ABNF is updated to reflect the alias. We cannot straddle the fence and simply put a note allowing "isdn-network" without modifying the ABNF, etc. This must be done for the draft to proceed to IESG. The draft is now in WGLC, and we can certainly handle this change if the working group agrees as an outcome of WGLC. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From pkyzivat@alum.mit.edu Wed Nov 20 15:08:51 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F21AE536 for ; Wed, 20 Nov 2013 15:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_41=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms45kFCUCv7c for ; Wed, 20 Nov 2013 15:08:49 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC01AE180 for ; Wed, 20 Nov 2013 15:08:49 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id ryur1m0060cZkys5Fz8ibY; Wed, 20 Nov 2013 23:08:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id rz8i1m00N3ZTu2S3Wz8i1G; Wed, 20 Nov 2013 23:08:42 +0000 Message-ID: <528D40FA.8040908@alum.mit.edu> Date: Wed, 20 Nov 2013 15:08:42 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com> In-Reply-To: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384988922; bh=+fbgCp5ZFE6WPcGLQqxoHKImxAoMNapHwXIBgyyKPwU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=exJ8qArymOiIbkdqIoM1wU6z5XuIhijKrKa9ykXo+B6l2NRmMIaCJHH2mNFD1bLrx r4b77fuwuI02iXvqIUaVM0gPKbbZdPP84bUfcOQqiIYMDThVpYzja9dOBE1BZEjxvH nFJADNx0yIlWYz28LEnuHgoy4IuTnJxzUU9ZBtCadus6x3X7amCUI7p1FGYEHwV+G2 b/hvJWKcrXpssbrgPRo8QcX911R8HRxTTogxqAAQV/f9+M8uGU5cInHzEf1B8OL9uC 8czUPWBEO9h+QY8YaTImZjYjhSVLdQvAUgEiL0+T2InAxG5YAbwWvkwRLkGhOcio+P 9Xh4/4N14qQNA== Cc: "cuss@ietf.org" Subject: Re: [cuss] WGLC of draft-ietf-salud-alert-info-urns-09 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 23:08:51 -0000 On 11/20/13 11:44 AM, Dale R. Worley wrote: > [as chair] > > Given that we're having a WGLC, I'd like the authors of the draft to > indicate their opinion of the -09 version on the Salud mailing list. > > So far, I've been the only one to comment at all. > > Dale > Sorry Dale. I just did another review and found a few editorial things: Section 1.1: Another limitation of the current solution is that the referenced tones are tied to particular rendering. It is not possible to provide semantic indications or names for rendering characteristics that signals the intent and allows the recipient UA to decide how to render the received information in an appropriate way. s/signals/signal/ s/allows/allow/ Section 1.3: This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header field) to a "renderer" which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications. Reorder a sentence to make it clearer: s/based on the indication to a human user/to a human user based on the indication/ Section 4: Registration date: TBD How is this to be filled in? Should there be instructions to the editor? Section 7.2: The meaning of a or an that is defined privately (because of a preceding ) is only fixed within the context provided by the sequence of preceding s; these components have no meaning in isolation and there is no necessary relationship between the meaning of textually identical s that are preceded by different sequences of s. . Extra "." at the end of the paragraph. Section 9.2: The examples are a but hard to follow. Specifically, each example describes the signals at each source and the winner, but when doing so it never mentions which signals (Signal 1, Signal 2, ...) - it instead identifies by alert urn. Since to point is to determine the signal to be rendered, this seems obscure. For example the following would seem clearer to me for 9.2.1: If the device receives , then the sort is: Signals at source:internal: (this is, first place) Signal 2 Signals at source: (tied for second place) Signal 3 Signal 4 Signal 5 And these signals are excluded from the set: Signal 1 So in this example, the sorting algorithm properly gives first place to Signal 2. Section 10: A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service. The above only talks about adding *to* an Alert-Info, not the adding *of* an Alert-Info. I suggest: A SIP UA MAY include one or more Alert-Info header fields, containing one or more URNs in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service. Section 11: A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service. I think we would ideally allow a proxy to modify/remove URNs, but 3261 doesn't permit that. But a proxy can get a similar effect by putting a counteracting URN earlier in the sequence. But it is also possible that there will be no Alert-Info and the proxy needs to add one. I suggest: A SIP proxy MAY add an Alert-Info header field if none is present, and MAY add or remove URNs to an Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service. Thanks, Paul From aallen@blackberry.com Thu Nov 21 07:32:08 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD471ADF90 for ; Thu, 21 Nov 2013 07:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lIocqV4kOlO for ; Thu, 21 Nov 2013 07:32:06 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D489E1AE177 for ; Thu, 21 Nov 2013 07:32:05 -0800 (PST) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 Nov 2013 10:31:51 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 09:31:50 -0600 From: Andrew Allen To: "bruno.chatras@orange.com" , "Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT1dpjYGndAPU2F8sy5W0sV45ouyA4AgAEOYIA= Date: Thu, 21 Nov 2013 15:31:50 +0000 Message-ID: References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:32:08 -0000 I have some sympathy for Bruno's position. He is merely asking to align wit= h the principle of "Be strict in what you send, but generous in what you re= ceive". I don't think this creates a bad precedent (similar things have been done a= lready - just take a look at the more complex backwards compatibility bein= g defined now in INSIPID) and whatever is done always requires consensus. At IETF we hold in high regard running code and hope and expect that people= will implement drafts ahead of publication. Given the time this draft has = taken to progress it shouldn't be a surprise that there is now deployed equ= ipment based on earlier versions of the draft. In many cases work in IETF h= as originated based on what was already done outside IETF (e.g. Jabber) and= backwards compatibility with pre-standard kit is often a design goal. I don't think acceptance of a pre-standard token value is too much to ask = to ensure interoperability. That's why we create standards to ensure intero= perability not to be an obstacle to it. Andrew -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of bruno.chatras@orange= .com Sent: Wednesday, November 20, 2013 11:51 AM To: Vijay K. Gurbani; cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" Vijay, I don't know who had been invited to the hallway conversation you mentioned= but to be honest, I'm really surprised by the decision made. = Indeed, there were no objections on the cuss list to the latest wording (in= formative) proposed on Sept 12 for the text to be added to the document and= I don't really understand why the proposal was not implemented right away = in the I-D actually! = http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html Moreover, all people who have been active on this topic on the cuss mailing= list either supported the addition of an informative text or have asked qu= estions for clarification. I have not seen any explicit objection. So, how can a hallway conversation lead to such a U-turn? = Furthermore, I'd like to understand why people have concerns with adding th= e proposed informative statement in the CUSS document but seem to be happy = with a similar note in draft-ietf-bfcpbis-rfc4583bis Note: In [15] 'm-stream' was erroneously used in Section 10. Although the example was non-normative, it is implemented by some vendors and occurs in cases where the endpoint is willing to act as an server. Therefore, it is RECOMMENDED to support parsing and interpreting 'm-stream' the same way as 'mstrm' when receiving. Bruno > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = > de Vijay K. Gurbani Envoy=E9=A0: lundi 11 novembre 2013 18:39 =C0=A0: = > cuss@ietf.org Objet=A0: [cuss] "isdn-uui" versus "isdn-network" > = > Folks: > = > The forward movement of draft-ietf-cuss-sip-uui-isdn has been bogged down. > While the issue that stopped its movement is not as grandiose as the = > MTI discussion on the rtcweb WG (thankfully!), nonetheless, it must = > get resolved to proceed further. > = > At issue is the fact that draft-ietf-cuss-sip-uui-isdn uses the value = > of "isdn-uui" for the "purpose" header field parameter. Older = > versions of the draft used the value "isdn-network". Consequently, = > there are some implementations that use "isdn-network" and = > doubtlessly, for some valid reasons these implementations are not amenabl= e to change. > = > Therefore, it was proposed that a note be added that allows senders to = > use either "isdn-network" or "isdn-uui" and the receiver be prepared = > to receive either of the value. > = > The big question was whether this note appear as informative or normative? > = > If normative, then the ABNF would need to modified to support "isdn- = > network" generation as well. If informative, then this note sets a = > precedence that parameters defined in Work In Progress Internet-Drafts = > be supported in perpetuity. The argument for not supporting "isdn- = > network" by updating the ABNF is that it introduces a certain amount = > of > uncertainty: how does a sender decide which representation of the = > parameter to send out? It can randomly choose one, of course, but = > this just seems a bad protocol design pattern. > = > The chairs, the AD, the draft author and a few WG members had a a = > hallway conversation in the Vancouver IETF to close this issue. > = > The outcome of this conversation is that "isdn-network" is an artifact = > that draft-ietf-cuss-sip-uui-isdn is NOT required to carry on forward. > Allowing the daft to support an older representation simply sets a = > precedent that will engender a tough ride as the draft sails through the = IESG. > = > As such, "isdn-uui" is the only legal value. > = > We will now proceed to issue a WGLC on the draft. > = > Thanks, > = > Vijay K. Gurbani and Enrico Marocco. > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From aallen@blackberry.com Thu Nov 21 07:32:09 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D82E1ADF90 for ; Thu, 21 Nov 2013 07:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqGJ5S60MIdA for ; Thu, 21 Nov 2013 07:32:05 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 82D001ADFD9 for ; Thu, 21 Nov 2013 07:32:05 -0800 (PST) Received: from xct102ads.rim.net ([10.67.111.43]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 Nov 2013 10:31:53 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 09:31:52 -0600 From: Andrew Allen To: "cuss@ietf.org" Thread-Topic: WGLC commentsfor draft-ietf-cuss-sip-uui-isdn Thread-Index: Ac7ms5+uqD1lEgYcTAytxv9IVdFQqg== Date: Thu, 21 Nov 2013 15:31:51 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E677ABXMB104ADSrimnet_" MIME-Version: 1.0 Subject: [cuss] WGLC commentsfor draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:32:09 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E677ABXMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I have reviewed draft-ietf-cuss-sip-uui-isdn Here are some NITS General: inconsistent use of User-to-User (sometimes without hyphens and so= metimes lower case u) Section 3.1 The maximum number of octets of user information that can be transported in 128 octets plus a protocol discriminator. SHOULD BE The maximum number of octets of user information that can be transported is 128 octets plus a protocol discriminator. This sentence doesn't make sense to me. I think it needs rephrasing: Only a single user information can be transported in each message. Section 6 What happens to User-to-User header fields relating to different packages is outside the scope of this document. READS BETTER AS What happens to User-to-User header fields relating to other packages is outside the scope of this document. Section 8 The UAS MAY include the User-to-User header field in responses to the initial INVITE request, or the BYE requests or responses for the dialog, only where the original INVITE request included a User-to- User header field with the "purpose" header field parameter to "isdn- uui", or where no "purpose" header field parameter was included. SHOULD BE The UAS MAY include the User-to-User header field in responses to the initial INVITE request, or the BYE requests or responses for the dialog, only where the original INVITE request included a User-to- User header field with the "purpose" header field parameter set to "isdn- uui", or where no "purpose" header field parameter was included. When receiving UUI, when multiple User-to-User header fields are received from the originating user in the same request with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAC MUST discard all these header fields. SHOULD BE When receiving UUI, when multiple User-to-User header fields are received from the originating user in the same request with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAC MUST discard all these header fields. Section 9 A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". SHOULD BE A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value than "isdn-uui". --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E677ABXMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

 

I have reviewed draft-ietf-cuss-sip-uui-isdn

 

Here are some NITS

 

General: inconsistent use of User-to-User (sometimes= without hyphens and sometimes lower case u)

 

Section 3.1

 

      The maximum num= ber of octets of user information that can be

      transported in = 128 octets plus a protocol discriminator.

 

SHOULD BE

 

      The maximum=
 number of octets of user information that can be
      transported=
 is 128=
 octets plus a protocol discriminator.

 

This sentence doesn’t make sense to me. I thin= k it needs rephrasing:

 

       =
 Only a single user information can be transported in each message.

 

Section 6

 

      What happen=
s to User-to-User header fields relating to different

      packages is=
 outside the scope of this document.


 


READS BETTER AS


 


      What happen=
s to User-to-User header fields relating to other


      packages is=
 outside the scope of this document.


 


 


Section 8


   The UAS MAY include the User-to-User header f=
ield in responses to the


   initial INVITE request, or the BYE requests o=
r responses for the


   dialog, only where the original INVITE reques=
t included a User-to-


   User header field with the "purpose"=
; header field parameter to "isdn-


   uui", or where no "purpose" he=
ader field parameter was included.


 


SHOULD BE


 


   The UAS MAY include the User-to-User header f=
ield in responses to the


   initial INVITE request, or the BYE requests o=
r responses for the


  dialog, only where the original INVITE request=
 included a User-to-


   User header field with the "purpose"=
; header field parameter
set to "isdn-


   uui", or where no "purpose" he=
ader field parameter was included.


 


 


   When receiving UUI, when multiple User-to-Use=
r header fields are


   received from the originating user in the sam=
e request with the


   "purpose" header field parameter to=
 "isdn-uui", or with no "purpose"


   header field parameter, or with some combinat=
ion of these, the UAC


   MUST discard all these header fields. 



 


SHOULD BE


 


   When receiving UUI, when multiple User-to-Use=
r header fields are


   received from the originating user in the sam=
e request with the


   "purpose" header field parameter
set to "isdn-uui", or with no &q=
uot;purpose"


   header field parameter, or with some combinat=
ion of these, the UAC


   MUST discard all these header fields. 



 


Section 9


 


   A receiving


   SIP entity MUST ignore a received User-to-Use=
r header field if the


   "content" header field parameter is=
 present and the value is some


   other value that "isdn-uui".


 


SHOULD BE


 


   A receiving


   SIP entity MUST ignore a received User-to-Use=
r header field if the


   "content" header field parameter is=
 present and the value is some


   other value
than "isdn-uui".


 
---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_BBF5DDFE515C3946BC18D733B20DAD2338E677ABXMB104ADSrimnet_-- From vkg@bell-labs.com Thu Nov 21 09:25:34 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48641AE08D for ; Thu, 21 Nov 2013 09:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBhlbGAp0uwm for ; Thu, 21 Nov 2013 09:25:32 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E61AE087 for ; Thu, 21 Nov 2013 09:25:32 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rALHPN1W008781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Nov 2013 11:25:23 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rALHPMSs030881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Nov 2013 11:25:23 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rALHPMl3005045; Thu, 21 Nov 2013 11:25:22 -0600 (CST) Message-ID: <528E4204.8080304@bell-labs.com> Date: Thu, 21 Nov 2013 11:25:24 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andrew Allen , "bruno.chatras@orange.com" , "cuss@ietf.org" References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:25:34 -0000 [As individual, of course.] On 11/21/2013 09:31 AM, Andrew Allen wrote: > > I have some sympathy for Bruno's position. He is merely asking to > align with the principle of "Be strict in what you send, but generous > in what you receive". I must say that I disagree. I suspect that Postel's Law was not designed to allow multiple tokens to represent the same semantic. Plus, implementing Postel's Law to the n-th degree leads to brittle parsers and easy to attack systems. There is a school of thought that parsers for large and complex grammars like SIP should be designed using a language-theoretic approach since these grammars produce essentially a complex language. Such complex grammars are PSPACE-complete, making it daunting to come up with a bullet-proof parser if we keep on adding multiple ways to represent similar concepts. But regardless, I don't mean to hammer on this. If folks feel that we need to grandfather "isdn-network", that is fine with me. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From aallen@blackberry.com Thu Nov 21 09:40:31 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7EC1AE091 for ; Thu, 21 Nov 2013 09:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySIu9CQP5aQi for ; Thu, 21 Nov 2013 09:40:29 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F41AE061 for ; Thu, 21 Nov 2013 09:40:28 -0800 (PST) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 Nov 2013 12:40:18 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 11:40:17 -0600 From: Andrew Allen To: "Vijay K. Gurbani" , "bruno.chatras@orange.com" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT1dpjYGndAPU2F8sy5W0sV45ouyA4AgAEOYICAAI1wAP//nhIA Date: Thu, 21 Nov 2013 17:40:17 +0000 Message-ID: References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> In-Reply-To: <528E4204.8080304@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:40:31 -0000 Vijay I don't think we are talking about applying this to the nth degree I think = we are simply recognizing that in this case there are deployed systems out = there that we ought to attempt to interoperate with if that can relatively = easily be achieved.. I am not sure it complicates the parser greatly to have two possible tokens= (A or B) as the value of a parameter and then in the call processing logic= have an if A or B statement. Andrew -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] = Sent: Thursday, November 21, 2013 12:25 PM To: Andrew Allen; bruno.chatras@orange.com; cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" [As individual, of course.] On 11/21/2013 09:31 AM, Andrew Allen wrote: > > I have some sympathy for Bruno's position. He is merely asking to = > align with the principle of "Be strict in what you send, but generous = > in what you receive". I must say that I disagree. I suspect that Postel's Law was not designed t= o allow multiple tokens to represent the same semantic. Plus, implementing Postel's Law to the n-th degree leads to brittle parsers= and easy to attack systems. There is a school of thought that parsers for large and complex grammars li= ke SIP should be designed using a language-theoretic approach since these g= rammars produce essentially a complex language. Such complex grammars are = PSPACE-complete, making it daunting to come up with a bullet-proof parser i= f we keep on adding multiple ways to represent similar concepts. But regardless, I don't mean to hammer on this. If folks feel that we need= to grandfather "isdn-network", that is fine with me. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Thu Nov 21 10:39:37 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA741AE03D for ; Thu, 21 Nov 2013 10:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sczImULTpIB for ; Thu, 21 Nov 2013 10:39:35 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 420181ADFEF for ; Thu, 21 Nov 2013 10:39:35 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id sDen1m0031ZXKqc54JfUY6; Thu, 21 Nov 2013 18:39:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id sJfU1m00B3ZTu2S3hJfUfY; Thu, 21 Nov 2013 18:39:28 +0000 Message-ID: <528E5360.2010004@alum.mit.edu> Date: Thu, 21 Nov 2013 10:39:28 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: cuss@ietf.org References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385059168; bh=55LC8TewEzkwYMj+IHc1nPQy8WA1rqfYtUEpkygjMl0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KvlvaaxFwnyx7Ao45xr0dF1uzr78G78WsfQKFfMHIl5DCh02c9IX+tlflTMFpR4B+ 7JDT+uxo08L/JldB2ipDpFCyMup51ByvNGEG+tMQW8EazFZQbPgcdl9aNCKC1g9eA+ QgYIJKed8ew097YkYUehN99g1D6U4Q4wTjazhVhPcmSWmpHmlfhYh0LnmPA1WBdtmA 9TNmRafxPmlAa+l15rHWsIkDosIuYdG2yh0/w/61MhdPrYr9aiHzspPlxQIZA7jbgV VF1D5hEWpHF5j85r3WJwggFngMoIQZNdHjaXpJE8ixCkYFUy+4ZLNYURlwHTGvBpKo ciwHVmL8aQCdA== Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:39:37 -0000 I don't care enough to take a position either way. Thanks, Paul On 11/21/13 9:40 AM, Andrew Allen wrote: > Vijay > > I don't think we are talking about applying this to the nth degree I think we are simply recognizing that in this case there are deployed systems out there that we ought to attempt to interoperate with if that can relatively easily be achieved.. > > I am not sure it complicates the parser greatly to have two possible tokens (A or B) as the value of a parameter and then in the call processing logic have an if A or B statement. > > Andrew > > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Sent: Thursday, November 21, 2013 12:25 PM > To: Andrew Allen; bruno.chatras@orange.com; cuss@ietf.org > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" > > [As individual, of course.] > > On 11/21/2013 09:31 AM, Andrew Allen wrote: >> >> I have some sympathy for Bruno's position. He is merely asking to >> align with the principle of "Be strict in what you send, but generous >> in what you receive". > > I must say that I disagree. I suspect that Postel's Law was not designed to allow multiple tokens to represent the same semantic. > Plus, implementing Postel's Law to the n-th degree leads to brittle parsers and easy to attack systems. > > There is a school of thought that parsers for large and complex grammars like SIP should be designed using a language-theoretic approach since these grammars produce essentially a complex language. Such complex grammars are PSPACE-complete, making it daunting to come up with a bullet-proof parser if we keep on adding multiple ways to represent similar concepts. > > But regardless, I don't mean to hammer on this. If folks feel that we need to grandfather "isdn-network", that is fine with me. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From vkg@bell-labs.com Thu Nov 21 11:01:06 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A9E1AE265 for ; Thu, 21 Nov 2013 11:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLA8xtDno_if for ; Thu, 21 Nov 2013 11:01:04 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4DF1AE262 for ; Thu, 21 Nov 2013 11:01:04 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rALJ0uFo025112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Nov 2013 13:00:56 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rALJ0un0026757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Nov 2013 13:00:56 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rALJ0tWs003651; Thu, 21 Nov 2013 13:00:56 -0600 (CST) Message-ID: <528E5869.7080905@bell-labs.com> Date: Thu, 21 Nov 2013 13:00:57 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andrew Allen , "bruno.chatras@orange.com" , "cuss@ietf.org" References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:01:06 -0000 On 11/21/2013 11:40 AM, Andrew Allen wrote: > Vijay > > I don't think we are talking about applying this to the nth degree I > think we are simply recognizing that in this case there are deployed > systems out there that we ought to attempt to interoperate with if > that can relatively easily be achieved.. > > I am not sure it complicates the parser greatly to have two possible > tokens (A or B) as the value of a parameter and then in the call > processing logic have an if A or B statement. Andrew: If you look at the SIP grammar, this obviously will not be the only header with multiple representations. We simply keep on adding to that list. Beyond that, I think discussing about this to a great degree will not lead us anywhere. I am interested in this issue from an academic point of view, but pragmatism says that we proceed further without delays. As an individual, I am happy to allow the draft to proceed with the alias defined (or not). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From vkg@bell-labs.com Thu Nov 21 11:55:26 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DCF1AE162 for ; Thu, 21 Nov 2013 11:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2w4p2-KJJ0S for ; Thu, 21 Nov 2013 11:55:23 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1B1AE131 for ; Thu, 21 Nov 2013 11:55:23 -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 rALJtGSA011666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Nov 2013 13:55:16 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rALJtFij008999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Nov 2013 13:55:15 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rALJtFmn026530 for ; Thu, 21 Nov 2013 13:55:15 -0600 (CST) Message-ID: <528E6525.80009@bell-labs.com> Date: Thu, 21 Nov 2013 13:55:17 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [cuss] WGLC commentsfor draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:55:26 -0000 [ As co-chair ] On 11/21/2013 09:31 AM, Andrew Allen wrote: > I have reviewed draft-ietf-cuss-sip-uui-isdn > > Here are some NITS [...] Andrew: Thank you for the review! Much appreciated. If there are others who have reviewed or have an opinion on how to proceed, please chime in. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From christer.holmberg@ericsson.com Thu Nov 21 15:52:06 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE681AE2DA for ; Thu, 21 Nov 2013 15:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9ReHPborfOv for ; Thu, 21 Nov 2013 15:52:03 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE2F21AE17F for ; Thu, 21 Nov 2013 15:52:02 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-e3-528e9c9b54a9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.28.27941.B9C9E825; Fri, 22 Nov 2013 00:51:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 22 Nov 2013 00:51:54 +0100 From: Christer Holmberg To: "Vijay K. Gurbani" , Andrew Allen , "bruno.chatras@orange.com" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wTzIOLVm0h/9UaRh+s6U64K8JouUrUAgAF8FQCAAB+7AIAABCiAgAAWioCAAF593IAAA5Ko Date: Thu, 21 Nov 2013 23:51:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C54CE65@ESESSMB209.ericsson.se> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> , <528E5869.7080905@bell-labs.com> In-Reply-To: <528E5869.7080905@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C54CE65ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvre7sOX1BBmeOiVvcn7eV0eL7xYfM FjfaXzBbNKyRc2Dx6Lvs4jGrYS27x5IlP5k8Wp6dZAtgieKySUnNySxLLdK3S+DKeP77IlPB b52KeVtmsjcwNqp1MXJySAiYSOz/sooVwhaTuHBvPVsXIxeHkMARRolPPW9YIJzFjBLPHz8G ynBwsAlYSHT/0waJiwisYZTYfn8LO0i3MNCkhi0rmEFsEQFTie6Wf2wQdpTEpLndYDaLgKrE 7s1PmEBsXgFfiZXrVjNBLHjDJHHq7FywZk4BXYkn71+BncQIdNL3U2vAGpgFxCVuPZnPBHGq gMSSPeeZIWxRiZeP/0G9oCjx8dU+Roj6fIk3m+8xQywTlDg58wnLBEaRWUhGzUJSNgtJGURc T+LG1ClsELa2xLKFr5khbF2JGf8OQdVYS3Tt+oqiZgEjxypGjuLU4qTcdCODTYzA6Du45bfF DsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgfHQ+eRn8lciHin3 /dgTppb+hKnXYk4dQ+NL76bUOXquKhl1z0tXxz1d/XfH+0N1+Tk9NxS2Ljl1/O8prpxeT/tw rXksOiphjoHze3VYvij2R3MvPcRh+OL2bYNUrYJ/9sbsAk/6ftwXSym6dfPX8p4L2hcDK8Wm 3y5UnBXzPXfP+qCM7B3fNimxFGckGmoxFxUnAgDKJ+jBjAIAAA== Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 23:52:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C54CE65ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Why did we change the value to begin with? Was the reason pure "cosmetic"? Anyway, whatever the reason, as the ABNF syntax for the purpose header fiel= d parameter value vis "token", a parser should be able to handle also "isdn= -network". Regards, Christer ________________________________ From: cuss [cuss-bounces@ietf.org] on behalf of Vijay K. Gurbani [vkg@bell-= labs.com] Sent: Thursday, 21 November 2013 9:00 PM To: Andrew Allen; bruno.chatras@orange.com; cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" On 11/21/2013 11:40 AM, Andrew Allen wrote: > Vijay > > I don't think we are talking about applying this to the nth degree I > think we are simply recognizing that in this case there are deployed > systems out there that we ought to attempt to interoperate with if > that can relatively easily be achieved.. > > I am not sure it complicates the parser greatly to have two possible > tokens (A or B) as the value of a parameter and then in the call > processing logic have an if A or B statement. Andrew: If you look at the SIP grammar, this obviously will not be the only header with multiple representations. We simply keep on adding to that list. Beyond that, I think discussing about this to a great degree will not lead us anywhere. I am interested in this issue from an academic point of view, but pragmatism says that we proceed further without delays. As an individual, I am happy to allow the draft to proceed with the alias defined (or not). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss --_000_7594FB04B1934943A5C02806D1A2204B1C54CE65ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

Why did we change the value to begin with? Was the reason pure &quo= t;cosmetic"?

 

Anyway, whatever the reason, as the ABNF syntax for the purpose hea= der field parameter value vis "token", a parser should be ab= le to handle also "isdn-network".

 

Regards,

 

Christer

 

 

From: cuss [cuss-bounces@ietf.org] on behalf of Vijay K. Gurbani= [vkg@bell-labs.com]
Sent: Thursday, 21 November 2013 9:00 PM
To: Andrew Allen; bruno.chatras@orange.com; cuss@ietf.org
Subject: Re: [cuss] "isdn-uui" versus "isdn-network&q= uot;

On 11/21/2013 11:40 AM, Andrew Allen wrote:
> Vijay
>
> I don't think we are talking about applying this to the nth degree I > think we are simply recognizing that in this case there are deployed > systems out there that we ought to attempt to interoperate with if
> that can relatively easily be achieved..
>
> I am not sure it complicates the parser greatly to have two possible > tokens (A or B) as the value of a parameter and then in the call
> processing logic have an if A or B statement.

Andrew: If you look at the SIP grammar, this obviously will not be the
only header with multiple representations.  We simply keep on adding to that list.

Beyond that, I think discussing about this to a great degree will not
lead us anywhere.  I am interested in this issue from an academic
point of view, but pragmatism says that we proceed further without
delays.

As an individual, I am happy to allow the draft to proceed with the
alias defined (or not).

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: http:/= /ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq _______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cuss
--_000_7594FB04B1934943A5C02806D1A2204B1C54CE65ESESSMB209erics_-- From atle.monrad@ericsson.com Fri Nov 22 10:36:30 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E441AE039 for ; Fri, 22 Nov 2013 10:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICK9lwoc4LnL for ; Fri, 22 Nov 2013 10:36:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2EE1AE009 for ; Fri, 22 Nov 2013 10:36:28 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-46-528fa4241b35 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A4.22.03802.424AF825; Fri, 22 Nov 2013 19:36:20 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.134]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 22 Nov 2013 19:36:19 +0100 From: Atle Monrad To: "Vijay K. Gurbani" , Andrew Allen , "bruno.chatras@orange.com" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO5t6p/rnx1aTdzE2fpUK6uaPrRZov4vqAgAAWioCAAZpLMA== Date: Fri, 22 Nov 2013 18:36:19 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> In-Reply-To: <528E5869.7080905@bell-labs.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvra7Kkv4gg739Shb3521ltPh+8SGz xY32F8wWDWvkHFg8+i67eMxqWMvusWTJTyaPlmcn2QJYorhsUlJzMstSi/TtErgyzhzvZyno FqyYsPInawPjF94uRk4OCQETie4d85ggbDGJC/fWs3UxcnEICRxilJiz+SaUs4RRYsHRG2BV bAI6Eud+3mEFSYgIrGGU2H5/CztIQhhoVMOWFcwgtoiAqUR3yz+gbg4g20ni/K9KkDCLgKrE 1sUnWUFsXgFviTf9v1kgFrxjkph47SPYAk4BXYkn71+xgvQyCshKzG0Cu5RZQFzi1pP5UJcK SCzZc54ZwhaVePn4HyuErSSx9vB2Foh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIyd haRlFpKWWUhaFjCyrGJkz03MzEkvN9rECIyYg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYt4jMlDp+ef1z7W3Fx3qaJyxfEKJ/r/PL581mf3l6fftl JL4uCtacdqTu36uJp/5N2Otmlx+yXmSP9+P79XzF0VuDv0RZc3yZd/eErxur+I2o4ycsZOqT /4iafmI7cjfxkdpjnc9BX9KlRGcc9mnedrCudemzlntx+4UTkwWkp/dlZvdZRf/RVGIpzkg0 1GIuKk4EAM4fk8lmAgAA Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:36:31 -0000 Hi I guess each of the "shall we allow multiple representations" needs to be h= andled on a case-by-case basis, but generally speaking I understand that th= e chairs and ADs aren't too enthusiastic with too many ... What 3GPP really wants for Christmas is the draft to be completed. Somebody= must take a decision on this soon. cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: 21. november 2013 20:01 To: Andrew Allen; bruno.chatras@orange.com; cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" On 11/21/2013 11:40 AM, Andrew Allen wrote: > Vijay > > I don't think we are talking about applying this to the nth degree I=20 > think we are simply recognizing that in this case there are deployed=20 > systems out there that we ought to attempt to interoperate with if=20 > that can relatively easily be achieved.. > > I am not sure it complicates the parser greatly to have two possible=20 > tokens (A or B) as the value of a parameter and then in the call=20 > processing logic have an if A or B statement. Andrew: If you look at the SIP grammar, this obviously will not be the only= header with multiple representations. We simply keep on adding to that li= st. Beyond that, I think discussing about this to a great degree will not lead = us anywhere. I am interested in this issue from an academic point of view,= but pragmatism says that we proceed further without delays. As an individual, I am happy to allow the draft to proceed with the alias d= efined (or not). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Fri Nov 22 10:56:31 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12D1AE21E for ; Fri, 22 Nov 2013 10:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNq1YbjlTR0A for ; Fri, 22 Nov 2013 10:56:29 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EC4031AE19B for ; Fri, 22 Nov 2013 10:56:28 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAMIuLt0024018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Nov 2013 12:56:21 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rAMIuL1B022047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 22 Nov 2013 12:56:21 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rAMIuKeH022368 for ; Fri, 22 Nov 2013 12:56:21 -0600 (CST) Message-ID: <528FA8D6.8050301@bell-labs.com> Date: Fri, 22 Nov 2013 12:56:22 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "cuss@ietf.org" References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:56:31 -0000 On 11/22/2013 12:36 PM, Atle Monrad wrote: > Hi > > I guess each of the "shall we allow multiple representations" needs > to be handled on a case-by-case basis, but generally speaking I > understand that the chairs and ADs aren't too enthusiastic with too > many ... > > What 3GPP really wants for Christmas is the draft to be completed. > Somebody must take a decision on this soon. ... which means that by Nov 29, 2013 it'd be nice to hear from others who have an opinion. Many thanks to those who have already expressed one. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From atle.monrad@ericsson.com Fri Nov 22 11:04:28 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878C11AE1E6 for ; Fri, 22 Nov 2013 11:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYjHs2xxe8mm for ; Fri, 22 Nov 2013 11:04:26 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 103CC1ADF7C for ; Fri, 22 Nov 2013 11:04:25 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-b8-528faab1573d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 01.54.15980.1BAAF825; Fri, 22 Nov 2013 20:04:17 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.134]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Fri, 22 Nov 2013 20:04:17 +0100 From: Atle Monrad To: "Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQjqvmSckbl8USYrsZxBrS5apoxok3A Date: Fri, 22 Nov 2013 19:04:15 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C209216@ESESSMB203.ericsson.se> References: <5283CECB.8050804@bell-labs.com> In-Reply-To: <5283CECB.8050804@bell-labs.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre7GVf1BBp826VvcaH/BbNGwRs6B yaPvsovHkiU/mQKYorhsUlJzMstSi/TtErgyNnxYy1bQrVKxa+UalgbG99JdjJwcEgImEp0X ZzBB2GISF+6tZ+ti5OIQEjjEKHGm+zUzhLOEUeLlgQfsIFVsAjoS537eYQWxRQS8JaY+/Q9m CwtYSsw7+JQFIm4l8ezOKyYI20jiyIYpYL0sAqoSR29OZQOxeYF6H3+bwwxiCwHNPPBhGVgv p4CuxLqP34BsDg5GAVmJuU28IGFmAXGJW0/mQx0qILFkz3lmCFtU4uXjf6wQtpLE2sPbWSDq dSQW7P7EBmFrSyxb+JoZYq2gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye93HwT IzAODm75bbCDcdN9sUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgFFVY 80GmZH/aessVv6qUjrBpxa1wm8A77Yj3FRtBkQ75CK1/d3f/n1/hyJEV4lSmFLf5oujnLrcL 1kLKPaYXb30KsJqYxmStNeeA+J7Iwu7Lb5LD9tv+MjZ8I8VUx3Z5zt7zJ1cwLXNvTG/0EY4y U59z++PDE+rXQpdLhEsJHF2atKqptXq3EktxRqKhFnNRcSIAvR4p0FECAAA= Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:04:28 -0000 G'day I have reviewed the draft again and have a couple of nits. 1. Abstract The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. Remove space: this ISDN service for end-to-end transparency. 2. 3.2. Impacts of the ISDN service on SIP operation The ISDN service has the following impacts that need to be understood within the SIP environment. Call transfer ISDN call transfer cancels all user-to-user supplementary services. In the ISDN, if user-to-user data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred. Conference ISDN conferencing allows the user to still exchange user- to-user data after the conference is created. As far as UUS1 is concerned, it is not permitted. The ISDN three-party supplementary service is similar in many ways to conferencing, but is signalled using a different mechanism. This means that on clearing, the controller using UUS1 implicit does have the choice of sending data to either or both remote users. Because SIP conferencing cannot completely emulate the ISDN three-party supplementary service at the served user, UUS1 implicit is not possible. Diversion When ISDN diversion occurs, any UUS1 user-to-user data is sent to the forwarded-to-user (assuming that the call meets requirements for providing the service - this is impacted by the explicit service only). If the type of diversion is such that the call is also delivered to the forwarding user, they will also receive any UUS1 user-to-user data. Would it make sense to add some NLs and/or :s after the three "ISDN SSs" to= split the text and improve readability?? e.g. like Call transfer: ISDN call transfer cancels all user-to-user supplementary services. In the ISDN, if user-to-user data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred. Or Call transfer: ISDN call transfer cancels all user-to-user supplementary services. In the ISDN, if user-to-user data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred. ---- I hope the draft can progress soon Cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vij= ay K. Gurbani Sent: 13. november 2013 20:11 To: cuss@ietf.org Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Folks: Enrico and I will like to announce a WGLC for the ISDN draft [1]. The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. We will appreciate your comments on the draft, posted to the list. All com= ments are appreciated, even if it is a simple one-liner saying that you bel= ieve the draft is ready, or conversely, that it is not ready (and why). As you review the draft, as part of your WGLC review, please identify any i= ssues that may exist in regard to compatibility with draft-ietf-cuss-uui (t= he mechanism draft). Thank you. [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ Vijay K. Gurbani and Enrico Marocco _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From christer.holmberg@ericsson.com Sat Nov 23 06:21:37 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB31AE111 for ; Sat, 23 Nov 2013 06:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C5cb4F4Tx3Q for ; Sat, 23 Nov 2013 06:21:35 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0191AE0AC for ; Sat, 23 Nov 2013 06:21:35 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-2e-5290b9e729e8 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BF.24.23787.7E9B0925; Sat, 23 Nov 2013 15:21:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Sat, 23 Nov 2013 15:21:26 +0100 From: Christer Holmberg To: "Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wTzIOLVm0h/9UaRh+s6U64K8JouUrUAgAF8FQCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgAFUYgKAAAHmAg== Date: Sat, 23 Nov 2013 14:21:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5530C3@ESESSMB209.ericsson.se> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se>, <528FA8D6.8050301@bell-labs.com> In-Reply-To: <528FA8D6.8050301@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5530C3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre7znROCDPa1SVrcaH/BbNGwRs6B yaPvsovHkiU/mQKYorhsUlJzMstSi/TtErgyps/9wlLwV6Fi1t35bA2Mp6W7GDk5JARMJP5f XMUMYYtJXLi3nq2LkYtDSOAQo8TBpt1MEM5iRolpn/qAqjg42AQsJLr/aYM0iAh4S0x9+p8V xBYGGtSwZQUzRNxUorvlHxuEnSWx79EPdhCbRUBV4tnuF2A1vAK+EgsvzIeaf5FZ4sepNrBB nAK6ElevNYMVMQJd9P3UGiYQm1lAXOLWk/lMEJcKSCzZcx7qalGJl4//sYLcJiGgJDFtaxpE eb5E/7SljBC7BCVOznzCMoFRZBaSSbOQlM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/Q1A1 1hK/HyxkRFazgJFjFSN7bmJmTnq54SZGYDwd3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cA4eYpZ3V1v63VNvLynnewOKdzWCfp4T3GylHVPsf4FQ2c1 u93xXlUXo+qDdt1rFjrn/LrFgdfxUMI9ORWOz7usr8wIqn84p/TOGl8DHtFT1hY/Nt29JpUS f3wmj1pQ94z1BY4t74JObXoWY/VTzf2EsHecWZueX+xP+9e1ZbWMej1mzlsOaSuxFGckGmox FxUnAgC+AT2zdQIAAA== Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 14:21:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5530C3ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I already gave some comments, but in case the outcome was clear: I think we= should move the draft forward. Existing entities that implement the old value will anyway have to be updat= ed to support the new value. And, if new entities will have to support the = old value, I am sure the buyer will inform the vendor about that :) Regards, Christer From: cuss [cuss-bounces@ietf.org] on behalf of Vijay K. Gurbani [vkg@bell-= labs.com] Sent: Friday, 22 November 2013 8:56 PM To: cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" On 11/22/2013 12:36 PM, Atle Monrad wrote: > Hi > > I guess each of the "shall we allow multiple representations" needs > to be handled on a case-by-case basis, but generally speaking I > understand that the chairs and ADs aren't too enthusiastic with too > many ... > > What 3GPP really wants for Christmas is the draft to be completed. > Somebody must take a decision on this soon. ... which means that by Nov 29, 2013 it'd be nice to hear from others who have an opinion. Many thanks to those who have already expressed one. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss --_000_7594FB04B1934943A5C02806D1A2204B1C5530C3ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <26A5BA51AC2DD24699D8AA93CFA6DAD5@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi,

I already gave some comments, but in case the outcome was clear: I think we= should move the draft forward.

Existing entities that implement the old value will anyway have to be updat= ed to support the new value. And, if new entities will have to support the = old value, I am sure the buyer will inform the vendor about that :)

Regards,

Christer






From: cuss [cuss-bounces@ietf.org] on behalf of Vijay K. Gurbani [vkg@bell-= labs.com]
Sent: Friday, 22 November 2013 8:56 PM
To: cuss@ietf.org
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

On 11/22/2013 12:36 PM, Atle Monrad wrote:
> Hi
>
> I guess each of the "shall we allow multiple representations"= ; needs
> to be handled on a case-by-case basis, but generally speaking I
> understand that the chairs and ADs aren't too enthusiastic with too > many ...
>
> What 3GPP really wants for Christmas is the draft to be completed.
> Somebody must take a decision on this soon.

... which means that by Nov 29, 2013 it'd be nice to hear from others
who have an opinion.

Many thanks to those who have already expressed one.

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Og= q
_______________________________________________
cuss mailing list
cuss@ietf.org
https://www.ietf.org/mailman/listinfo/cuss --_000_7594FB04B1934943A5C02806D1A2204B1C5530C3ESESSMB209erics_-- From bruno.chatras@orange.com Mon Nov 25 00:18:00 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A6C1AC828 for ; Mon, 25 Nov 2013 00:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynp6DsidN83Z for ; Mon, 25 Nov 2013 00:17:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 25D5A1AC7F0 for ; Mon, 25 Nov 2013 00:17:55 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 28C4222C3BE; Mon, 25 Nov 2013 09:17:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0900F27C084; Mon, 25 Nov 2013 09:17:55 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 09:17:54 +0100 From: To: Christer Holmberg , "Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT0/rnx1aTdzE2fpUK6uaPrRZouX5ewgAFvMwCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgAFFg4CAAs41sA== Date: Mon, 25 Nov 2013 08:17:53 +0000 Message-ID: <5709_1385367475_529307B3_5709_6097_1_88CAD1D4E8773F42858B58CAA28272A0112DA65E@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se>, <528FA8D6.8050301@bell-labs.com> <7594FB04B1934943A5C02806D1A2204B1C5530C3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5530C3@ESESSMB209.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A0112DA65EPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.24.105114 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 08:18:00 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A0112DA65EPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are many use cases where the calling device sends UUI to a call cente= r but is not expecting any. Such devices (or associated interworking units)= would not have to be updated to support the new value. BC De : cuss [mailto:cuss-bounces@ietf.org] De la part de Christer Holmberg Envoy=E9 : samedi 23 novembre 2013 15:21 =C0 : Vijay K. Gurbani; cuss@ietf.org Objet : Re: [cuss] "isdn-uui" versus "isdn-network" Hi, I already gave some comments, but in case the outcome was clear: I think we= should move the draft forward. Existing entities that implement the old value will anyway have to be updat= ed to support the new value. And, if new entities will have to support the = old value, I am sure the buyer will inform the vendor about that :) Regards, Christer From: cuss [cuss-bounces@ietf.org] on behalf of Vijay K. Gurbani [vkg@bell-= labs.com] Sent: Friday, 22 November 2013 8:56 PM To: cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" On 11/22/2013 12:36 PM, Atle Monrad wrote: > Hi > > I guess each of the "shall we allow multiple representations" needs > to be handled on a case-by-case basis, but generally speaking I > understand that the chairs and ADs aren't too enthusiastic with too > many ... > > What 3GPP really wants for Christmas is the draft to be completed. > Somebody must take a decision on this soon. ... which means that by Nov 29, 2013 it'd be nice to hear from others who have an opinion. Many thanks to those who have already expressed one. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} = / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88CAD1D4E8773F42858B58CAA28272A0112DA65EPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There are = many use cases where the calling device sends UUI to a call center but is n= ot expecting any. Such devices (or associated interworking units) would not have to be updated to support the new value.

 = ;

BC

 = ;

 = ;

De : cuss= [mailto:cuss-bounces@ietf.org] De la part de Christer Holmberg
Envoy=E9 : samedi 23 novembre 2013 15:21
=C0 : Vijay K. Gurbani; cuss@ietf.org
Objet : Re: [cuss] "isdn-uui" versus "isdn-netwo= rk"

 

Hi,

I already gave some comments, but in case the outcome was clear: I think we= should move the draft forward.

Existing entities that implement the old value will anyway have to be updat= ed to support the new value. And, if new entities will have to support the = old value, I am sure the buyer will inform the vendor about that :)

Regards,

Christer






From: cuss [cuss-bounces@ietf.org] on behalf of Vijay K. Gurbani [vkg@bell-= labs.com]
Sent: Friday, 22 November 2013 8:56 PM
To: cuss@ietf.org
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"


On 11/22/2013 12:36 PM, Atle Monrad wrote:
> Hi
>
> I guess each of the "shall we allow multiple representations"= ; needs
> to be handled on a case-by-case basis, but generally speaking I
> understand that the chairs and ADs aren't too enthusiastic with too
> many ...
>
> What 3GPP really wants for Christmas is the draft to be completed.
> Somebody must take a decision on this soon.

... which means that by Nov 29, 2013 it'd be nice to hear from others
who have an opinion.

Many thanks to those who have already expressed one.

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.co= m,acm.org} / vijay.gurbani@alcatel-l= ucent.com
Web: http://ect.bell-labs.com= /who/vkg/  | Calendar: http://goo.gl/x3Ogq
_______________________________________________
cuss mailing list
cuss@ietf.org
https://www.ietf.org= /mailman/listinfo/cuss 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88CAD1D4E8773F42858B58CAA28272A0112DA65EPEXCVZYM12corpo_-- From thomas.belling@nsn.com Mon Nov 25 03:34:44 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5101AD8E3 for ; Mon, 25 Nov 2013 03:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5xyclE4oO2a for ; Mon, 25 Nov 2013 03:34:42 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 987771ACCFC for ; Mon, 25 Nov 2013 03:34:41 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAPBYccE009233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Nov 2013 12:34:38 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAPBYbaS000320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 12:34:37 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 25 Nov 2013 12:34:37 +0100 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.156]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 12:34:37 +0100 From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT0/rnx1aTdzE2fpUK6uaPrRZouX5ewgAFvMwCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgARJUDA= Date: Mon, 25 Nov 2013 11:34:35 +0000 Message-ID: References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> <528FA8D6.8050301@bell-labs.com> In-Reply-To: <528FA8D6.8050301@bell-labs.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2034 X-purgate-ID: 151667::1385379278-00006154-EAB8784B/0-0/0-0 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 11:34:45 -0000 For me, it is also quite important to finalize the work. I have a certain sympathy for considering backward compatibility, as I unde= rstand that the concerns relate to real deployments and seem of interest to= make things work in reality. I thus support related wording in the draft. I understand the point that drafts should be regarded as experimental and s= ubject to change. However, this is only fine if features demanded in the ma= rket are finalized within a reasonable time. If work goes on for about five= years (as in the current case), backward compatibility will become a real = concern no matter if purists like it. The main takeaway could be to aim to = finalize work in a reasonable amount of time. BR, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation NSN -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of ext Vijay K. Gurbani Sent: Friday, November 22, 2013 7:56 PM To: cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" On 11/22/2013 12:36 PM, Atle Monrad wrote: > Hi > > I guess each of the "shall we allow multiple representations" needs to=20 > be handled on a case-by-case basis, but generally speaking I=20 > understand that the chairs and ADs aren't too enthusiastic with too=20 > many ... > > What 3GPP really wants for Christmas is the draft to be completed. > Somebody must take a decision on this soon. ... which means that by Nov 29, 2013 it'd be nice to hear from others who h= ave an opinion. Many thanks to those who have already expressed one. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Tue Nov 26 18:13:48 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348771AE074 for ; Tue, 26 Nov 2013 18:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uo8sLdll8Yx for ; Tue, 26 Nov 2013 18:13:45 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4946C1AE061 for ; Tue, 26 Nov 2013 18:13:44 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rAR2DgaN024059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Nov 2013 20:13:43 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAR2DfYf004557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 03:13:41 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 27 Nov 2013 03:13:41 +0100 From: "DRAGE, Keith (Keith)" To: "Belling, Thomas (NSN - DE/Munich)" , "Gurbani, Vijay K (Vijay)" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT0/rnx1aTdzE2fpUK6uaPrRZouX5ewgAFvMwCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgARJUDCAAoh2sA== Date: Wed, 27 Nov 2013 02:13:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0EE102@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> <528FA8D6.8050301@bell-labs.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 02:13:48 -0000 I have indicated right at the start of one of the original calls that I wou= ld prefer not to make any addition in this area. But putting that aside for= the moment. In the hallway discussion, I tried to get clarification as to what the chan= ge should mean, because I have had several inconstent answers to this in th= e past. This basically falls into two issues: 1) Whether the change was a note (i.e. normative) or informative. My unders= tanding of Bruno's postion was that it should be normative, which means ess= entially that all implementations recognise the value when it is received. = However conformant implementations only generate the correct value. It appe= ars however other people were not aware that the change was intended to be = normative, based on your continued representation of this as a "NOTE". 2) If the change was normative, then presumably the new value should be IAN= A registered. It was apparently this that caused people to say that they di= d not want a normative change (which I guess would lead to the impression t= hat the usage was sanctioned for the future), and subsequently that did not= see the point of an informative change. In response to Christer, when writing the draft, we chose a label that was = consistent with the usage it was to be put, which was not to be constrained= to interworking with the ISDN, but rather one that provided the equivalent= capabilities. We were not aware that we were constrained by examples showi= ng other values in previous drafts; indeed we did not even look at some of = those older versions in this respect - at the time this was a new document = with a clean field. Regards Keith > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of=20 > Belling, Thomas (NSN - DE/Munich) > Sent: 25 November 2013 11:35 > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > For me, it is also quite important to finalize the work. >=20 > I have a certain sympathy for considering backward=20 > compatibility, as I understand that the concerns relate to=20 > real deployments and seem of interest to make things work in=20 > reality. I thus support related wording in the draft. >=20 > I understand the point that drafts should be regarded as=20 > experimental and subject to change. However, this is only=20 > fine if features demanded in the market are finalized within=20 > a reasonable time. If work goes on for about five years (as=20 > in the current case), backward compatibility will become a=20 > real concern no matter if purists like it. The main takeaway=20 > could be to aim to finalize work in a reasonable amount of time. >=20 > BR, Thomas >=20 >=20 > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > NSN >=20 >=20 >=20 > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of ext=20 > Vijay K. Gurbani > Sent: Friday, November 22, 2013 7:56 PM > To: cuss@ietf.org > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > On 11/22/2013 12:36 PM, Atle Monrad wrote: > > Hi > > > > I guess each of the "shall we allow multiple=20 > representations" needs to=20 > > be handled on a case-by-case basis, but generally speaking I=20 > > understand that the chairs and ADs aren't too enthusiastic with too=20 > > many ... > > > > What 3GPP really wants for Christmas is the draft to be completed. > > Somebody must take a decision on this soon. >=20 > ... which means that by Nov 29, 2013 it'd be nice to hear=20 > from others who have an opinion. >=20 > Many thanks to those who have already expressed one. >=20 > Cheers, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar:=20 > http://goo.gl/x3Ogq _______________________________________________ > 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 R.Jesske@telekom.de Tue Nov 26 23:17:42 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E446F1AE22C for ; Tue, 26 Nov 2013 23:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RojGvhIuwobE for ; Tue, 26 Nov 2013 23:17:36 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 427C71AE17C for ; Tue, 26 Nov 2013 23:17:33 -0800 (PST) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 27 Nov 2013 08:17:31 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 27 Nov 2013 08:17:29 +0100 From: To: , , , Date: Wed, 27 Nov 2013 08:17:28 +0100 Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT0/rnx1aTdzE2fpUK6uaPrRZouX5ewgAFvMwCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgARJUDCAAoh2sIAAVKhA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB76B3A5@HE113667.emea1.cds.t-internal.com> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> <528FA8D6.8050301@bell-labs.com> <949EF20990823C4C85C18D59AA11AD8B0EE102@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0EE102@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 07:17:43 -0000 Dear all, I had no problems in adding a note since such Note has more a guideline fun= ction which can be taken into consideration based on bilateral agreements a= nd local policy.=20 BUT I have problems with the whole discussion about making the "isdn-interworki= ng" now as a normative and mandatory alias or additional element which has = now to be understood by all interworking points. We have implemented 3GPP TS 29.163 which bases on the latest IETF draft. An= d this document never stated the "isdn-interworking" has to be used for int= erworking.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von DRAGE, Keith (Keith= ) Gesendet: Mittwoch, 27. November 2013 03:14 An: Belling, Thomas (NSN - DE/Munich); Gurbani, Vijay K (Vijay); cuss@ietf.= org Betreff: Re: [cuss] "isdn-uui" versus "isdn-network" I have indicated right at the start of one of the original calls that I wou= ld prefer not to make any addition in this area. But putting that aside for= the moment. In the hallway discussion, I tried to get clarification as to what the chan= ge should mean, because I have had several inconstent answers to this in th= e past. This basically falls into two issues: 1) Whether the change was a note (i.e. normative) or informative. My unders= tanding of Bruno's postion was that it should be normative, which means ess= entially that all implementations recognise the value when it is received. = However conformant implementations only generate the correct value. It appe= ars however other people were not aware that the change was intended to be = normative, based on your continued representation of this as a "NOTE". 2) If the change was normative, then presumably the new value should be IAN= A registered. It was apparently this that caused people to say that they di= d not want a normative change (which I guess would lead to the impression t= hat the usage was sanctioned for the future), and subsequently that did not= see the point of an informative change. In response to Christer, when writing the draft, we chose a label that was = consistent with the usage it was to be put, which was not to be constrained= to interworking with the ISDN, but rather one that provided the equivalent= capabilities. We were not aware that we were constrained by examples showi= ng other values in previous drafts; indeed we did not even look at some of = those older versions in this respect - at the time this was a new document = with a clean field. Regards Keith > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Belling, Thomas=20 > (NSN - DE/Munich) > Sent: 25 November 2013 11:35 > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > For me, it is also quite important to finalize the work. >=20 > I have a certain sympathy for considering backward compatibility, as I=20 > understand that the concerns relate to real deployments and seem of=20 > interest to make things work in reality. I thus support related=20 > wording in the draft. >=20 > I understand the point that drafts should be regarded as experimental=20 > and subject to change. However, this is only fine if features demanded=20 > in the market are finalized within a reasonable time. If work goes on=20 > for about five years (as in the current case), backward compatibility=20 > will become a real concern no matter if purists like it. The main=20 > takeaway could be to aim to finalize work in a reasonable amount of=20 > time. >=20 > BR, Thomas >=20 >=20 > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > NSN >=20 >=20 >=20 > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of ext Vijay K.=20 > Gurbani > Sent: Friday, November 22, 2013 7:56 PM > To: cuss@ietf.org > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > On 11/22/2013 12:36 PM, Atle Monrad wrote: > > Hi > > > > I guess each of the "shall we allow multiple > representations" needs to > > be handled on a case-by-case basis, but generally speaking I=20 > > understand that the chairs and ADs aren't too enthusiastic with too=20 > > many ... > > > > What 3GPP really wants for Christmas is the draft to be completed. > > Somebody must take a decision on this soon. >=20 > ... which means that by Nov 29, 2013 it'd be nice to hear from others=20 > who have an opinion. >=20 > Many thanks to those who have already expressed one. >=20 > Cheers, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane,=20 > Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar:=20 > http://goo.gl/x3Ogq _______________________________________________ > 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 >=20 _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From bruno.chatras@orange.com Wed Nov 27 00:37:37 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0111AE190 for ; Wed, 27 Nov 2013 00:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npVznJo0hinl for ; Wed, 27 Nov 2013 00:37:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 200531AC7F2 for ; Wed, 27 Nov 2013 00:37:29 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C970618C33E; Wed, 27 Nov 2013 09:37:28 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A8890238088; Wed, 27 Nov 2013 09:37:28 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 09:37:28 +0100 From: To: "R.Jesske@telekom.de" , "keith.drage@alcatel-lucent.com" , "thomas.belling@nsn.com" , "vijay.gurbani@alcatel-lucent.com" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO3wT0/rnx1aTdzE2fpUK6uaPrRZouX5ewgAFvMwCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgARJUDCAAoh2sIAAVKhAgAAYAcA= Date: Wed, 27 Nov 2013 08:37:28 +0000 Message-ID: <24886_1385541448_5295AF48_24886_7243_1_88CAD1D4E8773F42858B58CAA28272A0112DFB50@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> <528FA8D6.8050301@bell-labs.com> <949EF20990823C4C85C18D59AA11AD8B0EE102@FR712WXCHMBA11.zeu.alcatel-lucent.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB76B3A5@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB76B3A5@HE113667.emea1.cds.t-internal.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.26.162714 Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 08:37:38 -0000 What matters is not whether we call it "normative" or not but the keyword u= sed in the proposed text. The latest proposed wording was using "RECOMMENDE= D" and most people were happy with this before the "hallway conversation".= =20 http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html > -----Message d'origine----- > De=A0: cuss [mailto:cuss-bounces@ietf.org] De la part de R.Jesske@telekom= .de > Envoy=E9=A0: mercredi 27 novembre 2013 08:17 > =C0=A0: keith.drage@alcatel-lucent.com; thomas.belling@nsn.com; > vijay.gurbani@alcatel-lucent.com; cuss@ietf.org > Objet=A0: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > Dear all, > I had no problems in adding a note since such Note has more a guideline > function which can be taken into consideration based on bilateral agreeme= nts > and local policy. > BUT > I have problems with the whole discussion about making the "isdn- > interworking" now as a normative and mandatory alias or additional element > which has now to be understood by all interworking points. >=20 > We have implemented 3GPP TS 29.163 which bases on the latest IETF draft. = And > this document never stated the "isdn-interworking" has to be used for > interworking. >=20 >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von DRAGE, Keith (Kei= th) > Gesendet: Mittwoch, 27. November 2013 03:14 > An: Belling, Thomas (NSN - DE/Munich); Gurbani, Vijay K (Vijay); > cuss@ietf.org > Betreff: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > I have indicated right at the start of one of the original calls that I > would prefer not to make any addition in this area. But putting that aside > for the moment. >=20 > In the hallway discussion, I tried to get clarification as to what the > change should mean, because I have had several inconstent answers to this= in > the past. This basically falls into two issues: >=20 > 1) Whether the change was a note (i.e. normative) or informative. My > understanding of Bruno's postion was that it should be normative, which > means essentially that all implementations recognise the value when it is > received. However conformant implementations only generate the correct va= lue. > It appears however other people were not aware that the change was intend= ed > to be normative, based on your continued representation of this as a "NOT= E". >=20 > 2) If the change was normative, then presumably the new value should be > IANA registered. It was apparently this that caused people to say that th= ey > did not want a normative change (which I guess would lead to the impressi= on > that the usage was sanctioned for the future), and subsequently that did = not > see the point of an informative change. >=20 > In response to Christer, when writing the draft, we chose a label that was > consistent with the usage it was to be put, which was not to be constrain= ed > to interworking with the ISDN, but rather one that provided the equivalent > capabilities. We were not aware that we were constrained by examples show= ing > other values in previous drafts; indeed we did not even look at some of > those older versions in this respect - at the time this was a new document > with a clean field. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Belling, Thomas > > (NSN - DE/Munich) > > Sent: 25 November 2013 11:35 > > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" > > > > For me, it is also quite important to finalize the work. > > > > I have a certain sympathy for considering backward compatibility, as I > > understand that the concerns relate to real deployments and seem of > > interest to make things work in reality. I thus support related > > wording in the draft. > > > > I understand the point that drafts should be regarded as experimental > > and subject to change. However, this is only fine if features demanded > > in the market are finalized within a reasonable time. If work goes on > > for about five years (as in the current case), backward compatibility > > will become a real concern no matter if purists like it. The main > > takeaway could be to aim to finalize work in a reasonable amount of > > time. > > > > BR, Thomas > > > > > > ---------------------------------- > > Dr. Thomas Belling > > 3GPP Standardisation > > NSN > > > > > > > > -----Original Message----- > > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of ext Vijay K. > > Gurbani > > Sent: Friday, November 22, 2013 7:56 PM > > To: cuss@ietf.org > > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" > > > > On 11/22/2013 12:36 PM, Atle Monrad wrote: > > > Hi > > > > > > I guess each of the "shall we allow multiple > > representations" needs to > > > be handled on a case-by-case basis, but generally speaking I > > > understand that the chairs and ADs aren't too enthusiastic with too > > > many ... > > > > > > What 3GPP really wants for Christmas is the draft to be completed. > > > Somebody must take a decision on this soon. > > > > ... which means that by Nov 29, 2013 it'd be nice to hear from others > > who have an opinion. > > > > Many thanks to those who have already expressed one. > > > > Cheers, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, > > Rm. 9C-533, Naperville, Illinois 60563 (USA) > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: > > http://goo.gl/x3Ogq _______________________________________________ > > 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 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From atle.monrad@ericsson.com Thu Nov 28 03:27:21 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA221ADF78 for ; Thu, 28 Nov 2013 03:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fcp3LImdlfQ for ; Thu, 28 Nov 2013 03:27:19 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 96F591AD8DB for ; Thu, 28 Nov 2013 03:27:18 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-b9-52972894858a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5E.24.22496.49827925; Thu, 28 Nov 2013 12:27:17 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.134]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 28 Nov 2013 12:27:16 +0100 From: Atle Monrad To: "bruno.chatras@orange.com" , "R.Jesske@telekom.de" , "keith.drage@alcatel-lucent.com" , "thomas.belling@nsn.com" , "vijay.gurbani@alcatel-lucent.com" , "cuss@ietf.org" Thread-Topic: [cuss] "isdn-uui" versus "isdn-network" Thread-Index: AQHO5t6p/rnx1aTdzE2fpUK6uaPrRZouX5ewgAFvMwCAAB+7AIAABCiAgAAWioCAAYtzgIAABZoAgARJUDCAAoh2sIAAVKhAgAAYAcCAAD98YA== Date: Thu, 28 Nov 2013 11:27:16 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C21D969@ESESSMB203.ericsson.se> References: <5281161C.1060404@bell-labs.com> <17974_1384966290_528CE892_17974_4141_1_88CAD1D4E8773F42858B58CAA28272A0112D245F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <528E4204.8080304@bell-labs.com> <528E5869.7080905@bell-labs.com> <7D2F7D7ADBA812449F25F4A69922881C209134@ESESSMB203.ericsson.se> <528FA8D6.8050301@bell-labs.com> <949EF20990823C4C85C18D59AA11AD8B0EE102@FR712WXCHMBA11.zeu.alcatel-lucent.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB76B3A5@HE113667.emea1.cds.t-internal.com> <24886_1385541448_5295AF48_24886_7243_1_88CAD1D4E8773F42858B58CAA28272A0112DFB50@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <24886_1385541448_5295AF48_24886_7243_1_88CAD1D4E8773F42858B58CAA28272A0112DFB50@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvre5UjelBBstfclt8v/iQ2eJG+wtm i6eNZxktmu50sVm07drHaLHp3Dp2BzaP1md7WT2WLPnJ5PFz/VV2j5ZnJ9k82l4qBLBGcdmk pOZklqUW6dslcGUs3r+MpaDTt6Jn/kTmBsY59l2MnBwSAiYSHVNvs0PYYhIX7q1n62Lk4hAS OMEoceFmJ5SzhFFif98KNpAqNgEdiXM/77CCJEQEzjBJvP98GKxdGGhUw5YVzCC2iICpRHfL PzYIu07iz+GbrCA2i4CqxJVl/8HqeQW8JU4eWMgCsWE3m0Tfgk6wqZwCHYwSH6deB3I4OBgF ZCXmNvGCNDALiEvcejKfCeJWAYkle84zQ9iiEi8f/2OFsJUkVmy/xAhRrydxY+oUNghbW2LZ wtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMksWpxcW56UYGernpuSV6qUWZycXF +Xl6xambGIGRd3DLb6MdjCf32B9ilOZgURLnvc5aEyQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBcXVUsI1q9JIolwL/YPVE8c3yneWSAQeLr3AmWiZOs7jhvMl24hSGnRuPC/9RmvrXyf25 mvWEqzNFC8VWtj9n+h6W3/Bp4Zzp1zaKmdy1knLYGh4597RQ2YsXfFOXvuPbVek+91LPo0dz +PXSQ9Zfe7Tq41TWt3JrX9c9iM4JYFfK37L6l8v7OCWW4oxEQy3mouJEAFGAh06KAgAA Subject: Re: [cuss] "isdn-uui" versus "isdn-network" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:27:21 -0000 Hi When this was discussed at IETF-88 it was clearly communicated what people = had as an agreement on the cuss-list (due to interop) and this was the star= ting point of the discussion. It was also made clear that the parameter (isdn-interwork) had been include= d in some previous version(s) of the draft and that there were deployments = according to this.=20 Nevertheless, it was in this discussion found that older versions of parame= ter names was work-in-progress and was not seen as a strong reason to norma= tively support both old and new of the parameter names. ---- Below is my understanding of where and when the "isdn-interwork" parameter = was visible in the uui-drafts. Within IETF, it seems that the parameter "isdn-interwork" was normatively i= ntroduced in draft-johnston-sipping-cc-uui-08 (June 2009) and remains in dr= aft-johnston-sipping-cc-uui-09 (March 2010). This draft was then discontinu= ed and re-appeared as draft-johnson-cuss-sip-uui. In both versions (-00 and= -01) of this draft the "isdn-interwork" appear in the examples only. This = continue in the WG-adopted version draft-ietf-cuss-sip-uui-00. Since draft= -ietf-cuss-sip-uui-01 from July 11 2011 I have not been able to find any tr= ace of the parameter "isdn-interwork" in any of the cuss-drafts. 3GPP normally reference the most recent version of internet-draft, thus I c= annot find the "isdn-interwork" referenced in our documentation anymore. 3= GPP also Indicates internet-drafts as work-in-progress and indicate this ac= cordingly on our documentation. I leave to others to decide whether this is sufficient to introduce the nor= mative support of both values or not, but please get the drafts completed o= ne way or another.=20 thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of bruno.chatras@orange= .com Sent: 27. november 2013 09:37 To: R.Jesske@telekom.de; keith.drage@alcatel-lucent.com; thomas.belling@nsn= .com; vijay.gurbani@alcatel-lucent.com; cuss@ietf.org Subject: Re: [cuss] "isdn-uui" versus "isdn-network" What matters is not whether we call it "normative" or not but the keyword u= sed in the proposed text. The latest proposed wording was using "RECOMMENDE= D" and most people were happy with this before the "hallway conversation".= =20 http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html > -----Message d'origine----- > De=A0: cuss [mailto:cuss-bounces@ietf.org] De la part de=20 > R.Jesske@telekom.de Envoy=E9=A0: mercredi 27 novembre 2013 08:17 =C0=A0:= =20 > keith.drage@alcatel-lucent.com; thomas.belling@nsn.com;=20 > vijay.gurbani@alcatel-lucent.com; cuss@ietf.org Objet=A0: Re: [cuss]=20 > "isdn-uui" versus "isdn-network" >=20 > Dear all, > I had no problems in adding a note since such Note has more a=20 > guideline function which can be taken into consideration based on=20 > bilateral agreements and local policy. > BUT > I have problems with the whole discussion about making the "isdn-=20 > interworking" now as a normative and mandatory alias or additional=20 > element which has now to be understood by all interworking points. >=20 > We have implemented 3GPP TS 29.163 which bases on the latest IETF=20 > draft. And this document never stated the "isdn-interworking" has to=20 > be used for interworking. >=20 >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von DRAGE, Keith=20 > (Keith) > Gesendet: Mittwoch, 27. November 2013 03:14 > An: Belling, Thomas (NSN - DE/Munich); Gurbani, Vijay K (Vijay);=20 > cuss@ietf.org > Betreff: Re: [cuss] "isdn-uui" versus "isdn-network" >=20 > I have indicated right at the start of one of the original calls that=20 > I would prefer not to make any addition in this area. But putting that=20 > aside for the moment. >=20 > In the hallway discussion, I tried to get clarification as to what the=20 > change should mean, because I have had several inconstent answers to=20 > this in the past. This basically falls into two issues: >=20 > 1) Whether the change was a note (i.e. normative) or informative. My > understanding of Bruno's postion was that it should be normative,=20 > which means essentially that all implementations recognise the value=20 > when it is received. However conformant implementations only generate the= correct value. > It appears however other people were not aware that the change was=20 > intended to be normative, based on your continued representation of this = as a "NOTE". >=20 > 2) If the change was normative, then presumably the new value should be > IANA registered. It was apparently this that caused people to say that=20 > they did not want a normative change (which I guess would lead to the=20 > impression that the usage was sanctioned for the future), and=20 > subsequently that did not see the point of an informative change. >=20 > In response to Christer, when writing the draft, we chose a label that=20 > was consistent with the usage it was to be put, which was not to be=20 > constrained to interworking with the ISDN, but rather one that=20 > provided the equivalent capabilities. We were not aware that we were=20 > constrained by examples showing other values in previous drafts;=20 > indeed we did not even look at some of those older versions in this=20 > respect - at the time this was a new document with a clean field. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Belling,=20 > > Thomas (NSN - DE/Munich) > > Sent: 25 November 2013 11:35 > > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" > > > > For me, it is also quite important to finalize the work. > > > > I have a certain sympathy for considering backward compatibility, as=20 > > I understand that the concerns relate to real deployments and seem=20 > > of interest to make things work in reality. I thus support related=20 > > wording in the draft. > > > > I understand the point that drafts should be regarded as=20 > > experimental and subject to change. However, this is only fine if=20 > > features demanded in the market are finalized within a reasonable=20 > > time. If work goes on for about five years (as in the current case),=20 > > backward compatibility will become a real concern no matter if=20 > > purists like it. The main takeaway could be to aim to finalize work=20 > > in a reasonable amount of time. > > > > BR, Thomas > > > > > > ---------------------------------- > > Dr. Thomas Belling > > 3GPP Standardisation > > NSN > > > > > > > > -----Original Message----- > > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of ext Vijay K. > > Gurbani > > Sent: Friday, November 22, 2013 7:56 PM > > To: cuss@ietf.org > > Subject: Re: [cuss] "isdn-uui" versus "isdn-network" > > > > On 11/22/2013 12:36 PM, Atle Monrad wrote: > > > Hi > > > > > > I guess each of the "shall we allow multiple > > representations" needs to > > > be handled on a case-by-case basis, but generally speaking I=20 > > > understand that the chairs and ADs aren't too enthusiastic with=20 > > > too many ... > > > > > > What 3GPP really wants for Christmas is the draft to be completed. > > > Somebody must take a decision on this soon. > > > > ... which means that by Nov 29, 2013 it'd be nice to hear from=20 > > others who have an opinion. > > > > Many thanks to those who have already expressed one. > > > > Cheers, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent=20 > > Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > > Email: vkg@{bell-labs.com,acm.org} /=20 > > vijay.gurbani@alcatel-lucent.com > > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: > > http://goo.gl/x3Ogq _______________________________________________ > > 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 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Thu Nov 28 08:01:30 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF691AE058 for ; Thu, 28 Nov 2013 08:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFE2ChnlQ7ah for ; Thu, 28 Nov 2013 08:01:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 090051AE022 for ; Thu, 28 Nov 2013 08:01:27 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2342A3B4790; Thu, 28 Nov 2013 17:01:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 020AC2380AB; Thu, 28 Nov 2013 17:01:26 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 17:01:25 +0100 From: To: "Vijay K. Gurbani" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQjpZ8cipsk3kSQgC/b50QzQZo6481g Date: Thu, 28 Nov 2013 16:01:23 +0000 Message-ID: <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <5283CECB.8050804@bell-labs.com> In-Reply-To: <5283CECB.8050804@bell-labs.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.28.100914 Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 16:01:30 -0000 Hello, Please find below some comments: 1/ About "isdn-interwork" versus "isdn-uui" purpose parameter value:=20 The discussions on the "[cuss] "isdn-uui" versus "isdn-network"" email thre= ad confirmed that there is still support from other cuss participants for a= ddressing the use of the "isdn-network" parameter value. So, we don't think= the document can be published without addressing this issue. We also under= stand that at least one company would not accept replacing "RECOMMEND" with= "MUST", so we propose to stick to the initial approach (cf http://www.ietf= .org/mail-archive/web/cuss/current/msg00509.html ) and add the following te= xt in section 11: "The 'isdn-interwork' value for purpose parameter was used in Internet-Draf= ts that have led to the publication of the present RFC. Although these docu= ments had no other status than "work in progress", this value is implemente= d by some vendors. Therefore, it is RECOMMENDED to support parsing and inte= rpreting 'isdn-interwork' the same way as 'isdn-uui' when receiving." 2/ About UAC and UAS procedures: After having compared the UAC and UAS procedures in sections 7 and 8, I not= iced that 2 UAC procedures could be replicated as UAS procedures as well, s= o I would suggest to add in section 7: "When receiving UUI, when a User-to-User header field is received in a resp= onse that is not from the originating user with the "purpose" header field = parameter to "isdn-uui", or with no "purpose" header field parameter, the U= AS MUST discard this header field." (this procedure seems not present for UAS) And to add in section 8: "When sending UUI for the ISDN package, if the "purpose" header field is in= cluded, the UAS MUST set the User-to-User "purpose" header field parameter = to "isdn-uui"." (this procedure is present for UAS but not so explicitly written) It could be worthwhile to add them in order to be symmetric when a procedur= e is common to both UAC and UAS, otherwise people could wonder if it means = that they are just missing or if it means that they are not applicable. We would like these 1/ and 2/ comments to be taken into account before the = ISDN draft becomes a RFC. Thank you in advance. Best regards Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de V= ijay K. Gurbani Envoy=E9=A0: mercredi 13 novembre 2013 20:11 =C0=A0: cuss@ietf.org Objet=A0: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Folks: Enrico and I will like to announce a WGLC for the ISDN draft [1]. The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. We will appreciate your comments on the draft, posted to the list. All com= ments are appreciated, even if it is a simple one-liner saying that you bel= ieve the draft is ready, or conversely, that it is not ready (and why). As you review the draft, as part of your WGLC review, please identify any i= ssues that may exist in regard to compatibility with draft-ietf-cuss-uui (t= he mechanism draft). Thank you. [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ Vijay K. Gurbani and Enrico Marocco _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From keith.drage@alcatel-lucent.com Thu Nov 28 17:17:08 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76A31AE070 for ; Thu, 28 Nov 2013 17:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPtbOEJkLjIJ for ; Thu, 28 Nov 2013 17:17:06 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B32621AE06E for ; Thu, 28 Nov 2013 17:17:06 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rAT1H3Qk028397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Nov 2013 19:17:04 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAT1H2MW009458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Nov 2013 02:17:02 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 29 Nov 2013 02:17:02 +0100 From: "DRAGE, Keith (Keith)" To: "celine.serrutvalette@orange.com" , "Gurbani, Vijay K (Vijay)" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgACqPVA= Date: Fri, 29 Nov 2013 01:17:01 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0EF1F7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <5283CECB.8050804@bell-labs.com> <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 01:17:09 -0000 With regard to your point 1), you are specifying normative language - for t= his as defined as follows by RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That means exactly the same in 3GPP and therefore any references from 3GPP = carry this as a should level requirement - unless you are saying that the g= eneral 3GPP architecture provides a reason for the 3GPP specification overr= iding this. It means essentially for any general purpose implementation in IETF or 3GPP= that this becomes "MUST" or "shall", because the implications cannot be un= derstood unless applied to a specific content usage. As far as I am aware your organisation is the only one that has been suppor= ting statements at this level. My read of Roland's last comment was that he would not support a requiremen= t, but I leave him to speak. Regards Keith=20 > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of=20 > celine.serrutvalette@orange.com > Sent: 28 November 2013 16:01 > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > Hello, >=20 > Please find below some comments: >=20 > 1/ About "isdn-interwork" versus "isdn-uui" purpose parameter value:=20 >=20 > The discussions on the "[cuss] "isdn-uui" versus=20 > "isdn-network"" email thread confirmed that there is still=20 > support from other cuss participants for addressing the use=20 > of the "isdn-network" parameter value. So, we don't think the=20 > document can be published without addressing this issue. We=20 > also understand that at least one company would not accept=20 > replacing "RECOMMEND" with "MUST", so we propose to stick to=20 > the initial approach (cf=20 > http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm > l ) and add the following text in section 11: >=20 > "The 'isdn-interwork' value for purpose parameter was used in=20 > Internet-Drafts that have led to the publication of the=20 > present RFC. Although these documents had no other status=20 > than "work in progress", this value is implemented by some=20 > vendors. Therefore, it is RECOMMENDED to support parsing and=20 > interpreting 'isdn-interwork' the same way as 'isdn-uui' when=20 > receiving." >=20 > 2/ About UAC and UAS procedures: >=20 > After having compared the UAC and UAS procedures in sections=20 > 7 and 8, I noticed that 2 UAC procedures could be replicated=20 > as UAS procedures as well, so I would suggest to add in section 7: > "When receiving UUI, when a User-to-User header field is=20 > received in a response that is not from the originating user=20 > with the "purpose" header field parameter to "isdn-uui", or=20 > with no "purpose" header field parameter, the UAS MUST=20 > discard this header field." > (this procedure seems not present for UAS) >=20 > And to add in section 8: > "When sending UUI for the ISDN package, if the "purpose"=20 > header field is included, the UAS MUST set the User-to-User=20 > "purpose" header field parameter to "isdn-uui"." > (this procedure is present for UAS but not so explicitly written) >=20 > It could be worthwhile to add them in order to be symmetric=20 > when a procedure is common to both UAC and UAS, otherwise=20 > people could wonder if it means that they are just missing or=20 > if it means that they are not applicable. >=20 >=20 > We would like these 1/ and 2/ comments to be taken into=20 > account before the ISDN draft becomes a RFC. > Thank you in advance. >=20 > Best regards >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De=20 > la part de Vijay K. Gurbani Envoy=E9=A0: mercredi 13 novembre=20 > 2013 20:11 =C0=A0: cuss@ietf.org Objet=A0: [cuss] WGLC for=20 > draft-ietf-cuss-sip-uui-isdn >=20 > Folks: Enrico and I will like to announce a WGLC for the ISDN=20 > draft [1]. >=20 > The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. >=20 > We will appreciate your comments on the draft, posted to the=20 > list. All comments are appreciated, even if it is a simple=20 > one-liner saying that you believe the draft is ready, or=20 > conversely, that it is not ready (and why). >=20 > As you review the draft, as part of your WGLC review, please=20 > identify any issues that may exist in regard to compatibility=20 > with draft-ietf-cuss-uui (the mechanism draft). >=20 > Thank you. >=20 > [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ >=20 > Vijay K. Gurbani and Enrico Marocco > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 > ______________________________________________________________ > ___________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des=20 > informations confidentielles ou privilegiees et ne doivent=20 > donc pas etre diffuses, exploites ou copies sans=20 > autorisation. Si vous avez recu ce message par erreur,=20 > veuillez le signaler a l'expediteur et le detruire ainsi que=20 > les pieces jointes. Les messages electroniques etant=20 > susceptibles d'alteration, Orange decline toute=20 > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they=20 > should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the=20 > sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages=20 > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From R.Jesske@telekom.de Fri Nov 29 01:14:40 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAC01AD739 for ; Fri, 29 Nov 2013 01:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrDYO9k-gS1g for ; Fri, 29 Nov 2013 01:14:37 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id A988A1A1F08 for ; Fri, 29 Nov 2013 01:14:35 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 29 Nov 2013 10:14:31 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 29 Nov 2013 10:14:31 +0100 From: To: , , , Date: Fri, 29 Nov 2013 10:14:30 +0100 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQz6m0bJAR+y0uBhOtWswz/6Zo61B+AgACqPVCAAIKWYA== Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB7D976C@HE113667.emea1.cds.t-internal.com> References: <5283CECB.8050804@bell-labs.com> <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <949EF20990823C4C85C18D59AA11AD8B0EF1F7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0EF1F7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 09:14:40 -0000 Hi, when we discussed this approach, everybody was OK with a note since this wa= s agreed on a pragmatic approach. This was not based on a pedantic interpretation of editorial rules. Going a= long the rules the wording was not RECOMMENDED it was recommended. I have nothing against such note written with a lower case recommended. The= future RFC will still be understood by people reading it. And if the RFC w= ill be implemented it will work (with or without the Note). So goal reached. What will I say. I can go along the PRAGMATIC compromise reached one year a= go and I can life without a note. But I cannot accept any normative changes= to ABNF. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von DRAGE, Keith (Keith= ) Gesendet: Freitag, 29. November 2013 02:17 An: celine.serrutvalette@orange.com; Gurbani, Vijay K (Vijay); cuss@ietf.or= g Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn With regard to your point 1), you are specifying normative language - for t= his as defined as follows by RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That means exactly the same in 3GPP and therefore any references from 3GPP = carry this as a should level requirement - unless you are saying that the g= eneral 3GPP architecture provides a reason for the 3GPP specification overr= iding this. It means essentially for any general purpose implementation in IETF or 3GPP= that this becomes "MUST" or "shall", because the implications cannot be un= derstood unless applied to a specific content usage. As far as I am aware your organisation is the only one that has been suppor= ting statements at this level. My read of Roland's last comment was that he would not support a requiremen= t, but I leave him to speak. Regards Keith=20 > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of=20 > celine.serrutvalette@orange.com > Sent: 28 November 2013 16:01 > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > Hello, >=20 > Please find below some comments: >=20 > 1/ About "isdn-interwork" versus "isdn-uui" purpose parameter value:=20 >=20 > The discussions on the "[cuss] "isdn-uui" versus "isdn-network"" email=20 > thread confirmed that there is still support from other cuss=20 > participants for addressing the use of the "isdn-network" parameter=20 > value. So, we don't think the document can be published without=20 > addressing this issue. We also understand that at least one company=20 > would not accept replacing "RECOMMEND" with "MUST", so we propose to=20 > stick to the initial approach (cf=20 > http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm > l ) and add the following text in section 11: >=20 > "The 'isdn-interwork' value for purpose parameter was used in=20 > Internet-Drafts that have led to the publication of the present RFC.=20 > Although these documents had no other status than "work in progress",=20 > this value is implemented by some vendors. Therefore, it is=20 > RECOMMENDED to support parsing and interpreting 'isdn-interwork' the=20 > same way as 'isdn-uui' when receiving." >=20 > 2/ About UAC and UAS procedures: >=20 > After having compared the UAC and UAS procedures in sections > 7 and 8, I noticed that 2 UAC procedures could be replicated as UAS=20 > procedures as well, so I would suggest to add in section 7: > "When receiving UUI, when a User-to-User header field is received in a=20 > response that is not from the originating user with the "purpose"=20 > header field parameter to "isdn-uui", or with no "purpose" header=20 > field parameter, the UAS MUST discard this header field." > (this procedure seems not present for UAS) >=20 > And to add in section 8: > "When sending UUI for the ISDN package, if the "purpose"=20 > header field is included, the UAS MUST set the User-to-User "purpose"=20 > header field parameter to "isdn-uui"." > (this procedure is present for UAS but not so explicitly written) >=20 > It could be worthwhile to add them in order to be symmetric when a=20 > procedure is common to both UAC and UAS, otherwise people could wonder=20 > if it means that they are just missing or if it means that they are=20 > not applicable. >=20 >=20 > We would like these 1/ and 2/ comments to be taken into account before=20 > the ISDN draft becomes a RFC. > Thank you in advance. >=20 > Best regards >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part=20 > de Vijay K. Gurbani Envoy=E9=A0: mercredi 13 novembre > 2013 20:11 =C0=A0: cuss@ietf.org Objet=A0: [cuss] WGLC for=20 > draft-ietf-cuss-sip-uui-isdn >=20 > Folks: Enrico and I will like to announce a WGLC for the ISDN draft=20 > [1]. >=20 > The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. >=20 > We will appreciate your comments on the draft, posted to the list. =20 > All comments are appreciated, even if it is a simple one-liner saying=20 > that you believe the draft is ready, or conversely, that it is not=20 > ready (and why). >=20 > As you review the draft, as part of your WGLC review, please identify=20 > any issues that may exist in regard to compatibility with=20 > draft-ietf-cuss-uui (the mechanism draft). >=20 > Thank you. >=20 > [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ >=20 > Vijay K. Gurbani and Enrico Marocco > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 > ______________________________________________________________ > ___________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Fri Nov 29 05:25:13 2013 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396061ADFF8 for ; Fri, 29 Nov 2013 05:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRDBYGX3rAWM for ; Fri, 29 Nov 2013 05:25:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AE98D1AD7C2 for ; Fri, 29 Nov 2013 05:25:08 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 88C5622C6EC; Fri, 29 Nov 2013 14:25:06 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A052B4C0AF; Fri, 29 Nov 2013 14:24:44 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 14:24:44 +0100 From: To: "R.Jesske@telekom.de" , "keith.drage@alcatel-lucent.com" , "vijay.gurbani@alcatel-lucent.com" , "cuss@ietf.org" Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Thread-Index: AQHO4KQjpZ8cipsk3kSQgC/b50QzQZo6481ggACLkICAAIVoAIAAVaNQ Date: Fri, 29 Nov 2013 13:24:43 +0000 Message-ID: <16539_1385731506_529895B1_16539_55_3_F8BE5641EC3C954DA088A8350BDDFA480F359B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5283CECB.8050804@bell-labs.com> <681_1385654486_529768D6_681_2889_1_b84635f4-ca26-4417-911b-a5721866222a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <949EF20990823C4C85C18D59AA11AD8B0EF1F7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB7D976C@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB7D976C@HE113667.emea1.cds.t-internal.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 13:25:13 -0000 Hello, We agree for such a note written with a lower case recommended. Best regards Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Envoy=E9=A0: vendredi 29 novembre 2013 10:15 =C0=A0: keith.drage@alcatel-lucent.com; SERRUT VALETTE Celine IMT/OLN; vija= y.gurbani@alcatel-lucent.com; cuss@ietf.org Objet=A0: AW: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn Hi, when we discussed this approach, everybody was OK with a note since this wa= s agreed on a pragmatic approach. This was not based on a pedantic interpretation of editorial rules. Going a= long the rules the wording was not RECOMMENDED it was recommended. I have nothing against such note written with a lower case recommended. The= future RFC will still be understood by people reading it. And if the RFC w= ill be implemented it will work (with or without the Note). So goal reached. What will I say. I can go along the PRAGMATIC compromise reached one year a= go and I can life without a note. But I cannot accept any normative changes= to ABNF. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss [mailto:cuss-bounces@ietf.org] Im Auftrag von DRAGE, Keith (Keith) Gesendet: Freitag, 29. November 2013 02:17 An: celine.serrutvalette@orange.com; Gurbani, Vijay K (Vijay); cuss@ietf.org Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn With regard to your point 1), you are specifying normative language - for t= his as defined as follows by RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That means exactly the same in 3GPP and therefore any references from 3GPP = carry this as a should level requirement - unless you are saying that the g= eneral 3GPP architecture provides a reason for the 3GPP specification overr= iding this. It means essentially for any general purpose implementation in IETF or 3GPP= that this becomes "MUST" or "shall", because the implications cannot be un= derstood unless applied to a specific content usage. As far as I am aware your organisation is the only one that has been suppor= ting statements at this level. My read of Roland's last comment was that he would not support a requiremen= t, but I leave him to speak. Regards Keith=20 > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of=20 > celine.serrutvalette@orange.com > Sent: 28 November 2013 16:01 > To: Gurbani, Vijay K (Vijay); cuss@ietf.org > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn >=20 > Hello, >=20 > Please find below some comments: >=20 > 1/ About "isdn-interwork" versus "isdn-uui" purpose parameter value:=20 >=20 > The discussions on the "[cuss] "isdn-uui" versus "isdn-network"" email=20 > thread confirmed that there is still support from other cuss=20 > participants for addressing the use of the "isdn-network" parameter=20 > value. So, we don't think the document can be published without=20 > addressing this issue. We also understand that at least one company=20 > would not accept replacing "RECOMMEND" with "MUST", so we propose to=20 > stick to the initial approach (cf=20 > http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm > l ) and add the following text in section 11: >=20 > "The 'isdn-interwork' value for purpose parameter was used in=20 > Internet-Drafts that have led to the publication of the present RFC. > Although these documents had no other status than "work in progress",=20 > this value is implemented by some vendors. Therefore, it is=20 > RECOMMENDED to support parsing and interpreting 'isdn-interwork' the=20 > same way as 'isdn-uui' when receiving." >=20 > 2/ About UAC and UAS procedures: >=20 > After having compared the UAC and UAS procedures in sections > 7 and 8, I noticed that 2 UAC procedures could be replicated as UAS=20 > procedures as well, so I would suggest to add in section 7: > "When receiving UUI, when a User-to-User header field is received in a=20 > response that is not from the originating user with the "purpose" > header field parameter to "isdn-uui", or with no "purpose" header=20 > field parameter, the UAS MUST discard this header field." > (this procedure seems not present for UAS) >=20 > And to add in section 8: > "When sending UUI for the ISDN package, if the "purpose"=20 > header field is included, the UAS MUST set the User-to-User "purpose"=20 > header field parameter to "isdn-uui"." > (this procedure is present for UAS but not so explicitly written) >=20 > It could be worthwhile to add them in order to be symmetric when a=20 > procedure is common to both UAC and UAS, otherwise people could wonder=20 > if it means that they are just missing or if it means that they are=20 > not applicable. >=20 >=20 > We would like these 1/ and 2/ comments to be taken into account before=20 > the ISDN draft becomes a RFC. > Thank you in advance. >=20 > Best regards >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part=20 > de Vijay K. Gurbani Envoy=E9=A0: mercredi 13 novembre > 2013 20:11 =C0=A0: cuss@ietf.org Objet=A0: [cuss] WGLC for=20 > draft-ietf-cuss-sip-uui-isdn >=20 > Folks: Enrico and I will like to announce a WGLC for the ISDN draft=20 > [1]. >=20 > The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013. >=20 > We will appreciate your comments on the draft, posted to the list.=20=20 > All comments are appreciated, even if it is a simple one-liner saying=20 > that you believe the draft is ready, or conversely, that it is not=20 > ready (and why). >=20 > As you review the draft, as part of your WGLC review, please identify=20 > any issues that may exist in regard to compatibility with=20 > draft-ietf-cuss-uui (the mechanism draft). >=20 > Thank you. >=20 > [1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ >=20 > Vijay K. Gurbani and Enrico Marocco > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 > ______________________________________________________________ > ___________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you.