Subject: [Sip] GRUU, AORs, and identity, oh my!

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Mar 2005 15:48:33 -0500

Following the mostly inconclusive discussion during the SIP meeting on 
GRUUs, their relationship to identity, and the ability to extract the 
AOR from a GRUU, a few folks (including myself, Paul K., Rohan, Cullen 
and Jon P. for a bit) tried to sort it out and come up with a path 
forward that might be acceptable. The discussion was very fruitful and 
resulted in a proposal for a path forward that I think is good. If folks 
with an interest can respond, on the list or privately, if they think 
this is a good path, it would be great. I'd really like to wrap this 
work, a lot of things are dependent on it.

Proposal:

URIs have properties. Those properties are granted to the URI based on
policies of the domain, and genreally those properties are not visible
by inspection of the URI. There are a few properties in play here:

The "AOR" property: A URI has the AOR property (i.e., is an AOR) if a
domain will allow it to appear in the To header field of REGISTER
request.

The alias property: A URI is an alias if its treatment by the domain
is identical to another URI.

The GRUU property: A URI is hsa the GRUU property if it routes to a
particular UA instance.

The service treatment property: A URI has the service treatment
property if the domain will apply applications, features, and services
to calls made by, or made to, that URI, possibly based on associating
that URI with a user that has "subscribed" to various features.

The anonymous property: A URI has the anonymous property when it is
not possible, by inspection of the URI, to discern the user with whom
the URI is associated.

The identity property: A URI is considered an identity when it is one
that the domain will authorize as a valid value in the From header
field of a request.

A URI can have any combination of these properties. The URI returned
by the registrar in the gruu Contact header field parameter of a
REGISTER response is required to have the gruu property, and thats
it. It would be RECOMMENDED that it also have the service treatment
property, however, the specific services applied to that URI need not
match those provided to the AOR with which the URI is associated; this
is a domain policy decision. The spec would advise that it might be a
good idea to apply features like screening (but not forwarding) for
requests targeted to the GRUU. The domain could associate other
properties with the URI, but that would be outside the scope of the
GRUU spec. URIs with the GRUU property obtained in ways other than
registrations (like a provisioned URI for a gateway) need not have the
service treatment property either.

It is fundamental that the domain be able to create the URI that has
the GRUU property. It needs to be able to do this so it can be
constructed in a way that allows the domain to be able to route it to
the places it needs to be routed, and to have other properties which
the domain would like to associate with the URI. It is thus essential
that, when a client requires a URI with the GRUU property associated
with one of its registered contacts, that it be obtained by having the
domain hand the URI to the user agent. It is not acceptable for the UA
to simply construct the URI (for example, by appending an instance
parmeter to their AOR).

For similar reasons, usage of the caller prefernces mechanisms to
achieve the desired effect (route a call to a particular instance),
does not work. It depends on someone else constructing a URI that
interacts with domain processing logic for an AOR, to cause it to
route to a particular instance. Given the variability in routing logic
in a domain (for example, time based routing to only selected
contacts), this doesn't work.

Furthermore, there is a desire to be able to construct URIs that have
the GRUU property by separating the URI into a component that
identifies the AOR associated with the instance (when such an
association exists), and a component that contains domain-generated
context it uses to affect routing and processing of the URI so it goes
to the specific instance. As argued above, it is essential that a
domain be able to create and manage this context. Thus, such a
separation can be achieved by creating a URI parameter that is
analagous to the grid parameter, but for the domain provider. Call
this the "opaque" URI parameter. That is, the grid parameter provides
context to the UA, so that when it receives a request made to the URI,
it can use the grid as context. The opaque URI parameter provides
context to the domain, so that when the domain proxy receives a
request made to the URI, it can use the opaque parameter as context.

With this definition, the opaque parameter need not even be restricted
to usage with gruus. The gruu property is NOT based on the presence of
the opaque parameter. It is signaled through, for example, the
Supported header field in an INVITE/200 OK, as defined today in the
gruu specification. The opaque parameter allows a domain to hand out a
URI that allows it to be correlated with an AOR, in that a recipient
could extract the AOR from the URI (by stripping the opaque
parameter). However, the way in which the URI is correlated with the
AOR is up to domain policy. In the case of GRUU, the policy is that it
routes to a particular instance.

