From vkg@bell-labs.com Thu Nov 1 05:44:31 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D3A21F8A6B for ; Thu, 1 Nov 2012 05:44:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHcmN+JrR9r2 for ; Thu, 1 Nov 2012 05:44:31 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1F92021F8ADF for ; Thu, 1 Nov 2012 05:44:31 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id qA1CiUrL001116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Nov 2012 07:44:30 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qA1CiTU2016749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Nov 2012 07:44:30 -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 qA1CiTiG014750 for ; Thu, 1 Nov 2012 07:44:29 -0500 (CDT) Message-ID: <50926EF3.2000908@bell-labs.com> Date: Thu, 01 Nov 2012 07:45:39 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: cuss@ietf.org References: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> In-Reply-To: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; 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.12 Subject: [cuss] Fwd: Help the NomCom: Community Feedback X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 12:44:32 -0000 Folks: Please help provide community feedback to NomCom in evaluating candidates for open positions. Please see email below for more instructions. Thank you. -------- Original Message -------- Subject: Help the NomCom: Community Feedback Date: Wed, 31 Oct 2012 20:13:18 -0700 From: NomCom Chair To: Working Group Chairs The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 4. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Thu Nov 1 06:44:33 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E221F8E70 for ; Thu, 1 Nov 2012 06:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsaWiKL55AAX for ; Thu, 1 Nov 2012 06:44:32 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9C28321F8E76 for ; Thu, 1 Nov 2012 06:44:32 -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 qA1DiUlk026921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Nov 2012 08:44:31 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qA1DiT6N013083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Nov 2012 08:44:30 -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 qA1DiTAH019771 for ; Thu, 1 Nov 2012 08:44:29 -0500 (CDT) Message-ID: <50927D03.9000207@bell-labs.com> Date: Thu, 01 Nov 2012 08:45:39 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: 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] Fwd: Re: [85all] NomCom: Office Hours in Atlanta X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:44:34 -0000 -------- Original Message -------- Subject: Re: [85all] NomCom: Office Hours in Atlanta Date: Thu, 1 Nov 2012 08:22:48 -0400 From: Matthew Lepinski To: 85all@ietf.org I apologize for a minor error in the message below. In order to ensure that your input is useful to the NomCom, please send us your feedback on or before Sunday, November 11. (i.e., NOT November 4 as incorrectly indicated in the email below) - Matt Lepinski nomcom-chair@ietf.org On Wed, Oct 31, 2012 at 11:09 PM, Matthew Lepinski wrote: > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. > > The final list of candidates (as per RFC 5680) that the NomCom is > considering for open positions can be found at: > https://www.ietf.org/group/nomcom/2012/input/ > > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes > comments on specific individuals, as well as general feedback related to > any of the positions that NomCom is considering. > > Note: A list of leadership positions that the NomCom is considering can be > found at: https://www.ietf.org/group/nomcom/2012/ > > If the NomCom office hours are inconvenient for you or if you cannot > attend IETF 85, the NomCom is happy to take community input via email > to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a > meeting outside of office hours, just send us email and we can set > something up. > > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool: > https://www.ietf.org/group/nomcom/2012/input/ > > In order to ensure that your input is received in time to be useful, please > provide your input on or before Sunday, November 4. > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org _______________________________________________ 85all mailing list 85all@ietf.org https://www.ietf.org/mailman/listinfo/85all - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From keith.drage@alcatel-lucent.com Thu Nov 8 15:07:16 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390A821F880A for ; Thu, 8 Nov 2012 15:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.014 X-Spam-Level: X-Spam-Status: No, score=-110.014 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoG15S84xv+9 for ; Thu, 8 Nov 2012 15:07:15 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4185221F84BF for ; Thu, 8 Nov 2012 15:07:15 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8N6uYk026821 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Nov 2012 00:07:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 9 Nov 2012 00:07:09 +0100 From: "DRAGE, Keith (Keith)" To: "R.Jesske@telekom.de" , "celine.serrutvalette@orange.com" Date: Fri, 9 Nov 2012 00:07:07 +0100 Thread-Topic: [cuss] Status of cuss documents => purpose parameter value for ISDN Thread-Index: AQHNRLc3g2ez5iy82E2mZ4bOsx7495cRIkxggAmoVnCAACNB8IAFtu2wgMDcPaA= Message-ID: References: <4FD0B77D.2010501@bell-labs.com> <20778_1341499470_4FF5A84E_20778_8501_1_F8BE5641EC3C954DA088A8350BDDFA4801B334@PEXCVZYM13.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D14752FC04A@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D14752FC04A@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "cuss@ietf.org" Subject: Re: [cuss] Status of cuss documents => purpose parameter value for ISDN X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:07:16 -0000 So I am trying to work out how to address this comment from the WGLC. It is claimed a note is required, but the proposed text contains a normativ= e statement of SHOULD strength, but there is no proposal to update the ABNF= . So I need to ask, what is the proposal. Is it: 1) to make a normative requirement of SHOULD strength to provide this as a = coding capability. OR 2) to provide an informative statement that some implementations outside of= conformance of this specification, will use this value, and therefore othe= rs might want to support it. It would also be useful to understand what others from the working group wa= nt to do. Regards Keith > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: 09 July 2012 06:54 > To: celine.serrutvalette@orange.com; DRAGE, Keith (Keith) > Cc: cuss@ietf.org > Subject: AW: [cuss] Status of cuss documents =3D> purpose parameter value > for ISDN >=20 > Hi, > I can agree on such a note. >=20 > BR >=20 > Roland Jesske >=20 > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von > celine.serrutvalette@orange.com > Gesendet: Donnerstag, 5. Juli 2012 16:44 > An: keith.drage@alcatel-lucent.com > Cc: cuss@ietf.org > Betreff: Re: [cuss] Status of cuss documents =3D> purpose parameter value > for ISDN >=20 > Hello, >=20 > Since you may be currently updating the documents with the remarks > received from WGLC review, I would like to come back again on a topic > previously discussed (see http://www.ietf.org/mail- > archive/web/cuss/current/msg00355.html-comment C10 and > http://www.ietf.org/mail-archive/web/cuss/current/msg00418.html): the > value of purpose parameter for ISDN. > Indeed, some implementations are currently generating purpose=3D"isdn- > interwork" (as indicated in draft-johnston-sipping-cc-uui-08) so this wil= l > cause a backward compatibility issue because currently in the ISDN draft, > if present, purpose parameter value MUST be set to "isdn-uui" and, if > received, its value MUST be set to "isdn-uui", otherwise the header would > be discarded (as described in sections 7 and 8 of the ISDN draft) and the > interworking not performed. >=20 > Since some implementations may already be using purpose=3D"isdn-uui", it = may > not be acceptable to simply change it back to purpose=3D"isdn-interwork". > Therefore, I propose as a compromise to add the following note along the > line of what has been done in draft-ietf-bfcpbis-rfc4583bis-01 (section 6= ) > for BFCP topic: >=20 > Note: 'isdn-interwork' value for purpose parameter was used in Internet- > 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 implemented > by some vendors. Therefore, it is RECOMMENDED to support parsing and > interpreting 'isdn-interwork' the same way as 'isdn-uui' when receiving. >=20 > Regards, >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de > Vijay K. Gurbani Envoy=E9 : jeudi 7 juin 2012 16:15 =C0 : cuss@ietf.org > Objet : [cuss] Status of cuss documents >=20 > Folks: The WGLC date for the two remaining documents has passed. >=20 > The WG received a WGLC review on draft-ietf-cuss-sip-uui-06 courtesy of > Laura Liess. >=20 > The review for draft-ietf-cuss-sip-uui-isdn-04 is still pending, and > should be out by next week. >=20 > In the meantime, could the authors of draft-ietf-cuss-sip-uui please star= t > to address the WGLC comments and sent out a revision addressing the > comments? >=20 > To the extent that there are dependencies between these two drafts, I > suspect that cuss-sip-uui-isdn depends on cuss-sip-uui. Thus we can star= t > preparation for cuss-sip-uui while we wait for the WGLC review of cuss- > sip-uui-isdn. >=20 > Thanks, >=20 > Vijay K. Gurbani and Enrico Marocco >=20 > _______________________________________________ > 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'alteratio= n, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou 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, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Fri Nov 9 09:12:49 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191C21F8652 for ; Fri, 9 Nov 2012 09:12:48 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwnVYAvjd6JT for ; Fri, 9 Nov 2012 09:12:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2202121F84E9 for ; Fri, 9 Nov 2012 09:12:46 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5B1D63B4231; Fri, 9 Nov 2012 18:12:45 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2CFDD4C06E; Fri, 9 Nov 2012 18:12:45 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 9 Nov 2012 18:12:44 +0100 From: To: "DRAGE, Keith (Keith)" Thread-Topic: [cuss] Status of cuss documents => purpose parameter value for ISDN Thread-Index: AQHNRLc3g2ez5iy82E2mZ4bOsx7495cRIkxggAmoVnCAACNB8IAFtu2wgMDcPaCAAS8DoA== Date: Fri, 9 Nov 2012 17:12:44 +0000 Message-ID: <4902_1352481165_509D398D_4902_7253_4_F8BE5641EC3C954DA088A8350BDDFA48070788@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <4FD0B77D.2010501@bell-labs.com> <20778_1341499470_4FF5A84E_20778_8501_1_F8BE5641EC3C954DA088A8350BDDFA4801B334@PEXCVZYM13.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D14752FC04A@HE111648.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] 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: 2012.11.9.141533 Cc: "cuss@ietf.org" Subject: Re: [cuss] Status of cuss documents => purpose parameter value for ISDN X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:12:49 -0000 Hello, Thank you for your answer. We would prefer a normative requirement (1/ prop= osal) to indicate that equipment SHOULD interpret 'isdn-interwork' the same= way as 'isdn-uui' when receiving (and even that it MUST interpret it the s= ame way).=20 Indeed, informative requirement (2/ proposal) would not be sufficient to en= sure that any equipment will correctly interpret 'isdn-interwork' when rece= iving, what could lead to lose the IUU data if not (in that case the equipm= ent will discard the User-to-User header and for instance if it's a MGCF, i= t will not perform the SIP/ISUP interworking). Concerning your comment on ABNF, we followed the same approach as what has = been done in draft-ietf-bfcpbis-rfc4583bis-01, that's why we didn't modify = the ABNF accordingly, but we agree to update it if you think it is a better= way to proceed. Regards Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Envoy=E9=A0: vendredi 9 novembre 2012 00:07 =C0=A0: R.Jesske@telekom.de; SERRUT-VALETTE Celine OLNC/OLN Cc=A0: cuss@ietf.org Objet=A0: RE: [cuss] Status of cuss documents =3D> purpose parameter value = for ISDN So I am trying to work out how to address this comment from the WGLC. It is claimed a note is required, but the proposed text contains a normativ= e statement of SHOULD strength, but there is no proposal to update the ABNF. So I need to ask, what is the proposal. Is it: 1) to make a normative requirement of SHOULD strength to provide this as a = coding capability. OR 2) to provide an informative statement that some implementations outside of= conformance of this specification, will use this value, and therefore othe= rs might want to support it. It would also be useful to understand what others from the working group wa= nt to do. Regards Keith > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: 09 July 2012 06:54 > To: celine.serrutvalette@orange.com; DRAGE, Keith (Keith) > Cc: cuss@ietf.org > Subject: AW: [cuss] Status of cuss documents =3D> purpose parameter=20 > value for ISDN >=20 > Hi, > I can agree on such a note. >=20 > BR >=20 > Roland Jesske >=20 > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag=20 > von celine.serrutvalette@orange.com > Gesendet: Donnerstag, 5. Juli 2012 16:44 > An: keith.drage@alcatel-lucent.com > Cc: cuss@ietf.org > Betreff: Re: [cuss] Status of cuss documents =3D> purpose parameter=20 > value for ISDN >=20 > Hello, >=20 > Since you may be currently updating the documents with the remarks=20 > received from WGLC review, I would like to come back again on a topic=20 > previously discussed (see http://www.ietf.org/mail-=20 > archive/web/cuss/current/msg00355.html-comment C10 and > http://www.ietf.org/mail-archive/web/cuss/current/msg00418.html): the=20 > value of purpose parameter for ISDN. > Indeed, some implementations are currently generating purpose=3D"isdn-=20 > interwork" (as indicated in draft-johnston-sipping-cc-uui-08) so this=20 > will cause a backward compatibility issue because currently in the=20 > ISDN draft, if present, purpose parameter value MUST be set to=20 > "isdn-uui" and, if received, its value MUST be set to "isdn-uui",=20 > otherwise the header would be discarded (as described in sections 7=20 > and 8 of the ISDN draft) and the interworking not performed. >=20 > Since some implementations may already be using purpose=3D"isdn-uui", it= =20 > may not be acceptable to simply change it back to purpose=3D"isdn-interwo= rk". > Therefore, I propose as a compromise to add the following note along=20 > the line of what has been done in draft-ietf-bfcpbis-rfc4583bis-01=20 > (section 6) for BFCP topic: >=20 > Note: 'isdn-interwork' value for purpose parameter was used in=20 > Internet- Drafts that have led to the publication of the present RFC.=20 > Although these documents had not other status than "work in progress",=20 > it is implemented by some vendors. Therefore, it is RECOMMENDED to=20 > support parsing and interpreting 'isdn-interwork' the same way as 'isdn-u= ui' when receiving. >=20 > Regards, >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part=20 > de Vijay K. Gurbani Envoy=E9 : jeudi 7 juin 2012 16:15 =C0 : cuss@ietf.or= g=20 > Objet : [cuss] Status of cuss documents >=20 > Folks: The WGLC date for the two remaining documents has passed. >=20 > The WG received a WGLC review on draft-ietf-cuss-sip-uui-06 courtesy=20 > of Laura Liess. >=20 > The review for draft-ietf-cuss-sip-uui-isdn-04 is still pending, and=20 > should be out by next week. >=20 > In the meantime, could the authors of draft-ietf-cuss-sip-uui please=20 > start to address the WGLC comments and sent out a revision addressing=20 > the comments? >=20 > To the extent that there are dependencies between these two drafts, I=20 > suspect that cuss-sip-uui-isdn depends on cuss-sip-uui. Thus we can=20 > start preparation for cuss-sip-uui while we wait for the WGLC review=20 > of cuss- sip-uui-isdn. >=20 > Thanks, >=20 > Vijay K. Gurbani and Enrico Marocco >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 > ______________________________________________________________________ > ____ _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for=20 > messages that have been modified, changed or falsified. > Thank you. >=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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From keith.drage@alcatel-lucent.com Fri Nov 9 09:16:41 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35A121F87C1 for ; Fri, 9 Nov 2012 09:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.027 X-Spam-Level: X-Spam-Status: No, score=-110.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6xb4m5cDC38 for ; Fri, 9 Nov 2012 09:16:40 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id C281F21F87BD for ; Fri, 9 Nov 2012 09:16:39 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA9HGCFL018026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Nov 2012 18:16:38 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 9 Nov 2012 18:16:25 +0100 From: "DRAGE, Keith (Keith)" To: "celine.serrutvalette@orange.com" Date: Fri, 9 Nov 2012 18:16:24 +0100 Thread-Topic: [cuss] Status of cuss documents => purpose parameter value for ISDN Thread-Index: AQHNRLc3g2ez5iy82E2mZ4bOsx7495cRIkxggAmoVnCAACNB8IAFtu2wgMDcPaCAAS8DoIAAAgnA Message-ID: References: <4FD0B77D.2010501@bell-labs.com> <20778_1341499470_4FF5A84E_20778_8501_1_F8BE5641EC3C954DA088A8350BDDFA4801B334@PEXCVZYM13.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D14752FC04A@HE111648.emea1.cds.t-internal.com> <4902_1352481165_509D398D_4902_7253_4_F8BE5641EC3C954DA088A8350BDDFA48070788@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <4902_1352481165_509D398D_4902_7253_4_F8BE5641EC3C954DA088A8350BDDFA48070788@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "cuss@ietf.org" Subject: Re: [cuss] Status of cuss documents => purpose parameter value for ISDN X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:16:41 -0000 The previous version of BFCPbis exists as a full RFC. So that has the norma= tive definition. The situation is not the same here. Obviously I still seek other views on this change.=20 Keith > -----Original Message----- > From: celine.serrutvalette@orange.com > [mailto:celine.serrutvalette@orange.com] > Sent: 09 November 2012 17:13 > To: DRAGE, Keith (Keith) > Cc: cuss@ietf.org; R.Jesske@telekom.de > Subject: RE: [cuss] Status of cuss documents =3D> purpose parameter value > for ISDN >=20 > Hello, >=20 > Thank you for your answer. We would prefer a normative requirement (1/ > proposal) to indicate that equipment SHOULD interpret 'isdn-interwork' th= e > same way as 'isdn-uui' when receiving (and even that it MUST interpret it > the same way). > Indeed, informative requirement (2/ proposal) would not be sufficient to > ensure that any equipment will correctly interpret 'isdn-interwork' when > receiving, what could lead to lose the IUU data if not (in that case the > equipment will discard the User-to-User header and for instance if it's a > MGCF, it will not perform the SIP/ISUP interworking). > Concerning your comment on ABNF, we followed the same approach as what ha= s > been done in draft-ietf-bfcpbis-rfc4583bis-01, that's why we didn't modif= y > the ABNF accordingly, but we agree to update it if you think it is a > better way to proceed. >=20 > Regards >=20 > Celine Serrut-Valette > Orange Labs >=20 > -----Message d'origine----- > De=A0: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Envoy=E9=A0: vendredi 9 novembre 2012 00:07 > =C0=A0: R.Jesske@telekom.de; SERRUT-VALETTE Celine OLNC/OLN > Cc=A0: cuss@ietf.org > Objet=A0: RE: [cuss] Status of cuss documents =3D> purpose parameter valu= e for > ISDN >=20 > So I am trying to work out how to address this comment from the WGLC. >=20 > It is claimed a note is required, but the proposed text contains a > normative statement of SHOULD strength, but there is no proposal to updat= e > the ABNF. >=20 > So I need to ask, what is the proposal. Is it: >=20 > 1) to make a normative requirement of SHOULD strength to provide this > as a coding capability. >=20 > OR >=20 > 2) to provide an informative statement that some implementations > outside of conformance of this specification, will use this value, and > therefore others might want to support it. >=20 > It would also be useful to understand what others from the working group > want to do. >=20 > Regards >=20 > Keith >=20 >=20 >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: 09 July 2012 06:54 > > To: celine.serrutvalette@orange.com; DRAGE, Keith (Keith) > > Cc: cuss@ietf.org > > Subject: AW: [cuss] Status of cuss documents =3D> purpose parameter > > value for ISDN > > > > Hi, > > I can agree on such a note. > > > > BR > > > > Roland Jesske > > > > -----Urspr=FCngliche Nachricht----- > > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag > > von celine.serrutvalette@orange.com > > Gesendet: Donnerstag, 5. Juli 2012 16:44 > > An: keith.drage@alcatel-lucent.com > > Cc: cuss@ietf.org > > Betreff: Re: [cuss] Status of cuss documents =3D> purpose parameter > > value for ISDN > > > > Hello, > > > > Since you may be currently updating the documents with the remarks > > received from WGLC review, I would like to come back again on a topic > > previously discussed (see http://www.ietf.org/mail- > > archive/web/cuss/current/msg00355.html-comment C10 and > > http://www.ietf.org/mail-archive/web/cuss/current/msg00418.html): the > > value of purpose parameter for ISDN. > > Indeed, some implementations are currently generating purpose=3D"isdn- > > interwork" (as indicated in draft-johnston-sipping-cc-uui-08) so this > > will cause a backward compatibility issue because currently in the > > ISDN draft, if present, purpose parameter value MUST be set to > > "isdn-uui" and, if received, its value MUST be set to "isdn-uui", > > otherwise the header would be discarded (as described in sections 7 > > and 8 of the ISDN draft) and the interworking not performed. > > > > Since some implementations may already be using purpose=3D"isdn-uui", i= t > > may not be acceptable to simply change it back to purpose=3D"isdn- > interwork". > > Therefore, I propose as a compromise to add the following note along > > the line of what has been done in draft-ietf-bfcpbis-rfc4583bis-01 > > (section 6) for BFCP topic: > > > > 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. > > > > Regards, > > > > Celine Serrut-Valette > > Orange Labs > > > > -----Message d'origine----- > > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part > > de Vijay K. Gurbani Envoy=E9 : jeudi 7 juin 2012 16:15 =C0 : cuss@ietf.= org > > Objet : [cuss] Status of cuss documents > > > > Folks: The WGLC date for the two remaining documents has passed. > > > > The WG received a WGLC review on draft-ietf-cuss-sip-uui-06 courtesy > > of Laura Liess. > > > > The review for draft-ietf-cuss-sip-uui-isdn-04 is still pending, and > > should be out by next week. > > > > In the meantime, could the authors of draft-ietf-cuss-sip-uui please > > start to address the WGLC comments and sent out a revision addressing > > the comments? > > > > To the extent that there are dependencies between these two drafts, I > > suspect that cuss-sip-uui-isdn depends on cuss-sip-uui. Thus we can > > start preparation for cuss-sip-uui while we wait for the WGLC review > > of cuss- sip-uui-isdn. > > > > Thanks, > > > > Vijay K. Gurbani and Enrico Marocco > > > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > > > ______________________________________________________________________ > > ____ _______________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > 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, France Telecom - Orange decline toute responsabilite si > > ce message a ete altere, deforme ou falsifie. Merci. > > > > 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, France Telecom - Orange is not liable for > > messages that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss >=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, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou 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, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. From pkyzivat@alum.mit.edu Mon Nov 12 07:11:11 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABB121F85A2 for ; Mon, 12 Nov 2012 07:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgIjKsnPROeT for ; Mon, 12 Nov 2012 07:11:10 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 98F2121F85C2 for ; Mon, 12 Nov 2012 07:11:07 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id NanX1k00E1vXlb851fB7Qt; Mon, 12 Nov 2012 15:11:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Nf971k0033ZTu2S3df978G; Mon, 12 Nov 2012 15:09:07 +0000 Message-ID: <50A1111C.1040607@alum.mit.edu> Date: Mon, 12 Nov 2012 10:09:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: cuss@ietf.org References: <4FD0B77D.2010501@bell-labs.com> <20778_1341499470_4FF5A84E_20778_8501_1_F8BE5641EC3C954DA088A8350BDDFA4801B334@PEXCVZYM13.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D14752FC04A@HE111648.emea1.cds.t-internal.com> <4902_1352481165_509D398D_4902_7253_4_F8BE5641EC3C954DA088A8350BDDFA48070788@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [cuss] Status of cuss documents => purpose parameter value for ISDN X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:11:11 -0000 On 11/9/12 12:16 PM, DRAGE, Keith (Keith) wrote: > The previous version of BFCPbis exists as a full RFC. So that has the normative definition. The situation is not the same here. > > Obviously I still seek other views on this change. I don't care one way or the other. Thanks, Paul > Keith > >> -----Original Message----- >> From: celine.serrutvalette@orange.com >> [mailto:celine.serrutvalette@orange.com] >> Sent: 09 November 2012 17:13 >> To: DRAGE, Keith (Keith) >> Cc: cuss@ietf.org; R.Jesske@telekom.de >> Subject: RE: [cuss] Status of cuss documents => purpose parameter value >> for ISDN >> >> Hello, >> >> Thank you for your answer. We would prefer a normative requirement (1/ >> proposal) to indicate that equipment SHOULD interpret 'isdn-interwork' the >> same way as 'isdn-uui' when receiving (and even that it MUST interpret it >> the same way). >> Indeed, informative requirement (2/ proposal) would not be sufficient to >> ensure that any equipment will correctly interpret 'isdn-interwork' when >> receiving, what could lead to lose the IUU data if not (in that case the >> equipment will discard the User-to-User header and for instance if it's a >> MGCF, it will not perform the SIP/ISUP interworking). >> Concerning your comment on ABNF, we followed the same approach as what has >> been done in draft-ietf-bfcpbis-rfc4583bis-01, that's why we didn't modify >> the ABNF accordingly, but we agree to update it if you think it is a >> better way to proceed. >> >> Regards >> >> Celine Serrut-Valette >> Orange Labs >> >> -----Message d'origine----- >> De : DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] >> Envoyé : vendredi 9 novembre 2012 00:07 >> À : R.Jesske@telekom.de; SERRUT-VALETTE Celine OLNC/OLN >> Cc : cuss@ietf.org >> Objet : RE: [cuss] Status of cuss documents => purpose parameter value for >> ISDN >> >> So I am trying to work out how to address this comment from the WGLC. >> >> It is claimed a note is required, but the proposed text contains a >> normative statement of SHOULD strength, but there is no proposal to update >> the ABNF. >> >> So I need to ask, what is the proposal. Is it: >> >> 1) to make a normative requirement of SHOULD strength to provide this >> as a coding capability. >> >> OR >> >> 2) to provide an informative statement that some implementations >> outside of conformance of this specification, will use this value, and >> therefore others might want to support it. >> >> It would also be useful to understand what others from the working group >> want to do. >> >> Regards >> >> Keith >> >> >> >>> -----Original Message----- >>> From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] >>> Sent: 09 July 2012 06:54 >>> To: celine.serrutvalette@orange.com; DRAGE, Keith (Keith) >>> Cc: cuss@ietf.org >>> Subject: AW: [cuss] Status of cuss documents => purpose parameter >>> value for ISDN >>> >>> Hi, >>> I can agree on such a note. >>> >>> BR >>> >>> Roland Jesske >>> >>> -----Ursprüngliche Nachricht----- >>> Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag >>> von celine.serrutvalette@orange.com >>> Gesendet: Donnerstag, 5. Juli 2012 16:44 >>> An: keith.drage@alcatel-lucent.com >>> Cc: cuss@ietf.org >>> Betreff: Re: [cuss] Status of cuss documents => purpose parameter >>> value for ISDN >>> >>> Hello, >>> >>> Since you may be currently updating the documents with the remarks >>> received from WGLC review, I would like to come back again on a topic >>> previously discussed (see http://www.ietf.org/mail- >>> archive/web/cuss/current/msg00355.html-comment C10 and >>> http://www.ietf.org/mail-archive/web/cuss/current/msg00418.html): the >>> value of purpose parameter for ISDN. >>> Indeed, some implementations are currently generating purpose="isdn- >>> interwork" (as indicated in draft-johnston-sipping-cc-uui-08) so this >>> will cause a backward compatibility issue because currently in the >>> ISDN draft, if present, purpose parameter value MUST be set to >>> "isdn-uui" and, if received, its value MUST be set to "isdn-uui", >>> otherwise the header would be discarded (as described in sections 7 >>> and 8 of the ISDN draft) and the interworking not performed. >>> >>> Since some implementations may already be using purpose="isdn-uui", it >>> may not be acceptable to simply change it back to purpose="isdn- >> interwork". >>> Therefore, I propose as a compromise to add the following note along >>> the line of what has been done in draft-ietf-bfcpbis-rfc4583bis-01 >>> (section 6) for BFCP topic: >>> >>> 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. >>> >>> Regards, >>> >>> Celine Serrut-Valette >>> Orange Labs >>> >>> -----Message d'origine----- >>> De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part >>> de Vijay K. Gurbani Envoyé : jeudi 7 juin 2012 16:15 À : cuss@ietf.org >>> Objet : [cuss] Status of cuss documents >>> >>> Folks: The WGLC date for the two remaining documents has passed. >>> >>> The WG received a WGLC review on draft-ietf-cuss-sip-uui-06 courtesy >>> of Laura Liess. >>> >>> The review for draft-ietf-cuss-sip-uui-isdn-04 is still pending, and >>> should be out by next week. >>> >>> In the meantime, could the authors of draft-ietf-cuss-sip-uui please >>> start to address the WGLC comments and sent out a revision addressing >>> the comments? >>> >>> To the extent that there are dependencies between these two drafts, I >>> suspect that cuss-sip-uui-isdn depends on cuss-sip-uui. Thus we can >>> start preparation for cuss-sip-uui while we wait for the WGLC review >>> of cuss- sip-uui-isdn. >>> >>> Thanks, >>> >>> Vijay K. Gurbani and Enrico Marocco >>> >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>> >>> ______________________________________________________________________ >>> ____ _______________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> 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, France Telecom - Orange decline toute responsabilite si >>> ce message a ete altere, deforme ou falsifie. Merci. >>> >>> 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, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >> >> __________________________________________________________________________ >> _______________________________________________ >> >> 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, >> France Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> 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, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >