From internet-drafts@ietf.org Sun Aug 4 02:59:21 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 AAE6721F9A7D; Sun, 4 Aug 2013 02:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 w0v51zgm64PX; Sun, 4 Aug 2013 02:59:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DA021F9A59; Sun, 4 Aug 2013 02:59:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130804095920.17230.99919.idtracker@ietfa.amsl.com> Date: Sun, 04 Aug 2013 02:59:20 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 09:59:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Working = Group of the IETF. Title : Interworking ISDN Call Control User Information with SIP Author(s) : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-05.txt Pages : 19 Date : 2013-08-04 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. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-isdn-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Sun Aug 4 03:02:21 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 48A9E21F9A74 for ; Sun, 4 Aug 2013 03:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.609 X-Spam-Level: X-Spam-Status: No, score=-110.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 k+++ZrVcqovl for ; Sun, 4 Aug 2013 03:02:15 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id AC85121F9A59 for ; Sun, 4 Aug 2013 03:02:15 -0700 (PDT) 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 r74A2BsK004919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 4 Aug 2013 05:02:13 -0500 (CDT) 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 r74A2Bli024580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Aug 2013 12:02:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 4 Aug 2013 12:02:11 +0200 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-05.txt Thread-Index: AQHOkPlNHGGo399WpkecsCgnAUWcDpmE0Qug Date: Sun, 4 Aug 2013 10:02:10 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07BAA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] 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: [cuss] FW: I-D Action: draft-ietf-cuss-sip-uui-isdn-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 10:02:21 -0000 I've just posted a revision of the ISDN package with the ABNF updated to ma= tch the current main document. I'll post separately on the only open question. Regards Keith -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: 04 August 2013 10:59 To: i-d-announce@ietf.org Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Working = Group of the IETF. Title : Interworking ISDN Call Control User Information with SIP Author(s) : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-05.txt Pages : 19 Date : 2013-08-04 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. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-isdn-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Sun Aug 4 03:26:55 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 DB2F521F9956 for ; Sun, 4 Aug 2013 03:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.608 X-Spam-Level: X-Spam-Status: No, score=-110.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 OgEcBOJotbic for ; Sun, 4 Aug 2013 03:26:49 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56F8B21F994C for ; Sun, 4 Aug 2013 03:26:46 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r74AQige002726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 4 Aug 2013 05:26:46 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r74AQhgm025356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Aug 2013 12:26:44 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 4 Aug 2013 12:26:43 +0200 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Thread-Topic: draft-ietf-cuss-sip-uui-isdn-05 Thread-Index: Ac6Q/BGsLRy9BjuISt+6Ei9PF6mVeA== Date: Sun, 4 Aug 2013 10:26:43 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07BAD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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.35 Subject: [cuss] draft-ietf-cuss-sip-uui-isdn-05 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 10:26:56 -0000 I have just posted a -05 version of this draft. This leaves one issue which was raised by Celine a while back. Celine argued for the value "isdn-interwork" to be included for purpose in = addition to the one defined. This was for the purpose of backwards compatib= ility. This value only appears in the examples in the draft-johnston-cuss-sip-uui = and in -00 version of draft-ietf-cuss-sip-uui. It has never appeared in any version of draft-drage-cuss-sip-uui-isdn or dr= aft-ietf-cuss-sip-uui-isdn. It does appear defined in draft-johnston-sipping-cc-uui, but only in the -0= 8 and -09 versions, and not in prior versions. (3rd Jan 2010 through 14th D= ecember 2010 when it was replaced by the CUSS author draft) My understanding of the implications of this would be that a sender MUST NO= T send this value. A receiver MUST support this value when received, and co= rresponding requirements would be needed. The ABNF and IANA considerations = would also need to be updated to reflect this value. Could WG members indicate their preference for making this change, or for n= ot making this change. To start the discussion, my preference would be not to make this change, on= the basis that it conveys complexity for a previous draft version that was= not in existence for very long. As far as I can recall, neither of the two= versions that define this were ever referenced by 3GPP. Regards Keith From bruno.chatras@orange.com Tue Aug 6 00:05:14 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 63F7521F9C52 for ; Tue, 6 Aug 2013 00:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 n04FUwtS7-zf for ; Tue, 6 Aug 2013 00:05:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE911E80E0 for ; Tue, 6 Aug 2013 00:05:09 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AA9FB22D13B; Tue, 6 Aug 2013 09:05:05 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 83F7E27C102; Tue, 6 Aug 2013 09:05:05 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 09:05:05 +0200 From: To: "DRAGE, Keith (Keith)" , "cuss@ietf.org" Thread-Topic: draft-ietf-cuss-sip-uui-isdn-05 Thread-Index: Ac6Q/BGsLRy9BjuISt+6Ei9PF6mVeABdPUNQ Date: Tue, 6 Aug 2013 07:05:04 +0000 Message-ID: <14435_1375772705_5200A021_14435_321_1_88CAD1D4E8773F42858B58CAA28272A0232EEF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <949EF20990823C4C85C18D59AA11AD8B07BAD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07BAD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 Subject: Re: [cuss] draft-ietf-cuss-sip-uui-isdn-05 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 07:05:14 -0000 Hi Keith, all,=20 Unfortunately draft-johnston-sipping-cc-uui-08 was referenced by previous v= ersions of 3GPP TS 24.229. See for example reference 126 in TS 24.229 versi= ons 9.10.0 or 10.0.0 (and some others as well). As mentioned by Celine in t= he email sent on 5 July 2012, there are implementations based on this versi= on of the Johnson draft. Due to the holiday period we may not receive many answers from WG members a= bout their preference. However, a request for feedback was already made las= t year and there was no objection against Celine's requested change.=20 http://www.ietf.org/mail-archive/web/cuss/current/msg00430.html=09 http://www.ietf.org/mail-archive/web/cuss/current/msg00445.html My preference is of course to make this change. Best Regards BC > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de > DRAGE, Keith (Keith) > Envoy=E9=A0: dimanche 4 ao=FBt 2013 12:27 > =C0=A0: cuss@ietf.org > Objet=A0: [cuss] draft-ietf-cuss-sip-uui-isdn-05 >=20 > I have just posted a -05 version of this draft. >=20 > This leaves one issue which was raised by Celine a while back. >=20 > Celine argued for the value "isdn-interwork" to be included for purpose in > addition to the one defined. This was for the purpose of backwards > compatibility. >=20 > This value only appears in the examples in the draft-johnston-cuss-sip-uui > and in -00 version of draft-ietf-cuss-sip-uui. >=20 > It has never appeared in any version of draft-drage-cuss-sip-uui-isdn or > draft-ietf-cuss-sip-uui-isdn. >=20 > It does appear defined in draft-johnston-sipping-cc-uui, but only in the - > 08 and -09 versions, and not in prior versions. (3rd Jan 2010 through 14th > December 2010 when it was replaced by the CUSS author draft) >=20 > My understanding of the implications of this would be that a sender MUST > NOT send this value. A receiver MUST support this value when received, and > corresponding requirements would be needed. The ABNF and IANA > considerations would also need to be updated to reflect this value. >=20 > Could WG members indicate their preference for making this change, or for > not making this change. >=20 > To start the discussion, my preference would be not to make this change, = on > the basis that it conveys complexity for a previous draft version that was > not in existence for very long. As far as I can recall, neither of the two > versions that define this were ever referenced by 3GPP. >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From keith.drage@alcatel-lucent.com Tue Aug 6 00:12:16 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 363A511E80D5 for ; Tue, 6 Aug 2013 00:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 2kz3TzIldYKC for ; Tue, 6 Aug 2013 00:12:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A729021F9C7A for ; Tue, 6 Aug 2013 00:12:10 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r767Bx6x019477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2013 02:12:00 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r767BwVF025723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 09:11:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 6 Aug 2013 09:11:58 +0200 From: "DRAGE, Keith (Keith)" To: "bruno.chatras@orange.com" , "cuss@ietf.org" Thread-Topic: draft-ietf-cuss-sip-uui-isdn-05 Thread-Index: Ac6Q/BGsLRy9BjuISt+6Ei9PF6mVeABdPUNQAADD3PA= Date: Tue, 6 Aug 2013 07:11:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07C9E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B07BAD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <14435_1375772705_5200A021_14435_321_1_88CAD1D4E8773F42858B58CAA28272A0232EEF@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <14435_1375772705_5200A021_14435_321_1_88CAD1D4E8773F42858B58CAA28272A0232EEF@PEXCVZYM12.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.41] 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.37 Subject: Re: [cuss] draft-ietf-cuss-sip-uui-isdn-05 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 07:12:16 -0000 Just to point out that the request for comment last year produced one suppo= rter and one who did not respond further after the impact was clarified. I regarded that as indefinite, and certainly did not take it as support in = the WG. Keith > -----Original Message----- > From: bruno.chatras@orange.com [mailto:bruno.chatras@orange.com] > Sent: 06 August 2013 08:05 > To: DRAGE, Keith (Keith); cuss@ietf.org > Subject: RE: draft-ietf-cuss-sip-uui-isdn-05 >=20 > Hi Keith, all, >=20 > Unfortunately draft-johnston-sipping-cc-uui-08 was referenced by previous > versions of 3GPP TS 24.229. See for example reference 126 in TS 24.229 > versions 9.10.0 or 10.0.0 (and some others as well). As mentioned by > Celine in the email sent on 5 July 2012, there are implementations based > on this version of the Johnson draft. >=20 > Due to the holiday period we may not receive many answers from WG members > about their preference. However, a request for feedback was already made > last year and there was no objection against Celine's requested change. >=20 > http://www.ietf.org/mail-archive/web/cuss/current/msg00430.html > http://www.ietf.org/mail-archive/web/cuss/current/msg00445.html >=20 > My preference is of course to make this change. >=20 > Best Regards > BC >=20 >=20 >=20 > > -----Message d'origine----- > > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de > > DRAGE, Keith (Keith) > > Envoy=E9=A0: dimanche 4 ao=FBt 2013 12:27 > > =C0=A0: cuss@ietf.org > > Objet=A0: [cuss] draft-ietf-cuss-sip-uui-isdn-05 > > > > I have just posted a -05 version of this draft. > > > > This leaves one issue which was raised by Celine a while back. > > > > Celine argued for the value "isdn-interwork" to be included for purpose > in > > addition to the one defined. This was for the purpose of backwards > > compatibility. > > > > This value only appears in the examples in the draft-johnston-cuss-sip- > uui > > and in -00 version of draft-ietf-cuss-sip-uui. > > > > It has never appeared in any version of draft-drage-cuss-sip-uui-isdn o= r > > draft-ietf-cuss-sip-uui-isdn. > > > > It does appear defined in draft-johnston-sipping-cc-uui, but only in th= e > - > > 08 and -09 versions, and not in prior versions. (3rd Jan 2010 through > 14th > > December 2010 when it was replaced by the CUSS author draft) > > > > My understanding of the implications of this would be that a sender MUS= T > > NOT send this value. A receiver MUST support this value when received, > and > > corresponding requirements would be needed. The ABNF and IANA > > considerations would also need to be updated to reflect this value. > > > > Could WG members indicate their preference for making this change, or > for > > not making this change. > > > > To start the discussion, my preference would be not to make this change= , > on > > the basis that it conveys complexity for a previous draft version that > was > > not in existence for very long. As far as I can recall, neither of the > two > > versions that define this were ever referenced by 3GPP. > > > > Regards > > > > Keith > > > > > > _______________________________________________ > > 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 > confidentielles 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 > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From vkg@bell-labs.com Fri Aug 9 07:02:11 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 9E89421F94FA for ; Fri, 9 Aug 2013 07:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 ablLcVqLQRW0 for ; Fri, 9 Aug 2013 07:02:06 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53F21F967C for ; Fri, 9 Aug 2013 07:01:59 -0700 (PDT) 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 r79E1wWC011181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 Aug 2013 09:01:58 -0500 (CDT) 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 r79E1vOJ001718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Aug 2013 09:01:58 -0500 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 r79E1vtK025663 for ; Fri, 9 Aug 2013 09:01:57 -0500 (CDT) Message-ID: <5204F769.9060608@bell-labs.com> Date: Fri, 09 Aug 2013 09:06:33 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 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.10 Subject: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:02:11 -0000 Folks: Keith has opened up a thread to ask WG guidance on whether to include "isdn-network" in the purpose parameter. His detailed email laying out the argument is is in [1]. We need to close this issue as soon as possible in order to move forward. In the past, Enrico and I have received emails from other standards groups asking to move this work along quickly. Thus, we assume that there is a need for expediency if the work is to remain relevant. Can the folks who have an opinion on this issue please post to the mailing list. At this point, is only one additional voice (Bruno) besides Keith who has expressed an opinion. We need more. Please provide some input so we can gauge consensus on this issue, close it and move on. Thank you, [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html - 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 Fri Aug 9 07:22:30 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 DCA5921F99A8 for ; Fri, 9 Aug 2013 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofljJjUQPSBo for ; Fri, 9 Aug 2013 07:22:26 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 168CE21F992E for ; Fri, 9 Aug 2013 07:22:24 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id Ae3U1m0081swQuc5CeNQcN; Fri, 09 Aug 2013 14:22:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id AeNP1m01A3ZTu2S3beNQ6x; Fri, 09 Aug 2013 14:22:24 +0000 Message-ID: <5204FB1F.5090503@alum.mit.edu> Date: Fri, 09 Aug 2013 16:22:23 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cuss@ietf.org References: <5204F769.9060608@bell-labs.com> In-Reply-To: <5204F769.9060608@bell-labs.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=1376058144; bh=Xf8f7VHTW5oeD3/KNzYMpzoAmAJ0ct9Zh8Vm9uyhhjc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YAYJQRp5ubdCP2IYYQxB8skeNWmSgJ/EPMJL+0XBcQ+LuNYCgR+Phmjr6eCIJ6bJp u+/XHki8wPapcE71f4GuxbOiANjQkYjiC+dtXoJZ5BlIhtZjpXfraO6iNkc8ZCCs84 hTNgCVzQq1/CP3FlOpOP7FJ9OfzHunAsBXrDiA6dg7JvUQdsq7RiumkwkcSlXt+jM2 jHqixozJO13DEy+Tg63cweEBvdFwUeOfzZUamDUHaaZO8BnVrEQ16/rjETUiZGrk9V UH3Kpxg1IINTQ2V3NtA0g9HRWv7ebKTWnbpp0955sa11zpjskvOFDRIeW41WzDiHyu adQACzWo89XYA== Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:22:31 -0000 Precisely what semantics are being sought for this new purpose param value? Are isdn-uui and isdn-network to be treated as synonyms in all cases, or is isdn-network to *replace* isdn-uui? Or are they to be treated as separate but equal - that some may support one and some may support the other? Thanks, Paul On 8/9/13 4:06 PM, Vijay K. Gurbani wrote: > Folks: Keith has opened up a thread to ask WG guidance on whether to > include "isdn-network" in the purpose parameter. His detailed email > laying out the argument is is in [1]. > > We need to close this issue as soon as possible in order to move > forward. In the past, Enrico and I have received emails from other > standards groups asking to move this work along quickly. Thus, we > assume that there is a need for expediency if the work is to remain > relevant. > > Can the folks who have an opinion on this issue please post to the > mailing list. At this point, is only one additional voice (Bruno) > besides Keith who has expressed an opinion. We need more. > > Please provide some input so we can gauge consensus on this issue, > close it and move on. > > Thank you, > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html > > - vijay From bruno.chatras@orange.com Tue Aug 13 01:55:15 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 4D36221F9D09 for ; Tue, 13 Aug 2013 01:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] 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 aOYucZtkBLLT for ; Tue, 13 Aug 2013 01:55:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8621F862B for ; Tue, 13 Aug 2013 01:54:19 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 78FF3264C99; Tue, 13 Aug 2013 10:54:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2C4AF4C05D; Tue, 13 Aug 2013 10:54:18 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 13 Aug 2013 10:54:17 +0200 From: To: Paul Kyzivat , "cuss@ietf.org" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: AQHOlQkN9xgs/yBK7Ee3eyte3ezC2JmMzCGAgAYL5rA= Date: Tue, 13 Aug 2013 08:54:17 +0000 Message-ID: <13793_1376384058_5209F43A_13793_7209_1_88CAD1D4E8773F42858B58CAA28272A023629E@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> In-Reply-To: <5204FB1F.5090503@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.13.72430 Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:55:15 -0000 As both values are already in use in the field, I think the simplest approa= ch would be to treat them as synonyms. Another solution if people prefer to give preference to the new value would= be to deprecate sending "isdn-interwork" but to require the receiver to st= ill treat them as synonyms. BC > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de > Paul Kyzivat > Envoy=E9=A0: vendredi 9 ao=FBt 2013 16:22 > =C0=A0: cuss@ietf.org > Objet=A0: Re: [cuss] To "isdn-network" or not >=20 > Precisely what semantics are being sought for this new purpose param valu= e? > Are isdn-uui and isdn-network to be treated as synonyms in all cases, or = is > isdn-network to *replace* isdn-uui? Or are they to be treated as separate > but equal - that some may support one and some may support the other? >=20 > Thanks, > Paul >=20 > On 8/9/13 4:06 PM, Vijay K. Gurbani wrote: > > Folks: Keith has opened up a thread to ask WG guidance on whether to > > include "isdn-network" in the purpose parameter. His detailed email > > laying out the argument is is in [1]. > > > > We need to close this issue as soon as possible in order to move > > forward. In the past, Enrico and I have received emails from other > > standards groups asking to move this work along quickly. Thus, we > > assume that there is a need for expediency if the work is to remain > > relevant. > > > > Can the folks who have an opinion on this issue please post to the > > mailing list. At this point, is only one additional voice (Bruno) > > besides Keith who has expressed an opinion. We need more. > > > > Please provide some input so we can gauge consensus on this issue, > > close it and move on. > > > > Thank you, > > > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html > > > > - vijay >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From R.Jesske@telekom.de Tue Aug 13 05:09:35 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 59FAF11E817D for ; Tue, 13 Aug 2013 05:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtTULOY2XUof for ; Tue, 13 Aug 2013 05:09:31 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1111E8179 for ; Tue, 13 Aug 2013 05:09:30 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 13 Aug 2013 14:09:11 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 13 Aug 2013 14:09:10 +0200 From: To: , Date: Tue, 13 Aug 2013 14:09:08 +0200 Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6VC++rkiw2hAgHQpSknnGKF6bGIgC9GIUQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> In-Reply-To: <5204FB1F.5090503@alum.mit.edu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:09:35 -0000 Hi Paul, Celine and I had at least the agreement (http://www.ietf.org/mail-archive/w= eb/cuss/current/msg00430.html) that we can include a Note into the draft wh= ich indicates: Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dra= fts that have led to the publication of the present RFC. Although these doc= uments had not other status than "work in progress", it is implemented by s= ome vendors. Therefore, it is RECOMMENDED to support parsing and interpreti= ng 'isdn-interwork' the same way as 'isdn-uui' when receiving. So from my side implementations should only sent the "isdn-uui" but if "isd= n-interwork" is received all implementations should understand also this va= lue. Best Regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von Pa= ul Kyzivat Gesendet: Freitag, 9. August 2013 16:22 An: cuss@ietf.org Betreff: Re: [cuss] To "isdn-network" or not Precisely what semantics are being sought for this new purpose param value?= Are isdn-uui and isdn-network to be treated as synonyms in all cases, or i= s isdn-network to *replace* isdn-uui? Or are they to be treated as separate= but equal - that some may support one and some may support the other? Thanks, Paul On 8/9/13 4:06 PM, Vijay K. Gurbani wrote: > Folks: Keith has opened up a thread to ask WG guidance on whether to=20 > include "isdn-network" in the purpose parameter. His detailed email=20 > laying out the argument is is in [1]. > > We need to close this issue as soon as possible in order to move=20 > forward. In the past, Enrico and I have received emails from other=20 > standards groups asking to move this work along quickly. Thus, we=20 > assume that there is a need for expediency if the work is to remain=20 > relevant. > > Can the folks who have an opinion on this issue please post to the=20 > mailing list. At this point, is only one additional voice (Bruno)=20 > besides Keith who has expressed an opinion. We need more. > > Please provide some input so we can gauge consensus on this issue,=20 > close it and move on. > > Thank you, > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html > > - vijay _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From jan.van.geel@belgacom.be Tue Aug 13 05:18:50 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 1A6B121F9EC9 for ; Tue, 13 Aug 2013 05:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 U+x8XD-XjgO2 for ; Tue, 13 Aug 2013 05:18:46 -0700 (PDT) Received: from mx23.belgacom.be (mx23.belgacom.be [213.181.45.233]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9121E811B for ; Tue, 13 Aug 2013 05:18:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,868,1367964000"; d="scan'208,217";a="36714654" Received: from unknown (HELO A03006.BGC.NET) ([10.121.129.161]) by mx23.belgacom.be with ESMTP; 13 Aug 2013 14:18:43 +0200 X-TM-IMSS-Message-ID: <03cb0e260000d3d4@belgacom.be> Received: from A04023.BGC.NET ([10.120.135.24]) by belgacom.be ([10.121.129.161]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 03cb0e260000d3d4 ; Tue, 13 Aug 2013 14:18:42 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04023.BGC.NET ([10.120.135.24]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 14:18:42 +0200 From: "VAN GEEL Jan (CIS/SCC)" To: "R.Jesske@telekom.de" , "pkyzivat@alum.mit.edu" , "cuss@ietf.org" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6VC++r9xgs/yBK7Ee3eyte3ezC2AC9GIUQAAeecPA= Date: Tue, 13 Aug 2013 12:18:41 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.41.98] Content-Type: multipart/alternative; boundary="_000_1E97FFD1485F1142BC075FF145A53A1E318B86A04067BGCNET_" MIME-Version: 1.0 Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:18:50 -0000 --_000_1E97FFD1485F1142BC075FF145A53A1E318B86A04067BGCNET_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Knowing from experience that there will always be implementers which only i= mplement the "required" stuff and not the recommended stuff, wouldn't it be= better to make the note a little bit more pushing. For example: Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dr= afts that have led to the publication of the present RFC. Although these do= cuments had no other status than "work in progress", it is implemented by s= ome vendors. Therefore, in order to ensure interoperability, it is REQUIRED= to support parsing and interpreting 'isdn-interwork' the same way as 'isdn= -uui' when receiving. Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of R.J= esske@telekom.de Sent: Tuesday 13 August 2013 14:09 To: pkyzivat@alum.mit.edu; cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not Hi Paul, Celine and I had at least the agreement (http://www.ietf.org/mail-archive/w= eb/cuss/current/msg00430.html) that we can include a Note into the draft wh= ich indicates: Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dra= fts that have led to the publication of the present RFC. Although these doc= uments had not other status than "work in progress", it is implemented by s= ome vendors. Therefore, it is RECOMMENDED to support parsing and interpreti= ng 'isdn-interwork' the same way as 'isdn-uui' when receiving. So from my side implementations should only sent the "isdn-uui" but if "isd= n-interwork" is received all implementations should understand also this va= lue. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounc= es@ietf.org] Im Auftrag von Paul Kyzivat Gesendet: Freitag, 9. August 2013 16:22 An: cuss@ietf.org Betreff: Re: [cuss] To "isdn-network" or not Precisely what semantics are being sought for this new purpose param value?= Are isdn-uui and isdn-network to be treated as synonyms in all cases, or i= s isdn-network to *replace* isdn-uui? Or are they to be treated as separate= but equal - that some may support one and some may support the other? Thanks, Paul On 8/9/13 4:06 PM, Vijay K. Gurbani wrote: > Folks: Keith has opened up a thread to ask WG guidance on whether to > include "isdn-network" in the purpose parameter. His detailed email > laying out the argument is is in [1]. > > We need to close this issue as soon as possible in order to move > forward. In the past, Enrico and I have received emails from other > standards groups asking to move this work along quickly. Thus, we > assume that there is a need for expediency if the work is to remain > relevant. > > Can the folks who have an opinion on this issue please post to the > mailing list. At this point, is only one additional voice (Bruno) > besides Keith who has expressed an opinion. We need more. > > Please provide some input so we can gauge consensus on this issue, > close it and move on. > > Thank you, > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html > > - vijay _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer --_000_1E97FFD1485F1142BC075FF145A53A1E318B86A04067BGCNET_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Knowing from experience that there will always be implementers which o= nly implement the "required" stuff and not the recommended stuff,= wouldn't it be better to make the note a little bit more pushing.
 
