RFC 3859
Common Profile for Presence (CPP)
RFC 3859: Common Profile for Presence (CPP) 💖
Okay bestie, let's get the basics down first 🎀 This is RFC 3859, and its title is Common Profile for Presence (CPP). It came out of the Network Working Group, and J. Peterson from NeuStar wrote it. The category is Standards Track, and the date is August 2004. The header doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC in this copy 🧚
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice 💜
Copyright (C) The Internet Society (2004).
Abstract 🦋
Back when this was written, there were loads of presence protocols floating around, mostly as parts of commercial instant messaging services. The problem was that services built on these protocols barely talked to each other 😭 This spec sets up common semantics and data formats for presence, so gateways between presence services can actually be built 💅
Table of Contents 🌸
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abstract Presence Service . . . . . . . . . . . . . . . . . . 4
3.1. Overview of the Presence Service . . . . . . . . . . . . 4
3.2. Identification of PRESENTITIES and WATCHERS . . . . . . 6
3.2.1. Address Resolution . . . . . . . . . . . . . . . 6
3.3. Format of Presence Information . . . . . . . . . . . . . 6
3.4. The Presence Service . . . . . . . . . . . . . . . . . . 7
3.4.1. The Subscribe Operation . . . . . . . . . . . . 7
3.4.2. The Notify Operation . . . . . . . . . . . . . . 8
3.4.3. Subscribe Operation (with Zero Duration) . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. The PRES URI Scheme . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
A. PRES URI IANA Registration Template . . . . . . . . . . . . . 12
A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 12
A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 12
A.3. Character Encoding Considerations . . . . . . . . . . . 12
A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 12
A.5. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.6. Interoperability Considerations . . . . . . . . . . . . 13
A.7. Security Considerations . . . . . . . . . . . . . . . . 13
A.8. Relevant Publications . . . . . . . . . . . . . . . . . 13
A.9. Person & Email Address to Contact for Further
Information. . . . . . . . . . . . . . . . . . . . . . . 13
A.10. Author/Change Controller . . . . . . . . . . . . . . . . 13
A.11. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 13
B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 13
B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 13
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 151. Introduction ✨
Okay so presence is defined in RFC2778 [5] 🌟 When this was written, tons of presence protocols were in use (mostly inside commercial instant messaging services), and they barely interoperated with each other 💀 This spec defines semantics and data formats for the common services of presence, so gateways between presence services can be built. That's the common profile for presence (CPP) and it's giving main character energy 👑
Service behavior is described abstractly, in terms of operations invoked between the consumer and provider of a service. So each presence service has to spell out how that behavior maps onto its own protocol interactions 🦋 The strategy is totally a local choice, as long as there's a clear relation between the abstract behaviors of the service (as specified in this memo) and how a particular presence service faithfully realizes them. For example, one strategy might send presence info as key/value pairs, another might use a compact binary representation, and a third might use nested containers 🧚
The parameters for each operation are defined using an abstract syntax. The syntax specifies the range of possible data values, but each presence service has to say how well-formed instances of the abstract representation get encoded as a concrete series of bits 🫶
Last thing: to keep end-to-end features (especially security) working as they pass through presence interoperability gateways, this spec also gives recommendations for presence document formats that presence protocols could use 🔒
2. Terminology 💅
Here's the key word situation, and it's important: in this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1]. They indicate requirement levels for compliant implementations 😭🔥
This memo uses the vocabulary defined in RFC 2778 [5]. Terms like CLOSED, INSTANT INBOX, PRESENCE, and OPEN have the same meaning as they do there 🌸
The term 'gateway' in this document means a network element responsible for interworking between diverse presence protocols. The protocols themselves are all different, but under this model they can carry a common payload that the gateway relays 🧚 Honestly, whether these interworking middlemen should be called 'gateways' or 'relays' is kinda debatable 🙈 For this document, they're called 'CPP gateways' and we're moving on ✨
The term 'presence service' also comes from RFC 2778, but its meaning shifts a bit because of gateways in the CPP model. When a client sends an operation to a presence service, that service might be an endpoint, or it might be an intermediary like a CPP gateway. Honestly, the client shouldn't have to care which one it's talking to, since the responses from either will look the same 💖
This document defines the operations and attributes of an abstract presence protocol. For a compliant protocol to interface with a presence gateway, it must support all of the operations described here. In other words, the presence protocol must have some message or capability that provides the function described by each given operation 🎀 Similarly, the attributes defined for these operations must correspond to information available in the presence protocol, so the protocol can interface with gateways defined by this spec 🦋 Note that these attributes only give the minimum info needed for interoperability. The functions in a presence protocol that match the operations here can carry extra info that CPP won't map, and that's totally fine 🌈
3. Abstract Presence Service 🌟
Part 1 of 3 done, bestie! Part 2 picks up right here 💖
3.1. Overview of the Presence Service ✨
okay so bestie, when an app wants to keep tabs on the presence info of a PRESENTITY (aka get periodic updates, iykyk) 💖 it invokes the subscribe operation, like this:
+-------+ +-------+
| | | |
| appl. | -- subscribe ----> | pres. |
| | | svc. |
+-------+ +-------+the subscribe operation has five attributes: watcher, target, duration, SubscriptID and TransID 🎀. watcher and target name the WATCHER and PRESENTITY using the identifiers from Section 3.2. duration is the max number of seconds the SUBSCRIPTION should stay active (and it can be zero, which just means one-time request for presence info 🦋). SubscriptID is the reference you use later when you unsubscribe. TransID is a unique ID that lets the subscribe operation be matched up with its response 🔥. Gateways should be capable of handling TransIDs and SubscriptIDs up to 40 bytes long, periodt 💅.
upon receiving a subscribe operation, the service immediately responds by invoking the response operation with the same TransID ✨
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+the response operation has status, TransID and duration 🌸. status tells you whether the subscribe worked or flopped. The response's TransID matches the subscribe's TransID, obviously 🙈. And duration is how many seconds the subscription will actually be active, which can be different from what you asked for 👑.
if the response says success, the service immediately invokes the notify operation to send the presence info to the WATCHER 🧚
+-------+ +-------+
| | | |
| appl. | <------- notify -- | pres. |
| | | svc. |
+-------+ +-------+the notify operation has watcher, target and TransID 💜. The watcher and target values are exactly the same as in the subscribe that started all this. The TransID is a unique ID for this one notification. The notify operation also carries content, which is PRESENCE INFORMATION. You can read all about the content in Section 3.3 🍓.
if duration is non-zero, then for up to that long, the service invokes notify whenever the PRESENTITY's presence info changes 🌈. Otherwise, exactly one notify gets invoked, which is basically a one-time poll of the presence info ⭐. Either way, there's no application response to notify (the app never invokes a response operation when a notify happens) defined in CPP 💀.
the application may prematurely cancel a subscription by re-invoking the subscribe operation (same as before) with a duration of 0 and the same SubscriptID as the original subscribe operation 🫶
+-------+ +-------+
| | | |
| appl. | -- subscribe 0 --> | pres. |
| | | svc. |
+-------+ +-------+heads up: a notify operation will still be invoked when you cancel like this, and the watcher is allowed to toss that notification out 🗑️ no judgment.
the service immediately responds by invoking the response operation with the same TransID, e.g.,
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+this spec assumes CPP-compliant presence protocols give you reliable message delivery 😭 There are no application-layer delivery assurance provisions in this spec, so trust the transport, bestie.
3.2. Identification of PRESENTITIES and WATCHERS
a PRESENTITY is specified with the PRES URI scheme, which gets a deeper dive in Appendix A 🦋 for example: pres:fred@example.com ✨
WATCHERs identify themselves the same way PRESENTITIES do, so with a pres URI 💖
3.2.1. Address Resolution
a presence service client figures out the next hop for an operation by resolving the domain name part of the service destination 🧭. Compliant implementations SHOULD follow the guidelines for dereferencing URIs given in [2] 🎀.
3.3. Format of Presence Information
this spec is an abstract interop mechanism for presence protocols, so the message content stuff here is about semantics, not syntax 🌸. BUT, some super important interop and security properties only work if all the interoperating presence protocols use one common end-to-end format for presence 🔐. So applications that send notify operations through a CPP gateway MUST support the format defined in PIDF [4]. Applications MAY support other content formats too 🌈.
CPP gateways MUST be capable of relaying the body of a notify operation between supported presence protocols without needing to modify or inspect the content 🫶 no peeking, no editing, just vibes.
3.4. The Presence Service
an implementation of the service has to keep info about both presence information and continual operations (like periodic notification) in persistent storage 💾.
the subscription-identifier attribute used by the subscribe operation can be long-lived 🕰️ so the values generated for this parameter should be unique across a significant span of time. The SubscriptID should be intrinsically globally unique over time, not just unique among operations sent to or from one particular WATCHER and PRESENTITY pair 👑.
3.4.1. The Subscribe Operation
when an application wants to subscribe to a PRESENTITY's presence info, it invokes the subscribe operation 💖.
when the service gets told about a subscribe operation, it does these steps, in order ✨:
- if the
watcherortargetparameter doesn't refer to a valid PRESENTITY, a response operation withstatus"failure" gets invoked 🙈. - if access control doesn't let the application request this operation, a response operation with
status"failure" gets invoked 🔒. - if
durationis non-zero and thewatcherandtargetrefer to an in-progress subscribe operation for the application, a response operation withstatus"failure" gets invoked 💀. - otherwise, if the service can successfully deliver the message:
- a response operation with
status"success" is immediately invoked 🎉. (If the service picks a different duration for the subscription, it tells you that in the response operation.) - a notify operation, matching the target's presence info, is immediately invoked for the watcher 🧚.
- for up to the amount of time in the
durationparameter (counted from when the subscribe operation was received), if the target's presence info changes and access control allows it, a notify operation is invoked for the watcher 🦋.
- a response operation with
note that if duration is zero, the subscribe operation is a one-time poll of presence info. So the final step above (ongoing notifications for the life of the subscription) just doesn't happen 🍓.
when the service invokes a response operation because of this processing, the transID parameter is identical to the value in the subscribe operation the application invoked 💜.
3.4.2. The Notify Operation
the service invokes the notify operation whenever the presence info for a PRESENTITY changes and there are subscribers asking for notifications about that PRESENTITY 🔔.
there's no application response to the notify operation 🙅♀️.
3.4.3. Subscribe Operation (with Zero Duration)
when an application wants to end a subscription, it issues a SUBSCRIBE 0 with the SubscriptID of the existing subscription 🫶. A notify operation will be invoked by the presentity when a subscription gets canceled this way, and the watcher can toss that notification out 🗑️. There is no independent UNSUBSCRIBE operation, so this is the way 💅.
when an application wants presence info right now, without setting up any persistent subscription, it issues a SUBSCRIBE 0 with a new SubscriptID ⚡. There is no independent FETCH operation either, so one-and-done it is 🌸.
4. Security Considerations 🔒✨
Okay bestie, this part is SO important, so no playing around 😭. The detailed security considerations for presence protocols are in RFC 2779 [6], especially the requirements in sections 5.1 through 5.3, with some motivating discussion in 8.2 💅.
CPP defines an interoperability function that gateways between presence protocols use 🌈. CPP gateways MUST be compliant with the minimum security requirements of the presence protocols they interface with. No exceptions, periodt 💀.
Okay, here's the plot twist 🙈. Adding gateways to the presence security model from RFC 2779 also introduces some new risks. End-to-end security properties (especially confidentiality and integrity) between presentities and watchers that talk through a CPP gateway can only be provided if a common presence format (such as the format described in [4]) is supported by the protocols interfacing with the CPP gateway. So the format matters a LOT 👑.
When end-to-end security is required, the notify operation MUST use PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS SignedData) 🔐🔥.
The S/MIME algorithms are set by CMS [9]. The AES [11] algorithm should be preferred, as it is expected that AES best suits the capabilities of many platforms 🦋. Implementations MAY use AES as an encryption algorithm, but they are REQUIRED to support only the baseline algorithms mandated by S/MIME and CMS. Bare minimum, but make it make sense 💅.
When PRES URIs are used in presence protocols, they convey the identity of watchers and/or presentities 🫶. Certificates used for S/MIME presence operations SHOULD, for the purposes of reference integrity, contain a subjectAltName field containing the PRES URI of their subject. Certificates may also hold other identifiers, including ones specific to particular presence protocols. To make secure presence work smoothly through CPP gateways, users and service providers are encouraged to use trust anchors that are widely accepted, rather than trust anchors specific to one presence service or provider. Interop is the whole vibe ✨.
In some cases, anonymous presence services may be desired 🙈. That kind of capability is beyond the scope of this specification, so we're leaving it for another day 🧚.
5. IANA Considerations 🌸
The IANA has assigned the "pres" URI scheme 🎀.
5.1. The PRES URI Scheme
The Presence (PRES) URI scheme designates an Internet resource, namely a PRESENTITY or WATCHER 💜.
The syntax of a PRES URI is given in Appendix A.
6. Contributors 🫶
Dave Crocker edited earlier versions of this document. Iconic behavior 👑.
The following individuals made substantial textual contributions to this document:
- Athanassios Diacakis (thanos.diacakis@openwave.com)
- Florencio Mazzoldi (flo@networkprojects.com)
- Christian Huitema (huitema@microsoft.com)
- Graham Klyne (gk@ninebynine.org)
- Jonathan Rosenberg (jdrosen@dynamicsoft.com)
- Robert Sparks (rsparks@dynamicsoft.com)
- Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
7. References 📚
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April 2001.
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[7] Allocchio, C., "GSTN Address Element Extensions in Email Services", RFC 2846, June 2000.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
7.2. Informative References
[11] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm and in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
Appendix A. PRES URI IANA Registration Template 🎀
This section provides the information to register the pres: presence URI .
A.1. URI Scheme Name
pres
A.2. URI Scheme Syntax
The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is:
PRES-URI = "pres:" [ to ] [ headers ]
to = mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *uric
hvalue = *uricHere the symbol "mailbox" represents an encoded mailbox name as defined in RFC 2822 [3], and the symbol "uric" denotes any character that is valid in a URL (defined in RFC 2396 [10]).
A.3. Character Encoding Considerations
Representation of non-ASCII character sets in local-part strings is limited to the standard methods provided as extensions to RFC 2822 [3].
A.4. Intended Usage
Use of the pres: URI follows closely usage of the mailto: URI. That is, invocation of an PRES URI will cause the user's instant messaging application to start, with destination address and message headers fill-in according to the information supplied in the URI 💬.
A.5. Applications and/or Protocols which use this URI Scheme Name
It is anticipated that protocols compliant with RFC 2779, and meeting the interoperability requirements specified here, will make use of this URI scheme name.
A.6. Interoperability Considerations
The underlying exchange protocol used to send an instant message may vary from service to service. Therefore complete, Internet-scale interoperability cannot be guaranteed. However, a service conforming to this specification permits gateways to achieve interoperability sufficient to the requirements of RFC 2779.
A.7. Security Considerations
See Section 4.
A.8. Relevant Publications
A.9. Person & Email Address to Contact for Further Information
Jon Peterson [mailto:jon.peterson@neustar.biz]
A.10. Author/Change Controller
This scheme is registered under the IETF tree. As such, IETF maintains change control.
A.11. Applications and/or Protocols which use this URI Scheme Name
Instant messaging service; presence service
Appendix B. Issues of Interest 🧠
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway ✨.
B.1. Address Mapping
When mapping the service described in this memo, mappings that place special information into the im: address local-part MUST use the meta-syntax defined in RFC2846 [7]. Non-negotiable, bestie 🙅♀️.
B.2. Source-Route Mapping
The easiest mapping technique is a form of source-routing, and it's usually the least friendly to humans having to type the string 😭. Source-routing also has a history of operational problems.
Use of source-routing for exchanges between different services is done by a transformation that places the entire, original address string into the im: address local part and names the gateway in the domain part.
For example, if the destination INSTANT INBOX is pepp://example.com/fred, then, after performing the necessary character conversions, the resulting mapping is:
im:pepp=example.com/fred@relay-domainwhere "relay-domain" is derived from local configuration information.
Experience shows that it is vastly preferable to hide this mapping from end-users. If possible, the underlying software should perform the mapping automatically 🫶.
Appendix C. Acknowledgments 💖
The author would like to acknowledge John Ramsdell for his comments, suggestions and enthusiasm. Thanks to Derek Atkins for editorial fixes 🌷.
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.bizFull 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/SHE 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 procedures with respect to rights in RFC 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 💅✨
📦 where this page comes from
- ietf: rfc3859 2004-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms