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

From: JaekwonOH <[email-masked]>
Date: Tue, 05 Aug 2008 10:33:57 +0900

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
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Tue, 5 Aug 2008 17:23:33 +0100

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 | [email-masked] | +353 1 656 7843 (x37843)

________________________________

From: [email-masked] [mailto:[email-masked]] 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

---

From: <[email-masked]>
Date: Wed, 6 Aug 2008 23:28:14 -0500

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: [email-masked] [mailto:[email-masked]]
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

	From: [email-masked] [mailto:[email-masked]]
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

---

From: JaekwonOH <[email-masked]>
Date: Thu, 07 Aug 2008 14:17:48 +0900

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.
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) 
  To: Simple WG 
  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 | [email-masked] | +353 1 656 7843 (x37843)

------------------------------------------------------------------------------
  From: [email-masked] [mailto:[email-masked]] 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,

  Thanks & regards,

  Jaekwon OH

------------------------------------------------------------------------------

---

From: JaekwonOH <[email-masked]>
Date: Thu, 07 Aug 2008 15:25:46 +0900

Hi Krisztian,

Thanks for response. Please find below my response:

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.

Your understanding expands the semantics defined in RFC 3863 on the priority attribute. 
Problem is that there's no clarification on such interpretation. 

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.

Fortunately, the schema definition in RFC 3863 allows the <contact> element under <tuple> to occur just once (or zero). So, we could get free of this issue..

Thanks & regards,
Jaekwon OH

  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] 
  Sent: Thursday, August 07, 2008 1:28 PM
  Subject: 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: [email-masked] [mailto:[email-masked]] 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

    Colm Smyth

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] 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,

    Thanks & regards,

    Jaekwon OH

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2008 07:49:09 -0400

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

> 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.
>  
> through the user’s SIP Address of Record. However, one application
>     *From:* Smyth, Colm (Colm) <mailto:[email-masked]>
>     *To:* Simple WG <mailto:[email-masked]>
>     *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
>     tuple's source, but to reach the address; then, the priority
>     attribute has a meaningful scope.
>      
>     Colm Smyth
>     *AVAYA* | [email-masked] <mailto:[email-masked]> | +353 1 656
>     7843 (x37843)
>      
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *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,
>      
>     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.
>     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
>     ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Thu, 7 Aug 2008 14:22:05 +0100

You're describing a content-based dispatch scenario; as you note, a
content-oriented application isn't identifiable or addressable using a
URI.
 
The tuple class-id may help with identification, however there is little
guidance in the existing RFCs on what makes a good class-id. For
content-dispatch over a generic protocol (e.g. SIP or even HTTP), the
actual MIME-type would be useful. For other uses, it would be possible
to use a similar constructive approach to create an identifier that
identifies application in arbitrary levels of detail (e.g.
service/protocol/vendor+version).
 
All the best,
Colm Smyth
AVAYA | [email-masked]

From: JaekwonOH [mailto:[email-masked]] 
Sent: 07 August 2008 06:18
To: Simple WG; Smyth, Colm (Colm)
Subject: Re: [Simple] How to show presentity's relative service
preference

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.
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.

Thanks & regards,
Jaekwon OH

----- Original Message ----- 

	From: Smyth, Colm (Colm) <mailto:[email-masked]>  
	To: Simple WG <mailto:[email-masked]>  
	Sent: Wednesday, August 06, 2008 1:23 AM
	Subject: Re: [Simple] How to show presentity's relative service
preference

	 
	Colm Smyth

	Hi all,

	Thanks & regards,
	 
	Jaekwon OH

---

From: JaekwonOH <[email-masked]>
Date: Fri, 08 Aug 2008 15:38:00 +0900

Thanks for comment.

> 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

---

From: JaekwonOH <[email-masked]>
Date: Fri, 08 Aug 2008 15:39:12 +0900

It seems we now share the understanding that a service may not be uniquely identifiable with the contact URI only. 
Then, the question is whether the priority attribute is still meaningful to show presentity's relative service preference..

