Re: [Simple] How to show presentity's relative service preference

Even though RFC 3863 is not very well written, in my understanding the priority attribute defined in RFC 3863 represents the relative priority of the service among the other services listed in the presence document. If one tuple includes multiple <contact> elements (for whatever reason...), the numerical values for the priority attributes have to be carefully chosen so that the relative priority of the service falls within the intended range.

Cheers,
Krisztian

From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On Behalf Of ext Smyth, Colm (Colm)
Sent: Tuesday, August 05, 2008 9:24 AM
To: Simple WG
Subject: Re: [Simple] How to show presentity's relative service preference

I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself.

A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope.

Colm Smyth

Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications
AVAYA | smythc at avaya.com | +353 1 656 7843 (x37843)

From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On Behalf Of JaekwonOH
Sent: 05 August 2008 02:34
To: Simple WG
Subject: [Simple] How to show presentity's relative service preference

Hi all,

I'm wondering how a presentity can show his perferred services in presence.
A possibility seems to use the 'priority' attribute of <contact> element for this purpose.
However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.
For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted?
IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address.

If this is the case, what should we do?

Thanks & regards,

Jaekwon OH