From nobody Wed Apr 2 09:12:12 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8537F1A0284; Wed, 2 Apr 2014 09:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdr-05ziJIGm; Wed, 2 Apr 2014 09:11:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4E1A0390; Wed, 2 Apr 2014 09:10:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402161038.10532.85976.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 09:10:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/RKoLwMHftgm8uq6NynSutoPVCDg Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-15.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:12:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. Title : A Mechanism for Transporting User to User Call Control Information in SIP Authors : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-15.txt Pages : 19 Date : 2014-04-02 Abstract: There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 3 15:15:43 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186831A019D for ; Thu, 3 Apr 2014 15:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVXIlOyJBuOh for ; Thu, 3 Apr 2014 15:15:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BE0671A026D for ; Thu, 3 Apr 2014 15:15:37 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s33MFWHE027085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Apr 2014 17:15:32 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s33MFVCK010948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 Apr 2014 17:15:32 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s33MFVuK007271 for ; Thu, 3 Apr 2014 17:15:31 -0500 (CDT) Message-ID: <533DDDE5.9030101@bell-labs.com> Date: Thu, 03 Apr 2014 17:17:09 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 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.64 on 135.3.39.10 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/FwqgTmH2crnzOwvWn_nN3EMjX-Y Subject: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2014 22:15:42 -0000 All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the "Standards Action" guideline for defining UUI packages and registering new IANA elements for the parameter tables for purpose, encoding and content. The draft authors note that the original concern when the work was coming out of Dispatch was that the UUI not become a "wildcard" header to be used for a wide variety of purposes. Hence the direction toward requiring a standards track RFC. However, a lesser standard such as "Specification Required" might suffice and offer more flexibility for additional use cases, while not opening up the process totally as would be the case for "First Come First Serve." The IESG will like to revisit this decision to confirm that the WG decisions remains "Standards Action". To that end, Enrico and I will like to open up a 2-week period to ratify this decision to remain at "Standards Action" or to move to something other designation. The 2-week period ends on close of business (US Central Time) April 17, 2014. Please express an opinion; if you are for keeping status quo, please send a one-liner to the cuss WG mailing list. If you are of the opinion that we should relax the burden, please state so and a short reason on why we should do so. Thank you all. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Apr 4 07:33:08 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248A51A0191 for ; Fri, 4 Apr 2014 07:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQOiKtCEt7ho for ; Fri, 4 Apr 2014 07:33:01 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3401E1A0152 for ; Fri, 4 Apr 2014 07:33:01 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id lnyY1n0080QuhwU55qYwLx; Fri, 04 Apr 2014 14:32:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:f9e7:d4b2:db8d:afda]) by omta02.westchester.pa.mail.comcast.net with comcast id lqYu1n00y4wFaYb3NqYvCN; Fri, 04 Apr 2014 14:32:56 +0000 Message-ID: <533EC296.2080603@alum.mit.edu> Date: Fri, 04 Apr 2014 10:32:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: cuss@ietf.org References: <533DDDE5.9030101@bell-labs.com> In-Reply-To: <533DDDE5.9030101@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396621976; bh=b0i1q93i8xwSo7p4/VQ6/U0KDcm4aS7leFXpn1VLuF8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PiSUhbzPlLHxv1UCK4o9ZswmSG1Qg8hJfLmzOWFQcA4gSls+iwbnn+SY3GHD4/SKZ W4mxhCKZmy4M9J4lsmsPO7Je9Q8SnCJeh0okm3PcKYFVYyhd9EVh0i2AnogogK0IMk z8D6jdBnuCC3y3ruXj2ifp4RACBjD6ONQ7saIwhyC886d8ouec9TMHN7P4vQ98iN8h YfEcvZzRrOAzorZlP6cTQsxLErVrNDr2X9z+EyQ1MoM4l0kSOtVkHyhsXCF6mwIQxI F4ovmTzDQk6Yhu/5zK/sFmXT5nJT2D71Pt5fakN3bxipb7ZJlmx6Xw78JG3JlB9iYX ItX9N7xOj6sWw== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/xrb_KHObehGxP1V9vjG2L-1eQnY Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 14:33:06 -0000 Interesting to see this come back. My original opinion was (and still is) that for these to be useful, it must be possible for using enterprises to assign new values for each distinct deployment of an application. IMO even FCFS might be too high a bar for this. E.g., if I create a particular VXML application that captures some data and communicates it to a call center agent application via UUI, then the format of that data is likely to be unique. Lowering the bar below FCFS would require a naming scheme that guarantees uniqueness without registration. Thanks, Paul On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: > All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the > "Standards Action" guideline for defining UUI packages and registering > new IANA elements for the parameter tables for purpose, encoding and > content. > > The draft authors note that the original concern when the work > was coming out of Dispatch was that the UUI not become a "wildcard" > header to be used for a wide variety of purposes. Hence the direction > toward requiring a standards track RFC. However, a lesser standard > such as "Specification Required" might suffice and offer more > flexibility for additional use cases, while not opening up the process > totally as would be the case for "First Come First Serve." > > The IESG will like to revisit this decision to confirm that the WG > decisions remains "Standards Action". > > To that end, Enrico and I will like to open up a 2-week period to ratify > this decision to remain at "Standards Action" or to move to something > other designation. > > The 2-week period ends on close of business (US Central Time) April 17, > 2014. Please express an opinion; if you are for keeping status quo, > please send a one-liner to the cuss WG mailing list. If you are of the > opinion that we should relax the burden, please state so and a short > reason on why we should do so. > > Thank you all. > > - vijay From nobody Fri Apr 4 09:46:14 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090431A0227 for ; Fri, 4 Apr 2014 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHVKN8U1GpFZ for ; Fri, 4 Apr 2014 09:46:08 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC6F1A0224 for ; Fri, 4 Apr 2014 09:46:08 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so3716900wgg.2 for ; Fri, 04 Apr 2014 09:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XtVPbGUM+5221ewWUwh4g59g+YxYQGqwEOkmWmSVmSY=; b=X8faMQ47P/bl3Jukmrfn1A9gUJQvAH3Ue6gewVc74Kv6J50pn3kqmw8H0OSvMEhzTY TR929ITWxZQODLNRip6MaB9IR9ZjPDXrtJ6Saxeto0SznZvczHDBYpCfk5MgG12cs7Ep FRZ++FjOoKGNzWE3I95UkezepIbwmB1yF4QchVN3eVq+SAT+IF42s7w+RqBRR1ElXkS7 /oHcT40abZ2fKKNaEcplW8Hy3vB715VODuWcBwCUQgWKiClr3B4+iTfV5RODn2+/ELck +2HmQaBddm4GJ4ADaw3dzqOLn70yLrapZT9NzMqtlgLLO5RCoedpa2Ov5dsKnRYlxNOL HiaQ== MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr6059411wib.42.1396629963275; Fri, 04 Apr 2014 09:46:03 -0700 (PDT) Received: by 10.217.152.10 with HTTP; Fri, 4 Apr 2014 09:46:03 -0700 (PDT) In-Reply-To: <533EC296.2080603@alum.mit.edu> References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> Date: Fri, 4 Apr 2014 11:46:03 -0500 Message-ID: From: Alan Johnston To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8f3ba5b5d8044e04f63a401d Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/YeYvyC1pgP2V8l1wkE3NoNgdwAk Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 16:46:13 -0000 --e89a8f3ba5b5d8044e04f63a401d Content-Type: text/plain; charset=ISO-8859-1 Paul, I know you've explained this before. But you haven't explained how the requirements in Section 5. Guidelines for UUI Packages can be enforced if there isn't any review. Can you elaborate on this? - Alan - On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat wrote: > Interesting to see this come back. > > My original opinion was (and still is) that for these to be useful, it > must be possible for using enterprises to assign new values for each > distinct deployment of an application. IMO even FCFS might be too high a > bar for this. > > E.g., if I create a particular VXML application that captures some data > and communicates it to a call center agent application via UUI, then the > format of that data is likely to be unique. > > Lowering the bar below FCFS would require a naming scheme that guarantees > uniqueness without registration. > > Thanks, > Paul > > On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: > >> All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the >> "Standards Action" guideline for defining UUI packages and registering >> new IANA elements for the parameter tables for purpose, encoding and >> content. >> >> The draft authors note that the original concern when the work >> was coming out of Dispatch was that the UUI not become a "wildcard" >> header to be used for a wide variety of purposes. Hence the direction >> toward requiring a standards track RFC. However, a lesser standard >> such as "Specification Required" might suffice and offer more >> flexibility for additional use cases, while not opening up the process >> totally as would be the case for "First Come First Serve." >> >> The IESG will like to revisit this decision to confirm that the WG >> decisions remains "Standards Action". >> >> To that end, Enrico and I will like to open up a 2-week period to ratify >> this decision to remain at "Standards Action" or to move to something >> other designation. >> >> The 2-week period ends on close of business (US Central Time) April 17, >> 2014. Please express an opinion; if you are for keeping status quo, >> please send a one-liner to the cuss WG mailing list. If you are of the >> opinion that we should relax the burden, please state so and a short >> reason on why we should do so. >> >> Thank you all. >> >> - vijay >> > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > --e89a8f3ba5b5d8044e04f63a401d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Paul,

I know you've explained this = before. =A0But you haven't explained how the requirements in Section=A0= 5. Guidelines for UUI Packages can be enforced if there isn't any revie= w. =A0Can you elaborate on this?

- Alan -


=
On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Interesting to see this come back.

My original opinion was (and still is) that for these to be useful, it must= be possible for using enterprises to assign new values for each distinct d= eployment of an application. IMO even FCFS might be too high a bar for this= .

E.g., if I create a particular VXML application that captures some data and= communicates it to a call center agent application via UUI, then the forma= t of that data is likely to be unique.

Lowering the bar below FCFS would require a naming scheme that guarantees u= niqueness without registration.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

On 4/3/14 6:17 PM, Vijay K. Gurbani wrote:
All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the
"Standards Action" guideline for defining UUI packages and regist= ering
new IANA elements for the parameter tables for purpose, encoding and
content.

The draft authors note that the original concern when the work
was coming out of Dispatch was that the UUI not become a "wildcard&quo= t;
header to be used for a wide variety of purposes. =A0Hence the direction toward requiring a standards track RFC. =A0However, a lesser standard
such as "Specification Required" might suffice and offer more
flexibility for additional use cases, while not opening up the process
totally as would be the case for "First Come First Serve."

The IESG will like to revisit this decision to confirm that the WG
decisions remains "Standards Action".

To that end, Enrico and I will like to open up a 2-week period to ratify this decision to remain at "Standards Action" or to move to somet= hing
other designation.

The 2-week period ends on close of business (US Central Time) April 17,
2014. =A0Please express an opinion; if you are for keeping status quo,
please send a one-liner to the cuss WG mailing list. =A0If you are of the opinion that we should relax the burden, please state so and a short
reason on why we should do so.

Thank you all.

- vijay

_______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cuss

