Subject: [Sip] updated GRUU spec

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Jun 2006 21:59:56 -0400

I've just submitted an update to the GRUU spec. Until it appears, you 
can grab a copy here:

http://www.jdrosen.net/papers/draft-ietf-sip-gruu-08.txt

Here are the changes:

* Clarified that when a PSTN GW or media server constructs its own gruu that
routes directly to itself, it still needs to include the GRUU URI param

* Clarify that you should still use "supported: gruu" in dialog
forming requests and responses (per rfc3261) even though you don't
need that to determine if a uri is a gruu

* changed the structure of the grammar, in terms of how we represent
extensions to existing grammar. In particular, it now uses the =/
construct defined in RFC 4234, instead of redefining the grammar for
the parameter it extends. This is a much better way of defining
grammars since it allows for all of the extensions for a particular
protocol to be unioned together and still accurately represent the
overall grammar.

* Previously, if a UA didn't insert a grid parameter into its gruu,
there was no way to differentiate whether an incoming request was sent
to a gruu vs. an AOR. Since there are differing authorization rules
for requests sent to GRUU vs. AOR, this is problematic. Unfortunately,
a problem was reported with just using grid. The problem is that the
correspondent might remove the grid before sending a request to the
GRUU. To fix this, the spec now says that when a home proxy receives a
request sent to a gruu, and the gruu didn't have a grid param and
value in it already, the proxy adds a grid parameter to the r-uri in
the outgoing request, but with no value. The BNF for the grid
parameter has been updated so that it can appear with no value.

* for mid-dialog requests at the home proxy, if there are no route
headers beyond the home proxy (i.e., pointing to an edge proxy), but
there are Path values, those Path values get inserted into the
request as Route headers

* Security considerations section has a paragraph detailing attacks
where a malicious correspondent strips or modifies grid, opaque and
gruu parameters.

* changed grammar for DQUOTE to LDQUOT/RDQUOT

* clarified when the "gruu" URI param can be used in the contact of a
REGISTER. In particular, it says that you can in fact register a gruu
to an AOR, but only if that gruu is associated with a different
AOR. Otherwise, you get infinite loops. Added a check in registrar
processing that rejects a registration that binds a gruu to its
associated AOR

* clarified that a REGISTER response needs neither Require or
Supported

* IANA registry clarifies that gruu option tag does not imply usage of
GRUU

* Removed home proxy processing which was requiring it to remember, for the
duration of a dialog, which contact/flow a request arrived on, or was
sent to. This was previously used to help the home proxy figure out
which contact to use for a GRUU when there were more than one (which
happnes only in the sip-outbound case when a client registers multiple
flows). Originally I thought that you needed to match up the contact
in the mid-dialog request with the flow the original request came on,
but after much consideration it turns out not to matter, as long as an
edge proxy in sip-outbound doesn't look at the r-uri when delvering a
mid-dialog request towards a UA. This is now clear in the latest
sip-outbound, so we are OK.

* updated references

* clarified that third party registrations are permitted

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: Dean Willis <[email-masked]>
Date: Wed, 14 Jun 2006 22:55:50 -0500

On Jun 14, 2006, at 8:59 PM, Jonathan Rosenberg wrote:

> I've just submitted an update to the GRUU spec. Until it appears,  
> you can grab a copy here:
>

Yay! Thank you, Jonathan, for this heroic effort.

Ok, kids. The log book says "GRUU is done". Could you be so kind as  
to read through the new draft and make sure that's right, ASAP? I'd  
like to know whether we have any remaining issues that justify taking  
agenda time in Montreal in time to get the agenda figured out.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 15 Jun 2006 19:22:35 +0200

OK, Dean. Here goes

1) The protocol bits that trigger issueing of a GRUU are "Supported: gruu" 
and a sip.instance id in the Contact header. If "supported" then "MUST issue 
GRUU". If you compare this with e.g. 100rel it seems a bit odd, Supported: 
100rel does not force the server to use it. How about Supported -> SHOULD, 
Require -> MUST ? (could a domain have reasons not to honor the request for 
GRUUs?)

1a) Which error response if "Supported: gruu" but missing sip.instance? bad 
request?

2) There are several references to "dialog-creating" requests and responses 
for which GRUU can be used. This should be extended to include 
"target-refresh" requests such as UPDATE, and REGISTER (in rare cases)

3) section 6: the list on GRUU properties that MUST be exhibited should 
probably include "if the URI includes an "opaque" parameter, the base MUST 
be an AoR". The text later on depends on this

4) 7.1.1.1 says "MUST include Supported" . Does "Require" imply "Supported"?

5) 7.1.2.1 the part that says "MUST do so at this time" is too early. The 
REGISTER might be constructed according to outbound without Supported: gruu. 
I think 7.1.2.1 should start with "If REGISTER contains Supported: gruu, 
THEN { process as described here }"

6) 7.1.2.1 talks only about Supported, should probably say "Supported or 
Require"

7) 8.2.1 : I still feel that GRUU offers a great opportunity to start 
introducing looser routing. The spec already requires modifications to both 
proxies and UAs, so saying "proxy adds Route header" instead of "proxy 
rewrites request URI" seems a small effort. We'll be sorry later if we don't

8) c-p-gruu        =  "gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) RDQUOT, 
another draft authored by JR uses "DQUOTE" here...do we want consistency?

9) Section 12: some of the to-headers have the closing '>' one line too 
early; last message is missing an <allOneLine> start tag

Regards,

jeroen

> Ok, kids. The log book says "GRUU is done". Could you be so kind as  to 
> read through the new draft and make sure that's right, ASAP? I'd  like to 
> know whether we have any remaining issues that justify taking  agenda time 
> in Montreal in time to get the agenda figured out.
>
> --
> Dean
>
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 15 Jun 2006 15:31:05 -0500

> OK, Dean. Here goes

ask and ye shall receive . . .

>
> 1) The protocol bits that trigger issueing of a GRUU are  
> "Supported: gruu" and a sip.instance id in the Contact header. If  
> "supported" then "MUST issue GRUU". If you compare this with e.g.  
> 100rel it seems a bit odd, Supported: 100rel does not force the  
> server to use it. How about Supported -> SHOULD, Require -> MUST ?  
> (could a domain have reasons not to honor the request for GRUUs?)
>

We had an extended thread on that one, and ended up with the current  
position.

Supported: alone cannot require a UAS to do anything. It's just a  
hint that tells the UAS (in this case the registrar) that the UAC  
supports a specific extension and cn be expected to behave accordingly.

Require: also cannot force a UAS to use an extension -- it just makes  
sure that the UAS understand the extension, which is not the same  
thing. For example, I understand polygamy, I just don't use it (well,  
I might someday, but I'm single right now).

The basic idea is that it any UA that supports GRUU and issues a  
request with a sip.instance ID is asking for and really wants A GRUU.  
So a registrar that understands GRUU must issues one when the client  
asks for it or reject the request if it can't.

> 1a) Which error response if "Supported: gruu" but missing  
> sip.instance? bad request?
>

None. We just don't issue a gruu if we don't want to. The UAC hasn't  
insisted that it really wants one, so that's OK.

> 2) There are several references to "dialog-creating" requests and  
> responses for which GRUU can be used. This should be extended to  
> include "target-refresh" requests such as UPDATE, and REGISTER (in  
> rare cases)

Yeah, probably true.

>
> 3) section 6: the list on GRUU properties that MUST be exhibited  
> should probably include "if the URI includes an "opaque" parameter,  
> the base MUST be an AoR". The text later on depends on this
>

Ok, that's worthy of consideration.

> 4) 7.1.1.1 says "MUST include Supported" . Does "Require" imply  

Nope. Require does not imply Supported. Strange but true.

> 5) 7.1.2.1 the part that says "MUST do so at this time" is too  
> early. The REGISTER might be constructed according to outbound  
> without Supported: gruu. I think 7.1.2.1 should start with "If  
> REGISTER contains Supported: gruu, THEN { process as described here }"
>

Ok, this might need talking about.

> 6) 7.1.2.1 talks only about Supported, should probably say  
> "Supported or Require"
>

I don't think so -- as above, Require does not imply Supported.

> 7) 8.2.1 : I still feel that GRUU offers a great opportunity to  
> start introducing looser routing. The spec already requires  
> modifications to both proxies and UAs, so saying "proxy adds Route  
> header" instead of "proxy rewrites request URI" seems a small  
> effort. We'll be sorry later if we don't

I'm already sorry ;-(.

But we seem to have a consensus to do the route construction  
modification separately.
>
> 8) c-p-gruu        =  "gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI)  
> RDQUOT, another draft authored by JR uses "DQUOTE" here...do we  
> want consistency?

I thought the grammar guideline changed when the new grammar RFC came  
out. I'm not a BNF whiz though -- anybody know for sure?

>
> 9) Section 12: some of the to-headers have the closing '>' one line  
> too early; last message is missing an <allOneLine> start tag

Grr. Ok, that's a bug.

Ok, we have some probably things listed above that would need to be  
fixed before sending to IESG and are probably not needing a realtime  
discussion: your questions 2, 8, and 9 probably fall into this.

3 and 5 need talking about.

1, 4, and 6 I think I've answered, and 7 we had a pre-existing  
consensus about that we can change our minds on but probably won't.

Let's try and dissect 3 and 5 on the list in the next day or so and  
see if they close off.

Thanks!

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Jun 2006 15:18:34 -0400

inline.

Dean Willis wrote:

