Subject: [Sip] gruu-10 focused review comments

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Aug 2006 21:47:02 -0500

These are my review comments in the form requested by Keith.

Summary:

I believe this document to be technically correct, modulo the  
questions that I brought to the list separately. I also believe it  
reflects WG discussions to date. However, it appears to me to still  
be in the "result of lots of arguing about little things" stage from  
a clarity point of view and would benefit greatly from another strong  
editorial revision (I think most non-IETF-attending implementors will  
give up reading before completing the current document).

General comments:

I have, since this whole idea got traction, felt discomfort with what  
this extension will do to the architecture of future systems if it is  
not applied with reason. The simple lazy "well, lets just always use  
a GRUU because then it will always work" approach leads to a world  
where there is _NEVER_ a SIP transaction that doesn't involve a  
"service provider" (I really had to fight with myself to not write  
gatekeeper just then). This consequence is lightly explored on page  
19 - I would like it to see it under a much brighter spotlight, and I  
would like to see some guidance that would prevent unnecessary GRUU  
proliferation. Don't take this as a desire to not have GRUUs - I do  
agree that we need them for UAs that can't otherwise be reached. I  
just don't want to put out the firemen while putting out the fire.

There is a lot of text that reduces to "If you implement that  
extension over there, do what that extension tells you what to do".  
It was important during development of the text to make sure we  
worked in the context of those extensions, but having completed that  
exercise, I think we can safely elide the text (or reduce it to one  
standalone section). (outbound was bugging us at the time, so there's  
a bunch of outbound text here that doesn't really belong - we don't  
have, for instance, discussion of 183 using 100rel everywhere it  
might make sense)

There are some concepts that this document seems to create, but  
doesn't formally define or  borrow some other formal definition. The  
one that bugs me the most is "home proxy".