Thanks & regards,
Jaekwon OH

  ----- Original Message ----- 
  From: Smyth, Colm (Colm) 
  To: JaekwonOH ; Simple WG 
  Sent: Thursday, August 07, 2008 10:22 PM
  Subject: RE: [Simple] How to show presentity's relative service preference

  You're describing a content-based dispatch scenario; as you note, a content-oriented application isn't identifiable or addressable using a URI.

  The tuple class-id may help with identification, however there is little guidance in the existing RFCs on what makes a good class-id. For content-dispatch over a generic protocol (e.g. SIP or even HTTP), the actual MIME-type would be useful. For other uses, it would be possible to use a similar constructive approach to create an identifier that identifies application in arbitrary levels of detail (e.g. service/protocol/vendor+version).

  All the best,
  Colm Smyth
  AVAYA | [email-masked]

  Hi,

  Thanks for response.

  Thanks & regards,
  Jaekwon OH

  ----- Original Message ----- 
    From: Smyth, Colm (Colm) 
    To: Simple WG 
    Sent: Wednesday, August 06, 2008 1:23 AM
    Subject: Re: [Simple] How to show presentity's relative service preference

    Colm Smyth

    Hi all,

    Thanks & regards,

    Jaekwon OH

---

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Fri, 8 Aug 2008 11:00:48 +0100

Your scenario falls outside the scope of the present RFCs. Let's review
the relevant extracts.
 
RFC 3863 says:
     - Relative priority: numerical value specifying the priority
         of this COMMUNICATION ADDRESS. (optional)
and:
   The <contact> element contains a URL of the contact address.  It
   optionally has a 'priority' attribute, whose value means a relative
   priority of this contact address over the others.  The value of the
   attribute MUST be a decimal number between 0 and 1 inclusive with at
   most 3 digits after the decimal point.  Higher values indicate higher
   priority.  Examples of priority values are 0, 0.021, 0.5, 1.00. If
   the 'priority' attribute is omitted, applications MUST assign the
   contact address the lowest priority.  If the 'priority' value is out
   of the range, applications just SHOULD ignore the value and process
   it as if the attribute was not present.

   Applications SHOULD handle contacts with a higher priority as they
   have precedence over those with lower priorities.  How they are
   actually treated is beyond this specification.  Also, how to handle
   contacts with the same priority is up to implementations.
So the priority is intended to be used in combination with the contact
addresss.
 
RFC 4479 says:
   Each service is also associated with a priority, which represents the
   preference that the user has for usage of one service over another.
   This does not mean that, when a watcher wishes to communicate with
   the presentity, that they should always use the service with the
   highest priority.  If that were the case, there would be no point in
   including multiple services in the presence document.  Rather, the
   priority says, "If you, the watcher, cannot decide which of these to
   use, or if it is not important to you, this is the order in which I
   would like you to contact me.  However, I am giving you a choice."
   The priorities are relative to each other, and have no meaning as
   absolute numbers.  If there are two services, and they have
   priorities of 1 and .5, respectively, this is identical to giving
   them priorities of .2 and .1, respectively.
However clearly there is a benefit in providing presence information for
multiple services, because the subscriber may have a preference for
using a specific address type and so regardless they may need to treat
the priority as advisory information only.

In spite of this address-centric view of priority, I see no reason why a
smart subscriber should not use all the information in the tuple (in
particular, the class-id) to decide how best to address a presentity via
a service, and then the priority does have meaning.
 
I see some benefit in a new RFC (or an update to RFC 4479) that
clarifies this usage of priority, and that offers guidelines for
class-ids, and possibly a way to communicate the mime-types supported by
a given service. I'd also like to see a taxonomy of standard presence
substates (e.g. do-not-disturb) and a recommendation on which substates
are associated with open versus closed states.
 
