[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information toProposed Standard

Worry, not a DISCUSS.
May be satisfied with an explanation from Patrik, otherwise I'll plant a DISCUSS on it and ask for clarification.

The simple-presence document says:

5 Usage of Presence URIs

   A presentity is identified in the most general way through a presence
   URI [3], which is of the form pres:user@domain. These URIs are
   protocol independent. They are resolved to protocol specific URIs,
   such as a SIP or SIPS URI, through domain-specific mapping policies.

   If a subscriber is only aware of the protocol-independent pres URI
   for a presentity, it follows the procedures defined in [5]. These
   procedures will result in the placement of the pres URI in the
   Request-URI of the SIP request, followed by the usage of the DNS
   procedures defined in [5] to determine the host to send the SIP
   request to. Of course, a local outbound proxy may alternatively be
   used, as specified in RFC 3261 [1]. If the subscriber is aware of
   both the protocol-independent pres URI and the SIP or SIPS URI for
   the same presentity, it SHOULD use the SIP or SIPS URI.

   SUBSCRIBE messages also contain logical identifiers that define the
   originator and recipient of the subscription (the To and From header
   fields). These SHOULD contain SIP or SIPS URIs whenever possible, but
   MAY contain a pres URI if a SIP or SIPS URI is not known or
   available.
[5] is D. Crocker et al. , "Address resolution for instant messaging
and presence," Internet Draft, Internet Engineering Task Force, Oct.
2002. Work in progress.

I assume this is draft-ietf-impp-srv-01.txt (same title!).
That draft seems to envision DNS entries of the form
"_pres._sip.example.com" to look up which host to contact when one wants to use SIP to contact a presentity named "pres:xyzzy@example.com".
There's no mapping from one type of URI to another - in either direction.

This has two problems:

1) If a client uses SIP, he presumably has SIP URIs for himself. So he will use that SIP URI in the From field of a SUBSCRIBE, even though he also has his own PRES URI.
If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, how is the gateway to find the corresponding PRES URI?

2) If a client starts with the PRES URI, and later learns the SIP URI of someone, and those two identities part way for some reason (perhaps the client stops using SIP, or the SIP URI was to a proxy service, or something) - how does the client learn that it's time to go back to the PRES URI?

Both problems would be avoided if this document said to use PRES URI when both are available.

draft-ietf-impp-serv says:

   CPIM and CPP both specify operations that have 'source' and
   'destination' attributes.  While only the semantics, not the syntax,
   of these attributes are defined by CPIM and CPP, many instant
   messaging and presence protocols today support the use of URIs to
   reflect the source and destination of their operations.  Such
   protocols might be able to use the 'im' and 'pres' URI schemes
   directly to express the identities of the principals associated with
   a protocol exchange.  When these operations pass through a CPIM or
   CPP gateway, these URIs could be relayed without modification, which
   has a number of desirable properties for the purposes of
   interoperability.

Seems to me like a good argument for preferring "pres:" here.
I've added this comment to the tracker too.

                       Harald