Subject: [Simple] GRUU in presence document

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 Jun 2008 13:36:34 +0300

Hi there,

we have noticed that currently there isn't any way to use presence to 
identify the unique device.
There was something mentioned in an earlier version of the gruu draft : 
http://tools.ietf.org/html/draft-ietf-sip-gruu-10#section-4.3
but it has been removed.

The definition of the device ID in RFC 4479 suites well with the gruu, 
however the <contact> element
in the <tuple> element is a URI and the question is how the URI 
parameters will be handled.

We have identified several possible ways to use presence to identify the 
unique device, that we would like to discuss in the wg
The possible way are the following:

1) Use the public GRUU as the value of the contact element of the 
presence document.

2) Include the sip-instance of the public GRUU as a SIP-instance 
attribute in the device element of the presence document.
The GRUU is obtained by concatenating the aor of the contact element and 
the SIP-instance attribute in the device element.

3) Define a new element in the service element to define the public GRUU.

4) Use the sip-instance as the device-id of the device element.
   The GRUU is obtained by concatenating the AoR of the contact element 
and the device-id attribute in the service element containing the sip 
instance.
   The device element does not have to be included if not needed for 
other purposes.

Here the drawbacks of the different proposal we have identified so far:

Alt. 1 will change the existing meaning (if any) of the contact element 
and does not allow concatenation of service elements in case of multiple 
devices.

Alt. 2 requires a new device attribute to be defined, but has the 
advantage that multiple devices are supported by one service element and 
if needed;
         the deviceID can be different from the sip-instance of the GRUU.

Alt. 3 requires an extension to the schema and does not really give any 
advantage to alt 4 except that sip-instance and deviceID may be different.

Alt. 4 is schema compliant and supports multiple devices using the same 
service element. Requires that the deviceID is set to the sip-instance 
of GRUU

So, our proposal is to go for alternative 4 since it has the best fit 
with current standard and is assumed to be proposed to standardize GRUU 
for presence.
The <contact> and <deviceID> of the <service> element are optional but 
are mandatory to identify the GRUU.

regards
Sal
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jun 2008 09:59:11 -0400

inline...

> parameters will be handled.

I don't understand the point of the above sentence. A GRUU is also a 
URI. And URI parameters are the business of the owner/constructor of the 
URI, not those that simply send requests to the URI. The client of a URI 
should be opaque to any URI parameters it may or may not contain.

> 1) Use the public GRUU as the value of the contact element of the 

That is certainly a good option.

> the SIP-instance attribute in the device element.

Are you suggesting that the client of the take elements from different 
parts of the presence document and *assemble* them into a URI?

AAAAAAAAARRRRRRRRRGGGGGGGGGGGGGGGGG!!!!!!!!!!!

That is terrible!!!

Its doubly terrible that you are suggesting that the resulting assembly 
be called a gruu.

The algorithms for constructing gruus are the sole responsibility of the 
target home proxy. Other parties should not presume to know how those 
algorithms operate.

> 3) Define a new element in the service element to define the public GRUU.

Why?

>    The device element does not have to be included if not needed for 

Same comment as for 2.

> Alt. 1 will change the existing meaning (if any) of the contact element 

In what way does it change the meaning?

> and does not allow concatenation of service elements in case of multiple 

What? Are you talking about presence composition policies? Concatenation 
of tuples is one of many possible composition policies. This doesn't 
change that. It does result in a number of mutually exclusive 
alternative presence attributes - one per end device. If you want some 
other sort of composition policy you can do it. If you want to merge the 
presence attributes from the multiple devices into a single tuple you 
can do that too, but then you will have to replace the contact with 
something (e.g. the AOR) that represents all the incorporated UAs.

> service element. Requires that the deviceID is set to the sip-instance 

I stated my objections to 2 and 4 above. I just don't understand 3.

> are mandatory to identify the GRUU.

IMO a *client* should not have to do more than pick a tuple with desired 
properties from the presence document and then send a request to the URI 
obtained from the contact of that tuple. If the client normally would 
use caller preferences when initiating the call without presence, then 
it should still do so in this case. But IMO that caller should be making 
no further assumptions about how to address the target.

Before getting into details about this, I think you must have some 
unstated assumptions about how the presence is published and composed. 
If you can explain those further maybe a solution will be clearer.

	Thanks,
	Paul