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

From: Alan Johnston <[email-masked]>
Date: Tue, 18 Feb 2014 13:40:24 -0600

Peter,

Thanks for the review.  Somehow we missed seeing it, so apologies for the
long delay.

We have made all the changes you suggested, but won't be able to submit the
I-D until March.  Let us know if you have any concerns or comments.

See below for a few comments.

- Alan -

On Tue, May 28, 2013 at 10:48 PM, Peter Saint-Andre <[email-masked]>wrote:

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

No, they are separate use cases.  Rewrote this sentence to make this
clearer.  Which header is used is dependent on the use case, which is
chosen by the UA initiating.  As a result, there is no interop issues.

> Also, a normative reference to
> RFC 3515 seems needed here.
>

Added.

>
> In Section 4.1, has the ABNF been checked?
>

Yes.

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

Yes.

>
> 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..."
>

Done.

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

We have changed it to "standards action" based on WG consensus and AD
advice.

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

No, we don't allow RFC call usages.

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

Done.  Updated to RFC 7044.

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

Added reference to RFC 7044.

>
> 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.
>
>
Done.

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