From Vijay.Gurbani@alcatel-lucent.com Thu Sep 1 10:41:44 2011 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 34EDC21F933B for ; Thu, 1 Sep 2011 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 9ezcSNe7JlWY for ; Thu, 1 Sep 2011 10:41:43 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9B00321F932A for ; Thu, 1 Sep 2011 10:41:43 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p81HhE7p023484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Sep 2011 12:43:15 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p81HhEaY021557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Sep 2011 12:43:14 -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 p81HhEnb022359 for ; Thu, 1 Sep 2011 12:43:14 -0500 (CDT) Message-ID: <4E5FC4A9.8060203@alcatel-lucent.com> Date: Thu, 01 Sep 2011 12:45:13 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [cuss] 2nd WGLC for draft-ietf-cuss-sip-uui-reqs over X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 17:41:44 -0000 Folks: The 2nd WGLC for draft-ietf-cuss-sip-uui-reqs is now over. Dale has posted a set of comments, which will need a resolution by the authors of the draft. I believe Alan is planning to release an updated draft next week, whereupon Enrico and I will move this work ahead to IESG. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From md3135@att.com Thu Sep 1 10:51:36 2011 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 2B24F21F955F for ; Thu, 1 Sep 2011 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 A4uHp1v50FJS for ; Thu, 1 Sep 2011 10:51:35 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B395B21F94B7 for ; Thu, 1 Sep 2011 10:51:34 -0700 (PDT) X-Env-Sender: md3135@att.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1314899585!37101782!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15486 invoked from network); 1 Sep 2011 17:53:06 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 17:53:06 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p81HrVWs007463; Thu, 1 Sep 2011 13:53:31 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p81Hpmec002170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Sep 2011 13:53:07 -0400 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([169.254.5.157]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0289.001; Thu, 1 Sep 2011 13:51:38 -0400 From: "DOLLY, MARTIN C" To: "'Vijay.Gurbani@alcatel-lucent.com'" , "'cuss@ietf.org'" Thread-Topic: [cuss] 2nd WGLC for draft-ietf-cuss-sip-uui-reqs over Thread-Index: AQHMaM6YmdTzzdlNn0KDX/lpJP1GCpU4zfr+ Date: Thu, 1 Sep 2011 17:51:37 +0000 Message-ID: In-Reply-To: <4E5FC4A9.8060203@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.151.223.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] 2nd WGLC for draft-ietf-cuss-sip-uui-reqs over X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 17:51:36 -0000 ATT believes this draft is ready, that is why we did not post comments Martin C. Dolly Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink = Possible. +1.609.903.3360 ----- Original Message ----- From: Vijay K. Gurbani [mailto:Vijay.Gurbani@alcatel-lucent.com] Sent: Thursday, September 01, 2011 01:45 PM=0A= To: cuss@ietf.org Subject: [cuss] 2nd WGLC for draft-ietf-cuss-sip-uui-reqs over Folks: The 2nd WGLC for draft-ietf-cuss-sip-uui-reqs is now over. Dale has posted a set of comments, which will need a resolution by the authors of the draft. I believe Alan is planning to release an updated draft next week, whereupon Enrico and I will move this work ahead to IESG. Thanks, - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From dworley@avaya.com Thu Sep 1 11:19:45 2011 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 E60DF21F98A0 for ; Thu, 1 Sep 2011 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.348 X-Spam-Level: X-Spam-Status: No, score=-103.348 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 6db6VMxT2E7f for ; Thu, 1 Sep 2011 11:19:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 33BCE21F9893 for ; Thu, 1 Sep 2011 11:19:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHPMX06HCzI1/2dsb2JhbABCqE53gUABAQEBAgESKEQLAgEIDQghEDIlAQEEARIIGodQnSMCnEaFe2AEmFGLeg X-IronPort-AV: E=Sophos;i="4.68,314,1312171200"; d="scan'208";a="265631007" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Sep 2011 14:21:16 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Sep 2011 14:12:30 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 1 Sep 2011 14:21:15 -0400 From: "Worley, Dale R (Dale)" To: "Vijay K. Gurbani" , "cuss@ietf.org" Date: Thu, 1 Sep 2011 14:20:37 -0400 Thread-Topic: [cuss] 2nd WGLC for draft-ietf-cuss-sip-uui-reqs over Thread-Index: AcxozqO6WmL4rS8dTbamGX6UvUftvAABTVge Message-ID: References: <4E5FC4A9.8060203@alcatel-lucent.com> In-Reply-To: <4E5FC4A9.8060203@alcatel-lucent.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 Subject: Re: [cuss] 2nd WGLC for draft-ietf-cuss-sip-uui-reqs over X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 18:19:46 -0000 > From: Vijay K. Gurbani [Vijay.Gurbani@alcatel-lucent.com] >=20 > I believe Alan is planning to release an updated draft > next week, whereupon Enrico and I will move this work > ahead to IESG. Great! Dale From Vijay.Gurbani@alcatel-lucent.com Fri Sep 2 09:31:19 2011 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 01BE121F8B05 for ; Fri, 2 Sep 2011 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, 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 x9H1MmsIoUhR for ; Fri, 2 Sep 2011 09:31:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5841C21F8AF9 for ; Fri, 2 Sep 2011 09:31:18 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p82GWq3g002220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Sep 2011 11:32:52 -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 p82GWpHK019197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Sep 2011 11:32:52 -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 p82GWpHD029048 for ; Fri, 2 Sep 2011 11:32:51 -0500 (CDT) Message-ID: <4E6105AF.10207@alcatel-lucent.com> Date: Fri, 02 Sep 2011 11:34:55 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [cuss] Virtual interim: Mark your calendars 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, 02 Sep 2011 16:31:19 -0000 Folks: Based on the responses to the poll that Enrico initiated, it seems that Wed. Sept. 21, 2011 is agreeable for a virtual interim. As such, we will like to hold a virtual interim meeting for the CUSS WG as follows: Date: Wed, Sept. 21, 2011 Time: 10:00 AM US Central / 11:00 AM US Eastern / 8:00 AM US Pacific / 5:00 PM Paris, Frankfurt / 4:00 PM London WebEx details and agenda will follow soon. Please mark your calendars. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From wwwrun@ietfa.amsl.com Tue Sep 6 10:37:13 2011 Return-Path: X-Original-To: cuss@ietf.org Delivered-To: cuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 6026721F8C66; Tue, 6 Sep 2011 10:37:13 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110906173713.6026721F8C66@ietfa.amsl.com> Date: Tue, 6 Sep 2011 10:37:13 -0700 (PDT) Cc: cuss@ietf.org Subject: [cuss] CUSS Working Group Virtual Interim Meeting: September 21, 2011 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:37:13 -0000 The CUSS working group will hold a virtual interim meeting, with WebEx support, as follows: Date: Wed, Sept. 21 2011 Time: 10:00 AM US Central - 12:00 PM US Central WebEx details for this meeting will be posted to the CUSS mailing list (http://www.ietf.org/mail-archive/web/cuss/) From vkg@bell-labs.com Thu Sep 8 06:45:31 2011 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 0C56A21F8B7C for ; Thu, 8 Sep 2011 06:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 JBcdowvkp8aN for ; Thu, 8 Sep 2011 06:45:30 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1253D21F8B71 for ; Thu, 8 Sep 2011 06:45:29 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p88DlLW2013235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Sep 2011 08:47:21 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88DlLpS026565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Sep 2011 08:47: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 p88DlK8P011813 for ; Thu, 8 Sep 2011 08:47:21 -0500 (CDT) Message-ID: <4E68C7F4.8060200@bell-labs.com> Date: Thu, 08 Sep 2011 08:49:40 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Candidate drafts for last milestone (application usage specification for the ISDN UUI service) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:45:31 -0000 Folks: Enrico and I will have a draft agenda out shortly for the virtual interim meeting on Sept-21. In the meantime, the remaining chartered deliverable that does not have a draft assigned to it is: - An application usage specification for the ISDN UUI Service. On the agenda will be some discussion to choose a draft towards that deliverable. There is an (expired) candidate draft from Keith Drage [1]. Keith will be resurrecting the expired draft before the virtual interim. However, if anyone else wants to put forth a candidate draft, please do so over the next couple of weeks. During the virtual interim, we will like to choose a candidate draft as the charter deliverable. [1] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-00 Thank you, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Thu Sep 8 08:11:36 2011 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 AF47421F84DA for ; Thu, 8 Sep 2011 08:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 aJyw+DnCeO+K for ; Thu, 8 Sep 2011 08:11:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2689121F84BB for ; Thu, 8 Sep 2011 08:11:35 -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 p88FDQeq027934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Sep 2011 10:13:27 -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 p88FDQvl004371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Sep 2011 10:13:26 -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 p88FDQhQ013104 for ; Thu, 8 Sep 2011 10:13:26 -0500 (CDT) Message-ID: <4E68DC21.7040404@bell-labs.com> Date: Thu, 08 Sep 2011 10:15:45 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 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] WebEx coordinates for virtual meeting X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 15:11:36 -0000 The CUSS virtual interim meeting is scheduled on Date: Wed, Sept. 21, 2011 Time: 10:00 AM US Central / 11:00 AM US Eastern / 8:00 AM US Pacific / 5:00 PM Paris, Frankfurt / 4:00 PM London Webex coordinates are as follows: Topic: CUSS WG Virtual Interim Meeting Date: Wednesday, September 21, 2011 Time: 10:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 962 641 663 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=182406412&UID=1251558807&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=182406412&UID=1251558807&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=182406412&tollFree=0 Access code:962 641 663 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=182406412&UID=1251558807&ICS=MI&LD=1&RD=2&ST=1&SHA2=yhBUKtALdYmNz30ZDSBnlj1BJJLJLfXxb8wqfMHjREs=&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x962641663# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Thu Sep 8 08:42:06 2011 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 7209321F8B1A for ; Thu, 8 Sep 2011 08:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 3YY7Wi2oMAse for ; Thu, 8 Sep 2011 08:42:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE921F8ADE for ; Thu, 8 Sep 2011 08:42:04 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p88FhurE029239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Sep 2011 10:43:57 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88Fhu66013507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Sep 2011 10:43:56 -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 p88FhuKI016823 for ; Thu, 8 Sep 2011 10:43:56 -0500 (CDT) Message-ID: <4E68E347.3040309@bell-labs.com> Date: Thu, 08 Sep 2011 10:46:15 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [cuss] Draft agenda for virtual interim meeting X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 15:42:06 -0000 Folks: The CUSS virtual interim meeting is scheduled on Date: Wed, Sept. 21, 2011 Time: 10:00 AM US Central / 11:00 AM US Eastern / 8:00 AM US Pacific / 5:00 PM Paris, Frankfurt / 4:00 PM London Webex coordinates are at [1]. A draft agenda for CUSS virtual interim appears below. If anyone would like to add/remove/change items in the agenda, please let me and Enrico know. - Chair slides and administrivia, 5m - Mechanism draft. James Rafferty, 30m - ISDN UUI service application usage discussion (Open, 25m) - Candidate drafts: - draft-drage-cuss-sip-uui-isdn - Others [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00235.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From internet-drafts@ietf.org Fri Sep 9 08:37:06 2011 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 DB7DC21F8AB8; Fri, 9 Sep 2011 08:37:06 -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.104, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 UUxDayrH5apu; Fri, 9 Sep 2011 08:37:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8469721F889A; Fri, 9 Sep 2011 08:37:06 -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: 3.60 Message-ID: <20110909153706.29355.60061.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2011 08:37:06 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 15:37:07 -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 : Problem Statement and Requirements for Transporting User= to User Call Control Information in SIP Author(s) : Alan Johnston Laura Liess Filename : draft-ietf-cuss-sip-uui-reqs-05.txt Pages : 11 Date : 2011-09-09 This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-05.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-reqs-05.txt From alan.b.johnston@gmail.com Fri Sep 9 08:37:31 2011 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 7B66821F86A1 for ; Fri, 9 Sep 2011 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 iXruoO+RrV3I for ; Fri, 9 Sep 2011 08:37:30 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6900B21F8888 for ; Fri, 9 Sep 2011 08:37:30 -0700 (PDT) Received: by gwb17 with SMTP id 17so1844207gwb.15 for ; Fri, 09 Sep 2011 08:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XZ3+pKTsHWq+m/CURMaRTu6g0OsFmWfJPkn/mlUBzag=; b=q1QMgiaxyyUnh9g30gS1wvbyYId4HedaARlZPZuDV8D2oAmhb3VAasHYmDqcVCSQnM 8IYINvdNvVRf3p9+frg4xUBOLKdMy7kFVD59QfDRtwmKSExLC12OWkqWz/3ZMfQJLqQT adstI4VXCgXEM65yp7eiF5Oyb8WXVpGAb4S6M= MIME-Version: 1.0 Received: by 10.150.40.15 with SMTP id n15mr2175784ybn.0.1315582765421; Fri, 09 Sep 2011 08:39:25 -0700 (PDT) Received: by 10.151.7.5 with HTTP; Fri, 9 Sep 2011 08:39:25 -0700 (PDT) In-Reply-To: References: <4E4AECE1.9060704@bell-labs.com> Date: Fri, 9 Sep 2011 10:39:25 -0500 Message-ID: From: Alan Johnston To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] Second round of WGLC for draft-ietf-cuss-sip-uui-reqs X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 15:37:31 -0000 Dale, Thanks for your comments. See mine below. I have updated the draft based on your comments. - Alan - On Wed, Aug 24, 2011 at 1:17 PM, Worley, Dale R (Dale) wrote: > Here are my comments on draft-ietf-cuss-sip-uui-reqs-04. > > 2.2. =A0Proxy Retargeting > > I am not sure I can tell what the point of this use case is. =A0I > *think* that the idea is that in this case the proxy is changing the > request-URI, whereas in 2.1, it is silently assumed that the proxy is > not changing the request-URI. You are correct. =A0(My practical experience is that > proxies change request-URIs almost all the time, so the default case > of a proxy simply forwarding based on the existing request-URI doesn't > come naturally to mind.) =A0But there are also unclarities in the > wording. =A0E.g,., "the terminating UA" vs. "a different termination > UA", but only one terminating UA is shown. > > *If* I am right, this would be clearer as: > > =A0 In this scenario, the originator UA includes UUI in the INVITE sent > =A0 through a proxy to the terminating UA. =A0The proxy retargets the > =A0 INVITE, changing its request-URI to a URI that addresses the > =A0 termination UA. =A0The UUI information is then received and processed > =A0 by the terminating UA. =A0This call flow is identical to Figure 1 > =A0 except that the proxy retargets the request, i.e., changes the > =A0 request-URI as directed by some unspecified process. =A0The UUI in > =A0 the INVITE needs to be passed unchanged through this proxy > =A0 retargeting operation. I have used your description. > > Also, the use of "originator" vs. "originating" and "terminator" > vs. "terminating" is not clear. =A0My impression is that in telecomm > usage, the latter terms are favored over the former terms; this > document prefers "originator" and "terminator", but also uses > "termination" and "terminating". I have changed all the references to originating and terminating. > > 2.4. =A0Referral > > I would be a bit clearer to say: > > =A0 [...] =A0In some cases, this call flow is used in place of the > =A0 redirection call flow: =A0the Referrer immediately answers the call > =A0 and then sends the REFER. =A0This scenario is shown in Figure 3. > I have used this language. > REQ-1 > > Change "includes" to "include", since the subject of "include" is > "responses": > > =A0 SIP messages covered by this include INVITE requests and end-to- > =A0 end responses to the INVITE, which >>>include<<< 18x, 200, and 3xx > =A0 responses. I have rewritten it to remove the second include: "SIP messages covered by this include INVITE requests and end-to-end responses to the INVITE, i.e. 18x, 200, and 3xx responses." > > REQ-6 > > It reads better changing the "or"s to "and"s: > > =A0 REQ-6: The mechanism will support interworking with call control > =A0 related DSS1 information elements, QSIG information elements, and > =A0 ISUP parameters. Done. > > REQ-8 > > The grammar of REQ-8 is not quite correct. =A0Perhaps this is better: > > =A0 REQ-8: The mechanism will allow a UAC to require that a UAS > =A0 understands the call control UUI mechanism in order to have a > =A0 request routed to IT. =A0[...] > > or perhaps the word "and" is omitted here: > > =A0 REQ-8: The mechanism will allow a UAC to require that a UAS > =A0 understands the call control UUI mechanism >>>and<<< have a request > =A0 routed based on this information. =A0[...] Added the and. > > REQ-11 > > =A0 REQ-11: The solution will provide a mechanism of transporting at > =A0 least 128 octets of user data and a one octet protocol discriminator, > =A0 i.e. 129 octets in total. > > I would make explicit that the UUI is a sequence of octets, because > there is no other place where we state the data model we envision for > UUI. =A0Viz.: > > =A0 REQ-11: The UUI is a sequence of octets. =A0The solution will provide > =A0 a mechanism for transporting at least 128 octets of user data and a > =A0 separate one-octet protocol discriminator, i.e. 129 octets in total. Done. > > 4. =A0Security Considerations > > The last sentence of the 1st paragraph does not (IMHO) clearly state > what everyone knows that it means. =A0Perhaps: > > =A0 [...] =A0As such, is important for application users of SIP UUI to > =A0 know the level of security used and deployed in their particular > =A0 SIP environments, and not to assume that a standardized (but > =A0 perhaps rarely deployed) security mechanism is in place. > Done. > The following two paragraphs document 3 security approaches, despite > stating that they contain two. =A0Some revisions: > > =A0 There are >>>three<<< main security models that need to be > =A0 addressed by the SIP UUI mechanism. =A0One model treats the SIP layer > =A0 as untrusted and requires end-to-end integrity protection and/or > =A0 encryption. =A0This model can be achieved by providing these security > =A0 services at a layer above SIP. =A0In this case, the application > =A0 integrity protects and/or encrypts the UUI information before > =A0 passing it to the SIP layer. =A0This method has two advantages: it > =A0 does not assume or rely on end-to-end security mechanisms in SIP > =A0 (which have virtually no deployment), and allows the application > =A0 which understands the contents of the UUI to apply a proper level > =A0 of security. > > =A0 >>>A second approach<<< is for the application to pass the UUI withou= t > =A0 any protection to the SIP layer and require the SIP layer to > =A0 provide this security, >>>e.g., through routing requests using sips: > =A0 URIs<<<. =A0This approach is possible in theory, although its practic= al > =A0 use would be extremely limited. > > =A0 =A0>>>The third model<<< utilizes a trust domain and relies on perime= ter > =A0 security at the SIP layer. =A0This is the security model of the PSTN > =A0 and ISDN where UUI is commonly used today. =A0This approach uses hop- > =A0 by-hop security mechanisms and relies on border elements for > =A0 filtering and application of policy. =A0This approach is used today i= n > =A0 SIP UUI deployments. =A0>>>Within this approach, there is a > =A0 requirement that intermediary elements can detect and remove a UUI > =A0 element based on policy, but there is no requirement that an > =A0 intermediary element be able to read or interpret the UUI (as the UUI > =A0 contents only have end-to-end significance).<<< I have used your text. > > Within these three models, it's not clear to me exactly what the > security requirements (REQ-13, REQ-14, and REQ-15) mean. =A0Does each > requirement apply within the environment of each model? =A0And seemingly > the threat model changes between models: =A0in model 1, the SIP > intermediaries are untrusted; in model 2, the SIP intermediaries seem > to be trusted, but the networks are not trusted; and in model 3, the > "walled garden" network is entirely trusted. The answer depends on the mechanism. I think the discussion of to what extend these security requirements can be met in a realistic SIP deployment should be in the requirements document. > > Dale > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From vkg@bell-labs.com Fri Sep 9 11:35:23 2011 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 476AA21F889A for ; Fri, 9 Sep 2011 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 ADjxvSNi8pUO for ; Fri, 9 Sep 2011 11:35:22 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5FECE21F87FA for ; Fri, 9 Sep 2011 11:35:21 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p89IbHlK027497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Sep 2011 13:37:17 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p89IbGEi010719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Sep 2011 13:37:17 -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 p89IbGBU020074 for ; Fri, 9 Sep 2011 13:37:16 -0500 (CDT) Message-ID: <4E6A5D67.9010507@bell-labs.com> Date: Fri, 09 Sep 2011 13:39:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110831 Fedora/3.1.12-2.fc14 Lightning/1.0b2 Thunderbird/3.1.12 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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Moving draft-ietf-cuss-sip-uui-reqs ahead X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 18:35:23 -0000 Folks: Enrico and I have prepared a proto writeup based on the newly released draft-ietf-cuss-sip-uui-reqs-05. The proto writeup appears below and has been uploaded to the data tracker. We will notify our AD to move this draft ahead to IESG review. Thanks. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I (Vijay K. Gurbani) am the Document Shepherd. I have personally reviewed the latest version of the document and believe that it is ready for forwarding to IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has been reviewed by key WG and non-WG members that include John Elwell, Dale Worley, Christian Schmidt, Christer Holmberg, Roland Jesske, Martin Dolly, and Paul Kyzivat. Many among the list of reviewers are subject matter experts in SIP. I do not have any concerns about the depth or breadth of the reviews related to this work. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not have any concerns about broader reviews. The document proposes requirements on transporting user-to-user data in SIP. As such, it has been exposed to review and has received feedback from many subject matter experts in SIP. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any concerns that the AD should be aware of. I am not aware of any IPR disclosure related to this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I believe that the WG consensus behind the document is strong. The document has been subject to two WGLCs, with a plurality of comments provided during each phase from at least 7-8 distinct reviewers. Each of these comments were addressed in subsequent revisions, and the reviewers who had contributed those comments have been consistently satisfied with the resolution of these comments in revised versions. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No one has threatned an appeal or otherwise indicated extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, I have personally verified that all nits have been addressed. In the version going to the IESG (-05), there is only one nit --- reference to RFC2119 is defined but not used. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. There are no normative references. All references are informative. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document does not put any burden on IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This is a requirement document, as such there aren't any occurrences of a grammar or MIB definitions. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. Working Group Summary The working group consensus on this document is solid. Two WGLCs were held to ensure that all comments and feedback were accounted for. Document Quality This is a requirement document, as such there aren't any implementation details to list. That said, the document has received a positive nod from major service provider and equipment vendors. From keith.drage@alcatel-lucent.com Mon Sep 19 04:39:56 2011 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 2019D21F8BB3 for ; Mon, 19 Sep 2011 04:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 TgD8MdTt4gOx for ; Mon, 19 Sep 2011 04:39:55 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCEA21F8BAE for ; Mon, 19 Sep 2011 04:39:52 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8JBg5WY017480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Sep 2011 13:42:14 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 19 Sep 2011 13:42:05 +0200 From: "DRAGE, Keith (Keith)" To: "Cuss@ietf.org" Date: Mon, 19 Sep 2011 13:42:04 +0200 Thread-Topic: Registration requirements for new parameter values in the User-to-User header field Thread-Index: Acx2wScCocq0uzEoTZi2H9qtbLHjbQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [cuss] Registration requirements for new parameter values in the User-to-User header field X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:39:56 -0000 The syntax defines a number of new parameters for the header field. UUI =3D "User-to-User" HCOLON uui-data *(SEMI uui-param) uui-data =3D token uui-param =3D enc-param | cont-param | app-param | generic-param enc-param =3D "encoding=3D"("hex" | token) cont-param =3D "content=3D" token app-param =3D "app=3D" token The registration requirement for defining new header field parameter values= according to RFC 3968 is a published RFC, but this says nothing about the = strength required to define a new value - which are not registered. The only text we have in draft-ietf-cuss-sip-uui-01 about registration stre= ngth for new values is on the encoding parameter, which seems to require st= andards track RFC. My starting question is what strength do we really want to make on adding n= ew values to this header field, which ultimately comes down to what limitat= ions do we want to place on defining new application packages (such as ISDN= -UUI. Should it be standards track or are we going to make it as wide open = as the info-package definition. Regards Keith From keith.drage@alcatel-lucent.com Mon Sep 19 05:12:26 2011 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 25EC721F8B9B for ; Mon, 19 Sep 2011 05:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.957 X-Spam-Level: X-Spam-Status: No, score=-105.957 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 uEw6Y1n1VWpI for ; Mon, 19 Sep 2011 05:12:25 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1F821F848E for ; Mon, 19 Sep 2011 05:12:25 -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 p8JCDF0s020343 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Sep 2011 14:14:46 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 19 Sep 2011 14:14:33 +0200 From: "DRAGE, Keith (Keith)" To: "Cuss@ietf.org" Date: Mon, 19 Sep 2011 14:14:32 +0200 Thread-Topic: Redirection requirements Thread-Index: Acx2xbBHZRWnOSyYRYqUDnIeN8j3Xg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [cuss] Redirection requirements X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 12:12:26 -0000 The current requirements specify that it is possible that were A calls B an= d B forwards to C, B can send UUI data to C. How do we expect this to work? >From B to C we have suggested that we might tag the data on to the History-= Info header or something like, so that the UUI data is associated with the = URI of B. Given that an INVITE to C may be initiated from a proxy server, that receiv= ed a 3xx response from B, what does the 3xx response look like? And if the 3xx response goes all the way back to A, is B also allowed to in= clude a separate UUI that is intended for A rather than C? (And therefore e= ncoded distinctly from that intended for C). >From my perspective (the ISDN interworking) I don't need to know how to do = this, but I do need to know what to preclude because it will not work in th= e ISDN interworking case. Regards Keith From dworley@avaya.com Mon Sep 19 07:29:22 2011 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 327DC21F8BF6 for ; Mon, 19 Sep 2011 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 zOUgwVGK7BDG for ; Mon, 19 Sep 2011 07:29:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB721F8BDE for ; Mon, 19 Sep 2011 07:29:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMNRd07GmAcF/2dsb2JhbABCpyl3gVMBAQEBAgESKEQLAgEIDQghEDIlAQEEARIIGodVmjgCmnuGGGAEmQWMDQ X-IronPort-AV: E=Sophos;i="4.68,405,1312171200"; d="scan'208";a="304398128" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Sep 2011 10:31:44 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Sep 2011 10:31:13 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 19 Sep 2011 10:31:43 -0400 From: "Worley, Dale R (Dale)" To: "DRAGE, Keith (Keith)" , "Cuss@ietf.org" Date: Mon, 19 Sep 2011 10:29:35 -0400 Thread-Topic: Redirection requirements Thread-Index: Acx2xbBHZRWnOSyYRYqUDnIeN8j3XgAEt3e7 Message-ID: References: In-Reply-To: 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 Subject: Re: [cuss] Redirection requirements X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 14:29:22 -0000 > From: cuss-bounces@ietf.org [cuss-bounces@ietf.org] On Behalf Of DRAGE, K= eith (Keith) [keith.drage@alcatel-lucent.com] >=20 > The current requirements specify that it is possible that were A calls B = and B forwards to C, B can send UUI data to C. >=20 > How do we expect this to work? If the UUI is encoded in a header, one possibility is to include a "header"= in the Contact header of a 3xx response: SIP/2.0 302 Moved Temporarily ... Contact: sip:foo@example.com?UUI=3DAAAAAAAAAAAAAAAAAAAAAAAAAAAA Dale From keith.drage@alcatel-lucent.com Mon Sep 19 08:18:02 2011 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 B049821F8C3A for ; Mon, 19 Sep 2011 08:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.962 X-Spam-Level: X-Spam-Status: No, score=-105.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 3y-UaBw6UE1r for ; Mon, 19 Sep 2011 08:18:02 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A9DCB21F8C00 for ; Mon, 19 Sep 2011 08:18:01 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8JFJpCQ016130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 19 Sep 2011 17:20:18 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 19 Sep 2011 17:20:03 +0200 From: "DRAGE, Keith (Keith)" To: "Worley, Dale R (Dale)" , "Cuss@ietf.org" Date: Mon, 19 Sep 2011 17:20:02 +0200 Thread-Topic: Redirection requirements Thread-Index: Acx2xbBHZRWnOSyYRYqUDnIeN8j3XgAEt3e7AAGbO5A= Message-ID: References: In-Reply-To: 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] Redirection requirements X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 15:18:02 -0000 Yes that is what I was assuming, but the functionality has to be more compl= icated that that. We have an underlying requirement that the source of the UUI is identified = (in the absence of such identification it has come from A). Thus if A forwards to B1 and B1 forwards to B2 and B2 forwards to B3, and B= 3 forwards to C, I potentially end up with UUI from A, B1, B2, B3 being sen= t to C. The suggestion has been made that this gets tagged to the History-I= nfo header field entries in some way. So who is responsible for performing = the reencoding of the History-Info header field - the SIP proxy server perf= orming the rerouteing, who is modifying it anyway because they have replace= d the URI and therefore update the History-Info to suite, or the redirectin= g UA, who could effectively screw up the entire history of the call by repl= acing it. Keith > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] > Sent: 19 September 2011 15:30 > To: DRAGE, Keith (Keith); Cuss@ietf.org > Subject: RE: Redirection requirements >=20 > > From: cuss-bounces@ietf.org [cuss-bounces@ietf.org] On Behalf Of DRAGE, > Keith (Keith) [keith.drage@alcatel-lucent.com] > > > > The current requirements specify that it is possible that were A calls = B > and B forwards to C, B can send UUI data to C. > > > > How do we expect this to work? >=20 > If the UUI is encoded in a header, one possibility is to include a > "header" in the Contact header of a 3xx response: >=20 > SIP/2.0 302 Moved Temporarily > ... > Contact: sip:foo@example.com?UUI=3DAAAAAAAAAAAAAAAAAAAAAAAAAAAA >=20 > Dale From alan.b.johnston@gmail.com Mon Sep 19 17:45:22 2011 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 E96FF21F8B82 for ; Mon, 19 Sep 2011 17:45:22 -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 Xyq0EU74jW5F for ; Mon, 19 Sep 2011 17:45:22 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA9E21F8B5E for ; Mon, 19 Sep 2011 17:45:22 -0700 (PDT) Received: by yie12 with SMTP id 12so5487149yie.31 for ; Mon, 19 Sep 2011 17:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=I6wyD1/1+ZWU9j413OROMtcVZdMe7VdB9pqyCK+ya8M=; b=o9A1fCIUiI7uyVyoM2HrEV6QZ2hXFCZX+fLRTeLaUjgKvxAswFjlWzCr8PVX9yFfA7 qZSBexd+V0q/ohyPPrqo1kNTMnYPOyilKkRw6JNTbhbrD8UlFX0hTECLa4br3j57CznJ 4CQAP92JukuBZFhvwE68qrPCKMBTaMFXyrILs= Received: by 10.101.136.4 with SMTP id o4mr99696ann.157.1316479664022; Mon, 19 Sep 2011 17:47:44 -0700 (PDT) Received: from [192.168.1.135] (99-58-71-98.lightspeed.stlsmo.sbcglobal.net. [99.58.71.98]) by mx.google.com with ESMTPS id n8sm6457518and.1.2011.09.19.17.47.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 17:47:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alan Johnston In-Reply-To: Date: Mon, 19 Sep 2011 19:47:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <34974BDE-CDC5-4248-9359-B9364A3356FA@gmail.com> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: "Cuss@ietf.org" Subject: Re: [cuss] Redirection requirements X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 00:45:23 -0000 Keith, I am working on text on the usage of History-Info in this case, but I = expect it will be something similar to this: 1. Requests that contain UUI or potentially contain UUI should include = Supported: histinfo 2. Any entity, UA or proxy that forwards or recurses on a redirection = includes the appropriate History-Info entry. Since the UUI will be = escaped into the Contact URI, the UUI is included in History-Info = without any special processing. 3. A UA receiving a request with UUI checks to see if there are any = History-Info fields. If none, the UUI has come from the originator. If = the UUI matches a UUI in a History-Info, the UUI has come from entity in = the previous History-Info field. Of course, it is possible for History-Info entries to be modified or = removed, and of course a B2BUA can do anything at all. =20 - Alan - On Sep 19, 2011, at 10:20 AM, DRAGE, Keith (Keith) wrote: > Yes that is what I was assuming, but the functionality has to be more = complicated that that. >=20 > We have an underlying requirement that the source of the UUI is = identified (in the absence of such identification it has come from A). >=20 > Thus if A forwards to B1 and B1 forwards to B2 and B2 forwards to B3, = and B3 forwards to C, I potentially end up with UUI from A, B1, B2, B3 = being sent to C. The suggestion has been made that this gets tagged to = the History-Info header field entries in some way. So who is responsible = for performing the reencoding of the History-Info header field - the SIP = proxy server performing the rerouteing, who is modifying it anyway = because they have replaced the URI and therefore update the History-Info = to suite, or the redirecting UA, who could effectively screw up the = entire history of the call by replacing it. >=20 > Keith >=20 >> -----Original Message----- >> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] >> Sent: 19 September 2011 15:30 >> To: DRAGE, Keith (Keith); Cuss@ietf.org >> Subject: RE: Redirection requirements >>=20 >>> From: cuss-bounces@ietf.org [cuss-bounces@ietf.org] On Behalf Of = DRAGE, >> Keith (Keith) [keith.drage@alcatel-lucent.com] >>>=20 >>> The current requirements specify that it is possible that were A = calls B >> and B forwards to C, B can send UUI data to C. >>>=20 >>> How do we expect this to work? >>=20 >> If the UUI is encoded in a header, one possibility is to include a >> "header" in the Contact header of a 3xx response: >>=20 >> SIP/2.0 302 Moved Temporarily >> ... >> Contact: sip:foo@example.com?UUI=3DAAAAAAAAAAAAAAAAAAAAAAAAAAAA >>=20 >> Dale > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Mon Sep 19 17:45:23 2011 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 0919D21F8B5E for ; Mon, 19 Sep 2011 17:45:23 -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 r3dPiCqF9Msm for ; Mon, 19 Sep 2011 17:45:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4016821F8B71 for ; Mon, 19 Sep 2011 17:45:22 -0700 (PDT) Received: by gxk19 with SMTP id 19so3432gxk.31 for ; Mon, 19 Sep 2011 17:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pVOC+dkWZwzLmkzThiVViVTqcBQOi0LDPP6eUEUkWLE=; b=MzQ2M6HeL+syGoFe5zxIsix9vEvCCKOOGl8mCjwADywgQ8DHEyVM31kp//Ry66nmn0 jwRKe3YwEJsyj2iyAit0dAhl7AA+iGyVjBog2Yi43o5DDoAqGpLacrFDDGNn1FAJb0Yt B+lVarXUtj2TKAYDegwA12G0VTMxuj5O8PdDA= Received: by 10.236.123.43 with SMTP id u31mr658376yhh.97.1316479663163; Mon, 19 Sep 2011 17:47:43 -0700 (PDT) Received: from [192.168.1.135] (99-58-71-98.lightspeed.stlsmo.sbcglobal.net. [99.58.71.98]) by mx.google.com with ESMTPS id n8sm6457518and.1.2011.09.19.17.47.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 17:47:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alan Johnston In-Reply-To: Date: Mon, 19 Sep 2011 19:47:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9F2B0C1F-6203-41FF-A7D2-10F7262EE027@gmail.com> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: "Cuss@ietf.org" Subject: Re: [cuss] Registration requirements for new parameter values in the User-to-User header field X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 00:45:23 -0000 Keith, Initially, it seems to be a good idea to require all extensions to be = standards track RFC. Once we get some experience with the types of = UUI people are interested in, we could decide to change this. But for = now, we should require the maximum IETF review. - Alan - On Sep 19, 2011, at 6:42 AM, DRAGE, Keith (Keith) wrote: > The syntax defines a number of new parameters for the header field. >=20 > UUI =3D "User-to-User" HCOLON uui-data *(SEMI = uui-param) > uui-data =3D token > uui-param =3D enc-param | cont-param | app-param | = generic-param > enc-param =3D "encoding=3D"("hex" | token) > cont-param =3D "content=3D" token > app-param =3D "app=3D" token >=20 > The registration requirement for defining new header field parameter = values according to RFC 3968 is a published RFC, but this says nothing = about the strength required to define a new value - which are not = registered. >=20 > The only text we have in draft-ietf-cuss-sip-uui-01 about registration = strength for new values is on the encoding parameter, which seems to = require standards track RFC. >=20 > My starting question is what strength do we really want to make on = adding new values to this header field, which ultimately comes down to = what limitations do we want to place on defining new application = packages (such as ISDN-UUI. Should it be standards track or are we going = to make it as wide open as the info-package definition. >=20 >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From gonzalo.camarillo@ericsson.com Tue Sep 20 00:41:25 2011 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 0CAEC21F8696 for ; Tue, 20 Sep 2011 00:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.452 X-Spam-Level: X-Spam-Status: No, score=-106.452 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 2pwVgEFU0Wal for ; Tue, 20 Sep 2011 00:41:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 097BA21F8797 for ; Tue, 20 Sep 2011 00:41:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-86-4e7844338af5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.AE.20773.334487E4; Tue, 20 Sep 2011 09:43:47 +0200 (CEST) Received: from [131.160.126.144] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 09:43:46 +0200 Message-ID: <4E784432.5000407@ericsson.com> Date: Tue, 20 Sep 2011 10:43:46 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: cuss@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 07:41:25 -0000 Hi, I have gotten a publication request for the following draft: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-reqs-05 I have reviewed the document and have a few comments on it. As noted in the proto writeup, RFC 2119 appears in the references but is never used in the text. There is text that appears twice at the end of the second paragraph of page 9 and in the third paragraph of the same page. The first paragraph of Section 2 makes it very clear that this mechanism only applies to call control information while non-call control information can be transported using other mechanisms. Having such a statement somewhere at the beginning of Section 1 would make the scope of the draft clearer for readers from the start. With respect to the scope, readers in general may partially relate the term call control with operations related to SIP routing. However, the draft makes it clear that the call control information transported by this mechanism does not affect SIP routing. Would it be possible to describe the scope of this information in a somewhat clearer way? As soon as we resolve these issues, I will start an IETF LC on this draft. Thanks, Gonzalo From keith.drage@alcatel-lucent.com Tue Sep 20 09:03:25 2011 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 95C0621F8C45 for ; Tue, 20 Sep 2011 09:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.967 X-Spam-Level: X-Spam-Status: No, score=-105.967 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 LGO3jbuhKGnL for ; Tue, 20 Sep 2011 09:03:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id C228721F8BB9 for ; Tue, 20 Sep 2011 09:03:24 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8KG5mGG027221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 20 Sep 2011 18:05:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 20 Sep 2011 18:05:48 +0200 From: "DRAGE, Keith (Keith)" To: "Cuss@ietf.org" Date: Tue, 20 Sep 2011 18:05:46 +0200 Thread-Topic: New Version Notification for draft-drage-cuss-sip-uui-isdn-01.txt Thread-Index: Acx3rpyILyZgY8JVTquQZpxFSk5T8gAADaIA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [cuss] FW: New Version Notification for draft-drage-cuss-sip-uui-isdn-01.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: Tue, 20 Sep 2011 16:03:25 -0000 I've just submitted a revised version of the ISDN interworking draft for UU= I. Essentially the main changes from the previous version are that I've delete= d the list of open issues and added a first stab at procedures. Obviously some of the material is guessing at potential contents of the mai= n UUI draft. Please feel free to send comments. Regards Keith > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 20 September 2011 16:59 > To: DRAGE, Keith (Keith) > Cc: DRAGE, Keith (Keith); alan.b.johnston@gmail.com > Subject: New Version Notification for draft-drage-cuss-sip-uui-isdn-01.tx= t >=20 > A new version of I-D, draft-drage-cuss-sip-uui-isdn-01.txt has been > successfully submitted by Keith Drage and posted to the IETF repository. >=20 > Filename: draft-drage-cuss-sip-uui-isdn > Revision: 01 > Title: Interworking ISDN Call Control User Information with > SIP > Creation date: 2011-09-20 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > The motivation and use cases for interworking and transporting ITU-T > DSS1 User-user information element data in SIP are described in the > "Problem Statement and Requirements for Transporting User to User > Call Control Information in SIP" document. As networks move to > SIP > it is important that applications requiring this data can continue to > function in SIP networks as well as the ability to interwork with > this ISDN service for end-to- end transparency. This document > defines a usage of the User-to-User header field to enable > interworking with this ISDN service. >=20 > This document is covers the interworking with both public ISDN and > private ISDN capabilities, so the interworking with QSIG will also be > addressed. >=20 >=20 >=20 >=20 > The IETF Secretariat From dworley@avaya.com Tue Sep 20 11:02:55 2011 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 367641F0C3B for ; Tue, 20 Sep 2011 11:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 ZSIKBmSDJarc for ; Tue, 20 Sep 2011 11:02:54 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A05C81F0C3D for ; Tue, 20 Sep 2011 11:02:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEXUeE7GmAcF/2dsb2JhbABCp2B4gVMBAQEBAgESKEQLAgEIDQghEDIlAQEEARIIGodVl00Cm06GHWAEmQiMDg X-IronPort-AV: E=Sophos;i="4.68,412,1312171200"; d="scan'208";a="208625400" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Sep 2011 14:05:20 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Sep 2011 14:04:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 20 Sep 2011 14:05:19 -0400 From: "Worley, Dale R (Dale)" To: Gonzalo Camarillo , "cuss@ietf.org" Date: Tue, 20 Sep 2011 14:05:18 -0400 Thread-Topic: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt Thread-Index: Acx3aQ48pAgqnMR6RWyMtP28ND8s+AAVhPJ1 Message-ID: References: <4E784432.5000407@ericsson.com> In-Reply-To: <4E784432.5000407@ericsson.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 Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 18:02:55 -0000 > From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >=20 > With respect to the scope, readers in general may partially relate the > term call control with operations related to SIP routing. However, the > draft makes it clear that the call control information transported by > this mechanism does not affect SIP routing. Would it be possible to > describe the scope of this information in a somewhat clearer way? I believe I am misunderstanding something. I believe that the UUI mechanism is *intended* to be able to affect SIP routing, even that we have a *requirement* that it can do so. Looking at draft-ietf-cuss-sip-uui-reqs-05: REQ-8: The mechanism will allow a UAC to require that a UAS understands the call control UUI mechanism and have a request routed based on this information. If the UAS does not understand the mechanism, the request will fail. This could be useful in ensuring that a request destined for the PSTN is routed to a gateway that supports the UUI mechanism rather than an otherwise equivalent PSTN gateway that does not support the ISDN mechanism. Note that support of the UUI mechanism does not, by itself, imply that a particular application is supported - see REQ-10. I see that the first sentence combines two things, "allow a UAC to require that a UAS understands the call control UUI mechanism" and "have a request routed based on this information". I see that there is some ambiguity; I believe the intention is that the entity envisioned doing the routing can be a proxy or B2BUA, not just a UAS (as the syntax of the sentence might suggest). Dale From internet-drafts@ietf.org Tue Sep 20 11:08:44 2011 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 0BB6021F8BE7; Tue, 20 Sep 2011 11:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 RYuRn9RFrVOh; Tue, 20 Sep 2011 11:08:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914CB21F8BDC; Tue, 20 Sep 2011 11:08:43 -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: 3.60 Message-ID: <20110920180843.9931.53195.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 11:08:43 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-02.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: Tue, 20 Sep 2011 18:08:44 -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-02.txt Pages : 14 Date : 2011-09-20 There is a need for applications using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. This 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, along with an extension mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-02.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-02.txt From vkg@bell-labs.com Tue Sep 20 15:26:03 2011 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 7D26C1F0C5A for ; Tue, 20 Sep 2011 15:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 1Fwbz8ifScXm for ; Tue, 20 Sep 2011 15:26:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CC08B1F0C56 for ; Tue, 20 Sep 2011 15:26:02 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p8KMSSqT016647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Sep 2011 17:28:28 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8KMSS9R010536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 20 Sep 2011 17:28:28 -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 p8KMSS9x016008 for ; Tue, 20 Sep 2011 17:28:28 -0500 (CDT) Message-ID: <4E791420.3040702@bell-labs.com> Date: Tue, 20 Sep 2011 17:30:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Reminder: WG Virtual Interim Meeting WEDNESDAY, Sept-21-2011 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 22:26:03 -0000 Folks: I am sure some of you may be waiting with bated breaths, the wait is now over! The CUSS virtual interim meeting will be held on Wednesday, Sept-21-2011 @ 10:00 AM US Central / 11:00 AM US Eastern / 8:00 AM US Pacific / 5:00 PM Paris, Frankfurt / 4:00 PM London The meeting materials are available at: http://www.standardstrack.com/ietf/cuss/cuss-interim-3/ The Webex coordinates are available at: http://www.ietf.org/mail-archive/web/cuss/current/msg00235.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From gonzalo.camarillo@ericsson.com Wed Sep 21 01:27:37 2011 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 E21A321F8A6C for ; Wed, 21 Sep 2011 01:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.452 X-Spam-Level: X-Spam-Status: No, score=-106.452 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 6s4SQ9wt1DA4 for ; Wed, 21 Sep 2011 01:27:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1482621F88B7 for ; Wed, 21 Sep 2011 01:27:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-93-4e79a08c9ea0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.43.02839.C80A97E4; Wed, 21 Sep 2011 10:30:04 +0200 (CEST) Received: from [131.160.36.72] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:29:46 +0200 Message-ID: <4E79A079.3040301@ericsson.com> Date: Wed, 21 Sep 2011 11:29:45 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <4E784432.5000407@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "cuss@ietf.org" Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 08:27:38 -0000 Hi Dale, in the example you refer to below, what affects SIP routing is the presence of the information, not the contents of the information. That point should also be clarified by the document, actually. In any case, I was referring to the following text, which appears in the 2nd paragraph of Section 1: > This information > is essentially opaque data to SIP - it is unrelated to SIP routing, > authentication, or any other SIP function. This application can be > considered to be operating at a higher layer on the protocol stack. > As a result, SIP should not interpret, understand, or perform any > operations on the UUI. Cheers, Gonzalo On 20/09/2011 9:05 PM, Worley, Dale R (Dale) wrote: >> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >> >> With respect to the scope, readers in general may partially relate the >> term call control with operations related to SIP routing. However, the >> draft makes it clear that the call control information transported by >> this mechanism does not affect SIP routing. Would it be possible to >> describe the scope of this information in a somewhat clearer way? > > I believe I am misunderstanding something. I believe that the UUI > mechanism is *intended* to be able to affect SIP routing, even that we > have a *requirement* that it can do so. > > Looking at draft-ietf-cuss-sip-uui-reqs-05: > > REQ-8: The mechanism will allow a UAC to require that a UAS > understands the call control UUI mechanism and have a request routed > based on this information. If the UAS does not understand the > mechanism, the request will fail. > > This could be useful in ensuring that a request destined for the > PSTN is routed to a gateway that supports the UUI mechanism rather > than an otherwise equivalent PSTN gateway that does not support > the ISDN mechanism. Note that support of the UUI mechanism does > not, by itself, imply that a particular application is supported - > see REQ-10. > > I see that the first sentence combines two things, "allow a UAC to > require that a UAS understands the call control UUI mechanism" and > "have a request routed based on this information". I see that there > is some ambiguity; I believe the intention is that the entity > envisioned doing the routing can be a proxy or B2BUA, not just a UAS > (as the syntax of the sentence might suggest). > > Dale From keith.drage@alcatel-lucent.com Wed Sep 21 03:52:28 2011 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 4CCD521F8B08 for ; Wed, 21 Sep 2011 03:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.258 X-Spam-Level: X-Spam-Status: No, score=-105.258 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 JjmGUbCdxltE for ; Wed, 21 Sep 2011 03:52:27 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 65E3921F8AF4 for ; Wed, 21 Sep 2011 03:52:26 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8LAqq8i006372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Sep 2011 12:54:50 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 21 Sep 2011 12:54:45 +0200 From: "DRAGE, Keith (Keith)" To: Gonzalo Camarillo , "Worley, Dale R (Dale)" Date: Wed, 21 Sep 2011 12:54:45 +0200 Thread-Topic: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt Thread-Index: Acx4OK6JQYcgPeeZQSiu1g+fZ3LEnwAEwuLg Message-ID: References: <4E784432.5000407@ericsson.com> <4E79A079.3040301@ericsson.com> In-Reply-To: <4E79A079.3040301@ericsson.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 Cc: "cuss@ietf.org" Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 10:52:28 -0000 I thought the background of this requirement was the existing SIP compatibi= lity mechanisms of option tags and feature tags. They certainly do not impact routing. However I do note that the latest version of draft-ietf-sip-cuss-uui has th= e statement: The presence of a Supported:uui or Require:uui header field can be used by proxies to route to an appropriate UA, meeting REQ-8. This to me is extending the use of the existing mechanism beyond what RFC 3= 261 defines, so I think we need to consider this very carefully. I believe = draft-ietf-sip-cuss-uui should not define proxy requirements, and I don't b= elieve we want to introduce routing requirements at proxies based on the op= tion tag usage. (Obviously feature tag usage applies at proxies associated with a location = server populated at registration time). My view is that it is up to the recipient to advertise distinct addresses i= f it wishes one UAS to receive requests associated with a particular option= tag. I believe some further work on the requirement 8 is appropriate. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Gonzalo Camarillo > Sent: 21 September 2011 09:30 > To: Worley, Dale R (Dale) > Cc: cuss@ietf.org > Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt >=20 > Hi Dale, >=20 > in the example you refer to below, what affects SIP routing is the > presence of the information, not the contents of the information. That > point should also be clarified by the document, actually. >=20 > In any case, I was referring to the following text, which appears in the > 2nd paragraph of Section 1: >=20 > > This information > > is essentially opaque data to SIP - it is unrelated to SIP routing, > > authentication, or any other SIP function. This application can be > > considered to be operating at a higher layer on the protocol stack. > > As a result, SIP should not interpret, understand, or perform any > > operations on the UUI. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On 20/09/2011 9:05 PM, Worley, Dale R (Dale) wrote: > >> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] > >> > >> With respect to the scope, readers in general may partially relate the > >> term call control with operations related to SIP routing. However, the > >> draft makes it clear that the call control information transported by > >> this mechanism does not affect SIP routing. Would it be possible to > >> describe the scope of this information in a somewhat clearer way? > > > > I believe I am misunderstanding something. I believe that the UUI > > mechanism is *intended* to be able to affect SIP routing, even that we > > have a *requirement* that it can do so. > > > > Looking at draft-ietf-cuss-sip-uui-reqs-05: > > > > REQ-8: The mechanism will allow a UAC to require that a UAS > > understands the call control UUI mechanism and have a request routed > > based on this information. If the UAS does not understand the > > mechanism, the request will fail. > > > > This could be useful in ensuring that a request destined for the > > PSTN is routed to a gateway that supports the UUI mechanism rathe= r > > than an otherwise equivalent PSTN gateway that does not support > > the ISDN mechanism. Note that support of the UUI mechanism does > > not, by itself, imply that a particular application is supported = - > > see REQ-10. > > > > I see that the first sentence combines two things, "allow a UAC to > > require that a UAS understands the call control UUI mechanism" and > > "have a request routed based on this information". I see that there > > is some ambiguity; I believe the intention is that the entity > > envisioned doing the routing can be a proxy or B2BUA, not just a UAS > > (as the syntax of the sentence might suggest). > > > > Dale >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From keith.drage@alcatel-lucent.com Wed Sep 21 06:42:21 2011 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 03DD021F8BAD for ; Wed, 21 Sep 2011 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.965 X-Spam-Level: X-Spam-Status: No, score=-105.965 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 CGHPbTyHWHRi for ; Wed, 21 Sep 2011 06:42:20 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3796F21F8A67 for ; Wed, 21 Sep 2011 06:42:20 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8LDiQZQ027065 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 21 Sep 2011 15:44:45 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 21 Sep 2011 15:44:35 +0200 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Wed, 21 Sep 2011 15:44:34 +0200 Thread-Topic: Is the "app" header field parameter mandatory or not Thread-Index: Acx4ZJjVQyxiDlJ8QXW3T/P1usyOVg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [cuss] Is the "app" header field parameter mandatory or not X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 13:42:21 -0000 Draft-ietf-cuss-sip-uui currently defines the "app" header field parameter = as optional, with a value assumed if not there of "uui-isdn".=20 I'm wondering whether it would be simpler just to make it mandatory, with t= he error handling procedure to discard if it is not there. We have to have a value for the "app" if we are going to interpret the vali= dity of other parameters. Thoughts? Keith From pkyzivat@alum.mit.edu Wed Sep 21 06:56:15 2011 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 495C321F8C95 for ; Wed, 21 Sep 2011 06:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, SARE_SUB_OBFU_Q1=0.227] 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 QhnXhsroZCA9 for ; Wed, 21 Sep 2011 06:56:14 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 78E8321F8C3C for ; Wed, 21 Sep 2011 06:56:14 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id bNSz1h0031swQuc5ARyjdt; Wed, 21 Sep 2011 13:58:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id bRyi1h01G0tdiYw3bRyjgs; Wed, 21 Sep 2011 13:58:43 +0000 Message-ID: <4E79ED91.9030706@alum.mit.edu> Date: Wed, 21 Sep 2011 09:58:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: cuss@ietf.org References: <4E784432.5000407@ericsson.com> <4E79A079.3040301@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 13:56:15 -0000 Regarding Keith's comments, AFAIK it has always been valid (though perhaps not sensible) for a proxy to make routing decisions based on all sorts of properties of a message, presumably including Supported and Require header values. I agree with Gonzalo that the agreement had been that routing could be based on the presence/absence of the UUI info, but was not supposed to depend on the *content* of that info. Mechanistically a proxy certainly *could* base routing decisions on the UUI content. But without further standardization of content formats, a proxy that does so will be depending on private agreements about usage - it will essentially be part of the "application" that is using the UUI. (To use UUI the UAS, or application on top of it, must have confidence that the request will go to a server that has an understanding of the UUI encoding being used. If a proxy is choosing the routing based on the UUI then it "must be in on the deal".) Thanks, Paul On 9/21/11 6:54 AM, DRAGE, Keith (Keith) wrote: > I thought the background of this requirement was the existing SIP compatibility mechanisms of option tags and feature tags. > > They certainly do not impact routing. > > However I do note that the latest version of draft-ietf-sip-cuss-uui has the statement: > > The presence of a Supported:uui or > Require:uui header field can be used by proxies to route to an > appropriate UA, meeting REQ-8. > > This to me is extending the use of the existing mechanism beyond what RFC 3261 defines, so I think we need to consider this very carefully. I believe draft-ietf-sip-cuss-uui should not define proxy requirements, and I don't believe we want to introduce routing requirements at proxies based on the option tag usage. > > (Obviously feature tag usage applies at proxies associated with a location server populated at registration time). > > My view is that it is up to the recipient to advertise distinct addresses if it wishes one UAS to receive requests associated with a particular option tag. > > I believe some further work on the requirement 8 is appropriate. > > Regards > > Keith > > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> Gonzalo Camarillo >> Sent: 21 September 2011 09:30 >> To: Worley, Dale R (Dale) >> Cc: cuss@ietf.org >> Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt >> >> Hi Dale, >> >> in the example you refer to below, what affects SIP routing is the >> presence of the information, not the contents of the information. That >> point should also be clarified by the document, actually. >> >> In any case, I was referring to the following text, which appears in the >> 2nd paragraph of Section 1: >> >>> This information >>> is essentially opaque data to SIP - it is unrelated to SIP routing, >>> authentication, or any other SIP function. This application can be >>> considered to be operating at a higher layer on the protocol stack. >>> As a result, SIP should not interpret, understand, or perform any >>> operations on the UUI. >> >> Cheers, >> >> Gonzalo >> >> >> On 20/09/2011 9:05 PM, Worley, Dale R (Dale) wrote: >>>> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >>>> >>>> With respect to the scope, readers in general may partially relate the >>>> term call control with operations related to SIP routing. However, the >>>> draft makes it clear that the call control information transported by >>>> this mechanism does not affect SIP routing. Would it be possible to >>>> describe the scope of this information in a somewhat clearer way? >>> >>> I believe I am misunderstanding something. I believe that the UUI >>> mechanism is *intended* to be able to affect SIP routing, even that we >>> have a *requirement* that it can do so. >>> >>> Looking at draft-ietf-cuss-sip-uui-reqs-05: >>> >>> REQ-8: The mechanism will allow a UAC to require that a UAS >>> understands the call control UUI mechanism and have a request routed >>> based on this information. If the UAS does not understand the >>> mechanism, the request will fail. >>> >>> This could be useful in ensuring that a request destined for the >>> PSTN is routed to a gateway that supports the UUI mechanism rather >>> than an otherwise equivalent PSTN gateway that does not support >>> the ISDN mechanism. Note that support of the UUI mechanism does >>> not, by itself, imply that a particular application is supported - >>> see REQ-10. >>> >>> I see that the first sentence combines two things, "allow a UAC to >>> require that a UAS understands the call control UUI mechanism" and >>> "have a request routed based on this information". I see that there >>> is some ambiguity; I believe the intention is that the entity >>> envisioned doing the routing can be a proxy or B2BUA, not just a UAS >>> (as the syntax of the sentence might suggest). >>> >>> Dale >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Wed Sep 21 06:59:09 2011 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 7408A21F8C3E for ; Wed, 21 Sep 2011 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 1xAjwM5KpXYk for ; Wed, 21 Sep 2011 06:59:08 -0700 (PDT) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 929B721F8B5E for ; Wed, 21 Sep 2011 06:59:08 -0700 (PDT) Received: by gwj18 with SMTP id 18so1725067gwj.27 for ; Wed, 21 Sep 2011 07:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5PVj/HDSqOZeP0RFYuDF6JXYZXe9jdTquI3MEdV6E3c=; b=e7KizvQJYN/1JO9oviRaQv3oAE4YAZN6+gdciKDFbgZejt9W/1aI6Lrv2p8wIINNat 9e+K/7flnGu0/LCasFqMpVqEcVdaMqdLM1pkPW6RqZzUv28OzPJjjyCIjukxt+DBEW5Z 8DpLsxRulUOXG0mSB0S0oWBw6nFLDGwsgngEc= MIME-Version: 1.0 Received: by 10.150.75.15 with SMTP id x15mr623067yba.265.1316613697181; Wed, 21 Sep 2011 07:01:37 -0700 (PDT) Received: by 10.150.182.21 with HTTP; Wed, 21 Sep 2011 07:01:37 -0700 (PDT) In-Reply-To: References: <4E784432.5000407@ericsson.com> <4E79A079.3040301@ericsson.com> Date: Wed, 21 Sep 2011 09:01:37 -0500 Message-ID: From: Alan Johnston To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 13:59:09 -0000 Keith, See below. - Alan - On Wed, Sep 21, 2011 at 5:54 AM, DRAGE, Keith (Keith) wrote: > I thought the background of this requirement was the existing SIP compati= bility mechanisms of option tags and feature tags. > > They certainly do not impact routing. Perhaps you have some strict definition of routing. In my view, any decision made by a proxy on a destination is a form of routing. Also, RFC 3261 places no restrictions or limitations on what it can do. Any and every part of a SIP message can be used by a proxy to determine routing. > > However I do note that the latest version of draft-ietf-sip-cuss-uui has = the statement: > > =A0 The presence of a Supported:uui or > =A0 Require:uui header field can be used by proxies to route to an > =A0 appropriate UA, meeting REQ-8. > > This to me is extending the use of the existing mechanism beyond what RFC= 3261 defines, so I think we need to consider this very carefully. I believ= e draft-ietf-sip-cuss-uui should not define proxy requirements, and I don't= believe we want to introduce routing requirements at proxies based on the = option tag usage. The intent is not to introduce any requirements on proxies. > > (Obviously feature tag usage applies at proxies associated with a locatio= n server populated at registration time). This is all these statements mean. Perhaps at issue is the meaning of rout= ing. > > My view is that it is up to the recipient to advertise distinct addresses= if it wishes one UAS to receive requests associated with a particular opti= on tag. > > I believe some further work on the requirement 8 is appropriate. What work needs to be done? > > Regards > > Keith > > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> Gonzalo Camarillo >> Sent: 21 September 2011 09:30 >> To: Worley, Dale R (Dale) >> Cc: cuss@ietf.org >> Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt >> >> Hi Dale, >> >> in the example you refer to below, what affects SIP routing is the >> presence of the information, not the contents of the information. That >> point should also be clarified by the document, actually. >> >> In any case, I was referring to the following text, which appears in the >> 2nd paragraph of Section 1: >> >> > =A0 =A0This information >> > =A0 =A0is essentially opaque data to SIP - it is unrelated to SIP rout= ing, >> > =A0 =A0authentication, or any other SIP function. =A0This application = can be >> > =A0 =A0considered to be operating at a higher layer on the protocol st= ack. >> > =A0 =A0As a result, SIP should not interpret, understand, or perform a= ny >> > =A0 =A0operations on the UUI. >> >> Cheers, >> >> Gonzalo >> >> >> On 20/09/2011 9:05 PM, Worley, Dale R (Dale) wrote: >> >> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >> >> >> >> With respect to the scope, readers in general may partially relate th= e >> >> term call control with operations related to SIP routing. However, th= e >> >> draft makes it clear that the call control information transported by >> >> this mechanism does not affect SIP routing. Would it be possible to >> >> describe the scope of this information in a somewhat clearer way? >> > >> > I believe I am misunderstanding something. =A0I believe that the UUI >> > mechanism is *intended* to be able to affect SIP routing, even that we >> > have a *requirement* that it can do so. >> > >> > Looking at draft-ietf-cuss-sip-uui-reqs-05: >> > >> > =A0 =A0REQ-8: The mechanism will allow a UAC to require that a UAS >> > =A0 =A0understands the call control UUI mechanism and have a request r= outed >> > =A0 =A0based on this information. =A0If the UAS does not understand th= e >> > =A0 =A0mechanism, the request will fail. >> > >> > =A0 =A0 =A0 This could be useful in ensuring that a request destined f= or the >> > =A0 =A0 =A0 PSTN is routed to a gateway that supports the UUI mechanis= m rather >> > =A0 =A0 =A0 than an otherwise equivalent PSTN gateway that does not su= pport >> > =A0 =A0 =A0 the ISDN mechanism. =A0Note that support of the UUI mechan= ism does >> > =A0 =A0 =A0 not, by itself, imply that a particular application is sup= ported - >> > =A0 =A0 =A0 see REQ-10. >> > >> > I see that the first sentence combines two things, "allow a UAC to >> > require that a UAS understands the call control UUI mechanism" and >> > "have a request routed based on this information". =A0I see that there >> > is some ambiguity; I believe the intention is that the entity >> > envisioned doing the routing can be a proxy or B2BUA, not just a UAS >> > (as the syntax of the sentence might suggest). >> > >> > Dale >> >> _______________________________________________ >> 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 dworley@avaya.com Wed Sep 21 11:30:39 2011 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 84BF111E80AD for ; Wed, 21 Sep 2011 11:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.345 X-Spam-Level: X-Spam-Status: No, score=-103.345 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 6r2ziAslwm6M for ; Wed, 21 Sep 2011 11:30:39 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id EA3D511E80AB for ; Wed, 21 Sep 2011 11:30:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABYtek7GmAcF/2dsb2JhbABCDqdbeIFTAQEBAQIBEigtFwsCAQgNAQchEDIlAQEEARIIGodVmTQCmzyGHWAEmQuLOlM X-IronPort-AV: E=Sophos;i="4.68,418,1312171200"; d="scan'208";a="304960770" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Sep 2011 14:33:02 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Sep 2011 14:32:23 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 21 Sep 2011 14:33:02 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "cuss@ietf.org" Date: Wed, 21 Sep 2011 14:33:02 -0400 Thread-Topic: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt Thread-Index: Acx4ZpWX60bEucUrRpGNasV8xTnkUQAJWejF Message-ID: References: <4E784432.5000407@ericsson.com> <4E79A079.3040301@ericsson.com> , <4E79ED91.9030706@alum.mit.edu> In-Reply-To: <4E79ED91.9030706@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 18:30:39 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > I agree with Gonzalo that the agreement had been that routing could be > based on the presence/absence of the UUI info, but was not supposed to > depend on the *content* of that info. I believe that the *intention* is the following requirements and non-requirements for the mechanism that we define: - A SIP element should be able to easily discern whether or not a SIP request carries UUI, because we want to support the ability for proxies to make routing decisions based on the presence/absence of UUI. - This discernment is *not* to be driven by the presence/absence of option-tags in Supported, Requires, etc.; Supported/Requires is independent of the presence/absence of UUI. - It is *not* a requirement for a SIP proxy to easily parse the UUI information itself in order to base a routing decision on the *contents* of the UUI. (Although it would be difficult to define a mechanism which would make it difficult for a proxy to parse the UUI.) From keith.drage@alcatel-lucent.com Thu Sep 22 04:19:46 2011 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 C30B121F8C0B for ; Thu, 22 Sep 2011 04:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 dsE3X-JCFaXY for ; Thu, 22 Sep 2011 04:19:46 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3E21F8C06 for ; Thu, 22 Sep 2011 04:19:45 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8MBMA5o009478 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Sep 2011 13:22:11 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 22 Sep 2011 13:22:10 +0200 From: "DRAGE, Keith (Keith)" To: "Worley, Dale R (Dale)" , Paul Kyzivat , "cuss@ietf.org" Date: Thu, 22 Sep 2011 13:22:09 +0200 Thread-Topic: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt Thread-Index: Acx4ZpWX60bEucUrRpGNasV8xTnkUQAJWejFACKejCA= Message-ID: References: <4E784432.5000407@ericsson.com> <4E79A079.3040301@ericsson.com> , <4E79ED91.9030706@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 11:19:46 -0000 As I indicated on the call yesterday, I want to make sure the requirement 8= as finally drafted, does not need any UUI specific requirements on proxy e= ntities. While it is not precluded that proxies look at option tags or at presence o= r absence of header fields, I don't believe we should be working on a UUI s= olution that depends on them. If people really think there is a need for sp= ecific routeing, then we should be using either the routeing tools we alrea= dy have, or write something generic. (I do realize that usage of feature tags provides a generic mechanism to in= fluence routeing at an inbound proxy associated with a registrar). Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Worley, Dale R (Dale) > Sent: 21 September 2011 19:33 > To: Paul Kyzivat; cuss@ietf.org > Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt >=20 > > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > > > > I agree with Gonzalo that the agreement had been that routing could be > > based on the presence/absence of the UUI info, but was not supposed to > > depend on the *content* of that info. >=20 > I believe that the *intention* is the following requirements and > non-requirements for the mechanism that we define: >=20 > - A SIP element should be able to easily discern whether or not a SIP > request carries UUI, because we want to support the ability for > proxies to make routing decisions based on the presence/absence of > UUI. >=20 > - This discernment is *not* to be driven by the presence/absence of > option-tags in Supported, Requires, etc.; Supported/Requires is > independent of the presence/absence of UUI. >=20 > - It is *not* a requirement for a SIP proxy to easily parse the UUI > information itself in order to base a routing decision on the > *contents* of the UUI. (Although it would be difficult to define a > mechanism which would make it difficult for a proxy to parse the > UUI.) >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Thu Sep 22 10:50:22 2011 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 2B3E01F0C5D for ; Thu, 22 Sep 2011 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 JdKvEVxrC8OM for ; Thu, 22 Sep 2011 10:50:21 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2B1F0C60 for ; Thu, 22 Sep 2011 10:50:21 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id bn2Q1h0031wpRvQ5Ctsu6z; Thu, 22 Sep 2011 17:52:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id btst1h0090tdiYw3etst14; Thu, 22 Sep 2011 17:52:53 +0000 Message-ID: <4E7B75F2.6000605@alum.mit.edu> Date: Thu, 22 Sep 2011 13:52:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "cuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [cuss] backup minutes for cuss interim meeting 21-sep-2011 @ 11:00 EDT X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 17:50:22 -0000 Notes from the cuss interim meeting 21-sep-2011 @ 11:00-13:00 EDT Vijay said he was enabling recoding of the meeting. Keith said we need to *ask* if ok to record. Alan discussed the requirements doc. Particularly Keith had issue with Rqmt-8. Concern is that it be clear that this doesn't require updates to proxies. He doesn't have a preference on how this is done. Goal is to impose no requirements on what proxies do or don't do with this info. Gonzalo said that after this is fixed we can continue rather than having another WGLC. We have missed the proposed Sept 15 date for WGLC of the mechanism document. It will be delayed a bit. For isdn draft, plan to hum for adoption of Keith's draft. Intend to ask for 1 hr slot in taiwan, then cancel if not needed. Discussion of draft-ietf-cuss-sip-uui-02, by Alan J: Keith asked about making application be mandatory. Alan stated that existing deployments don't do this. There was no decision Paul asked to allow quoted string as well as token for the uui value. This was agreed. Keith raised further concern about determination of source of UUI. He wants it to be more general - to state that UUI source is same as message source, and message source can be determined in many ways, including P-Asserted-Identity. Keith raised issues with H-I and isdn. Do we allow redirection in the isdn case, and what happens. What happens if we do redirection and it overwrites the uui info. There was a suggestion that when we get to wglc, formally ask sipcore to review the doc in context of 4244bis usage. Paul brought up question of what "application" means. Keith agreed he didn't know either. So we need to clear that up. Further discussion will be done on list for this. Keith didn't think feature-tag is needed for isdn. I suggested that the name format including uui- probably wasn't good either - that there is probably more than just UUI involved in the feature. Discussion of draft-drage-cuss-sip-uui-isdn-01, by Keith D: Lots of clarifying discussion. Suggestions for word smithing. (Current text suggests that use in initial INVITE allows general usage within dialog, not just in response to the invite or in BYE. But other text contradicts this.) Paul mentioned that section 6 is confusing by its use of 128 as the size limit, because the limit with protocol discriminator is 129. Keith will clarify. There was a request for any objections to adopting this doc as wg doc. There were none. Will take to list for formal approval. Wrapup: Keith would like another conference call before Taipei. Alan agreed. Suggestion to have it around week of Oct 24. Will have a doodle poll on this. Thanks, Paul P.S. I will miss the Friday conf call due to a conflicting engagement. I will also have limited internet connectivity for the next week, so don't be surprised to not see me commenting. From pkyzivat@alum.mit.edu Thu Sep 22 11:38:37 2011 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 0FDC51F0C3C for ; Thu, 22 Sep 2011 11:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 Y+5jWZazs5Eq for ; Thu, 22 Sep 2011 11:38:36 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBFA1F0C5D for ; Thu, 22 Sep 2011 11:38:36 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id boZe1h0071uE5Es5Duh803; Thu, 22 Sep 2011 18:41:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id buh71h01e0tdiYw3cuh88X; Thu, 22 Sep 2011 18:41:08 +0000 Message-ID: <4E7B8141.5000006@alum.mit.edu> Date: Thu, 22 Sep 2011 14:41:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "cuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [cuss] Definition of "application" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:38:37 -0000 In the meeting the other day I expressed confusion over the use of "application" in cuss. IMO its far from clear what is intended, and it may be ambiguous. Here are some examples of usage of this term in the mechanism doc: Individual applications using the UUI mechanism will utilize media feature tags to indicate that a UA supports a particular application user of UUI. [Section 1] All applications using this SIP UUI mechanism must publish a standards track RFC which describes the usage. The SIP UUI mechanism is applicable in the following situations: 1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily SIP aware. ... [Section 5] The "app" parameter identifies the application which generates and consumes the UUI information. [Section 4] My confusion is whether "application" means: 1) A particular conceptual function (or maybe "business process") made of components that communicate using sip, that could be implemented and instantiated multiple times. (E.g. "call center".) 2) A particular implementation of (1) as specific server code, but which still can be instantiated multiple times. (E.g. "Example Corp distributed call center product") 3) A particular deployment of (1) or (2). (E.g. the ABC Corp. deployment of the Example Corp distributed call center product, including configuration of the data gathered by an IVR and passed via UUI.) The reason I ask is because its my impression that common practice today is for the format of data passed via UUI to be customized per deployment. Thus "content" would need to be defined per deployment. And then, since applications define the allowed content, the applications also need to be defined per-deployment. (What I describe as (3) above.) BUT, IMO its unreasonable to expect that individual deployments would do such registration. But IMO it would be good to use app= and content= to identify the significance of the UUI data. Doing so would potentially prevent mistakes due to misconfiguration, and would help in analysis of network traffic. It also could potentially be used for message routing. It *may* be possible that standards could be defined for "content", consistent with application definitions (1) and/or (2) above. But that remains to be demonstrated - it may not turn out to be true in practice. If applications of UUI fall into definition (3) above, then I think the naming for applications and content needs to be relaxed so that no registration is required. That probably means identifiers that are naturally unique. Thanks, Paul From md3135@att.com Thu Sep 22 12:17:51 2011 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 6C77811E8096 for ; Thu, 22 Sep 2011 12:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 MyZSHWem40kf for ; Thu, 22 Sep 2011 12:17:50 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF511E8095 for ; Thu, 22 Sep 2011 12:17:50 -0700 (PDT) X-Env-Sender: md3135@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1316719221!39698285!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25334 invoked from network); 22 Sep 2011 19:20:21 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 19:20:21 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8MJKjXO026942; Thu, 22 Sep 2011 15:20:48 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8MJKf5l026701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Sep 2011 15:20:41 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.142]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0289.001; Thu, 22 Sep 2011 15:20:14 -0400 From: "DOLLY, MARTIN C" To: "'pkyzivat@alum.mit.edu'" , "'cuss@ietf.org'" Thread-Topic: [cuss] Definition of "application" Thread-Index: AQHMeVc2gydHdWdXpU+gyjs+Bwf+dZVZxqCt Date: Thu, 22 Sep 2011 19:20:13 +0000 Message-ID: In-Reply-To: <4E7B8141.5000006@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.151.223.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] Definition of "application" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 19:17:51 -0000 Paul Application is the "user" of the UUI information. This a capability, not a "service", so I not sure what you are digging for = here Martin Martin C. Dolly Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink = Possible. +1.609.903.3360 ----- Original Message ----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Thursday, September 22, 2011 02:41 PM=0A= To: cuss@ietf.org Subject: [cuss] Definition of "application" In the meeting the other day I expressed confusion over the use of=20 "application" in cuss. IMO its far from clear what is intended, and it=20 may be ambiguous. Here are some examples of usage of this term in the=20 mechanism doc: Individual applications using the UUI mechanism will utilize media feature tags to indicate that a UA supports a particular application user of UUI. [Section 1] All applications using this SIP UUI mechanism must publish a standards track RFC which describes the usage. The SIP UUI mechanism is applicable in the following situations: 1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily SIP aware. ... [Section 5] The "app" parameter identifies the application which generates and consumes the UUI information. [Section 4] My confusion is whether "application" means: 1) A particular conceptual function (or maybe "business process") made of components that communicate using sip, that could be implemented and instantiated multiple times. (E.g. "call center".) 2) A particular implementation of (1) as specific server code, but which still can be instantiated multiple times. (E.g. "Example Corp distributed call center product") 3) A particular deployment of (1) or (2). (E.g. the ABC Corp. deployment of the Example Corp distributed call center product, including configuration of the data gathered by an IVR and passed via UUI.) The reason I ask is because its my impression that common practice today=20 is for the format of data passed via UUI to be customized per=20 deployment. Thus "content" would need to be defined per deployment. And=20 then, since applications define the allowed content, the applications=20 also need to be defined per-deployment. (What I describe as (3) above.)=20 BUT, IMO its unreasonable to expect that individual deployments would do=20 such registration. But IMO it would be good to use app=3D and content=3D to identify the=20 significance of the UUI data. Doing so would potentially prevent=20 mistakes due to misconfiguration, and would help in analysis of network=20 traffic. It also could potentially be used for message routing. It *may* be possible that standards could be defined for "content",=20 consistent with application definitions (1) and/or (2) above. But that=20 remains to be demonstrated - it may not turn out to be true in practice. If applications of UUI fall into definition (3) above, then I think the=20 naming for applications and content needs to be relaxed so that no=20 registration is required. That probably means identifiers that are=20 naturally unique. Thanks, Paul _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@alum.mit.edu Thu Sep 22 14:14:17 2011 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 BB0181F0C8D for ; Thu, 22 Sep 2011 14:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Do-0-h3YU4NS for ; Thu, 22 Sep 2011 14:14:17 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id D153611E8097 for ; Thu, 22 Sep 2011 14:14:16 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id br3P1h0031ZXKqc51xGpgm; Thu, 22 Sep 2011 21:16:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id bxGo1h01U0tdiYw3hxGpZu; Thu, 22 Sep 2011 21:16:49 +0000 Message-ID: <4E7BA5BE.4010108@alum.mit.edu> Date: Thu, 22 Sep 2011 17:16:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "DOLLY, MARTIN C" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'cuss@ietf.org'" Subject: Re: [cuss] Definition of "application" X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:14:17 -0000 On 9/22/11 3:20 PM, DOLLY, MARTIN C wrote: > Paul > > Application is the "user" of the UUI information. > This a capability, not a "service", so I not sure what you are digging for here My point is that if each deployment is a different application, using different content formats, then an IANA registration model for application and content doesn't really work, and we should be looking for something else. Alternately, we need to consider if there is a way applications and content of a sort suitable for iana registration provide a useful model for how to use this mechanism. OR, we just forget about application and content definitions. In which case we don't need to mention applications at all. Thanks, Paul > Martin > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible. > +1.609.903.3360 > > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, September 22, 2011 02:41 PM > To: cuss@ietf.org > Subject: [cuss] Definition of "application" > > In the meeting the other day I expressed confusion over the use of > "application" in cuss. IMO its far from clear what is intended, and it > may be ambiguous. Here are some examples of usage of this term in the > mechanism doc: > > Individual applications using the UUI mechanism will > utilize media feature tags to indicate that a UA supports a particular > application user of UUI. [Section 1] > > All applications using this SIP UUI mechanism must publish a > standards track RFC which describes the usage. The SIP UUI mechanism > is applicable in the following situations: > > 1. The information is generated and consumed by an application > during session setup using SIP, but the application is not > necessarily SIP aware. > ... > [Section 5] > > The "app" parameter identifies the application which generates and > consumes the UUI information. [Section 4] > > My confusion is whether "application" means: > > 1) A particular conceptual function (or maybe "business process") > made of components that communicate using sip, that could be > implemented and instantiated multiple times. (E.g. "call center".) > > 2) A particular implementation of (1) as specific server code, > but which still can be instantiated multiple times. (E.g. > "Example Corp distributed call center product") > > 3) A particular deployment of (1) or (2). (E.g. the ABC Corp. > deployment of the Example Corp distributed call center product, > including configuration of the data gathered by an IVR and > passed via UUI.) > > The reason I ask is because its my impression that common practice today > is for the format of data passed via UUI to be customized per > deployment. Thus "content" would need to be defined per deployment. And > then, since applications define the allowed content, the applications > also need to be defined per-deployment. (What I describe as (3) above.) > BUT, IMO its unreasonable to expect that individual deployments would do > such registration. > > But IMO it would be good to use app= and content= to identify the > significance of the UUI data. Doing so would potentially prevent > mistakes due to misconfiguration, and would help in analysis of network > traffic. It also could potentially be used for message routing. > > It *may* be possible that standards could be defined for "content", > consistent with application definitions (1) and/or (2) above. But that > remains to be demonstrated - it may not turn out to be true in practice. > > If applications of UUI fall into definition (3) above, then I think the > naming for applications and content needs to be relaxed so that no > registration is required. That probably means identifiers that are > naturally unique. > > Thanks, > Paul > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Fri Sep 23 03:46:52 2011 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 DBC2521F8515 for ; Fri, 23 Sep 2011 03:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.971 X-Spam-Level: X-Spam-Status: No, score=-105.971 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 0jf82z2BZ6SN for ; Fri, 23 Sep 2011 03:46:52 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id E083221F8531 for ; Fri, 23 Sep 2011 03:46:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8NAnKHg010461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Sep 2011 12:49:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 23 Sep 2011 12:49:20 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "cuss@ietf.org" Date: Fri, 23 Sep 2011 12:49:18 +0200 Thread-Topic: [cuss] Definition of "application" Thread-Index: Acx5VzcztUQYGTFeRWaC5Qoc7qMp7AAhrq1w Message-ID: References: <4E7B8141.5000006@alum.mit.edu> In-Reply-To: <4E7B8141.5000006@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [cuss] Definition of "application" 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, 23 Sep 2011 10:46:53 -0000 I suspect we need two separate and distinct terms. 1) To represent the entity above the SIP later which is the consumer and ge= nerator of the UUI information, and which in many cases will not be a SIP u= ser. This entity has responsibility for the format and content of the paylo= ad (including the ISDN protocol discriminator). 2) To represent the different usage documents, where a different map= s to each different value of the "app" header field parameter. The value of= the "app" header field parameter defines what values are legitimate in the= "content" header field parameter and the "encoding" header field parameter= . Suggestions welcome. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 22 September 2011 19:41 > To: cuss@ietf.org > Subject: [cuss] Definition of "application" >=20 > In the meeting the other day I expressed confusion over the use of > "application" in cuss. IMO its far from clear what is intended, and it > may be ambiguous. Here are some examples of usage of this term in the > mechanism doc: >=20 > Individual applications using the UUI mechanism will > utilize media feature tags to indicate that a UA supports a particular > application user of UUI. [Section 1] >=20 > All applications using this SIP UUI mechanism must publish a > standards track RFC which describes the usage. The SIP UUI mechanism > is applicable in the following situations: >=20 > 1. The information is generated and consumed by an application > during session setup using SIP, but the application is not > necessarily SIP aware. > ... > [Section 5] >=20 > The "app" parameter identifies the application which generates and > consumes the UUI information. [Section 4] >=20 > My confusion is whether "application" means: >=20 > 1) A particular conceptual function (or maybe "business process") > made of components that communicate using sip, that could be > implemented and instantiated multiple times. (E.g. "call center".) >=20 > 2) A particular implementation of (1) as specific server code, > but which still can be instantiated multiple times. (E.g. > "Example Corp distributed call center product") >=20 > 3) A particular deployment of (1) or (2). (E.g. the ABC Corp. > deployment of the Example Corp distributed call center product, > including configuration of the data gathered by an IVR and > passed via UUI.) >=20 > The reason I ask is because its my impression that common practice today > is for the format of data passed via UUI to be customized per > deployment. Thus "content" would need to be defined per deployment. And > then, since applications define the allowed content, the applications > also need to be defined per-deployment. (What I describe as (3) above.) > BUT, IMO its unreasonable to expect that individual deployments would do > such registration. >=20 > But IMO it would be good to use app=3D and content=3D to identify the > significance of the UUI data. Doing so would potentially prevent > mistakes due to misconfiguration, and would help in analysis of network > traffic. It also could potentially be used for message routing. >=20 > It *may* be possible that standards could be defined for "content", > consistent with application definitions (1) and/or (2) above. But that > remains to be demonstrated - it may not turn out to be true in practice. >=20 > If applications of UUI fall into definition (3) above, then I think the > naming for applications and content needs to be relaxed so that no > registration is required. That probably means identifiers that are > naturally unique. >=20 > Thanks, > Paul > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Fri Sep 23 15:26:12 2011 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 6670721F8C51 for ; Fri, 23 Sep 2011 15:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.606 X-Spam-Level: X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 mDj3kV86BBQM for ; Fri, 23 Sep 2011 15:26:11 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2269521F8C48 for ; Fri, 23 Sep 2011 15:26:11 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8NMSdEm011738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 23 Sep 2011 17:28:40 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8NMSdFI017311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Sep 2011 17:28:39 -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 p8NMSdqr027330 for ; Fri, 23 Sep 2011 17:28:39 -0500 (CDT) Message-ID: <4E7D08AE.8060206@bell-labs.com> Date: Fri, 23 Sep 2011 17:31:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Draft minutes for Sep-21-2011 Virtual Interim meeting 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, 23 Sep 2011 22:26:12 -0000 Folks: The draft minutes for the Wed, Sep-21-2011 virtual interim meeting are below. As it turns out, the recording of the virtual interim cannot be located, so the draft minutes are condensed from the notes taken by our volunteers (thanks, Enrico and Paul). There is a missing decision that can benefit from someone recalling what the discussion culminated in. The place where this missing decision occurs can be found by searching for the string "" If someone recalls, please let me know. Please go through the minutes and check for accuracy in my trans- cription of the raw notes from our volunteers. Any errors so introduce remain mine. Please send any corrections by Friday, October 7, 2011 or earlier. Thanks. --- Begin draft minutes CUSS 3rd Virtual Meeting Wednesday, Sep. 21, 2011. 10:00 AM US Central - 11:30 AM US Central Attendees: 9 identified + 3 Call-in users Minutes taken by Enrico Marocco and Paul Kyzivat Agenda was bashed and accepted. Administrivia, Chairs ===================== Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-3/Agenda.pdf The requirement draft (draft-ietf-cuss-sip-uui-reqs-05) has been through two WGLCs and is currently in the PubReq state. The AD (Gonzalo) has reviewed it and has offered some comments on the list for clarification on a couple of items (see http://www.ietf.org/mail-archive/web/cuss/current/msg00246.html). Keith wants to make sure that the REQ-8 does not place any burdens on existing proxies. Alan is confident that he can address these comments shortly and get a new revision out. The new revision will be used for a IETF LC. The mechanism draft (draft-ietf-cuss-sip-uui-02) needs more reviews. The date for moving this ahead to WGLC as agreed during Quebec City was Sept-15. The draft needs more volunteers to review it. The ISDN UUI Service application usage specification deliverable currently does not have a draft associated with it. Keit Drage's independent submission (draft-drage-cuss-sip-uui-isdn-01) is a candidate. Solicitations were sent out on the WG list to get more candidate drafts, none emerged. During the meeting it was decided to adopt draft-drage-cuss-sip-uui-isdn as the deliverable. It was expressed that the WG should ask for an 1-hour slot for Taiwan and cancel if not needed (the chairs have put a request into the system). The attendess expressed some interest in meeting in Taiwan to iron out any remaining issues with mechanism draft. It was also expressed that another virtual meeting before Taiwan be organized (probably around end of October). Mechanism draft, Alan Johnston ============================== Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-3/Mechanism.pdf Draft: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-02 Alan went through the changes from previous version. There was some discussion on whether the "app" parameter in the UUI production rule (see slide 3) can be made mandatory. Alan noted that while this parameter is needed for the ISDN use case, its utility on other usages is not clear. No decision reached and further talks to proceed on the mailing list. Paul asked on expanding the ABNF to include quoted-string as well as a token for the uui-data production rule (see slide). This was agreed to. Keith asked whether the order of the parameters can be reversed when expressing them as ABNF; Alan agreed to do so. Keith and Alan agreed to exclude rfc3325 (Private Extensions to SIP for Asserted Identity within Trusted Networks) when determining sources of UUI headers but include P-A-I as a possible source. There was a longer discussion on H-I and ISDN use case. There were two points to consider: (1) Decide whether ISDN package would allow redirects, and (2) if a redirect were to occur and overrides the UUI, how would this be detected? Should it be prevented? Or is it acceptable? There was a reasonable amount of discussion that culminated in It was also decided that during WGLC, sipcore would be invited to review the document in the context of 4244bis usage. Paul noted that the term "application" is ambiguous. There is a thread underway on the list to reach consensus on how this term is used in the mechanism draft (see http://www.ietf.org/mail-archive/web/cuss/current/msg00259.html). ISDN Usage Draft, Keith Drage ============================= Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-3/ISDN-Drage.pdf Draft: http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 Keith Drage presented the draft. Most comments on the draft were about clarifying existing text: - Current text suggests that use in initial INVITE allows general usage within dialog, not just in response to the invite or in BYE. But other text contradicts this. - Section 6 is confusing by its use of 128 as the size limit, because sthe limit with protocol discriminator is 129. The chairs noted that the last charter item --- ISDN UUI Service application usage --- does not have a draft assigned as a deliverable. A call for other candidate drafts went out on Sept-08-2011 (see http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html) but no other drafts have been put forth. Given that there are no other candidate drafts, the chairs asked attendees to express any reservations if this draft (i.e., draft-drage-cuss-sip-uui-isdn-01) was to be adopted as a deliverable to ISDN UUI Service application usage specification charter item. There were no reservations expressed by the attendees. Therefore, after ratifying this decision on the mailing list, Keith will be asked to submit a WG -00 version. The meeting adjourned. ================================================================================ Note takers: Enrico Marocco and Paul Kyzivat Raw notes: - Notes from Paul are archived at http://www.ietf.org/mail-archive/web/cuss/current/msg00258.html - Notes from Enrico appear below. CUSS WG, September 21, 2011 Virtual interim meeting Chairs: Vijay Gurbani and Enrico Marocco Area Director: Gonzalo Camarillo About 10 participants. The meeting will be recorded. Agenda ------ Vijay presents the agenda and status of the WG. Requirements are almost done. Alan Johnston: Gonzalo posted a few comments to the list, no major issues. Minor issues with REQ-8, in particular make clear that the intermediaries should not be expected to understand UUI. Keith Drage: make clear that only endpoints are supposed to understand UUI. Alan: early next week at the latest will provide text. Gonzalo: the draft should be clear whether the mechanism affects routing. Don't care what way we go, as long as its clear. Paul Kyzivat: we should not preclude proxies do whatever they like, as long as we don't make that required. Keith: agrees. Gonzalo: just clarify that this does not affect SIP routing. Vijay: Gonzalo, do we need another WGLC after that change? Gonzalo: no, once it's done, will move it on. Mechanism draft needs more review, please volunteer. The ISDN UUI usage item is the only charter item with no WG draft, and only one candidate individual draft (Keith's); plan is to adopt it. Any one has opinions about meeting in Taiwan? Martin Dolly: won't be in TW because of the conflict with 3GPP. Alan: would be good to meet. Mechanism draft --------------- Alan presents the mechanism draft. We need some review so that we can go to WGLC. Keith: we can make the app parameter mandatory. Alan: it is certainly needed for the ISDN use case, but am not sure other usages will require it. Paul: don't have an opinion, but there can be issues with other schemas. (Further discussion among Paul, Alan, Keith and James.) Keith: can the order of the parameters be reversed in ABNF, seems more logic? Alan: yes. Keith: am fine with the rules for inserting UUI in requests and responses, except that they exclude 3325. Alan: we can add P-Asserted-ID as a source of UUI. Paul: the intent is SHOULD strenght? Alan: yes. Keith: in the ISDN UUI added in a forward is indistinguishable from one inserted at the origin. History-Info could cause interop issues. Alan: not sure we should forbid it because the ISDN does not support it. Paul: do you want to forbid H-I for UUI? (Note taker got disconnected for a couple of minutes.) Will discuss on the list. The draft references 4244bis even if it does not use any of the changes. Will keep the fresh ref unless it holds it back. Keith: at some point we may need a review from SIPCORE. Paul: the term "applications" is ambiguous in guidelines. Is "call center product" an application? Or is it a deployment using UUI? Alan: we don't fully know this until we receive proposals for applications. The only one we have is ISDN. Paul: it may be useful to explain what we mean by that. Alan: would prefer not to narrow the scope of applications too much. I don't know how we can do that now. We can add a minimum set of guidelines. We'll make sure that we are consistent about the use of "applications". Keith: not really convinced the ISDN usage needs a media tag. Paul: either you need a feature tag or you don't. ISDN usage draft ---------------- Keith presents the ISDN usage draft. Paul: confused about some of the wording, e.g. "you must use it in invite only" and then "in any other in-dialog message". Keith: it could be in re-INVITE, or an empty UUI. Paul: in section 7 you say initial INVITE. Alan: seems like the ISDN is using the empty UUI for discovering UUI support. It still seems the right thing to do, from the SIP perspective you are still conveying end-to-end info. Paul: section 6 is a little confused. Alan: this draft will create the first entries in the app and content parameters IANA registries. Vijay: if anyone is opposed to adopting this draft as WG item, please speak now. No one opposed. The group will have another meeting before Taipei, tentatively during the week starting on Oct. 24, and will meet live at IETF 82. --- End draft minutes From vkg@bell-labs.com Tue Sep 27 06:58:53 2011 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 23A9621F8B76 for ; Tue, 27 Sep 2011 06:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.625 X-Spam-Level: X-Spam-Status: No, score=-106.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 s0ALjsWbjNly for ; Tue, 27 Sep 2011 06:58:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 399C221F8B75 for ; Tue, 27 Sep 2011 06:58:51 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p8RE1bCZ014007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Sep 2011 09:01:37 -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 p8RE1aAU011116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Sep 2011 09:01:37 -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 p8RE1auo017112 for ; Tue, 27 Sep 2011 09:01:36 -0500 (CDT) Message-ID: <4E81D7DA.3030302@bell-labs.com> Date: Tue, 27 Sep 2011 09:04:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [cuss] Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:58:53 -0000 Folks: As discussed during last week's virtual interim meeting [1], the WG needs to choose a draft that satisfies the last orphan milestone (ISDN UUI Service application usage specification). Keith Drage has an individual draft [2] that could be used towards the milestone. A call for additional candidate drafts went out on Sep-08-2011 [3], but did not result in any new entries. Therefore, during the interim meeting of Sep-21-2011, it was decided to adopt draft-drage-cuss-sip-uui-isdn as the working group draft towards the ISDN UUI Service application usage milestone. As such, Enrico and I seek to ratify this decision on the mailing list and request Keith to submit a WG -00 version of his draft no later than Tuesday, Aug-4-2011. If there are any concerns, please let the WG know. [1] Draft minutes at http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From R.Jesske@telekom.de Tue Sep 27 09:31:26 2011 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 86E2F21F8D6F for ; Tue, 27 Sep 2011 09:31:26 -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 JsVBmqga79c9 for ; Tue, 27 Sep 2011 09:31:25 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 822D821F8ECF for ; Tue, 27 Sep 2011 09:31:25 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 27 Sep 2011 16:36:32 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.163]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 27 Sep 2011 16:36:31 +0200 From: To: , Date: Tue, 27 Sep 2011 16:36:30 +0200 Thread-Topic: [cuss] Adopting draft-drage-cuss-sip-uui-isdn Thread-Index: Acx9Hf70U8e5CvnVQCaXpSUGu3vSNgABHK8g Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0968C5CD3F@HE111648.emea1.cds.t-internal.com> References: <4E81D7DA.3030302@bell-labs.com> In-Reply-To: <4E81D7DA.3030302@bell-labs.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 16:31:26 -0000 Hi, I have no concerns, so Keith can provide a WG version. Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > Auftrag von Vijay K. Gurbani > Gesendet: Dienstag, 27. September 2011 16:04 > An: cuss@ietf.org > Betreff: [cuss] Adopting draft-drage-cuss-sip-uui-isdn > > Folks: As discussed during last week's virtual interim > meeting [1], the WG needs to choose a draft that satisfies > the last orphan milestone (ISDN UUI Service application usage > specification). > > Keith Drage has an individual draft [2] that could be used towards > the milestone. A call for additional candidate drafts went out on > Sep-08-2011 [3], but did not result in any new entries. > > Therefore, during the interim meeting of Sep-21-2011, it was > decided to adopt draft-drage-cuss-sip-uui-isdn as the working > group draft towards the ISDN UUI Service application usage > milestone. > > As such, Enrico and I seek to ratify this decision on the mailing > list and request Keith to submit a WG -00 version of his draft > no later than Tuesday, Aug-4-2011. > > If there are any concerns, please let the WG know. > > [1] Draft minutes at > http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html > [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 > [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From md3135@att.com Tue Sep 27 09:33:14 2011 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 DC59221F8EDC for ; Tue, 27 Sep 2011 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 z5F9mzBfsUK1 for ; Tue, 27 Sep 2011 09:33:14 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 174BE21F8ECF for ; Tue, 27 Sep 2011 09:33:14 -0700 (PDT) X-Env-Sender: md3135@att.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1317141357!39180464!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32013 invoked from network); 27 Sep 2011 16:35:57 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 16:35:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8RGaOSO014111; Tue, 27 Sep 2011 12:36:24 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8RGaMK5014074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2011 12:36:22 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.142]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0289.001; Tue, 27 Sep 2011 12:35:54 -0400 From: "DOLLY, MARTIN C" To: "'R.Jesske@telekom.de'" , "'vkg@bell-labs.com'" , "'cuss@ietf.org'" Thread-Topic: [cuss] Adopting draft-drage-cuss-sip-uui-isdn Thread-Index: Acx9Hf70U8e5CvnVQCaXpSUGu3vSNgABHK8gAARFKvQ= Date: Tue, 27 Sep 2011 16:35:53 +0000 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0968C5CD3F@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.151.223.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 16:33:15 -0000 +1, agreed move forward Martin C. Dolly Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink = Possible. +1.609.903.3360 ----- Original Message ----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Tuesday, September 27, 2011 10:36 AM=0A= To: vkg@bell-labs.com ; cuss@ietf.org Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn Hi, I have no concerns, so Keith can provide a WG version. Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > Auftrag von Vijay K. Gurbani > Gesendet: Dienstag, 27. September 2011 16:04 > An: cuss@ietf.org > Betreff: [cuss] Adopting draft-drage-cuss-sip-uui-isdn > > Folks: As discussed during last week's virtual interim > meeting [1], the WG needs to choose a draft that satisfies > the last orphan milestone (ISDN UUI Service application usage > specification). > > Keith Drage has an individual draft [2] that could be used towards > the milestone. A call for additional candidate drafts went out on > Sep-08-2011 [3], but did not result in any new entries. > > Therefore, during the interim meeting of Sep-21-2011, it was > decided to adopt draft-drage-cuss-sip-uui-isdn as the working > group draft towards the ISDN UUI Service application usage > milestone. > > As such, Enrico and I seek to ratify this decision on the mailing > list and request Keith to submit a WG -00 version of his draft > no later than Tuesday, Aug-4-2011. > > If there are any concerns, please let the WG know. > > [1] Draft minutes at > http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html > [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 > [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > 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 vkg@bell-labs.com Tue Sep 27 10:24:57 2011 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 F070921F8EB7 for ; Tue, 27 Sep 2011 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.624 X-Spam-Level: X-Spam-Status: No, score=-106.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 uEnpbO7cQOq7 for ; Tue, 27 Sep 2011 10:24:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD221F8EC4 for ; Tue, 27 Sep 2011 10:24:55 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p8RHRf9V001780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Sep 2011 12:27:41 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8RHRe3N000775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Sep 2011 12:27:41 -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 p8RHRevx007227 for ; Tue, 27 Sep 2011 12:27:40 -0500 (CDT) Message-ID: <4E820826.4060304@bell-labs.com> Date: Tue, 27 Sep 2011 12:30:14 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Corrected: Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 17:24:57 -0000 Sorry, date below of "Aug-4-2011" should be "Oct-4-2011". --- Original message Folks: As discussed during last week's virtual interim meeting [1], the WG needs to choose a draft that satisfies the last orphan milestone (ISDN UUI Service application usage specification). Keith Drage has an individual draft [2] that could be used towards the milestone. A call for additional candidate drafts went out on Sep-08-2011 [3], but did not result in any new entries. Therefore, during the interim meeting of Sep-21-2011, it was decided to adopt draft-drage-cuss-sip-uui-isdn as the working group draft towards the ISDN UUI Service application usage milestone. As such, Enrico and I seek to ratify this decision on the mailing list and request Keith to submit a WG -00 version of his draft no later than Tuesday, Aug-4-2011. If there are any concerns, please let the WG know. [1] Draft minutes at http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html --- End original message Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From laura.liess.dt@googlemail.com Tue Sep 27 12:52:36 2011 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 0D1AB21F8CD0 for ; Tue, 27 Sep 2011 12:52:36 -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 OR8UPgTUnH9l for ; Tue, 27 Sep 2011 12:52:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D79EA21F8CC1 for ; Tue, 27 Sep 2011 12:52:34 -0700 (PDT) Received: by wyh21 with SMTP id 21so6117202wyh.31 for ; Tue, 27 Sep 2011 12:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Lw8hclG0tEMsyJUpYYEy/4FmeSpWxZPZcX62i+iNZik=; b=GKjBbtmhlD/hpRROalWzCGpn0M9cxToGlB9WTF/3R1k0+ZyTTQERaCmBQIlG3Xi3rX l57D06Tz1jai3Ee2nlLbWsGD60/rFGXrvzqrosGNYKZrr/Qj3MxpxrUtOM1PURbqFPtJ +xH2YDMOCEq4QQV+0lJYrQN4/iL4Ud9L84Fh4= MIME-Version: 1.0 Received: by 10.227.9.1 with SMTP id j1mr9587543wbj.12.1317153320464; Tue, 27 Sep 2011 12:55:20 -0700 (PDT) Received: by 10.227.7.165 with HTTP; Tue, 27 Sep 2011 12:55:20 -0700 (PDT) In-Reply-To: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D0968C5CD3F@HE111648.emea1.cds.t-internal.com> Date: Tue, 27 Sep 2011 21:55:20 +0200 Message-ID: From: Laura Liess To: "DOLLY, MARTIN C" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 19:52:36 -0000 I agree with moving on with the draft. regards, Laura 2011/9/27 DOLLY, MARTIN C : > +1, agreed move forward > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethin= k Possible. > +1.609.903.3360 > > ----- Original Message ----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Tuesday, September 27, 2011 10:36 AM > To: vkg@bell-labs.com ; cuss@ietf.org > Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn > > Hi, > I have no concerns, so Keith can provide a WG version. > > Regards > > Roland > > >> -----Urspr=FCngliche Nachricht----- >> Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im >> Auftrag von Vijay K. Gurbani >> Gesendet: Dienstag, 27. September 2011 16:04 >> An: cuss@ietf.org >> Betreff: [cuss] Adopting draft-drage-cuss-sip-uui-isdn >> >> Folks: As discussed during last week's virtual interim >> meeting [1], the WG needs to choose a draft that satisfies >> the last orphan milestone (ISDN UUI Service application usage >> specification). >> >> Keith Drage has an individual draft [2] that could be used towards >> the milestone. =A0A call for additional candidate drafts went out on >> Sep-08-2011 [3], but did not result in any new entries. >> >> Therefore, during the interim meeting of Sep-21-2011, it was >> decided to adopt draft-drage-cuss-sip-uui-isdn as the working >> group draft towards the ISDN UUI Service application usage >> milestone. >> >> As such, Enrico and I seek to ratify this decision on the mailing >> list and request Keith to submit a WG -00 version of his draft >> no later than Tuesday, Aug-4-2011. >> >> If there are any concerns, please let the WG know. >> >> [1] Draft minutes at >> =A0 =A0http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html >> [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 >> [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html >> >> Thanks, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (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 >> > _______________________________________________ > 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 keith.drage@alcatel-lucent.com Tue Sep 27 17:00:52 2011 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 4D4EB21F8D0B for ; Tue, 27 Sep 2011 17:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.975 X-Spam-Level: X-Spam-Status: No, score=-105.975 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 7igNjIa40oQS for ; Tue, 27 Sep 2011 17:00:51 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 116F321F8D08 for ; Tue, 27 Sep 2011 17:00:50 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8S03aBa004875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Sep 2011 02:03:36 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 28 Sep 2011 02:03:36 +0200 From: "DRAGE, Keith (Keith)" To: "Gurbani, Vijay K (Vijay)" , "cuss@ietf.org" Date: Wed, 28 Sep 2011 02:03:34 +0200 Thread-Topic: [cuss] Adopting draft-drage-cuss-sip-uui-isdn Thread-Index: Acx9HgGBJDsQBC86Q4SMSwB3rdiiDAAD2lcg Message-ID: References: <4E81D7DA.3030302@bell-labs.com> In-Reply-To: <4E81D7DA.3030302@bell-labs.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.84 Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 00:00:52 -0000 If and when I submit a -00 next week (dependent of course on the WG respons= e to the request by the WG chairs below, I would like to introduce some add= itional changes, based on comments made in the interim meeting, and on some= alignment discussion held with the editors of the UUI mechanism draft. If there are issues with any of these, then please say so and I will not in= clude them, and we can defer them to further discussion. Please be specific= as to which items you have issues with if responding - I'd rather not see = a default to all not handled. My proposed changes are: 1) Discussions on the list have highlighted the overburdening of the word "= application". As a result it is proposed to change the name of the "app" he= ader field parameter in the mechanism draft to "package" header field param= eter. This has a consequential impact on the ISDN document. The word "appli= cation" is now solely reserved for the name of the functionality that passe= s the UUI to the SIP functionality to send, and to which the UUI is deliver= ed on receipt by the SIP functionality. As well as the change of the name o= f the header field parameter, this results in a number of instances of the = word "application" becoming "package". A couple of instances relating to th= e coding of the "content" header field parameter become "SIP entity". 2) Section 5 needs substantial rewording as it no longer applies in this ma= nner. I propose that we modify the text to indicate that if one wants to us= e an enhanced UUI where both endpoints are SIP, but still work with the ISD= N, then one will have to same information using two different packages, one= the ISDN one, and the other some enhanced package. My current proposal is to delete the last sentence of the first paragraph a= nd reword the second paragraph as follows: "The SIP UUI mechanism provides a way to achieve this transition. As an en= dpoint moves from being an ISDN gateway to a native SIP endpoint, and a pac= kage for some form of enhanced UUI has been standardized, the endpoint can = carry the UUI data both as ISDN and as some other package in parallel. Thi= s will permit the other endpoint to use the UUI according to the ISDN packa= ge if it is an ISDN gateway or the enhanced package if it is a native SIP e= ndpoint." 3) In section 8, a couple of requirements relating to the "content" header = field parameter actually relate to the "package" header field parameter (fo= rmerly "app" header field parameter). These are corrected. 4) Update references from "draft-johnston-cuss-sip-uui" to "draft-ietf-cuss= -sip-uui". 5) Make clear throughout the document that the UUI payload is a protocol di= scriminator plus 128 octets of data. 6) Make clearer that it is the initial INVITE request and responses and the= BYE request and responses only that carry the information in this package. 7) Make clear that there are no normative requirements on the protocol disc= riminator. This text is added to the end of section 9: " This document places no other normative requirement on the use of the pro= tocol discriminator; it is required at interworking gateways to allow mappi= ng into the appropriate fields in the ISDN protocols, but otherwise the usa= ge is entirely up to the application, and outside the scope of this documen= t. Valid values are identified and documented by ITU-T, and there is no IAN= A registry for these values." 8) Remove the following text from section 7, as it is a duplicate of the te= xt in section 9: " When sending UUI, the sending application MUST include a protocol discrim= inator octet, conforming to table 4-26 of ITU-T Recommendation Q.931 [Q931]= as the first octet of the payload information." 9) Define a media feature tag specific for the package. It has been propose= d to do this for all packages. "sip.uui-isdn" is proposed. 10) Correct the short title for the draft. I am aware we need to rework the security considerations text but that will= require a little more research, so I will stick at this list for the momen= t. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Vijay K. Gurbani > Sent: 27 September 2011 15:04 > To: cuss@ietf.org > Subject: [cuss] Adopting draft-drage-cuss-sip-uui-isdn >=20 > Folks: As discussed during last week's virtual interim > meeting [1], the WG needs to choose a draft that satisfies > the last orphan milestone (ISDN UUI Service application usage > specification). >=20 > Keith Drage has an individual draft [2] that could be used towards > the milestone. A call for additional candidate drafts went out on > Sep-08-2011 [3], but did not result in any new entries. >=20 > Therefore, during the interim meeting of Sep-21-2011, it was > decided to adopt draft-drage-cuss-sip-uui-isdn as the working > group draft towards the ISDN UUI Service application usage > milestone. >=20 > As such, Enrico and I seek to ratify this decision on the mailing > list and request Keith to submit a WG -00 version of his draft > no later than Tuesday, Aug-4-2011. >=20 > If there are any concerns, please let the WG know. >=20 > [1] Draft minutes at > http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html > [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 > [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From alan.b.johnston@gmail.com Thu Sep 29 05:05:42 2011 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 C3B0821F8C59 for ; Thu, 29 Sep 2011 05:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 GD-sI4O81B0u for ; Thu, 29 Sep 2011 05:05:38 -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 B1CC021F8CED for ; Thu, 29 Sep 2011 05:05:38 -0700 (PDT) Received: by ywa6 with SMTP id 6so580765ywa.31 for ; Thu, 29 Sep 2011 05:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=szpVdnSORmogL+w3Bvyp2WRXt6N/qRSwpnpEDYd9rUg=; b=MwT+Dg6wcsBazLlU400mXsJx4TcJEC5vWnORkB89OAubWgoHYmrIRBUFw9aI5n7rSK 0syySZFIYJiElcAOj7LrpYt0s7aNrxP3Jaa2eOP70mCKKbDzWD3SbqfhzgppUtcKNm1a /WmzXO0jLvF4qFCRgfLBSqwfjr7RWT0NO9b/o= MIME-Version: 1.0 Received: by 10.151.86.21 with SMTP id o21mr9341205ybl.94.1317298109543; Thu, 29 Sep 2011 05:08:29 -0700 (PDT) Received: by 10.151.113.4 with HTTP; Thu, 29 Sep 2011 05:08:29 -0700 (PDT) In-Reply-To: References: <4E81D7DA.3030302@bell-labs.com> Date: Thu, 29 Sep 2011 07:08:29 -0500 Message-ID: From: Alan Johnston To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Gurbani, Vijay K \(Vijay\)" , "cuss@ietf.org" Subject: Re: [cuss] Adopting draft-drage-cuss-sip-uui-isdn X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 12:05:42 -0000 I support adopting this draft as a working group item. We will soon produce a revision to the mechanism draft to align with these changes. - Alan - On Tue, Sep 27, 2011 at 7:03 PM, DRAGE, Keith (Keith) wrote: > If and when I submit a -00 next week (dependent of course on the WG respo= nse to the request by the WG chairs below, I would like to introduce some a= dditional changes, based on comments made in the interim meeting, and on so= me alignment discussion held with the editors of the UUI mechanism draft. > > If there are issues with any of these, then please say so and I will not = include them, and we can defer them to further discussion. Please be specif= ic as to which items you have issues with if responding - I'd rather not se= e a default to all not handled. > > My proposed changes are: > > 1) =A0 =A0 =A0Discussions on the list have highlighted the overburdening = of the word "application". As a result it is proposed to change the name of= the "app" header field parameter in the mechanism draft to "package" heade= r field parameter. This has a consequential impact on the ISDN document. Th= e word "application" is now solely reserved for the name of the functionali= ty that passes the UUI to the SIP functionality to send, and to which the U= UI is delivered on receipt by the SIP functionality. As well as the change = of the name of the header field parameter, this results in a number of inst= ances of the word "application" becoming "package". A couple of instances r= elating to the coding of the "content" header field parameter become "SIP e= ntity". > > 2) =A0 =A0 =A0Section 5 needs substantial rewording as it no longer appli= es in this manner. I propose that we modify the text to indicate that if on= e wants to use an enhanced UUI where both endpoints are SIP, but still work= with the ISDN, then one will have to same information using two different = packages, one the ISDN one, and the other some enhanced package. > > My current proposal is to delete the last sentence of the first paragraph= and reword the second paragraph as follows: > > "The SIP UUI mechanism provides a way to achieve this transition. =A0As a= n endpoint moves from being an ISDN gateway to a native SIP endpoint, and a= package for some form of enhanced UUI has been standardized, the endpoint = can carry the UUI data both as ISDN and as some other package in parallel. = =A0This will permit the other endpoint to use the UUI according to the ISDN= package if it is an ISDN gateway or the enhanced package if it is a native= SIP endpoint." > > 3) =A0 =A0 =A0In section 8, a couple of requirements relating to the "con= tent" header field parameter actually relate to the "package" header field = parameter (formerly "app" header field parameter). These are corrected. > > 4) =A0 =A0 =A0Update references from "draft-johnston-cuss-sip-uui" to "dr= aft-ietf-cuss-sip-uui". > > 5) =A0 =A0 =A0Make clear throughout the document that the UUI payload is = a protocol discriminator plus 128 octets of data. > > 6) =A0 =A0 =A0Make clearer that it is the initial INVITE request and resp= onses and the BYE request and responses only that carry the information in = this package. > > 7) =A0 =A0 =A0Make clear that there are no normative requirements on the = protocol discriminator. This text is added to the end of section 9: > > " This document places no other normative requirement on the use of the p= rotocol discriminator; it is required at interworking gateways to allow map= ping into the appropriate fields in the ISDN protocols, but otherwise the u= sage is entirely up to the application, and outside the scope of this docum= ent. Valid values are identified and documented by ITU-T, and there is no I= ANA registry for these values." > > 8) =A0 =A0 =A0Remove the following text from section 7, as it is a duplic= ate of the text in section 9: > > " When sending UUI, the sending application MUST include a protocol discr= iminator octet, conforming to table 4-26 of ITU-T Recommendation Q.931 [Q93= 1] as the first octet of the payload information." > > 9) =A0 =A0 =A0Define a media feature tag specific for the package. It has= been proposed to do this for all packages. "sip.uui-isdn" is proposed. > > 10) =A0 =A0 Correct the short title for the draft. > > I am aware we need to rework the security considerations text but that wi= ll require a little more research, so I will stick at this list for the mom= ent. > > > Regards > > Keith > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of >> Vijay K. Gurbani >> Sent: 27 September 2011 15:04 >> To: cuss@ietf.org >> Subject: [cuss] Adopting draft-drage-cuss-sip-uui-isdn >> >> Folks: As discussed during last week's virtual interim >> meeting [1], the WG needs to choose a draft that satisfies >> the last orphan milestone (ISDN UUI Service application usage >> specification). >> >> Keith Drage has an individual draft [2] that could be used towards >> the milestone. =A0A call for additional candidate drafts went out on >> Sep-08-2011 [3], but did not result in any new entries. >> >> Therefore, during the interim meeting of Sep-21-2011, it was >> decided to adopt draft-drage-cuss-sip-uui-isdn as the working >> group draft towards the ISDN UUI Service application usage >> milestone. >> >> As such, Enrico and I seek to ratify this decision on the mailing >> list and request Keith to submit a WG -00 version of his draft >> no later than Tuesday, Aug-4-2011. >> >> If there are any concerns, please let the WG know. >> >> [1] Draft minutes at >> =A0 =A0http://www.ietf.org/mail-archive/web/cuss/current/msg00263.html >> [2] http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-01 >> [3] http://www.ietf.org/mail-archive/web/cuss/current/msg00234.html >> >> Thanks, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (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 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From internet-drafts@ietf.org Thu Sep 29 08:20:56 2011 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 0D75521F8D88; Thu, 29 Sep 2011 08:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 zJvMjaSElOD0; Thu, 29 Sep 2011 08:20:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8129121F8CB5; Thu, 29 Sep 2011 08:20:55 -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: 3.60 Message-ID: <20110929152055.26713.78609.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2011 08:20:55 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-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: Thu, 29 Sep 2011 15:20:56 -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 : Problem Statement and Requirements for Transporting User= to User Call Control Information in SIP Author(s) : Alan Johnston Laura Liess Filename : draft-ietf-cuss-sip-uui-reqs-06.txt Pages : 11 Date : 2011-09-29 This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-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-reqs-06.txt From alan.b.johnston@gmail.com Thu Sep 29 08:31:40 2011 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 6B76421F8DFD for ; Thu, 29 Sep 2011 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 2qvuv1okss0O for ; Thu, 29 Sep 2011 08:31:39 -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 BBF6521F8DEB for ; Thu, 29 Sep 2011 08:31:39 -0700 (PDT) Received: by ywa6 with SMTP id 6so814374ywa.31 for ; Thu, 29 Sep 2011 08:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=eLAh7RC/L73xlpPQAlu12aIZo7nCSmDVhwAFRfl1Zc4=; b=FkrEfrwf14KsrurDA5kVHgdYtfqAgE1XdVSeEvlpLDIqKVsdzfqH7TX81Q0uJevSh7 TV8+OKHLEUnvc7VAvEGm077U8+y8wBJIao3x+WPMRiweG7sQXumsMVPru14zlbJlMAr2 NGVBqYjN70amIoD0C34/g5znh4J8kfLG2OFyo= MIME-Version: 1.0 Received: by 10.151.28.19 with SMTP id f19mr9584577ybj.151.1317310470852; Thu, 29 Sep 2011 08:34:30 -0700 (PDT) Received: by 10.151.113.4 with HTTP; Thu, 29 Sep 2011 08:34:30 -0700 (PDT) In-Reply-To: <20110929152055.26713.78609.idtracker@ietfa.amsl.com> References: <20110929152055.26713.78609.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2011 10:34:30 -0500 Message-ID: From: Alan Johnston To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-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: Thu, 29 Sep 2011 15:31:40 -0000 All, I have revised the requirements draft based on Gonzalo's AD comments and Keith's terminology comments. I believe it is ready for IETF LC. - Alan - On Thu, Sep 29, 2011 at 10:20 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Call Control UUI Service for SIP Wo= rking Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Problem Statement and Requirem= ents for Transporting User to User Call Control Information in SIP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Laura Liess > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-cuss-sip-uui-reqs-06.= txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-29 > > =A0 This document introduces the transport of call control related User > =A0 to User Information (UUI) using the Session Initiation Protocol > =A0 (SIP), and develops several requirements for a new SIP mechanism. > =A0 Some SIP sessions are established by or related to a non-SIP > =A0 application. =A0This application may have information that needs to b= e > =A0 transported between the SIP User Agents during session establishment. > =A0 In addition to interworking with the ISDN UUI Service, this extension > =A0 will also be used for native SIP endpoints requiring application UUI. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-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-reqs-06.txt > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From gonzalo.camarillo@ericsson.com Thu Sep 29 09:31:03 2011 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 B387A21F8E8E for ; Thu, 29 Sep 2011 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.689 X-Spam-Level: X-Spam-Status: No, score=-104.689 tagged_above=-999 required=5 tests=[AWL=1.683, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 GEXvbyRNV70b for ; Thu, 29 Sep 2011 09:31:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D78E921F8EA9 for ; Thu, 29 Sep 2011 09:31:02 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b9-4e849df156a8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.115.87]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.DC.20773.1FD948E4; Thu, 29 Sep 2011 18:33:53 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 18:33:31 +0200 Received: from [131.160.126.200] (rvi2-126-200.lmf.ericsson.se [131.160.126.200]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8FC79245F; Thu, 29 Sep 2011 19:33:29 +0300 (EEST) Message-ID: <4E849DD8.6080002@ericsson.com> Date: Thu, 29 Sep 2011 19:33:28 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Alan Johnston References: <20110929152055.26713.78609.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "cuss@ietf.org" Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-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: Thu, 29 Sep 2011 16:31:03 -0000 Hi, I have just requested its IETF LC. It will start shortly. Cheers, Gonzalo On 29/09/2011 6:34 PM, Alan Johnston wrote: > All, > > I have revised the requirements draft based on Gonzalo's AD comments > and Keith's terminology comments. > > I believe it is ready for IETF LC. > > - Alan - > > On Thu, Sep 29, 2011 at 10:20 AM, wrote: >> 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 : Problem Statement and Requirements for Transporting User to User Call Control Information in SIP >> Author(s) : Alan Johnston >> Laura Liess >> Filename : draft-ietf-cuss-sip-uui-reqs-06.txt >> Pages : 11 >> Date : 2011-09-29 >> >> This document introduces the transport of call control related User >> to User Information (UUI) using the Session Initiation Protocol >> (SIP), and develops several requirements for a new SIP mechanism. >> Some SIP sessions are established by or related to a non-SIP >> application. This application may have information that needs to be >> transported between the SIP User Agents during session establishment. >> In addition to interworking with the ISDN UUI Service, this extension >> will also be used for native SIP endpoints requiring application UUI. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-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-reqs-06.txt >> _______________________________________________ >> 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 iesg-secretary@ietf.org Thu Sep 29 10:18:36 2011 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 EC3D121F8CD1; Thu, 29 Sep 2011 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 bq1ied7-r+Xz; Thu, 29 Sep 2011 10:18:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD5821F8C97; Thu, 29 Sep 2011 10:18:35 -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: 3.60 Message-ID: <20110929171835.24723.71395.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2011 10:18:35 -0700 Cc: cuss@ietf.org Subject: [cuss] Last Call: (Problem Statement and Requirements for Transporting User to User Call Control Information in SIP) to Informational RFC 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: Thu, 29 Sep 2011 17:18:36 -0000 The IESG has received a request from the Call Control UUI Service for SIP WG (cuss) to consider the following document: - 'Problem Statement and Requirements for Transporting User to User Call Control Information in SIP' as an Informational RFC 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 2011-10-13. 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 This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/ No IPR declarations have been submitted directly on this I-D.