6.1. Requesting a Subscription
If an XMPP entity wants to subscribe to the presence information of a
non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "subscribe" to the target presentity. The
syntax mapping is as follows:
o The XMPP ’from’ attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP ’to’ attribute (user@host) MUST be mapped to the CPP
"target parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the
address.
o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly
"unsubscribed".
o The XMPP ’id’ attribute SHOULD be mapped to the CPP "TransID"
field.
If the target presentity approves the subscription request (through
whatever protocol it uses to interact with the gateway), the
XMPP-CPIM gateway MUST return a presence stanza of type "subscribed"
to the XMPP entity and notify the XMPP entity of the target’s current
available presence. Thereafter, until the subscription is cancelled,
the gateway MUST notify the subscribing XMPP entity every time the
target’s presence information changes.
If the target presentity denies the subscription request, the
XMPP-CPIM gateway MUST return a presence stanza of type
"unsubscribed" to the XMPP entity and MUST NOT invoke the notify
operation.
In addition to the approval and denial cases, one of the following
exceptions may occur:
o The target parameter (XMPP "to" address) does not refer to a valid
presentity; if this exception occurs, the XMPP-CPIM gateway MUST
return an <item-not-found/> stanza error to the XMPP entity.
o Access control rules do not permit the entity to subscribe to the
target; if this exception occurs, the XMPP-CPIM gateway MUST
return a <forbidden/> stanza error to the XMPP entity.
o There exists a pre-existing subscription or in-progress subscribe
operation between the XMPP entity and the target presentity; if
this exception occurs, the XMPP-CPIM gateway SHOULD return a
<conflict/> stanza error to the XMPP entity.
XMPP services assume that a subscription is active until it is
explicitly terminated. However, non-XMPP services may implement
subscriptions of limited duration, which must be periodically
refreshed in order to mimic the permanence of XMPP subscriptions.
Therefore, an XMPP-to-CPIM gateway may need to send such refreshes to
the non-XMPP entity on behalf of the XMPP entity to that the
subscription does not expire. Whether such refreshes are necessary
depends on the native protocol implemented by the CPIM-aware non-XMPP
service to which the gateway is translating.
6.2. Receiving a Subscription Request
If a non-XMPP presentity wants to subscribe to the presence
information of an XMPP entity through an XMPP-CPIM gateway, it MUST
use whatever protocol it uses to interact with the gateway in order
to request the subscription; subject to local access rules, the
gateway MUST then send a presence stanza of type "subscribe" to the
XMPP entity from the non-XMPP watcher. The syntax mapping is as
follows:
o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
to the XMPP ’from’ attribute (user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the
address.
o The CPP "target parameter" field (pres:user@host) MUST be mapped
to the XMPP ’to’ attribute (user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the
address.
o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly
"unsubscribed".
o The CPP "TransID" field SHOULD be mapped to the XMPP ’id’
attribute.
If the target XMPP entity approves the subscription request, it MUST
send a presence stanza of type "subscribed" to the watcher
presentity. The XMPP-CPIM gateway MUST then notify the watcher
presentity of the target XMPP entity’s current available presence.
Thereafter, until the subscription is cancelled, the gateway MUST
notify the watcher presentity every time the target’s presence
information changes.
If the target XMPP entity denies the subscription request, it MUST
send a presence stanza of type "unsubscribed" to the watcher
presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
operation.
In addition to the approval and denial cases, one of the following
exceptions MAY occur:
o The target parameter (XMPP "to" address) does not refer to a valid
XMPP entity
o Access control rules do not permit the watcher presentity to
subscribe to the target XMPP entity
o There exists a pre-existing subscription or in-progress subscribe
operation between the watcher presentity and the target XMPP
entity
If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
the watcher presentity of failure.
XMPP services assume that a subscription is active until it is
explicitly terminated. With the exception of handling duration
parameters whose value is zero, handling duration parameters will be
highly dependent on the implementation and requirements of the
XMPP-CPIM gateway. Since there are no explicit requirements for
supporting a "duration parameter" specified in either [IMP-MODEL] or
[IMP-REQS], duration parameter mapping is a local issue that falls
outside the scope of this memo. However, an XMPP-CPIM gateway MAY
keep track of the duration parameter if received from an entity on
the non-XMPP service and delete the subscription after that duration
parameter expires.
6.3. The Notify Operation
An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
presence information associated with an XMPP entity or CPP presentity
changes and there are subscribers to that information on the other
side of the gateway. The syntax mapping for presence information
related to a notify operation is defined under Mapping for Presence
(Section 5).
6.3.1. Multiple Resources
Semantically, PIDF contains the notion of multiple presence "tuples".
Normally, a PIDF document will contain at least one tuple but MAY
contain more than one tuple (or zero tuples, for which see next
section). In the terminology of XMPP, each tuple would map to
presence information for a separate resource. However, XMPP does not
include the ability to send presence information about more than one
resource at a time, since the resource that generates the presence
information is contained in the ’from’ address of a presence stanza.
Therefore, an XMPP-CPIM gateway that acts as a presence service
SHOULD split a PIDF document that contains multiple tuples into
multiple XMPP presence stanzas, and SHOULD generate only one PIDF
document (with multiple tuples) if an XMPP user currently has
multiple connected resources.
In the interest of not multiplying XMPP stanzas beyond necessity, an
XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only if the
presence information contained in a PIDF tuple communicates a change
in the availability status of the device or application associated
with that tuple ID.
In the interest of complying with the PIDF recommendation to provide
information about multiple "resources" in multiple tuples rather than
in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include
information about all of an XMPP user’s resources in one PIDF
document (with one tuple for each resource), even if the availability
status of only one resource has changed.
6.3.2. Zero Resources
A PIDF document may contain zero tuples. For example:
PIDF Document with Zero Tuples
<presence entity=’pres:juliet@example.com’
xmlns=’urn:ietf:params:xml:ns:pidf’/>
Because (1) the ’entity’ attribute of a PIDF <presence/> element maps
to the <user@host> portion of an XMPP address and (2) the ’id’
attribute of a PIDF <tuple/> element maps to the resource identifier
portion of an XMPP address, a PIDF document that contains zero tuples
would provide presence information about a <user@host> rather than a
<user@host/resource> when mapped to XMPP. Although the notion of
presence notifications about a mere user rather than one of the
user’s resources is nearly meaningless in the XMPP context, an
XMPP-CPIM gateway SHOULD map a PIDF document with zero tuples to an
XMPP presence stanza whose ’from’ address is the user@host of the
non-XMPP entity. However, an XMPP-CPIM gateway MUST NOT generate a
PIDF document with zero <tuple/> children when receiving a presence
stanza from an XMPP entity (i.e., all PIDF documents communicated by
the gateway to a non-XMPP service MUST contain at least one <tuple/>
element).
6.4. Unsubscribing
If an XMPP entity wants to unsubscribe from the presence of a
non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "unsubscribe" to the target presentity. The
syntax mapping is as follows:
o The XMPP ’from’ attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP ’to’ attribute (user@host) MUST be mapped to the CPP
"target parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the
address.
o The CPP "duration parameter" MUST be set to zero.
o The XMPP ’id’ attribute SHOULD be mapped to the CPP "TransID"
field.
If the target parameter (XMPP "to" address) does not refer to a valid
presentity, the XMPP-CPIM gateway MUST return an <item-not-found/>
stanza error to the XMPP entity.
Upon receiving the presence stanza of type "unsubscribe" from the
XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
notifications to the XMPP entity.
6.5. Cancelling a Subscription
If an XMPP entity wants to cancel a non-XMPP presentity’s
subscription to the entity’s presence through an XMPP-CPIM gateway,
it MUST send a presence stanza of type "unsubscribed" to the target
presentity. The syntax mapping is as follows:
o The XMPP ’from’ attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST add the "pres:" Presence URI scheme to the front of the
address.
o The XMPP ’to’ attribute (user@host) MUST be mapped to the CPP
"target parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST add the "pres:" Presence URI scheme to the front of the
address.
o The CPP "duration parameter" MUST be set to zero.
o The XMPP ’id’ attribute SHOULD be mapped to the CPP "TransID"
field.
Upon receiving the presence stanza of type "unsubscribed" from the
XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
notifications to the watcher presentity.
7. Security Considerations
Detailed security considerations for instant messaging and presence
protocols are given in [IMP-REQS], specifically in Sections 5.1
through 5.4.
This document specifies methods for exchanging instant messages and
presence information through a gateway that implements [CPIM] and
[CPP]. Such a gateway MUST be compliant with the minimum security
requirements of the instant messaging and presence protocols with
which it interfaces. The introduction of gateways to the security
model of instant messaging and presence in RFC 2779 also introduces
some new risks. In particular, end-to-end security properties
(especially confidentiality and integrity) between instant messaging
and presence user agents that interface through an XMPP-CPIM gateway
can be provided only if common formats are supported; these formats
are specified fully in [XMPP-E2E].
8. References
8.1. Normative References
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC
3859, August 2004.
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February
2000.
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
"Instant Messaging / Presence Protocol Requirements",
RFC 2779, February 2000.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August
2004.
[PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings (stringprep)", RFC 3454,
December 2002.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[URL-GUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November
1999.
[US-ASCII] Cerf, V., "ASCII format for network interchange", RFC
20, October 1969.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-E2E] Saint-Andre, P., Ed., "End-to-End Signing and Object
Encryption in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 3923, October 2004.
[XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and
Presence Protocol (XMPP): Instant Messaging and
Presence", RFC 3921, October 2004.
8.2. Informative References
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[MIMETYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[XMPP-PIDF] Saint-Andre, P., "Transporting Presence Information
Data/Format (PIDF) over the Extensible Messaging and
Presence Protocol (XMPP)", Work in Progress, February
2004.
Author’s Address
Peter Saint-Andre
Jabber Software Foundation
EMail: stpeter@jabber.org
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.