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

From: "Orit Levin" <[email-masked]>
Date: Thu, 24 Feb 2005 15:17:55 -0800

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="00sd8ggdgdasd===asd9">

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