idnits 2.17.1
draft-ietf-apex-presence-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 822 has weird spacing: '...itiates ser...'
== Line 839 has weird spacing: '...bscribe for...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (August 14, 2001) is 8291 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-06) exists of
draft-ietf-apex-core-05
** Downref: Normative reference to an Historic draft: draft-ietf-apex-core
(ref. '1')
== Outdated reference: A later version (-08) exists of
draft-ietf-apex-access-07
** Downref: Normative reference to an Historic draft:
draft-ietf-apex-access (ref. '3')
Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Rose
3 Internet-Draft Invisible Worlds, Inc.
4 Expires: February 12, 2002 G. Klyne
5 Baltimore Technologies
6 D. Crocker
7 Brandenburg Consulting
8 August 14, 2001
10 The APEX Presence Service
11 draft-ietf-apex-presence-05
13 Status of this Memo
15 This document is an Internet-Draft and is in full conformance with
16 all provisions of Section 10 of RFC2026.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on February 12, 2002.
36 Copyright Notice
38 Copyright (C) The Internet Society (2001). All Rights Reserved.
40 Abstract
42 This memo describes the APEX presence service, addressed as the well-
43 known endpoint "apex=presence". The presence service is used to
44 manage presence information for APEX endpoints.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 2. Management of Presence Information . . . . . . . . . . . . . . 4
50 2.1 Update of Presence Information . . . . . . . . . . . . . . . . 5
51 2.2 Distribution of Presence Information . . . . . . . . . . . . . 7
52 2.3 Distribution of Watcher Information . . . . . . . . . . . . . 10
53 3. Format of Presence Entries . . . . . . . . . . . . . . . . . . 13
54 4. The Presence Service . . . . . . . . . . . . . . . . . . . . . 14
55 4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 15
56 4.2 The Subscribe Operation . . . . . . . . . . . . . . . . . . . 16
57 4.3 The Watch Operation . . . . . . . . . . . . . . . . . . . . . 18
58 4.4 The Publish Operation . . . . . . . . . . . . . . . . . . . . 20
59 4.5 The Terminate Operation . . . . . . . . . . . . . . . . . . . 22
60 4.6 The Notify Operation . . . . . . . . . . . . . . . . . . . . . 23
61 4.7 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 23
62 5. Registration: The Presence Service . . . . . . . . . . . . . . 24
63 6. The Presence Service DTD . . . . . . . . . . . . . . . . . . . 25
64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
65 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
67 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
68 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 31
69 B.1 Changes from draft-ietf-apex-presence-04 . . . . . . . . . . . 31
70 B.2 Changes from draft-ietf-apex-presence-03 . . . . . . . . . . . 31
71 B.3 Changes from draft-ietf-apex-presence-02 . . . . . . . . . . . 31
72 B.4 Changes from draft-ietf-apex-presence-01 . . . . . . . . . . . 31
73 B.5 Changes from draft-ietf-apex-presence-00 . . . . . . . . . . . 31
74 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32
76 1. Introduction
78 This memo describes a presence service that is built upon the APEX
79 [1] "relaying mesh". The APEX presence service is used to manage
80 presence information for APEX endpoints.
82 APEX, at its core, provides a best-effort datagram service. Within
83 an administrative domain, all relays must be able to handle messages
84 for any endpoint within that domain. APEX services are logically
85 defined as endpoints but given their ubiquitous semantics they do not
86 necessarily need to be associated with a single physical endpoint.
87 As such, they may be provisioned co-resident with each relay within
88 an administrative domain, even though they are logically provided on
89 top of the relaying mesh, i.e.,
91 +----------+ +----------+ +----------+ +---------+
92 | APEX | | APEX | | APEX | | |
93 | access | | presence | | report | | ... |
94 | service | | service | | service | | |
95 +----------+ +----------+ +----------+ +---------+
96 | | | |
97 | | | |
98 +----------------------------------------------------------------+
99 | |
100 | APEX core |
101 | |
102 +----------------------------------------------------------------+
104 That is, applications communicate with an APEX service by exchanging
105 data with a "well-known endpoint" (WKE).
107 APEX applications communicate with the presence service by exchanging
108 data with the well-known endpoint "apex=presence" in the
109 corresponding administrative domain, e.g.,
110 "apex=presence@example.com" is the endpoint associated with the
111 presence service in the "example.com" administrative domain.
113 Note that within a single administrative domain, the presence service
114 makes use of the APEX access [3] service in order to determine if an
115 originator is allowed to view or manage presence information.
117 2. Management of Presence Information
119 Management of presence information falls into three categories:
121 o applications may update the presence information associated with
122 an endpoint;
124 o applications may subscribe to receive presence information
125 associated with an endpoint; and,
127 o applications may find out who is subscribed to receive presence
128 information.
130 Each is now described in turn.
132 2.1 Update of Presence Information
134 When an application wants to modify the presence information
135 associated with an endpoint, it sends a publish operation to the
136 service, e.g.,
138 +-------+ +-------+
139 | | -- data -------> | |
140 | appl. | | relay |
141 | | <--------- ok -- | |
142 +-------+ +-------+
144 C:
145
146
147
148
150
153
156
158
159
160
161
162 S:
164 Note that this example uses the "subaddress" convention specified in
165 Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of
166 traffic for a particular endpoint. Of course, popular applications
167 may have their own URI method assigned to them (e.g.,
168 "im:fred@example.com").
170 The service immediately responds with a reply operation containing
171 the same transaction-identifier, e.g.,
173 +-------+ +-------+
174 | | <------- data -- | |
175 | relay | | pres. |
176 | | -- ok ---------> | svc. |
177 +-------+ +-------+
179 C:
180
181
182
183
184
185
186 S:
188 2.2 Distribution of Presence Information
190 When an application wants to (periodically) receive the presence
191 information associated with an endpoint, it sends a subscribe
192 operation to the service, e.g.,
194 +-------+ +-------+
195 | | -- data -------> | |
196 | appl. | | relay |
197 | | <--------- ok -- | |
198 +-------+ +-------+
200 C:
201
202
203
204
206
207
208 S:
210 The service immediately responds with a publish operation containing
211 the same transaction-identifier, e.g.,
213 +-------+ +-------+
214 | | <------- data -- | |
215 | relay | | pres. |
216 | | -- ok ---------> | svc. |
217 +-------+ +-------+
219 C:
220
221
222
223
225
228
231
232
233
234
235 S:
237 Subsequently, for up to the specified "duration", the service sends
238 new publish operations whenever there are any changes to the
239 endpoint's presence information. If the "duration" is zero-valued, a
240 one time poll of the presence information is achieved; otherwise, at
241 the end of the "duration", a terminate operation is sent.
243 Note that Step 5 of Section 4.4 requires that the "lastUpdate"
244 attribute of a presence entry be supplied in order to update that
245 entry; accordingly, applications must successfully retrieve an
246 publish entry prior to trying to update that entry. This is usually
247 accomplished by subscribing with a zero-valued duration.
249 Either the subscriber or the service may cancel a subscription by
250 sending a terminate operation, e.g.,
252 +-------+ +-------+
253 | | -- data -------> | |
254 | appl. | | relay |
255 | | <--------- ok -- | |
256 +-------+ +-------+
258 C:
259
260
261
262
263
264
265 S:
267 +-------+ +-------+
268 | | <------- data -- | |
269 | relay | | pres. |
270 | | -- ok ---------> | svc. |
271 +-------+ +-------+
273 C:
274
275
276
277
278
279
280 S:
282 or
283 +-------+ +-------+
284 | | <------- data -- | |
285 | relay | | pres. |
286 | | -- ok ---------> | svc. |
287 +-------+ +-------+
289 C:
290
291
292
293
294
295
296 S:
298 2.3 Distribution of Watcher Information
300 When an application wants to (periodically) receive notices about
301 endpoints that are subscribed to receive presence information, it
302 sends a watch operation to the service, e.g.,
304 +-------+ +-------+
305 | | -- data -------> | |
306 | appl. | | relay |
307 | | <--------- ok -- | |
308 +-------+ +-------+
310 C:
311
312
313
314
316
317
318 S:
320 The service immediately responds with a reply operation containing
321 the same transaction-identifier, e.g.,
323 +-------+ +-------+
324 | | <------- data -- | |
325 | relay | | pres. |
326 | | -- ok ---------> | svc. |
327 +-------+ +-------+
329 C:
330
331
332
334
335
336 S:
338 For each current subscriber, the service immediately sends a notify
339 operation containing the same transaction-identifier, e.g.,
341 +-------+ +-------+
342 | | <------- data -- | |
343 | relay | | pres. |
344 | | -- ok ---------> | svc. |
345 +-------+ +-------+
347 C:
348
349
350
351
353
354
355 S:
357 Subsequently, for up to the specified "duration", the service sends
358 new notify operations whenever an application subscribes successfully
359 or a subscription is terminated. If the "duration" is zero-valued, a
360 one time poll of the watcher information is achieved; otherwise, at
361 the end of the "duration", a terminate operation is sent.
363 Either the watcher or the service may cancel the request by sending a
364 terminate operation, e.g.,
366 +-------+ +-------+
367 | | -- data -------> | |
368 | appl. | | relay |
369 | | <--------- ok -- | |
370 +-------+ +-------+
372 C:
373
374
375
376
377
378
379 S:
381 +-------+ +-------+
382 | | <------- data -- | |
383 | relay | | pres. |
384 | | -- ok ---------> | svc. |
385 +-------+ +-------+
387 C:
388
389
390
391
392
393
394 S:
396 or
397 +-------+ +-------+
398 | | <------- data -- | |
399 | relay | | pres. |
400 | | -- ok ---------> | svc. |
401 +-------+ +-------+
403 C:
404
405
406
407
408
409
410 S:
412 3. Format of Presence Entries
414 Each administrative domain is responsible for maintaining a "presence
415 entry" for each of its endpoints (regardless of whether those
416 endpoints are currently attached to the relaying mesh).
418 Section 6 defines the syntax for presence entries. Each presence
419 entry has a "publisher" attribute, a "lastUpdate" attribute, a
420 "publisherInfo" attribute, and contains one or more "tuple" elements:
422 o the "publisher" attribute specifies the endpoint associated with
423 the presence entry;
425 o the "lastUpdate" attribute specifies the date and time that the
426 service last updated the presence entry;
428 o the "publisherInfo" attribute specifies arbitrary information
429 about the publisher (using a URI); and,
431 o each "tuple" element specifies information about an entity
432 associated with the endpoint.
434 Each "tuple" element has a "destination" attribute, an
435 "availableUntil" attribute, a "tupleInfo" attribute, and contains
436 zero or more "capability" elements:
438 o the "destination" attribute identifies the entity as a URI (e.g.,
439 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
441 o the "availableUntil" attribute specifies the latest date and time
442 that the entity is capable of receiving messages;
444 o the "tupleInfo" attribute specifies arbitrary information about
445 the entity (using a URI); and,
447 o each "capability" element contains a specification as to the kinds
448 of content the entity is capable of receiving.
450 Each "capability" element contains arbitrary character data formatted
451 according to the standard indicated in the element's "baseline"
452 attribute.
454 4. The Presence Service
456 Section 5 contains the APEX service registration for the presence
457 service:
459 o Within an administrative domain, the service is addressed using
460 the well-known endpoint of "apex=presence".
462 o Section 6 defines the syntax of the operations exchanged with the
463 service.
465 o A consumer of the service initiates communications by sending data
466 containing the subscribe, watch, or publish operation.
468 o In addition to replying to these operations, the service may also
469 initiate communications by sending data containing the terminate,
470 publish, or notify operations.
472 An implementation of the service must maintain information about both
473 presence entries and in-progress operations in persistent storage.
475 Consult Section 6.1.1 of [1] for a discussion on the properties of
476 long-lived transaction-identifiers.
478 4.1 Use of XML and MIME
480 Section 4.1 of [1] describes how arbitrary MIME content is exchanged
481 as a BEEP [2] payload. For example, to transmit:
483
484
485
486
488 where "..." refers to:
490 then the corresponding BEEP message might look like this:
492 C: MSG 1 1 . 42 1234
493 C: Content-Type: multipart/related; boundary="boundary";
494 C: start="<1@example.com>";
495 C: type="application/beep+xml"
496 C:
497 C: --boundary
498 C: Content-Type: application/beep+xml
499 C: Content-ID: <1@example.com>
500 C:
501 C:
502 C:
503 C:
504 C:
505 C: --boundary
506 C: Content-Type: application/beep+xml
507 C: Content-ID: <2@example.com>
508 C:
509 C:
510 C: --boundary--
511 C: END
513 or this:
515 C: MSG 1 1 . 42 1234
516 C: Content-Type: application/beep+xml
517 C:
518 C:
519 C:
520 C:
521 C:
522 C:
523 C:
524 C:
525 C: END
527 4.2 The Subscribe Operation
529 When an application wants to (periodically) receive the presence
530 information associated with an endpoint, it sends a "subscribe"
531 element to the service.
533 The "subscribe" element has a "publisher" attribute, a "duration"
534 attribute, a "transID" attribute, and no content:
536 o the "publisher" attribute specifies the endpoint associated with
537 the presence entry;
539 o the "transID" attribute specifies the transaction-identifier
540 associated with this operation; and,
542 o the "duration" attribute specifies the maximum number of seconds
543 for which the originator is interested in receiving updated
544 presence information.
546 When the service receives a "subscribe" element, we refer to the
547 "publisher" attribute of that element as the "subject", and the
548 service performs these steps:
550 1. If the subject is outside of this administrative domain, a
551 "reply" element having code 553 is sent to the originator.
553 2. If the subject does not refer to a valid endpoint, a "reply"
554 element having code 550 is sent to the originator.
556 3. If the subject's access entry does not contain a
557 "presence:subscribe" token for the originator, a "reply" element
558 having code 537 is sent to the originator.
560 4. If the originator already has an in-progress subscribe operation
561 for the subject, then the previous subscribe operation is
562 silently terminated, and processing continues.
564 5. If the "transID" attribute refers to an in-progress subscribe or
565 watch operation for the originator, a "reply" element having code
566 555 is sent to the originator.
568 6. Otherwise:
570 1. A "publish" element, corresponding to the subject's presence
571 entry, is immediately sent to the originator.
573 2. For each endpoint currently watching subscribers to the
574 subject's presence information, a "notify" element is
575 immediately as sent (c.f., Step 6.3 of Section 4.6).
577 3. For up to the amount of time indicated by the "duration"
578 attribute of the "subscribe" element, if the subject's
579 presence entry changes, an updated "presence" element is sent
580 to the originator using the publish operation (Section 4.4).
581 Finally, when the amount of time indicated by the "duration"
582 attribute expires, a terminate operation (Section 4.5) is
583 sent to the originator.
585 Note that if the duration is zero-valued, then the subscribe
586 operation is making a one-time poll of the presence information.
587 Accordingly, Step 6.3 above does not occur.
589 Regardless of whether a "publish" or "reply" element is sent to the
590 originator, the "transID" attribute is identical to the value found
591 in the "subscribe" element sent by the originator.
593 4.3 The Watch Operation
595 When an application wants to (periodically) receive notices about
596 endpoints that are subscribed to receive presence entry, it sends a
597 "watch" element to the service.
599 The "watch" element has a "publisher" attribute, a "duration"
600 attribute, a "transID" attribute, and no content:
602 o the "publisher" attribute specifies the endpoint associated with
603 the presence entry;
605 o the "transID" attribute specifies the transaction-identifier
606 associated with this operation; and,
608 o the "duration" attribute specifies the maximum number of seconds
609 for which the originator is interested in watching subscribers.
611 When the service receives a "watch" element, we refer to the
612 "publisher" attribute of that element as the "subject", and the
613 service performs these steps:
615 1. If the subject is outside of this administrative domain, a
616 "reply" element having code 553 is sent to the originator.
618 2. If the subject does not refer to a valid endpoint, a "reply"
619 element having code 550 is sent to the originator.
621 3. If the subject's access entry does not contain a "presence:watch"
622 token for the originator, a "reply" element having code 537 is
623 sent to the originator.
625 4. If the originator already has an in-progress watch operation for
626 the subject, then the previous watch operation is silently
627 terminated, and processing continues.
629 5. If the "transID" attribute refers to an in-progress subscribe or
630 watch operation for the originator, a "reply" element having code
631 555 is sent to the originator.
633 6. Otherwise:
635 1. A "reply" element having code 250 is sent to the originator.
637 2. For each endpoint currently subscribing to the subject's
638 presence information, a "notify" element is immediately sent
639 to the originator (c.f., Section 4.6).
641 3. For up to the amount of time indicated by the "duration"
642 attribute of the "watch" element, whenever a subscribe
643 operation succeeds or a subscription is terminated, a
644 "notify" element is sent to the originator. Finally, when
645 the amount of time indicated by the "duration" attribute
646 expires, a terminate operation (Section 4.5) is sent to the
647 originator.
649 Note that if the duration is zero-valued, then the watch
650 operation is making a one-time poll of the presence information.
651 Accordingly, Step 6.3 above does not occur.
653 Regardless of whether a "notify" or "reply" element is sent to the
654 originator, the "transID" attribute is identical to the value found
655 in the "presence" element sent by the originator.
657 4.4 The Publish Operation
659 When an application wants to modify the presence entry associated
660 with an endpoint, it sends a "publish" element to the service. In
661 addition, the service sends a "publish" element to endpoints that
662 have subscribed to see presence information (c.f., Section 4.2).
664 The "publish" element has a "publisher" attribute, a "transID"
665 attribute, a "timeStamp" attribute, and contains a "presence"
666 element:
668 o the "publisher" attribute specifies the endpoint to be associated
669 with the presence entry;
671 o the "transID" attribute specifies the transaction-identifier
672 associated with this operation;
674 o the "timeStamp" attribute specifies the application's notion of
675 the current date and time; and,
677 o the "presence" element contains the desired presence entry for the
678 endpoint.
680 When the service sends a "publish" element, the "transID" attribute
681 specifies the transaction-identifier associated with the subscribe
682 operation that caused this "publish" element to be sent, and the
683 "timeStamp" attribute specifies the service's notion of the current
684 date and time. No reply is sent by the receiving endpoint.
686 When the service receives a "publish" element, we refer to the
687 "publisher" attribute of that element as the "subject", and the
688 service performs these steps:
690 1. If the "publisher" attribute of the "publish" element doesn't
691 match the "publisher" attribute of the "presence" element
692 contained in the "publish" element, a "reply" element having code
693 503 is sent to the originator.
695 2. If the subject is outside of this administrative domain, a
696 "reply" element having code 553 is sent to the originator.
698 3. If the subject does not refer to a valid endpoint, a "reply"
699 element having code 550 is sent to the originator.
701 4. If the subject's access entry does not contain a
702 "presence:publish" token for the originator, a "reply" element
703 having code 537 is sent to the originator.
705 5. If the "lastUpdate" attribute of the "publish" element is not
706 semantically identical to the "lastUpdate" attribute of the
707 subject's presence entry, a "reply" element having code 555 is
708 sent to the originator. (This allows a simple mechanism for
709 atomic updates.)
711 6. Otherwise:
713 1. The subject's presence entry is updated from the "publish"
714 element.
716 2. The "lastUpdate" attribute of the presence entry is set to
717 the service's notion of the current date and time.
719 3. A "reply" element having code 250 is sent to the originator.
721 When sending the "reply" element, the "transID" attribute is
722 identical to the value found in the "publish" element sent by the
723 originator.
725 4.5 The Terminate Operation
727 When an application no longer wishes to subscribe to presence
728 information or to watch endpoints that are subscribed to receive
729 presence information, it sends a "terminate" element to the service;
730 similarly, when the service no longer considers an application to be
731 subscribing or watching, a "terminate" element is sent to the
732 application.
734 The "terminate" element contains only a "transID" attribute that
735 specifies the transaction-identifier associated an in-progress
736 subscribe or watch operation. Section 9.1 of [1] defines the syntax
737 for the "terminate" element.
739 When the service receives a "terminate" element, it performs these
740 steps:
742 1. If the transaction-identifier does not refer to a previous
743 subscribe or watch operation for the originator, an "error"
744 element having code 550 is returned.
746 2. Otherwise, the previous subscribe or watch operation for the
747 originator is terminated, and a "reply" element having code 250
748 is sent to the originator.
750 Note that following a terminate operation, the originator may receive
751 further presence or watcher updates. Although the service will send
752 no further updates after processing a terminate operation and sending
753 the reply operation, earlier updates may be in transit.
755 4.6 The Notify Operation
757 The service sends a "notify" element to endpoints that are watching
758 other endpoints subscribed to presence information (c.f., Section
759 4.3).
761 The "notify" element has a "subscriber" attribute, a "transID"
762 attribute, a "duration" attribute, an "action" attribute, and no
763 content:
765 o the "subscriber" attribute specifies the endpoint that is
766 subscribed to presence information; and,
768 o the "transID" attribute specifies the transaction-identifier
769 associated with the watch operation that caused this "notify"
770 element to be sent;
772 o the "action" attribute specifies whether a subscription or its
773 termination has occurred; and,
775 o if a subscription is being reported, the "duration" attribute
776 specifies the requested duration of the subscription.
778 No reply is sent by the receiving endpoint.
780 4.7 The Reply Operation
782 While processing operations, the service may respond with a "reply"
783 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for
784 the definition and an exposition of the syntax of the reply element.
786 5. Registration: The Presence Service
788 Well-Known Endpoint: apex=presence
790 Syntax of Messages Exchanged: c.f., Section 6
792 Sequence of Messages Exchanged: c.f., Section 4
794 Access Control Tokens: presence:subscribe, presence:watch,
795 presence:publish
797 Contact Information: c.f., the "Authors' Addresses" section of this
798 memo
800 6. The Presence Service DTD
802
812
813 %APEXCORE;
815
844
845
850
851
856
857
858
863
864
871
875
876
882
883
889
890
891
894 7. Security Considerations
896 Consult [1]'s Section 11 for a discussion of security issues.
898 In addition, timestamps issued by the the presence service may
899 disclose location information. If this information is considered
900 sensistive, the special timezone value "-00:00" may be used.
902 References
904 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
905 Core", draft-ietf-apex-core-05 (work in progress), August 2001.
907 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
908 3080, March 2001.
910 [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service",
911 draft-ietf-apex-access-07 (work in progress), August 2001.
913 Authors' Addresses
915 Marshall T. Rose
916 Invisible Worlds, Inc.
917 131 Stony Circle
918 Suite 500
919 Santa Rosa, CA 95401
920 US
922 Phone: +1 707 578 2350
923 EMail: mrose@invisible.net
924 URI: http://invisible.net/
926 Graham Klyne
927 Baltimore Technologies
928 1310 Waterside
929 Arlington Business Park
930 Theale, Reading RG7 4SA
931 UK
933 Phone: +44 118 903 8000
934 EMail: gk@acm.org
936 David H. Crocker
937 Brandenburg Consulting
938 675 Spruce Drive
939 Sunnyvale, CA 94086
940 US
942 Phone: +1 408 246 8253
943 EMail: dcrocker@brandenburg.com
944 URI: http://www.brandenburg.com/
946 Appendix A. Acknowledgements
948 The authors gratefully acknowledge the contributions of: Neil Cook,
949 Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
951 Appendix B. Revision History
953 Note to RFC editor: please remove this entire appendix, and the
954 corresponding entries in the table of contents, prior to publication.
956 B.1 Changes from draft-ietf-apex-presence-04
958 o Corrected three typos.
960 o Removed the reference to "xml.resource.org" in the DTD.
962 o Changed the syntax of the "baseline" attribute to URI, to allow
963 for distributed registration of possible values.
965 o Added timezone warning to the "Security Considerations" section.
967 B.2 Changes from draft-ietf-apex-presence-03
969 o The new date-time format referenced in the core document is now
970 used for the timestamp data-type.
972 o The relationship of the "reply" element to the core document was
973 clarified.
975 B.3 Changes from draft-ietf-apex-presence-02
977 o Re-organization previous version for consistency.
979 B.4 Changes from draft-ietf-apex-presence-01
981 o Grammar error in Security Considerations.
983 o Extraneous sentence in Step 6.2 of Section 4.3.
985 o Notifications are now sent when a subscription is terminated.
987 B.5 Changes from draft-ietf-apex-presence-00
989 o Change "subaddress" convention from RFC 2846 to APEX's custom
990 ABNF.
992 Full Copyright Statement
994 Copyright (C) The Internet Society (2001). All Rights Reserved.
996 This document and translations of it may be copied and furnished to
997 others, and derivative works that comment on or otherwise explain it
998 or assist in its implementation may be prepared, copied, published
999 and distributed, in whole or in part, without restriction of any
1000 kind, provided that the above copyright notice and this paragraph are
1001 included on all such copies and derivative works. However, this
1002 document itself may not be modified in any way, such as by removing
1003 the copyright notice or references to the Internet Society or other
1004 Internet organizations, except as needed for the purpose of
1005 developing Internet standards in which case the procedures for
1006 copyrights defined in the Internet Standards process must be
1007 followed, or as required to translate it into languages other than
1008 English.
1010 The limited permissions granted above are perpetual and will not be
1011 revoked by the Internet Society or its successors or assigns.
1013 This document and the information contained herein is provided on an
1014 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1015 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1016 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1017 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1018 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1020 Acknowledgement
1022 Funding for the RFC Editor function is currently provided by the
1023 Internet Society.