Re: How to show presentity's relative service preference
JaekwonOH <jaekwon.oh <at> samsung.com>
2008-08-08 06:38:00 GMT
Thanks for comment.
> Only if it wants them to. It certainly may use a separate contact uri
> for each application. (They probably have the same address and are
> distinguished by the user part, or port.) Its the responsibility of the
> application to put in enough uniqueness to get proper results.
I agree that if all each application can have unique contact address then there's no problem.
However, as I understand relevant RFCs incl. RFC4479, this seems not always the case.
So, when the contact address is not unique over different applications, it is questionable whether the
priority attribute can be still meaningful to show presentity's relative service preference...
Thanks & regards,
Jaekwon OH
----- Original Message -----
From: "Paul Kyzivat" <pkyzivat <at> cisco.com>
To: "JaekwonOH" <jaekwon.oh <at> samsung.com>
Cc: "Simple WG" <simple <at> ietf.org>; "Smyth, Colm (Colm)" <smythc <at> avaya.com>
Sent: Thursday, August 07, 2008 8:49 PM
Subject: Re: [Simple] How to show presentity's relative service preference
>
>
> JaekwonOH wrote:
>> Hi,
>>
>> Thanks for response.
>> Even when the device contact URI registered for an AOR is used for
>> tuple's contact address, the uniqueness of the contact address for a
>> tupe seems not guaranteed. For example, a device may run multiple SIP
>> applications, then tuples for each of those would contain the same URI.
>
> Only if it wants them to. It certainly may use a separate contact uri
> for each application. (They probably have the same address and are
> distinguished by the user part, or port.) Its the responsibility of the
> application to put in enough uniqueness to get proper results.
>
> Paul
>
>> This aspect has already been clarified in RFC 4479 (see the following
>> excerption).
>> Therefore, IMHO, the uniquness of contact address for each tuple seem
>> not guaranteed, so the use of 'priority' attribute of <contact> in
>> <tuple> is not enogh to show the presenity's relative service preference.
>>
>> From RFC 4479 section 3.3.2 reach information,
>>
>> Even for services reachable over a communications network, the URI
>> alone may not be sufficient. For example, two applications may be
>> running within a cellular telephone, both of which are reachable
>> through the user’s SIP Address of Record. However, one application
>> is launched when the INVITE request contains a body of a particular
>> type, and the other is launched for other body types. As another
>> example, a service may provide complex application logic that
>> operates correctly only when contacted from matching application
>> software. In such a case, even though the communications between
>> instances utilizes a standard protocol (such as SIP), the user
>> experience will not be correct unless the applications are matched.
>> When the URI is not sufficient, additional attributes of the service
>> can be present that define the instructions on how the service is to
>> be reached. These attributes must be understood for the service to
>> be utilized. If a watcher receives a presence document containing
>> reach information it does not understand, it should discard the
>> service information.
>>
>>
>> Thanks & regards,
>> Jaekwon OH
>> ----- Original Message -----
>>
>> *From:* Smyth, Colm (Colm) <mailto:smythc <at> avaya.com>
>> *To:* Simple WG <mailto:simple <at> ietf.org>
>> *Sent:* Wednesday, August 06, 2008 1:23 AM
>> *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 <mailto: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
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Simple mailing list
>> Simple <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Simple mailing list
>> Simple <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
RSS Feed