Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3343

The Application Exchange (APEX) Presence Service

Pages: 23
Historic

Top   ToC   RFC3343 - Page 1
Network Working Group                                            M. Rose
Request for Comments: 3343                  Dover Beach Consulting, Inc.
Category: Experimental                                          G. Klyne
                                                            Nine by Nine
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                              April 2003


            The Application Exchange (APEX) Presence Service

Status of this Memo

   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 Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use and Management of Presence Information . . . . . . . . . . 3 2.1 Update of Presence Information . . . . . . . . . . . . . . . . 3 2.2 Distribution of Presence Information . . . . . . . . . . . . . 4 2.3 Distribution of Watcher Information . . . . . . . . . . . . . 7 3. Format of Presence Entries . . . . . . . . . . . . . . . . . . 10 4. The Presence Service . . . . . . . . . . . . . . . . . . . . . 11 4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 12 4.2 The Subscribe Operation . . . . . . . . . . . . . . . . . . . 13 4.3 The Watch Operation . . . . . . . . . . . . . . . . . . . . . 14 4.4 The Publish Operation . . . . . . . . . . . . . . . . . . . . 15 4.5 The Terminate Operation . . . . . . . . . . . . . . . . . . . 17 4.6 The Notify Operation . . . . . . . . . . . . . . . . . . . . . 17 4.7 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 18 5. Registration: The Presence Service . . . . . . . . . . . . . . 18 6. The Presence Service DTD . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Top   ToC   RFC3343 - Page 2
       Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23

1. Introduction

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.
Top   ToC   RFC3343 - Page 3

2. Use and Management of Presence Information

Management of presence information falls into three categories: o applications may update the presence information associated with an endpoint; o applications may subscribe to receive presence information associated with an endpoint; and, o applications may find out who is subscribed to receive presence information. Each is now described in turn.

2.1 Update of Presence Information

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 />
Top   ToC   RFC3343 - Page 4
   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 />

2.2 Distribution of Presence Information

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 />
Top   ToC   RFC3343 - Page 5
   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.)
Top   ToC   RFC3343 - Page 6
   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 />
Top   ToC   RFC3343 - Page 7

2.3 Distribution of Watcher Information

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 />
Top   ToC   RFC3343 - Page 8
   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.
Top   ToC   RFC3343 - Page 9
   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 />
Top   ToC   RFC3343 - Page 10

3. Format of Presence Entries

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: o the "publisher" attribute specifies the endpoint associated with the presence entry; o the "lastUpdate" attribute specifies the date and time that the service last updated the presence entry; o the "publisherInfo" attribute specifies arbitrary information about the publisher (using a URI); and, o each "tuple" element specifies information about an entity associated with the endpoint. Each "tuple" element has a "destination" attribute, an "availableUntil" attribute, a "tupleInfo" attribute, and contains zero or more "capability" elements: o the "destination" attribute identifies the entity as a URI (e.g., "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com"); o the "availableUntil" attribute specifies the latest date and time that the entity is capable of receiving messages; o the "tupleInfo" attribute specifies arbitrary information about the entity (using a URI); and, o each "capability" element contains a specification as to the kinds of content the entity is capable of receiving. Each "capability" element contains arbitrary character data formatted according to the standard indicated in the element's "baseline" attribute.
Top   ToC   RFC3343 - Page 11

4. The Presence Service

Section 5 contains the APEX service registration for the presence service: o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=presence". o Section 6 defines the syntax of the operations exchanged with the service. o A consumer of the service initiates communications by sending data containing the subscribe, watch, or publish operation. o In addition to replying to these operations, the service may also initiate communications by sending data containing the terminate, publish, or notify operations. 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.
Top   ToC   RFC3343 - Page 12

4.1 Use of XML and MIME

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
Top   ToC   RFC3343 - Page 13

4.2 The Subscribe Operation

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: o the "publisher" attribute specifies the endpoint associated with the presence entry; o the "transID" attribute specifies the transaction-identifier associated with this operation; and, o the "duration" attribute specifies the maximum number of seconds for which the originator is interested in receiving updated presence information. 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: 1. If the subject is outside of this administrative domain, a "reply" element having code 553 is sent to the originator. 2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator. 3. If the subject's access entry does not contain a "presence:subscribe" token for the originator, a "reply" element having code 537 is sent to the originator. 4. If the originator already has an in-progress subscribe operation for the subject, then the previous subscribe operation is silently terminated, and processing continues. 5. If the "transID" attribute refers to an in-progress subscribe or watch operation for the originator, a "reply" element having code 555 is sent to the originator. 6. Otherwise: 1. A "publish" element, corresponding to the subject's presence entry, is immediately sent to the originator.
Top   ToC   RFC3343 - Page 14
      2. For each endpoint currently watching subscribers to the
         subject's presence information, a "notify" element is
         immediately as sent (c.f., Step 6.3 of Section 4.6).

      3. For up to the amount of time indicated by the "duration"
         attribute of the "subscribe" element, if the subject's presence
         entry changes, an updated "presence" element is sent to the
         originator using the publish operation (Section 4.4).  Finally,
         when the amount of time indicated by the "duration" attribute
         expires, a terminate operation (Section 4.5) is sent to the
         originator.

      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.

