Subject: RE: [Sip] GRUU and grid

From: Jeroen Van Bemmel <[email-masked]>
Date: Tue, 19 Sep 2006 18:08:16 +0200

Paul, Eric,

As I commented before - for a request sent to a GRUU outside of a dialog, I think the GRUU would normally appear in the To header, including any grid parameter. Therefore the UAS could inspect that to determine if the request was sent to (one of) its GRUU(s), and proxies need not copy the grid

Regards,
Jeroen 

-----Oorspronkelijk bericht -----
Van: "Paul Kyzivat" <[email-masked]>
Aan: "Eric Rescorla" <[email-masked]>
CC: [email-masked]
Verzonden: 19-9-06 15:56
Onderwerp: Re: [Sip] GRUU and grid

Eric Rescorla wrote:
> I recently made another pass through gruu-10 and I started wondering
> about the use of the "grid" parameter. ISTM that it serves two
> purposes:
> 
> 1. To let a UA hang a context variable/indicator off of a URI.
> 2. To let a UA know it was referenced via a GRUU.
> 
> So, the grid is sort of doing double duty in two not terribly
> related contexts. That's not always bad, but I fear it is
> in this case.

I must admit that this double usage arose out of expediency, and fairly 
recently.

Originally there was no way to tell whether you had been invoked via a 
gruu or the corresponding AOR, except if you had happened to use a grid 
parameter and it hadn't been tampered with. But that turned out not to 
be good enough.

The usage seemed benign enough at the time.

> First, wouldn't it be nice to be able to hang a context
> variable/indicator off any URI, not just a GRUU? 

Perhaps. Though the logistics get more difficult. If the context is 
applied to an AOR, and can be delivered to multiple UAs, then they must 
have a common agreement about the meaning of the context. But I suppose 
somebody would find a use for it.

> I've seen this issue
> come up in the context of e-mail spam, where users would like to be able
> to mint new e-mail addresses (sort-of capabilities) for each use to
> enable easy filtering.  It's obviously really nice to be able to do this
> without the help of your service provider. If you could use grids
> (probably renamed) with AORs or something like them, that would work for
> this, right? 
> 
> Second, just from an evocative perspective, having a "grid" parameter
> which can get into the To: one of two ways

It is only the R-URI that can get a grid parameter in two ways.

> and which means 
> "I was referenced via a GRUU" feels overloaded. Why not invent
> a different parameter for "I was referenced via a GRUU".

I think of the grid parameter with no value as simply the "default" 
value in a gruu, so it doesn't feel overloaded to me.

Would it seem less weird if the gruu that was returned by the registrar 
was pre-populated with a grid parameter with no value? (And the 
understanding that the UA may add a value to it if desired.) In that 
case, the use of a gruu with no grid parameter would be an error, which 
could be fixed either by rejecting it or by inserting the grid parameter.

But I also don't have a big problem with making this two parameters if 
there is agreement that grid should be usable for non-gruus. The 
downside to this is that the grid parameter requires special action from 
the proxy translating the R-URI. Coupling this to gruu ensures it will 
be implemented where it needs to be. If it were decoupled then I don't 
know how you ensure the proper translation will be done.

	Paul

> -Ekr
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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

_______________________________________________
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: [email-masked]
Date: Tue, 19 Sep 2006 12:36:28 -0400

From: Jeroen Van Bemmel <[email-masked]>

   As I commented before - for a request sent to a GRUU outside of a
   dialog, I think the GRUU would normally appear in the To header,
   including any grid parameter. Therefore the UAS could inspect that
   to determine if the request was sent to (one of) its GRUU(s), and
   proxies need not copy the grid

That's assuming that the request was originally sent to the GRUU, as
opposed to originally sent to an address that was then forwarded to
the GRUU.  In general, treating the To field as anything other than a
comment is dangerous.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Sep 2006 12:39:19 -0400

Jeroen Van Bemmel wrote:
> Paul, Eric,
> 
> As I commented before - for a request sent to a GRUU outside of a dialog,
> I think the GRUU would normally appear in the To header, including any
> grid parameter. Therefore the UAS could inspect that to determine if the
> request was sent to (one of) its GRUU(s), and proxies need not copy the grid

The To-URI is never a reliable source of information. I agree that in 
*some* cases the gruu is likely to end up in the To-URI as well as the 
R-URI, but there are lots of cases when that might not be so. E.g.
- I might have gotten in an invite dialog with you, and then want to
   subscribe to you. That is recommended to be done out of dialog now.
   I am likely to use the To or From URI from my existing dialog
   for the new dialog, and just use the gruu from the Contact for
   the R-URI.

- I might send a request, get a 3xx that happens to contain a gruu,
   and retry changing only the R-URI to the gruu.

- I might send a request to alice@atlanta, and be forwarded to
   a gruu for bob@biloxi. Only the R-URI will be updated.

- I might subscribe to presence for alice@atlanta, and pick out
   a contact to call that happens to be a gruu, to send a request to.
   I'm inclined to make the To be alice@atlanta and the R-URI be
   the gruu.

The time you want the grid is when the gruu was definitely the target of 
the request, and was translated. To be sure of that, the proxy doing the 
translation must be complicit.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 19 Sep 2006 20:33:13 +0200

OK, so there exist cases that would not work without the proxy's help.

It appears the draft could provide some more guidance in section 8.1.2, on 
how to populate the To header for requests sent to a GRUU outside of a 
dialog.
RFC3261 says: "The initial Request-URI of the message SHOULD be set to the 
value of the URI in the To field." But for GRUU, we start with a request 
URI.

If the AoR can be derived from the GRUU or is otherwise known, it would make 
sense to use that. But for anonymized GRUUs?

Regards,

Jeroen

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Jeroen Van Bemmel" <[email-masked]>
Cc: "Eric Rescorla" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 19, 2006 6:39 PM
Subject: Re: [Sip] GRUU and grid

>> Jeroen -----Oorspronkelijk bericht -----
>> parameter and it hadn't been tampered with. But that turned out not to be 
>> good enough.
>>
>>> and which means "I was referenced via a GRUU" feels overloaded. Why not 
>>> invent
>> I think of the grid parameter with no value as simply the "default" value 
>> in a gruu, so it doesn't feel overloaded to me.
>>
>> there is agreement that grid should be usable for non-gruus. The downside 
>> to this is that the grid parameter requires special action from the proxy 
>> translating the R-URI. Coupling this to gruu ensures it will be 
>> implemented where it needs to be. If it were decoupled then I don't know 
>> how you ensure the proper translation will be done.
>>
>> Paul
>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>>
>>>