>> 1) The protocol bits that trigger issueing of a GRUU are  "Supported: 
>> gruu" and a sip.instance id in the Contact header. If  "supported" 
>> then "MUST issue GRUU". If you compare this with e.g.  100rel it seems 
>> a bit odd, Supported: 100rel does not force the  server to use it. How 
>> about Supported -> SHOULD, Require -> MUST ?  (could a domain have 
>> reasons not to honor the request for GRUUs?)
>>
> 
> Supported: alone cannot require a UAS to do anything. It's just a  hint 
> that tells the UAS (in this case the registrar) that the UAC  supports a 
> specific extension and cn be expected to behave accordingly.
> 
> thing. For example, I understand polygamy, I just don't use it (well,  I 
> might someday, but I'm single right now).
> 

The thing that is requiring the registrar to give out a GRUU is the 
spceification itself. As Dean says, Supported means that the client 
understands gruu and is prepared to receive one. The registrar hands one 
out if it supports gruu too. If the registrar doesn't, the registration 
is processed normally. The bit I disagree with Dean on is that the 
registrar never rejects the request. Only case that happens is if the 
client puts a Require in the REGISTER, and the registrar doesn't support 
gruu.

Indeed, note that the registrar will create a gruu even if the client 
doesn't support it, as long as instance ID was there. The reason is that 
even though the client doesn't support gruu, other elements listening to 
reg-event will get notified, and with the gruu reg-event extension, need 
to see that gruu. This is called out later in the spec:

   Inclusion of a GRUU in the "gruu" Contact header field parameter of a
    REGISTER response is separate from the computation and storage of the
    GRUU.  It is possible that the registrar has computed a GRUU for one
    UA, but a different UA that queries for the current set of
    registrations doesn't understand GRUU.  In that case, the REGISTER
    response sent to that second UA would not contain the "gruu" Contact
    header field parameter, even though the UA has a GRUU for that
    contact.

> insisted that it really wants one, so that's OK.

Slight correction - it *can't* issue a gruu at all for contacts without 
instance ID. Remember that a GRUU is bound to an AOR and instance ID. 
So, unless you have both, you can't issue one. Its not like it just 
doesn't want to; it cannot.

Its really important to understand that in NO WAY is this an error 
condition (contacts without instance ID). Third party registrations, for 
example, are allowed and will typically not contian an instance ID.

>> include "target-refresh" requests such as UPDATE, and REGISTER (in  

Right - fixed.

> Ok, that's worthy of consideration.

Correct. I added that.

> Nope. Require does not imply Supported. Strange but true.

Right. I added a sentence to clarify that.

> 
>> 5) 7.1.2.1 the part that says "MUST do so at this time" is too  early. 
>> The REGISTER might be constructed according to outbound  without 
>> Supported: gruu. I think 7.1.2.1 should start with "If  REGISTER 
>> contains Supported: gruu, THEN { process as described here }"
>>
> 

I don't understand the issue you are raising. If the REGISTER is 
constructed using sip-outbound there is still an instnace ID. What changes?

> 
>> 6) 7.1.2.1 talks only about Supported, should probably say  "Supported 
>> or Require"
>>
> 

Right - its just Supported.

>> introducing looser routing. The spec already requires  modifications 
>> to both proxies and UAs, so saying "proxy adds Route  header" instead 
>> of "proxy rewrites request URI" seems a small  effort. We'll be sorry 
>> later if we don't
> 
> 
> I'm already sorry ;-(.
> 

Right. We have the tools (via Require/Supported) to negotiate it separately.

>> RDQUOT, another draft authored by JR uses "DQUOTE" here...do we  want 
>> consistency?
> 
> 

No - this is a change I made based on private comments on the draft. 
Doing this makes it consistent with 3261 syntax, which uses 
LDQUOT/RDQUOT around header parameters.

>> too early; last message is missing an <allOneLine> start tag

Good catch. I fixed two instances of the early '>' and the missing 
allOneLine.

Thanks,
Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 16 Jun 2006 23:34:29 +0200

Jonathan,

inline

Regards,

jeroen

>    header field parameter, even though the UA has a GRUU for that

I did not make the connection that through reg-event another element could 
receive the GRUU, and use it / distribute it. As a consequence, the UA could 
receive a request with a request URI containing something else than its 
registered Contact. Harmless enough I suppose

>>
>>> 1a) Which error response if "Supported: gruu" but missing  sip.instance? 
>>> bad request?
>>>
>>
> instance ID. Remember that a GRUU is bound to an AOR and instance ID. So, 
> unless you have both, you can't issue one. Its not like it just doesn't 
> want to; it cannot.
>

Perhaps worth mentioning as a valid case (note to implementors)

> constructed using sip-outbound there is still an instnace ID. What 

it was related to my assumption that a registrar would have no need to 
create a GRUU if the UA did not support it

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Jun 2006 18:55:51 -0400