4.3 The Watch Operation

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: o the "publisher" attribute specifies the endpoint associated with the presence entry; o the "transID" attribute specifies the transaction-identifier associated with this operation; and, o the "duration" attribute specifies the maximum number of seconds for which the originator is interested in watching subscribers. 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: 1. If the subject is outside of this administrative domain, a "reply" element having code 553 is sent to the originator. 2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator.
Top   ToC   RFC3343 - Page 15
   3. If the subject's access entry does not contain a "presence:watch"
      token for the originator, a "reply" element having code 537 is
      sent to the originator.

   4. If the originator already has an in-progress watch operation for
      the subject, then the previous watch operation is silently
      terminated, and processing continues.

   5. If the "transID" attribute refers to an in-progress subscribe or
      watch operation for the originator, a "reply" element having code
      555 is sent to the originator.

   6. Otherwise:

      1. A "reply" element having code 250 is sent to the originator.

      2. For each endpoint currently subscribing to the subject's
         presence information, a "notify" element is immediately sent to
         the originator (c.f., Section 4.6).

      3. For up to the amount of time indicated by the "duration"
         attribute of the "watch" element, whenever a subscribe
         operation succeeds or a subscription is terminated, a "notify"
         element is sent to the originator.  Finally, when the amount of
         time indicated by the "duration" attribute expires, a terminate
         operation (Section 4.5) is sent to the originator.

      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.

4.4 The Publish Operation

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: o the "publisher" attribute specifies the endpoint to be associated with the presence entry;
Top   ToC   RFC3343 - Page 16
   o  the "transID" attribute specifies the transaction-identifier
      associated with this operation;

   o  the "timeStamp" attribute specifies the application's notion of
      the current date and time; and,

   o  the "presence" element contains the desired presence entry for the
      endpoint.

   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:

   1. If the "publisher" attribute of the "publish" element doesn't
      match the "publisher" attribute of the "presence" element
      contained in the "publish" element, a "reply" element having code
      503 is sent to the originator.

   2. If the subject is outside of this administrative domain, a "reply"
      element having code 553 is sent to the originator.

   3. If the subject does not refer to a valid endpoint, a "reply"
      element having code 550 is sent to the originator.

   4. If the subject's access entry does not contain a
      "presence:publish" token for the originator, a "reply" element
      having code 537 is sent to the originator.

   5. If the "lastUpdate" attribute of the "publish" element is not
      semantically identical to the "lastUpdate" attribute of the
      subject's presence entry, a "reply" element having code 555 is
      sent to the originator.  (This allows a simple mechanism for
      atomic updates.)

   6. Otherwise:

      1. The subject's presence entry is updated from the "publish"
         element.

      2. The "lastUpdate" attribute of the presence entry is set to the
         service's notion of the current date and time.
Top   ToC   RFC3343 - Page 17
      3. A "reply" element having code 250 is sent to the originator.

   When sending the "reply" element, the "transID" attribute is
   identical to the value found in the "publish" element sent by the
   originator.

4.5 The Terminate Operation

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: 1. If the transaction-identifier does not refer to a previous subscribe or watch operation for the originator, an "error" element having code 550 is returned. 2. Otherwise, the previous subscribe or watch operation for the originator is terminated, and a "reply" element having code 250 is sent to the originator. 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.

4.6 The Notify Operation

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: o the "subscriber" attribute specifies the endpoint that is subscribed to presence information; and,
Top   ToC   RFC3343 - Page 18
   o  the "transID" attribute specifies the transaction-identifier
      associated with the watch operation that caused this "notify"
      element to be sent;

   o  the "action" attribute specifies whether a subscription or its
      termination has occurred; and,

   o  if a subscription is being reported, the "duration" attribute
      specifies the requested duration of the subscription.

   No reply is sent by the receiving endpoint.

4.7 The Reply Operation

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.

5. Registration: The Presence Service

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

6. The Presence Service DTD

<!-- 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;
Top   ToC   RFC3343 - Page 19
   <!--
     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>
Top   ToC   RFC3343 - Page 20
   <!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>
Top   ToC   RFC3343 - Page 21

7. Security Considerations

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).

References

[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.
Top   ToC   RFC3343 - Page 22

Acknowledgements

The authors gratefully acknowledge the contributions of: Neil Cook, Eric Dixon, Darren New, Scott Pead, and Bob Wyman.

Authors' Addresses

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/
Top   ToC   RFC3343 - Page 23
Full Copyright Statement

   Copyright (C) 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.