Subject: [Sip] Re: Critical reviewers for draft-ietf-sip-gruu-10

From: [email-masked]
Date: Sun, 20 Aug 2006 17:34:58 -0400

Here is my review.  There is only one technical issue, and that one is
minor.

----------------------------------------------------------------------
Item 1: 

- location in document

Section 8.2.2.

- nature of comment

Editorial.  Wording does not match intention of author (see author's
comment below).  Current wording is a significant technical problem.

- comment

>From the SIP mailing list:

    From: Jonathan Rosenberg <[email-masked]>

    > From: Dale Worley
    > In 8.2.2, I see "The rules in Section 8.1.1 ensure that at least one
    > proxy in the same domain of the home proxy will be visited."  In the
    > context, it appears that this is stating that 8.1.1 ensures that a UA
    > in a domain that issues GRUUs will always have its UAs use an outbound
    > proxy.  And yet I can't see how 8.1.1 forces that, especially in light
    > of the statement "Note that this specification does not require the
    > use of an outbound proxy".

    This is a bug. It should say that, if an outbound proxy is used at all, 
    then the request will visit a proxy in the home domain. But, its valid 
    to use gruu without any outbound proxies.

- proposed fix

Have the author correct the wording, as there seems to be no
disagreement on the substance of the passage, in that I now agree that
it is a bug in as Jonathan described it.

Item 2: 

- location in document

Section 6, figure 3 and section 12, figure 5.

- nature of comment

Editorial.

- comment

The two figures in the I-D are labeled "figure 3" and "figure 5",
rather than the expected "figure 1" and "figure 2" (as in -09).

- proposed fix

Renumber figures as in -09.

Item 3: 

- location in document

Section 8.1.1.

- nature of comment

Editorial.

- comment

>    When using a service route,
>    this requirement (that the GRUU be obtained from a domain that will
>    be visited by the request) it is sufficient to use the GRUU learned
>    in the same registration that delivered the service route.
> 
> This doesn't parse.  Possibly it should read "... to satisfy this
> requirement (...), it is sufficient ...".

- proposed fix

As proposed by the author on the SIP mailing list:

    When using a service route, this requirement (that the GRUU be
    obtained from a domain that will be visited by the request) is
    readily met by using the GRUU learned in the same REGISTER
    response that delivered the service route.

Item 4:

- location in document

Section 5.

- nature of comment

Editorial.

- comment

My comment:

> Section 5, page 9:  "that results from stripping out the "opaque" URI
> parameter" s.b. "that results from stripping out the "opaque" and
> "gruu" URI parameters".

> But that isn't really the statement we want either, since URI
> "equivalence" is not affected by a URI parameter present in one URI
> and not in the other.  See RFC 3261, section 19.1.4.  That is,
> 
>    sip:[email-masked]
>    sip:[email-masked];opaque="dRfHgbHjGhImBv";gruu
> 
> are equivalent already.  But unfortunately so are:
> 
>    sip:[email-masked]
>    sip:[email-masked];opaque="dRfHgbHjGhImBv";gruu;hop-sip-and-jump
> 
> and we want to rule out the latter pair.

Author's response:

> Interesting. What this means is that, based on URI equivalence, a GRUU 
> will in fact equal its AOR. Hmm. Its not obvious to me that this is a 
> bug or a feature. It really depends on what is a reasonable basis for 
> URI equality. One reasonable definition is that two URI should be 
> equivalent only if requests targeted towards them would reach the same 
> user, where 'same' refers to the ability to authenticate with a specific 
> credential. With that definition, the GRUU should be equal to the AOR 
> based on URI equality.
> 
> Since I don't see any real issue with the AOR and GRUU being equal, I 
> think all we need to do is state that this is the fact. I changed the 
> paragraph we're talking about to read:
> 
> <t>
> If the GRUU contains an "opaque" URI parameter, the URI that results
> from stripping out the "opaque" and "gruu" URI parameters MUST be
> equivalent to the AOR associated with the GRUU. Indeed, the GRUU
> itself will also be equivalent to the AOR based on URI comparison,
> since the "gruu" and "opaque" parameters will be ignored during
> comparison, being present in one URI (the GRUU) and not the other (the
> AOR).
> </t>

- proposed fix

I believe that I confused the issue in the exchange above, as the
question is not a matter of a useful definition of "equivalence" (it's
far too late to change that, anyway), but that in the passage, we
probably don't want to use "equivalence" to describe the relationship
between the GRUU and the AOR.

I suggest:

> If the GRUU contains an "opaque" URI parameter, the URI that results
> from stripping out the "opaque" and "gruu" URI parameters MUST be
> the AOR associated with the GRUU.

Using "the same as" is probably stricter than we really need (as
textual equality would not allow rearranging the order of URI
parameters, and other trivial changes), but it ensures that
implementations do not construct GRUUs that confuse other
implementations.  Whereas the current wording uses "equivalent", which
allows gratuitously adding and deleting URI parameters.

Item 5: 

- location in document

Section 10.

- nature of comment

Minor technical.

- comment

My original comment:

> Section 10, page 23:  ""gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI)
> RDQUOT" is not what we want, I think.  I think the semantics we are
> looking for is ""gruu" EQUAL quoted-string, where the value
> represented by the quoted-string is a SIP-URI or SIPS-URI".  (That
> latter could be represented in BNF, but that would make it less
> clear.)

> Due to the details of the grammar, the new formulation differs from
> the original only in some unusual cases, such as allowing:
> 
>      Contact: <...>;gruu="sip:gruu\[email-masked];gruu"
> 
> (The GRUU is <sip:[email-masked];gruu>.)
> 
> But it seems to me that it is non-orthogonal (and inviting trouble) to
> have the grammar for c-p-gruu forbid backslash-escapes of characters
> that do not require them, when the grammar for generic-param allows
> them.

Author's response:

> Egads. I disagree here. The SIP URI itself cannot contain a quote, so 
> there is no need to ever use backslash escaping. I think folks might get 
> confused by backslash escaping here. If you just put the unescaped URI 
> in, you'll never have a problem. Why allow escaping?

My response:

I see it as a dangerous thing to introduce differing rules as to what
escaping is allowed and forbidden in different parameters.  As a
matter of layering, it should be possible to write a parser that can
correctly parse the values of all parameters, and conversely, a
composer that can correctly represent any set of values for any
parmeters, and neither should require special knowledge of any
particular parameters.  (Note that the grammar of RFC 3261 adhered to
this principle.)

Since in the general case, RFC 3261 allows, e.g., a parameter value of
"a~b" to be represented

>      Contact: <...>;unknown-parameter="a\~b"

Then it should be acceptable to escape any occurrence of "~" in any
header-parameter using "\", as in the case in my original comment.
Otherwise, the parser and composer for name-addr's will need continual
tweaking to accomodate the special restrictions of each newly
standardized header-parameter.  In this case, the composer needs to
know that while the generic grammar allows any character that can
appear in a value to be escaped with "\" (and for a few, it is
mandatory), that in the gruu parameter, escaping is forbidden.

(Although unfortunately, this principle is already violated in regard
to string-value's in feature-param's (RFC 3840), where the
header-parameter value must contain an unescaped "<", followed by the
string value itself, and then an unescaped ">", but any occurrences of
"<" and ">" in the string value must be escaped "\".  And those rules
provide no practical benefit, as a general URI parser must already be
able to handle both escaped and un-escaped "<" and ">" in all
positions within quoted header-parameter values.)

- proposed fix

Substitute:

    c-p-gruu        =  "gruu" EQUAL quoted-string

This would imply that c-p-gruu is to be intrpreted as any other
quoted-string that is the value of a header-parameter.  That the value
represented by the quoted-string is a sip or sips URI is not enforced
by this grammar, but is stated elsewhere in the document.

Item 6: 

- location in document

Section 12.

- nature of comment

Editorial.

- comment

Example messages are indented by different amounts.

Continuation line of header is missing its initial whitespace (or an
<allOneLine> construction was omitted) in the example at the bottom of
page 30:

    Contact: <sip:[email-masked]>
    ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

- proposed fix

Indent the example messages consistently.

Correct the presentation of the split Contact header.
----------------------------------------------------------------------

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip