[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] GRUU in presence document
inline...
Salvatore Loreto wrote:
> 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.
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.
> 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.
That is certainly a good option.
> 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.
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?
> 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.
Same comment as for 2.
> 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
In what way does it change the meaning?
> and does not allow concatenation of service elements in case of multiple
> devices.
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.
> 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
I stated my objections to 2 and 4 above. I just don't understand 3.
> 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.
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
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple