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

From: [email-masked]
Date: Sat, 22 Oct 2011 17:31:55 -0700

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-03.txt
	Pages           : 16
	Date            : 2011-10-22

   There is a need for applications using SIP to exchange User to User
   Information (UUI) data during session establishment.  This
   information, known as call control UUI data, is a small piece of data
   inserted by an application initiating the session, and utilized by an
   application accepting the session.  Applications define a UUI package
   for the transport of their UUI data.  This data is opaque to SIP and
   its function is unrelated to any basic SIP function.  This document
   defines a new SIP header field, User-to-User, to transport UUI data,
   along with an extension mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-03.txt

---

From: Alan Johnston <[email-masked]>
Date: Sun, 23 Oct 2011 15:47:02 -0500

Here are the changes to the -03 version of the draft (you can see all
of them in the diff
http://tools.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-03.txt)

- Terminology: consistent use of "UUI data" to refer to the contents
of the User-to-User header field
- Terminology: replaced "application" with "package".  Added text
describing how new UUI packages are defined.
- Updated ABNF: added option for quoted-string
- Source Identity: clarified text and added reference to RFC 3325
- Added RPC to non-use cases for UUI
- IANA Registries: added text creating IANA registries for package,
content, and encoding values

Comments most welcome!

- Alan -

On Sat, Oct 22, 2011 at 7:31 PM,  <[email-masked]> wrote:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2011 16:37:08 -0400

Since this is approaching completion, its time to focus in on things 
that were, up till now, details that could be left till later. I've 
found several of those:

Why must newly defined packages define a new "content" value?
I can imagine cases where a new package reuses previously defined 
"content" values. E.g.
- package X uses content values A,B,C, and defines them
- package Y uses content values A,D,E, and defines D & E

So, I'm inclined to just say that each package spec references the 
content types it accepts. Those can be ones that it also defines, or 
ones that are defined elsewhere (some other RFC.)

In guidelines section, there is a list of applicable conditions, and a 
list of inapplicable conditions (which all seem to be negations of the 
applicable conditions). How are these to be interpreted if more than one 
of them match? (Must *all* the applicable conditions match? Or is one 
sufficient? I presume you intend *all* for applicability, *any* for 
inapplicability.)

It also appears that condition 1 is inconsistent with condition 3. 
Either an application above sip generates/consumes the data, or the SIP 
UAC/UAS do so.

While "hex" encoding is registered, there is no actual definition of 
what it means. This is probably well understood at a high level, but 
there are details that could be misunderstood. Things that need to be 
nailed down:
- does it use [0-9A-F], [0-9a-f], or [0-9A-Fa-f] ?
- does it have a prefix (e.g. 0x) or not?
- what happens if there are an odd number of hex digits?
- can the quoted string syntax be used with hex?

It doesn't matter much what we choose above, as long as we do. I would 
be inclined to:
- [0-9A-Fa-f]
- no prefix
- invalid if it has an odd number of hex digits. Results undefined.
- a quoted string may be used with hex. The quotes are ignored.

Then I think we need to specify that the hex encoding yields a sequence 
of octets, one octet per each two hex digits, in the same order, with 
the first digit of each pair defining the high order 4 bits of the octet 
and the 2nd digit providing the low order 4 bits.

For the content specification to work with hex encoding, it should be 
defined to work on a sequence of octets. If content specifications are 
to work with other encodings, I think we need one of the following:
- every encoding must be defined to yield a sequence of octets,
   so that the content specifications will work with them, OR
- each content specification must identify which encodings it works
   with, and how it works with each

ISTM that it would be more straightforward to require each encoding to 
yield a sequence of octets, so that content specifications are 
independent of encodings. For instance, a "string" encoding could be 
defined as yielding a sequence of octets that is the UTF8 encoding of 
the string.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Mon, 24 Oct 2011 19:35:40 -0500

Paul,

These are all excellent issues - I've added them to the slides for
tomorrow.  In short, I think I agree with all your suggestions, but
lets go through them on the interim call.

- Alan -

On Mon, Oct 24, 2011 at 3:37 PM, Paul Kyzivat <[email-masked]> wrote:
> Since this is approaching completion, its time to focus in on things that
> were, up till now, details that could be left till later. I've found several
> of those:
>
> I can imagine cases where a new package reuses previously defined "content"
> values. E.g.
> So, I'm inclined to just say that each package spec references the content
> types it accepts. Those can be ones that it also defines, or ones that are
> defined elsewhere (some other RFC.)
>
> In guidelines section, there is a list of applicable conditions, and a list
> of inapplicable conditions (which all seem to be negations of the applicable
> conditions). How are these to be interpreted if more than one of them match?
> (Must *all* the applicable conditions match? Or is one sufficient? I presume
> you intend *all* for applicability, *any* for inapplicability.)
>
> It also appears that condition 1 is inconsistent with condition 3. Either an
> application above sip generates/consumes the data, or the SIP UAC/UAS do so.
>
> While "hex" encoding is registered, there is no actual definition of what it
> means. This is probably well understood at a high level, but there are
> details that could be misunderstood. Things that need to be nailed down:
> It doesn't matter much what we choose above, as long as we do. I would be
> inclined to:
> - [0-9A-Fa-f]
> - no prefix
> Then I think we need to specify that the hex encoding yields a sequence of
> octets, one octet per each two hex digits, in the same order, with the first
> digit of each pair defining the high order 4 bits of the octet and the 2nd
> digit providing the low order 4 bits.
>
> defined to work on a sequence of octets. If content specifications are to
> work with other encodings, I think we need one of the following:
> ISTM that it would be more straightforward to require each encoding to yield
> a sequence of octets, so that content specifications are independent of
> encodings. For instance, a "string" encoding could be defined as yielding a
> sequence of octets that is the UTF8 encoding of the string.
>
>        Thanks,
>        Paul