From vkg@bell-labs.com Tue May 1 09:28:22 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 CEE2221E819A for ; Tue, 1 May 2012 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.821 X-Spam-Level: X-Spam-Status: No, score=-109.821 tagged_above=-999 required=5 tests=[AWL=0.778, 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 GQiyvWJaOb8r for ; Tue, 1 May 2012 09:28:22 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 250BE21E816B for ; Tue, 1 May 2012 09:28:22 -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 q41GSLTS019149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 11:28:21 -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 q41GSKnY014179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 May 2012 11:28:21 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q41GSKvr006266; Tue, 1 May 2012 11:28:20 -0500 (CDT) Message-ID: <4FA0105A.2070006@bell-labs.com> Date: Tue, 01 May 2012 11:33:30 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "draft-ietf-cuss-sip-uui@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: cuss@ietf.org Subject: [cuss] Changing "package" to "purpose" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:28:22 -0000 Alan, James: As per the last word on changing "package" to "purpose", it seems that we did not get any opposition pursuant to the call for consensus [1]. Can you please issue a revised I-D for the mechanism draft, that will allow Keith to drive a revision to his uui-isdn draft as well. Let's get these documents done so we can gauge whether we can go for a WGLC on them. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00406.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From alan.b.johnston@gmail.com Wed May 2 04:58:08 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 9094521F8A85 for ; Wed, 2 May 2012 04:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 F878qWpqrbvD for ; Wed, 2 May 2012 04:58:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0984221F89E1 for ; Wed, 2 May 2012 04:58:07 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1064341obb.31 for ; Wed, 02 May 2012 04:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JDolgWVI6s2rBOPq3L2o06rStPWHx08qT0uZHofLHb4=; b=CCiA8r+0l/2LQIaj/E3vR3ylLgUsYBpUT+Cv99wA3Z/BGKs1HCRGWRiv0svPxMUn2H ZescOn3tK4f95KcV/Htve8guRlbWiovNeeeSWI0Vb78jL4eL+ax1w/CeJLg4F5tpxH05 66PfZjxGze99pDvAaW53mob2ilMDShm5RPmMqGZ0VI/WDjfGnGiALXQP9IFhBSr4TKpw gzLqNy4CgQKJQUaPAWc0PQCuZfms+Ry4i2YjF4bb+KNbz+LEZ8IT6lfhdHyFbUY/+p8W NKR4dx+e97ZVCRkZ3QOlDHhXXc7b+/KcaP22Y3xMnd7zDnwRQee391JqXDSeg+wCz4pe H7Qg== MIME-Version: 1.0 Received: by 10.182.174.42 with SMTP id bp10mr4409514obc.54.1335959887678; Wed, 02 May 2012 04:58:07 -0700 (PDT) Received: by 10.182.35.167 with HTTP; Wed, 2 May 2012 04:58:07 -0700 (PDT) In-Reply-To: <4FA0105A.2070006@bell-labs.com> References: <4FA0105A.2070006@bell-labs.com> Date: Wed, 2 May 2012 06:58:07 -0500 Message-ID: From: Alan Johnston To: "Vijay K. Gurbani" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-cuss-sip-uui@tools.ietf.org" , cuss@ietf.org Subject: Re: [cuss] Changing "package" to "purpose" 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, 02 May 2012 11:58:08 -0000 Will do. - Alan - On Tue, May 1, 2012 at 11:33 AM, Vijay K. Gurbani wrote= : > Alan, James: As per the last word on changing "package" to > "purpose", it seems that we did not get any opposition pursuant > to the call for consensus [1]. > > Can you please issue a revised I-D for the mechanism draft, that > will allow Keith to drive a revision to his uui-isdn draft as well. > > Let's get these documents done so we can gauge whether we can go > for a WGLC on them. > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00406.html > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: =A0 http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From internet-drafts@ietf.org Fri May 4 07:47:46 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 3A8F321F85F1; Fri, 4 May 2012 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 EnZY49eD8Frt; Fri, 4 May 2012 07:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92D721F857D; Fri, 4 May 2012 07:47:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504144745.24304.23475.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 07:47:45 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-06.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:47:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Work= ing Group of the IETF. Title : A Mechanism for Transporting User to User Call Control I= nformation in SIP Author(s) : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-06.txt Pages : 18 Date : 2012-05-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ From internet-drafts@ietf.org Fri May 4 08:04:21 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 4B98221F86EF; Fri, 4 May 2012 08:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 qZLhmyoyK+Sq; Fri, 4 May 2012 08:04:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8D21F8680; Fri, 4 May 2012 08:04:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504150420.30057.54480.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 08:04:20 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:04:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Work= ing Group of the IETF. Title : Interworking ISDN Call Control User Information with SIP Author(s) : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-04.txt Pages : 19 Date : 2012-05-04 The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ From keith.drage@alcatel-lucent.com Fri May 4 08:26:55 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 5D6BA21F8760 for ; Fri, 4 May 2012 08:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.787 X-Spam-Level: X-Spam-Status: No, score=-109.787 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 uA+N5nVAguDi for ; Fri, 4 May 2012 08:26:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 64FF421F86D0 for ; Fri, 4 May 2012 08:26:54 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q44FQpZ7018781 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 May 2012 17:26:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 4 May 2012 17:26:52 +0200 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Fri, 4 May 2012 17:26:51 +0200 Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt Thread-Index: Ac0qBzQazp1YHvi2SwOYQBdusq53swAAr5kQ Message-ID: References: <20120504150420.30057.54480.idtracker@ietfa.amsl.com> In-Reply-To: <20120504150420.30057.54480.idtracker@ietfa.amsl.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:26:55 -0000 I've just issued a new version of this document. There should be no surprises here. The changes are essentially to align with the new version of draft-ietf-cus= s-sip-uui that you will have also just seen, essentially to change the "pac= kage" header field parameter to the "purpose" header field parameter. There= is one new sentence explaining the relationship between header field param= eter and packages.=20 Keith -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: 04 May 2012 16:04 To: i-d-announce@ietf.org Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Work= ing Group of the IETF. Title : Interworking ISDN Call Control User Information with SIP Author(s) : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-04.txt Pages : 19 Date : 2012-05-04 The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Sat May 5 11:21:18 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 1F98F21F84EF for ; Sat, 5 May 2012 11:21:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erA+0lrzT0YX for ; Sat, 5 May 2012 11:21:17 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 99B8B21F84E2 for ; Sat, 5 May 2012 11:21:17 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q45ILGsc027783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 5 May 2012 13:21:16 -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 q45ILG6v004281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 5 May 2012 13:21:16 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.19.197]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q45ILFxO029388 for ; Sat, 5 May 2012 13:21:16 -0500 (CDT) Message-ID: <4FA570D4.10006@bell-labs.com> Date: Sat, 05 May 2012 13:26:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 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: Sat, 05 May 2012 18:21:18 -0000 All: Enrico and I will like to issue a WGLC for the two drafts that constitute the remaining of our chartered work. These drafts have been revised post-Paris IETF based on the discussion in Paris and subsequent ratification on the mailing list. The two drafts are: draft-ietf-cuss-sip-uui-06 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-06) draft-ietf-cuss-sip-uui-isdn-04 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-04) The WGLC expires on May 27, 2012. We are looking for volunteers to perform WGLC on each of these documents. Please let me and Enrico know as soon as you can if you are able to help out. Thank you, Vijay K. Gurbani and Enrico Marocco From celine.serrutvalette@orange.com Mon May 7 07:14:24 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 3082B21F85A3 for ; Mon, 7 May 2012 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfZ7ryNEI9pW for ; Mon, 7 May 2012 07:14:23 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3145521F85AC for ; Mon, 7 May 2012 07:14:23 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B537E301D1; Mon, 7 May 2012 16:14:34 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 041F8E301B4; Mon, 7 May 2012 16:14:34 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 16:14:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2012 16:14:19 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620256A58D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt Thread-Index: Ac0qBzQazp1YHvi2SwOYQBdusq53swAAr5kQAJRi0hA= References: <20120504150420.30057.54480.idtracker@ietfa.amsl.com> From: To: , X-OriginalArrivalTime: 07 May 2012 14:14:21.0977 (UTC) FILETIME=[B2F6B090:01CD2C5B] Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:14:24 -0000 Hello, Thank you for this update. I would have 2 comments: - In relationship with the change of parameter name from "package" to = "purpose" and its application to ISDN draft, the value of "purpose" = header field parameter is still set to "isdn-uui", would it be possible = to come back to previous "isdn-interwork" value in order to allow a = backward compatibility with draft-johnston-sipping-cc-uui-08 on which = several implementations are based?=20 - Additionally, in Section 13 ("This document adds the following row to = the "UUI packages" sub-registry of the SIP parameter registry"), should = "UUI packages" name not be replaced by "UUI purposes" name as it deals = with the IANA registration of the parameter value defined for ISDN? Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de DRAGE, Keith (Keith) Envoy=E9=A0: vendredi 4 mai 2012 17:27 =C0=A0: cuss@ietf.org Objet=A0: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt I've just issued a new version of this document. There should be no surprises here. The changes are essentially to align with the new version of = draft-ietf-cuss-sip-uui that you will have also just seen, essentially = to change the "package" header field parameter to the "purpose" header = field parameter. There is one new sentence explaining the relationship = between header field parameter and packages.=20 Keith -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org Sent: 04 May 2012 16:04 To: i-d-announce@ietf.org Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-04.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Call Control UUI Service = for SIP Working Group of the IETF. Title : Interworking ISDN Call Control User Information with = SIP Author(s) : Keith Drage Alan Johnston Filename : draft-ietf-cuss-sip-uui-isdn-04.txt Pages : 19 Date : 2012-05-04 The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-isdn-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ _______________________________________________ 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 celine.serrutvalette@orange.com Mon May 7 07:16:17 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 D86E221F849D for ; Mon, 7 May 2012 07:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKUOkQsHi8Kf for ; Mon, 7 May 2012 07:16:17 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id DE07621F849A for ; Mon, 7 May 2012 07:16:16 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B1815D88FC; Mon, 7 May 2012 16:16:15 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 3189B5D8857; Mon, 7 May 2012 16:16:15 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 16:16:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2012 16:16:13 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620256A58E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20120504144745.24304.23475.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-06.txt Thread-Index: Ac0qBOALr+PBsAksQK6eBNIoPaNZlQCVvIsA References: <20120504144745.24304.23475.idtracker@ietfa.amsl.com> From: To: , X-OriginalArrivalTime: 07 May 2012 14:16:15.0407 (UTC) FILETIME=[F692BBF0:01CD2C5B] Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-06.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:16:18 -0000 Hello, Thank you for this update. I would have 2 comments: - Section 4: As discussed before, we agreed together to add a = clarification on the possibility to have multiple User-to-User headers = with same or different packages, could you please add it?: For reminder: Orange request: "Would it be possible to indicate that "Multiple = User-to-User header fields MAY be present in a request or response, = containing uui-data for the same or for different packages?" Your answer: "On #1, I'm fine calling out that the multiple UUI data = elements can be for the same or different packages." (28th March) - Section 6.3: Should "package" name not be replaced by "purpose" name = since this section deals with IANA registration of SIP parameter? Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de internet-drafts@ietf.org Envoy=E9=A0: vendredi 4 mai 2012 16:48 =C0=A0: i-d-announce@ietf.org Cc=A0: cuss@ietf.org Objet=A0: [cuss] I-D Action: draft-ietf-cuss-sip-uui-06.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Call Control UUI Service = for SIP Working Group of the IETF. Title : A Mechanism for Transporting User to User Call = Control Information in SIP Author(s) : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-06.txt Pages : 18 Date : 2012-05-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From R.Jesske@telekom.de Mon May 21 04:35:42 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 66DBF21F8630 for ; Mon, 21 May 2012 04:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERemftMgIB3w for ; Mon, 21 May 2012 04:35:41 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 34C8521F8629 for ; Mon, 21 May 2012 04:35:39 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 21 May 2012 13:34:22 +0200 Received: from HE113676.emea1.cds.t-internal.com (10.134.99.29) by HE111628.emea1.cds.t-internal.com (10.134.93.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 21 May 2012 13:34:22 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 21 May 2012 13:34:22 +0200 From: To: , , Date: Mon, 21 May 2012 13:34:19 +0200 Thread-Topic: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Thread-Index: Ac0q6+DKuJUltJEvTnGCht6gQhbAngMRFXSA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF4686AD@HE111648.emea1.cds.t-internal.com> References: <4FA570D4.10006@bell-labs.com> In-Reply-To: <4FA570D4.10006@bell-labs.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 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, 21 May 2012 11:35:42 -0000 Dear all, I was asked to review the draft sip-uui-isdn-04. The draft itself is in a g= ood shape and I propose to move forward in the process approval. Here are my comments in detail: GENERAL: 1. The draft is applicable for the intended scope of the document which cov= ers the interworking with both public ISDN and private ISDN capabilities. T= he aspects of QSIG probably stated. 2. All points of discussion on email list and meetings are reflected probab= ly. This includes one of the main discussion point, the name change "packag= e" to "purpose". 3. Backward compatibility to early implementations based on earlier drafts = are given. The appearance of the header fields "content" and "encoding" is = optional. 4. I wonder if a sentence for ISUP User-to-User transport and interworking = would help to understand that the ISUP interworking behavior is the same as= for ISDN. (For me it is clear) Text could look like: ISUP itself transports transparently the ISDN User-to= -User Information element. The interworking of ISUP with SIP applies with t= he same rules as for ISDN due to the fact that ISUP itself transports trans= parently the ISDN User-to-User Information element. DETAIL: 1. Section "3.1. The service" For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3 and section 7 [Q931]. I would propose to add an additional reference to Q.931 Section 4.5.30 wh= ere the User-user information element is defined. This helps the interested= reader of Q.931 to find also the related protocol element. Proposed Text: For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3, 4.5.30 and section = 7 [Q931]. 2. Section "9. UUI contents" I have some problems with the wording "...the sending SIP entity MAY, but n= eed not, include ..." There is not a direct guidance for implementation. I think we should use some more recommendatory wording. Like "...it is "RE= COMMENDED" that the sending SIP entity include a..." or "...it is "OPTIONAL" that the sending SIP entity include a..." To show that the element is not needed an additional sentence is added to s= how the behavior of the receiving entity: "A receiving SIP entity accepts a= received User-to-User header field if the "xxx" header field parameter is set to "xxx" or is absent. Proposals: Replace: The default and only content defined for this package is "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". With: The default and only content defined for this package is "isdn-uui". When sending UUI, it is "RECOMMENDED" that the sending SIP entity includ= e a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". A receiving SIP entity accepts a received User-to-User header field if the "content" header field parameter is set to "isdn-uui" or is absent. Replace: The default and only encoding defined for this package is "hex". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". With: The default and only encoding defined for this package is "hex". When sending UUI, it is "RECOMMENDED" that the sending SIP entity includ= e an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". A receiving SIP entity accepts a received User-to-User header field if the "encoding" header field parameter set to "hex" or is absent. EDITORIAL: 1. Section "3.1. The service" ... The above come from the ISDN specifications defined for public networks. There are a parallel set of ISDN specifications defined for private networks (QSIG}. ... Wrong bracket 2. Page 5 2nd paragraph 2nd sentence: spelling -- descriminator --> discrim= inator 3. Section "7. UAC requirements" Replace should--> SHOULD While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. Replace by: While there is no harm in including the "uui" option tag, and strictly it SHOULD be included if the extension is supported, it performs no function. 4. Section "8. UAS requirements" last paragraph last sentence. I would add an originally. So that the sentence read: There are no mechanisms for determining which was the originally intended d= ata packet so all are discarded. I hope this helps. Thank you Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von Vi= jay K. Gurbani Gesendet: Samstag, 5. Mai 2012 20:26 An: cuss@ietf.org Betreff: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 All: Enrico and I will like to issue a WGLC for the two drafts that constit= ute the remaining of our chartered work. These drafts have been revised po= st-Paris IETF based on the discussion in Paris and subsequent ratification = on the mailing list. The two drafts are: draft-ietf-cuss-sip-uui-06 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-06) draft-ietf-cuss-sip-uui-isdn-04 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-04) The WGLC expires on May 27, 2012. We are looking for volunteers to perform WGLC on each of these documents. = Please let me and Enrico know as soon as you can if you are able to help ou= t. Thank you, Vijay K. Gurbani and Enrico Marocco _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From celine.serrutvalette@orange.com Mon May 21 07:22: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 2FD3621F855B for ; Mon, 21 May 2012 07:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miE+Zz7i2rbu for ; Mon, 21 May 2012 07:22:10 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8821F8598 for ; Mon, 21 May 2012 07:22:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 186B0DE4008; Mon, 21 May 2012 16:23:42 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id EE2A5DE4004; Mon, 21 May 2012 16:23:41 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 16:22:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 16:22:06 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462025ABBA1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF4686AD@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Thread-Index: Ac0q6+DKuJUltJEvTnGCht6gQhbAngMRFXSAAAnB6jA= References: <4FA570D4.10006@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF4686AD@HE111648.emea1.cds.t-internal.com> From: To: X-OriginalArrivalTime: 21 May 2012 14:22:08.0734 (UTC) FILETIME=[1AF4A7E0:01CD375D] Cc: cuss@ietf.org Subject: Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 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, 21 May 2012 14:22:11 -0000 Hello, Related to GENERAL points 2 and 3, to follow the change of parameter = name and in order to ensure backward compatibility to early = implementations based on earlier drafts (e.g. = draft-johnston-sipping-cc-uui-08) on which several implementations are = based, could you rename the value of "purpose" parameter from "isdn-uui" = to "isdn-interwork" (see = http://www.ietf.org/mail-archive/web/cuss/current/msg00355.html, comment = C10)? Indeed, the meaning of both values is the same and the value is = defined for ISDN interworking purpose ("for interworking with the ISDN = user-to-user service" in Section 13), therefore "isdn-interwork" is a = relevant value for "purpose" parameter and in addition it would allow = backward compatibility.=20 Please find also a minor comment in Section 13 ("This document adds the = following row to the "UUI packages" sub-registry of the SIP parameter = registry"), it seems that "UUI packages" should be replaced by "UUI = purpose" as it gives the parameter value which is registered to IANA for = ISDN interworking. Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part = de R.Jesske@telekom.de Envoy=E9=A0: lundi 21 mai 2012 13:34 =C0=A0: vkg@bell-labs.com; enrico.marocco@telecomitalia.it; = cuss@ietf.org Objet=A0: Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Dear all, I was asked to review the draft sip-uui-isdn-04. The draft itself is in = a good shape and I propose to move forward in the process approval. Here are my comments in detail: GENERAL: 1. The draft is applicable for the intended scope of the document which = covers the interworking with both public ISDN and private ISDN = capabilities. The aspects of QSIG probably stated. 2. All points of discussion on email list and meetings are reflected = probably. This includes one of the main discussion point, the name = change "package" to "purpose". 3. Backward compatibility to early implementations based on earlier = drafts are given. The appearance of the header fields "content" and = "encoding" is optional. 4. I wonder if a sentence for ISUP User-to-User transport and = interworking would help to understand that the ISUP interworking = behavior is the same as for ISDN. (For me it is clear) Text could look like: ISUP itself transports transparently the ISDN = User-to-User Information element. The interworking of ISUP with SIP = applies with the same rules as for ISDN due to the fact that ISUP itself = transports transparently the ISDN User-to-User Information element. DETAIL: 1. Section "3.1. The service" For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3 and section 7 [Q931]. I would propose to add an additional reference to Q.931 Section 4.5.30 = where the User-user information element is defined. This helps the = interested reader of Q.931 to find also the related protocol element. Proposed Text: For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3, 4.5.30 and = section 7 [Q931]. 2. Section "9. UUI contents" I have some problems with the wording "...the sending SIP entity MAY, = but need not, include ..." There is not a direct guidance for = implementation. I think we should use some more recommendatory wording. Like "...it is = "RECOMMENDED" that the sending SIP entity include a..." or "...it is "OPTIONAL" that the sending SIP entity include a..." To show that the element is not needed an additional sentence is added = to show the behavior of the receiving entity: "A receiving SIP entity = accepts a received User-to-User header field if the "xxx" header field parameter is set to "xxx" or is absent. Proposals: Replace: The default and only content defined for this package is "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". With: The default and only content defined for this package is "isdn-uui". When sending UUI, it is "RECOMMENDED" that the sending SIP entity = include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". A receiving SIP entity accepts a received User-to-User header field if = the "content" header field parameter is set to "isdn-uui" or is absent. Replace: The default and only encoding defined for this package is "hex". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". With: The default and only encoding defined for this package is "hex". When sending UUI, it is "RECOMMENDED" that the sending SIP entity = include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". A receiving SIP entity accepts a received User-to-User header field if = the "encoding" header field parameter set to "hex" or is absent. EDITORIAL: 1. Section "3.1. The service" ... The above come from the ISDN specifications defined for public networks. There are a parallel set of ISDN specifications defined for private networks (QSIG}. ... Wrong bracket 2. Page 5 2nd paragraph 2nd sentence: spelling -- descriminator --> = discriminator 3. Section "7. UAC requirements" Replace should--> SHOULD While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. Replace by: While there is no harm in including the "uui" option tag, and strictly it SHOULD be included if the extension is supported, it performs no function. 4. Section "8. UAS requirements" last paragraph last sentence. I would add an originally. So that the sentence read: There are no mechanisms for determining which was the originally = intended data packet so all are discarded. I hope this helps. Thank you Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von = Vijay K. Gurbani Gesendet: Samstag, 5. Mai 2012 20:26 An: cuss@ietf.org Betreff: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 All: Enrico and I will like to issue a WGLC for the two drafts that = constitute the remaining of our chartered work. These drafts have been = revised post-Paris IETF based on the discussion in Paris and subsequent = ratification on the mailing list. The two drafts are: draft-ietf-cuss-sip-uui-06 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-06) draft-ietf-cuss-sip-uui-isdn-04 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-04) The WGLC expires on May 27, 2012. We are looking for volunteers to perform WGLC on each of these = documents. Please let me and Enrico know as soon as you can if you are = able to help out. Thank you, Vijay K. Gurbani and Enrico Marocco _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From R.Jesske@telekom.de Tue May 22 00:08:03 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 495C311E8080 for ; Tue, 22 May 2012 00:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Ps+miKVHdF for ; Tue, 22 May 2012 00:08:02 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id C79B811E8085 for ; Tue, 22 May 2012 00:08:00 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 22 May 2012 09:07:57 +0200 Received: from HE113675.emea1.cds.t-internal.com (10.134.99.28) by HE111629.emea1.cds.t-internal.com (10.134.93.21) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 22 May 2012 09:07:46 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 22 May 2012 09:07:45 +0200 From: To: , Date: Tue, 22 May 2012 09:07:44 +0200 Thread-Topic: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Thread-Index: Ac0q6+DKuJUltJEvTnGCht6gQhbAngMRFXSAAAnB6jAAJHS4UA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D141616AAC7@HE111648.emea1.cds.t-internal.com> References: <4FA570D4.10006@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF4686AD@HE111648.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462025ABBA1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462025ABBA1@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: L.Liess@telekom.de, cuss@ietf.org Subject: Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 07:08:03 -0000 Hi, When I went through the discussion. I found the last comment on issue C10 t= hat with the following statement: > > **Section 13** > > C10: "This document adds the following row to the "UUI packages" > > sub- registry of the SIP parameter registry: Value: isdn-uui" =3D> it > > would be suitable to rename the value of package parameter from "isdn-u= ui" > > into "isdn-interwork". The goal would to allow compatibility with > > already deployed implementations that are based on the > > draft-johnston individual draft (draft referenced since a long time > > in 3GPP documents). There would be no change regarding the meaning > > because the definitions of "isdn- interwork" and "isdn-uui" values > > are exactly the same, for ISDN interworking scenarios ("which is to > > interoperate with ISDN User to User Signaling (UUS)"). > > > > This is driven directly from the mechanism draft, so I will follow > whatever it states there. So my conclusion was that the draft itself "sip-uui-isdn-04" does reflect w= hat the mechanism sip-uui-06 is defining. No more comments were made which = were following up that issue. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: celine.serrutvalette@orange.com [mailto:celine.serrutvalette@orange.co= m] Gesendet: Montag, 21. Mai 2012 16:22 An: keith.drage@alcatel-lucent.com Cc: Jesske, Roland; vkg@bell-labs.com; enrico.marocco@telecomitalia.it; cus= s@ietf.org Betreff: RE: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Hello, Related to GENERAL points 2 and 3, to follow the change of parameter name a= nd in order to ensure backward compatibility to early implementations based= on earlier drafts (e.g. draft-johnston-sipping-cc-uui-08) on which several= implementations are based, could you rename the value of "purpose" paramet= er from "isdn-uui" to "isdn-interwork" (see http://www.ietf.org/mail-archiv= e/web/cuss/current/msg00355.html, comment C10)? Indeed, the meaning of both= values is the same and the value is defined for ISDN interworking purpose = ("for interworking with the ISDN user-to-user service" in Section 13), ther= efore "isdn-interwork" is a relevant value for "purpose" parameter and in a= ddition it would allow backward compatibility. Please find also a minor comment in Section 13 ("This document adds the fol= lowing row to the "UUI packages" sub-registry of the SIP parameter registry= "), it seems that "UUI packages" should be replaced by "UUI purpose" as it = gives the parameter value which is registered to IANA for ISDN interworking= . Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de R.J= esske@telekom.de Envoy=E9 : lundi 21 mai 2012 13:34 =C0 : vkg@bell-labs.com= ; enrico.marocco@telecomitalia.it; cuss@ietf.org Objet : Re: [cuss] WGLC fo= r sip-uui-06 and sip-uui-isdn-04 Dear all, I was asked to review the draft sip-uui-isdn-04. The draft itself is in a g= ood shape and I propose to move forward in the process approval. Here are my comments in detail: GENERAL: 1. The draft is applicable for the intended scope of the document which cov= ers the interworking with both public ISDN and private ISDN capabilities. T= he aspects of QSIG probably stated. 2. All points of discussion on email list and meetings are reflected probab= ly. This includes one of the main discussion point, the name change "packag= e" to "purpose". 3. Backward compatibility to early implementations based on earlier drafts = are given. The appearance of the header fields "content" and "encoding" is = optional. 4. I wonder if a sentence for ISUP User-to-User transport and interworking = would help to understand that the ISUP interworking behavior is the same as= for ISDN. (For me it is clear) Text could look like: ISUP itself transport= s transparently the ISDN User-to-User Information element. The interworking= of ISUP with SIP applies with the same rules as for ISDN due to the fact t= hat ISUP itself transports transparently the ISDN User-to-User Information = element. DETAIL: 1. Section "3.1. The service" For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3 and section 7 [Q931]. I would propose to add an additional reference to Q.931 Section 4.5.30 wh= ere the User-user information element is defined. This helps the interested= reader of Q.931 to find also the related protocol element. Proposed Text: For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3, 4.5.30 and section = 7 [Q931]. 2. Section "9. UUI contents" I have some problems with the wording "...the sending SIP entity MAY, but n= eed not, include ..." There is not a direct guidance for implementation. I think we should use some more recommendatory wording. Like "...it is "RE= COMMENDED" that the sending SIP entity include a..." or "...it is "OPTIONAL" that the sending SIP entity include a..." To show that the element is not needed an additional sentence is added to s= how the behavior of the receiving entity: "A receiving SIP entity accepts a= received User-to-User header field if the "xxx" header field parameter is set to "xxx" or is absent. Proposals: Replace: The default and only content defined for this package is "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". With: The default and only content defined for this package is "isdn-uui". When sending UUI, it is "RECOMMENDED" that the sending SIP entity includ= e a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". A receiving SIP entity accepts a received User-to-User header field if the "content" header field parameter is set to "isdn-uui" or is absent. Replace: The default and only encoding defined for this package is "hex". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". With: The default and only encoding defined for this package is "hex". When sending UUI, it is "RECOMMENDED" that the sending SIP entity includ= e an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". A receiving SIP entity accepts a received User-to-User header field if the "encoding" header field parameter set to "hex" or is absent. EDITORIAL: 1. Section "3.1. The service" ... The above come from the ISDN specifications defined for public networks. There are a parallel set of ISDN specifications defined for private networks (QSIG}. ... Wrong bracket 2. Page 5 2nd paragraph 2nd sentence: spelling -- descriminator --> discrim= inator 3. Section "7. UAC requirements" Replace should--> SHOULD While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. Replace by: While there is no harm in including the "uui" option tag, and strictly it SHOULD be included if the extension is supported, it performs no function. 4. Section "8. UAS requirements" last paragraph last sentence. I would add an originally. So that the sentence read: There are no mechanisms for determining which was the originally intended d= ata packet so all are discarded. I hope this helps. Thank you Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von Vi= jay K. Gurbani Gesendet: Samstag, 5. Mai 2012 20:26 An: cuss@ietf.org Betreff: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 All: Enrico and I will like to issue a WGLC for the two drafts that constit= ute the remaining of our chartered work. These drafts have been revised po= st-Paris IETF based on the discussion in Paris and subsequent ratification = on the mailing list. The two drafts are: draft-ietf-cuss-sip-uui-06 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-06) draft-ietf-cuss-sip-uui-isdn-04 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-04) The WGLC expires on May 27, 2012. We are looking for volunteers to perform WGLC on each of these documents. = Please let me and Enrico know as soon as you can if you are able to help ou= t. Thank you, Vijay K. Gurbani and Enrico Marocco _______________________________________________ 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 celine.serrutvalette@orange.com Tue May 22 01:00: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 EF0B221F849A for ; Tue, 22 May 2012 01:00:41 -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 A33e5HcQ0PQN for ; Tue, 22 May 2012 01:00:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1721F8497 for ; Tue, 22 May 2012 01:00:40 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E7D5B2DC3F8; Tue, 22 May 2012 10:00:38 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C66F04C024; Tue, 22 May 2012 10:00:38 +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.0247.003; Tue, 22 May 2012 10:00:38 +0200 From: To: "R.Jesske@telekom.de" , "keith.drage@alcatel-lucent.com" Thread-Topic: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Thread-Index: Ac0q6+DKuJUltJEvTnGCht6gQhbAngMRFXSAAAnB6jAAJHS4UAAAcO1A Date: Tue, 22 May 2012 08:00:37 +0000 Message-ID: <25188_1337673638_4FBB47A6_25188_975_1_F8BE5641EC3C954DA088A8350BDDFA4892E0@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <4FA570D4.10006@bell-labs.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF4686AD@HE111648.emea1.cds.t-internal.com> <843DA8228A1BA74CA31FB4E111A5C462025ABBA1@ftrdmel0.rd.francetelecom.fr> <580BEA5E3B99744AB1F5BFF5E9A3C67D141616AAC7@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D141616AAC7@HE111648.emea1.cds.t-internal.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.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: 2012.5.16.153315 Cc: "L.Liess@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:00:42 -0000 Hello, Yes you're right the draft "sip-uui-isdn-04" does reflect what the mechanis= m "sip-uui-06" is defining since "sip-uui-isdn-04" has been updated with "p= urpose" parameter name instead of "package" as defined in the generic draft= (the value of the parameter for ISDN interworking is not defined in the ge= neric draft but in the ISDN one). Now "sip-uui-isdn-04" is modified with the parameter name, the next step wo= uld be the change of the parameter value (actually this comment C10 makes s= ense once the parameter name is "purpose", it has no sense when the paramet= er name was "package", that's why I didn't raise it again before.).=20 Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Envoy=E9=A0: mardi 22 mai 2012 09:08 =C0=A0: SERRUT-VALETTE Celine RD-CORE; keith.drage@alcatel-lucent.com Cc=A0: vkg@bell-labs.com; enrico.marocco@telecomitalia.it; cuss@ietf.org; L= .Liess@telekom.de; Martin.Huelsemann@telekom.de Objet=A0: AW: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Hi, When I went through the discussion. I found the last comment on issue C10 t= hat with the following statement: > > **Section 13** > > C10: "This document adds the following row to the "UUI packages" > > sub- registry of the SIP parameter registry: Value: isdn-uui" =3D> it > > would be suitable to rename the value of package parameter from "isdn-u= ui" > > into "isdn-interwork". The goal would to allow compatibility with > > already deployed implementations that are based on the > > draft-johnston individual draft (draft referenced since a long time > > in 3GPP documents). There would be no change regarding the meaning > > because the definitions of "isdn- interwork" and "isdn-uui" values > > are exactly the same, for ISDN interworking scenarios ("which is to > > interoperate with ISDN User to User Signaling (UUS)"). > > > > This is driven directly from the mechanism draft, so I will follow > whatever it states there. So my conclusion was that the draft itself "sip-uui-isdn-04" does reflect w= hat the mechanism sip-uui-06 is defining. No more comments were made which = were following up that issue. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: celine.serrutvalette@orange.com [mailto:celine.serrutvalette@orange.co= m] Gesendet: Montag, 21. Mai 2012 16:22 An: keith.drage@alcatel-lucent.com Cc: Jesske, Roland; vkg@bell-labs.com; enrico.marocco@telecomitalia.it; cus= s@ietf.org Betreff: RE: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 Hello, Related to GENERAL points 2 and 3, to follow the change of parameter name a= nd in order to ensure backward compatibility to early implementations based= on earlier drafts (e.g. draft-johnston-sipping-cc-uui-08) on which several= implementations are based, could you rename the value of "purpose" paramet= er from "isdn-uui" to "isdn-interwork" (see http://www.ietf.org/mail-archiv= e/web/cuss/current/msg00355.html, comment C10)? Indeed, the meaning of both= values is the same and the value is defined for ISDN interworking purpose = ("for interworking with the ISDN user-to-user service" in Section 13), ther= efore "isdn-interwork" is a relevant value for "purpose" parameter and in a= ddition it would allow backward compatibility. Please find also a minor comment in Section 13 ("This document adds the fol= lowing row to the "UUI packages" sub-registry of the SIP parameter registry= "), it seems that "UUI packages" should be replaced by "UUI purpose" as it = gives the parameter value which is registered to IANA for ISDN interworking. Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De : cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] De la part de R.J= esske@telekom.de Envoy=E9 : lundi 21 mai 2012 13:34 =C0 : vkg@bell-labs.com= ; enrico.marocco@telecomitalia.it; cuss@ietf.org Objet : Re: [cuss] WGLC fo= r sip-uui-06 and sip-uui-isdn-04 Dear all, I was asked to review the draft sip-uui-isdn-04. The draft itself is in a g= ood shape and I propose to move forward in the process approval. Here are my comments in detail: GENERAL: 1. The draft is applicable for the intended scope of the document which cov= ers the interworking with both public ISDN and private ISDN capabilities. T= he aspects of QSIG probably stated. 2. All points of discussion on email list and meetings are reflected probab= ly. This includes one of the main discussion point, the name change "packag= e" to "purpose". 3. Backward compatibility to early implementations based on earlier drafts = are given. The appearance of the header fields "content" and "encoding" is = optional. 4. I wonder if a sentence for ISUP User-to-User transport and interworking = would help to understand that the ISUP interworking behavior is the same as= for ISDN. (For me it is clear) Text could look like: ISUP itself transport= s transparently the ISDN User-to-User Information element. The interworking= of ISUP with SIP applies with the same rules as for ISDN due to the fact t= hat ISUP itself transports transparently the ISDN User-to-User Information = element. DETAIL: 1. Section "3.1. The service" For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3 and section 7 [Q931]. I would propose to add an additional reference to Q.931 Section 4.5.30 wh= ere the User-user information element is defined. This helps the interested= reader of Q.931 to find also the related protocol element. Proposed Text: For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3, 4.5.30 and section 7 [Q931]. 2. Section "9. UUI contents" I have some problems with the wording "...the sending SIP entity MAY, but n= eed not, include ..." There is not a direct guidance for implementation. I think we should use some more recommendatory wording. Like "...it is "RE= COMMENDED" that the sending SIP entity include a..." or "...it is "OPTIONAL" that the sending SIP entity include a..." To show that the element is not needed an additional sentence is added to s= how the behavior of the receiving entity: "A receiving SIP entity accepts a= received User-to-User header field if the "xxx" header field parameter is set to "xxx" or is absent. Proposals: Replace: The default and only content defined for this package is "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". With: The default and only content defined for this package is "isdn-uui". When sending UUI, it is "RECOMMENDED" that the sending SIP entity includ= e a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". A receiving SIP entity accepts a received User-to-User header field if the "content" header field parameter is set to "isdn-uui" or is absent. Replace: The default and only encoding defined for this package is "hex". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". With: The default and only encoding defined for this package is "hex". When sending UUI, it is "RECOMMENDED" that the sending SIP entity include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". A receiving SIP entity accepts a received User-to-User header field if the "encoding" header field parameter set to "hex" or is absent. EDITORIAL: 1. Section "3.1. The service" ... The above come from the ISDN specifications defined for public networks. There are a parallel set of ISDN specifications defined for private networks (QSIG}. ... Wrong bracket 2. Page 5 2nd paragraph 2nd sentence: spelling -- descriminator --> discrim= inator 3. Section "7. UAC requirements" Replace should--> SHOULD While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. Replace by: While there is no harm in including the "uui" option tag, and strictly it SHOULD be included if the extension is supported, it performs no function. 4. Section "8. UAS requirements" last paragraph last sentence. I would add an originally. So that the sentence read: There are no mechanisms for determining which was the originally intended d= ata packet so all are discarded. I hope this helps. Thank you Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im Auftrag von Vi= jay K. Gurbani Gesendet: Samstag, 5. Mai 2012 20:26 An: cuss@ietf.org Betreff: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04 All: Enrico and I will like to issue a WGLC for the two drafts that constit= ute the remaining of our chartered work. These drafts have been revised po= st-Paris IETF based on the discussion in Paris and subsequent ratification = on the mailing list. The two drafts are: draft-ietf-cuss-sip-uui-06 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-06) draft-ietf-cuss-sip-uui-isdn-04 (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-04) The WGLC expires on May 27, 2012. We are looking for volunteers to perform WGLC on each of these documents. = Please let me and Enrico know as soon as you can if you are able to help ou= t. Thank you, Vijay K. Gurbani and Enrico Marocco _______________________________________________ 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. From laura.liess.dt@googlemail.com Fri May 25 03:54:50 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 642D421F85E6 for ; Fri, 25 May 2012 03:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvhrjdM2RHyN for ; Fri, 25 May 2012 03:54:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 768DF21F852C for ; Fri, 25 May 2012 03:54:49 -0700 (PDT) Received: by yenq13 with SMTP id q13so276670yen.31 for ; Fri, 25 May 2012 03:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YwhLvAC0kJ3r0YEqqpnUMMrWSSn5PeQS4GuXp4pLoiQ=; b=N3vHsy7/ClaqUufNiBQgdhCtPrnAqdqzA3kaNjbHxRkGTI+Hbzbm2PmdlbWQ5DBNEP ZvNT8KwzHrds3EzBPC8hlVyaQV8YRwExzDIF+fnPlat84cAQF4QJy92XvJ8S2gh6CCLl yYTISAYoJztNWaa+7hP25OKDQsXHjo0td3NR49TeXOK3Fk8/R2pIcztkkaMARrYmrXRy oEl5zQJP+cEO1gUd2Qzf/UffjJaKCkugKoDwEwqqzWC7q8HXWSTGLJx1z28fEkru27HQ QwDA3tCtr48J6IHS1z/h+TNRUCNAZ86dedxtHEkunoFxDTM4HGJ5hPxCExQezSdz+y9b J3rw== MIME-Version: 1.0 Received: by 10.42.68.71 with SMTP id w7mr1738275ici.26.1337943288624; Fri, 25 May 2012 03:54:48 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Fri, 25 May 2012 03:54:48 -0700 (PDT) Date: Fri, 25 May 2012 12:54:48 +0200 Message-ID: From: Laura Liess To: "Vijay K. Gurbani" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: [cuss] WGLC review for draft-ietf-cuss-sip-uui-06 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, 25 May 2012 10:54:50 -0000 Dear Vijay, You asked me to provide a WGLC review of the document draft-ietf-cuss-sip-uui-06. I read the document and I think it is in good shape. Just a few minor comments: Section 3, 5-th paragraph: Add explicit reference to draft-ietf-cuss-sip-uui-isdn. Old text: =93Since the basic design of the UUI header field is similar to the ISDN UUI service, interworking with PSTN protocols will be straightforward and will be documented in a separate specification, meeting REQ-6.=94 New text: =93Since the basic design of the UUI header field is similar to the ISDN UUI service, interworking with PSTN protocols will be straightforward and >>is<< documented in a separate specification >>[I-D.draft-ietf-cuss-sip-uui-isdn]<<, meeting REQ-6.=94 (changed or added text is between >> and <<). Section 4: - My understanding is that more than one content values can be defined for a UUI package. If this is the case, the sentence =93Newly defined UUI packages MUST define a new "content" value.=94 should be something like =93Newly defined UUI packages MUST define new "content" value >>s and the default<<.=94 Section 4.1, the example at the end of the section: - The current text: =93redirection response F2 of Figure 3=94. Is =93Figure 3=94 correct here? - The current text: =93The resulting INVITE F5 would contain:=94 But in the RFC 6567 Figure 3 (and also in Figure 2), F5 is a 200 OK. Or did I miss something? Section 4.3: Proxies/B2BUAs at a network border may anonymize SIP URIs in the History-Info (the DT SBCs do that when the redirecting party requested privacy) or may drop it (also I don=92t know about real implementations doing that). This is OK and the issue was already discussed on the ML. In most scenarios the application in the UA consuming the UUI data will be probably able to identify the sender at application level. However, I think it could be useful to have some words about this issue at the end of Section 4.3, something like: =93Proxies/B2BUAs at a network border anonymizing a SIP URI in the History-Info SHOULD leave the corresponding User-to-User parameter, if present, and the corresponding User-to-User header, unchanged. Proxies/B2BUAs at a network border dropping a History-Info header which contains User-to-User parameter, SHOULD not drop the corresponding User-to-User header. In such cases the UA consuming the UUI data are not able, at SIP level, to identify the source, but in most cases it may be able to do it at the application level.=93 But I am also OK if the authors think adding such a text is not useful. Section 10.2 and throughout the document: Replace [I-D.ietf-cuss-sip-uui-reqs] by [RFC6567]. Thank you Laura From pkyzivat@alum.mit.edu Fri May 25 07:31:39 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 BE8A021F8671 for ; Fri, 25 May 2012 07:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08qvPou6MGcb for ; Fri, 25 May 2012 07:31:39 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 295AC21F8617 for ; Fri, 25 May 2012 07:31:38 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id ECsQ1j00827AodY51EXeV5; Fri, 25 May 2012 14:31:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id EEXe1j00707duvL3fEXedP; Fri, 25 May 2012 14:31:38 +0000 Message-ID: <4FBF97C9.7000105@alum.mit.edu> Date: Fri, 25 May 2012 10:31:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [cuss] WGLC review for draft-ietf-cuss-sip-uui-06 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, 25 May 2012 14:31:39 -0000 On 5/25/12 6:54 AM, Laura Liess wrote: > Section 4: > - My understanding is that more than one content values can be defined > for a UUI package. If this is the case, the sentence “Newly defined > UUI packages MUST define a new "content" value.” should be something > like “Newly defined UUI packages MUST define new "content" value>>s > and the default<<.” It seems that this section was not updated to be consistent with the language now present in section 5. (The 2nd paragraph #3.) Not only can there be multiple valid content values for a package, but a package can reuse content values defined elsewhere. This means that it might not be necessary to define new content values when defining a package. While looking at this I realized something else. Given the way we have evolved the use of "encoding", I think it would make sense to bind the valid encodings to a particular content value, rather than to a particular package. So, when defining a new "content" one would have to specify which encoding(s) it may have. When specifying a new package one would only need to specify what content values it may have. Does that make sense to anybody else? Thanks, Paul From laura.liess.dt@googlemail.com Tue May 29 01:57:56 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 6FE1721F8744 for ; Tue, 29 May 2012 01:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQehAplPU-17 for ; Tue, 29 May 2012 01:57:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A49A021F8741 for ; Tue, 29 May 2012 01:57:55 -0700 (PDT) Received: by yhq56 with SMTP id 56so2480095yhq.31 for ; Tue, 29 May 2012 01:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2zKnehDx/C80OjCKlx0/3INNGwKS+yGIRSblzdrzghI=; b=l7NeEeplndBpmYF4owdFk4xZi38Hh1xDOmJg21dXQGS40kabDx+gNegdYIFFy4YxdZ iBF5uuYC/Hera2+c763Pnxh1cwKstn0rLTjBQcf+I0B5b8zPOz1sJClKyeyU7KjjyZiG 7es4+ZM6gu1kxN7iAmU6PCVJJm3waNB0VoEvmmo8TxhOATcz4ftupjfFRtOKsTc62tHz 7/Wyv4wUtg1RdWi28RANQZz67SPgJBDBhaXQy/CQ+228rNaUPdWBjPVw2yKbW9OfKYc9 tbhlgqhr63yHWV+hlVD/vmZKlHI50Ygn4SWTfsobYoSTc5iYmXKmL1gRwxQlA7We+odC I56Q== MIME-Version: 1.0 Received: by 10.50.91.233 with SMTP id ch9mr6229855igb.8.1338281875014; Tue, 29 May 2012 01:57:55 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Tue, 29 May 2012 01:57:54 -0700 (PDT) In-Reply-To: <4FBF97C9.7000105@alum.mit.edu> References: <4FBF97C9.7000105@alum.mit.edu> Date: Tue, 29 May 2012 10:57:54 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat , cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cuss] WGLC review for draft-ietf-cuss-sip-uui-06 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 08:57:56 -0000 Paul, 2012/5/25 Paul Kyzivat : > > While looking at this I realized something else. Given the way we have > evolved the use of "encoding", I think it would make sense to bind the va= lid > encodings to a particular content value, rather than to a particular > package. So, when defining a new "content" one would have to specify whic= h > encoding(s) it may have. When specifying a new package one would only nee= d > to specify what content values it may have. I agree with you. It makes much more sense to bind the encodings to content values instead of packages. And easier to understand. Just I am not sure which consequencies would this change have for both drafts and if we do not run again into the "existing implementation" issue. I would like to know Alan's and Keith's and FT's opinion. Thanks a lot Laura > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss