|
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,
From: JaekwonOH [mailto:jaekwon.oh at samsung.com] 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. 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 -----
|
_______________________________________________ Simple mailing list Simple at ietf.org https://www.ietf.org/mailman/listinfo/simple