inline.

Jeroen van Bemmel wrote:

>> doesn't support it, as long as instance ID was there. The reason is 
>> that even though the client doesn't support gruu, other elements 
>> listening to reg-event will get notified, and with the gruu reg-event 
>> extension, need to see that gruu. This is called out later in the spec:
>>
> I did not make the connection that through reg-event another element 
> could receive the GRUU, and use it / distribute it. As a consequence, 
> the UA could receive a request with a request URI containing something 
> else than its registered Contact. Harmless enough I suppose

Not quite. When the reg-event subscriber sends a request to the GRUU, it 
will arrive at the home proxy, where the r-uri is translated to the 
registered contact. The only bit of weirdness is that, per the -08, that 
request will have a grid parameter added to it, and the UA will receive 
a request whose r-uri looks like its registered contact except with the 
addition of grid. There should be no harm in that.

TO clarify that this use case is possible, I updated the above paragraph 
as follows:

<t>
Inclusion of a GRUU in the "gruu" Contact header field parameter of a
REGISTER response is separate from the computation and storage of the
GRUU. It is possible that the registrar has computed a GRUU for
one UA, but a different UA that queries for
the current set of registrations doesn't understand GRUU. In that
case, the REGISTER response sent to that second UA would not contain
the "gruu" Contact header field parameter, even though the UA has a
GRUU for that contact. Similarly, a UA might send a REGISTER request
with a contact containing a "+sip.instance" Contact header field but
no "gruu" option tag in the Supported header field. The registrar can
still assign a GRUU, and indeed, a subscriber to the registration
event package could learn the GRUU from the notification <xref
target="RFC3680"/> <xref target="I-D.ietf-sipping-gruu-reg-event"/>.
</t>

>> Slight correction - it *can't* issue a gruu at all for contacts 
>> without instance ID. Remember that a GRUU is bound to an AOR and 
>> instance ID. So, unless you have both, you can't issue one. Its not 
>> like it just doesn't want to; it cannot.
>>
>> condition (contacts without instance ID). Third party registrations, 
>> for example, are allowed and will typically not contian an instance ID.
>>
>>
> 

OK, I added a sentence about that, so it reads:

<t>
A UA MAY perform third party registrations (registrations where the
entity performing the registration is not the same as the AOR in the
To header field of the registration), and as in the above
paragraph, MAY register contacts that do not point to the UA
performing the registration. In addition, a UA MAY register contacts
which omit the "+sip.instance" Contact header field parameter, in
which case they would not be associated with any GRUU.
</t>

Look OK? I'll submit a -09 if it looks like your comments are all addressed.

Thanks,
Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 17 Jun 2006 10:50:39 +0200

> Look OK? I'll submit a -09 if it looks like your comments are all 

Yes, please proceed

Regards,

Jeroen

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 22 Jun 2006 17:25:57 -0400

From: "Jeroen van Bemmel" <[email-masked]>

Actually, what triggers *constructing* a GRUU is (1) Registrar
implements GRUU, and (2) Contact contains +sip.instance.  What
triggers adding the gruu header-parameter in the response is (1) and
(2) along with (3) "Supported: gruu" in the request (so the Registrar
knows that the UAC can cope with it).

(As I was reading the I-D, I wondered why the UAC could send
+sip.instance without first discerning that the Registrar supported
it, but the Registrar could not send gruu without first discerning
that the UAC supported it.  But I think that's because +sip.instance
is identifiable as a caller preference, and there is a defined way for
UASs to deal with a caller preference it does not understand.)

So if a UA wants to get a GRUU when it can, but not get its
registration rejected if it cannot, it uses Supported: gruu and
+sip.instance.  If the Registrar implements gruu, it MUST send a gruu
in response.  But if a UA wants to make sure it gets a GRUU (and gets
its REGISTER rejected with 420 if it cannot), it uses Supported: gruu,
Require: gruu, and +sip.instance.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 11:24:27 -0400

inline.

Dale R. Worley wrote:

> implements GRUU, and (2) Contact contains +sip.instance. 

Exactly.

> What

Exactly.

> UASs to deal with a caller preference it does not understand.)

There is no need for the client to discover registrar support for gruu 
prior to registration, because there is no harm in including 
+sip.instance even if the registrar doesnt support it. Indeed, if ALL 
the registrar/proxy supports is rfc3841, then +sip.instance is still 
usable with that (though not terribly valuable).

> +sip.instance.

Right, and this is what it normally ought to do.

>  If the Registrar implements gruu, it MUST send a gruu

Only caveat is that require just makes sure the registrar supports gruu; 
it doesn't FORCE the proxy to hand you out a gruu. Policy may, for some 
reason, still tell it not to hand you a gruu since you've been a bad boy 
this year.

-Jonathan R.