From iesg-secretary@ietf.org Wed May 15 08:57:48 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 B68E421F87FB; Wed, 15 May 2013 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 GkCZI3GFY+GS; Wed, 15 May 2013 08:57:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2939821F8ED8; Wed, 15 May 2013 08:57:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Sender: Message-ID: <20130515155737.6482.16403.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 08:57:37 -0700 Cc: cuss@ietf.org Subject: [cuss] Last Call: (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 15 May 2013 15:57:50 -0000 The IESG has received a request from the Call Control UUI Service for SIP WG (cuss) to consider the following document: - 'A Mechanism for Transporting User to User Call Control Information in SIP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ballot/ No IPR declarations have been submitted directly on this I-D. From celine.serrutvalette@orange.com Thu May 16 00:58:34 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 698C721F874A for ; Thu, 16 May 2013 00:58:34 -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 I4PoGCqai34I for ; Thu, 16 May 2013 00:58:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0728C21F8EE3 for ; Thu, 16 May 2013 00:58:26 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 979FA3B5A61; Thu, 16 May 2013 09:58:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7B64E4C05D; Thu, 16 May 2013 09:58:25 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 16 May 2013 09:58:25 +0200 From: To: Alan Johnston Thread-Topic: [cuss] Last Call: (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard Thread-Index: AQHOUYUBDHiCwbYsmkSfHq/PF497sZkHcTSw Date: Thu, 16 May 2013 07:58:24 +0000 Message-ID: <21378_1368691105_519491A1_21378_70_13_F8BE5641EC3C954DA088A8350BDDFA480B3F0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20130515155737.6482.16403.idtracker@ietfa.amsl.com> In-Reply-To: <20130515155737.6482.16403.idtracker@ietfa.amsl.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.5.2.60325 Cc: "cuss@ietf.org" Subject: Re: [cuss] Last Call: (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard 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, 16 May 2013 07:58:34 -0000 Hello, I look at the new version draft-ietf-cuss-sip-uui-10.txt and I don't unders= tand why "encoding" parameter name has been changed into "content" in secti= on 4.1 (so there is "content" twice). Could you please explain? Is it an ed= itorial mistake? Thank you in advance. Regards, Celine Serrut-Valette Orange Labs Extract from 4.1. Syntax for UUI Header Field: cont-param =3D "content" EQUAL cont-param-value cont-param-value =3D token enc-param =3D "content" EQUAL enc-param-value enc-param-value =3D token / "hex" -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de T= he IESG Envoy=E9=A0: mercredi 15 mai 2013 17:58 =C0=A0: IETF-Announce Cc=A0: cuss@ietf.org Objet=A0: [cuss] Last Call: (A Mechanism f= or Transporting User to User Call Control Information in SIP) to Proposed S= tandard The IESG has received a request from the Call Control UUI Service for SIP W= G (cuss) to consider the following document: - 'A Mechanism for Transporting User to User Call Control Information in SIP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2013-05-29. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ 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 alan.b.johnston@gmail.com Thu May 16 09:57:23 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 1101B21F93C4 for ; Thu, 16 May 2013 09:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qlLeyly7EpEt for ; Thu, 16 May 2013 09:57:22 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id C76CC21F93A5 for ; Thu, 16 May 2013 09:57:21 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so24209wib.4 for ; Thu, 16 May 2013 09:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6VOLWIDcoTgq8I/g1PoHFE6zD4mvvzzkMvwJhIDxKcQ=; b=chM9Ei8MT/nGOu1vlB6Rzsam6BOi4fuS/SrC1XwwHqC/79AxuYbqt8DQl0SQWELzr7 8caME8zlP7rk3ZjqRLkT/kz1jrv80Yf4uu65na6X0FNQT4LfKT2C2BPk0RGn6v6Oqagz FuK6BVbCsh5wDY1mlp7qy605lHP0aLCNn71NdE6+o27czZZavu3ZORfQSyfEuwRjnPa9 YaGylwP3KkGGd4ctwQ2Kmv0e+CCU8vEJbAYYJvCGP1ldIIpbpPIsCwc4Mto5kv5mDqDl W02+jPHlxeFy3fnsV1kgDKiSHHUltz+b2Mp1LXp3xNQay13wGjKav449V7dFN/pAwG+c CjHg== MIME-Version: 1.0 X-Received: by 10.180.89.170 with SMTP id bp10mr26075572wib.26.1368723440447; Thu, 16 May 2013 09:57:20 -0700 (PDT) Received: by 10.216.83.145 with HTTP; Thu, 16 May 2013 09:57:20 -0700 (PDT) In-Reply-To: <21378_1368691105_519491A1_21378_70_13_F8BE5641EC3C954DA088A8350BDDFA480B3F0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20130515155737.6482.16403.idtracker@ietfa.amsl.com> <21378_1368691105_519491A1_21378_70_13_F8BE5641EC3C954DA088A8350BDDFA480B3F0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 16 May 2013 11:57:20 -0500 Message-ID: From: Alan Johnston To: "celine.serrutvalette@orange.com" Content-Type: multipart/alternative; boundary=14dae9cc955076b77904dcd8c2ce Cc: "cuss@ietf.org" Subject: Re: [cuss] Last Call: (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard 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, 16 May 2013 16:57:23 -0000 --14dae9cc955076b77904dcd8c2ce Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Celine, Yes, that is a typo. The line in the ABNF should be: enc-param =3D "encoding" EQUAL enc-param-value - Alan - On Thu, May 16, 2013 at 2:58 AM, wrote: > Hello, > > I look at the new version draft-ietf-cuss-sip-uui-10.txt and I don't > understand why "encoding" parameter name has been changed into "content" = in > section 4.1 (so there is "content" twice). Could you please explain? Is i= t > an editorial mistake? Thank you in advance. > Regards, > > Celine Serrut-Valette > Orange Labs > > Extract from 4.1. Syntax for UUI Header Field: > > cont-param =3D "content" EQUAL cont-param-value > cont-param-value =3D token > enc-param =3D "content" EQUAL enc-param-value > enc-param-value =3D token / "hex" > > -----Message d'origine----- > De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de > The IESG > Envoy=E9 : mercredi 15 mai 2013 17:58 > =C0 : IETF-Announce > Cc : cuss@ietf.org > Objet : [cuss] Last Call: (A Mechanism > for Transporting User to User Call Control Information in SIP) to Propose= d > Standard > > > The IESG has received a request from the Call Control UUI Service for SIP > WG (cuss) to consider the following document: > - 'A Mechanism for Transporting User to User Call Control Information in > SIP' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-05-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > There is a class of applications which benefit from using SIP to > exchange User to User Information (UUI) data during session > establishment. This information, known as call control UUI data, is > a small piece of data inserted by an application initiating the > session, and utilized by an application accepting the session. The > rules which apply for a specific application are defined by a UUI > package. This UUI data is opaque to SIP and its function is > unrelated to any basic SIP function. This document defines a new SIP > header field, User-to-User, to transport UUI data, along with an > extension mechanism. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > 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. > > --14dae9cc955076b77904dcd8c2ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Celine,

Yes, that is a typo. =A0The = line in the ABNF should be:

=A0 =A0 =A0enc-param =A0 =3D "en= coding" EQUAL enc-param-value

- Alan -


On Thu, May 16, 2013 at 2:58 AM, <celine.serrutvalette@oran= ge.com> wrote:
Hello,

I look at the new version draft-ietf-cuss-sip-uui-10.txt and I don't un= derstand why "encoding" parameter name has been changed into &quo= t;content" in section 4.1 (so there is "content" twice). Cou= ld you please explain? Is it an editorial mistake? Thank you in advance. Regards,

Celine Serrut-Valette
Orange Labs

Extract from 4.1. =A0Syntax for UUI Header Field:

=A0 =A0 =A0 =A0 cont-param =A0 =3D "content" EQUAL cont-param-val= ue
=A0 =A0 =A0 =A0 cont-param-value =3D token
=A0 =A0 =A0 =A0 enc-param =A0 =3D "content" EQUAL enc-param-value=
=A0 =A0 =A0 =A0 enc-param-value =3D token / "hex"

-----Message d'origine-----
De=A0: cuss-bounces@ietf.org [= mailto:cuss-bounces@ietf.org] = De la part de The IESG
Envoy=E9=A0: mercredi 15 mai 2013 17:58
=C0=A0: IETF-Announce
Cc=A0: cuss@ietf.org
Objet=A0: [cuss] Last Call: <draft-ietf-cuss-sip-uui-10.txt> (A Mecha= nism for Transporting User to User Call Control Information in SIP) to Prop= osed Standard


The IESG has received a request from the Call Control UUI Service for SIP W= G (cuss) to consider the following document:
- 'A Mechanism for Transporting User to User Call Control Information i= n
=A0 =A0SIP'
=A0 <draft-ietf-cuss-sip-uui-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-29. Ex= ceptionally, comments may be sent to iesg@= ietf.org instead. In either case, please retain the beginning of the Su= bject line to allow automated sorting.

Abstract


=A0 =A0There is a class of applications which benefit from using SIP to
=A0 =A0exchange User to User Information (UUI) data during session
=A0 =A0establishment. =A0This information, known as call control UUI data, = is
=A0 =A0a small piece of data inserted by an application initiating the
=A0 =A0session, and utilized by an application accepting the session. =A0Th= e
=A0 =A0rules which apply for a specific application are defined by a UUI =A0 =A0package. =A0This UUI data is opaque to SIP and its function is
=A0 =A0unrelated to any basic SIP function. =A0This document defines a new = SIP
=A0 =A0header field, User-to-User, to transport UUI data, along with an
=A0 =A0extension mechanism.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/= ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://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 message= s electroniques 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.


--14dae9cc955076b77904dcd8c2ce-- From vkg@bell-labs.com Thu May 16 10:08:22 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 6802B21F85D6 for ; Thu, 16 May 2013 10:08:22 -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 SQCOF9P1m7I1 for ; Thu, 16 May 2013 10:08:17 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7FADE11E8111 for ; Thu, 16 May 2013 10:08:17 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4GH8GCG009690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 May 2013 12:08:16 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r4GH8Gkx018322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 May 2013 12:08:16 -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 r4GH8Ghf019317 for ; Thu, 16 May 2013 12:08:16 -0500 (CDT) Message-ID: <51951353.2060806@bell-labs.com> Date: Thu, 16 May 2013 12:11:47 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: cuss@ietf.org References: <20130515155737.6482.16403.idtracker@ietfa.amsl.com> <21378_1368691105_519491A1_21378_70_13_F8BE5641EC3C954DA088A8350BDDFA480B3F0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [cuss] Last Call: (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard 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, 16 May 2013 17:08:22 -0000 On 05/16/2013 11:57 AM, Alan Johnston wrote: > Hi Celine, > > Yes, that is a typo. The line in the ABNF should be: > > enc-param = "encoding" EQUAL enc-param-value Alan, Celine: Do you think it is worth spinning a new version or should we fix this typo during Auth-48? Let's decide what to do and move ahead since Enrico and I will like to get the ISDN I-D moving forward now that this one is in motion. 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 jmh@joelhalpern.com Sun May 19 11:58: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 38C2D21F8D70; Sun, 19 May 2013 11:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 wnPdHgmJCIaE; Sun, 19 May 2013 11:58:10 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0B621F8D71; Sun, 19 May 2013 11:58:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 02C731C0526; Sun, 19 May 2013 11:58:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-20.clppva.east.verizon.net [70.106.134.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0F43B1C04D7; Sun, 19 May 2013 11:58:04 -0700 (PDT) Message-ID: <519920BA.9040308@joelhalpern.com> Date: Sun, 19 May 2013 14:58:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "A. Jean Mahoney" References: <5195550A.3000608@nostrum.com> In-Reply-To: <5195550A.3000608@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, draft-ietf-cuss-sip-uui-all@tools.ietf.org, IETF discussion list , cuss@ietf.org Subject: [cuss] [Gen-art] review: draft-ietf-cuss-sip-uui-10 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, 19 May 2013 18:58:15 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-cuss-sip-uui-10 A Mechanism for Transporting User to User Call Control Information in SIP Reviewer: Joel M. Halpern Review Date: 19-May-2013 IETF LC End Date: 29-May-2013 IESG Telechat date: N/A Summary: This document is nearly ready for publication as a Proposed Standard Major issues: Minor issues: The requirements discussions for redirection and referral (second paragraph of section 3, in regards REQ-3) includes what appears to be normative requirements on redirecting devices. a) This would seem to belong in section 4 on Normative Definition. b) It would seem that there ought to be some discussion of what happens with redirecting devices that do not understand this new UUI. (I presume things work, but I don't see how.) Nits/editorial comments: In section 8.2, given that this is a WG document, should the "the authors believe" actually be "the WG believes"? Or even, given IETF rough consensus on this document, "the IETF believes"?