|
Network Working Group Request for Comments: 3343 Category: Experimental |
M. Rose Dover Beach Consulting, Inc. G. Klyne Nine by Nine D. Crocker Brandenburg InternetWorking April 2003 |
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright © The Internet Society (2003). All Rights Reserved.
This memo describes the Application Exchange (APEX) presence service, addressed as the well-known endpoint "apex=presence". The presence service is used to manage presence information for APEX endpoints.
1. Introduction
2. Use and Management of Presence Information
2.1 Update of Presence Information
2.2 Distribution of Presence Information
2.3 Distribution of Watcher Information
3. Format of Presence Entries
4. The Presence Service
4.1 Use of XML and MIME
4.2 The Subscribe Operation
4.3 The Watch Operation
4.4 The Publish Operation
4.5 The Terminate Operation
4.6 The Notify Operation
4.7 The Reply Operation
5. Registration: The Presence Service
6. The Presence Service DTD
7. Security Considerations
References
Acknowledgements
Authors' Addresses
Full Copyright Statement
This memo describes a presence service that is built upon the APEX [1] "relaying mesh". The APEX presence service is used to manage presence information for APEX endpoints.
APEX, at its core, provides a best-effort datagram service. Within an administrative domain, all relays must be able to handle messages for any endpoint within that domain. APEX services are logically defined as endpoints, but given their ubiquitous semantics they do not necessarily need to be associated with a single physical endpoint. As such, they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e.,
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
APEX applications communicate with the presence service by exchanging
data with the well-known endpoint "apex=presence" in the
corresponding administrative domain, e.g.,
"apex=presence@example.com" is the endpoint associated with the
presence service in the "example.com" administrative domain.
Note that within a single administrative domain, the presence service makes use of the APEX access [3] service in order to determine if an originator is allowed to view or manage presence information.
Management of presence information falls into three categories:
Each is now described in turn.
When an application wants to modify the presence information associated with an endpoint, it sends a publish operation to the service, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<publish publisher='fred@example.com' transID='1'
timeStamp='2000-05-14T13:30:00-08:00'>
<presence publisher='fred@example.com'
lastUpdate='2000-05-14T13:02:00-08:00'
publisherInfo='http://www.example.com/fred/'>
<tuple
destination='apex:fred/appl=im@example.com'
availableUntil='2000-05-14T14:02:00-08:00' />
<tuple destination='mailto:fred@flintstone.com'
availableUntil='2525-12-31T23:59:59-08:00' />
</presence>
</publish>
</data-content>
</data>
S: <ok />
Note that this example uses the "subaddress" convention specified in
Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of
traffic for a particular endpoint. Of course, popular applications
may have their own URI method assigned to them (e.g.,
"im:fred@example.com").
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<reply code='250' transID='1' />
</data-content>
</data>
S: <ok />
When an application wants to (periodically) receive the presence information associated with an endpoint, it sends a subscribe operation to the service, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<subscribe publisher='fred@example.com' duration='86400'
transID='100' />
</data-content>
</data>
S: <ok />
The service immediately responds with a publish operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<publish publisher='fred@example.com' transID='100'
timeStamp='2000-05-14T13:30:00-08:00'>
<presence publisher='fred@example.com'
lastUpdate='2000-05-14T13:02:00-08:00'
publisherInfo='http://www.example.com/fred/'>
<tuple
destination='apex:fred/appl=im@example.com'
availableUntil='2000-05-14T14:02:00-08:00' />
</presence>
</publish>
</data-content>
</data>
S: <ok />
Subsequently, for up to the specified "duration", the service sends new publish operations whenever there are any changes to the endpoint's presence information. If the "duration" is zero-valued, a one time poll of the presence information is achieved; otherwise, at the end of the "duration", a terminate operation is sent.
Note that Step 5 of Section 4.4 requires that the "lastUpdate"
attribute of a presence entry be supplied in order to update that
entry; accordingly, applications must successfully retrieve a
presence entry prior to trying to update that entry. This is usually
accomplished by subscribing with a zero-valued duration.
(Regardless, administrators should ensure that applications
authorized to update a presence entry are also authorized to retrieve
that entry.)
Either the subscriber or the service may cancel a subscription by sending a terminate operation, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<terminate transID='100' />
</data-content>
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<reply code='250' transID='100' />
</data-content>
</data>
S: <ok />
or
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<terminate transID='100' />
</data-content>
</data>
S: <ok />
When an application wants to (periodically) receive notices about endpoints that are subscribed to receive presence information, it sends a watch operation to the service, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<watch publisher='fred@example.com' duration='86400'
transID='2' />
</data-content>
</data>
S: <ok />
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'
<reply code='250' transID='2' />
</data-content>
</data>
S: <ok />
For each current subscriber, the service immediately sends a notify operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<notify subscriber='wilma@example.com' transID='2'
duration='86000' action='subscribe' />
</data-content>
</data>
S: <ok />
Subsequently, for up to the specified "duration", the service sends new notify operations whenever an application subscribes successfully or a subscription is terminated. If the "duration" is zero-valued, a one time poll of the watcher information is achieved; otherwise, at the end of the "duration", a terminate operation is sent.
Either the watcher or the service may cancel the request by sending a terminate operation, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<terminate transID='2' />
</data-content>
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<reply code='250' transID='2' />
</data-content>
</data>
S: <ok />
or
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<terminate transID='2' />
</data-content>
</data>
S: <ok />
Each administrative domain is responsible for maintaining a "presence entry" for each of its endpoints (regardless of whether those endpoints are currently attached to the relaying mesh).
Section 6 defines the syntax for presence entries. Each presence entry has a "publisher" attribute, a "lastUpdate" attribute, a "publisherInfo" attribute, and contains one or more "tuple" elements:
Each "tuple" element has a "destination" attribute, an
"availableUntil" attribute, a "tupleInfo" attribute, and contains
zero or more "capability" elements:
Each "capability" element contains arbitrary character data formatted according to the standard indicated in the element's "baseline" attribute.
Section 5 contains the APEX service registration for the presence service:
An implementation of the service must maintain information about both presence entries and in-progress operations in persistent storage.
Consult Section 6.1.1 of [1] for a discussion on the properties of long-lived transaction-identifiers.
Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a BEEP [2] payload. For example, to transmit:
<data content='...'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
</data>
where "..." refers to: <reply code='250' transID='1' />
then the corresponding BEEP message might look like this:
C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=presence@example.com' />
C: </data>
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <2@example.com>
C:
C: <reply code='250' transID='1' />
C: --boundary--
C: END
or this:
C: MSG 1 1 . 42 1234
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=presence@example.com' />
C: <data-content Name='Content'>
C: <reply code='250' transID='1' />
C: </data-content>
C: </data>
C: END
When an application wants to (periodically) receive the presence information associated with an endpoint, it sends a "subscribe" element to the service.
The "subscribe" element has a "publisher" attribute, a "duration" attribute, a "transID" attribute, and no content:
When the service receives a "subscribe" element, we refer to the "publisher" attribute of that element as the "subject", and the service performs these steps:
Note that if the duration is zero-valued, then the subscribe operation is making a one-time poll of the presence information. Accordingly, Step 6.3 above does not occur.
Regardless of whether a "publish" or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "subscribe" element sent by the originator.
When an application wants to (periodically) receive notices about endpoints that are subscribed to receive presence entry, it sends a "watch" element to the service.
The "watch" element has a "publisher" attribute, a "duration" attribute, a "transID" attribute, and no content:
When the service receives a "watch" element, we refer to the "publisher" attribute of that element as the "subject", and the service performs these steps:
Note that if the duration is zero-valued, then the watch operation is making a one-time poll of the presence information. Accordingly, Step 6.3 above does not occur.
Regardless of whether a "notify" or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "presence" element sent by the originator.
When an application wants to modify the presence entry associated with an endpoint, it sends a "publish" element to the service. In addition, the service sends a "publish" element to endpoints that have subscribed to see presence information (c.f., Section 4.2).
The "publish" element has a "publisher" attribute, a "transID" attribute, a "timeStamp" attribute, and contains a "presence" element:
When the service sends a "publish" element, the "transID" attribute specifies the transaction-identifier associated with the subscribe operation that caused this "publish" element to be sent, and the "timeStamp" attribute specifies the service's notion of the current date and time. No reply is sent by the receiving endpoint.
When the service receives a "publish" element, we refer to the "publisher" attribute of that element as the "subject", and the service performs these steps:
When sending the "reply" element, the "transID" attribute is identical to the value found in the "publish" element sent by the originator.
When an application no longer wishes to subscribe to presence information or to watch endpoints that are subscribed to receive presence information, it sends a "terminate" element to the service; similarly, when the service no longer considers an application to be subscribing or watching, a "terminate" element is sent to the application.
The "terminate" element contains only a "transID" attribute that specifies the transaction-identifier associated an in-progress subscribe or watch operation. Section 9.1 of [1] defines the syntax for the "terminate" element.
When the service receives a "terminate" element, it performs these steps:
Note that following a terminate operation, the originator may receive further presence or watcher updates. Although the service will send no further updates after processing a terminate operation and sending the reply operation, earlier updates may be in transit.
The service sends a "notify" element to endpoints that are watching other endpoints subscribed to presence information (c.f., Section 4.3).
The "notify" element has a "subscriber" attribute, a "transID" attribute, a "duration" attribute, an "action" attribute, and no content:
No reply is sent by the receiving endpoint.
While processing operations, the service may respond with a "reply" element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for the definition and an exposition of the syntax of the reply element.
Well-Known Endpoint: apex=presence
Syntax of Messages Exchanged: c.f., Section 6
Sequence of Messages Exchanged: c.f., Section 4
Access Control Tokens: presence:subscribe, presence:watch, presence:publish
Contact Information: c.f., the "Authors' Addresses" section of this memo
<!--
DTD for the APEX presence service, as of 2001-05-08
Refer to this DTD as:
<!ENTITY % APEXPRESENCE PUBLIC "-//IETF//DTD APEX PRESENCE//EN"
"">
%APEXPRESENCE;
-->
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
<!--
Synopsis of the APEX presence service
service WKE: apex=presence
message exchanges:
consumer initiates service replies
================== ================
subscribe publish or reply
terminate reply
watch reply
publish reply
service initiates consumer replies
================= ================
terminate (nothing)
publish (nothing)
notify (nothing)
access control:
token target
================== ======
presence:subscribe for "publisher" of "subscribe" element
presence:watch for "publisher" of "watch" element
presence:publish for "publisher" of "publish" element
-->
<!ELEMENT subscribe EMPTY>
<!ATTLIST subscribe
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; #REQUIRED>
<!ELEMENT watch EMPTY>
<!ATTLIST watch
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; #REQUIRED>
<!-- publisher attributes must match in publish and presence -->
<!ELEMENT publish (presence)>
<!ATTLIST publish
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
timeStamp %TIMESTAMP; #REQUIRED>
<!ELEMENT notify EMPTY>
<!ATTLIST notify
subscriber %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; "0"
action (subscribe|terminate)
"subscribe">
<!--
presence entries
-->
<!ELEMENT presence (tuple+)>
<!ATTLIST presence
publisher %ENDPOINT; #REQUIRED
lastUpdate %TIMESTAMP; #REQUIRED
publisherInfo
%URI; "">
<!ELEMENT tuple (capability*)>
<!ATTLIST tuple
destination %URI; #REQUIRED
availableUntil
%TIMESTAMP; #REQUIRED
tupleInfo %URI; "">
<!-- e.g., baseline='urn:ietf:rfc:rfc2533' -->
<!ELEMENT capability (#PCDATA)>
<!ATTLIST capability
baseline %URI #REQUIRED>
Consult [1]'s Section 11 for a discussion of security issues.
In addition, timestamps issued by the the presence service may disclose location information. If this information is considered sensitive, the special timezone value "-00:00" may be used (after converting the local time accordingly).
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", RFC 3340, July 2002.
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[3] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
(APEX) Access Service", RFC 3341, July 2002.
The authors gratefully acknowledge the contributions of: Neil Cook, Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Graham Klyne
Nine by Nine
EMail: gk@ninebynine.org
David H. Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
US
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
Copyright © The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the Internet Society.