[apps-discuss] AppsDir review of draft-ietf-cuss-sip-uui-10

[Peter Saint-Andre <[e-mail]>]

Greetings!

I have been selected as the Applications Area Directorate [1] reviewer
for draft-ietf-cuss-sip-uui. Please resolve these comments along with
any other Last Call comments you might receive. Please wait for
direction from your document shepherd or AD before posting a new version
of the Internet-Draft.

Document: draft-ietf-cuss-sip-uui-10
Title: A Mechanism for Transporting User to User Call Control
Information in SIP
Reviewer: Peter Saint-Andre
Review Date: 2013-05-28
IETF Last Call ends: 2013-05-29

Summary: The document is ready for advancement to Proposed Standard but
could do with a bit more polishing.

Major Issues:

None.

Minor Issues:

Section 3 states:

   For redirection and referral use cases and REQ-3, the header field
   shall be included (escaped) into the Contact or Refer-To URI.

No guidelines are provided for deciding between use of the Contact
header field or the Refer-To header field. Might that introduce the
possibility of interoperability problems? Also, a normative reference to
RFC 3515 seems needed here.

In Section 4.1, has the ABNF been checked?

Section 4.2 states:

   Each octet of binary
   data to be represented in the hex encoding MUST be mapped to two
   hexadecimal digits (represented by ASCII characters 0-9, A-F and
   a-f), each representing four bits within the octet.

Is the output case-insensitive?

Also, in Section 4.2:

   Hex encoding is normally done as a token,
   although quoted-string is permitted, in which case the quotes MUST be
   ignored.

The phrase "done as" is a bit loose; I assume you mean something like
"The hex-encoded value is normally represented using the 'token'
construction from RFC 3261, although the 'quoted-string' construction is
permitted..."

In Section 5, what is the rationale for using a policy of "RFC Required"
rather than, say, "Specification Required"? Were the various RFC 5226
options considered by the CUSS WG?

Please note that Section 5 states:

   UUI packages defined using this SIP UUI mechanism MUST follow the
   "RFC Required" guideline as defined in [RFC5226] and publish a
   standards track RFC which describes the usage.

However, Section 6.3 states:

   This specification establishes the uui-packages sub-registry under
   http://www.iana.org/assignments/sip-parameters.  New uui-packages
   MUST follow the "Specification Required" guideline as defined in
   [RFC5226].

Are those two statements in conflict?

In Section 5, condition #5 states:

      5.  The UUI data is not being utilized for user-to-user Remote
      Procedure Call (RPC) calls.

Is it possible to use the UUI header field for RPC calls, or in general
as a kind of back channel? If so, it would be good to discuss that in
the Security Considerations

Nits:

It would be helpful to reference 4244bis on first mention of
History-Info. Also, isn't it properly "the History-Info header field"?

What is "hi-targeted-to-uri"? If that is a specification, a citation
would be helpful.

The following text would be better placed in the Terminology section
(or, at the least, before the first example that uses this convention,
not after the second example):

   Note that the <allOneLine> tag convention from SIP  Torture Test
   Messages [RFC4475] is used to show that there are no line breaks in
   the actual message syntax.

Peter

[1]
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate