Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 15 April 2014 19:11 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 <cuss@ietfa.amsl.com>; 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 <cuss@ietfa.amsl.com>; 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 <cuss@ietf.org>; 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 <pkyzivat@alum.mit.edu>
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)" <keith.drage@alcatel-lucent.com>, Alan Johnston <alan.b.johnston@gmail.com>
References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <CAKhHsXFSXaY=Ch_YKfVN6AyYmF_UCVzy4wdoj-mBjLKXjHyGsQ@mail.gmail.com> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <CAKhHsXECj+HsBNYju8kE8yUJ9-ijdvs6KTPnnO6wW_4A_UqRXw@mail.gmail.com> <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" <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" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss/>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=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 <pkyzivat@alum.mit.edu
>     <mailto: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
>                 <mailto:cuss-bounces@ietf.org>] On Behalf Of Paul Kyzivat
>                 Sent: 04 April 2014 20:31
>                 To: Alan Johnston
>                 Cc: cuss@ietf.org <mailto: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:pkyzivat@alum.mit.edu>
>                     <mailto:pkyzivat@alum.mit.edu
>                     <mailto: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 <mailto:cuss@ietf.org>
>                     <mailto:cuss@ietf.org <mailto:cuss@ietf.org>>
>                     https://www.ietf.org/mailman/____listinfo/cuss
>                     <https://www.ietf.org/mailman/__listinfo/cuss>
>                           <https://www.ietf.org/mailman/__listinfo/cuss
>                     <https://www.ietf.org/mailman/listinfo/cuss>>
>
>
>
>                 _________________________________________________
>                 cuss mailing list
>                 cuss@ietf.org <mailto:cuss@ietf.org>
>                 https://www.ietf.org/mailman/__listinfo/cuss
>                 <https://www.ietf.org/mailman/listinfo/cuss>
>
>
>