--e89a8f3ba5b5d8044e04f63a401d-- From nobody Fri Apr 4 12:32:42 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13E01A0192 for ; Fri, 4 Apr 2014 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STuvKNYT7zBg for ; Fri, 4 Apr 2014 12:32:34 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC601A0174 for ; Fri, 4 Apr 2014 12:32:34 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id lnWf1n0020Fqzac56vYVoN; Fri, 04 Apr 2014 19:32:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:e4ed:5ea7:c3bf:a277]) by omta08.westchester.pa.mail.comcast.net with comcast id lvXL1n00T1TX2lk3UvXMjS; Fri, 04 Apr 2014 19:32:29 +0000 Message-ID: <533F0885.7040503@alum.mit.edu> Date: Fri, 04 Apr 2014 15:31:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alan Johnston References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396639949; bh=lA5+FmI1cJyylSpeyYYaQXRR46jEZfbJbHcfXABsZ1c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gQJjGFhwc6FXySPAJUgmNpzOW2teb/69jRBPjTPxbF6+C+cKgwPwpF7Yw/qobABIR H7eVod48RjWu/fvl28E57kuv0da1ZRrKSibgD6g9gc/iof5lHb9vD52TAaV8rlHvgL FizeI0i4w3KMdUWGDP5fZacHp1bwtGO1tG0jvQYyncZefeEbHF5YOeEGZSMAtm5ynd CyCFVUzH7x1WdNn8TjYIQiq90s4aa1mTgKaybcI4y9e1BGdAs5SlSKTgtO8N4Y29po uwOE+REZ8cowIYM2/WTyTu/dMLwRnvDMToQm0yEGM/MjKP8ylD4/FIajyjY3mrTxJ9 CMmxLLYPHIHpA== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/tSqc-pvDq_4HjPh-zDahq87ys9s Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 19:32:39 -0000 On 4/4/14 12:46 PM, Alan Johnston wrote: > Paul, > > I know you've explained this before. But you haven't explained how the > requirements in Section 5. Guidelines for UUI Packages can be enforced > if there isn't any review. Can you elaborate on this? With no review these couldn't be enforced. They could still remain as guidelines. Thanks, Paul > - Alan - > > > On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat > wrote: > > Interesting to see this come back. > > My original opinion was (and still is) that for these to be useful, > it must be possible for using enterprises to assign new values for > each distinct deployment of an application. IMO even FCFS might be > too high a bar for this. > > E.g., if I create a particular VXML application that captures some > data and communicates it to a call center agent application via UUI, > then the format of that data is likely to be unique. > > Lowering the bar below FCFS would require a naming scheme that > guarantees uniqueness without registration. > > Thanks, > Paul > > On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: > > All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to > ratify the > "Standards Action" guideline for defining UUI packages and > registering > new IANA elements for the parameter tables for purpose, encoding and > content. > > The draft authors note that the original concern when the work > was coming out of Dispatch was that the UUI not become a "wildcard" > header to be used for a wide variety of purposes. Hence the > direction > toward requiring a standards track RFC. However, a lesser standard > such as "Specification Required" might suffice and offer more > flexibility for additional use cases, while not opening up the > process > totally as would be the case for "First Come First Serve." > > The IESG will like to revisit this decision to confirm that the WG > decisions remains "Standards Action". > > To that end, Enrico and I will like to open up a 2-week period > to ratify > this decision to remain at "Standards Action" or to move to > something > other designation. > > The 2-week period ends on close of business (US Central Time) > April 17, > 2014. Please express an opinion; if you are for keeping status quo, > please send a one-liner to the cuss WG mailing list. If you are > of the > opinion that we should relax the burden, please state so and a short > reason on why we should do so. > > Thank you all. > > - vijay > > > _________________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/__listinfo/cuss > > > From nobody Mon Apr 14 10:34:42 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650461A06C1 for ; Mon, 14 Apr 2014 10:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHqiunA_pczz for ; Mon, 14 Apr 2014 10:34:29 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C41A069E for ; Mon, 14 Apr 2014 10:34:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A45C020992 for ; Mon, 14 Apr 2014 13:34:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 14 Apr 2014 13:34:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=E/vVhceQ3k If6NjD07mKSw92koc=; b=embaAlHjrP0CTSA8nJsGPo5Lu7LTYjrFTWjwj3nYr/ GaJHlRHplvnj4GhLRwU7PkNIYYxu64HzssmTt6Li9/rUwcNtE1XcBDeqyZJLnylZ iMmxM9Ja33txRDZ9rEeQrNYz7EVZ+i3cVD5z3AuHGrJDq53nt/Qn4GktQTTQxDqo s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=E/vVhceQ3kIf6NjD07mKSw 92koc=; b=ZPbkxsF9jf8iZMZOdxqXS2lp2QtqUkoX5VxBBzCLGdCJ/HQ4T3eifO yFbkSvYRvgdgVCf+r6jq3I6dbNslIp1WKI1jLKJpx0vTtdcPgpF9di1sgFURzb3A 7NzwxV4w00zsp7aljD0zl1FTWfDJksVkjdhgci1+7q5AJgZmuD++o= X-Sasl-enc: 1je/HEuqdpi6JXMHtpjY79QsGG7RZvnLNKETUBItllQ6 1397496866 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 96E846800C7 for ; Mon, 14 Apr 2014 13:34:24 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 14 Apr 2014 10:34:21 -0700 From: Alissa Cooper To: Message-ID: Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui References: <533DDDE5.9030101@bell-labs.com> In-Reply-To: <533DDDE5.9030101@bell-labs.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/zlbb8yvrC4aVbBhVVuPajtYWOC0 Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2014 17:34:37 -0000 There have not been many responses to Vijay=B9s request below. Please send your opinion to this list, even if it is =B3no changes needed.=B2 Thanks, Alissa On 4/3/14, 3:17 PM, "Vijay K. Gurbani" wrote: >All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the >"Standards Action" guideline for defining UUI packages and registering >new IANA elements for the parameter tables for purpose, encoding and >content. > >The draft authors note that the original concern when the work >was coming out of Dispatch was that the UUI not become a "wildcard" >header to be used for a wide variety of purposes. Hence the direction >toward requiring a standards track RFC. However, a lesser standard >such as "Specification Required" might suffice and offer more >flexibility for additional use cases, while not opening up the process >totally as would be the case for "First Come First Serve." > >The IESG will like to revisit this decision to confirm that the WG >decisions remains "Standards Action". > >To that end, Enrico and I will like to open up a 2-week period to ratify >this decision to remain at "Standards Action" or to move to something >other designation. > >The 2-week period ends on close of business (US Central Time) April 17, >2014. Please express an opinion; if you are for keeping status quo, >please send a one-liner to the cuss WG mailing list. If you are of the >opinion that we should relax the burden, please state so and a short >reason on why we should do so. > >Thank you all. > >- vijay >--=20 >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq > >_______________________________________________ >cuss mailing list >cuss@ietf.org >https://www.ietf.org/mailman/listinfo/cuss From nobody Mon Apr 14 18:36:29 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012251A06B6 for ; Mon, 14 Apr 2014 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYVcw91mU-2N for ; Mon, 14 Apr 2014 18:36:21 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id E4DCD1A02CA for ; Mon, 14 Apr 2014 18:36:20 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3F1aEjx019535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Apr 2014 20:36:15 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3F1aD12009243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 03:36:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 15 Apr 2014 03:36:13 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Alan Johnston Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui Thread-Index: AQHPT4pBb4V/ZbOWiECsn8iI8uuD3psBZOsAgAAlNICAAC4qgIAE6Y4w Date: Tue, 15 Apr 2014 01:36:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> In-Reply-To: <533F0885.7040503@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/uCG1Gxv2kCWP6G3iU9nojcCnutw Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 01:36:27 -0000 I believe we would want the guidelines enforced.=20 I also expect that we would want to do a further review of the guidelines i= f they are the sole basis for allowing packages in or not, before we allowe= d a relaxation of the approval regime. Regards Keith=20 > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 04 April 2014 20:31 > To: Alan Johnston > Cc: cuss@ietf.org > Subject: Re: [cuss] Ratification of "Standards Action"=20 > guideline for draft-ietf-cuss-sip-uui >=20 > On 4/4/14 12:46 PM, Alan Johnston wrote: > > Paul, > > > > I know you've explained this before. But you haven't explained how=20 > > the requirements in Section 5. Guidelines for UUI Packages can be=20 > > enforced if there isn't any review. Can you elaborate on this? >=20 > With no review these couldn't be enforced. > They could still remain as guidelines. >=20 > Thanks, > Paul >=20 > > - Alan - > > > > > > On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat > > wrote: > > > > Interesting to see this come back. > > > > My original opinion was (and still is) that for these=20 > to be useful, > > it must be possible for using enterprises to assign new=20 > values for > > each distinct deployment of an application. IMO even=20 > FCFS might be > > too high a bar for this. > > > > E.g., if I create a particular VXML application that=20 > captures some > > data and communicates it to a call center agent=20 > application via UUI, > > then the format of that data is likely to be unique. > > > > Lowering the bar below FCFS would require a naming scheme that > > guarantees uniqueness without registration. > > > > Thanks, > > Paul > > > > On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: > > > > All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to > > ratify the > > "Standards Action" guideline for defining UUI packages and > > registering > > new IANA elements for the parameter tables for=20 > purpose, encoding and > > content. > > > > The draft authors note that the original concern=20 > when the work > > was coming out of Dispatch was that the UUI not=20 > become a "wildcard" > > header to be used for a wide variety of purposes. Hence the > > direction > > toward requiring a standards track RFC. However, a=20 > lesser standard > > such as "Specification Required" might suffice and=20 > offer more > > flexibility for additional use cases, while not=20 > opening up the > > process > > totally as would be the case for "First Come First Serve." > > > > The IESG will like to revisit this decision to=20 > confirm that the WG > > decisions remains "Standards Action". > > > > To that end, Enrico and I will like to open up a=20 > 2-week period > > to ratify > > this decision to remain at "Standards Action" or to move to > > something > > other designation. > > > > The 2-week period ends on close of business (US=20 > Central Time) > > April 17, > > 2014. Please express an opinion; if you are for=20 > keeping status quo, > > please send a one-liner to the cuss WG mailing=20 > list. If you are > > of the > > opinion that we should relax the burden, please=20 > state so and a short > > reason on why we should do so. > > > > Thank you all. > > > > - vijay > > > > > > _________________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/__listinfo/cuss > > > > > > >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From nobody Mon Apr 14 18:59:37 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB9A1A0259 for ; Mon, 14 Apr 2014 18:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y900VbOMT41 for ; Mon, 14 Apr 2014 18:59:34 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41E1A067E for ; Mon, 14 Apr 2014 18:59:34 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id q1ED1n0070Fqzac531zXk0; Tue, 15 Apr 2014 01:59:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id q1zX1n00H3ZTu2S3U1zXCW; Tue, 15 Apr 2014 01:59:31 +0000 Message-ID: <534C9283.3010206@alum.mit.edu> Date: Mon, 14 Apr 2014 21:59:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Alan Johnston References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397527171; bh=NYOi1Ouogc0ZIk1j8l0VE93TYcsOBmSdGi/Aix/EwMg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G87kXelUS7shyjAx+9RFASS3pQrFy3llaEW6zLzNB0aEQ/P98JegZyDy2q6h9186G q048Jrbz5VtDYLWkxVDn88nuB6C++v0+XByU6hZ66tnI76cps1s8siwmXHOnWhJf9n rCZpH2bGlGxw66jzAAmAyQHJR7Tv8zkYB/vJ/fukHJrNL2DuU4rwU8kDFsuF1FBwZ+ F2lX8XCYvfXXqCODOFSpmMcC11yVD8zfBGai1Ae4+C1tfgcKoJ8TbNtKGrgZeLTSgK 7OqEwiv6HJ19dqb68uzRdLa3HL3uSCvbrkhJhc1L4VWBhaI3gk2Ipc0Fx0QftrAurH beqralGRkZDOw== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/cHZKvqiM_y0zt74ZZXwvk0f4kIc Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 01:59:36 -0000 On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: > I believe we would want the guidelines enforced. > > I also expect that we would want to do a further review of the guidelines if they are the sole basis for allowing packages in or not, before we allowed a relaxation of the approval regime. I think the effect of the registration rules will be that no new registrations are made, and the default will be used by everyone, as is currently the case. That means that everyone depends upon configuration to ensure that client and server agree on usage. If you are running a call center, and decide what information you need to communicate from your IVR to your ACD, are you going to publish an RFC to register the format for that? I think not. Even a FCFS registration is probably too much. Yet it would still be good to ensure that client and server are using the same formats. When I raised this issue early on, I got no traction for it, so I decided to let it go until people had deployment experience. Then they could figure out they need something different. But now it has come up again. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 04 April 2014 20:31 >> To: Alan Johnston >> Cc: cuss@ietf.org >> Subject: Re: [cuss] Ratification of "Standards Action" >> guideline for draft-ietf-cuss-sip-uui >> >> On 4/4/14 12:46 PM, Alan Johnston wrote: >>> Paul, >>> >>> I know you've explained this before. But you haven't explained how >>> the requirements in Section 5. Guidelines for UUI Packages can be >>> enforced if there isn't any review. Can you elaborate on this? >> >> With no review these couldn't be enforced. >> They could still remain as guidelines. >> >> Thanks, >> Paul >> >>> - Alan - >>> >>> >>> On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat >> > wrote: >>> >>> Interesting to see this come back. >>> >>> My original opinion was (and still is) that for these >> to be useful, >>> it must be possible for using enterprises to assign new >> values for >>> each distinct deployment of an application. IMO even >> FCFS might be >>> too high a bar for this. >>> >>> E.g., if I create a particular VXML application that >> captures some >>> data and communicates it to a call center agent >> application via UUI, >>> then the format of that data is likely to be unique. >>> >>> Lowering the bar below FCFS would require a naming scheme that >>> guarantees uniqueness without registration. >>> >>> Thanks, >>> Paul >>> >>> On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: >>> >>> All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to >>> ratify the >>> "Standards Action" guideline for defining UUI packages and >>> registering >>> new IANA elements for the parameter tables for >> purpose, encoding and >>> content. >>> >>> The draft authors note that the original concern >> when the work >>> was coming out of Dispatch was that the UUI not >> become a "wildcard" >>> header to be used for a wide variety of purposes. Hence the >>> direction >>> toward requiring a standards track RFC. However, a >> lesser standard >>> such as "Specification Required" might suffice and >> offer more >>> flexibility for additional use cases, while not >> opening up the >>> process >>> totally as would be the case for "First Come First Serve." >>> >>> The IESG will like to revisit this decision to >> confirm that the WG >>> decisions remains "Standards Action". >>> >>> To that end, Enrico and I will like to open up a >> 2-week period >>> to ratify >>> this decision to remain at "Standards Action" or to move to >>> something >>> other designation. >>> >>> The 2-week period ends on close of business (US >> Central Time) >>> April 17, >>> 2014. Please express an opinion; if you are for >> keeping status quo, >>> please send a one-liner to the cuss WG mailing >> list. If you are >>> of the >>> opinion that we should relax the burden, please >> state so and a short >>> reason on why we should do so. >>> >>> Thank you all. >>> >>> - vijay >>> >>> >>> _________________________________________________ >>> 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 nobody Mon Apr 14 19:44:26 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8221A030C for ; Mon, 14 Apr 2014 19:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2Nb71N-baYs for ; Mon, 14 Apr 2014 19:44:19 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 738FF1A030B for ; Mon, 14 Apr 2014 19:44:19 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so9001972wes.1 for ; Mon, 14 Apr 2014 19:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V2p3+5mFNVOpUoi/zk3Abep5ZTGsKeydnXfB08D/KLk=; b=boca/gGcpSyNRpiCcRQjkr8XmpszgL0fIk1jkkbx8Mu09aUeAlfw+AtsC9TJfqzasM fJth29wBpRhC3flc5ICokJSN9LpzfwechZ3qOVAJa7QWbcIcalcxxHsWU7yRI8PmLFLP nHXcumSQiMzsp8JqKCV5HxYHceKLIXHCCRYgRPXJ/vkL3rt8xUB2ovJp+p8C+/GEvbqj q+CpZiNJKXG4/mlYC/BTC5/CrUzx+MhzF6xRFda1ER3lcUgndjMDTBMyamIPz2Dvr/z8 gR/bPlLytMDTcixWsSafVCpjJ2/4QNUHcpVYDjjSgRyjtWboo9sfSFclvq/r0XssQrsm mRpg== MIME-Version: 1.0 X-Received: by 10.194.60.114 with SMTP id g18mr3924wjr.61.1397529854901; Mon, 14 Apr 2014 19:44:14 -0700 (PDT) Received: by 10.217.152.10 with HTTP; Mon, 14 Apr 2014 19:44:14 -0700 (PDT) In-Reply-To: <534C9283.3010206@alum.mit.edu> References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> Date: Mon, 14 Apr 2014 21:44:14 -0500 Message-ID: From: Alan Johnston To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b66f33d9083d904f70bc666 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/ncT13AYIcf5LctBXWWTVjLwAqTM Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 02:44:23 -0000 --047d7b66f33d9083d904f70bc666 Content-Type: text/plain; charset=UTF-8 Paul, Keith and I have been discussing this in terms of new packages, which can define all new SIP semantics, but I notice in your response you are mainly talking about contents. Perhaps we could have different requirements for these: the specification required for new packages, but something lower for contents. I'm not completely sure where encodings would fit in this scheme. What do you think? - Alan - On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat wrote: > On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: > >> I believe we would want the guidelines enforced. >> >> I also expect that we would want to do a further review of the guidelines >> if they are the sole basis for allowing packages in or not, before we >> allowed a relaxation of the approval regime. >> > > I think the effect of the registration rules will be that no new > registrations are made, and the default will be used by everyone, as is > currently the case. That means that everyone depends upon configuration to > ensure that client and server agree on usage. > > If you are running a call center, and decide what information you need to > communicate from your IVR to your ACD, are you going to publish an RFC to > register the format for that? I think not. Even a FCFS registration is > probably too much. Yet it would still be good to ensure that client and > server are using the same formats. > > When I raised this issue early on, I got no traction for it, so I decided > to let it go until people had deployment experience. Then they could figure > out they need something different. But now it has come up again. > > Thanks, > Paul > > Regards >> >> Keith >> >> -----Original Message----- >>> From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 04 April 2014 20:31 >>> To: Alan Johnston >>> Cc: cuss@ietf.org >>> Subject: Re: [cuss] Ratification of "Standards Action" >>> guideline for draft-ietf-cuss-sip-uui >>> >>> On 4/4/14 12:46 PM, Alan Johnston wrote: >>> >>>> Paul, >>>> >>>> I know you've explained this before. But you haven't explained how >>>> the requirements in Section 5. Guidelines for UUI Packages can be >>>> enforced if there isn't any review. Can you elaborate on this? >>>> >>> >>> With no review these couldn't be enforced. >>> They could still remain as guidelines. >>> >>> Thanks, >>> Paul >>> >>> - Alan - >>>> >>>> >>>> On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat >>> > wrote: >>>> >>>> Interesting to see this come back. >>>> >>>> My original opinion was (and still is) that for these >>>> >>> to be useful, >>> >>>> it must be possible for using enterprises to assign new >>>> >>> values for >>> >>>> each distinct deployment of an application. IMO even >>>> >>> FCFS might be >>> >>>> too high a bar for this. >>>> >>>> E.g., if I create a particular VXML application that >>>> >>> captures some >>> >>>> data and communicates it to a call center agent >>>> >>> application via UUI, >>> >>>> then the format of that data is likely to be unique. >>>> >>>> Lowering the bar below FCFS would require a naming scheme that >>>> guarantees uniqueness without registration. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: >>>> >>>> All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to >>>> ratify the >>>> "Standards Action" guideline for defining UUI packages and >>>> registering >>>> new IANA elements for the parameter tables for >>>> >>> purpose, encoding and >>> >>>> content. >>>> >>>> The draft authors note that the original concern >>>> >>> when the work >>> >>>> was coming out of Dispatch was that the UUI not >>>> >>> become a "wildcard" >>> >>>> header to be used for a wide variety of purposes. Hence the >>>> direction >>>> toward requiring a standards track RFC. However, a >>>> >>> lesser standard >>> >>>> such as "Specification Required" might suffice and >>>> >>> offer more >>> >>>> flexibility for additional use cases, while not >>>> >>> opening up the >>> >>>> process >>>> totally as would be the case for "First Come First Serve." >>>> >>>> The IESG will like to revisit this decision to >>>> >>> confirm that the WG >>> >>>> decisions remains "Standards Action". >>>> >>>> To that end, Enrico and I will like to open up a >>>> >>> 2-week period >>> >>>> to ratify >>>> this decision to remain at "Standards Action" or to move to >>>> something >>>> other designation. >>>> >>>> The 2-week period ends on close of business (US >>>> >>> Central Time) >>> >>>> April 17, >>>> 2014. Please express an opinion; if you are for >>>> >>> keeping status quo, >>> >>>> please send a one-liner to the cuss WG mailing >>>> >>> list. If you are >>> >>>> of the >>>> opinion that we should relax the burden, please >>>> >>> state so and a short >>> >>>> reason on why we should do so. >>>> >>>> Thank you all. >>>> >>>> - vijay >>>> >>>> >>>> _________________________________________________ >>>> 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 >>> >>> > --047d7b66f33d9083d904f70bc666 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

Keith and I have been discussing = this in terms of new packages, which can define all new SIP semantics, but = I notice in your response you are mainly talking about contents. =C2=A0Perh= aps we could have different requirements for these: the specification requi= red for new packages, but something lower for contents. =C2=A0I'm not c= ompletely sure where encodings would fit in this scheme.

What do you think?

- Alan -


On M= on, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:
On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wro= te:
I believe we would want the guidelines enforced.

I also expect that we would want to do a further review of the guidelines i= f they are the sole basis for allowing packages in or not, before we allowe= d a relaxation of the approval regime.

I think the effect of the registration rules will be that no new registrati= ons are made, and the default will be used by everyone, as is currently the= case. That means that everyone depends upon configuration to ensure that c= lient and server agree on usage.

If you are running a call center, and decide what information you need to c= ommunicate from your IVR to your ACD, are you going to publish an RFC to re= gister the format for that? I think not. Even a FCFS registration is probab= ly too much. Yet it would still be good to ensure that client and server ar= e using the same formats.

When I raised this issue early on, I got no traction for it, so I decided t= o let it go until people had deployment experience. Then they could figure = out they need something different. But now it has come up again.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Regards

Keith

-----Original Message-----
From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 04 April 2014 20:31
To: Alan Johnston
Cc: cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action"
guideline for draft-ietf-cuss-sip-uui

On 4/4/14 12:46 PM, Alan Johnston wrote:
Paul,

I know you've explained this before. =C2=A0But you haven't explaine= d how
the requirements in Section 5. Guidelines for UUI Packages can be
enforced if there isn't any review. =C2=A0Can you elaborate on this?

With no review these couldn't be enforced.
They could still remain as guidelines.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

- Alan -


On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 =C2=A0Interesting to see this come back.

=C2=A0 =C2=A0 =C2=A0My original opinion was (and still is) that for these
to be useful,
=C2=A0 =C2=A0 =C2=A0it must be possible for using enterprises to assign new=
values for
=C2=A0 =C2=A0 =C2=A0each distinct deployment of an application. IMO even
FCFS might be
=C2=A0 =C2=A0 =C2=A0too high a bar for this.

=C2=A0 =C2=A0 =C2=A0E.g., if I create a particular VXML application that
captures some
=C2=A0 =C2=A0 =C2=A0data and communicates it to a call center agent
application via UUI,
=C2=A0 =C2=A0 =C2=A0then the format of that data is likely to be unique.
=C2=A0 =C2=A0 =C2=A0Lowering the bar below FCFS would require a naming sche= me that
=C2=A0 =C2=A0 =C2=A0guarantees uniqueness without registration.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

=C2=A0 =C2=A0 =C2=A0On 4/3/14 6:17 PM, Vijay K. Gurbani wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0All: The IESG has sent draft-ietf-cuss-si= p-uui to the WG to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ratify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Standards Action" guideline fo= r defining UUI packages and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new IANA elements for the parameter table= s for
purpose, encoding and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0content.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft authors note that the original = concern
when the work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was coming out of Dispatch was that the U= UI not
become a "wildcard"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0header to be used for a wide variety of p= urposes. =C2=A0Hence the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0direction
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0toward requiring a standards track RFC. = =C2=A0However, a
lesser standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such as "Specification Required"= ; might suffice and
offer more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flexibility for additional use cases, whi= le not
opening up the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0totally as would be the case for "Fi= rst Come First Serve."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IESG will like to revisit this decisi= on to
confirm that the WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decisions remains "Standards Action&= quot;.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To that end, Enrico and I will like to op= en up a
2-week period
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to ratify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this decision to remain at "Standard= s Action" or to move to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other designation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The 2-week period ends on close of busine= ss (US
Central Time)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0April 17,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02014. =C2=A0Please express an opinion; if= you are for
keeping status quo,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0please send a one-liner to the cuss WG ma= iling
list. =C2=A0If you are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opinion that we should relax the burden, = please
state so and a short
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reason on why we should do so.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you all.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- vijay


=C2=A0 =C2=A0 =C2=A0________________________________________________= _
=C2=A0 =C2=A0 =C2=A0cuss mailing list
=C2=A0 =C2=A0 =C2=A0cuss= @ietf.org <mailto:cuss@ietf.org>
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/__listinfo/cuss=
=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/cuss= >



_______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cuss



--047d7b66f33d9083d904f70bc666-- From nobody Tue Apr 15 01:24:33 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C71A0395 for ; Tue, 15 Apr 2014 01:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU7-EImROuAW for ; Tue, 15 Apr 2014 01:24:28 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B59481A06E0 for ; Tue, 15 Apr 2014 01:24:28 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s3F8OL4x028010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Apr 2014 03:24:22 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s3F8OKNI011862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 10:24:20 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 15 Apr 2014 10:24:20 +0200 From: "DRAGE, Keith (Keith)" To: Alan Johnston , Paul Kyzivat Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui Thread-Index: AQHPT4pBb4V/ZbOWiECsn8iI8uuD3psBZOsAgAAlNICAAC4qgIAE6Y4wgAs6O4CAAAx/AIAAdUjA Date: Tue, 15 Apr 2014 08:24:19 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B187709FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/4OHSR2UZfMTDNwWPLGuQTb2hB_8 Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 08:24:32 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B187709FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the use cse Paul had been giving, I have an assumption that the ISDN pac= kage would be used (because call centers) are connected to the PSTN as well= . This would be effectively a privately defined protocol running over the t= op, and signalled as such. If you want a public protocol (i.e. standardised) running over the top, the= package definition, or any other UUI parameters, could be coupled with the= RFC that defines it. Keith ________________________________ From: Alan Johnston [mailto:alan.b.johnston@gmail.com] Sent: 15 April 2014 03:44 To: Paul Kyzivat Cc: DRAGE, Keith (Keith); cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-= ietf-cuss-sip-uui Paul, Keith and I have been discussing this in terms of new packages, which can d= efine all new SIP semantics, but I notice in your response you are mainly t= alking about contents. Perhaps we could have different requirements for th= ese: the specification required for new packages, but something lower for c= ontents. I'm not completely sure where encodings would fit in this scheme. What do you think? - Alan - On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat > wrote: On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: I believe we would want the guidelines enforced. I also expect that we would want to do a further review of the guidelines i= f they are the sole basis for allowing packages in or not, before we allowe= d a relaxation of the approval regime. I think the effect of the registration rules will be that no new registrati= ons are made, and the default will be used by everyone, as is currently the= case. That means that everyone depends upon configuration to ensure that c= lient and server agree on usage. If you are running a call center, and decide what information you need to c= ommunicate from your IVR to your ACD, are you going to publish an RFC to re= gister the format for that? I think not. Even a FCFS registration is probab= ly too much. Yet it would still be good to ensure that client and server ar= e using the same formats. When I raised this issue early on, I got no traction for it, so I decided t= o let it go until people had deployment experience. Then they could figure = out they need something different. But now it has come up again. Thanks, Paul Regards Keith -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org] On = Behalf Of Paul Kyzivat Sent: 04 April 2014 20:31 To: Alan Johnston Cc: cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui On 4/4/14 12:46 PM, Alan Johnston wrote: Paul, I know you've explained this before. But you haven't explained how the requirements in Section 5. Guidelines for UUI Packages can be enforced if there isn't any review. Can you elaborate on this? With no review these couldn't be enforced. They could still remain as guidelines. Thanks, Paul - Alan - On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat >> wrote: Interesting to see this come back. My original opinion was (and still is) that for these to be useful, it must be possible for using enterprises to assign new values for each distinct deployment of an application. IMO even FCFS might be too high a bar for this. E.g., if I create a particular VXML application that captures some data and communicates it to a call center agent application via UUI, then the format of that data is likely to be unique. Lowering the bar below FCFS would require a naming scheme that guarantees uniqueness without registration. Thanks, Paul On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the "Standards Action" guideline for defining UUI packages and registering new IANA elements for the parameter tables for purpose, encoding and content. The draft authors note that the original concern when the work was coming out of Dispatch was that the UUI not become a "wildcard" header to be used for a wide variety of purposes. Hence the direction toward requiring a standards track RFC. However, a lesser standard such as "Specification Required" might suffice and offer more flexibility for additional use cases, while not opening up the process totally as would be the case for "First Come First Serve." The IESG will like to revisit this decision to confirm that the WG decisions remains "Standards Action". To that end, Enrico and I will like to open up a 2-week period to ratify this decision to remain at "Standards Action" or to move to something other designation. The 2-week period ends on close of business (US Central Time) April 17, 2014. Please express an opinion; if you are for keeping status quo, please send a one-liner to the cuss WG mailing list. If you are of the opinion that we should relax the burden, please state so and a short reason on why we should do so. Thank you all. - vijay _________________________________________________ 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 --_000_949EF20990823C4C85C18D59AA11AD8B187709FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In the use cse Paul had been givi= ng, I have an assumption that the ISDN package would be used (because call = centers) are connected to the PSTN as well. This would be effectively a privately defined protocol running over the to= p, and signalled as such.
 
If you want a public protocol (i.= e. standardised) running over the top, the package definition, or any other= UUI parameters, could be coupled with the RFC that defines it.
 
Keith
 
 

From: Alan Johnston [mailto:alan.b.= johnston@gmail.com]
Sent: 15 April 2014 03:44
To: Paul Kyzivat
Cc: DRAGE, Keith (Keith); cuss@ietf.org
Subject: Re: [cuss] Ratification of "Standards Action" gui= deline for draft-ietf-cuss-sip-uui

Paul,

Keith and I have been discussing this in terms of new packages, which = can define all new SIP semantics, but I notice in your response you are mai= nly talking about contents.  Perhaps we could have different requireme= nts for these: the specification required for new packages, but something lower for contents.  I'm not complete= ly sure where encodings would fit in this scheme.

What do you think?

- Alan -


On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote:
I believe we would want the guidelines enforced.

I also expect that we would want to do a further review of the guidelines i= f they are the sole basis for allowing packages in or not, before we allowe= d a relaxation of the approval regime.

I think the effect of the registration rules will be that no new registrati= ons are made, and the default will be used by everyone, as is currently the= case. That means that everyone depends upon configuration to ensure that c= lient and server agree on usage.

If you are running a call center, and decide what information you need to c= ommunicate from your IVR to your ACD, are you going to publish an RFC to re= gister the format for that? I think not. Even a FCFS registration is probab= ly too much. Yet it would still be good to ensure that client and server are using the same formats.

When I raised this issue early on, I got no traction for it, so I decided t= o let it go until people had deployment experience. Then they could figure = out they need something different. But now it has come up again.

        Thanks,
        Paul

Regards

Keith

-----Original Message-----
From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 04 April 2014 20:31
To: Alan Johnston
Cc: cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action"
guideline for draft-ietf-cuss-sip-uui

On 4/4/14 12:46 PM, Alan Johnston wrote:
Paul,

I know you've explained this before.  But you haven't explained how the requirements in Section 5. Guidelines for UUI Packages can be
enforced if there isn't any review.  Can you elaborate on this?

With no review these couldn't be enforced.
They could still remain as guidelines.

        Thanks,
        Paul

- Alan -


On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

     Interesting to see this come back.

     My original opinion was (and still is) that for these
to be useful,
     it must be possible for using enterprises to assign new=
values for
     each distinct deployment of an application. IMO even
FCFS might be
     too high a bar for this.

     E.g., if I create a particular VXML application that
captures some
     data and communicates it to a call center agent
application via UUI,
     then the format of that data is likely to be unique.
     Lowering the bar below FCFS would require a naming sche= me that
     guarantees uniqueness without registration.

              Thanks,
              Paul

     On 4/3/14 6:17 PM, Vijay K. Gurbani wrote:

         All: The IESG has sent draft-ietf-cuss-si= p-uui to the WG to
         ratify the
         "Standards Action" guideline fo= r defining UUI packages and
         registering
         new IANA elements for the parameter table= s for
purpose, encoding and
         content.

         The draft authors note that the original = concern
when the work
         was coming out of Dispatch was that the U= UI not
become a "wildcard"
         header to be used for a wide variety of p= urposes.  Hence the
         direction
         toward requiring a standards track RFC. &= nbsp;However, a
lesser standard
         such as "Specification Required"= ; might suffice and
offer more
         flexibility for additional use cases, whi= le not
opening up the
         process
         totally as would be the case for "Fi= rst Come First Serve."

         The IESG will like to revisit this decisi= on to
confirm that the WG
         decisions remains "Standards Action&= quot;.

         To that end, Enrico and I will like to op= en up a
2-week period
         to ratify
         this decision to remain at "Standard= s Action" or to move to
         something
         other designation.

         The 2-week period ends on close of busine= ss (US
Central Time)
         April 17,
         2014.  Please express an opinion; if= you are for
keeping status quo,
         please send a one-liner to the cuss WG ma= iling
list.  If you are
         of the
         opinion that we should relax the burden, = please
state so and a short
         reason on why we should do so.

         Thank you all.

         - vijay


     ________________________________________________= _
     cuss mailing list
     cuss= @ietf.org <mailto:cuss@ietf.org>
     https://www.ietf.org/mailman/__listinfo/cuss=
     <https://www.ietf.org/mailman/listinfo/cuss= >



_______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cuss