I'd be interested in collaborating on any subset of these initiatives
off-line and presenting some input to the WG. If anyone else is
interested, please contact me directly. Jaekwon, given your insights in
this thread, I hope you would consider contributing directly.
 
All the best,
Colm Smyth
AVAYA | [email-masked] 

From: JaekwonOH [mailto:[email-masked]] 
Sent: 08 August 2008 07:39
To: Simple WG; Smyth, Colm (Colm)
Subject: Re: [Simple] How to show presentity's relative service
preference

It seems we now share the understanding that a service may not be
uniquely identifiable with the contact URI only. 
Then, the question is whether the priority attribute is still meaningful
to show presentity's relative service preference..
 
Thanks & regards,
Jaekwon OH

	----- Original Message ----- 
	From: Smyth, Colm (Colm) <mailto:[email-masked]>  
	To: JaekwonOH <mailto:[email-masked]>  ; Simple WG
<mailto:[email-masked]>  
	Sent: Thursday, August 07, 2008 10:22 PM
	Subject: RE: [Simple] How to show presentity's relative service
preference

	You're describing a content-based dispatch scenario; as you
note, a content-oriented application isn't identifiable or addressable
using a URI.
	 
	The tuple class-id may help with identification, however there
is little guidance in the existing RFCs on what makes a good class-id.
For content-dispatch over a generic protocol (e.g. SIP or even HTTP),
the actual MIME-type would be useful. For other uses, it would be
possible to use a similar constructive approach to create an identifier
that identifies application in arbitrary levels of detail (e.g.
service/protocol/vendor+version).
	 
	All the best,
	Colm Smyth
	AVAYA | [email-masked]

	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.
	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.

	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:[email-masked]>  
		To: Simple WG <mailto:[email-masked]>  
		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 | [email-masked] | +353 1 656 7843 (x37843)

		From: [email-masked]
[mailto:[email-masked]] 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Aug 2008 08:45:53 -0400

> However, as I understand relevant RFCs incl. RFC4479, this seems not always the case. 

What would lead you to think you can't have as many unique addresses as 
you want?

---

From: JaekwonOH <[email-masked]>
Date: Thu, 14 Aug 2008 08:45:41 +0900

Hi Paul,

> What would lead you to think you can't have as many unique addresses as 

SIP applications for a registered user (i.e., presentity), such as voip, ptt, and im. They can share the user's SIP AOR as contact address, and be differentiated each other with different feature tags. 

Thanks & regards,
Jaekwon OH

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Aug 2008 09:18:00 -0400

> SIP applications for a registered user (i.e., presentity), such as voip, ptt, and im. They can share the user's SIP AOR as contact address, and be differentiated each other with different feature t…

You didn't answer my question. Unique addresses are cheap. Why not use 
as many as you need?

Also, this subject was discussed at length some years ago.

The question is what you expect the caller to do to establish contact 
with an advertised service of a presentity. The straightforward thing is 
to simply expect the caller to send an INVITE (or whatever) to the 
contact address listed for the service. If there is more than one 
mutually exclusive services that share a contact address, then this is 
not likely to get the intended result.

Alternatively, you may expect the caller to add other signaling elements 
  to the request, over and above the contact address, to indicate what 
service(s)/feature(s)/capabilities it desires of the target when the 
contact address doesn't uniquely identify that.

The problem with the latter is that the caller must know that it is 
expected to do this, and also know *what* additional signaling elements 
to add to achieve this. Its especially problematic if what needs to be 
added varies from one callee to another for the same capability.

A compromise here would be for the registered contact to have embedded 
sip headers. When this contact is used, these headers would be added to 
the request. But that is a feature that isn't universally (or often) 
implemented.

Ensuring that every "service" has a unique contact address is certainly 
likely to maximize the chance of establishing the desired type of 
session. This is easy and cheap for a UA to do if it is implementing its 
own services. If it is depending on an upstream app server to implement 
the services then things get more complex, but I think this approach can 
still work.

	Thanks,
	Paul