Subject: [Sip] draft-ietf-sip-gruu-09

From: [email-masked]
Date: Mon, 26 Jun 2006 17:32:31 -0400

I've gone over draft-ietf-sip-gruu-09, and it's a fine piece of work,
I must say.  As far as I can tell, every doubt I've had about the GRUU
machinery has been resolved (except for the "edge router" problem,
which has been dealt with via sip-outbound).  I've written up some
editorial changes to the I-D.  I don't think that any of these change
the protocol, but this is such an important I-D that it ought to be
described as rigorously as possible.

----------------------------------------------------------------------

There seems to be disagreement as to what the plural of GRUU is --
GRUU or GRUUs.  E.g., section 13, page 31 uses both "Furthermore,
GRUUs do not address" and "These GRUU will be passed".  There is a
similar inconsistency regarding the plural of AOR.

Section 3, page 5:  "the following is true" should be "the following
three properties are true", in order to ensure there is no ambiguity
about the definition.

Section 4.3, page 7:  "Each tuple also has" s.b. "Each tuple has", as
there is no preceding discussion of anything that "each tuple has".
(This actually caused me some confusion the first time I read it!)

Section 5, page 9:  ", and to easily recognize that the URI has the
GRUU property" s.b. omitted, as it is the "gruu" parameter that does
that, not the "opaque" parameter.

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.

Section 7.1.1.1, page 13:  "characteristic [8].  The instance ID MUST
identify the UA that is performing the registration."
s.b. "characteristic [8], whose value MUST be the instance ID that
identifies the UA being registered."  This is needed to explicitly
state what the value of the feature tag is, as well as to be correct
for third-party registrations.

Section 8.1.1, page 18:  "the grammar for the parameter" s.b. "the
grammar for the parameter given in section 10".

Section 8.1.1, page 18:  "(which is the case for administratively
constructed GRUUs)" s.b. omitted -- as far as I can tell, this isn't
always true.

Section 8.2.2, page 21:  "location service for that user"
s.b. "location service for that AOR", since "user" is not used
elsewhere in that paragraph.

Section 10, page 23:  "The grammar for string-value is obtained from
[8]." s.b. omitted, since "string-value" is not mentioned elsewhere.

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.

Section 12, page 29:  Messages 13, 14, 15, and 16 (from figure 2, page
26) are not shown.  This may be intentional, but probably should be
noted explicitly, as the other requests seem to be shown.

----------------------------------------------------------------------

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