Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt

From: [email-masked]
Date: Sat, 01 Dec 2012 15:44:40 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF.

	Title           : A Mechanism for Transporting User to User Call Control Information in SIP
	Author(s)       : Alan Johnston
                          James Rafferty
	Filename        : draft-ietf-cuss-sip-uui-08.txt
	Pages           : 18
	Date            : 2012-12-01

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
   rules which apply for a specific application are defined by a UUI
   package.  This UUI data is opaque to SIP and its function is
   unrelated to any basic SIP function.  This document defines a new SIP
   header field, User-to-User, to transport UUI data, along with an
   extension mechanism.

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-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 3 Dec 2012 10:36:33 +0200

Authors,

thanks for addressing my comments. I still have a couple of quick questions.

The new draft uses RFC Required as its IANA policy. I have not seen any
discussions on the mailing list about this. Has the WG considered the
Specification Required policy as well? Given that the draft gives
guidelines on what is appropriate to register and what is not, having a
policy that involves some type of technical review (e.g., by an expert)
would seem a natural choice. What were the reasons considered when
making this decision?

I had a comment on the first sentence of Section 4.1 that does not seem
to have been addressed. What is the meaning of "only" in this sentence?

>    The User-to-User (UUI) header field can be present in INVITE requests
>    and responses only and in BYE requests and responses.

Thanks,

Gonzalo

On 02/12/2012 1:44 AM, [email-masked] wrote:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Dec 2012 10:46:23 -0500

> would seem a natural choice. What were the reasons considered when

Thanks for bringing this up.

Others can report their recollection - I recall that this was discussed. 
It was (and still is) my opinion that the bar needs to be very low for 
defining these extensions, because they are likely to be custom to 
individual vendor applications or individual enterprise deployments. I'm 
not sure that even FCFS is a low enough bar. But I finally gave up 
arguing this point because most everyone seems to think that the only 
*real* usage with be with the legacy default.

IIUC, the legacy usage of this has the format of uui data being 
deployment-specific without any mechanism for verifying that sender and 
receiver agree on what that format it.

	Thanks,
	Paul

---

From: James Rafferty <[email-masked]>
Date: Fri, 28 Dec 2012 10:15:05 -0500

Gonzalo, 

Please see my comments below:  

James
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Monday, December 03, 2012 3:37 AM
To: [email-masked]
Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt

Authors,

The new draft uses RFC Required as its IANA policy. I have not seen any discussions on the mailing list about this. Has the WG considered the Specification Required policy as well? Given that the draft gives guidelines on what is appropriate to register and what is not, having a policy that involves some type of technical review (e.g., by an expert) would seem a natural choice. What were the reasons considered when making this decision?

JR - There was a brief exchange between Keith Drage and Alan Johnston on this topic around Sept. 19, 2011 on the CUSS list, but I didn't see any immediate further discussion.   See the emails with Subject:    Registration requirements for new parameter values in the User-to-User header field.   There were several items to be clarified at that time around what kind of content needed to be specified for new UUI applications as a result of October list discussions and an interim meeting.   The result was additional IANA verbiage being added within the -03 version of the document in Section 6.4 - 6.5  stating that a Standards Track RFC was required for registering new values for the content and encoding parameters of the UUI header.    

I had a comment on the first sentence of Section 4.1 that does not seem to have been addressed. What is the meaning of "only" in this sentence?

>    and responses only and in BYE requests and responses.

JR - The use of "only" here now looks superfluous, since the sentence goes on to discuss another context where the UUI header can be used; it probably would be clearer if "only" is deleted.   

Thanks,

Gonzalo