Subject: [cuss] Comments on draft-ietf-cuss-sip-uui-01

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 12 Jul 2011 15:36:49 -0400

In regard to the BNF:

"|" is used where the official operator is "/".  Although I don't
think anyone will be confused.

In a number of rules, a literal "=" is used where SIP BNF typically
uses EQUAL (which permits SWS before the "=").  E.g.,

        cont-param  = "content=" token

as opposed to 

        cont-param  = "content" EQUAL token

The header is named "User-to-User".  I would expect "UUI", which is
briefer and seems to be the term that is used throughout the telephony
field.

The relationship between "content" and "app" seems to be vaguely
specified.  As far as I can tell, the primary categorization is on
"app" and then within the app value, it is categorized by "content".
OTOH, the text always describes the "content" value before describing
the "app" value, which suggests primacy of "content".

The semantics of "content" is not clear.  (The only thing that is
certain is that "content" cannot be a media type, as "/" is not
permitted in tokens.)

How multiple User-to-User headers are to be handled is not clear.  The
syntax does not allow a COMMA-separated list of values, so RFC 3261
section 7.3.1 says that multiple headers are not permitted.  But
section 4.1 of the draft explicitly allows multiple values *if* they
have different "app" values; presumably values with the same "app"
value and different "content" values remain forbidden.  All of this
seems to be risky, in case a proxy assumes that section 7.3.1 forbids
new headers which do not obey the COMMA rule, and thus it blindly
combines

    User-to-User: 0123456789abcdef
    User-to-User: abcdef0123456789

into

    User-to-User: 0123456789abcdef, abcdef0123456789

which is syntactically invalid.

The lack of clarity of which User-to-User values may be combined leads
to lack of clarity regarding how a proxy acts on a 3xx response whose
Contact value contains "?User-to-User=...".  Currently, there are two
alternatives for how headers are processed in this situation:  If the
header may appear only once in a request, the included header
completely replaces any existing header of that name.  If the header
may appear multiple times, the included header is added to the series
of headers of that name.  (For the latter to succeed requires that any
two header values that are individually valid can be validly both
present in a request.)  The complexity of the combining rules for
User-to-User requires the rules to be explicitly stated.

Is the "actual" content, the underlying semantics of the value space,
of the User-to-User header assumed to be a sequence of octets?  Or is
that only if encoding=hex?

The details of "hex" are not specified.  AFAICT the only detail is
what case A-F may be in.

Dale