From vkg@bell-labs.com Fri Feb 8 08:26:28 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 59FD821F8AB6 for ; Fri, 8 Feb 2013 08:26:28 -0800 (PST) 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 8U6M7ifKlJCZ for ; Fri, 8 Feb 2013 08:26:27 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBA021F8AB4 for ; Fri, 8 Feb 2013 08:26:27 -0800 (PST) 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 r18GQQCH006613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Feb 2013 10:26:26 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r18GQPR2018169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 8 Feb 2013 10:26:26 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r18GQPjP021390 for ; Fri, 8 Feb 2013 10:26:25 -0600 (CST) Message-ID: <511527BC.6080909@bell-labs.com> Date: Fri, 08 Feb 2013 10:28:44 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Call for opinion ends on IANA policy for new packages 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, 08 Feb 2013 16:26:28 -0000 All: As per the email on the list on Jan 14, 2013 [1], the call for opinions on whether we proceed with "Standards Action" for ' draft-ietf-cuss-sip-uui-08 has now expired. In the absence of any additional communications since [1], it is understood that we will proceed with "Standards Action". Enrico and I will like to invite the authors of draft-ietf-cuss-sip-uui-08 to release a new version reflecting this change and other minor changes suggested by the AD. As soon as the new version is available, we can move the draft ahead in its current state of publication requested. Regarding the ISDN use case, the authors are also invited to release a new version so we can move this draft ahead. A final note: we are not meeting f2f in Orlando. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00455.html Thank you, - 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 Wed Feb 20 04:04:32 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 8146821F87C5 for ; Wed, 20 Feb 2013 04:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.162 X-Spam-Level: X-Spam-Status: No, score=-109.162 tagged_above=-999 required=5 tests=[AWL=1.087, 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 Qlx5BFiZQ4xG for ; Wed, 20 Feb 2013 04:04:31 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9501321F87A3 for ; Wed, 20 Feb 2013 04:04:31 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1KC4Ois019953 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 20 Feb 2013 13:04:29 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 20 Feb 2013 13:04:26 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Wed, 20 Feb 2013 13:04:25 +0100 Thread-Topic: ABNF in UUI documents Thread-Index: Ac4PYZo4S9Okq4HwRriq+GX6n1hdYg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [cuss] ABNF in UUI documents 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, 20 Feb 2013 12:04:32 -0000 I make the ABNF more formal in the UUISDN document, and that requires a cha= nge to the UUI document. Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. 11. Coding requirements This document defines "isdn-uui" as a new value of the User-to-User "purpose" header field parameter. This document defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. A content value of "isdn-uui" indicates that the contents have a first octet that is a protocol discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] followed by uui-data that can be subject to a length limitation (before encoding or after decoding) that is generally 128 octets. My question is whether this should define BNF to add this to the BNF of dra= ft-ietf-cuss-sip-uui which is currently. UUI =3D "User-to-User" HCOLON uui-value *(COMMA uui-value) uui-value =3D uui-data *(SEMI uui-param) uui-data =3D token / quoted-string uui-param =3D pkg-param / cont-param / enc-param / generic-param pkg-param =3D "purpose" EQUAL token cont-param =3D "content" EQUAL token enc-param =3D "encoding" EQUAL ("hex" / token) If we did this I guess it would look something like: pkg-param =3D "purpose" EQUAL "isdn-uui" / token cont-param =3D "content" EQUAL "isdn-uui" / token Originally I was thinking we could do something like pkg-param-value /=3D "isdn-uui" but that would require an update to draft-ietf-cuss-sip-uui to do: pkg-param =3D "purpose" EQUAL pkg-param-value pkg-param-value =3D token Can we make this change to the UUI document, and I'll then follow through w= ith the UUI ISDN document? regards Keith From thomas.belling@nsn.com Wed Feb 20 06:44: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 B968221F87ED for ; Wed, 20 Feb 2013 06:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSgAGTCHKdqL for ; Wed, 20 Feb 2013 06:44:21 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B6C7E21F8700 for ; Wed, 20 Feb 2013 06:44:20 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r1KEh6hW003068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 15:43:06 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r1KEh4Dc019861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 15:43:04 +0100 Received: from DEMUMBX002.nsn-intra.net ([169.254.3.238]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.02.0328.009; Wed, 20 Feb 2013 15:43:04 +0100 From: "Belling, Thomas (NSN - DE/Munich)" To: "ext DRAGE, Keith (Keith)" Thread-Topic: ABNF in UUI documents Thread-Index: Ac4PYZo4S9Okq4HwRriq+GX6n1hdYgAFkY6g Date: Wed, 20 Feb 2013 14:43:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2482 X-purgate-ID: 151667::1361371386-00001023-CF28E6DB/0-0/0-0 Cc: "cuss@ietf.org" Subject: Re: [cuss] ABNF in UUI documents 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, 20 Feb 2013 14:44:21 -0000 Hi Keith, your alternatives look a bit like a beauty competition. But we need to get = the drafts stable and published the sooner the better. I would thus have a= slight preference for your first alternative that does not require updates= of draft-ietf-cuss-sip-uui-isdn-04. Thomas -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext= DRAGE, Keith (Keith) Sent: Wednesday, February 20, 2013 1:04 PM To: cuss@ietf.org Subject: [cuss] ABNF in UUI documents I make the ABNF more formal in the UUISDN document, and that requires a cha= nge to the UUI document. Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. 11. Coding requirements This document defines "isdn-uui" as a new value of the User-to-User "purpose" header field parameter. This document defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. A content value of "isdn-uui" indicates that the contents have a first octet that is a protocol discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] followed by uui-data that can be subject to a length limitation (before encoding or after decoding) that is generally 128 octets. My question is whether this should define BNF to add this to the BNF of dra= ft-ietf-cuss-sip-uui which is currently. UUI =3D "User-to-User" HCOLON uui-value *(COMMA uui-value) uui-value =3D uui-data *(SEMI uui-param) uui-data =3D token / quoted-string uui-param =3D pkg-param / cont-param / enc-param / generic-param pkg-param =3D "purpose" EQUAL token cont-param =3D "content" EQUAL token enc-param =3D "encoding" EQUAL ("hex" / token) If we did this I guess it would look something like: pkg-param =3D "purpose" EQUAL "isdn-uui" / token cont-param =3D "content" EQUAL "isdn-uui" / token Originally I was thinking we could do something like pkg-param-value /=3D "isdn-uui" but that would require an update to draft-ietf-cuss-sip-uui to do: pkg-param =3D "purpose" EQUAL pkg-param-value pkg-param-value =3D token Can we make this change to the UUI document, and I'll then follow through w= ith the UUI ISDN document? regards Keith _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Wed Feb 20 08:31:41 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 8142321F88F1 for ; Wed, 20 Feb 2013 08:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=0.082, 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 FYLjYpBnKkHD for ; Wed, 20 Feb 2013 08:31:40 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 670A921F86BA for ; Wed, 20 Feb 2013 08:31:40 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id 2bHW1l0020SCNGk55gXfNw; Wed, 20 Feb 2013 16:31:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 2gXf1l01C3ZTu2S3VgXffG; Wed, 20 Feb 2013 16:31:39 +0000 Message-ID: <5124FA6B.30704@alum.mit.edu> Date: Wed, 20 Feb 2013 11:31:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361377899; bh=K4dK3DIWEQB0x3Hlsm62vz1t3ApxMUhMqNIALTnksJo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pdxb+8sD0dpUtVgSTI0tPxnV3GNijRhXGB2cdkaeJZopR3+nWbfZix/mh/H8oVuP3 5i/xoKbQjgEly3sWEZ8WBOI8Mr/RwjNNAx9UVWDcvI+nu0pK9L8SKK564U5COJdm80 SJrKyqicJMKkEb4BdtjeZfRsvnC1uH/weaS0ujApfSU7+dqCp+41eyOMaAeu72/RCV 5hohytqNKE1FA8/ukmnGeJTcu9fXc73nnq7HZacC72ie+GCSZ+nCe9Go5m9xoWzj0Q jUZVfVGm1NTqpU0NMC/3arCKYQyIOwC4epxCSOJUef1Yq8Ik70F3aqr1tslz+Kh0oP qcpxfXfJiEiBw== Subject: Re: [cuss] ABNF in UUI documents 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, 20 Feb 2013 16:31:41 -0000 Keith, We are establishing a registry for purpose/package values. IMO you should use that for "isdn-uui", rather than extending the syntax to include it. Thanks, Paul On 2/20/13 7:04 AM, DRAGE, Keith (Keith) wrote: > I make the ABNF more formal in the UUISDN document, and that requires a change to the UUI document. > > Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. > > 11. Coding requirements > > This document defines "isdn-uui" as a new value of the User-to-User > "purpose" header field parameter. > > This document defines "isdn-uui" as a new value of the User-to-User > "content" header field parameter. A content value of "isdn-uui" > indicates that the contents have a first octet that is a protocol > discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] > followed by uui-data that can be subject to a length limitation > (before encoding or after decoding) that is generally 128 octets. > > My question is whether this should define BNF to add this to the BNF of draft-ietf-cuss-sip-uui which is currently. > > UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value) > uui-value = uui-data *(SEMI uui-param) > uui-data = token / quoted-string > uui-param = pkg-param / cont-param / enc-param / generic-param > pkg-param = "purpose" EQUAL token > cont-param = "content" EQUAL token > enc-param = "encoding" EQUAL ("hex" / token) > > If we did this I guess it would look something like: > > pkg-param = "purpose" EQUAL "isdn-uui" / token > cont-param = "content" EQUAL "isdn-uui" / token > > Originally I was thinking we could do something like > > pkg-param-value /= "isdn-uui" > > but that would require an update to draft-ietf-cuss-sip-uui to do: > > pkg-param = "purpose" EQUAL pkg-param-value > pkg-param-value = token > > Can we make this change to the UUI document, and I'll then follow through with the UUI ISDN document? > > regards > > Keith > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Wed Feb 20 08:56: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 CB11E21E8048 for ; Wed, 20 Feb 2013 08:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.222 X-Spam-Level: X-Spam-Status: No, score=-107.222 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 p4i0+3CYJn-3 for ; Wed, 20 Feb 2013 08:56:55 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id F046521E8044 for ; Wed, 20 Feb 2013 08:56:54 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1KGslt3018552 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2013 17:56:49 +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; Wed, 20 Feb 2013 17:56:32 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "cuss@ietf.org" Date: Wed, 20 Feb 2013 17:56:31 +0100 Thread-Topic: [cuss] ABNF in UUI documents Thread-Index: Ac4Ph8aq6XNeOoeDRROn/T9BDC6cagAAyABQ Message-ID: References: <5124FA6B.30704@alum.mit.edu> In-Reply-To: <5124FA6B.30704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [cuss] ABNF in UUI documents 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, 20 Feb 2013 16:56:55 -0000 These issues are orthogonal. Placing a value in an IANA registry does not define it, all it does is make= some attempt at stopping someone else from using it for a different purpos= e. The normative definition is the base RFC.=20 All I am doing is ensuring that the ABNF defines the values, rather than th= e text. If you extract the ABNF from both documents and combine them, then = you can very strings against it. What I am proposing is exactly what has been done for some, but not all, at= tribute values in SDP. Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 20 February 2013 16:32 > To: cuss@ietf.org > Subject: Re: [cuss] ABNF in UUI documents >=20 > Keith, >=20 > We are establishing a registry for purpose/package values. > IMO you should use that for "isdn-uui", rather than extending the syntax > to include it. >=20 > Thanks, > Paul >=20 > On 2/20/13 7:04 AM, DRAGE, Keith (Keith) wrote: > > I make the ABNF more formal in the UUISDN document, and that requires a > change to the UUI document. > > > > Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. > > > > 11. Coding requirements > > > > This document defines "isdn-uui" as a new value of the User-to-User > > "purpose" header field parameter. > > > > This document defines "isdn-uui" as a new value of the User-to-User > > "content" header field parameter. A content value of "isdn-uui" > > indicates that the contents have a first octet that is a protocol > > discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] > > followed by uui-data that can be subject to a length limitation > > (before encoding or after decoding) that is generally 128 octets. > > > > My question is whether this should define BNF to add this to the BNF of > draft-ietf-cuss-sip-uui which is currently. > > > > UUI =3D "User-to-User" HCOLON uui-value *(COMMA uui- > value) > > uui-value =3D uui-data *(SEMI uui-param) > > uui-data =3D token / quoted-string > > uui-param =3D pkg-param / cont-param / enc-param / generic- > param > > pkg-param =3D "purpose" EQUAL token > > cont-param =3D "content" EQUAL token > > enc-param =3D "encoding" EQUAL ("hex" / token) > > > > If we did this I guess it would look something like: > > > > pkg-param =3D "purpose" EQUAL "isdn-uui" / token > > cont-param =3D "content" EQUAL "isdn-uui" / token > > > > Originally I was thinking we could do something like > > > > pkg-param-value /=3D "isdn-uui" > > > > but that would require an update to draft-ietf-cuss-sip-uui to do: > > > > pkg-param =3D "purpose" EQUAL pkg-param-value > > pkg-param-value =3D token > > > > Can we make this change to the UUI document, and I'll then follow > through with the UUI ISDN document? > > > > regards > > > > Keith > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Wed Feb 20 09:21:52 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 9690E21F84B9 for ; Wed, 20 Feb 2013 09:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=0.080, 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 tAXPwfYpeWH8 for ; Wed, 20 Feb 2013 09:21:51 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7221F8821 for ; Wed, 20 Feb 2013 09:21:51 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id 2e9E1l0020vyq2s57hMqGX; Wed, 20 Feb 2013 17:21:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 2hMq1l00Z3ZTu2S3RhMqJk; Wed, 20 Feb 2013 17:21:50 +0000 Message-ID: <5125062E.8060204@alum.mit.edu> Date: Wed, 20 Feb 2013 12:21:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <5124FA6B.30704@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361380910; bh=QtpLvQSsOSDzcYpCTXn3C8FG2PQ1UsRreSgf7WN/Kko=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ccWhnKXCRbiHH/Pd6uaUylf00Ry6CEZi9GBeK/YNzOg6FCrCx19cQrO7LcFcBEJaF +oaxkzYjf+hoM9v0g/FOMl9Stn6/1FWZMhKn9Ixw4R8MofyDJoxI+e+mEXSJhu5ofM EI4Te3Yjszdw5kMN1i0bHF6HYq2O+G+zmNOUeeMemT2aU35Mi57QtkPSIWjb5o1taU auaTbEOw2r29fDkZNz6D6768qXLd05rerZ/xfrUc2kD5Tt9HodosoA/MZDZrCczDTX f4tLoe68uwmgQoXACHuz0Rg8la96eLf8vOoz5+qAPUuDPfS8lCMePAmWdLyPoK3l4f m/gOmO74w55Mg== Cc: "cuss@ietf.org" Subject: Re: [cuss] ABNF in UUI documents 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, 20 Feb 2013 17:21:52 -0000 On 2/20/13 11:56 AM, DRAGE, Keith (Keith) wrote: > These issues are orthogonal. > > Placing a value in an IANA registry does not define it, all it does is make some attempt at stopping someone else from using it for a different purpose. > > The normative definition is the base RFC. > > All I am doing is ensuring that the ABNF defines the values, rather than the text. If you extract the ABNF from both documents and combine them, then you can very strings against it. > > What I am proposing is exactly what has been done for some, but not all, attribute values in SDP. First, let me be clear that I don't feel strongly about this one way or the other, so don't let my comments get in the way of getting this done. I agree that in some cases we continue to update both ABNF and a registry. This *may* be viewed as helpful to readers. But it may also be deceptive and lull them into not checking the registry, which is a bad thing. It also doesn't work in all cases. It only works when the rules for adding a new value require the production of a standards document. The change you propose to the base document is harmless. It is also possible to accomplish what you want without it, though the result is a little less pretty: pkg-param /= "purpose" EQUAL "isdn-uui" But IMO it is equally acceptable to not update the syntax at all. The value you are defining already conforms to "token". Thanks, Paul > Keith > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 20 February 2013 16:32 >> To: cuss@ietf.org >> Subject: Re: [cuss] ABNF in UUI documents >> >> Keith, >> >> We are establishing a registry for purpose/package values. >> IMO you should use that for "isdn-uui", rather than extending the syntax >> to include it. >> >> Thanks, >> Paul >> >> On 2/20/13 7:04 AM, DRAGE, Keith (Keith) wrote: >>> I make the ABNF more formal in the UUISDN document, and that requires a >> change to the UUI document. >>> >>> Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. >>> >>> 11. Coding requirements >>> >>> This document defines "isdn-uui" as a new value of the User-to-User >>> "purpose" header field parameter. >>> >>> This document defines "isdn-uui" as a new value of the User-to-User >>> "content" header field parameter. A content value of "isdn-uui" >>> indicates that the contents have a first octet that is a protocol >>> discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] >>> followed by uui-data that can be subject to a length limitation >>> (before encoding or after decoding) that is generally 128 octets. >>> >>> My question is whether this should define BNF to add this to the BNF of >> draft-ietf-cuss-sip-uui which is currently. >>> >>> UUI = "User-to-User" HCOLON uui-value *(COMMA uui- >> value) >>> uui-value = uui-data *(SEMI uui-param) >>> uui-data = token / quoted-string >>> uui-param = pkg-param / cont-param / enc-param / generic- >> param >>> pkg-param = "purpose" EQUAL token >>> cont-param = "content" EQUAL token >>> enc-param = "encoding" EQUAL ("hex" / token) >>> >>> If we did this I guess it would look something like: >>> >>> pkg-param = "purpose" EQUAL "isdn-uui" / token >>> cont-param = "content" EQUAL "isdn-uui" / token >>> >>> Originally I was thinking we could do something like >>> >>> pkg-param-value /= "isdn-uui" >>> >>> but that would require an update to draft-ietf-cuss-sip-uui to do: >>> >>> pkg-param = "purpose" EQUAL pkg-param-value >>> pkg-param-value = token >>> >>> Can we make this change to the UUI document, and I'll then follow >> through with the UUI ISDN document? >>> >>> regards >>> >>> Keith >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>> >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Wed Feb 20 09:30:20 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 5DFDE21F8703 for ; Wed, 20 Feb 2013 09:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 MCIE4RX3QyTV for ; Wed, 20 Feb 2013 09:30:19 -0800 (PST) Received: from mail-ye0-f177.google.com (mail-ye0-f177.google.com [209.85.213.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3729621F869F for ; Wed, 20 Feb 2013 09:30:19 -0800 (PST) Received: by mail-ye0-f177.google.com with SMTP id m14so1480557yen.8 for ; Wed, 20 Feb 2013 09:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:x-mailer:from:subject:date :to; bh=fUPWXa6ssNgIfVj9fVdScPApN6J8oCV3q/Y1DQK6QGQ=; b=b38SEYH5tP9m899/TOd1xN4rMkoR7ydRB0zso+ywAV26mDj2feloSaP3Up6uX7Yev+ z7lps8e+KERt6B0ZBLAays5ebGcqUkGMjMCNUOsBPPf1LMsehXHzKnnwZyxVP7T0oopA NYPeI9KeDYQ3nKUlh/GbgJpu9ugHhRFL5ngtoZlXJm3VtjIl9cZnTRkppIxmYunHyb8p uBwZt7PgjDo8o7i86eitwx4pHMBpOEEm1nXy2v/cyxEUfEhUGwb7NrU0gdHmRlUVM8h6 G0GyxjcdBX/UooeZzR02RiboH2eRJkuyGLwNXOjb3usZcbxWQDOPkhUI8sjK+fhZUKXD wQxA== X-Received: by 10.236.149.8 with SMTP id w8mr38549221yhj.71.1361381418597; Wed, 20 Feb 2013 09:30:18 -0800 (PST) Received: from [10.182.53.172] ([166.205.66.71]) by mx.google.com with ESMTPS id u2sm42272810yhl.8.2013.02.20.09.30.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 09:30:17 -0800 (PST) References: <5124FA6B.30704@alum.mit.edu> In-Reply-To: <5124FA6B.30704@alum.mit.edu> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <1A2B383E-D49E-4515-90F9-48B9D738F254@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Alan Johnston Date: Wed, 20 Feb 2013 12:30:14 -0500 To: Paul Kyzivat Cc: "cuss@ietf.org" Subject: Re: [cuss] ABNF in UUI documents 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, 20 Feb 2013 17:30:20 -0000 I agree with Paul.=20 - Alan - On Feb 20, 2013, at 11:31 AM, Paul Kyzivat wrote: > Keith, >=20 > We are establishing a registry for purpose/package values. > IMO you should use that for "isdn-uui", rather than extending the syntax t= o include it. >=20 > Thanks, > Paul >=20 > On 2/20/13 7:04 AM, DRAGE, Keith (Keith) wrote: >> I make the ABNF more formal in the UUISDN document, and that requires a c= hange to the UUI document. >>=20 >> Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. >>=20 >> 11. Coding requirements >>=20 >> This document defines "isdn-uui" as a new value of the User-to-User >> "purpose" header field parameter. >>=20 >> This document defines "isdn-uui" as a new value of the User-to-User >> "content" header field parameter. A content value of "isdn-uui" >> indicates that the contents have a first octet that is a protocol >> discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] >> followed by uui-data that can be subject to a length limitation >> (before encoding or after decoding) that is generally 128 octets. >>=20 >> My question is whether this should define BNF to add this to the BNF of d= raft-ietf-cuss-sip-uui which is currently. >>=20 >> UUI =3D "User-to-User" HCOLON uui-value *(COMMA uui-value= ) >> uui-value =3D uui-data *(SEMI uui-param) >> uui-data =3D token / quoted-string >> uui-param =3D pkg-param / cont-param / enc-param / generic-para= m >> pkg-param =3D "purpose" EQUAL token >> cont-param =3D "content" EQUAL token >> enc-param =3D "encoding" EQUAL ("hex" / token) >>=20 >> If we did this I guess it would look something like: >>=20 >> pkg-param =3D "purpose" EQUAL "isdn-uui" / token >> cont-param =3D "content" EQUAL "isdn-uui" / token >>=20 >> Originally I was thinking we could do something like >>=20 >> pkg-param-value /=3D "isdn-uui" >>=20 >> but that would require an update to draft-ietf-cuss-sip-uui to do: >>=20 >> pkg-param =3D "purpose" EQUAL pkg-param-value >> pkg-param-value =3D token >>=20 >> Can we make this change to the UUI document, and I'll then follow through= with the UUI ISDN document? >>=20 >> regards >>=20 >> Keith >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >>=20 >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Thu Feb 21 01:07:03 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 AF96C21F8E3C for ; Thu, 21 Feb 2013 01:07:03 -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 9be0M2ClmBfa for ; Thu, 21 Feb 2013 01:07:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 786D021F8DF0 for ; Thu, 21 Feb 2013 01:07:02 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 632C83B4C57; Thu, 21 Feb 2013 10:07:01 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 45087238048; Thu, 21 Feb 2013 10:07:01 +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.0328.009; Thu, 21 Feb 2013 10:07:00 +0100 From: To: "DRAGE, Keith (Keith)" Thread-Topic: [cuss] ABNF in UUI documents Thread-Index: Ac4PYZo4S9Okq4HwRriq+GX6n1hdYgAHcYCAAADeU4AAAOJaAAAjDX2A Date: Thu, 21 Feb 2013 09:07:00 +0000 Message-ID: <28539_1361437621_5125E3B5_28539_1284_1_F8BE5641EC3C954DA088A8350BDDFA4808D602@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5124FA6B.30704@alum.mit.edu> <5125062E.8060204@alum.mit.edu> In-Reply-To: <5125062E.8060204@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.5] 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.2.19.124517 Cc: "cuss@ietf.org" Subject: Re: [cuss] ABNF in UUI documents 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, 21 Feb 2013 09:07:03 -0000 Hello, In link with this topic, please also consider our last exchanges about the = "purpose" parameter value ("isdn-uui" is the expected value but "isdn-inter= work" shall also be interpreted when received): http://www.ietf.org/mail-ar= chive/web/cuss/current/msg00445.html Thank you for taking it into account in your update of UUI ISDN draft. Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de P= aul Kyzivat Envoy=E9=A0: mercredi 20 f=E9vrier 2013 18:22 =C0=A0: DRAGE, Keith (Keith) Cc=A0: cuss@ietf.org Objet=A0: Re: [cuss] ABNF in UUI documents On 2/20/13 11:56 AM, DRAGE, Keith (Keith) wrote: > These issues are orthogonal. > > Placing a value in an IANA registry does not define it, all it does is ma= ke some attempt at stopping someone else from using it for a different purp= ose. > > The normative definition is the base RFC. > > All I am doing is ensuring that the ABNF defines the values, rather than = the text. If you extract the ABNF from both documents and combine them, the= n you can very strings against it. > > What I am proposing is exactly what has been done for some, but not all, = attribute values in SDP. First, let me be clear that I don't feel strongly about this one way or the= other, so don't let my comments get in the way of getting this done. I agree that in some cases we continue to update both ABNF and a registry. = This *may* be viewed as helpful to readers. But it may also be deceptive an= d lull them into not checking the registry, which is a bad thing. It also doesn't work in all cases. It only works when the rules for adding = a new value require the production of a standards document. The change you propose to the base document is harmless. It is also possible to accomplish what you want without it, though the resu= lt is a little less pretty: pkg-param /=3D "purpose" EQUAL "isdn-uui" But IMO it is equally acceptable to not update the syntax at all. The value= you are defining already conforms to "token". Thanks, Paul > Keith > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat >> Sent: 20 February 2013 16:32 >> To: cuss@ietf.org >> Subject: Re: [cuss] ABNF in UUI documents >> >> Keith, >> >> We are establishing a registry for purpose/package values. >> IMO you should use that for "isdn-uui", rather than extending the=20 >> syntax to include it. >> >> Thanks, >> Paul >> >> On 2/20/13 7:04 AM, DRAGE, Keith (Keith) wrote: >>> I make the ABNF more formal in the UUISDN document, and that=20 >>> requires a >> change to the UUI document. >>> >>> Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines. >>> >>> 11. Coding requirements >>> >>> This document defines "isdn-uui" as a new value of the User-to-User >>> "purpose" header field parameter. >>> >>> This document defines "isdn-uui" as a new value of the User-to-User >>> "content" header field parameter. A content value of "isdn-uui" >>> indicates that the contents have a first octet that is a protocol >>> discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] >>> followed by uui-data that can be subject to a length limitation >>> (before encoding or after decoding) that is generally 128 octets. >>> >>> My question is whether this should define BNF to add this to the BNF=20 >>> of >> draft-ietf-cuss-sip-uui which is currently. >>> >>> UUI =3D "User-to-User" HCOLON uui-value *(COMMA uui- >> value) >>> uui-value =3D uui-data *(SEMI uui-param) >>> uui-data =3D token / quoted-string >>> uui-param =3D pkg-param / cont-param / enc-param / generic- >> param >>> pkg-param =3D "purpose" EQUAL token >>> cont-param =3D "content" EQUAL token >>> enc-param =3D "encoding" EQUAL ("hex" / token) >>> >>> If we did this I guess it would look something like: >>> >>> pkg-param =3D "purpose" EQUAL "isdn-uui" / token >>> cont-param =3D "content" EQUAL "isdn-uui" / token >>> >>> Originally I was thinking we could do something like >>> >>> pkg-param-value /=3D "isdn-uui" >>> >>> but that would require an update to draft-ietf-cuss-sip-uui to do: >>> >>> pkg-param =3D "purpose" EQUAL pkg-param-value >>> pkg-param-value =3D token >>> >>> Can we make this change to the UUI document, and I'll then follow >> through with the UUI ISDN document? >>> >>> regards >>> >>> Keith >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>> >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ 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.