For example:
 
Note: 'isdn-interwork' value for purpose parameter was used in Intern= et-Drafts that have led to the publication of the present RFC. Although the= se documents had no other status than "work in progress", it is i= mplemented by some vendors. Therefore, in order to ensure interoperability, it is REQUIRED to support parsing and interpreting 'isd= n-interwork' the same way as 'isdn-uui' when receiving.
 
Kind regards
 
Jan Van Geel
IT and Network Specialist
Belgacom CIS/SCC/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : jan.van.geel@belgacom.be
 
-----Original Message-----
From: cuss-bounces@ietf.org [mailt= o:cuss-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
Sent: Tuesday 13 August 2013 14:09
To: pkyzivat@alum.mit.edu; cuss@ietf.org
Subject: Re: [cuss] To "isdn-network" or not
 
Hi Paul,
Celine and I had at least the agreement (http://www.ietf.org/mail-arc= hive/web/cuss/current/msg00430.html) that we can include a Note into th= e draft which indicates:
 
Note: 'isdn-interwork' value for purpose parameter was used in Interne= t-Drafts that have led to the publication of the present RFC. Although thes= e documents had not other status than "work in progress", it is i= mplemented by some vendors. Therefore, it is RECOMMENDED to support parsing and interpreting 'isdn-interwork' the sam= e way as 'isdn-uui' when receiving.
 
So from my side implementations should only sent the "isdn-uui&qu= ot; but if "isdn-interwork" is received all implementations shoul= d understand also this value.
 
Best Regards
 
Roland
 
 
 
-----Urspr=FCngliche Nachricht-----
Gesendet: Freitag, 9. August 2013 16:22
Betreff: Re: [cuss] To "isdn-network" or not
 
Precisely what semantics are being sought for this new purpose param v= alue? Are isdn-uui and isdn-network to be treated as synonyms in all cases,= or is isdn-network to *replace* isdn-uui? Or are they to be treated as sep= arate but equal - that some may support one and some may support the other?
 
        Thanks,
        Paul
 
On 8/9/13 4:06 PM, Vijay K. Gurbani wrote:
> Folks: Keith has opened up a thread to ask WG guidance on whether= to
> include "isdn-network" in the purpose parameter.  = His detailed email
> laying out the argument is is in [1].
>
> We need to close this issue as soon as possible in order to move =
> forward.  In the past, Enrico and I have received emails fro= m other
> standards groups asking to move this work along quickly.  Th= us, we
> assume that there is a need for expediency if the work is to rema= in
> relevant.
>
> Can the folks who have an opinion on this issue please post to th= e
> mailing list.  At this point, is only one additional voice (= Bruno)
> besides Keith who has expressed an opinion.  We need more.
>
> Please provide some input so we can gauge consensus on this issue= ,
> close it and move on.
>
> Thank you,
>
>
> - vijay
 
_______________________________________________
cuss mailing list
_______________________________________________
cuss mailing list
 

  ________________________________  

***** Discl= aimer *****
http://www.belgacom.be= /maildisclaimer
 --_000_1E97FFD1485F1142BC075FF145A53A1E318B86A04067BGCNET_-- From pkyzivat@alum.mit.edu Tue Aug 13 07:41:46 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 B8B6411E8176 for ; Tue, 13 Aug 2013 07:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5LWwzdv7S+Y for ; Tue, 13 Aug 2013 07:41:29 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id C190C11E815C for ; Tue, 13 Aug 2013 07:41:28 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id CBb51m0050cZkys5EEhTBd; Tue, 13 Aug 2013 14:41:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id CEfT1m00X3ZTu2S3WEfTCf; Tue, 13 Aug 2013 14:39:27 +0000 Message-ID: <520A451E.9090901@alum.mit.edu> Date: Tue, 13 Aug 2013 16:39:26 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "VAN GEEL Jan (CIS/SCC)" References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376404887; bh=tIogbVUsLKiNHPYV7+pDFO6U4FH27/Lsc7oZYCMFXRQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nzJ5ZBZcgdi1LO08xmSB+QwYr9JnMX5u2C+yRCvtQB7YDEISyHnYIqGvW5TPAq/N2 1vLqkyhvOQIUjLVl4jNsOyurRqmYs3FKIP+qxTZ9Cbmd8rKAKtmY1jqfRrrV02C27r UGvi8HId7GotM+HI/3lW6jJHNh5bAra1SZ82g5+9yHtxd+FIiJH70fs1mtbjrVoOMJ lMzmYhRg4o6a3zPPmkm5IOpPRXUlVfLbXE+ss6zb6pFOBJ35Wifcc05SlQs94qizC7 Hk4NKKNkYWOj+ibXCF2HKtaOk17T+VvIXuq/7oF62prXULgXchsf+z2NkyrmavvljC 7mKQlorGgKseQ== Cc: "cuss@ietf.org" Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 14:41:46 -0000 On 8/13/13 2:18 PM, VAN GEEL Jan (CIS/SCC) wrote: > Knowing from experience that there will always be implementers which > only implement the "required" stuff and not the recommended stuff, > wouldn't it be better to make the note a little bit more pushing. > For example: > Note: 'isdn-interwork' value for purpose parameter was used in > Internet-Drafts that have led to the publication of the present RFC. > Although these documents had no other status than "work in progress", it > is implemented by some vendors. Therefore, in order to ensure > interoperability, it is REQUIRED to support parsing and interpreting > 'isdn-interwork' the same way as 'isdn-uui' when receiving. This is easy to do. Will it be sufficient? If you have stuff deployed out there that uses and knows only isdn-interwork, then won't it fail when *receiving* isdn-uui? In the extreme, if there is stuff deployed that only uses isdn-interwork, and other stuff deployed that only uses isdn-uui, then to be compatible with both, new stuff will need to send requests with *both*. Thanks, Paul > Kind regards > Jan Van Geel > IT and Network Specialist > Belgacom CIS/SCC/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > R.Jesske@telekom.de > Sent: Tuesday 13 August 2013 14:09 > To: pkyzivat@alum.mit.edu; cuss@ietf.org > Subject: Re: [cuss] To "isdn-network" or not > Hi Paul, > Celine and I had at least the agreement > (http://www.ietf.org/mail-archive/web/cuss/current/msg00430.html) that > we can include a Note into the draft which indicates: > Note: 'isdn-interwork' value for purpose parameter was used in > Internet-Drafts that have led to the publication of the present RFC. > Although these documents had not other status than "work in progress", > it is implemented by some vendors. Therefore, it is RECOMMENDED to > support parsing and interpreting 'isdn-interwork' the same way as > 'isdn-uui' when receiving. > So from my side implementations should only sent the "isdn-uui" but if > "isdn-interwork" is received all implementations should understand also > this value. > Best Regards > Roland > -----Ursprüngliche Nachricht----- > Von: cuss-bounces@ietf.org > [mailto:cuss-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Freitag, 9. August 2013 16:22 > An: cuss@ietf.org > Betreff: Re: [cuss] To "isdn-network" or not > Precisely what semantics are being sought for this new purpose param > value? Are isdn-uui and isdn-network to be treated as synonyms in all > cases, or is isdn-network to *replace* isdn-uui? Or are they to be > treated as separate but equal - that some may support one and some may > support the other? > Thanks, > Paul > On 8/9/13 4:06 PM, Vijay K. Gurbani wrote: >> Folks: Keith has opened up a thread to ask WG guidance on whether to >> include "isdn-network" in the purpose parameter. His detailed email >> laying out the argument is is in [1]. >> >> We need to close this issue as soon as possible in order to move >> forward. In the past, Enrico and I have received emails from other >> standards groups asking to move this work along quickly. Thus, we >> assume that there is a need for expediency if the work is to remain >> relevant. >> >> Can the folks who have an opinion on this issue please post to the >> mailing list. At this point, is only one additional voice (Bruno) >> besides Keith who has expressed an opinion. We need more. >> >> Please provide some input so we can gauge consensus on this issue, >> close it and move on. >> >> Thank you, >> >> [1]http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html >> >> - vijay > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > > _ ________________________________ _ > > ***** Disclaimer ***** > http://www.belgacom.be/maildisclaimer From vkg@bell-labs.com Tue Aug 13 07:46:26 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 C5A9121E814A for ; Tue, 13 Aug 2013 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 Pg-4TJ5Xp2wk for ; Tue, 13 Aug 2013 07:46:22 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2378921F9B52 for ; Tue, 13 Aug 2013 07:46:22 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7DEkFg5020481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Aug 2013 09:46:15 -0500 (CDT) 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 r7DEkFqs031532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Aug 2013 09:46:15 -0500 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 r7DEkETM008933 for ; Tue, 13 Aug 2013 09:46:15 -0500 (CDT) Message-ID: <520A47CC.5070904@bell-labs.com> Date: Tue, 13 Aug 2013 09:50:52 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: cuss@ietf.org References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 14:46:26 -0000 Keith, Alan: I suspect we can agree that there appears to be some consensus for "isdn-network" to be treated as a second-class alias for "isdn-uui". I am sympathetic to the ramifications of the unnecessary complexity on supporting deprecated parameter values --- the deprecated "transport=tls" parameter issues we faced in SIP raise their ugly head in my memory. But I suspect that supporting the "isdn-network" as an alias that is strongly bounded by language you suggest towards the bottom of your email [1] limits its scope in creating problems. Unless there are other views to be considered, can you please indicate whether you think this issue is equitably settled so we can move forward. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From R.Jesske@telekom.de Thu Aug 15 00:56:09 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 D4BBD21E811A for ; Thu, 15 Aug 2013 00:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 yZQxERao52B1 for ; Thu, 15 Aug 2013 00:56:06 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id E6E9B21E80A3 for ; Thu, 15 Aug 2013 00:56:05 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 15 Aug 2013 09:56:03 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 15 Aug 2013 09:56:02 +0200 From: To: , Date: Thu, 15 Aug 2013 09:56:00 +0200 Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6YM+XqnqqNnfo5QXeS8Bv1lKqV7QBWOXbA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> In-Reply-To: <520A47CC.5070904@bell-labs.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:56:09 -0000 Hi, does this mean that we add the proposed note? Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von Vi= jay K. Gurbani Gesendet: Dienstag, 13. August 2013 16:51 An: cuss@ietf.org Betreff: Re: [cuss] To "isdn-network" or not Keith, Alan: I suspect we can agree that there appears to be some consensus= for "isdn-network" to be treated as a second-class alias for "isdn-uui". I am sympathetic to the ramifications of the unnecessary complexity on supp= orting deprecated parameter values --- the deprecated "transport=3Dtls" par= ameter issues we faced in SIP raise their ugly head in my memory. But I su= spect that supporting the "isdn-network" as an alias that is strongly bound= ed by language you suggest towards the bottom of your email [1] limits its = scope in creating problems. Unless there are other views to be considered, can you please indicate whet= her you think this issue is equitably settled so we can move forward. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9= C-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 Thu Aug 15 08:07:01 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 D369521F9F1B for ; Thu, 15 Aug 2013 08:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.624 X-Spam-Level: X-Spam-Status: No, score=-109.624 tagged_above=-999 required=5 tests=[AWL=0.975, 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 K897r6sWDH+i for ; Thu, 15 Aug 2013 08:06:56 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B40E121F9F21 for ; Thu, 15 Aug 2013 08:06:54 -0700 (PDT) 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 r7FF6kOj016737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Aug 2013 10:06:47 -0500 (CDT) 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 r7FF6kB4014096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Aug 2013 10:06:46 -0500 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 r7FF6k5t013161; Thu, 15 Aug 2013 10:06:46 -0500 (CDT) Message-ID: <520CEF9D.1060104@bell-labs.com> Date: Thu, 15 Aug 2013 10:11:25 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> 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 Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 15:07:02 -0000 On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > Hi, > does this mean that we add the proposed note? Roland: I believe that Paul's thoughts on this subject [1] deserve a response from the working group if we are to add this note. My operating assumption when I posted my comment [2] was that the legacy gear that is sending out "isdn-network" is only acting as a UAC (a PSTN to SIP gateway/PBX, for instance). Thus, it can get away with only sending "isdn-network". But if this is not true, and we have legacy UAS that only accept "isdn-network", then how does a random UAC know whether it will send "isdn-network" or "isdn-uui"? Thoughts? [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From bruno.chatras@orange.com Fri Aug 16 01:13:39 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 C1AB911E812E for ; Fri, 16 Aug 2013 01:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 mxFlz5LPpKNp for ; Fri, 16 Aug 2013 01:13:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01011E825E for ; Fri, 16 Aug 2013 01:13:34 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3EEAD325286; Fri, 16 Aug 2013 10:13:31 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 220462380B6; Fri, 16 Aug 2013 10:13:31 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 16 Aug 2013 10:13:30 +0200 From: To: "Vijay K. Gurbani" , "R.Jesske@telekom.de" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: AQHOlQkN9xgs/yBK7Ee3eyte3ezC2JmMzCGAgAYkGACAAAKrgIAAKoUAgAKwwQCAAHmngIABPkFQ Date: Fri, 16 Aug 2013 08:13:29 +0000 Message-ID: <17623_1376640811_520DDF2B_17623_3672_1_88CAD1D4E8773F42858B58CAA28272A02375A7@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> In-Reply-To: <520CEF9D.1060104@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: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.16.52419 Cc: "cuss@ietf.org" Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 08:13:39 -0000 Vijay's operating assumption is valid from my point of view. That's why the= proposed note should be OK. BC > -----Message d'origine----- > De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de > Vijay K. Gurbani > Envoy=E9=A0: jeudi 15 ao=FBt 2013 17:11 > =C0=A0: R.Jesske@telekom.de > Cc=A0: cuss@ietf.org > Objet=A0: Re: [cuss] To "isdn-network" or not >=20 > On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > > Hi, > > does this mean that we add the proposed note? >=20 > Roland: >=20 > I believe that Paul's thoughts on this subject [1] deserve a response from > the working group if we are to add this note. >=20 > My operating assumption when I posted my comment [2] was that the legacy > gear that is sending out "isdn-network" is only acting as a UAC (a PSTN to > SIP gateway/PBX, for instance). Thus, it can get away with only sending > "isdn-network". >=20 > But if this is not true, and we have legacy UAS that only accept "isdn- > network", then how does a random UAC know whether it will send "isdn- > network" or "isdn-uui"? >=20 > Thoughts? >=20 > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html > [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html >=20 > Thanks, >=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: 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. From atle.monrad@ericsson.com Fri Aug 16 01:35:57 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 7A0DA11E8264 for ; Fri, 16 Aug 2013 01:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aacfl3LiDs+L for ; Fri, 16 Aug 2013 01:35:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67211E8262 for ; Fri, 16 Aug 2013 01:35:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-ac-520de451e811 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AA.1B.16099.154ED025; Fri, 16 Aug 2013 10:35:30 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.248]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Fri, 16 Aug 2013 10:35:29 +0200 From: Atle Monrad To: "VAN GEEL Jan (CIS/SCC)" , "R.Jesske@telekom.de" , "pkyzivat@alum.mit.edu" , "cuss@ietf.org" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6VC++rnqqNnfo5QXeS8Bv1lKqV7QC9GIUQAAeecPAAYLEt0A== Date: Fri, 16 Aug 2013 08:35:28 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C16F6AE@ESESSMB203.ericsson.se> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7D2F7D7ADBA812449F25F4A69922881C16F6AEESESSMB203ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvrW7QE94gg8P/2CxutL9gtthwew+z xYoNB1gtmu50sTmwePx9/4HJY9mMdhaPJUt+Mnm0vVQIYInisklJzcksSy3St0vgyvjZ1Mxe sPQxY8XxvfUNjGvOMHYxcnBICJhIHFqS38XICWSKSVy4t56ti5GLQ0jgMKNE7/0rTBDOEkaJ Lf/3MoNUsQnoSJz7eYcVJCEisItRYvenN4wgCWGgxLOD69lBbBEBXYlrT9pYIGwnic6zD8Bs FgFVidXvFjODbOYV8JaYeVwAYsF1Romtu/aDLeAUcJFYtf8QC0gNo4CsxNwmXpAws4C4xK0n 85kgLhWQWLLnPDOELSrx8vE/VghbSeLHhkssEPX5Ekcm3gOzeQUEJU7OfMIygVFkFpJRs5CU zUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGy5yZm5qSXG25iBMbYwS2/dXcw njoncohRmoNFSZx3k96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MmXebYrjlOO52WzMu M4sM3NGXas6qPtuzcNMlxfsrHnxhZUs8+tlMRj04/l3Dn6POzCfW1ki7fc5Rfym0Xphlj/kl /rCIPZ+f/2EWafaxCDrccZwx4Hoa2zW1UnWF/3MPr74rlMPO8VDS0S2CsWGfOI9HyaRXl9/V /W9mbD56SP3A39PNymxKLMUZiYZazEXFiQDOTbHZfwIAAA== Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 08:35:58 -0000 --_000_7D2F7D7ADBA812449F25F4A69922881C16F6AEESESSMB203ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All As said before, 3GPP is really waiting for the cuss-sip-uui drafts to compl= ete. The new NOTE as outlined by Jan: Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dra= fts that have led to the publication of the present RFC. Although these doc= uments had no other status than "work in progress", it is implemented by so= me vendors. Therefore, in order to ensure interoperability, it is REQUIRED = to support parsing and interpreting 'isdn-interwork' the same way as 'isdn-= uui' when receiving. Seem to give a graceful transition from the existing implementations to thi= s "soon-to-be RFC". Hope this will satisfy all parties. Thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation Ericsson From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of VAN= GEEL Jan (CIS/SCC) Sent: 13. august 2013 14:19 To: R.Jesske@telekom.de; pkyzivat@alum.mit.edu; cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not Knowing from experience that there will always be implementers which only i= mplement the "required" stuff and not the recommended stuff, wouldn't it be= better to make the note a little bit more pushing. For example: Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dra= fts that have led to the publication of the present RFC. Although these doc= uments had no other status than "work in progress", it is implemented by so= me vendors. Therefore, in order to ensure interoperability, it is REQUIRED = to support parsing and interpreting 'isdn-interwork' the same way as 'isdn-= uui' when receiving. Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-boun= ces@ietf.org] On Behalf Of R.Jesske@telekom.de Sent: Tuesday 13 August 2013 14:09 To: pkyzivat@alum.mit.edu; cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not Hi Paul, Celine and I had at least the agreement (http://www.ietf.org/mail-archive/w= eb/cuss/current/msg00430.html) that we can include a Note into the draft wh= ich indicates: Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dra= fts that have led to the publication of the present RFC. Although these doc= uments had not other status than "work in progress", it is implemented by s= ome vendors. Therefore, it is RECOMMENDED to support parsing and interpreti= ng 'isdn-interwork' the same way as 'isdn-uui' when receiving. So from my side implementations should only sent the "isdn-uui" but if "isd= n-interwork" is received all implementations should understand also this va= lue. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounc= es@ietf.org] Im Auftrag von Paul Kyzivat Gesendet: Freitag, 9. August 2013 16:22 An: cuss@ietf.org Betreff: Re: [cuss] To "isdn-network" or not Precisely what semantics are being sought for this new purpose param value?= Are isdn-uui and isdn-network to be treated as synonyms in all cases, or i= s isdn-network to *replace* isdn-uui? Or are they to be treated as separate= but equal - that some may support one and some may support the other? Thanks, Paul On 8/9/13 4:06 PM, Vijay K. Gurbani wrote: > Folks: Keith has opened up a thread to ask WG guidance on whether to > include "isdn-network" in the purpose parameter. His detailed email > laying out the argument is is in [1]. > > We need to close this issue as soon as possible in order to move > forward. In the past, Enrico and I have received emails from other > standards groups asking to move this work along quickly. Thus, we > assume that there is a need for expediency if the work is to remain > relevant. > > Can the folks who have an opinion on this issue please post to the > mailing list. At this point, is only one additional voice (Bruno) > besides Keith who has expressed an opinion. We need more. > > Please provide some input so we can gauge consensus on this issue, > close it and move on. > > Thank you, > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00476.html > > - vijay _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer --_000_7D2F7D7ADBA812449F25F4A69922881C16F6AEESESSMB203ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All

 <= /p>

As said before, 3GPP is r= eally waiting for the cuss-sip-uui drafts to complete.

 <= /p>

The new NOTE as outlined = by Jan:

Note: 'isdn-interwork' value for purpos= e parameter was used in Internet-Drafts that have led to the publication of= the present RFC. Although these documents had no other status than "work in progress", it is implemented by some vendor= s. Therefore, in order to ensure interoperability, it is REQUIRED to support parsi= ng and interpreting 'isdn-interwork' the same way as 'isdn-uui' when receiv= ing.

 <= /p>

Seem to give a graceful t= ransition from the existing implementations to this “soon-to-be RFC&#= 8221;.

 <= /p>

Hope this will satisfy al= l parties.

 <= /p>

Thanks
/atle

 <= /p>

________________________________


Atle Monrad
3GPP CT Chairman

Group Function Technology – Standardization and Technical Regulation<= /span>
Ericsson

 

 <= /p>

From: cuss-bou= nces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of VAN GEEL Jan (CIS/SCC)
Sent: 13. august 2013 14:19
To: R.Jesske@telekom.de; pkyzivat@alum.mit.edu; cuss@ietf.org
Subject: Re: [cuss] To "isdn-network" or not

 

Knowing from experience that there will= always be implementers which only implement the "required" stuff= and not the recommended stuff, wouldn't it be better to make the note a little bit more pushing.

 

For example:

 

Note: 'isdn-interwork' value for purpos= e parameter was used in Internet-Drafts that have led to the publication of= the present RFC. Although these documents had no other status than "work in progress", it is implemented by some vendor= s. Therefore, in order to ensure interoperability, it is REQUIRED to support parsi= ng and interpreting 'isdn-interwork' the same way as 'isdn-uui' when receiv= ing.

 

Kind regards

 

Jan Van Geel

IT and Network Specialist

Belgacom CIS/SCC/FVC

Tel: +32 2 202 1035

Tel: +32 2 207 9032

 

-----Original Message-----
From: cuss-bounces@ietf.org [<= a href=3D"mailto:cuss-bounces@ietf.org">mailto:cuss-bounces@ietf.org] O= n Behalf Of R.Jesske@telekom.de
Sent: Tuesday 13 August 2013 14:09
To: pkyzivat@alum.mit.edu; cuss@ietf.org
Subject: Re: [cuss] To "isdn-network" or not

 

Hi Paul,

Celine and I had at least the agreement= (http://www.ietf.org/mail-archive/web/cuss/current/msg00430.html) that we can include a Note into the draft which indicates:

 

Note: 'isdn-interwork' value for purpos= e parameter was used in Internet-Drafts that have led to the publication of= the present RFC. Although these documents had not other status than "work in progress", it is implemented by some vendor= s. Therefore, it is RECOMMENDED to support parsing and interpreting 'isdn-i= nterwork' the same way as 'isdn-uui' when receiving.

 

So from my side implementations should = only sent the "isdn-uui" but if "isdn-interwork" is rec= eived all implementations should understand also this value.

 

Best Regards

 

Roland

 

 

 

-----Urspr=FCngliche Nachricht-----

Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auft= rag von Paul Kyzivat

Gesendet: Freitag, 9. August 2013 16:22=

Betreff: Re: [cuss] To "isdn-netwo= rk" or not

 

Precisely what semantics are being soug= ht for this new purpose param value? Are isdn-uui and isdn-network to be tr= eated as synonyms in all cases, or is isdn-network to *replace* isdn-uui? Or are they to be treated as separate but equal - that some may = support one and some may support the other?

 

      &nb= sp; Thanks,

      &nb= sp; Paul

 

On 8/9/13 4:06 PM, Vijay K. Gurbani wro= te:

> Folks: Keith has opened up a threa= d to ask WG guidance on whether to

> include "isdn-network" i= n the purpose parameter.  His detailed email

> laying out the argument is is in [= 1].

> 

> We need to close this issue as soo= n as possible in order to move

> forward.  In the past, Enrico= and I have received emails from other

> standards groups asking to move th= is work along quickly.  Thus, we

> assume that there is a need for ex= pediency if the work is to remain

> relevant.

> 

> Can the folks who have an opinion = on this issue please post to the

> mailing list.  At this point,= is only one additional voice (Bruno)

> besides Keith who has expressed an= opinion.  We need more.

> 

> Please provide some input so we ca= n gauge consensus on this issue,

> close it and move on.

> 

> Thank you,

> 

> 

> - vijay

 

_______________________________________= ________

cuss mailing list

_______________________________________= ________

cuss mailing list

 

 

  ________________________________  

--_000_7D2F7D7ADBA812449F25F4A69922881C16F6AEESESSMB203ericsso_-- From R.Jesske@telekom.de Fri Aug 16 01:38:53 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 20F4D11E8262 for ; Fri, 16 Aug 2013 01:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tps6orPQeU5a for ; Fri, 16 Aug 2013 01:38:49 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1E94D11E825E for ; Fri, 16 Aug 2013 01:38:48 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 16 Aug 2013 10:38:46 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 16 Aug 2013 10:38:45 +0200 From: To: , Date: Fri, 16 Aug 2013 10:38:43 +0200 Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: AQHOlQkN9xgs/yBK7Ee3eyte3ezC2JmMzCGAgAYkGACAAAKrgIAAKoUAgAKwwQCAAHmngIABPkFQgAAH3JA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC8EB7@HE111648.emea1.cds.t-internal.com> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> <17623_1376640811_520DDF2B_17623_3672_1_88CAD1D4E8773F42858B58CAA28272A02375A7@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17623_1376640811_520DDF2B_17623_3672_1_88CAD1D4E8773F42858B58CAA28272A02375A7@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 08:38:53 -0000 +1 -----Urspr=FCngliche Nachricht----- Von: bruno.chatras@orange.com [mailto:bruno.chatras@orange.com]=20 Gesendet: Freitag, 16. August 2013 10:13 An: Vijay K. Gurbani; Jesske, Roland Cc: cuss@ietf.org Betreff: RE: [cuss] To "isdn-network" or not Vijay's operating assumption is valid from my point of view. That's why the= proposed note should be OK. BC > -----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: jeudi 15 ao=FBt 2013 17:11 =C0=A0:=20 > R.Jesske@telekom.de Cc=A0: cuss@ietf.org Objet=A0: Re: [cuss] To=20 > "isdn-network" or not >=20 > On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > > Hi, > > does this mean that we add the proposed note? >=20 > Roland: >=20 > I believe that Paul's thoughts on this subject [1] deserve a response=20 > from the working group if we are to add this note. >=20 > My operating assumption when I posted my comment [2] was that the=20 > legacy gear that is sending out "isdn-network" is only acting as a UAC=20 > (a PSTN to SIP gateway/PBX, for instance). Thus, it can get away with=20 > only sending "isdn-network". >=20 > But if this is not true, and we have legacy UAS that only accept=20 > "isdn- network", then how does a random UAC know whether it will send=20 > "isdn- network" or "isdn-uui"? >=20 > Thoughts? >=20 > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html > [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html >=20 > Thanks, >=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 ___________________________________________________________________________= ______________________________________________ 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. From jan.van.geel@belgacom.be Mon Aug 19 00:42:54 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 9D69F21F9C78 for ; Mon, 19 Aug 2013 00:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHwEt2i0IrrM for ; Mon, 19 Aug 2013 00:42:48 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id B057B11E820A for ; Mon, 19 Aug 2013 00:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,911,1367964000"; d="scan'208";a="31902156" Received: from a03005.bgc.net ([10.120.129.161]) by mx13.belgacom.be with ESMTP; 19 Aug 2013 09:42:33 +0200 X-TM-IMSS-Message-ID: <21c7f7c2000573ee@belgacom.be> Received: from A04021.BGC.NET ([10.120.135.22]) by belgacom.be ([10.120.129.161]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 21c7f7c2000573ee ; Mon, 19 Aug 2013 09:42:31 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04021.BGC.NET ([10.120.135.22]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 09:42:31 +0200 From: "VAN GEEL Jan (CIS/SCC)" To: "Vijay K. Gurbani" , "R.Jesske@telekom.de" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6YM+XqnqqNnfo5QXeS8Bv1lKqV7QBWOXbAAAsJgoAAvY/VUA== Date: Mon, 19 Aug 2013 07:42:30 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> In-Reply-To: <520CEF9D.1060104@bell-labs.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.28.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cuss@ietf.org" Subject: Re: [cuss] To "isdn-network" or not 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, 19 Aug 2013 07:42:54 -0000 Just for my understanding: If a UAC is allowed to send "isdn-network" isn't it then required that ALL = UAS are able to accept this value ? If yes then I believe a UAC can send either "isdn-network" or "isdn-uui" an= d every UAS needs to understand "isdn-network" and "isdn-uui". As long as the text or note reflects this without leaving room for differen= t interpretation I'm fine. Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vij= ay K. Gurbani Sent: Thursday 15 August 2013 17:11 To: R.Jesske@telekom.de Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > Hi, > does this mean that we add the proposed note? Roland: I believe that Paul's thoughts on this subject [1] deserve a response from = the working group if we are to add this note. My operating assumption when I posted my comment [2] was that the legacy ge= ar that is sending out "isdn-network" is only acting as a UAC (a PSTN to SI= P gateway/PBX, for instance). Thus, it can get away with only sending "isd= n-network". But if this is not true, and we have legacy UAS that only accept "isdn-netw= ork", then how does a random UAC know whether it will send "isdn-network" o= r "isdn-uui"? Thoughts? [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer From R.Jesske@telekom.de Tue Aug 20 04:13:16 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 9B0F411E820F for ; Tue, 20 Aug 2013 04:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgB-wGTSHnl5 for ; Tue, 20 Aug 2013 04:13:13 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id B6CAB11E820B for ; Tue, 20 Aug 2013 04:13:09 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 20 Aug 2013 13:13:07 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 20 Aug 2013 13:13:07 +0200 From: To: , Date: Tue, 20 Aug 2013 13:13:07 +0200 Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6YM+XqnqqNnfo5QXeS8Bv1lKqV7QBWOXbAAAsJgoAAvY/VUAA483WQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BF98B52@HE111648.emea1.cds.t-internal.com> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 11:13:16 -0000 Hi Jan, we have the definition of isdn-uui since a couple of years within the Draft= . Nevertheless to avoid backwards compatibility problems it is useful that th= e new uui interworking entities will understand also "isdn-network". When we start that sending should be also allowed also we will end up in a = never ending situation where equipment will be produced using "isdn-uui" an= d also equipment with "isdn-network". With our current "agreed" note "isdn-network" we will end up hopefully in a= couple of years and networks will then only use "isdn-uui". As a side effect we have also to rewrite 3GPP specifications. What carriers using the old extension will do in cases when they receive "i= sdn-network" is their problem. I assume they will ignore it. But this cannot be solved by the current draft. We had an agreement of adding a note pointing to the fact than "isdn-uui" s= hould be understood by all entities providing interworking. So my proposal is still to add the note we agreed one year ago and where I = thought it will be only some months till the RFC will appear. (And also tha= t time when we started to implement the draft.): Note: 'isdn-interwork' value for purpose parameter was used in Internet-Dra= fts that have led to the publication of the present RFC. Although these doc= uments had not other status than "work in progress", it is implemented by s= ome vendors. Therefore, it is RECOMMENDED to support parsing and interpreti= ng 'isdn-interwork' the same way as 'isdn-uui' when receiving. Could we agree on counting who is OK with this Note? Or can we have an alternative proposal? Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: VAN GEEL Jan (CIS/SCC) [mailto:jan.van.geel@belgacom.be]=20 Gesendet: Montag, 19. August 2013 09:43 An: Vijay K. Gurbani; Jesske, Roland Cc: cuss@ietf.org Betreff: RE: [cuss] To "isdn-network" or not Just for my understanding: If a UAC is allowed to send "isdn-network" isn't it then required that ALL = UAS are able to accept this value ? If yes then I believe a UAC can send either "isdn-network" or "isdn-uui" an= d every UAS needs to understand "isdn-network" and "isdn-uui". As long as the text or note reflects this without leaving room for differen= t interpretation I'm fine. Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vij= ay K. Gurbani Sent: Thursday 15 August 2013 17:11 To: R.Jesske@telekom.de Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > Hi, > does this mean that we add the proposed note? Roland: I believe that Paul's thoughts on this subject [1] deserve a response from = the working group if we are to add this note. My operating assumption when I posted my comment [2] was that the legacy ge= ar that is sending out "isdn-network" is only acting as a UAC (a PSTN to SI= P gateway/PBX, for instance). Thus, it can get away with only sending "isd= n-network". But if this is not true, and we have legacy UAS that only accept "isdn-netw= ork", then how does a random UAC know whether it will send "isdn-network" o= r "isdn-uui"? Thoughts? [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9= C-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 ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer From vkg@bell-labs.com Tue Aug 20 06:50:07 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 49A5D11E80F6 for ; Tue, 20 Aug 2013 06:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.083 X-Spam-Level: X-Spam-Status: No, score=-110.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 mxzWuI4oBNHm for ; Tue, 20 Aug 2013 06:50:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77C11E8105 for ; Tue, 20 Aug 2013 06:50:02 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r7KDnvXq017605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Aug 2013 08:49:57 -0500 (CDT) 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 r7KDnu9i016293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Aug 2013 08:49:57 -0500 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 r7KDnu9r028597; Tue, 20 Aug 2013 08:49:56 -0500 (CDT) Message-ID: <5213751E.8060006@bell-labs.com> Date: Tue, 20 Aug 2013 08:54:38 -0500 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: R.Jesske@telekom.de References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BF98B52@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BF98B52@HE111648.emea1.cds.t-internal.com> 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.11 Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 13:50:07 -0000 On 08/20/2013 06:13 AM, R.Jesske@telekom.de wrote: [...] > Could we agree on counting who is OK with this Note? > Or can we have an alternative proposal? Roland: While not an actual count, I would note that all the people who expressed an opinion on this --- except for Paul's observation [1] --- supported the addition of the note with the understanding in [2]. As such, Enrico and I would exhort the authors of the draft to chime in on the mailing list with their acquiescence (or questions) and close this issue by producing a revision as soon as possible. Authors? [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00487.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From atle.monrad@ericsson.com Wed Aug 21 13:54:38 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 85B6E11E8124 for ; Wed, 21 Aug 2013 13:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb3DOzmyKTw9 for ; Wed, 21 Aug 2013 13:54:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1493611E8139 for ; Wed, 21 Aug 2013 13:54:20 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-ed-521528f7be0a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3E.55.22048.7F825125; Wed, 21 Aug 2013 22:54:16 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.129]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 21 Aug 2013 22:54:16 +0200 From: Atle Monrad To: "VAN GEEL Jan (CIS/SCC)" , "Vijay K. Gurbani" , "R.Jesske@telekom.de" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6YM+XqnqqNnfo5QXeS8Bv1lKqV7QBWOXbAAAsJgoAAvY/VUAB/pcGg Date: Wed, 21 Aug 2013 20:54:14 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C183B50@ESESSMB203.ericsson.se> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje4PDdEgg6UnmCxutL9gtthwew+z RdOdLjaLhjVyDiwey2a0s3j0XXbxWLLkJ5NH20uFAJYoLpuU1JzMstQifbsErowrV4QK+iQr njQqNjA+FOli5OSQEDCROHblIhOELSZx4d56ti5GLg4hgcOMEof2XmKEcJYwSqw79Rasik1A R+LczzusIAkRgT5Gic9HzrCCJJgFlCVe/GsFs4WBip4dXM8OYosI6Epce9LGAmG7Sby88xqs hkVAVWJyazsjiM0r4C0x6eoNFohtK5glJjzsB9vGKeAi0XYcJMHBwSggKzG3iRdil7jErSfz oc4WkFiy5zwzhC0q8fLxP1YIW0micckTqNt0JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis1C MnYWkpZZSFpmIWlZwMiyipE9NzEzJ73cfBMjMIoObvltsINx032xQ4zSHCxK4ryb9c4ECgmk J5akZqemFqQWxReV5qQWH2Jk4uCUamDsqO/K+OC2omWGOR+PUktEEZ/72+Wzf07seJiat1lq 8U3W3u2XTDbelv8gMFP6zD2JJSEHPH369vPa7v3y9Pxk7+WJzQr/ylcdeGH/8EBuIpfWL6Gb DcG2tSf5VV4cqlpd183epOP1RPJxRPUGe62ShqW5bz1cX3GFKSTXHnkaWZ3O8v45q5QSS3FG oqEWc1FxIgAURfGHcAIAAA== Cc: "cuss@ietf.org" Subject: Re: [cuss] To "isdn-network" or not 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, 21 Aug 2013 20:54:38 -0000 All I would like to support moving along with text in line with previous discus= sions (i.e. the already identified Note) and not reopen old discussions. We= 'll never be able to complete the draft otherwise. 3GPP has a number of long-lasting drafts that move extremely slowly. I would be happy to report progress on the draft-ietf-cuss-sip-uui-isdn and= the linked and pending draft-ietf-cuss-sip-uui to get this "package" compl= eted and out of the way ;-) Thanks and have a nice day. /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 VAN= GEEL Jan (CIS/SCC) Sent: 19. august 2013 09:43 To: Vijay K. Gurbani; R.Jesske@telekom.de Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not Just for my understanding: If a UAC is allowed to send "isdn-network" isn't it then required that ALL = UAS are able to accept this value ? If yes then I believe a UAC can send either "isdn-network" or "isdn-uui" an= d every UAS needs to understand "isdn-network" and "isdn-uui". As long as the text or note reflects this without leaving room for differen= t interpretation I'm fine. Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vij= ay K. Gurbani Sent: Thursday 15 August 2013 17:11 To: R.Jesske@telekom.de Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > Hi, > does this mean that we add the proposed note? Roland: I believe that Paul's thoughts on this subject [1] deserve a response from = the working group if we are to add this note. My operating assumption when I posted my comment [2] was that the legacy ge= ar that is sending out "isdn-network" is only acting as a UAC (a PSTN to SI= P gateway/PBX, for instance). Thus, it can get away with only sending "isd= n-network". But if this is not true, and we have legacy UAS that only accept "isdn-netw= ork", then how does a random UAC know whether it will send "isdn-network" o= r "isdn-uui"? Thoughts? [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From christer.holmberg@ericsson.com Thu Aug 22 09:30:40 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 09A5111E81F2 for ; Thu, 22 Aug 2013 09:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f365eXwJX+mH for ; Thu, 22 Aug 2013 09:30:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5628C11E80E3 for ; Thu, 22 Aug 2013 09:30:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-46-52163ca9db58 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0A.18.16099.9AC36125; Thu, 22 Aug 2013 18:30:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 18:30:33 +0200 From: Christer Holmberg To: Atle Monrad , "VAN GEEL Jan (CIS/SCC)" , "Vijay K. Gurbani" , "R.Jesske@telekom.de" Thread-Topic: [cuss] To "isdn-network" or not Thread-Index: Ac6VC++r9xgs/yBK7Ee3eyte3ezC2AC9GIUQAAeecPAAATyjAABWGAIAAA807oAAuXzJAACAO9oAAC0yOPA= Date: Thu, 22 Aug 2013 16:30:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C47593B@ESESSMB209.ericsson.se> References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> <7D2F7D7ADBA812449F25F4A69922881C183B50@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C183B50@ESESSMB203.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje4qG7Eggy/9PBY32l8wW2y4vYfZ oulOF5tFwxo5BxaPZTPaWTz6Lrt4LFnyk8mj7aVCAEsUl01Kak5mWWqRvl0CV0bDghnsBQvk Ku4cK2tgbJbsYuTgkBAwkejaw9bFyAlkiklcuLceyObiEBI4zCjx4dEUdpCEkMASRomePnuQ ejYBC4nuf9ogNSICOxgl1v+/wQRSwyygLPHiXysriC0soCPx/OwZZhBbREBX4tqTNhYIO0li 7buPYDUsAqoSd191gdm8Ar4SW74tZIZY/IpZYv/kb+wgyzgFfCQezI4FqWEEOu77qTVQu8Ql Phy8zgxxtIDEkj3noWxRiZeP/7FC2EoSPzZcYoGo15O4MXUKG4StLbFs4WtmiL2CEidnPmGZ wCg2C8nYWUhaZiFpmYWkZQEjyypG9tzEzJz0csNNjMAIOrjlt+4OxlPnRA4xSnOwKInzbtI7 EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0UP4nonEhujyn6deHfz18M2put+Twiebeq15 HvBpskbwzrXyFXeWrOp8269uxXuq/t+e8tMbz/cs2hnNpVsSw/eXuzop7dtd+1+lKumHFl8/ 2KBTeWofi859t6AHWpnq9dtt/DcHb1+5702q/a70Cp22yed68lcI7PD/zL/CzPmTxuROpscn gpRYijMSDbWYi4oTAS+5kvNuAgAA Cc: "cuss@ietf.org" Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 16:30:40 -0000 Hi, I am also ok with the suggested way forward, using a Note. Keep in mind, though, that since the receiver has to be able to parse both = values, they both need to be in the ABNF. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Puole= sta Atle Monrad L=E4hetetty: 21. elokuuta 2013 23:54 Vastaanottaja: VAN GEEL Jan (CIS/SCC); Vijay K. Gurbani; R.Jesske@telekom.d= e Kopio: cuss@ietf.org Aihe: Re: [cuss] To "isdn-network" or not All I would like to support moving along with text in line with previous discus= sions (i.e. the already identified Note) and not reopen old discussions. We= 'll never be able to complete the draft otherwise. 3GPP has a number of long-lasting drafts that move extremely slowly. I would be happy to report progress on the draft-ietf-cuss-sip-uui-isdn and= the linked and pending draft-ietf-cuss-sip-uui to get this "package" compl= eted and out of the way ;-) Thanks and have a nice day. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation Ericss= on -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of VAN= GEEL Jan (CIS/SCC) Sent: 19. august 2013 09:43 To: Vijay K. Gurbani; R.Jesske@telekom.de Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not Just for my understanding: If a UAC is allowed to send "isdn-network" isn't it then required that ALL = UAS are able to accept this value ? If yes then I believe a UAC can send either "isdn-network" or "isdn-uui" an= d every UAS needs to understand "isdn-network" and "isdn-uui". As long as the text or note reflects this without leaving room for differen= t interpretation I'm fine. Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vij= ay K. Gurbani Sent: Thursday 15 August 2013 17:11 To: R.Jesske@telekom.de Cc: cuss@ietf.org Subject: Re: [cuss] To "isdn-network" or not On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: > Hi, > does this mean that we add the proposed note? Roland: I believe that Paul's thoughts on this subject [1] deserve a response from = the working group if we are to add this note. My operating assumption when I posted my comment [2] was that the legacy ge= ar that is sending out "isdn-network" is only acting as a UAC (a PSTN to SI= P gateway/PBX, for instance). Thus, it can get away with only sending "isd= n-network". But if this is not true, and we have legacy UAS that only accept "isdn-netw= ork", then how does a random UAC know whether it will send "isdn-network" o= r "isdn-uui"? Thoughts? [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Thu Aug 22 11:24:47 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 5DF2311E81F8 for ; Thu, 22 Aug 2013 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 xmAwfV5WqEVY for ; Thu, 22 Aug 2013 11:24:41 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86F11E81C5 for ; Thu, 22 Aug 2013 11:24:34 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uz19so4269671obc.21 for ; Thu, 22 Aug 2013 11:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=wucuxm2ybdvvyvXjTWsp09WROHkEQczxsxX1uvKb1jM=; b=FaCmtW9UPQk/XgkFqRzN9VUQhvWXbLyjdmQ6g6NFmwtcoOlQZsZEM+j/y3ml4GyEXr a5WsBJAHshB+yofsCVbNhDLPH1HNhhrhsrYNljm2L3c1cA6l5dLzJq/x5zb68ssE7uBZ lR5JNxIHD14osMqsgK6YRHkr/vAHkZpf+iXoojU7OfHDOpY/Ibi+vl2sYQFwDi6Cbqzv MysDnhbMLqhWTY0p/mBlmXzE2z4eozk31KUaYtAMo8FhL+j5R1rKRrU9I1U+qquhoQ2V cDuuj8OphME45k5Shs2xj+PvdnqhMfwnxoowFXguvBDcBwdLqt+7ODuQ7JN3qmWzVeSw 2CHw== X-Received: by 10.60.145.241 with SMTP id sx17mr15733708oeb.57.1377195874103; Thu, 22 Aug 2013 11:24:34 -0700 (PDT) Received: from [10.54.140.170] ([166.147.97.239]) by mx.google.com with ESMTPSA id qi5sm20352391obb.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 11:24:33 -0700 (PDT) References: <5204F769.9060608@bell-labs.com> <5204FB1F.5090503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BE3EDAD@HE111648.emea1.cds.t-internal.com> <1E97FFD1485F1142BC075FF145A53A1E318B86@A04067.BGC.NET> <520A47CC.5070904@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D183BEC87A3@HE111648.emea1.cds.t-internal.com> <520CEF9D.1060104@bell-labs.com> <1E97FFD1485F1142BC075FF145A53A1E319561@A04067.BGC.NET> <7D2F7D7ADBA812449F25F4A69922881C183B50@ESESSMB203.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C47593B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C47593B@ESESSMB209.ericsson.se> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Alan Johnston Date: Thu, 22 Aug 2013 13:24:29 -0500 To: Christer Holmberg Cc: "cuss@ietf.org" Subject: Re: [cuss] To "isdn-network" or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:24:48 -0000 I agree. Both need to be in the ABNF.=20 - Alan - On Aug 22, 2013, at 11:30 AM, Christer Holmberg wrote: > Hi, >=20 > I am also ok with the suggested way forward, using a Note. >=20 > Keep in mind, though, that since the receiver has to be able to parse both= values, they both need to be in the ABNF. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Alkuper=C3=A4inen viesti----- > L=C3=A4hett=C3=A4j=C3=A4: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.= org] Puolesta Atle Monrad > L=C3=A4hetetty: 21. elokuuta 2013 23:54 > Vastaanottaja: VAN GEEL Jan (CIS/SCC); Vijay K. Gurbani; R.Jesske@telekom.= de > Kopio: cuss@ietf.org > Aihe: Re: [cuss] To "isdn-network" or not >=20 > All >=20 > I would like to support moving along with text in line with previous discu= ssions (i.e. the already identified Note) and not reopen old discussions. We= 'll never be able to complete the draft otherwise. >=20 > 3GPP has a number of long-lasting drafts that move extremely slowly. > I would be happy to report progress on the draft-ietf-cuss-sip-uui-isdn an= d the linked and pending draft-ietf-cuss-sip-uui to get this "package" compl= eted and out of the way ;-) >=20 > Thanks and have a nice day. > /atle >=20 > ________________________________=20 >=20 >=20 > Atle Monrad > 3GPP CT Chairman >=20 > Group Function Technology - Standardization and Technical Regulation Erics= son >=20 >=20 >=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of VA= N GEEL Jan (CIS/SCC) > Sent: 19. august 2013 09:43 > To: Vijay K. Gurbani; R.Jesske@telekom.de > Cc: cuss@ietf.org > Subject: Re: [cuss] To "isdn-network" or not >=20 > Just for my understanding: >=20 > If a UAC is allowed to send "isdn-network" isn't it then required that ALL= UAS are able to accept this value ? >=20 > If yes then I believe a UAC can send either "isdn-network" or "isdn-uui" a= nd every UAS needs to understand "isdn-network" and "isdn-uui". > As long as the text or note reflects this without leaving room for differe= nt interpretation I'm fine. >=20 > Kind regards >=20 >=20 > Jan Van Geel > IT and Network Specialist > Belgacom CIS/SCC/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be >=20 >=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vi= jay K. Gurbani > Sent: Thursday 15 August 2013 17:11 > To: R.Jesske@telekom.de > Cc: cuss@ietf.org > Subject: Re: [cuss] To "isdn-network" or not >=20 > On 08/15/2013 02:56 AM, R.Jesske@telekom.de wrote: >> Hi, >> does this mean that we add the proposed note? >=20 > Roland: >=20 > I believe that Paul's thoughts on this subject [1] deserve a response from= the working group if we are to add this note. >=20 > My operating assumption when I posted my comment [2] was that the legacy g= ear that is sending out "isdn-network" is only acting as a UAC (a PSTN to SI= P gateway/PBX, for instance). Thus, it can get away with only sending "isdn= -network". >=20 > But if this is not true, and we have legacy UAS that only accept "isdn-net= work", then how does a random UAC know whether it will send "isdn-network" o= r "isdn-uui"? >=20 > Thoughts? >=20 > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00484.html > [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00485.html >=20 > Thanks, >=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: http://goo.gl/x3Ogq __= _____________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 > ________________________________ >=20 > ***** Disclaimer ***** > http://www.belgacom.be/maildisclaimer > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss