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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jul 2006 00:32:59 -0400

inline.

[email-masked] wrote:

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

Thanks!

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

Well, this topic has come up for the term URI, which is the last U in 
GRUU. So it would stand to reason that if the plural of URI is URIs, 
then the plural of GRUU is GRUUs. I found some email threads on this 
topic, for example:

http://lists.w3.org/Archives/Public/www-tag/2002Aug/0124.html

and apparently this was an open issue in the preparation of the revision 
to 2396:

http://www.gbiv.com/protocols/uri/rev-2002/issues.html#023-URI-plural

the conclusion appears to be that the plural of URI is URIs. So, I 
suggest we follow suit and have the plural of GRUU be GRUUs.

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

fixed.

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

fixed.

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

Well, thats debatable. The owner of the domain could key off just the 
opaque parameter in fact. However, I just deleted this bit as you 
suggest since it can be misinterpreted.

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

good catch.

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

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>

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

fixed.

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

fixed.

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

I'd like to give an example of what I'm talking about here. I'll say, 
"which can be the case for administratively constructed GRUUs, for example)

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

ok.

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

Good catch. Leftovers for when the instance ID was defined here.

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

Thats what the grammar says now. I don't see why its not 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.

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?

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

Its intentional. Not all messages are shown, but most are at least 
mentioned. I now mention these.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jul 2006 09:24:17 -0400

> suggest we follow suit and have the plural of GRUU be GRUUs.

Hey, that's not fair!

I was looking for a precedent when cleaning up 
draft-ietf-sipping-gruu-reg-event-06, and noticed there was 
inconsistency in draft-ietf-sip-gruu. We discussed this, and I thought 
we decided that the plural is GRUU. I made my draft consistent with that.

If you decide this way then I should respin 
draft-ietf-sipping-gruu-reg-event.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jul 2006 23:10:03 -0400

Oops - sorry to change my mind on this. I vaguely recall discussing this 
issue previously, but didn't remember that we concluded anything. There 
are some actual arguments in the threads and links I found arguing why 
URIs is better than URI (namely, its clear whether its plural or 
singular), that apply to GRUU too. So, I do think we should go with 
GRUUs and I've already made this edit in my working version of -10.

-Jonathan R.

Paul Kyzivat wrote:

>> and apparently this was an open issue in the preparation of the 
>> revision to 2396:
>>