RFC 3343

The Application Exchange (APEX) Presence Service

📅 published May 2003, from ietf

📮 RFC 3343: The Application Exchange (APEX) Presence Service 💖

okay so, this RFC is literally about how presence info (is someone online, are they available, all that) gets managed on the APEX relaying mesh 🦋 it's an Experimental doc, which means it's not an Internet standard, the authors are asking for feedback 🧚

the authors are M. Rose from Dover Beach Consulting, Inc., G. Klyne from Nine by Nine, and D. Crocker from Brandenburg InternetWorking 🎀 it was published in April 2003 by the Network Working Group ✨ the title block doesn't list anything it obsoletes or updates, so there's nothing to flag there 👀

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, so bestie, go give feedback 🫶 distribution of this memo is unlimited 🌸

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. it's giving clean and simple 🍓

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
       Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23

1. Introduction 🦋

okay so this memo describes a presence service that's built on top of the APEX [1] "relaying mesh" 🕸️ the APEX presence service is used to manage presence information for APEX endpoints, and yes, that's the whole pitch 💅

APEX, at its core, gives you a best-effort datagram service 📦 within an administrative domain, all relays must be able to handle messages for any endpoint within that domain. no exceptions, bestie 🚫 APEX services are logically defined as endpoints, but since they have such ubiquitous semantics, they don't necessarily need to be tied to a single physical endpoint 🧚 so they may be provisioned co-resident with each relay within an administrative domain, even though they're logically provided on top of the relaying mesh, i.e.,

      +----------+     +----------+    +----------+    +---------+
      |   APEX   |     |   APEX   |    |   APEX   |    |         |
      |  access  |     | presence |    |  report  |    |   ...   |
      | service  |     |  service |    | service  |    |         |
      +----------+     +----------+    +----------+    +---------+
           |                |               |               |
           |                |               |               |
   +----------------------------------------------------------------+
   |                                                                |
   |                            APEX core                           |
   |                                                                |
   +----------------------------------------------------------------+

that's the vibe: applications talk to an APEX service by exchanging data with a "well-known endpoint" (WKE) 🌈

APEX applications talk to the presence service by exchanging data with the well-known endpoint "apex=presence" in the matching administrative domain, e.g., "apex=presence@example.com" is the endpoint for the presence service in the "example.com" administrative domain 💜

and note that within a single administrative domain, the presence service uses the APEX access [3] service to figure out whether an originator is allowed to view or manage presence information 🔐 the gatekeeping is literally built in 😭

2. Use and Management of Presence Information 💌

management of presence information falls into three categories, and it's giving organized 🎀

  • applications may update the presence information associated with an endpoint;
  • applications may subscribe to receive presence information associated with an endpoint; and,
  • applications may find out who is subscribed to receive presence information.

we'll go through each one now 🫶

2.1 Update of Presence Information 📤

when an application wants to change the presence information attached to an endpoint, it sends a publish operation to the service 💅 here's the vibe:

    +-------+                  +-------+
    |       | -- 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 />

this example uses the "subaddress" convention from Section 2.2 of [1] (e.g., "fred/appl=im") to mark multiplexing of traffic for a particular endpoint 🧠 and of course, popular apps can have their own URI method assigned to them (e.g., "im:fred@example.com") 📱

the service immediately responds with a reply operation carrying 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 />

the reply comes back instantly with the matching transID, no waiting around 🌈✨

2.2. Distribution of Presence Information 💖

okay so when an app wants to (periodically) get the presence info for an endpoint, it sends a subscribe operation to the service, like this 🫶

    +-------+                  +-------+
    |       | -- 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 instantly replies with a publish operation that has the same transaction-identifier, and it's giving very "I got you" energy ✨

                               +-------+                  +-------+
                               |       | <------- 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 />

then, for up to the specified "duration", the service keeps sending new publish operations whenever the endpoint's presence info changes 🌸 if the "duration" is zero-valued, that's just a one time poll of the presence info 🙈 otherwise, when the "duration" ends, a terminate operation gets sent.

ngl this next part is important 💅 Step 5 of Section 4.4 requires that the "lastUpdate" attribute of a presence entry be supplied in order to update that entry. so applications must successfully retrieve a presence entry before they try to update it. this is usually done by subscribing with a zero-valued duration. (and fr fr, administrators should make sure that any app allowed to update a presence entry is also allowed to retrieve that entry 🔥)

either the subscriber or the service can cancel a subscription by sending a terminate operation, like so 👑

    +-------+                  +-------+
    |       | -- 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 />

2.3. Distribution of Watcher Information 🧚

okay now flip it! when an app wants to (periodically) hear about endpoints that are subscribed to receive presence info, it sends a watch operation to the service 👀

    +-------+                  +-------+
    |       | -- 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 replies with a reply operation that has the same transaction-identifier 💜

                               +-------+                  +-------+
                               |       | <------- 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 with the same transaction-identifier, like this 🍓

                               +-------+                  +-------+
                               |       | <------- 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 />

then, for up to the specified "duration", the service sends new notify operations whenever an app subscribes successfully or a subscription gets terminated 🌈 if the "duration" is zero-valued, it's a one time poll of the watcher info ✨ otherwise, when the "duration" ends, a terminate operation is sent.

either the watcher or the service can cancel the request by sending a terminate operation 💀

    +-------+                  +-------+
    |       | -- 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 />

3. Format of Presence Entries 🦋

okay so each administrative domain is responsible for keeping a "presence entry" for each of its endpoints 🎀 (and yes, that's true whether or not those endpoints are currently hooked up 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 one or more "tuple" elements:

  • the publisher attribute specifies the endpoint the presence entry belongs to;
  • the lastUpdate attribute specifies the date and time that the service last updated the presence entry;
  • the publisherInfo attribute specifies arbitrary information about the publisher (using a URI); and,
  • 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 zero or more "capability" elements 🧁

  • the destination attribute identifies the entity as a URI (e.g., apex:fred/appl=im@example.com or mailto:fred@flintstone.com);
  • the availableUntil attribute specifies the latest date and time that the entity is capable of receiving messages;
  • the tupleInfo attribute specifies arbitrary information about the entity (using a URI); and,
  • each capability element contains a specification as to the kinds of content the entity is capable of receiving.

last one! 🫶 each "capability" element contains arbitrary character data, formatted according to the standard indicated in the element's "baseline" attribute ✨

4. The Presence Service ✨

okay bestie, this is the main event 💅 Section 5 has the APEX service registration for the presence service:

  • Within an administrative domain, the service is addressed using the well-known endpoint of apex=presence.
  • Section 6 defines the syntax of the operations exchanged with the service.
  • A consumer of the service initiates communications by sending data containing the subscribe, watch, or publish operation.
  • 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. 🦋

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

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:

  • the publisher attribute specifies the endpoint associated with the presence entry;
  • the transID attribute specifies the transaction-identifier associated with this operation; and,
  • 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.
    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:

  • the publisher attribute specifies the endpoint associated with the presence entry;
  • the transID attribute specifies the transaction-identifier associated with this operation; and,
  • 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.
  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:

  • the publisher attribute specifies the endpoint to be associated with the presence entry;
  • the transID attribute specifies the transaction-identifier associated with this operation;
  • the timeStamp attribute specifies the application's notion of the current date and time; and,
  • 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.
    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 ✋

okay so when an application is done subscribing to presence info (or done watching endpoints that are subscribed to it), it sends a "terminate" element to the service 💅 and it works the other way too: when the service stops thinking an application is subscribing or watching, it sends that application a "terminate" element. no cap, it's a two-way breakup text 💀

The terminate element has one attribute only: transID. That's how it points at the transaction-identifier of the in-progress subscribe or watch operation it's ending. The syntax lives in Section 9.1 of [1] if you want the full deets 🤓

When the service gets a terminate element, it runs through these steps:

  1. If the transaction-identifier doesn't match a previous subscribe or watch operation for the originator, the service sends back an error element with code 550. 🙅‍♀️
  2. Otherwise, the previous subscribe or watch operation for the originator gets terminated, and the service sends back a reply element with code 250. ✨

Now the lowkey tricky part 👀 After a terminate, the originator can still get presence or watcher updates. The service stops sending new updates once it has processed the terminate and sent the reply, but updates that were already sent earlier might still be floating around the network 🦋 so don't panic if one slides in late!

4.6 The Notify Operation 📣

The service sends a "notify" element to endpoints that are watching other endpoints that are subscribed to presence information (c.f., Section 4.3). It's giving "hey, heads up, something changed" 🫶

The notify element has four attributes: subscriber, transID, duration, and action. It has no content. Here's what each one does:

  • subscriber says which endpoint is the one subscribed to presence information. 🎀
  • transID says which transaction-identifier goes with the watch operation that caused this notify element to be sent. 🧚
  • action says whether a subscription or its termination has happened. 🔥
  • duration only matters when a subscription is being reported: it gives the requested duration of that subscription. ⏳

The receiving endpoint doesn't send a reply. It just takes the news and vibes 💜

4.7 The Reply Operation 💬

while the service is processing operations, it might respond with a "reply" element. For the definition and an explanation of the reply element's syntax, check out Sections 10.2 and 6.1.2 of [1], respectively 📚 (literally the best homework I've ever been assigned 😭)

5. Registration: The Presence Service 📝

Here's the registration info, verbatim, because the registry is not the place to get creative 🌸

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 🧩

Okay, the DTD. This is the schema for the APEX presence service, dated 2001-05-08. It's the blueprint, so every character matters 💖 (no edits, bestie, I promise)

<!--
  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>

7. Security Considerations 🔐

Big safety energy here 🚨 For a discussion of security issues, check out Section 11 of [1].

But also, the presence service's timestamps can reveal location info 📍 Yikes. If that info is sensitive, you can use the special timezone value "-00:00" (after converting the local time accordingly) 🙈 It's like putting your location on airplane mode.

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

Acknowledgements 🫶

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

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/

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

📦 where this page comes from