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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 04 April 2014 14:33 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 248A51A0191 for <cuss@ietfa.amsl.com>; 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 <cuss@ietfa.amsl.com>; 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 <cuss@ietf.org>; 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 <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: 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" <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: 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