I got really lost during a linear read-through on what the  
requirements around including opaque, and instance ID were,  
especially when it came to being able to remove them and infer things  
from the result. After digging at it, I think the document is  
internally consistent (but don't feel 100% confident there). It would  
be very good to condense these into one authoritative set of statements.

I have not attempted to be comprehensive with grammar nits in the  
comments below - I captured things as I spotted them, but I hope  
we'll be doing a nit review of a revision and saved that level of  
effort for that time.
Those I captured, I'll send to Jonathan directly.

---
Location: Section 5 2nd paragraph
Nature: editorial
Suggested fix: This extension defines two separate mechanisms. The  
first provides one way for a UA to obtain a GRUU. The second allows a  
UA to use a GRUU, regardless of how it obtained it. <t/><t> This  
extension defines the protocol operations for obtaining GRUUs through  
registration, and discusses the alternative of obtaining GRUUs  
through administrative operation.
---
Location: Section 5 3rd paragraph, last sentence
Nature: minor technical
Suggested fix:
    OLD:     instance identifier, the server
    NEW:    instance identifier against the same AoR, the server
---
Location: Section 5 7th paragraph (first full text paragraph on page 9)
Nature: editorial
Comment: The first sentence (containing "it would set the value")  
will be taken as normative by the implement-the-examples crowd. This  
sentence is true only for one of the suggestions for forming opaque.
Suggested fix: change "would set" to "might set"
---
Location: Section 5 8th paragraph, last sentence
Nature: editorial
Comment: For the first time reader, the consequence described in the  
last sentence is not yet obvious.
Suggested fix: replace the last sentence with "This allows the UA to  
tell that the request was originally sent to a GRUU with no grid  
instead of to an AOR".
---
Location: Section 6 first paragraph on page 10.
Nature: minor technical
Comment: the instance identifier uniquely identifies the agent  
amongst all other user agents (full stop).
Suggested fix: delete "associated with an AOR"
---
Location: Section 6 second paragraph on page 10
Nature: editorial
Comment: I think the diagram covers this paragraph sufficiently and  
suggest either deleting the paragraph or starting it off with  
something along the lines of "this paragraph describes the figure 3  
in text form".
---
Location: Section 6 second paragrpah (starting "The contacts that are  
bound")
Nature: editorial
Comment: The important message here (the last two sentences) gets  
lost under the wieght of the first part of the paragraph. That first  
part loses me completely, so I'm having a hard time suggesting  
alternative text. Would anything be lost if it were deleted?
---
Location: Section 6, page 11 second bullet.
Nature: minor technical
Comment: As you point out elsewhere, the thing that is responsible  
for resolving the GRUU may not actually be a proxy.
Suggested fix: delete proxy from the last sentence in this bullet  
(leaving "route to a server with access"
---
Location: Section 6, page 12 first paragraph (Starting "Section 8.2")
Nature: editorial
Comment: This section is about the creation of GRUUs - this sentence  
doesn't belong here.
Suggested fix: Delete the sentence
---
Location: Section 6, page 12, paragraphs 2 through 5 (starting with  
"When a domain constructs")
Nature: editorial
Comment: The first of these paragraphs is a no-op and can safely go  
away. The second and third are all about _USING_ GRUUs, not forming  
them and doesn't belong in this section. Thier content is covered  
elsewhere.
Recommendation: Delete these three paragraphs
---
Location: Section 6, page 12, last full paragraph (starting with "Mid- 
dialog requests), last sentence
Nature: minor(ish) technical
Comment: You can get URIs into Route headers of initial requests.  
There is the possibility that this URI would be the same as what you  
might have record-routed with if this were a mid-dialog request.  
Using Route to distinguish initial requests from mid-dialog requests  
is not safe as specified here. Given that things like "screening  
services" are not well defined, I am very nervous about putting  
normative text around their invokation. It's still very unclear to me  
that you would ever want to do something different with a GRUU at a  
proxy if you encountered it in or outside a dialog. If there's a  
feature that relies on this knowledge, that feature should be asking  
the UA to participate in giving the featuure-server the information  
it needs to not do the wrong thing.
Suggested fix: Reduce the strength of the text exploring different  
services to descriptive. Remove the in-vs-out of dialog distinction  
text.
---
Location: Section 6, last paragraph
Nature: technical
Comment: Raised in a separate thread (infinite state storage)
---
Location: Section 7, top of page 14, first fractional sentence
Nature: editorial
Comment/Suggested Fix: Can we put a pointer to wherever we have  
guidance on how to form these instance ID values at the end of this  
sentence?
---
Location: Section 7, 1st full paragraph page 14
Nature:  technical
Comment: This RECOMMENDED almost has a "why this isn't must", but  
it's not quite all there. Why isn't it a MUST? Is it because UAs can  
do this differentiation in other ways (I'm not sure I see one), or is  
it that there are some UAs that won't care?
---
Location : Section 7, 2nd full paragraph - page 14 (If a UA instance  
is trying to register multiple contacts...)
Nature editorial/technical
Comment: Can we scope this paragraph to GRUUs or delete it? This  
feels like a very odd general requirement. Even scoped to GRUUs this  
feels like an inappropriate MUST. Advisory text along the lines of  
"GRUUs are not intended to provide redundancy through the use of  
multiple contacts. Implementations seeking that functionality should  
utilize the mechanisms in [11] instead." would be better.
---
Location: Section 7, third full paragraph page 14.
Nature editorial/technical
Comment: For the last two sentences, which are attempting to avoid  
GRUU loops, it's not clear if this is a place where the contact  
violates the SHOULD NOT above it with respect to not containing the  
"gruu" header field (or is it URI) parameter, or if this is a contact  
that has no instance-id, gruu, or grid parameters but is still  
(somehow) a GRUU?
---
Location: Section 7, fourth full paragraph page 14.
Nature: editorial
Comment: This doesn't appear to add anything that we don't already  
say or get from 3261. Suggest striking it.
---
Location: Section 7, 5th full paragraph page 14 (starting "If a UA  
wishes to guarantee")
Nature: minor technical
Suggested fix:
   OLD: guarantee that the request is not processed
   NEW: guarantee that the REGISTER request is not processed
---
Location: Section 7, 5th full paragraph page 14 (starting "If a UA  
wishes to guarantee")
Nature: editorial
Suggested fix:
   OLD: option tag. This is in addition to the presence of the  
Supported header field.
   NEW: option tag, in addition to a Supported header field also  
containing the "gruu" option tag.
---
Location: Section 7.1.1.2 first paragraph
Nature: editorial
Comment: This whole paragraph is subjugate to the if in the next  
paragraph. Suggest restructuring it so everythings under one IF clause.
---
Location: Section 7.1.1.2 first paragraph
Nature: editorial
Comment: Its not clear what "extract the contacts" means here
---
Location: Section 7.1.1.2 page 15 first paragraph
Nature: editorial
Comment Can we pull the SIP/SIPS behaviors out into one paragraph  
standing on its own in the document? It should be a simple one. As it  
stands, my head was swimming after the sentence in this paragraph  
enough that I couldn't track the next idea.
---
Location: Section 7.1.1.2 page 15 first paragraph somewhere near the  
middle (look for "domain to a contact with" at the start of a line
Nature: minor technical
Comment/fix: Suggest changing to "domain to the contact with"
---
Location: Section 7.1.1.2 page 15, last paragraph before 7.1.2
Nature: technical
Comment: This paragraph implies that you _can_ remove, delete, or  
otherwise invalidate a GRUU through some mechanism. What is it?
As far as I can tell, it's ONLY through the administrative removal of  
the AoR. I think this paragraph may have meant to be talking about the
contacts that might be bound to the GRUU, not the GRUU itself.
Suggested fix: Change this paragraph to explicitly talk about the  
contacts bound to the GRUU. Add a paragraph noting that GRUUs are never
deleted through the mechanisms in this document - that they only go  
away through administrative removal of the AoR they are associated with.
---
Location: Section 7.1.2 second paragraph.
Nature: editorial
Comment: This will be read to say there are THREE URIs, the GRUU and  
the SIP and SIPS versions of the GRUU.
Suggested fix. Remove all the SIP/SIPS treatment to its own section,  
avoid this particular sentence construct in that section.
---
Location: Section 7.1.2.1 first paragraph
Nature: minor technical
Comment/fix: add  "containing the 'gruu' feature tag" after "might  
contain a Require header field:.
---
Location: Section 7.1.2.1 top paragraph on page 16
Nature: technical/editorial
Comment: This says to create a GRUU according to the procedures of  
Section 6, but there are no procedures in section 6, only  
characteristics, a statement that the process of creation is  
implementation dependent, and pointers to the appendix for how one  
might go about such creation.
Suggested fix: s/proceedures/requirements/
---
Location: Section 7.1.2.1 top paragraph on page 16
Nature: editorial
Comment: The pronouns in this paragraph are ambiguous. "it MUST be  
ignored", "they MUST be discarded"
Suggested fix: use the nouns
---
Location: Section 7.1.2.1 first paragraph, last sentence
Nature: confused
Comment: This sentence says contacts omitting the instance parameter  
are not processed by the rules in this specification, but back on  
page 14, you talk about registering GRUUs as contacts but leaving of  
the instance id. Is that that resulting thing a GRUU or not? Either  
this paragraph or the third full paragraph on page 14 needs  
clarification.
---
Location: Section 7.1.2.1 third paragraph page 16
Nature: minor technical
Comment: Why does the registrar put the instance id in the contact  
header field if the request didn't contain Supported: gruu? A  
registrar that doesn't know gruu isn't going to do this. A UA that  
doesn't know GRUU or outbound isn't going to use it? This looks like  
a setup for a subtle interop problem later.
----
Location: Section 7.1.2.1 fourth paragraph last sentence
Nature: editorial/minor technical
Comment/fix: change the end of the last sentence from "a GRUU" to  
"any GRUU that is bound to that AoR".
---
Location: Section 7.1.2.1 (no specific place)
Nature: minor technical
Comment; It would be useful to point out somewhere that this  
specification SPECIFICALLY doesn't allow a contact to be bound into  
the system that will be reached when the GRUU is accessed, but not  
reached when the AOR is accessed.
---
Location: Section 7.1.2.1 last paragraph
Nature: minor technical
Comment: This looks like normative requirements (MUST NOTs?) in  
disguise.
---
Location: Section 7.2 4th paragraph last sentence
Nature: editorial/technical
Comment: This requirement is very undermotivated. Why must I include  
the gruu parameter here. Who's going to care and do anything  
different with it? Normally it would be the thing resolving the GRUU,  
but in this case, THAT'S ME, not some other proxy. Why are we trying  
to put requirements on how I talk to myself?
---
Location: Section 8.1.1 first paragraph
Nature: editorial
Comment: as written, there will be some implementer that won't let  
you use a third-party gruu (one obtained through a REFER for example)  
because you don't have an active registration for it.
Suggested fix: Put a paragraph break after the first sentence.  
Replace the second sentence  with "A UA MUST NOT use a GRUU it  
obtained through registration unless that registration is still
active."
---
Location: Section 8.1.1 second paragraph
Nature: editorial
Comment: When would an implementation consider violating this SHOULD?  
We should document this (see my architectural concern at the  
beginning) or make this a MUST and be done with it.
---
Location: Section 8 (generally)
Nature: editorial
Comment: (from the beginning) "home proxy" starts to creep in here
---
Location: Section 8.1.1. last paragraph page 18 (first on page 19)
Nature: editorial
Comment: I can't parse much of this - the sentence on using service  
route in particular eludes me.
Suggested fix: I don't have one yet - will keep trying to make this  
make sense.
---
Location: Section 8.1.1 last paragraph page 19
Nature: editorial
Comment/fix: change "in requests it generates" to "in all requests it  
generates"
---
Location : Section 8.1.2 2nd and third paragraphs
Nature: editorial
Comment: What does any of this have to do with Sending a message to a  
GRUU (the section title)
Suggested fix: Create a new section for these two paragraphs "Sending  
a request to an AOR derived from a GRUU"
---
Location 8.2.1, 8.2.2 8.2.3
Nature: editorial/technical
Comment; (See thread on whether we really need to separate in-vs-out- 
of-dialog
---
Location: Security considerations
Nature: minor technical
Comment: We talk about how there is no privacy coming from a GRUU and  
how we can guess instance-ids or repeated instance-ids with against a  
given AoR, but I don't think we talk about hotelling. If you know the  
last person that used a particular device (because you knew they were  
in a cube or a hotel room) and you watched the instance-id they used,  
then if you know the next person using that device, you can guess a  
gruu for them. Does that do you any good? Imagine you were traveling  
and were letting your assistant (we all have those, right) answer  
your calls, but you'd grab them if it rang more than twice...

_______________________________________________
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: Tue, 22 Aug 2006 17:01:56 -0400

I sent my comments to gruu-09 and Jonathan dealt with them in gruu-10. 
So I am going to just comment on some of Robert's comments.

	Paul

Robert Sparks wrote:

> header field if the request didn't contain Supported: gruu? A registrar 
> that doesn't know gruu isn't going to do this. A UA that doesn't know 
> GRUU or outbound isn't going to use it? This looks like a setup for a 
> subtle interop problem later.

I think the problem with the text is only in calling this out as if it 
was a special action, which it is not.

The registrar puts it because it puts all the contact header parameters 
from the register into the response by default. If the registrar did not 
support gruu it would still do this.

The only special action is inclusion of the "gruu" *header* parameter, 
containing the assigned gruu.

> Comment: This requirement is very undermotivated. Why must I include the 
> gruu parameter here. Who's going to care and do anything different with 
> it? Normally it would be the thing resolving the GRUU, but in this case, 
> THAT'S ME, not some other proxy. Why are we trying to put requirements 
> on how I talk to myself?

This is in support of a point that is only hinted at:

According to 3261, contacts should always be gruus. But common practice 
has evolved that they are not. So common practice has also evolved to 
implement features on the assumption that contacts received from others 
are not gruus. It does no good to start migrating to a world where 
contacts may be gruus if you can't tell which are and which are not. 
That is the purpose of the gruu uri parameter - so that others will 
believe that this contact is a gruu, and implement their features with 
that in mind.

What is lacking is an explanation of that and a recommendation to 
implement features assuming the URI is globally routable if it contains 
a "gruu" parameter. I had been thinking this was already there until I 
had occasion to go looking for it. (I'm sending that as a comment of my 
own.)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Aug 2006 17:00:50 -0400

I sent my comments earlier, against -09, and Jonathan dealt with them. 
But I recently realized I had a new one. Hope it isn't too late.

	Paul

Location: Section 8.1.2
Nature: minor technical

Comment: According to 3261, contacts should always be gruus. But common 
practice has evolved that they are not. So common practice has also 
evolved to implement features on the assumption that contacts received 
from others are not gruus. It does no good to start migrating to a world 
where contacts may be gruus if you can't tell which are and which are 
not. That is the purpose of the gruu uri parameter - so that others will 
believe that this contact is a gruu, and implement their features with 
that in mind.

What is lacking is an explanation of that and a recommendation to 
implement features assuming the URI is globally routable if it contains 
a "gruu" parameter. I had been thinking this was already there until I 
had occasion to go looking for it.

Suggested fix: Replace the first paragraph as follows:

OLD:
    There is no new behavior associated with sending a request to a GRUU.
    A GRUU is a URI like any other.  When a UA receives a request or
    response, it knows that the remote target is a GRUU by the presence
    of the "gruu" URI parameter.  The UA can take the GRUU, send a
    request to it, and then be sure that the request is delivered to the
    UA instance which sent the request or response.

NEW:
    A GRUU is a URI like any other.  When a UA receives a request or
    response, it knows that the remote target is a GRUU by the presence
    of the "gruu" URI parameter.  The UA can take the GRUU, send a
    request to it, and then be sure that the request is delivered to the
    UA instance which sent the request or response.

    For UACs that have been assuming the URIs in contact headers in
    messages from others are globally routable there is no new behavior
    associated with sending a request to that URI when it is a GRUU.

    However some UACs have been assuming that URIs in received contact
    headers are not globally routable, and using ad hoc techniques when
    targetting requests to them. (E.g. Using the To or From-URI instead
    of the contact URI, or sending a new request in-dialog when an
    out-of-dialog request would otherwise be preferred.) A GRUU-aware
    UAC SHOULD treat a URI containing a "gruu" URI-parameter as globally
    routable, and condition its actions accordingly, if it would
    otherwise consider that URI to not be globally routable.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Aug 2006 22:44:33 -0400

Dean Willis wrote:
> 
> On Aug 22, 2006, at 4:00 PM, Paul Kyzivat wrote:
> 
> I'll paste my confusion in-line.
> 
> But we've already got people talking about redirecting or retargeting 
> requests that were sent to a GRUU -- perhaps in the UA, or perhaps in 
> some proxy.
> 
> And the GRUU, despite being "universally routable", isn't necessarily 
> reachable. It is just more likely to be reachable than the real Contact.

That is the part I left unchanged from the original.

> I like the preceding.
> But the last sentence of the preceding lost me. It's a URI. Since I know 
> it is supposed to be a GRUU, I should try it before trying tricky 
> transforms on the other URIs I have available (including AOR). But I 
> might NOT actually be able to reach it. Are there still use cases where 
> I'm going to fall back and try something tricky?

I guess I'm not being successful in saying what I mean. I'm classifying 
UAs into two classes:

- those that assume a contact is globally routable and use it when 
implementing features. (E.g. Refer-To it.)

- those that do something else. (e.g. Refer-To the To-URI.)

When the first kind are updated to support gruu they don't need to do 
nothing new.

When the second kind are updated to support gruu, they can continue 
unchanged for contacts lacking the gruu parameter. But for contacts 
containing the gruu parameter they should give up their paranoia and act 
like the first kind.

	Paul

> -- 
> Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Aug 2006 21:04:13 -0500

I like the preceding.

>    otherwise consider that URI to not be globally routable.

But the last sentence of the preceding lost me. It's a URI. Since I  
know it is supposed to be a GRUU, I should try it before trying  
tricky transforms on the other URIs I have available (including AOR).  
But I might NOT actually be able to reach it. Are there still use  
cases where I'm going to fall back and try something tricky?

--
Dean