draft-ietf-apex-presence-06.txt   rfc3343.txt 
Network Working Group M. Rose Network Working Group M. Rose
Internet-Draft Dover Beach Consulting, Inc. Request for Comments: 3343 Dover Beach Consulting, Inc.
Expires: July 15, 2002 G. Klyne Category: Experimental G. Klyne
MIMEsweeper Group Nine by Nine
D. Crocker D. Crocker
Brandenburg Consulting Brandenburg InternetWorking
January 14, 2002 April 2003
The APEX Presence Service The Application Exchange (APEX) Presence Service
draft-ietf-apex-presence-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo defines an Experimental Protocol for the Internet
all provisions of Section 10 of RFC2026. community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Internet-Drafts are working documents of the Internet Engineering Distribution of this memo is unlimited.
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo describes the APEX presence service, addressed as the well- This memo describes the Application Exchange (APEX) presence service,
known endpoint "apex=presence". The presence service is used to addressed as the well-known endpoint "apex=presence". The presence
manage presence information for APEX endpoints. service is used to manage presence information for APEX endpoints.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use and Management of Presence Information . . . . . . . . . . 4 2. Use and Management of Presence Information . . . . . . . . . . 3
2.1 Update of Presence Information . . . . . . . . . . . . . . . . 5 2.1 Update of Presence Information . . . . . . . . . . . . . . . . 3
2.2 Distribution of Presence Information . . . . . . . . . . . . . 7 2.2 Distribution of Presence Information . . . . . . . . . . . . . 4
2.3 Distribution of Watcher Information . . . . . . . . . . . . . 10 2.3 Distribution of Watcher Information . . . . . . . . . . . . . 7
3. Format of Presence Entries . . . . . . . . . . . . . . . . . . 13 3. Format of Presence Entries . . . . . . . . . . . . . . . . . . 10
4. The Presence Service . . . . . . . . . . . . . . . . . . . . . 14 4. The Presence Service . . . . . . . . . . . . . . . . . . . . . 11
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 15 4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 12
4.2 The Subscribe Operation . . . . . . . . . . . . . . . . . . . 16 4.2 The Subscribe Operation . . . . . . . . . . . . . . . . . . . 13
4.3 The Watch Operation . . . . . . . . . . . . . . . . . . . . . 18 4.3 The Watch Operation . . . . . . . . . . . . . . . . . . . . . 14
4.4 The Publish Operation . . . . . . . . . . . . . . . . . . . . 20 4.4 The Publish Operation . . . . . . . . . . . . . . . . . . . . 15
4.5 The Terminate Operation . . . . . . . . . . . . . . . . . . . 22 4.5 The Terminate Operation . . . . . . . . . . . . . . . . . . . 17
4.6 The Notify Operation . . . . . . . . . . . . . . . . . . . . . 23 4.6 The Notify Operation . . . . . . . . . . . . . . . . . . . . . 17
4.7 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 23 4.7 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 18
5. Registration: The Presence Service . . . . . . . . . . . . . . 24 5. Registration: The Presence Service . . . . . . . . . . . . . . 18
6. The Presence Service DTD . . . . . . . . . . . . . . . . . . . 25 6. The Presence Service DTD . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 31 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
B.1 Changes from draft-ietf-apex-presence-05 . . . . . . . . . . . 31
B.2 Changes from draft-ietf-apex-presence-04 . . . . . . . . . . . 31
B.3 Changes from draft-ietf-apex-presence-03 . . . . . . . . . . . 31
B.4 Changes from draft-ietf-apex-presence-02 . . . . . . . . . . . 31
B.5 Changes from draft-ietf-apex-presence-01 . . . . . . . . . . . 31
B.6 Changes from draft-ietf-apex-presence-00 . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This memo describes a presence service that is built upon the APEX This memo describes a presence service that is built upon the APEX
[1] "relaying mesh". The APEX presence service is used to manage [1] "relaying mesh". The APEX presence service is used to manage
presence information for APEX endpoints. presence information for APEX endpoints.
APEX, at its core, provides a best-effort datagram service. Within APEX, at its core, provides a best-effort datagram service. Within
an administrative domain, all relays must be able to handle messages an administrative domain, all relays must be able to handle messages
for any endpoint within that domain. APEX services are logically for any endpoint within that domain. APEX services are logically
defined as endpoints but given their ubiquitous semantics they do not defined as endpoints, but given their ubiquitous semantics they do
necessarily need to be associated with a single physical endpoint. not necessarily need to be associated with a single physical
As such, they may be provisioned co-resident with each relay within endpoint. As such, they may be provisioned co-resident with each
an administrative domain, even though they are logically provided on relay within an administrative domain, even though they are logically
top of the relaying mesh, i.e., provided on top of the relaying mesh, i.e.,
+----------+ +----------+ +----------+ +---------+ +----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | | | APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... | | access | | presence | | report | | ... |
| service | | service | | service | | | | service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+ +----------+ +----------+ +----------+ +---------+
| | | | | | | |
| | | | | | | |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| | | |
skipping to change at page 8, line 40 skipping to change at page 5, line 40
S: <ok /> S: <ok />
Subsequently, for up to the specified "duration", the service sends Subsequently, for up to the specified "duration", the service sends
new publish operations whenever there are any changes to the new publish operations whenever there are any changes to the
endpoint's presence information. If the "duration" is zero-valued, a endpoint's presence information. If the "duration" is zero-valued, a
one time poll of the presence information is achieved; otherwise, at one time poll of the presence information is achieved; otherwise, at
the end of the "duration", a terminate operation is sent. the end of the "duration", a terminate operation is sent.
Note that Step 5 of Section 4.4 requires that the "lastUpdate" Note that Step 5 of Section 4.4 requires that the "lastUpdate"
attribute of a presence entry be supplied in order to update that attribute of a presence entry be supplied in order to update that
entry; accordingly, applications must successfully retrieve an entry; accordingly, applications must successfully retrieve a
presence entry prior to trying to update that entry. This is usually presence entry prior to trying to update that entry. This is usually
accomplished by subscribing with a zero-valued duration. accomplished by subscribing with a zero-valued duration.
(Regardless, administrators should ensure that applications (Regardless, administrators should ensure that applications
authorized to update a precense entry are also authorized to retrieve authorized to update a presence entry are also authorized to retrieve
that entry.) that entry.)
Either the subscriber or the service may cancel a subscription by Either the subscriber or the service may cancel a subscription by
sending a terminate operation, e.g., sending a terminate operation, e.g.,
+-------+ +-------+ +-------+ +-------+
| | -- data -------> | | | | -- data -------> | |
| appl. | | relay | | appl. | | relay |
| | <--------- ok -- | | | | <--------- ok -- | |
+-------+ +-------+ +-------+ +-------+
skipping to change at page 17, line 9 skipping to change at page 13, line 28
associated with this operation; and, associated with this operation; and,
o the "duration" attribute specifies the maximum number of seconds o the "duration" attribute specifies the maximum number of seconds
for which the originator is interested in receiving updated for which the originator is interested in receiving updated
presence information. presence information.
When the service receives a "subscribe" element, we refer to the When the service receives a "subscribe" element, we refer to the
"publisher" attribute of that element as the "subject", and the "publisher" attribute of that element as the "subject", and the
service performs these steps: service performs these steps:
1. If the subject is outside of this administrative domain, a 1. If the subject is outside of this administrative domain, a "reply"
"reply" element having code 553 is sent to the originator. element having code 553 is sent to the originator.
2. If the subject does not refer to a valid endpoint, a "reply" 2. If the subject does not refer to a valid endpoint, a "reply"
element having code 550 is sent to the originator. element having code 550 is sent to the originator.
3. If the subject's access entry does not contain a 3. If the subject's access entry does not contain a
"presence:subscribe" token for the originator, a "reply" element "presence:subscribe" token for the originator, a "reply" element
having code 537 is sent to the originator. having code 537 is sent to the originator.
4. If the originator already has an in-progress subscribe operation 4. If the originator already has an in-progress subscribe operation
for the subject, then the previous subscribe operation is for the subject, then the previous subscribe operation is silently
silently terminated, and processing continues. terminated, and processing continues.
5. If the "transID" attribute refers to an in-progress subscribe or 5. If the "transID" attribute refers to an in-progress subscribe or
watch operation for the originator, a "reply" element having code watch operation for the originator, a "reply" element having code
555 is sent to the originator. 555 is sent to the originator.
6. Otherwise: 6. Otherwise:
1. A "publish" element, corresponding to the subject's presence 1. A "publish" element, corresponding to the subject's presence
entry, is immediately sent to the originator. entry, is immediately sent to the originator.
2. For each endpoint currently watching subscribers to the 2. For each endpoint currently watching subscribers to the
subject's presence information, a "notify" element is subject's presence information, a "notify" element is
immediately as sent (c.f., Step 6.3 of Section 4.6). immediately as sent (c.f., Step 6.3 of Section 4.6).
3. For up to the amount of time indicated by the "duration" 3. For up to the amount of time indicated by the "duration"
attribute of the "subscribe" element, if the subject's attribute of the "subscribe" element, if the subject's presence
presence entry changes, an updated "presence" element is sent entry changes, an updated "presence" element is sent to the
to the originator using the publish operation (Section 4.4). originator using the publish operation (Section 4.4). Finally,
Finally, when the amount of time indicated by the "duration" when the amount of time indicated by the "duration" attribute
attribute expires, a terminate operation (Section 4.5) is expires, a terminate operation (Section 4.5) is sent to the
sent to the originator. originator.
Note that if the duration is zero-valued, then the subscribe Note that if the duration is zero-valued, then the subscribe
operation is making a one-time poll of the presence information. operation is making a one-time poll of the presence information.
Accordingly, Step 6.3 above does not occur. Accordingly, Step 6.3 above does not occur.
Regardless of whether a "publish" or "reply" element is sent to the Regardless of whether a "publish" or "reply" element is sent to the
originator, the "transID" attribute is identical to the value found originator, the "transID" attribute is identical to the value found
in the "subscribe" element sent by the originator. in the "subscribe" element sent by the originator.
4.3 The Watch Operation 4.3 The Watch Operation
When an application wants to (periodically) receive notices about When an application wants to (periodically) receive notices about
endpoints that are subscribed to receive presence entry, it sends a endpoints that are subscribed to receive presence entry, it sends a
"watch" element to the service. "watch" element to the service.
skipping to change at page 19, line 9 skipping to change at page 14, line 47
o the "transID" attribute specifies the transaction-identifier o the "transID" attribute specifies the transaction-identifier
associated with this operation; and, associated with this operation; and,
o the "duration" attribute specifies the maximum number of seconds o the "duration" attribute specifies the maximum number of seconds
for which the originator is interested in watching subscribers. for which the originator is interested in watching subscribers.
When the service receives a "watch" element, we refer to the When the service receives a "watch" element, we refer to the
"publisher" attribute of that element as the "subject", and the "publisher" attribute of that element as the "subject", and the
service performs these steps: service performs these steps:
1. If the subject is outside of this administrative domain, a 1. If the subject is outside of this administrative domain, a "reply"
"reply" element having code 553 is sent to the originator. element having code 553 is sent to the originator.
2. If the subject does not refer to a valid endpoint, a "reply" 2. If the subject does not refer to a valid endpoint, a "reply"
element having code 550 is sent to the originator. element having code 550 is sent to the originator.
3. If the subject's access entry does not contain a "presence:watch" 3. If the subject's access entry does not contain a "presence:watch"
token for the originator, a "reply" element having code 537 is token for the originator, a "reply" element having code 537 is
sent to the originator. sent to the originator.
4. If the originator already has an in-progress watch operation for 4. If the originator already has an in-progress watch operation for
the subject, then the previous watch operation is silently the subject, then the previous watch operation is silently
terminated, and processing continues. terminated, and processing continues.
5. If the "transID" attribute refers to an in-progress subscribe or 5. If the "transID" attribute refers to an in-progress subscribe or
watch operation for the originator, a "reply" element having code watch operation for the originator, a "reply" element having code
555 is sent to the originator. 555 is sent to the originator.
6. Otherwise: 6. Otherwise:
1. A "reply" element having code 250 is sent to the originator. 1. A "reply" element having code 250 is sent to the originator.
2. For each endpoint currently subscribing to the subject's 2. For each endpoint currently subscribing to the subject's
presence information, a "notify" element is immediately sent presence information, a "notify" element is immediately sent to
to the originator (c.f., Section 4.6). the originator (c.f., Section 4.6).
3. For up to the amount of time indicated by the "duration" 3. For up to the amount of time indicated by the "duration"
attribute of the "watch" element, whenever a subscribe attribute of the "watch" element, whenever a subscribe
operation succeeds or a subscription is terminated, a operation succeeds or a subscription is terminated, a "notify"
"notify" element is sent to the originator. Finally, when element is sent to the originator. Finally, when the amount of
the amount of time indicated by the "duration" attribute time indicated by the "duration" attribute expires, a terminate
expires, a terminate operation (Section 4.5) is sent to the operation (Section 4.5) is sent to the originator.
originator.
Note that if the duration is zero-valued, then the watch Note that if the duration is zero-valued, then the watch operation
operation is making a one-time poll of the presence information. is making a one-time poll of the presence information.
Accordingly, Step 6.3 above does not occur. Accordingly, Step 6.3 above does not occur.
Regardless of whether a "notify" or "reply" element is sent to the Regardless of whether a "notify" or "reply" element is sent to the
originator, the "transID" attribute is identical to the value found originator, the "transID" attribute is identical to the value found
in the "presence" element sent by the originator. in the "presence" element sent by the originator.
4.4 The Publish Operation 4.4 The Publish Operation
When an application wants to modify the presence entry associated When an application wants to modify the presence entry associated
with an endpoint, it sends a "publish" element to the service. In with an endpoint, it sends a "publish" element to the service. In
addition, the service sends a "publish" element to endpoints that addition, the service sends a "publish" element to endpoints that
skipping to change at page 21, line 9 skipping to change at page 16, line 24
When the service sends a "publish" element, the "transID" attribute When the service sends a "publish" element, the "transID" attribute
specifies the transaction-identifier associated with the subscribe specifies the transaction-identifier associated with the subscribe
operation that caused this "publish" element to be sent, and the operation that caused this "publish" element to be sent, and the
"timeStamp" attribute specifies the service's notion of the current "timeStamp" attribute specifies the service's notion of the current
date and time. No reply is sent by the receiving endpoint. date and time. No reply is sent by the receiving endpoint.
When the service receives a "publish" element, we refer to the When the service receives a "publish" element, we refer to the
"publisher" attribute of that element as the "subject", and the "publisher" attribute of that element as the "subject", and the
service performs these steps: service performs these steps:
1. If the "publisher" attribute of the "publish" element doesn't 1. If the "publisher" attribute of the "publish" element doesn't
match the "publisher" attribute of the "presence" element match the "publisher" attribute of the "presence" element
contained in the "publish" element, a "reply" element having code contained in the "publish" element, a "reply" element having code
503 is sent to the originator. 503 is sent to the originator.
2. If the subject is outside of this administrative domain, a 2. If the subject is outside of this administrative domain, a "reply"
"reply" element having code 553 is sent to the originator. element having code 553 is sent to the originator.
3. If the subject does not refer to a valid endpoint, a "reply" 3. If the subject does not refer to a valid endpoint, a "reply"
element having code 550 is sent to the originator. element having code 550 is sent to the originator.
4. If the subject's access entry does not contain a 4. If the subject's access entry does not contain a
"presence:publish" token for the originator, a "reply" element "presence:publish" token for the originator, a "reply" element
having code 537 is sent to the originator. having code 537 is sent to the originator.
5. If the "lastUpdate" attribute of the "publish" element is not 5. If the "lastUpdate" attribute of the "publish" element is not
semantically identical to the "lastUpdate" attribute of the semantically identical to the "lastUpdate" attribute of the
subject's presence entry, a "reply" element having code 555 is subject's presence entry, a "reply" element having code 555 is
sent to the originator. (This allows a simple mechanism for sent to the originator. (This allows a simple mechanism for
atomic updates.) atomic updates.)
6. Otherwise: 6. Otherwise:
1. The subject's presence entry is updated from the "publish" 1. The subject's presence entry is updated from the "publish"
element. element.
2. The "lastUpdate" attribute of the presence entry is set to 2. The "lastUpdate" attribute of the presence entry is set to the
the service's notion of the current date and time. service's notion of the current date and time.
3. A "reply" element having code 250 is sent to the originator. 3. A "reply" element having code 250 is sent to the originator.
When sending the "reply" element, the "transID" attribute is When sending the "reply" element, the "transID" attribute is
identical to the value found in the "publish" element sent by the identical to the value found in the "publish" element sent by the
originator. originator.
4.5 The Terminate Operation 4.5 The Terminate Operation
When an application no longer wishes to subscribe to presence When an application no longer wishes to subscribe to presence
information or to watch endpoints that are subscribed to receive information or to watch endpoints that are subscribed to receive
presence information, it sends a "terminate" element to the service; presence information, it sends a "terminate" element to the service;
skipping to change at page 22, line 22 skipping to change at page 17, line 28
application. application.
The "terminate" element contains only a "transID" attribute that The "terminate" element contains only a "transID" attribute that
specifies the transaction-identifier associated an in-progress specifies the transaction-identifier associated an in-progress
subscribe or watch operation. Section 9.1 of [1] defines the syntax subscribe or watch operation. Section 9.1 of [1] defines the syntax
for the "terminate" element. for the "terminate" element.
When the service receives a "terminate" element, it performs these When the service receives a "terminate" element, it performs these
steps: steps:
1. If the transaction-identifier does not refer to a previous 1. If the transaction-identifier does not refer to a previous
subscribe or watch operation for the originator, an "error" subscribe or watch operation for the originator, an "error"
element having code 550 is returned. element having code 550 is returned.
2. Otherwise, the previous subscribe or watch operation for the 2. Otherwise, the previous subscribe or watch operation for the
originator is terminated, and a "reply" element having code 250 originator is terminated, and a "reply" element having code 250 is
is sent to the originator. sent to the originator.
Note that following a terminate operation, the originator may receive Note that following a terminate operation, the originator may receive
further presence or watcher updates. Although the service will send further presence or watcher updates. Although the service will send
no further updates after processing a terminate operation and sending no further updates after processing a terminate operation and sending
the reply operation, earlier updates may be in transit. the reply operation, earlier updates may be in transit.
4.6 The Notify Operation 4.6 The Notify Operation
The service sends a "notify" element to endpoints that are watching The service sends a "notify" element to endpoints that are watching
other endpoints subscribed to presence information (c.f., Section other endpoints subscribed to presence information (c.f., Section
skipping to change at page 28, line 11 skipping to change at page 21, line 11
<!ELEMENT capability (#PCDATA)> <!ELEMENT capability (#PCDATA)>
<!ATTLIST capability <!ATTLIST capability
baseline %URI #REQUIRED> baseline %URI #REQUIRED>
7. Security Considerations 7. Security Considerations
Consult [1]'s Section 11 for a discussion of security issues. Consult [1]'s Section 11 for a discussion of security issues.
In addition, timestamps issued by the the presence service may In addition, timestamps issued by the the presence service may
disclose location information. If this information is considered disclose location information. If this information is considered
sensistive, the special timezone value "-00:00" may be used. sensitive, the special timezone value "-00:00" may be used (after
converting the local time accordingly).
References References
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", draft-ietf-apex-core-06 (work in progress), January 2002. Core", RFC 3340, July 2002.
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001. 3080, March 2001.
[3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service", [3] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
draft-ietf-apex-access-08 (work in progress), January 2002. (APEX) Access Service", RFC 3341, July 2002.
Acknowledgements
The authors gratefully acknowledge the contributions of: Neil Cook,
Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
Authors' Addresses Authors' Addresses
Marshall T. Rose Marshall T. Rose
Dover Beach Consulting, Inc. Dover Beach Consulting, Inc.
POB 255268 POB 255268
Sacramento, CA 95865-5268 Sacramento, CA 95865-5268
US US
Phone: +1 916 483 8878 Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us EMail: mrose@dbc.mtview.ca.us
Graham Klyne Graham Klyne
MIMEsweeper Group Nine by Nine
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 118 903 8000 EMail: gk@ninebynine.org
EMail: Graham.Klyne@MIMEsweeper.com
David H. Crocker David H. Crocker
Brandenburg Consulting Brandenburg InternetWorking
675 Spruce Drive 675 Spruce Drive
Sunnyvale, CA 94086 Sunnyvale, CA 94086
US US
Phone: +1 408 246 8253 Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/ URI: http://www.brandenburg.com/
Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Neil Cook,
Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
Appendix B. Revision History
Note to RFC editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication.
B.1 Changes from draft-ietf-apex-presence-05
o Add parenthetical comment regarding correct setting of permissions
in order to update an entry.
B.2 Changes from draft-ietf-apex-presence-04
o Corrected three typos.
o Removed the reference to "xml.resource.org" in the DTD.
o Changed the syntax of the "baseline" attribute to URI, to allow
for distributed registration of possible values.
o Added timezone warning to the "Security Considerations" section.
B.3 Changes from draft-ietf-apex-presence-03
o The new date-time format referenced in the core document is now
used for the timestamp data-type.
o The relationship of the "reply" element to the core document was
clarified.
B.4 Changes from draft-ietf-apex-presence-02
o Re-organization previous version for consistency.
B.5 Changes from draft-ietf-apex-presence-01
o Grammar error in Security Considerations.
o Extraneous sentence in Step 6.2 of Section 4.3.
o Notifications are now sent when a subscription is terminated.
B.6 Changes from draft-ietf-apex-presence-00
o Change "subaddress" convention from RFC 2846 to APEX's custom
ABNF.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 49 change blocks. 
217 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/