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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 5 Mar 2014 15:58:55 +0000

Hi Peter,

Alan has just revised the draft per his email below.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-cuss-sip-uui-13.txt

Cheers,

Gonzalo

On 18/02/2014 7:40 PM, Alan Johnston wrote:
> 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]
> <mailto:[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
> 
> 
>