--_000_949EF20990823C4C85C18D59AA11AD8B187709FR712WXCHMBA11zeu_-- From nobody Tue Apr 15 09:33:07 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B601A07B6 for ; Tue, 15 Apr 2014 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vis-kTg5PJWi for ; Tue, 15 Apr 2014 09:33:04 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D66B91A01BE for ; Tue, 15 Apr 2014 09:33:03 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id qCRX1n0061c6gX855GZ0kB; Tue, 15 Apr 2014 16:33:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id qGZ01n00N3ZTu2S3jGZ0vD; Tue, 15 Apr 2014 16:33:00 +0000 Message-ID: <534D5F3C.40902@alum.mit.edu> Date: Tue, 15 Apr 2014 12:33:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alan Johnston References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397579580; bh=MN5zX1rngc6z4h6EP40WJBHlIuAhTq1ObMUhWRCSm/M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pd2p79Y1HKElNOrbut7aAk6RRfm+SED9pmTroB9CFuBtfM4a7FiKB0Fvs2c+oJb8X nmrdtgy6N5eGwYMCd6tRJome6fb33jik5caO6mE2Eu4mzuJi+xtQSmUOyj6n2auHBP nwZWtWQfrYTZZfhIt9ATMgisEQqhZwEok0+QtX1WQPnxWOxFMCuLYXOF8irqkyBlGR iM6cQXdeng4mTG8qTPL1Fadv6ZnH+YgrliT6I/o+0petvR04zVuSKns+gJvgMy7IC2 q/pjbG/ZUi0epw8ofbDcsj1bBszu6RNjjupjCntb12Ajw5QoufZ1IfbqtRVISBpTbu UO9BKZ4lkyraw== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/cDfJNvTrGvwbY1LuXs2V6gOgT7g Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 16:33:05 -0000 On 4/14/14 10:44 PM, Alan Johnston wrote: > Paul, > > Keith and I have been discussing this in terms of new packages, which > can define all new SIP semantics, but I notice in your response you are > mainly talking about contents. Perhaps we could have different > requirements for these: the specification required for new packages, but > something lower for contents. I'm not completely sure where encodings > would fit in this scheme. > > What do you think? Well, if you want to do anything new then you need to define a new package. That must have a new purpose, and may have new content and/or encoding defs. There is little in the draft that explains how those should be used other than the general meaning of the words "purpose", "content", and "encoding". The draft references the isdn draft as an example, but that isn't very useful for defining something more specific. So one question is where to draw the line between purpose and content. For instance, content might be "CSV", or it might be "CallCenter123.example.com". And purpose might be "CallCenter", or it might be "CallCenter123.example.com". The one that is probably the least volatile is "encoding", since we are talking about encoding of byte strings. We probably won't need a whole lot of those. Maybe "CSV" would be a useful encoding, rather than a content. Or maybe TLV. Unfortunately we haven't set a path, so we are leaving it to others to decide. In my mind, the point is that the combination used in a UUI header ought to be sufficient so that a receiver can determine if it understands what it has received. And I think in general the stuff shared between components of one application deployment won't work with some other application deployment. Thanks, Paul > - Alan - > > > On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat > wrote: > > On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: > > I believe we would want the guidelines enforced. > > I also expect that we would want to do a further review of the > guidelines if they are the sole basis for allowing packages in > or not, before we allowed a relaxation of the approval regime. > > > I think the effect of the registration rules will be that no new > registrations are made, and the default will be used by everyone, as > is currently the case. That means that everyone depends upon > configuration to ensure that client and server agree on usage. > > If you are running a call center, and decide what information you > need to communicate from your IVR to your ACD, are you going to > publish an RFC to register the format for that? I think not. Even a > FCFS registration is probably too much. Yet it would still be good > to ensure that client and server are using the same formats. > > When I raised this issue early on, I got no traction for it, so I > decided to let it go until people had deployment experience. Then > they could figure out they need something different. But now it has > come up again. > > Thanks, > Paul > > Regards > > Keith > > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org > ] On Behalf Of Paul Kyzivat > Sent: 04 April 2014 20:31 > To: Alan Johnston > Cc: cuss@ietf.org > Subject: Re: [cuss] Ratification of "Standards Action" > guideline for draft-ietf-cuss-sip-uui > > On 4/4/14 12:46 PM, Alan Johnston wrote: > > Paul, > > I know you've explained this before. But you haven't > explained how > the requirements in Section 5. Guidelines for UUI > Packages can be > enforced if there isn't any review. Can you elaborate > on this? > > > With no review these couldn't be enforced. > They could still remain as guidelines. > > Thanks, > Paul > > - Alan - > > > On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat > > >__> wrote: > > Interesting to see this come back. > > My original opinion was (and still is) that for these > > to be useful, > > it must be possible for using enterprises to > assign new > > values for > > each distinct deployment of an application. IMO even > > FCFS might be > > too high a bar for this. > > E.g., if I create a particular VXML application that > > captures some > > data and communicates it to a call center agent > > application via UUI, > > then the format of that data is likely to be unique. > > Lowering the bar below FCFS would require a naming > scheme that > guarantees uniqueness without registration. > > Thanks, > Paul > > On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: > > All: The IESG has sent draft-ietf-cuss-sip-uui > to the WG to > ratify the > "Standards Action" guideline for defining UUI > packages and > registering > new IANA elements for the parameter tables for > > purpose, encoding and > > content. > > The draft authors note that the original concern > > when the work > > was coming out of Dispatch was that the UUI not > > become a "wildcard" > > header to be used for a wide variety of > purposes. Hence the > direction > toward requiring a standards track RFC. > However, a > > lesser standard > > such as "Specification Required" might suffice and > > offer more > > flexibility for additional use cases, while not > > opening up the > > process > totally as would be the case for "First Come > First Serve." > > The IESG will like to revisit this decision to > > confirm that the WG > > decisions remains "Standards Action". > > To that end, Enrico and I will like to open up a > > 2-week period > > to ratify > this decision to remain at "Standards Action" > or to move to > something > other designation. > > The 2-week period ends on close of business (US > > Central Time) > > April 17, > 2014. Please express an opinion; if you are for > > keeping status quo, > > please send a one-liner to the cuss WG mailing > > list. If you are > > of the > opinion that we should relax the burden, please > > state so and a short > > reason on why we should do so. > > Thank you all. > > - vijay > > > ___________________________________________________ > 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 nobody Tue Apr 15 12:11:57 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087191A02D0 for ; Tue, 15 Apr 2014 12:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiORsMuwBBmd for ; Tue, 15 Apr 2014 12:11:52 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFE81A016B for ; Tue, 15 Apr 2014 12:11:52 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id qBqZ1n0061ap0As5CKBpRy; Tue, 15 Apr 2014 19:11:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id qKBo1n00a3ZTu2S3iKBoGF; Tue, 15 Apr 2014 19:11:49 +0000 Message-ID: <534D8474.70403@alum.mit.edu> Date: Tue, 15 Apr 2014 15:11:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Alan Johnston References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397589109; bh=Dw1bM/Q7cKQ4zcTp8yc7TvTofm8enQmINw/5H8DYBbU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fi+Je20nLQR88qZOBa9Thdx8uiHyzaHFNtXi17sVV6+2H+TJnhjb0+gl+dQQO8ohb GUlI4sfQrF9Psa9toQ5gNS1rcehNQq1rWFZYI8zQoakoidNh78j8WLd0HoJUPnOKr4 bfG9oapWzf1c+HuRUMjbbo3ZFCOM5cJZhMrPukL40NqlypfJl2tG/P6C8/Wo4wH0WQ TyZVoJZp8lwy32Hn5NSuc0LfOA7qBTlqvuW1IHiwqLxvpE7NjRjUf+f536vaO3rr69 xg5ffCaA5gYpfTc3KXlHmEjBplqkJDVAHxroHR1xf6SbCe1DRPGEP8C7olR65yvy+V jBhqAKJm4fuXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/JBdleYx7rejEWifD2oexd8xokCo Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 19:11:54 -0000 On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote: > In the use cse Paul had been giving, I have an assumption that the ISDN > package would be used (because call centers) are connected to the PSTN > as well. This would be effectively a privately defined protocol running > over the top, and signalled as such. > If you want a public protocol (i.e. standardised) running over the top, > the package definition, or any other UUI parameters, could be coupled > with the RFC that defines it. It doesn't matter if the call center is connected to the PSTN. What matters is the source and destination of the UUI. There is a pretty good chance that those will be connected with sip - probably within the same enterprise. Everybody using the ISDN package is a *problem*, because it has no way to distinguish different usages that don't interoperate. The point I'm making is that most of the usages *won't* be public. (Are there *any* that *are*?) I write a VXML application for my business. It collects some information, and then forwards the call to an ACD, passing the collected information via UUI. The format and purpose of that data is specific to my particular VXML app and the application the call center operators use. Who is going to write an RFC to define that? (Nobody!) If that accidentally ends up at the "wrong" app, how will it be detected that it is wrong? (Hopefully by the purpose and content attributes of the UUI.) How do you imagine purpose and content being used, such that somebody would be in a position to write an RFC to define them? Thanks, Paul > Keith > > ------------------------------------------------------------------------ > *From:* Alan Johnston [mailto:alan.b.johnston@gmail.com] > *Sent:* 15 April 2014 03:44 > *To:* Paul Kyzivat > *Cc:* DRAGE, Keith (Keith); cuss@ietf.org > *Subject:* Re: [cuss] Ratification of "Standards Action" guideline > for draft-ietf-cuss-sip-uui > > Paul, > > Keith and I have been discussing this in terms of new packages, > which can define all new SIP semantics, but I notice in your > response you are mainly talking about contents. Perhaps we could > have different requirements for these: the specification required > for new packages, but something lower for contents. I'm not > completely sure where encodings would fit in this scheme. > > What do you think? > > - Alan - > > > On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat > wrote: > > On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: > > I believe we would want the guidelines enforced. > > I also expect that we would want to do a further review of > the guidelines if they are the sole basis for allowing > packages in or not, before we allowed a relaxation of the > approval regime. > > > I think the effect of the registration rules will be that no new > registrations are made, and the default will be used by > everyone, as is currently the case. That means that everyone > depends upon configuration to ensure that client and server > agree on usage. > > If you are running a call center, and decide what information > you need to communicate from your IVR to your ACD, are you going > to publish an RFC to register the format for that? I think not. > Even a FCFS registration is probably too much. Yet it would > still be good to ensure that client and server are using the > same formats. > > When I raised this issue early on, I got no traction for it, so > I decided to let it go until people had deployment experience. > Then they could figure out they need something different. But > now it has come up again. > > Thanks, > Paul > > Regards > > Keith > > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org > ] On Behalf Of Paul Kyzivat > Sent: 04 April 2014 20:31 > To: Alan Johnston > Cc: cuss@ietf.org > Subject: Re: [cuss] Ratification of "Standards Action" > guideline for draft-ietf-cuss-sip-uui > > On 4/4/14 12:46 PM, Alan Johnston wrote: > > Paul, > > I know you've explained this before. But you > haven't explained how > the requirements in Section 5. Guidelines for UUI > Packages can be > enforced if there isn't any review. Can you > elaborate on this? > > > With no review these couldn't be enforced. > They could still remain as guidelines. > > Thanks, > Paul > > - Alan - > > > On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat > > >__> wrote: > > Interesting to see this come back. > > My original opinion was (and still is) that > for these > > to be useful, > > it must be possible for using enterprises to > assign new > > values for > > each distinct deployment of an application. > IMO even > > FCFS might be > > too high a bar for this. > > E.g., if I create a particular VXML > application that > > captures some > > data and communicates it to a call center agent > > application via UUI, > > then the format of that data is likely to be > unique. > > Lowering the bar below FCFS would require a > naming scheme that > guarantees uniqueness without registration. > > Thanks, > Paul > > On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: > > All: The IESG has sent > draft-ietf-cuss-sip-uui to the WG to > ratify the > "Standards Action" guideline for defining > UUI packages and > registering > new IANA elements for the parameter tables for > > purpose, encoding and > > content. > > The draft authors note that the original > concern > > when the work > > was coming out of Dispatch was that the > UUI not > > become a "wildcard" > > header to be used for a wide variety of > purposes. Hence the > direction > toward requiring a standards track RFC. > However, a > > lesser standard > > such as "Specification Required" might > suffice and > > offer more > > flexibility for additional use cases, > while not > > opening up the > > process > totally as would be the case for "First > Come First Serve." > > The IESG will like to revisit this decision to > > confirm that the WG > > decisions remains "Standards Action". > > To that end, Enrico and I will like to > open up a > > 2-week period > > to ratify > this decision to remain at "Standards > Action" or to move to > something > other designation. > > The 2-week period ends on close of > business (US > > Central Time) > > April 17, > 2014. Please express an opinion; if you > are for > > keeping status quo, > > please send a one-liner to the cuss WG mailing > > list. If you are > > of the > opinion that we should relax the burden, > please > > state so and a short > > reason on why we should do so. > > Thank you all. > > - vijay > > > > ___________________________________________________ > 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 nobody Wed Apr 16 08:20:40 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5931A01D8 for ; Wed, 16 Apr 2014 08:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-3JYygFyXRH for ; Wed, 16 Apr 2014 08:20:32 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF741A01BB for ; Wed, 16 Apr 2014 08:20:32 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id qe321n0081GhbT855fLVlZ; Wed, 16 Apr 2014 15:20:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id qfLU1n00l3ZTu2S3TfLUGf; Wed, 16 Apr 2014 15:20:29 +0000 Message-ID: <534E9FBC.3000508@alum.mit.edu> Date: Wed, 16 Apr 2014 11:20:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: James Rafferty , "'DRAGE, Keith \(Keith\)'" , 'Alan Johnston' References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534D8474.70403@alum.mit.edu> <03fd01cf58f2$03946320$0abd2960$@humancomm.com> In-Reply-To: <03fd01cf58f2$03946320$0abd2960$@humancomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397661629; bh=7fgtGJY7VlF1/FpmWE88hZVxXbrtvx+vWclx6phvLd0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fFMZ4u+2CMYXg8DNO0VhipwVtIC51EzXkgdyYRUgpsspKTf/DjugWYA2f2EWToKBm vEMTwdlAzA5I5Oj/oCrqdV8Zd/LgfEukdWMHOs85WIpkf6yaRCC6yJtp2uu3c5de/M af03ZEivdclX9X61VPMXoLFP8zkRqFMPhddEbQWBf7ZKa6/EOQ0LmysFdQs68gpKOr eT1JJ6rgmT3kRZywCkPOdBc1VVHvvV/cDamaYIga7SJBiSNxKtwyWtoRAvRMT7GzR8 sW/X9F7Bj6CFmfJSx6GTRNT65FKL96dCzqvAbikmj2mxefy9xanET++7tabTB+fMFZ 86+QSzUby2bjw== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/BnBFJdfgZogyN3V1w7JXw6mp-9s Cc: cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 15:20:35 -0000 On 4/15/14 5:30 PM, James Rafferty wrote: > Hi, > > As Alan noted, we seem to be having two discussions here. What I thought > we'd be talking about is what level of IANA action is needed. Recent drafts > set that bar at "Standards Action." I'm personally open to the less > rigorous definition of "Specification Required," which would allow > organizations outside of the IETF to define packages, but would still imply > that the guidelines in Section 5 would continue to be enforced. However, > there hasn't been any discussion about such a middle ground. > > Paul, would lowering the bar to "Specification Required" help offer some of > the flexibility you want? This would allow other packages to be defined -- > inside or outside the IETF -- but would still imply adherence to the > guidelines in section 5. This would also bring a "designated expert" into > play, in order to provide review of the proposed specification. I don't think reducing to "Specification Required" would address my concerns in any way. I don't even think reducing to FCFS would do that. Frankly, *for now* I am satisfied to leave the requirement at Standards Action, with the understanding that this is just temporary to get the basic mechanism (with the ISDN package) published. That allows us to keep control and so prevent something stupid being done. Then I think there should be further discussion about how purpose, content, and encoding *should* be used, and what sorts of registration policies would facilitate that. My thinking is that it should be something like feature tags, with the namespace partitioned, so there can be some values with standardized values, and another part of the namespace that can be used by individual enterprises without need of registration while still preventing collision. > On some of the other points: > > -- Encodings -- I would not expect too many of those to be defined; my > former company supported the current binary definition and an earlier ASCII > encoding Yes. Me too. But it would be useful to have a discussion of what might be other meaningful values. I personally would have liked to also see a "text" (or "ascii" or whatever) encoding. I think many uses would find this sufficient, and it would be much more readable for diagnosing call flows, for examples, etc. Beyond that I don't know. It depends on how the line is drawn between content and encoding. > -- Purpose -- This is the rationale behind having a separate package Once we get beyond ISDN, I see Purpose as being the primary mechanism for ensuring that sender and receiver are compatible. > -- Content -- allows for further elaboration on what kinds of semantic > information are supported; see section 5.1 on extensibility I think it is likely that there would be only one content per purpose, and so it will be redundant. OTOH, the purpose could be treated as a sort of interface, with the content naming individual messages within the interface. Thanks, Paul > James > > > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, April 15, 2014 3:12 PM > To: DRAGE, Keith (Keith); Alan Johnston > Cc: cuss@ietf.org > Subject: Re: [cuss] Ratification of "Standards Action" guideline for > draft-ietf-cuss-sip-uui > > On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote: >> In the use cse Paul had been giving, I have an assumption that the >> ISDN package would be used (because call centers) are connected to the >> PSTN as well. This would be effectively a privately defined protocol >> running over the top, and signalled as such. >> If you want a public protocol (i.e. standardised) running over the >> top, the package definition, or any other UUI parameters, could be >> coupled with the RFC that defines it. > > It doesn't matter if the call center is connected to the PSTN. What matters > is the source and destination of the UUI. There is a pretty good chance that > those will be connected with sip - probably within the same enterprise. > > Everybody using the ISDN package is a *problem*, because it has no way to > distinguish different usages that don't interoperate. > > The point I'm making is that most of the usages *won't* be public. (Are > there *any* that *are*?) > > I write a VXML application for my business. It collects some information, > and then forwards the call to an ACD, passing the collected information via > UUI. The format and purpose of that data is specific to my particular VXML > app and the application the call center operators use. Who is going to write > an RFC to define that? (Nobody!) If that accidentally ends up at the "wrong" > app, how will it be detected that it is wrong? (Hopefully by the purpose and > content attributes of the UUI.) > > How do you imagine purpose and content being used, such that somebody would > be in a position to write an RFC to define them? > > Thanks, > Paul > >> Keith >> >> > ------------------------------------------------------------------------ >> *From:* Alan Johnston [mailto:alan.b.johnston@gmail.com] >> *Sent:* 15 April 2014 03:44 >> *To:* Paul Kyzivat >> *Cc:* DRAGE, Keith (Keith); cuss@ietf.org >> *Subject:* Re: [cuss] Ratification of "Standards Action" guideline >> for draft-ietf-cuss-sip-uui >> >> Paul, >> >> Keith and I have been discussing this in terms of new packages, >> which can define all new SIP semantics, but I notice in your >> response you are mainly talking about contents. Perhaps we could >> have different requirements for these: the specification required >> for new packages, but something lower for contents. I'm not >> completely sure where encodings would fit in this scheme. >> >> What do you think? >> >> - Alan - >> >> >> On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat > > wrote: >> >> On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: >> >> I believe we would want the guidelines enforced. >> >> I also expect that we would want to do a further review of >> the guidelines if they are the sole basis for allowing >> packages in or not, before we allowed a relaxation of the >> approval regime. >> >> >> I think the effect of the registration rules will be that no new >> registrations are made, and the default will be used by >> everyone, as is currently the case. That means that everyone >> depends upon configuration to ensure that client and server >> agree on usage. >> >> If you are running a call center, and decide what information >> you need to communicate from your IVR to your ACD, are you going >> to publish an RFC to register the format for that? I think not. >> Even a FCFS registration is probably too much. Yet it would >> still be good to ensure that client and server are using the >> same formats. >> >> When I raised this issue early on, I got no traction for it, so >> I decided to let it go until people had deployment experience. >> Then they could figure out they need something different. But >> now it has come up again. >> >> Thanks, >> Paul >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: cuss [mailto:cuss-bounces@ietf.org >> ] On Behalf Of Paul Kyzivat >> Sent: 04 April 2014 20:31 >> To: Alan Johnston >> Cc: cuss@ietf.org >> Subject: Re: [cuss] Ratification of "Standards Action" >> guideline for draft-ietf-cuss-sip-uui >> >> On 4/4/14 12:46 PM, Alan Johnston wrote: >> >> Paul, >> >> I know you've explained this before. But you >> haven't explained how >> the requirements in Section 5. Guidelines for UUI >> Packages can be >> enforced if there isn't any review. Can you >> elaborate on this? >> >> >> With no review these couldn't be enforced. >> They could still remain as guidelines. >> >> Thanks, >> Paul >> >> - Alan - >> >> >> On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat >> >> > >__> wrote: >> >> Interesting to see this come back. >> >> My original opinion was (and still is) that >> for these >> >> to be useful, >> >> it must be possible for using enterprises to >> assign new >> >> values for >> >> each distinct deployment of an application. >> IMO even >> >> FCFS might be >> >> too high a bar for this. >> >> E.g., if I create a particular VXML >> application that >> >> captures some >> >> data and communicates it to a call center >> agent >> >> application via UUI, >> >> then the format of that data is likely to be >> unique. >> >> Lowering the bar below FCFS would require a >> naming scheme that >> guarantees uniqueness without registration. >> >> Thanks, >> Paul >> >> On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: >> >> All: The IESG has sent >> draft-ietf-cuss-sip-uui to the WG to >> ratify the >> "Standards Action" guideline for defining >> UUI packages and >> registering >> new IANA elements for the parameter >> tables for >> >> purpose, encoding and >> >> content. >> >> The draft authors note that the original >> concern >> >> when the work >> >> was coming out of Dispatch was that the >> UUI not >> >> become a "wildcard" >> >> header to be used for a wide variety of >> purposes. Hence the >> direction >> toward requiring a standards track RFC. >> However, a >> >> lesser standard >> >> such as "Specification Required" might >> suffice and >> >> offer more >> >> flexibility for additional use cases, >> while not >> >> opening up the >> >> process >> totally as would be the case for "First >> Come First Serve." >> >> The IESG will like to revisit this >> decision to >> >> confirm that the WG >> >> decisions remains "Standards Action". >> >> To that end, Enrico and I will like to >> open up a >> >> 2-week period >> >> to ratify >> this decision to remain at "Standards >> Action" or to move to >> something >> other designation. >> >> The 2-week period ends on close of >> business (US >> >> Central Time) >> >> April 17, >> 2014. Please express an opinion; if you >> are for >> >> keeping status quo, >> >> please send a one-liner to the cuss WG >> mailing >> >> list. If you are >> >> of the >> opinion that we should relax the burden, >> please >> >> state so and a short >> >> reason on why we should do so. >> >> Thank you all. >> >> - vijay >> >> >> >> ___________________________________________________ >> 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 nobody Wed Apr 16 09:12:02 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F401A0176 for ; Wed, 16 Apr 2014 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FisrJOlMVCDY for ; Wed, 16 Apr 2014 09:11:52 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 95F911A014B for ; Wed, 16 Apr 2014 09:11:51 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so11187859wes.28 for ; Wed, 16 Apr 2014 09:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oVm2MpttJvYQGLslibUPeVJc9a7PFMTrDVUQ9m9n2+c=; b=ECGwOcm0gHwGnh6bp3TXSHNFuPk2TWIxlWScQU+ZZ13k0QUrhZXdDDebPgQqn6dVzx 8sk0vXytFABx7RN2fJplAacpS6xuSVc80OyGSyZ4Os3YzieD+dWS+ktxo8NDJaPpvTb5 7SCzaH1iMYbODBoPBsKFYpoVC5w27kYsDx7kzQyGlSmP2I3rtML+Znil1AHoBtJIDYdB AMZVhC43k2KuT9VT9ZKSxt1s01C8WVp+u9y8XcONZ4A4Gkt4WZnQMIuhZgGaDaVkm4zY AjAg8nNw45fOxmfm/BjmqMXYR0OupGkX8GPrgbJWpHleQ5jNK5yB+zk9OYS1+mSB/GWy 0mlA== MIME-Version: 1.0 X-Received: by 10.194.109.6 with SMTP id ho6mr7827677wjb.21.1397664707912; Wed, 16 Apr 2014 09:11:47 -0700 (PDT) Received: by 10.217.152.10 with HTTP; Wed, 16 Apr 2014 09:11:47 -0700 (PDT) In-Reply-To: <534E9FBC.3000508@alum.mit.edu> References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534D8474.70403@alum.mit.edu> <03fd01cf58f2$03946320$0abd2960$@humancomm.com> <534E9FBC.3000508@alum.mit.edu> Date: Wed, 16 Apr 2014 11:11:47 -0500 Message-ID: From: Alan Johnston To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bf10b506e2a8404f72b2c07 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/wHWxrh0sZnUVRe7Z0g3Z1m61srk Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 16:11:57 -0000 --047d7bf10b506e2a8404f72b2c07 Content-Type: text/plain; charset=UTF-8 Paul, So we are in agreement, then. Keep this draft at Standards Action for new packages so we can keep control over how this mechanism is used. Your proposal sounds very interesting for opening things up, and if published as a standards track document would allow for exactly what you want. - Alan - On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat wrote: > On 4/15/14 5:30 PM, James Rafferty wrote: > >> Hi, >> >> As Alan noted, we seem to be having two discussions here. What I thought >> we'd be talking about is what level of IANA action is needed. Recent >> drafts >> set that bar at "Standards Action." I'm personally open to the less >> rigorous definition of "Specification Required," which would allow >> organizations outside of the IETF to define packages, but would still >> imply >> that the guidelines in Section 5 would continue to be enforced. However, >> there hasn't been any discussion about such a middle ground. >> >> Paul, would lowering the bar to "Specification Required" help offer some >> of >> the flexibility you want? This would allow other packages to be defined >> -- >> inside or outside the IETF -- but would still imply adherence to the >> guidelines in section 5. This would also bring a "designated expert" into >> play, in order to provide review of the proposed specification. >> > > I don't think reducing to "Specification Required" would address my > concerns in any way. I don't even think reducing to FCFS would do that. > > Frankly, *for now* I am satisfied to leave the requirement at Standards > Action, with the understanding that this is just temporary to get the basic > mechanism (with the ISDN package) published. That allows us to keep control > and so prevent something stupid being done. > > Then I think there should be further discussion about how purpose, > content, and encoding *should* be used, and what sorts of registration > policies would facilitate that. > > My thinking is that it should be something like feature tags, with the > namespace partitioned, so there can be some values with standardized > values, and another part of the namespace that can be used by individual > enterprises without need of registration while still preventing collision. > > On some of the other points: >> >> -- Encodings -- I would not expect too many of those to be defined; my >> former company supported the current binary definition and an earlier >> ASCII >> encoding >> > > Yes. Me too. But it would be useful to have a discussion of what might be > other meaningful values. > > I personally would have liked to also see a "text" (or "ascii" or > whatever) encoding. I think many uses would find this sufficient, and it > would be much more readable for diagnosing call flows, for examples, etc. > > Beyond that I don't know. It depends on how the line is drawn between > content and encoding. > > -- Purpose -- This is the rationale behind having a separate package >> > > Once we get beyond ISDN, I see Purpose as being the primary mechanism for > ensuring that sender and receiver are compatible. > > -- Content -- allows for further elaboration on what kinds of semantic >> information are supported; see section 5.1 on extensibility >> > > I think it is likely that there would be only one content per purpose, and > so it will be redundant. OTOH, the purpose could be treated as a sort of > interface, with the content naming individual messages within the interface. > > Thanks, > Paul > > James >> >> >> -----Original Message----- >> From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Tuesday, April 15, 2014 3:12 PM >> To: DRAGE, Keith (Keith); Alan Johnston >> Cc: cuss@ietf.org >> Subject: Re: [cuss] Ratification of "Standards Action" guideline for >> draft-ietf-cuss-sip-uui >> >> On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote: >> >>> In the use cse Paul had been giving, I have an assumption that the >>> ISDN package would be used (because call centers) are connected to the >>> PSTN as well. This would be effectively a privately defined protocol >>> running over the top, and signalled as such. >>> If you want a public protocol (i.e. standardised) running over the >>> top, the package definition, or any other UUI parameters, could be >>> coupled with the RFC that defines it. >>> >> >> It doesn't matter if the call center is connected to the PSTN. What >> matters >> is the source and destination of the UUI. There is a pretty good chance >> that >> those will be connected with sip - probably within the same enterprise. >> >> Everybody using the ISDN package is a *problem*, because it has no way to >> distinguish different usages that don't interoperate. >> >> The point I'm making is that most of the usages *won't* be public. (Are >> there *any* that *are*?) >> >> I write a VXML application for my business. It collects some information, >> and then forwards the call to an ACD, passing the collected information >> via >> UUI. The format and purpose of that data is specific to my particular VXML >> app and the application the call center operators use. Who is going to >> write >> an RFC to define that? (Nobody!) If that accidentally ends up at the >> "wrong" >> app, how will it be detected that it is wrong? (Hopefully by the purpose >> and >> content attributes of the UUI.) >> >> How do you imagine purpose and content being used, such that somebody >> would >> be in a position to write an RFC to define them? >> >> Thanks, >> Paul >> >> Keith >>> >>> >>> ------------------------------------------------------------ >> ------------ >> >>> *From:* Alan Johnston [mailto:alan.b.johnston@gmail.com] >>> *Sent:* 15 April 2014 03:44 >>> *To:* Paul Kyzivat >>> *Cc:* DRAGE, Keith (Keith); cuss@ietf.org >>> *Subject:* Re: [cuss] Ratification of "Standards Action" guideline >>> for draft-ietf-cuss-sip-uui >>> >>> Paul, >>> >>> Keith and I have been discussing this in terms of new packages, >>> which can define all new SIP semantics, but I notice in your >>> response you are mainly talking about contents. Perhaps we could >>> have different requirements for these: the specification required >>> for new packages, but something lower for contents. I'm not >>> completely sure where encodings would fit in this scheme. >>> >>> What do you think? >>> >>> - Alan - >>> >>> >>> On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat < >>> pkyzivat@alum.mit.edu >>> > wrote: >>> >>> On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: >>> >>> I believe we would want the guidelines enforced. >>> >>> I also expect that we would want to do a further review of >>> the guidelines if they are the sole basis for allowing >>> packages in or not, before we allowed a relaxation of the >>> approval regime. >>> >>> >>> I think the effect of the registration rules will be that no new >>> registrations are made, and the default will be used by >>> everyone, as is currently the case. That means that everyone >>> depends upon configuration to ensure that client and server >>> agree on usage. >>> >>> If you are running a call center, and decide what information >>> you need to communicate from your IVR to your ACD, are you going >>> to publish an RFC to register the format for that? I think not. >>> Even a FCFS registration is probably too much. Yet it would >>> still be good to ensure that client and server are using the >>> same formats. >>> >>> When I raised this issue early on, I got no traction for it, so >>> I decided to let it go until people had deployment experience. >>> Then they could figure out they need something different. But >>> now it has come up again. >>> >>> Thanks, >>> Paul >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: cuss [mailto:cuss-bounces@ietf.org >>> ] On Behalf Of Paul >>> Kyzivat >>> Sent: 04 April 2014 20:31 >>> To: Alan Johnston >>> Cc: cuss@ietf.org >>> Subject: Re: [cuss] Ratification of "Standards Action" >>> guideline for draft-ietf-cuss-sip-uui >>> >>> On 4/4/14 12:46 PM, Alan Johnston wrote: >>> >>> Paul, >>> >>> I know you've explained this before. But you >>> haven't explained how >>> the requirements in Section 5. Guidelines for UUI >>> Packages can be >>> enforced if there isn't any review. Can you >>> elaborate on this? >>> >>> >>> With no review these couldn't be enforced. >>> They could still remain as guidelines. >>> >>> Thanks, >>> Paul >>> >>> - Alan - >>> >>> >>> On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat >>> >> pkyzivat@alum.mit.edu> >>> >> >__> wrote: >>> >>> Interesting to see this come back. >>> >>> My original opinion was (and still is) that >>> for these >>> >>> to be useful, >>> >>> it must be possible for using enterprises to >>> assign new >>> >>> values for >>> >>> each distinct deployment of an application. >>> IMO even >>> >>> FCFS might be >>> >>> too high a bar for this. >>> >>> E.g., if I create a particular VXML >>> application that >>> >>> captures some >>> >>> data and communicates it to a call center >>> agent >>> >>> application via UUI, >>> >>> then the format of that data is likely to be >>> unique. >>> >>> Lowering the bar below FCFS would require a >>> naming scheme that >>> guarantees uniqueness without registration. >>> >>> Thanks, >>> Paul >>> >>> On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: >>> >>> All: The IESG has sent >>> draft-ietf-cuss-sip-uui to the WG to >>> ratify the >>> "Standards Action" guideline for defining >>> UUI packages and >>> registering >>> new IANA elements for the parameter >>> tables for >>> >>> purpose, encoding and >>> >>> content. >>> >>> The draft authors note that the original >>> concern >>> >>> when the work >>> >>> was coming out of Dispatch was that the >>> UUI not >>> >>> become a "wildcard" >>> >>> header to be used for a wide variety of >>> purposes. Hence the >>> direction >>> toward requiring a standards track RFC. >>> However, a >>> >>> lesser standard >>> >>> such as "Specification Required" might >>> suffice and >>> >>> offer more >>> >>> flexibility for additional use cases, >>> while not >>> >>> opening up the >>> >>> process >>> totally as would be the case for "First >>> Come First Serve." >>> >>> The IESG will like to revisit this >>> decision to >>> >>> confirm that the WG >>> >>> decisions remains "Standards Action". >>> >>> To that end, Enrico and I will like to >>> open up a >>> >>> 2-week period >>> >>> to ratify >>> this decision to remain at "Standards >>> Action" or to move to >>> something >>> other designation. >>> >>> The 2-week period ends on close of >>> business (US >>> >>> Central Time) >>> >>> April 17, >>> 2014. Please express an opinion; if you >>> are for >>> >>> keeping status quo, >>> >>> please send a one-liner to the cuss WG >>> mailing >>> >>> list. If you are >>> >>> of the >>> opinion that we should relax the burden, >>> please >>> >>> state so and a short >>> >>> reason on why we should do so. >>> >>> Thank you all. >>> >>> - vijay >>> >>> >>> >>> ______________________________ >>> _____________________ >>> 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 >> >> >> > --047d7bf10b506e2a8404f72b2c07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

So we are in agreement, then. =C2= =A0Keep this draft at Standards Action for new packages so we can keep cont= rol over how this mechanism is used.

Your proposal= sounds very interesting for opening things up, and if published as a stand= ards track document would allow for exactly what you want.

- Alan -


On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat <p= kyzivat@alum.mit.edu> wrote:
On 4/15/14 5:30 PM, James Rafferty wrote:
Hi,

As Alan noted, we seem to be having two discussions here. =C2=A0What I thou= ght
we'd be talking about is what level of IANA action is needed. =C2=A0Rec= ent drafts
set that bar at "Standards Action." =C2=A0I'm personally open= to the less
rigorous definition of "Specification Required," which would allo= w
organizations outside of the IETF to define packages, but would still imply=
that the guidelines in Section 5 would continue to be enforced. =C2=A0Howev= er,
there hasn't been any discussion about such a middle ground.

Paul, would lowering the bar to "Specification Required" help off= er some of
the flexibility you want? =C2=A0This would allow other packages to be defin= ed --
inside or outside the IETF -- but would still imply adherence to the
guidelines in section 5. =C2=A0This would also bring a "designated exp= ert" into
play, in order to provide review of the proposed specification.

I don't think reducing to "Specification Required" would addr= ess my concerns in any way. I don't even think reducing to FCFS would d= o that.