There is no requirement that a domain use the opaque parameter to
provide a URI with GRUU properties. A domain that, for example, also
requires the URI to have an anonymous property, may not be able to do
that. Returning a URI in the gruu contact header field of the REGISTER
response that uses the opaque parameter would be a MAY.

Furthermore, the scope of the REGISTER mechanism in the gruu spec is
concerned entirely with returning URIs with the gruu property. There
is a need to ask a domain to mint URIs with other properties, such as
anonmyous. Mechanisms for that kind of minting are outside
the scope of the gruu spec.

Because the domain can decide whether or not the URI returned in the
REGISTER response has other properties, it might allow it to have the
identity property, or it might not. There are no guarantees, and so,
ouside of other mechanisms for signaling that the URI has the identity
property, the recipient of the URI cannot assume it is a valid
identity. Nothing can prevent the UA from trying, and thus inserting
the GRUU into the From header field of an INVITE. Whether or not the
domain would then insert the Identity header field would depend on
domain policy.

Based on this analysis, I would suggest updating the GRUU spec to
include the above. I think it is not unreasonable to include the more
abstract discussion on URI properties, including the definition of
AOR, though I would prefer that the identity definition be moved into
draft-ietf-sip-identity and thus a reference be provided from the GRUU
spec.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Mar 2005 12:47:55 -0600

Jonathan Rosenberg wrote:
> If folks with an interest can respond, on the list or privately, 
> if they think this is a good path, it would be great. I'd really like 
> to wrap this work, a lot of things are dependent on it.

Jonathan:

Yes; good path forward.  One comment and a clarification -- please
see inline.

> by inspection of the URI. There are a few properties in play here:
[...]

First, I see a new property of a URI: Routability.  This property
is rather implicit in the notion of a URI, and in fact, the GRUU
property is a subset of this property (more below).

   Routability: A URI has a routability property in that it always
   routes to the domain that owns the URI.

I see the GRUU as being a subset of this property, since a
GRUU routes to a _specific_ instance within the domain that
owns the URI.  A URI itself allows the SIP mesh to route
the request to the domain that owns the URI.

Second, the wording below allows us to retrieve a AoR from a GRUU.

> request made to the URI, it can use the opaque parameter as context.

In practice, the "opaque" parameter will indeed be some opaque
sequence of characters instead of an actual domain name...yes?
Something like:

   sip:hha9s8d=[email-masked];opaque=fx45d-pe2"

It is up to the resolving domain proxy to figure out which AoR
"fx45d-pe2" belongs to.

> include the above.

Sounds fine.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Mar 2005 19:28:39 -0500

inline.

Vijay K. Gurbani wrote:
>> If folks with an interest can respond, on the list or privately, if 
>> they think this is a good path, it would be great. I'd really like to 
>> wrap this work, a lot of things are dependent on it.
> 
> 
> Jonathan:
> 

This is nearly a tautology; RFC 3263 causes a URI to be resolved to a 
host that serves the domain in the domain part.

>   sip:hha9s8d=[email-masked];opaque=fx45d-pe2"

The idea is that it would be something like this:

sip:[email-masked];opaque="asd998ggfdgsafl000---"

that is, the AOR is still exposed in the user@domain part.

Thanks,
Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Tue, 15 Mar 2005 15:58:51 +0200

ext Jonathan Rosenberg wrote:
--snip

> draft-ietf-sip-identity and thus a reference be provided from the GRUU

I agree with the analysis and this seems like a good way forward.

Cheers,
Aki

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Mar 2005 12:50:55 -0600

Jonathan Rosenberg wrote:
vkg>   Routability: A URI has a routability property in that it always
vkg>   routes to the domain that owns the URI.
jdr>
jdr> This is nearly a tautology; RFC 3263 causes a URI to be resolved to a
jdr> host that serves the domain in the domain part.

Yes, I realize that routing is intrinsic to a URI.  However, I
still think that routing to a domain versus routing to a specific
instance within the domain may be different properties.  The
latter (a GRUU) is a subset of the former.

