Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2005 15:15:15 -0500

Roughly what Orit proposes (using a uri parameter on the AoR) was my 
original preference way back at the beginning of gruu discussions. I 
think it would satisfy henning's desire for transparency if we 
explicitly standardize the particular parameter name used for this purpose.

I think there remains a need to *allow* gruus that *don't* expose the 
associated AoR. There are options here for that:
- use a bogus user part, with the parameter containing the key info
- use no user part at all, with the parameter containing the key info
- continue as has been suggested till now - encode the key info
   into an opaque user part.

Using any of these we would end up with at least two forms - one where 
the AoR is recoverable, and another where it is not. I prefer a 
non-recoverable form where it is very clear this is a gruu, but that 
recovery of the AoR is not intended. Of the above, that would be a uri 
with no user part, and a parameter. E.g.

- <sip:[email-masked];gruu="00sd8ggdgdasd===asd9">
- <sip:cisco.com;gruu="00sd8ggdgdasd===asd9">

Which form is used by any given gruu provider can remain a private matter.

(I'm not too wild about "instance" as the parameter name.)

	Paul

Orit Levin wrote:
> What would be wrong with having a GRUU always formatted as the user AOR
> with an additional URL parameter carrying the value "making it a GRUU"
> and understood by the user domain/registrar only?
> 
> Instead of:
> sip:jdrosen.instance.00sd8ggdgdasd===[email-masked]
> 
> Make it:
> <sip:[email-masked]; instance=www.borderware.com>
> 
> Orit.
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Henning Schulzrinne
>>Sent: Thursday, February 24, 2005 5:44 AM
>>To: Jonathan Rosenberg
>>Cc: [email-masked]
>>Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu
>>
>>I find this sub-optimal from a general design point of view. 
>>I thought we have had a general preference for being explicit 
>>about semantics, rather than overloading other elements or 
>>mechanisms. (See discussions on INFO and other similar 
>>topics.) I think many of the proposed labeling mechanisms 
>>would work and supporting at least one, even if somewhat 
>>arbitrarily selected, will get us to do the right thing in 
>>the majority of cases.
>>
>>This is particularly important since this is not just a local 
>>matter, i.e., other parties not familiar with the conventions 
>>of the sending side will need to be able to robustly extract 
>>this information.
>>
>>Jonathan Rosenberg wrote:
>>
>>>We had a long discussion in another thread about whether or 
>>
>>not we had 
>>
>>>an additional requirement to allow the recipient of a GRUU 
>>
>>to be able 
>>
>>>to determine the AOR associated with that gruu. This seemed 
>>
>>to be an 
>>
>>>issue for systems that generate call logs or bills, since 
>>
>>you'll have 
>>
>>>these entries that are meaningless.
>>>
>>>Though I didnt make any changes to gruu in order to meet this 
>>>requirement, there may be a simple approach that we can 
>>
>>provide that 
>>
>>>fits with the current gruu mechanism.
>>>
>>>The spec is clear that there are no constraints on how a domain 
>>>constructs a gruu. The appendix includes a few sample algorithms 
>>>(though I'll note one of them is broken...). As such, there 
>>
>>is nothing 
>>
>>>wrong with a domain constructing a gruu by including the 
>>
>>instance ID 
>>
>>>and AOR in the clear in the user part of the URI:
>>>
>>>sip:jdrosen.instance.00sd8ggdgdasd===[email-masked]
>>>
>>>for example. Thus, we could list such a technique as a viable 
>>>approach, and recommend that a particular means of encoding 
>>
>>the URI be 
>>
>>>used in order to allow other entities to extract the aor.
>>>
>>>Thus, we would have a way for the recipient of a domain to 
>>
>>get a hint 
>>
>>>about the possible AOR (no guarantee though), without changing the 
>>>mechanism at all.
>>>
>>>Would that represent a reasonable compromise?
>>>
>>>Thanks,
>>>Jonathan R.
>>
>>
>>_______________________________________________
>>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: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 22:10:09 -0800

On 2/23/05 9:17 PM, "Jonathan Rosenberg" <[email-masked]> wrote:

> We had a long discussion in another thread about whether or not we had
> an additional requirement to allow the recipient of a GRUU to be able to
> determine the AOR associated with that gruu. This seemed to be an issue
> for systems that generate call logs or bills, since you'll have these
> entries that are meaningless.

I'm confused on why these system need to contact to be meaningful and what
devices they are using today that make the contact meaningful for a billing
system. The billing (and logging system) I have seen have seemed to be more
interested in From, PAI, Call-ID, Time, and request URI.

I'm still lost on the need for this. It will further confuse the UA / user
resource confusion that we already have.