Frankly, *for now* I am satisfied to leave the requirement at Standards Act= ion, with the understanding that this is just temporary to get the basic me= chanism (with the ISDN package) published. That allows us to keep control a= nd so prevent something stupid being done.

Then I think there should be further discussion about how purpose, content,= and encoding *should* be used, and what sorts of registration policies wou= ld facilitate that.

My thinking is that it should be something like feature tags, with the name= space partitioned, so there can be some values with standardized values, an= d another part of the namespace that can be used by individual enterprises = without need of registration while still preventing collision.

On some of the other points:

-- Encodings -- I would not expect too many of those to be defined; my
former company =C2=A0supported the current binary definition and an earlier= ASCII
encoding

Yes. Me too. But it would be useful to have a discussion of what might be o= ther meaningful values.

I personally would have liked to also see a "text" (or "asci= i" or whatever) encoding. I think many uses would find this sufficient= , and it would be much more readable for diagnosing call flows, for example= s, etc.

Beyond that I don't know. It depends on how the line is drawn between c= ontent and encoding.

-- Purpose -- This is the rationale behind having a separate package

Once we get beyond ISDN, I see Purpose as being the primary mechanism for e= nsuring that sender and receiver are compatible.

-- Content -- allows for further elaboration on what kinds of semantic
information are supported; see section 5.1 on extensibility

I think it is likely that there would be only one content per purpose, and = so it will be redundant. OTOH, the purpose could be treated as a sort of in= terface, with the content naming individual messages within the interface.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

James


-----Original Message-----
From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Tuesday, April 15, 2014 3:12 PM
To: DRAGE, Keith (Keith); Alan Johnston
Cc: cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action" guideline = for
draft-ietf-cuss-sip-uui

On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote:
In the use cse Paul had been giving, I have an assumption that the
ISDN package would be used (because call centers) are connected to the
PSTN as well. This would be effectively a privately defined protocol
running over the top, and signalled as such.
If you want a public protocol (i.e. standardised) running over the
top, the package definition, or any other UUI parameters, could be
coupled with the RFC that defines it.

It doesn't matter if the call center is connected to the PSTN. What mat= ters
is the source and destination of the UUI. There is a pretty good chance tha= t
those will be connected with sip - probably within the same enterprise.

Everybody using the ISDN package is a *problem*, because it has no way to distinguish different usages that don't interoperate.

The point I'm making is that most of the usages *won't* be public. = (Are
there *any* that *are*?)

I write a VXML application for my business. It collects some information, and then forwards the call to an ACD, passing the collected information via=
UUI. The format and purpose of that data is specific to my particular VXML<= br> app and the application the call center operators use. Who is going to writ= e
an RFC to define that? (Nobody!) If that accidentally ends up at the "= wrong"
app, how will it be detected that it is wrong? (Hopefully by the purpose an= d
content attributes of the UUI.)

How do you imagine purpose and content being used, such that somebody would=
be in a position to write an RFC to define them?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Keith


-------------------------------------------------------------= -----------
=C2=A0 =C2=A0 =C2=A0*From:* Alan Johnston [mailto:alan.b.johnston@gmail.com]=
=C2=A0 =C2=A0 =C2=A0*Sent:* 15 April 2014 03:44
=C2=A0 =C2=A0 =C2=A0*To:* Paul Kyzivat
=C2=A0 =C2=A0 =C2=A0*Cc:* DRAGE, Keith (Keith); cuss@ietf.org
=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [cuss] Ratification of "Standards A= ction" guideline
=C2=A0 =C2=A0 =C2=A0for draft-ietf-cuss-sip-uui

=C2=A0 =C2=A0 =C2=A0Paul,

=C2=A0 =C2=A0 =C2=A0Keith and I have been discussing this in terms of new p= ackages,
=C2=A0 =C2=A0 =C2=A0which can define all new SIP semantics, but I notice in= your
=C2=A0 =C2=A0 =C2=A0response you are mainly talking about contents. =C2=A0P= erhaps we could
=C2=A0 =C2=A0 =C2=A0have different requirements for these: the specificatio= n required
=C2=A0 =C2=A0 =C2=A0for new packages, but something lower for contents. =C2= =A0I'm not
=C2=A0 =C2=A0 =C2=A0completely sure where encodings would fit in this schem= e.

=C2=A0 =C2=A0 =C2=A0What do you think?

=C2=A0 =C2=A0 =C2=A0- Alan -


=C2=A0 =C2=A0 =C2=A0On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <pkyzivat@alum.mit.edu=
=C2=A0 =C2=A0 =C2=A0<mailto:pkyzivat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 4/14/14 9:36 PM, DRAGE, Keith (Keith) = wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I believe we would want the= guidelines enforced.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also expect that we would= want to do a further review of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the guidelines if they are = the sole basis for allowing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packages in or not, before = we allowed a relaxation of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0approval regime.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think the effect of the registration ru= les will be that no new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registrations are made, and the default w= ill be used by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0everyone, as is currently the case. That = means that everyone
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0depends upon configuration to ensure that= client and server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0agree on usage.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If you are running a call center, and dec= ide what information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you need to communicate from your IVR to = your ACD, are you going
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to publish an RFC to register the format = for that? I think not.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Even a FCFS registration is probably too = much. Yet it would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0still be good to ensure that client and s= erver are using the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same formats.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When I raised this issue early on, I got = no traction for it, so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I decided to let it go until people had d= eployment experience.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Then they could figure out they need some= thing different. But
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now it has come up again.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keith

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Original= Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: cuss [m= ailto:cuss-bounc= es@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:cuss-bounces@ietf.= org>] On Behalf Of Paul Kyzivat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: 04 Apri= l 2014 20:31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Alan John= ston
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cc: cuss@ietf.org <mailto:cuss@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: = [cuss] Ratification of "Standards Action"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0guideline for= draft-ietf-cuss-sip-uui

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 4/4/14 12:= 46 PM, Alan Johnston wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Paul,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I know you've explained this before. =C2=A0But you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0haven't explained how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0the requirements in Section 5. Guidelines for UUI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Packages can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0enforced if there isn't any review. =C2=A0Can you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0elaborate on this?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0With no revie= w these couldn't be enforced.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0They could st= ill remain as guidelines.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- Alan -


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<pkyzivat@= alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:pk= yzivat@alum.mit.edu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:pk= yzivat@alum.mit.edu>>__> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Interesting to see this come back.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0My original opinion was (and still is) that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0for these

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be useful,=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0it must be possible for using enterprises to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0assign new

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0values for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0each distinct deployment of an application.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0IMO even

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FCFS might be=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0too high a bar for this.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0E.g., if I create a particular VXML
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0application that

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0captures some=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0data and communicates it to a call center
agent

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application v= ia UUI,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0then the format of that data is likely to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0unique.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Lowering the bar below FCFS would require a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0naming scheme that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0guarantees uniqueness without registration.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0On 4/3/14 6:17 PM, Vijay K. Gurbani wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0All: The IESG has sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0draft-ietf-cuss-sip-uui to the WG to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ratify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Standards Action" guidelin= e for defining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0UUI packages and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new IANA elements for the parameter tables for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0purpose, enco= ding and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0content.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft authors note that the origi= nal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0concern

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when the work=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was coming out of Dispatch was that t= he
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0UUI not

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0become a &quo= t;wildcard"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0header to be used for a wide variety = of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0purposes. =C2=A0Hence the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0direction
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0toward requiring a standards track RF= C.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0However, a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lesser standa= rd

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such as "Specification Required&= quot; might
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0suffice and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offer more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flexibility for additional use cases,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0while not

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opening up th= e

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0totally as would be the case for &quo= t;First
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Come First Serve."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IESG will like to revisit this decision to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confirm that = the WG

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decisions remains "Standards Act= ion".

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To that end, Enrico and I will like t= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0open up a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02-week period=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to ratify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this decision to remain at "Stan= dards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Action" or to move to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other designation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The 2-week period ends on close of =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0business (US

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Central Time)=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0April 17,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02014. =C2=A0Please express an opinion= ; if you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keeping statu= s quo,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0please send a one-liner to the cuss W= G
mailing

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list. =C2=A0I= f you are

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opinion that we should relax the burd= en,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0please

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state so and = a short

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reason on why we should do so.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you all.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- vijay



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0___________________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0cuss mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0cuss@ietf.org <= ;mailto:cuss@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:cuss@ietf.= org <mailto:cuss@= ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0https://www.ietf.org/mailman/____listinfo/cuss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.ietf.org/mailman/__listinfo/cuss>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/__listinfo/= cuss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.ietf.org/mailman/listinfo/cuss>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________= ____________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cuss mailing = list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cuss@ietf.org <mailto:cuss@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/mailman/__listinfo/cuss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://w= ww.ietf.org/mailman/listinfo/cuss>




_______________________________________________
cuss mailing list
cuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cuss




--047d7bf10b506e2a8404f72b2c07-- From nobody Wed Apr 16 09:45:56 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A281A1A0272 for ; Wed, 16 Apr 2014 09:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJK0IwTbhcKD for ; Wed, 16 Apr 2014 09:45:52 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id CC8731A0273 for ; Wed, 16 Apr 2014 09:45:50 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id qcpp1n0091ei1Bg53glnNN; Wed, 16 Apr 2014 16:45:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id qglm1n00g3ZTu2S3kglnfE; Wed, 16 Apr 2014 16:45:47 +0000 Message-ID: <534EB3BA.6070504@alum.mit.edu> Date: Wed, 16 Apr 2014 12:45:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alan Johnston References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534D8474.70403@alum.mit.edu> <03fd01cf58f2$03946320$0abd2960$@humancomm.com> <534E9FBC.3000508@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397666747; bh=LSIHng2qORVjgebFOy7mZZd1DmDPzqiIchWTtXsor44=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H6GfiZPafxi9lpb1f8eS1UGo2N6DPtbSQ38vaik/0C85s5AWI7sEJV5yDNDTGJcDN 7MAM7Q9IDuqFpFabodkPGpkYHHcAEGUWKFcUVZJpsY+uqP6iT6H0fvjtm3fofrUtyo /97oUSnBuZNdA20iuaJwlR7khjj8vWOp7NjfEU+axvbi11eVZOMaVHmDJMKjVibwiJ 7YxLH8RHEbLfjN7DrKZAYt9vOhcj0/YaTNS5qpdGYow7rKMbiWTLyP+ozDqZqHtQSx fMa5WCJoBLwCEME+Ta9zOVOBcAUagUlLT2XDAiRlq/16Ps9ygSnML0ck8XFD2M0s7D 7X/Izc+ncaOFA== Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/YBkE4O2nO5Dd19a1trVY_DmFhSU Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 16:45:54 -0000 On 4/16/14 12:11 PM, Alan Johnston wrote: > Paul, > > So we are in agreement, then. Keep this draft at Standards Action for > new packages so we can keep control over how this mechanism is used. > > Your proposal sounds very interesting for opening things up, and if > published as a standards track document would allow for exactly what you > want. Perhaps, to resolve the IESG concern over the use of Standards Action, we could add some text indicating that this is conservative choice made while we if and how to open it up. Thanks, Paul > - Alan - > > > On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat > wrote: > > On 4/15/14 5:30 PM, James Rafferty wrote: > > Hi, > > As Alan noted, we seem to be having two discussions here. What > I thought > we'd be talking about is what level of IANA action is needed. > Recent drafts > set that bar at "Standards Action." I'm personally open to the less > rigorous definition of "Specification Required," which would allow > organizations outside of the IETF to define packages, but would > still imply > that the guidelines in Section 5 would continue to be enforced. > However, > there hasn't been any discussion about such a middle ground. > > Paul, would lowering the bar to "Specification Required" help > offer some of > the flexibility you want? This would allow other packages to be > defined -- > inside or outside the IETF -- but would still imply adherence to the > guidelines in section 5. This would also bring a "designated > expert" into > play, in order to provide review of the proposed specification. > > > I don't think reducing to "Specification Required" would address my > concerns in any way. I don't even think reducing to FCFS would do that. > > Frankly, *for now* I am satisfied to leave the requirement at > Standards Action, with the understanding that this is just temporary > to get the basic mechanism (with the ISDN package) published. That > allows us to keep control and so prevent something stupid being done. > > Then I think there should be further discussion about how purpose, > content, and encoding *should* be used, and what sorts of > registration policies would facilitate that. > > My thinking is that it should be something like feature tags, with > the namespace partitioned, so there can be some values with > standardized values, and another part of the namespace that can be > used by individual enterprises without need of registration while > still preventing collision. > > On some of the other points: > > -- Encodings -- I would not expect too many of those to be > defined; my > former company supported the current binary definition and an > earlier ASCII > encoding > > > Yes. Me too. But it would be useful to have a discussion of what > might be other meaningful values. > > I personally would have liked to also see a "text" (or "ascii" or > whatever) encoding. I think many uses would find this sufficient, > and it would be much more readable for diagnosing call flows, for > examples, etc. > > Beyond that I don't know. It depends on how the line is drawn > between content and encoding. > > -- Purpose -- This is the rationale behind having a separate package > > > Once we get beyond ISDN, I see Purpose as being the primary > mechanism for ensuring that sender and receiver are compatible. > > -- Content -- allows for further elaboration on what kinds of > semantic > information are supported; see section 5.1 on extensibility > > > I think it is likely that there would be only one content per > purpose, and so it will be redundant. OTOH, the purpose could be > treated as a sort of interface, with the content naming individual > messages within the interface. > > Thanks, > Paul > > James > > > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org > ] On Behalf Of Paul Kyzivat > Sent: Tuesday, April 15, 2014 3:12 PM > To: DRAGE, Keith (Keith); Alan Johnston > Cc: cuss@ietf.org > Subject: Re: [cuss] Ratification of "Standards Action" guideline for > draft-ietf-cuss-sip-uui > > On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote: > > In the use cse Paul had been giving, I have an assumption > that the > ISDN package would be used (because call centers) are > connected to the > PSTN as well. This would be effectively a privately defined > protocol > running over the top, and signalled as such. > If you want a public protocol (i.e. standardised) running > over the > top, the package definition, or any other UUI parameters, > could be > coupled with the RFC that defines it. > > > It doesn't matter if the call center is connected to the PSTN. > What matters > is the source and destination of the UUI. There is a pretty good > chance that > those will be connected with sip - probably within the same > enterprise. > > Everybody using the ISDN package is a *problem*, because it has > no way to > distinguish different usages that don't interoperate. > > The point I'm making is that most of the usages *won't* be > public. (Are > there *any* that *are*?) > > I write a VXML application for my business. It collects some > information, > and then forwards the call to an ACD, passing the collected > information via > UUI. The format and purpose of that data is specific to my > particular VXML > app and the application the call center operators use. Who is > going to write > an RFC to define that? (Nobody!) If that accidentally ends up at > the "wrong" > app, how will it be detected that it is wrong? (Hopefully by the > purpose and > content attributes of the UUI.) > > How do you imagine purpose and content being used, such that > somebody would > be in a position to write an RFC to define them? > > Thanks, > Paul > > Keith > > > ------------------------------__------------------------------__------------ > > *From:* Alan Johnston > [mailto:alan.b.johnston@gmail.__com > ] > *Sent:* 15 April 2014 03:44 > *To:* Paul Kyzivat > *Cc:* DRAGE, Keith (Keith); cuss@ietf.org > > *Subject:* Re: [cuss] Ratification of "Standards > Action" guideline > for draft-ietf-cuss-sip-uui > > Paul, > > Keith and I have been discussing this in terms of new > packages, > which can define all new SIP semantics, but I notice > in your > response you are mainly talking about contents. > Perhaps we could > have different requirements for these: the > specification required > for new packages, but something lower for contents. > I'm not > completely sure where encodings would fit in this scheme. > > What do you think? > > - Alan - > > > On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat > > >__> wrote: > > On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: > > I believe we would want the guidelines enforced. > > I also expect that we would want to do a > further review of > the guidelines if they are the sole basis for > allowing > packages in or not, before we allowed a > relaxation of the > approval regime. > > > I think the effect of the registration rules will > be that no new > registrations are made, and the default will be > used by > everyone, as is currently the case. That means > that everyone > depends upon configuration to ensure that client > and server > agree on usage. > > If you are running a call center, and decide what > information > you need to communicate from your IVR to your ACD, > are you going > to publish an RFC to register the format for that? > I think not. > Even a FCFS registration is probably too much. Yet > it would > still be good to ensure that client and server are > using the > same formats. > > When I raised this issue early on, I got no > traction for it, so > I decided to let it go until people had deployment > experience. > Then they could figure out they need something > different. But > now it has come up again. > > Thanks, > Paul > > Regards > > Keith > > -----Original Message----- > From: cuss [mailto:cuss-bounces@ietf.org > > >__] On Behalf Of Paul Kyzivat > Sent: 04 April 2014 20:31 > To: Alan Johnston > Cc: cuss@ietf.org > > > Subject: Re: [cuss] Ratification of > "Standards Action" > guideline for draft-ietf-cuss-sip-uui > > On 4/4/14 12:46 PM, Alan Johnston wrote: > > Paul, > > I know you've explained this before. > But you > haven't explained how > the requirements in Section 5. > Guidelines for UUI > Packages can be > enforced if there isn't any review. > Can you > elaborate on this? > > > With no review these couldn't be enforced. > They could still remain as guidelines. > > Thanks, > Paul > > - Alan - > > > On Fri, Apr 4, 2014 at 9:32 AM, Paul > Kyzivat > > > > >__>__> wrote: > > Interesting to see this come back. > > My original opinion was (and > still is) that > for these > > to be useful, > > it must be possible for using > enterprises to > assign new > > values for > > each distinct deployment of an > application. > IMO even > > FCFS might be > > too high a bar for this. > > E.g., if I create a particular VXML > application that > > captures some > > data and communicates it to a > call center > agent > > application via UUI, > > then the format of that data is > likely to be > unique. > > Lowering the bar below FCFS > would require a > naming scheme that > guarantees uniqueness without > registration. > > Thanks, > Paul > > On 4/3/14 6:17 PM, Vijay K. > Gurbani wrote: > > All: The IESG has sent > draft-ietf-cuss-sip-uui to the WG to > ratify the > "Standards Action" guideline > for defining > UUI packages and > registering > new IANA elements for the > parameter > tables for > > purpose, encoding and > > content. > > The draft authors note that > the original > concern > > when the work > > was coming out of Dispatch > was that the > UUI not > > become a "wildcard" > > header to be used for a wide > variety of > purposes. Hence the > direction > toward requiring a standards > track RFC. > However, a > > lesser standard > > such as "Specification > Required" might > suffice and > > offer more > > flexibility for additional > use cases, > while not > > opening up the > > process > totally as would be the case > for "First > Come First Serve." > > The IESG will like to > revisit this > decision to > > confirm that the WG > > decisions remains "Standards > Action". > > To that end, Enrico and I > will like to > open up a > > 2-week period > > to ratify > this decision to remain at > "Standards > Action" or to move to > something > other designation. > > The 2-week period ends on > close of > business (US > > Central Time) > > April 17, > 2014. Please express an > opinion; if you > are for > > keeping status quo, > > please send a one-liner to > the cuss WG > mailing > > list. If you are > > of the > opinion that we should relax > the burden, > please > > state so and a short > > reason on why we should do so. > > Thank you all. > > - vijay > > > > > _____________________________________________________ > 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 nobody Fri Apr 18 14:09:32 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437A51A0495 for ; Fri, 18 Apr 2014 14:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMB7AxZsmpJ9 for ; Fri, 18 Apr 2014 14:09:26 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id D66121A043E for ; Fri, 18 Apr 2014 14:09:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7BA30217AD for ; Fri, 18 Apr 2014 17:09:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 18 Apr 2014 17:09:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=Es/2kvqqJVLIn5MvZ1VaAYAsGPc=; b=lXKESDIJ5ffNlFc+h8PSqblSmHzt c6TpVhUDZfQSaAo8eRSqCoWnb2a6zuOZBEo0zSBqDeT+ihUdmL++J+GPtGfPalYu 0zzeWcbedoLQTmtEQmhr8EO/c+kTmiSftuNuGgPTITmp3RH0KMC4vhKt2Nj11Ia8 8LwOkcLyT2Nb0DU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=Es/2kvqqJVLIn5MvZ1VaAY AsGPc=; b=Fj8XPDYo1A/7EDeghXOR1Jr6D86OUgMOgWMuOR8dhsP78ieQPQR7Rg yAHEWwCgvjR5t1riQKzgWY7gfEtnBAh7RrNpdyVJ8pXX74rexYicJFXV2tASWhL7 EN570mrfFq4T9R4vauBrzQyLbvb57WnD4AYufdV9O0O10MYBBKZM0= X-Sasl-enc: 1LY8kR2zEOiSNg2r97tbBCroytLexOFGVdqcWFwmSzPo 1397855359 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 86A40C0000C; Fri, 18 Apr 2014 17:09:18 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 18 Apr 2014 14:09:12 -0700 From: Alissa Cooper To: Paul Kyzivat , Alan Johnston Message-ID: Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534D8474.70403@alum.mit.edu> <03fd01cf58f2$03946320$0abd2960$@humancomm.com> <534E9FBC.3000508@alum.mit.edu> <534EB3BA.6070504@alum.mit.edu> In-Reply-To: <534EB3BA.6070504@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/6m6zfpYSJ4eYJW2OXI4CwsAKK3c Cc: "cuss@ietf.org" Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 21:09:30 -0000 On 4/16/14, 9:45 AM, "Paul Kyzivat" wrote: >On 4/16/14 12:11 PM, Alan Johnston wrote: >> Paul, >> >> So we are in agreement, then. Keep this draft at Standards Action for >> new packages so we can keep control over how this mechanism is used. >> >> Your proposal sounds very interesting for opening things up, and if >> published as a standards track document would allow for exactly what you >> want. > >Perhaps, to resolve the IESG concern over the use of Standards Action, >we could add some text indicating that this is conservative choice made >while we if and how to open it up. This sounds like a reasonable resolution to me. Alissa > > Thanks, > Paul > >> - Alan - >> >> >> On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat > > wrote: >> >> On 4/15/14 5:30 PM, James Rafferty wrote: >> >> Hi, >> >> As Alan noted, we seem to be having two discussions here. What >> I thought >> we'd be talking about is what level of IANA action is needed. >> Recent drafts >> set that bar at "Standards Action." I'm personally open to the >>less >> rigorous definition of "Specification Required," which would >>allow >> organizations outside of the IETF to define packages, but would >> still imply >> that the guidelines in Section 5 would continue to be enforced. >> However, >> there hasn't been any discussion about such a middle ground. >> >> Paul, would lowering the bar to "Specification Required" help >> offer some of >> the flexibility you want? This would allow other packages to be >> defined -- >> inside or outside the IETF -- but would still imply adherence >>to the >> guidelines in section 5. This would also bring a "designated >> expert" into >> play, in order to provide review of the proposed specification. >> >> >> I don't think reducing to "Specification Required" would address my >> concerns in any way. I don't even think reducing to FCFS would do >>that. >> >> Frankly, *for now* I am satisfied to leave the requirement at >> Standards Action, with the understanding that this is just temporary >> to get the basic mechanism (with the ISDN package) published. That >> allows us to keep control and so prevent something stupid being >>done. >> >> Then I think there should be further discussion about how purpose, >> content, and encoding *should* be used, and what sorts of >> registration policies would facilitate that. >> >> My thinking is that it should be something like feature tags, with >> the namespace partitioned, so there can be some values with >> standardized values, and another part of the namespace that can be >> used by individual enterprises without need of registration while >> still preventing collision. >> >> On some of the other points: >> >> -- Encodings -- I would not expect too many of those to be >> defined; my >> former company supported the current binary definition and an >> earlier ASCII >> encoding >> >> >> Yes. Me too. But it would be useful to have a discussion of what >> might be other meaningful values. >> >> I personally would have liked to also see a "text" (or "ascii" or >> whatever) encoding. I think many uses would find this sufficient, >> and it would be much more readable for diagnosing call flows, for >> examples, etc. >> >> Beyond that I don't know. It depends on how the line is drawn >> between content and encoding. >> >> -- Purpose -- This is the rationale behind having a separate >>package >> >> >> Once we get beyond ISDN, I see Purpose as being the primary >> mechanism for ensuring that sender and receiver are compatible. >> >> -- Content -- allows for further elaboration on what kinds of >> semantic >> information are supported; see section 5.1 on extensibility >> >> >> I think it is likely that there would be only one content per >> purpose, and so it will be redundant. OTOH, the purpose could be >> treated as a sort of interface, with the content naming individual >> messages within the interface. >> >> Thanks, >> Paul >> >> James >> >> >> -----Original Message----- >> From: cuss [mailto:cuss-bounces@ietf.org >> ] On Behalf Of Paul Kyzivat >> Sent: Tuesday, April 15, 2014 3:12 PM >> To: DRAGE, Keith (Keith); Alan Johnston >> Cc: cuss@ietf.org >> Subject: Re: [cuss] Ratification of "Standards Action" >>guideline for >> draft-ietf-cuss-sip-uui >> >> On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote: >> >> In the use cse Paul had been giving, I have an assumption >> that the >> ISDN package would be used (because call centers) are >> connected to the >> PSTN as well. This would be effectively a privately defined >> protocol >> running over the top, and signalled as such. >> If you want a public protocol (i.e. standardised) running >> over the >> top, the package definition, or any other UUI parameters, >> could be >> coupled with the RFC that defines it. >> >> >> It doesn't matter if the call center is connected to the PSTN. >> What matters >> is the source and destination of the UUI. There is a pretty good >> chance that >> those will be connected with sip - probably within the same >> enterprise. >> >> Everybody using the ISDN package is a *problem*, because it has >> no way to >> distinguish different usages that don't interoperate. >> >> The point I'm making is that most of the usages *won't* be >> public. (Are >> there *any* that *are*?) >> >> I write a VXML application for my business. It collects some >> information, >> and then forwards the call to an ACD, passing the collected >> information via >> UUI. The format and purpose of that data is specific to my >> particular VXML >> app and the application the call center operators use. Who is >> going to write >> an RFC to define that? (Nobody!) If that accidentally ends up at >> the "wrong" >> app, how will it be detected that it is wrong? (Hopefully by the >> purpose and >> content attributes of the UUI.) >> >> How do you imagine purpose and content being used, such that >> somebody would >> be in a position to write an RFC to define them? >> >> Thanks, >> Paul >> >> Keith >> >> >> >>------------------------------__------------------------------__--------- >>--- >> >> *From:* Alan Johnston >> [mailto:alan.b.johnston@gmail.__com >> ] >> *Sent:* 15 April 2014 03:44 >> *To:* Paul Kyzivat >> *Cc:* DRAGE, Keith (Keith); cuss@ietf.org >> >> *Subject:* Re: [cuss] Ratification of "Standards >> Action" guideline >> for draft-ietf-cuss-sip-uui >> >> Paul, >> >> Keith and I have been discussing this in terms of new >> packages, >> which can define all new SIP semantics, but I notice >> in your >> response you are mainly talking about contents. >> Perhaps we could >> have different requirements for these: the >> specification required >> for new packages, but something lower for contents. >> I'm not >> completely sure where encodings would fit in this >>scheme. >> >> What do you think? >> >> - Alan - >> >> >> On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat >> >> > >__> wrote: >> >> On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: >> >> I believe we would want the guidelines >>enforced. >> >> I also expect that we would want to do a >> further review of >> the guidelines if they are the sole basis for >> allowing >> packages in or not, before we allowed a >> relaxation of the >> approval regime. >> >> >> I think the effect of the registration rules will >> be that no new >> registrations are made, and the default will be >> used by >> everyone, as is currently the case. That means >> that everyone >> depends upon configuration to ensure that client >> and server >> agree on usage. >> >> If you are running a call center, and decide what >> information >> you need to communicate from your IVR to your ACD, >> are you going >> to publish an RFC to register the format for that? >> I think not. >> Even a FCFS registration is probably too much. Yet >> it would >> still be good to ensure that client and server are >> using the >> same formats. >> >> When I raised this issue early on, I got no >> traction for it, so >> I decided to let it go until people had deployment >> experience. >> Then they could figure out they need something >> different. But >> now it has come up again. >> >> Thanks, >> Paul >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: cuss [mailto:cuss-bounces@ietf.org >> >> > >__] On Behalf Of Paul Kyzivat >> Sent: 04 April 2014 20:31 >> To: Alan Johnston >> Cc: cuss@ietf.org >> > >> Subject: Re: [cuss] Ratification of >> "Standards Action" >> guideline for draft-ietf-cuss-sip-uui >> >> On 4/4/14 12:46 PM, Alan Johnston wrote: >> >> Paul, >> >> I know you've explained this before. >> But you >> haven't explained how >> the requirements in Section 5. >> Guidelines for UUI >> Packages can be >> enforced if there isn't any review. >> Can you >> elaborate on this? >> >> >> With no review these couldn't be enforced. >> They could still remain as guidelines. >> >> Thanks, >> Paul >> >> - Alan - >> >> >> On Fri, Apr 4, 2014 at 9:32 AM, Paul >> Kyzivat >> > > > >> > >> > >__>__> wrote: >> >> Interesting to see this come >>back. >> >> My original opinion was (and >> still is) that >> for these >> >> to be useful, >> >> it must be possible for using >> enterprises to >> assign new >> >> values for >> >> each distinct deployment of an >> application. >> IMO even >> >> FCFS might be >> >> too high a bar for this. >> >> E.g., if I create a particular >>VXML >> application that >> >> captures some >> >> data and communicates it to a >> call center >> agent >> >> application via UUI, >> >> then the format of that data is >> likely to be >> unique. >> >> Lowering the bar below FCFS >> would require a >> naming scheme that >> guarantees uniqueness without >> registration. >> >> Thanks, >> Paul >> >> On 4/3/14 6:17 PM, Vijay K. >> Gurbani wrote: >> >> All: The IESG has sent >> draft-ietf-cuss-sip-uui to the WG to >> ratify the >> "Standards Action" guideline >> for defining >> UUI packages and >> registering >> new IANA elements for the >> parameter >> tables for >> >> purpose, encoding and >> >> content. >> >> The draft authors note that >> the original >> concern >> >> when the work >> >> was coming out of Dispatch >> was that the >> UUI not >> >> become a "wildcard" >> >> header to be used for a wide >> variety of >> purposes. Hence the >> direction >> toward requiring a standards >> track RFC. >> However, a >> >> lesser standard >> >> such as "Specification >> Required" might >> suffice and >> >> offer more >> >> flexibility for additional >> use cases, >> while not >> >> opening up the >> >> process >> totally as would be the case >> for "First >> Come First Serve." >> >> The IESG will like to >> revisit this >> decision to >> >> confirm that the WG >> >> decisions remains "Standards >> Action". >> >> To that end, Enrico and I >> will like to >> open up a >> >> 2-week period >> >> to ratify >> this decision to remain at >> "Standards >> Action" or to move to >> something >> other designation. >> >> The 2-week period ends on >> close of >> business (US >> >> Central Time) >> >> April 17, >> 2014. Please express an >> opinion; if you >> are for >> >> keeping status quo, >> >> please send a one-liner to >> the cuss WG >> mailing >> >> list. If you are >> >> of the >> opinion that we should relax >> the burden, >> please >> >> state so and a short >> >> reason on why we should do >>so. >> >> Thank you all. >> >> - vijay >> >> >> >> >> _____________________________________________________ >> 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 >> >> >> >> >> > >_______________________________________________ >cuss mailing list >cuss@ietf.org >https://www.ietf.org/mailman/listinfo/cuss From nobody Mon Apr 28 06:38:55 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E800A1A0A22 for ; Mon, 28 Apr 2014 06:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a-rKHt7_gHj for ; Mon, 28 Apr 2014 06:38:53 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7589C1A0A20 for ; Mon, 28 Apr 2014 06:38:53 -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 s3SDcpQo026651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Apr 2014 08:38:51 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s3SDcpSR018608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 28 Apr 2014 08:38:51 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s3SDcpPp008247 for ; Mon, 28 Apr 2014 08:38:51 -0500 (CDT) Message-ID: <535E5A5D.60008@bell-labs.com> Date: Mon, 28 Apr 2014 08:40:45 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 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.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/EEUC1E-wok9LaYvQe47tPu0J4BI Subject: [cuss] "Standard Action" ratification consensus for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 13:38:55 -0000 Folks: A word of thanks to all those that expressed an interest in the thread we opened up for the ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui [1]. The balance of the views expressed on the topic appear to be to keep the draft at Standards Action for new packages so we can control the use of the mechanism. We need to inform the IESG that this is the choice of the WG, as conservative as it may be. For now, this choice will be in effect and may be revisited in the future. Alissa (as AD) will follow up with the IESG to get the draft moving ahead. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00592.html Cheers, Vijay K. Gurbani and Enrico Marocco. From nobody Mon Apr 28 07:23:49 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CE51A0A20 for ; Mon, 28 Apr 2014 07:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PgXjcMpQBzC for ; Mon, 28 Apr 2014 07:23:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id EA75C1A0983 for ; Mon, 28 Apr 2014 07:23:45 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 4DAFD1B822E; Mon, 28 Apr 2014 16:23:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 358D4384072; Mon, 28 Apr 2014 16:23:44 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 28 Apr 2014 16:23:44 +0200 From: To: Alan Johnston , "cuss@ietf.org" Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-15.txt Thread-Index: AQHPTo5N8Q0Dp8OH7kWIqxUZTIbZV5r+m/2QgCiW0AA= Date: Mon, 28 Apr 2014 14:23:43 +0000 Message-ID: <3573_1398695024_535E6470_3573_16723_1_F8BE5641EC3C954DA088A8350BDDFA4813D312@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <88CAD1D4E8773F42858B58CAA28272A0144BD71C@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <88CAD1D4E8773F42858B58CAA28272A0144BD71C@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.28.72723 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/d-yOIZeflUK4ECVjkJjQrltOo18 Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-15.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 14:23:49 -0000 Hello, Please find some comments on these new modifications in v15 compared with v= 14: - Abstract: "The syntax and semantics for the UUI data used by a specific a= pplication." =3D> The verb seems missing. - =A74: Could you explain for which reasons you deleted the sentence "If th= e "purpose" header field parameter is not present, interworking with the IS= DN UUI Service MUST be assumed"? Without this information, we do not know t= hat in such a case we have to refer to ISDN UUI, where this possibility is = permitted for earlier implementations (ISDN UUI: "Non-inclusion of the "pur= pose" header field parameter is permitted, but this is primarily to allow e= arlier implementations to support this package"). Regards, Celine Serrut-Valette Orange Labs -----Message d'origine----- De=A0: cuss [mailto:cuss-bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9=A0: mercredi 2 avril 2014 18:11 =C0=A0: i-d-announce@ietf.o= rg Cc=A0: cuss@ietf.org Objet=A0: [cuss] I-D Action: draft-ietf-cuss-sip-uu= i-15.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Working = Group of the IETF. Title : A Mechanism for Transporting User to User Call Co= ntrol Information in SIP Authors : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-15.txt Pages : 19 Date : 2014-04-02 Abstract: There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-15 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Apr 29 16:58:49 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC171A096B for ; Tue, 29 Apr 2014 16:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG19iojpo8xV for ; Tue, 29 Apr 2014 16:58:46 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 89DD71A096A for ; Tue, 29 Apr 2014 16:58:46 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C9D4221110 for ; Tue, 29 Apr 2014 19:58:44 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 29 Apr 2014 19:58:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=QFl3N3xjUznFwldIh1BDCqX swP4=; b=zYB2Z10PxugA5Rk5db+6L58pIvcgfeZ6n7jAgTHT68kivzfukFquHbo I27wqCvWk1n2taIyYmG13IpaCoPB0UpauXZ78q5KAuyUnsgPsra8Lplvlzb6Rw+T +YNmx0BMApKvZUUiECTvivkzXQwP0AMax5Cl8ai/Gm982uHyUZrE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=QFl3N3xjUznFwldIh1BDCqXswP4=; b=gUcrMcO5OG066dIsoAe9AAEOmPme AAsDKFkH5zrtO1k3QkRiBQz+/hHHkYXegfl5rPuXoeo5e/1oGWyGYxEst2kWfkgN /GQQIHkPOR2oG4qUNkMWSwUY3aCKc1cnbwo31e0sLKVSVI6KXD+jneAstYbA0VI2 a15YaKnM6oS1s0s= X-Sasl-enc: HlQuXWzQz+OHmnZjxf6tCnF62zMnRM53bXQWTVphodd+ 1398815924 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id ECDE9C00005; Tue, 29 Apr 2014 19:58:42 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Tue, 29 Apr 2014 16:58:37 -0700 From: Alissa Cooper To: Message-ID: Thread-Topic: AD review: draft-ietf-cuss-sip-uui-isdn-08 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/6UZzrL8LCFrJT9XMAdlIcUW11W8 Cc: draft-ietf-cuss-sip-uui-isdn@tools.ietf.org Subject: [cuss] AD review: draft-ietf-cuss-sip-uui-isdn-08 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:58:48 -0000 I have reviewed this draft in preparation for IETF LC. Overall, it's in good shape, and I have requested the LC. A couple of comments to address with any LC comments: Section 4 says: "If the SIP-T method of encapsulation of ISDN instead of interworking is used, this is a reasonable mechanism and does not require any extensions to existing SIP-T. However, if true ISDN interworking is being done, this approach is not reasonable." It=E2=80=99s not clear from this text why the mechanism is described as =E2=80=9Cnot reasonable.=E2=80=9D This text should be clarified to explain that encapsulation is not needed when ISDN interworking is being done. Section 6 says: "If an interworking point is reached, and the limitations are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked. As a result there is also only one encoding value specified." This text needs to be more explicit about which =E2=80=9Climitations=E2=80=9D it is referring to. If it is the size limitation (128 octets plus the protocol discriminator) or the limitation to one UUI data element, those should be made explicit. Same goes for the text in section 7 about "the ISDN service restrictions" =E2=80=94 the restrictions should be made explicit. Sections 7 and 8 say: "When receiving UUI, when multiple User-to-User header fields are received in the same response with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAC MUST discard all these header fields. There are no mechanisms for determining which was the intended data packet so all are discarded." s/data packet/UUI object/ Section 13: The =E2=80=9CContact:=E2=80=9D fields need to be filled in. Thanks, Alissa From nobody Wed Apr 30 04:57:44 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0601A6F53; Wed, 30 Apr 2014 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgur1dhKIysE; Wed, 30 Apr 2014 04:57:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A46DA1A08BD; Wed, 30 Apr 2014 04:57:39 -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: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140430115739.12784.4765.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 04:57:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/YkrYv_ngd2T58sXTHbNCsINmTUk Cc: cuss@ietf.org Subject: [cuss] Last Call: (Interworking ISDN Call Control User Information with SIP) to Proposed Standard X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 11:57:41 -0000 The IESG has received a request from the Call Control UUI Service for SIP WG (cuss) to consider the following document: - 'Interworking ISDN Call Control User Information with SIP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-14. 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 The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Apr 30 12:59:01 2014 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9081A884D; Wed, 30 Apr 2014 12:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmpQAL3yNisk; Wed, 30 Apr 2014 12:58:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB301A095F; Wed, 30 Apr 2014 12:58:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430195855.18997.70675.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 12:58:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/hwIisiBCLYAQMLeZhMq2dAoQ13s Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-16.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 19:58:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. Title : A Mechanism for Transporting User to User Call Control Information in SIP Authors : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-16.txt Pages : 19 Date : 2014-04-30 Abstract: There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/