vkg> In practice, the "opaque" parameter will indeed be some opaque
vkg> sequence of characters instead of an actual domain name...yes?
vkg> Something like:
vkg>   sip:hha9s8d=[email-masked];opaque=fx45d-pe2"
jdr>
jdr> The idea is that it would be something like this:
jdr>    sip:[email-masked];opaque="asd998ggfdgsafl000---"
jdr> that is, the AOR is still exposed in the user@domain part.

Initially I thought that the opaque parameter will aid in
extracting the AoR from the GRUU (since the WG has thrashed
on that particular problem), but based on above, this appears
not to be the case (the AoR is already available).

So, what is the use of the opaque parameter?  I re-read your
email and it says that the opaque parameter "...contains a
domain-generated context [used] to affect routing and processing
of the URI so it goes to the specific instance."  Isn't that what
a GRUU is for as well?

What happens when a GRUU contains an opaque parameter as in my
example above?  I guess the question is, what is the use case
that has motivated the opaque parameter?

Thanks,

- vijay
Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Mar 2005 16:11:15 -0500

> that has motivated the opaque parameter?

I think you are not getting the point. In the above, a gruu (at least 
this form of gruu) *is* an AoR *augmented* with the opaque parameter. 
The AoR is recoverable from this form of gruu by removing the opaque 
parameter.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Mar 2005 15:29:54 -0600

> The AoR is recoverable from this form of gruu by removing the opaque 

Paul:

Of course I see that; however, I thought that the opaque
parameter was an answer to a problem that the WG has
thrashed about, namely, how to recover an AoR from a GRUU.

Not all GRUUs will be of the nice form sip:user@domain.
For those that are, removing the opaque parameter to get the
AoR is a no-brainer -- the AoR is staring at you right in
the face.  So I see little utility in adding an opaque
parameter to such an AoR.

Hence my question -- what was the use case that motivated
the opaque parameter.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Mar 2005 17:49:57 -0500

Vijay,

OK, we must really be talking past one another. The opaque parameter is 
what the proxy uses to recognize this is a gruu rather than just an AoR:

- AoR:  sip:[email-masked]
- Gruu: sip:[email-masked];opaque="xyzzy"

There could be another form of gruu that is anonymized. If so the point 
would be that one should not be able to recover the AoR from it.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Mar 2005 09:29:51 -0600

> what the proxy uses to recognize this is a gruu rather than just an AoR:

Oh, ok.  So, the opaque parameter is a context saved by the
proxy that will allow it to match the gruu to an AoR.  A
gruu routes to a particular instance, but the opaque serves
to map the gruu to a particular AoR in the proxy's domain.

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Mar 2005 04:48:39 -0500

inline.

> latter (a GRUU) is a subset of the former.

This doesnt make sense to me. All URIs resolve to their domains. GRUUs 
have the property that, within the domain, they route to an instance. 
Thus, the only property here worth noting is the gruu property.

> not to be the case (the AoR is already available).

I don't follow you here. The GRUU looks like this:

to extract the AOR, you remove the opaque parameter.

> of the URI so it goes to the specific instance."  Isn't that what

Yes. The point is that the GRUU is created by adding the opaque 
parameter to the AOR.

> that has motivated the opaque parameter?

To extract the AOR from the GRUU.

-Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 17 Mar 2005 09:27:31 -0600

Jonathan:

I see it as a property that the URIs resolve to their domain names;
rfc3986 in fact makes no mention of routability per se, and
notes that "...Nor should it be assumed that a system
using URIs will access the resource identified: in many cases,
URIs are used to denote resources without any intention that they
be accessed."  We have build SIP systems around the fact that
we will access (i.e. route to) the URI and identify a domain (AoR)
versus a specific endpoint (gruu) for the URI.

But this is all academic; as the editor of the GRUU I-D, it
is your choice to accept my argument or not.  Not accepting
it will not be the end of the world, just like accepting it
will not drastically change the world ;-)

> to extract the AOR, you remove the opaque parameter.

I think after an email exchange with Paul K. (which you may
probably have read by now) on the WG mailing list, I
see the reason for the opaque parameter.  I did post my
understanding of its usage (see
http://www1.ietf.org/mail-archive/web/sip/current/msg11295.html);
if that understanding is flawed, do let me know.

Thanks,

- vijay