Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea)

From: "Sean Olson" <[email-masked]>
Date: Thu, 3 Nov 2005 16:57:02 -0800

Well, if GRUU ==  Globally Routable UA URI, and you treat a URI as a
GRUU which does not have one of these properties, things will break. If
you care when things break, you would want to know in advance. This
would apply to UAs, proxies, etc. You could make the argument that all
URIs should be GRUUs so what you really want is a property that says a
URI is *not* at a GRUU and assume all others are ;-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Thursday, November 03, 2005 4:41 PM
To: Jeroen van Bemmel
Cc: Sip
Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was:
Alert-Info Idea)

On Nov 3, 2005, at 4:15 PM, Jeroen van Bemmel wrote:
>
> I understood GRUU as a property of the URI, not the resource itself. I

> did not receive an answer to that, and don't know if it would change 
> the outcome of this discussion.
>

I agree with the assertion that GRUU is a property of the URI, not of
the resource indicated by the URI.

However, I'm not certain that we need to know that the URI has the "GRUU
properties". More on that later.

> As to the second part of my argument - that for other use cases 
> clients won't know the URI is a GRUU - Jonathan's reply was: "In all 
> of these cases, I don't think the recipient of the URI would do 
> anything differently if it knew it was a gruu, as opposed to if it 
> didnt. A GRUU is just a URI that has the property that URIs in 
> Refer-To, contact and PIDF need to have in order to work right anyway.

> To date, we havent had a way to produce those URI reliably.
> Now we do."
>
> So the question is: would the other side (or proxies on the path) 
> behave differently when the Supported: gruu header is present?
>
> The motivation given in the draft-06 states: "[...] since the remote 
> target used by clients to date has typically not had the GRUU 
> properties, implementations have adapted their behaviors (oftentimes 
> in proprietary ways) to compensate.  To facilitate a transition away 
> from these behaviors, it is necessary for a UA receiving the message 
> to know whether the remote target is a GRUU or not." (section 5, 
> non-normative)
>
> In other words: "Supported: gruu" is a signal to implementations to 
> ~not~ "adapt their behavior". So the assumption is that they would 
> behave differently without the "Supported: gruu".
>
> If this line of reasoning is followed, I think it should be applied 
> consistently. By implication it should also be indicated if the 
> Refer-To URI is a GRUU or not, under the assumption that 
> implementations would otherwise "adapt their behavior". However, this 
> creates an ambiguity when Supported: gruu is used to indicate
> that: What if a request is sent with both a Contact and a Refer-To 
> header, and only one of the two is a GRUU?
>
> IMO, the usage of Supported here is questionable (with the exception 
> of the REGISTER and OPTIONS requests, for which it does makes sense)

The open question is: would modes (other than registrars) really behave
differently if they thought a URI to be a GRUU?

If not, then we have no need for the use of "Supported: gruu" as a hint,
or to tag a URI as a GRUU syntactically.

If so, then we would appear to need a way, on a per-URI basis, to
indicate that a URI isa GRUU.

--
Dean

_______________________________________________
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

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 4 Nov 2005 08:28:42 +0100

With the current state of things, that would give many false positives...

What could be defined, is a set of criteria for a URI to positively 
determine that it is not a GRUU. One obvious criterion is if the host part 
is an IP address in the private space

Besides this, I think it would be wise to err on the side of caution: if we 
don't mark known GRUUs as such, elements that would behave differently have 
no way of determining that. What do we have to loose if we do mark them?

There are consequences:

- URI equality rules should be updated to say that if one URI is marked as 
GRUU and another is not, then they are not equal
- anywhere where URIs are being ordered (e.g. proxy target set), with 
q-values being equal or absent a GRUU SHOULD be preferred over a non-GRUU
- ...

Regards,

Jeroen

----- Original Message ----- 
From: "Sean Olson" <[email-masked]>
To: "Dean Willis" <[email-masked]>; "Jeroen van Bemmel" 
<[email-masked]>
Cc: "Sip" <[email-masked]>
Sent: Friday, November 04, 2005 1:57 AM
Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info 
Idea)

-----Original Message-----

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Nov 2005 11:49:50 -0600

> URI is *not* at a GRUU and assume all others are ;-)

So, exactly what do you do differently if you think something might  
not be GRUU?

You've been given this URI. Don't you just have to try it and see if  
it works, and if not then back off to some other behavior?

Remember, there's really no such thing as an absolutely universally  
reachable URI. It might b a URI on the public internet that your corp  
firewall has decided to block. It might just stop working between the  
time you get it and the time you try to use it. The Net might  
partition in between you. And so on.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Nov 2005 13:34:21 -0500

Dean - see below.

	Paul

Dean Willis wrote:
> So, exactly what do you do differently if you think something might  not 
> be GRUU?
> 
> You've been given this URI. Don't you just have to try it and see if  it 
> works, and if not then back off to some other behavior?

There is an example in section 6.3 of draft-ietf-sipping-cc-transfer-05:

    If the Contact URI of the Transfer Target is a GRUU (Globally
    Routable User Agent URI) GRUU [5] then the Transferee SHOULD use that
    URI as the Refer-To URI.  If the Contact URI is not known to be a
    GRUU (Supported: gruu is not present), then the Address of Record
    (AOR) of the Transfer Target should be used.  That is, the same URI
    that the Transferee used to establish the session with the Transfer
    Target should be used.  In case the triggered INVITE is routed to a
    different User Agent than the Transfer Target, the Require: replaces
    header field should be used in the triggered INVITE.  (This is to
    prevent an incorrect User Agent which does not support Replaces from
    ignoring the Replaces and answering the INVITE without a dialog
    match.)

> time you get it and the time you try to use it. The Net might  partition 
> in between you. And so on.
> 
> -- 
> Dean
> 
>

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 04 Nov 2005 19:02:05 -0500

> it works, and if not then back off to some other behavior?

I believe that is what everybody does in practice.  And we have sort of
given them permission to do so, since RFC 3261 says that Contacts should
be GRUUs.

Dale