idnits 2.17.1
draft-ietf-apex-presence-04.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 (July 9, 2001) is 8326 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-04
** 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-06
** 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: January 7, 2002 G. Klyne
5 Baltimore Technologies
6 D. Crocker
7 Brandenburg Consulting
8 July 9, 2001
10 The APEX Presence Service
11 draft-ietf-apex-presence-04
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 January 7, 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-03 . . . . . . . . . . . 31
70 B.2 Changes from draft-ietf-apex-presence-02 . . . . . . . . . . . 31
71 B.3 Changes from draft-ietf-apex-presence-01 . . . . . . . . . . . 31
72 B.4 Changes from draft-ietf-apex-presence-00 . . . . . . . . . . . 31
73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32
75 1. Introduction
77 This memo describes a presence service that is built upon the APEX
78 [1] "relaying mesh". The APEX presence service is used to manage
79 presence information for APEX endpoints.
81 APEX, at its core, provides a best-effort datagram service. Within
82 an administrative domain, all relays must be able to handle messages
83 for any endpoint within that domain. APEX services are logically
84 defined as endpoints but given their ubiquitous semantics they do not
85 necessarily need to be associated with a single physical endpoint.
86 As such, they may be provisioned co-resident with each relay within
87 an administrative domain, even though they are logically provided on
88 top of the relaying mesh, i.e.,
90 +----------+ +----------+ +----------+ +---------+
91 | APEX | | APEX | | APEX | | |
92 | access | | presence | | report | | ... |
93 | service | | service | | service | | |
94 +----------+ +----------+ +----------+ +---------+
95 | | | |
96 | | | |
97 +----------------------------------------------------------------+
98 | |
99 | APEX core |
100 | |
101 +----------------------------------------------------------------+
103 That is, applications communicate with an APEX service by exchanging
104 data with a "well-known endpoint" (WKE).
106 APEX applications communicate with the presence service by exchanging
107 data with the well-known endpoint "apex=presence" in the
108 corresponding administrative domain, e.g.,
109 "apex=presence@example.com" is the endpoint associated with the
110 presence service in the "example.com" administrative domain.
112 Note that within a single administrative domain, the presence service
113 makes use of the APEX access [3] service in order to determine if an
114 originator is allowed to view or manage presence information.
116 2. Management of Presence Information
118 Management of presence information falls into three categories:
120 o applications may update the presence information associated with
121 an endpoint;
123 o applications may subscribe to receive presence information
124 associated with an endpoint; and,
126 o applications may find out who is subscribed to receive presence
127 information.
129 Each is now described in turn.
131 2.1 Update of Presence Information
133 When an application wants to modify the presence information
134 associated with an endpoint, it sends a publish operation to the
135 service, e.g.,
137 +-------+ +-------+
138 | | -- data -------> | |
139 | appl. | | relay |
140 | | <--------- ok -- | |
141 +-------+ +-------+
143 C:
144
145
146
147
149
152
155
157
158
159
160
161 S:
163 Note that this example uses the "subaddress" convention specified in
164 Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of
165 traffic for a particular endpoint. Of course, popular applications
166 may have their own URI method assigned to them (e.g.,
167 "im:fred@example.com").
169 The service immediately responds with a reply operation containing
170 the same transaction-identifier, e.g.,
172 +-------+ +-------+
173 | | <------- data -- | |
174 | relay | | pres. |
175 | | -- ok ---------> | svc. |
176 +-------+ +-------+
178 C:
179
180
181
182
183
184
185 S:
187 2.2 Distribution of Presence Information
189 When an application wants to (periodically) receive the presence
190 information associated with an endpoint, it sends a subscribe
191 operation to the service, e.g.,
193 +-------+ +-------+
194 | | -- data -------> | |
195 | appl. | | relay |
196 | | <--------- ok -- | |
197 +-------+ +-------+
199 C:
200
201
202
203
205
206
207 S:
209 The service immediately responds with a publish operation containing
210 the same transaction-identifier, e.g.,
212 +-------+ +-------+
213 | | <------- data -- | |
214 | relay | | pres. |
215 | | -- ok ---------> | svc. |
216 +-------+ +-------+
218 C:
219
220
221
222
224
227
230
231
232
233
234 S:
236 Subsequently, for up to the specified "duration", the service sends
237 new publish operations whenever there are any changes to the
238 endpoint's presence information. If the "duration" is zero-valued, a
239 one time poll of the presence information is achieved; otherwise, at
240 the end of the "duration", a terminate operation is sent.
242 Note that Step 5 of Section 4.4 requires that the "lastUpdate"
243 attribute of a presence entry be supplied in order to update that
244 entry; accordingly, applications must successfully retrieve an
245 publish entry prior to trying to update that entry. This is usually
246 accomplished by subscribing with a zero-valued duration.
248 Either the subscriber or the service may cancel a subscription by
249 sending a terminate operation, e.g.,
251 +-------+ +-------+
252 | | -- data -------> | |
253 | appl. | | relay |
254 | | <--------- ok -- | |
255 +-------+ +-------+
257 C:
258
259
260
261
262
263
264 S:
266 +-------+ +-------+
267 | | <------- data -- | |
268 | relay | | pres. |
269 | | -- ok ---------> | svc. |
270 +-------+ +-------+
272 C:
273
274
275
276
277
278
279 S:
281 or
282 +-------+ +-------+
283 | | <------- data -- | |
284 | relay | | pres. |
285 | | -- ok ---------> | svc. |
286 +-------+ +-------+
288 C:
289
290
291
292
293
294
295 S:
297 2.3 Distribution of Watcher Information
299 When an application wants to (periodically) receive notices about
300 endpoints that are subscribed to receive presence information, it
301 sends a watch operation to the service, e.g.,
303 +-------+ +-------+
304 | | -- data -------> | |
305 | appl. | | relay |
306 | | <--------- ok -- | |
307 +-------+ +-------+
309 C:
310
311
312
313
315
316
317 S:
319 The service immediately responds with a reply operation containing
320 the same transaction-identifier, e.g.,
322 +-------+ +-------+
323 | | <------- data -- | |
324 | relay | | pres. |
325 | | -- ok ---------> | svc. |
326 +-------+ +-------+
328 C:
329
330
331
333
334
335 S:
337 For each current subscriber, the service immediately sends a notify
338 operation containing the same transaction-identifier, e.g.,
340 +-------+ +-------+
341 | | <------- data -- | |
342 | relay | | pres. |
343 | | -- ok ---------> | svc. |
344 +-------+ +-------+
346 C:
347
348
349
350
352
353
354 S:
356 Subsequently, for up to the specified "duration", the service sends
357 new notify operations whenever an application subscribes successfully
358 or a subscription is terminated. If the "duration" is zero-valued, a
359 one time poll of the watcher information is achieved; otherwise, at
360 the end of the "duration", a terminate operation is sent.
362 Either the watcher or the service may cancel the request by sending a
363 terminate operation, e.g.,
365 +-------+ +-------+
366 | | -- data -------> | |
367 | appl. | | relay |
368 | | <--------- ok -- | |
369 +-------+ +-------+
371 C:
372
373
374
375
376
377
378 S:
380 +-------+ +-------+
381 | | <------- data -- | |
382 | relay | | pres. |
383 | | -- ok ---------> | svc. |
384 +-------+ +-------+
386 C:
387
388
389
390
391
392
393 S:
395 or
396 +-------+ +-------+
397 | | <------- data -- | |
398 | relay | | pres. |
399 | | -- ok ---------> | svc. |
400 +-------+ +-------+
402 C:
403
404
405
406
407
408
409 S:
411 3. Format of Presence Entries
413 Each administrative domain is responsible for maintaining a "presence
414 entry" for each of its endpoints (regardless of whether those
415 endpoints are currently attached to the relaying mesh).
417 Section 6 defines the syntax for presence entries. Each presence
418 entry has a "publisher" attribute, a "lastUpdate" attribute, a
419 "publisherInfo" attribute, and contains one or more "tuple" elements:
421 o the "publisher" attribute specifies the endpoint associated with
422 the presence entry;
424 o the "lastUpdate" attribute specifies the date and time that the
425 service last updated the presence entry;
427 o the "publisherInfo" attribute specifies arbitrary information
428 about the publisher (using a URI); and,
430 o each "tuple" element specifies information about an entity
431 associated with the endpoint.
433 Each "tuple" element has a "destination" attribute, an
434 "availableUntil" attribute, a "tupleInfo" attribute, and contains
435 zero or more "capability" elements:
437 o the "destination" attribute identifies the entity as a URI (e.g.,
438 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
440 o the "availableUntil" attribute specifies the latest date and time
441 that the entity is capable of receiving messages;
443 o the "tupleInfo" attribute specifies arbitrary information about
444 the entity (using a URI); and,
446 o each "capability" element contains a specification as to the kinds
447 of content the entity is capable of receiving.
449 Each "capability" element contains arbitrary character data formatted
450 according to the standard indicated in the element's "baseline"
451 attribute.
453 4. The Presence Service
455 Section 5 contains the APEX service registration for the presence
456 service:
458 o Within an administrative domain, the service is addressed using
459 the well-known endpoint of "apex=presence".
461 o Section 6 defines the syntax of the operations exchanged with the
462 service.
464 o A consumer of the service initiates communications by sending data
465 containing the subscribe, watch, or publish operation.
467 o In addition to replying to these operations, the service may also
468 initiate communications by sending data containing the terminate,
469 publish, or notify operations.
471 An implementation of the service must maintain information about both
472 presence entries and in-progress operations in persistent storage.
474 Consult Section 6.1.1 of [1] for a discussion on the properties of
475 long-lived transaction-identifiers.
477 4.1 Use of XML and MIME
479 Section 4.1 of [1] describes how arbitrary MIME content is exchanged
480 as a BEEP [2] payload. For example, to transmit:
482
483
484
485
487 where "..." refers to:
489 then the corresponding BEEP message might look like this:
491 C: MSG 1 1 . 42 1234
492 C: Content-Type: multipart/related; boundary="boundary";
493 C: start="<1@example.com>";
494 C: type="application/beep+xml"
495 C:
496 C: --boundary
497 C: Content-Type: application/beep+xml
498 C: Content-ID: <1@example.com>
499 C:
500 C:
501 C:
502 C:
503 C:
504 C: --boundary
505 C: Content-Type: application/beep+xml
506 C: Content-ID: <2@example.com>
507 C:
508 C:
509 C: --boundary--
510 C: END
512 or this:
514 C: MSG 1 1 . 42 1234
515 C: Content-Type: application/beep+xml
516 C:
517 C:
518 C:
519 C:
520 C:
521 C:
522 C:
523 C:
524 C: END
526 4.2 The Subscribe Operation
528 When an application wants to (periodically) receive the presence
529 information associated with an endpoint, it sends a "subscribe"
530 element to the service.
532 The "subscribe" element has a "publisher" attribute, a "duration"
533 attribute, a "transID" attribute, and no content:
535 o the "publisher" attribute specifies the endpoint associated with
536 the presence entry;
538 o the "transID" attribute specifies the transaction-identifier
539 associated with this operation; and,
541 o the "duration" attribute specifies the maximum number of seconds
542 for which the originator is interested in receiving updated
543 presence information.
545 When the service receives a "subscribe" element, we refer to the
546 "publisher" attribute of that element as the "subject", and the
547 service performs these steps:
549 1. If the subject is outside of this administrative domain, a
550 "reply" element having code 553 is sent to the originator.
552 2. If the subject does not refer to a valid endpoint, a "reply"
553 element having code 550 is sent to the originator.
555 3. If the subject's access entry does not contain a
556 "presence:subscribe" token for the originator, a "reply" element
557 having code 537 is sent to the originator.
559 4. If the originator already has an in-progress subscribe operation
560 for the subject, then the previous subscribe operation is
561 silently terminated, and processing continues.
563 5. If the "transID" attribute refers to an in-progress subscribe or
564 watch operation for the originator, a "reply" element having code
565 555 is sent to the originator.
567 6. Otherwise:
569 1. A "publish" element, corresponding to the subject's presence
570 entry, is immediately sent to the originator.
572 2. For each endpoint currently watching subscribers to the
573 subject's presence information, a "notify" element is
574 immediately as sent (c.f., Step 6.3 of Section 4.6).
576 3. For up to the amount of time indicated by the "duration"
577 attribute of the "subscribe" element, if the subject's
578 presence entry changes, an updated "presence" element is sent
579 to the originator using the publish operation (Section 4.4).
580 Finally, when the amount of time indicated by the "duration"
581 attribute expires, a terminate operation (Section 4.5) is
582 sent to the originator.
584 Note that if the duration is zero-valued, then the subscribe
585 operation is making a one-time poll of the presence information.
586 Accordingly, Step 6.3 above does not occur.
588 Regardless of whether a "publish" or "reply" element is sent to the
589 originator, the "transID" attribute is identical to the value found
590 in the "subscribe" element sent by the originator.
592 4.3 The Watch Operation
594 When an application wants to (periodically) receive notices about
595 endpoints that are subscribed to receive presence entry, it sends a
596 "watch" element to the service.
598 The "watch" element has a "publisher" attribute, a "duration"
599 attribute, a "transID" attribute, and no content:
601 o the "publisher" attribute specifies the endpoint associated with
602 the presence entry;
604 o the "transID" attribute specifies the transaction-identifier
605 associated with this operation; and,
607 o the "duration" attribute specifies the maximum number of seconds
608 for which the originator is interested in watching subscribers.
610 When the service receives a "watch" element, we refer to the
611 "publisher" attribute of that element as the "subject", and the
612 service performs these steps:
614 1. If the subject is outside of this administrative domain, a
615 "reply" element having code 553 is sent to the originator.
617 2. If the subject does not refer to a valid endpoint, a "reply"
618 element having code 550 is sent to the originator.
620 3. If the subject's access entry does not contain a "presence:watch"
621 token for the originator, a "reply" element having code 537 is
622 sent to the originator.
624 4. If the originator already has an in-progress watch operation for
625 the subject, then the previous watch operation is silently
626 terminated, and processing continues.
628 5. If the "transID" attribute refers to an in-progress subscribe or
629 watch operation for the originator, a "reply" element having code
630 555 is sent to the originator.
632 6. Otherwise:
634 1. A "reply" element having code 250 is sent to the originator.
636 2. For each endpoint currently subscribing to the subject's
637 presence information, a "notify" element is immediately sent
638 to the originator (c.f., Section 4.6).
640 3. For up to the amount of time indicated by the "duration"
641 attribute of the "watch" element, whenever a subscribe
642 operation succeeds or a subscription is terminated, a
643 "notify" element is sent to the originator. Finally, when
644 the amount of time indicated by the "duration" attribute
645 expires, a terminate operation (Section 4.5) is sent to the
646 originator.
648 Note that if the duration is zero-valued, then the watch
649 operation is making a one-time poll of the presence information.
650 Accordingly, Step 6.3 above does not occur.
652 Regardless of whether a "notify" or "reply" element is sent to the
653 originator, the "transID" attribute is identical to the value found
654 in the "presence" element sent by the originator.
656 4.4 The Publish Operation
658 When an application wants to modify the presence entry associated
659 with an endpoint, it sends a "publish" element to the service. In
660 addition, the service sends a "publish" element to endpoints that
661 have subscribed to see presence information (c.f., Section 4.2).
663 The "publish" element has a "publisher" attribute, a "transID"
664 attribute, a "timeStamp" attribute, and contains a "presence"
665 element:
667 o the "publisher" attribute specifies the endpoint to be associated
668 with the presence entry;
670 o the "transID" attribute specifies the transaction-identifier
671 associated with this operation;
673 o the "timeStamp" attribute specifies the application's notion of
674 the current date and time; and,
676 o the "presence" element contains the desired presence entry for the
677 endpoint.
679 When the service sends a "publish" element, the "transID" attribute
680 specifies the transaction-identifier associated with the subscribe
681 operation that caused this "publish" element to be sent, and the
682 "timeStamp" attribute specifies the service's notion of the current
683 date and time. No reply is sent by the receiving endpoint.
685 When the service receives a "publish" element, we refer to the
686 "publisher" attribute of that element as the "subject", and the
687 service performs these steps:
689 1. If the "publisher" attribute of the "publish" element doesn't
690 match the "publisher" attribute of the "presence" element
691 contained in the "publish" element, a "reply" element having code
692 503 is sent to the originator.
694 2. If the subject is outside of this administrative domain, a
695 "reply" element having code 553 is sent to the originator.
697 3. If the subject does not refer to a valid endpoint, a "reply"
698 element having code 550 is sent to the originator.
700 4. If the subject's access entry does not contain a
701 "presence:publish" token for the originator, a "reply" element
702 having code 537 is sent to the originator.
704 5. If the "lastUpdate" attribute of the "publish" element is not
705 semantically identical to the "lastUpdate" attribute of the
706 subject's presence entry, a "reply" element having code 555 is
707 sent to the originator. (This allows a simple mechanism for
708 atomic updates.)
710 6. Otherwise:
712 1. The subject's presence entry is updated from the "publish"
713 element.
715 2. The "lastUpdate" attribute of the presence entry is set to
716 the service's notion of the current date and time.
718 3. A "reply" element having code 250 is sent to the originator.
720 When sending the "reply" element, the "transID" attribute is
721 identical to the value found in the "publish" element sent by the
722 originator.
724 4.5 The Terminate Operation
726 When an application no longer wishes to subscribe to presence
727 information or to watch endpoints that are subscribed to receive
728 presence information, it sends a "terminate" element to the service;
729 similarly, when the service no longer considers an application to be
730 subscribing or watching, a "terminate" element is sent to the
731 application.
733 The "terminate" element contains only a "transID" attribute that
734 specifies the transaction-identifier associated an in-progress
735 subscribe or watch operation. Section 9.1 of [1] defines the syntax
736 for the "terminate" element.
738 When the service receives a "terminate" element, it performs these
739 steps:
741 1. If the transaction-identifier does not refer to a previous
742 subscribe or watch operation for the originator, an "error"
743 element having code 550 is returned.
745 2. Otherwise, the previous subscribe or watch operation for the
746 originator is terminated, and a "reply" element having code 250
747 is sent to the originator.
749 Note that following a terminate operation, the originator may receive
750 further presence or watcher updates. Although the service will send
751 no further updates after processing a terminate operation and sending
752 the reply operation, earlier updates may be in transit.
754 4.6 The Notify Operation
756 The service sends a "notify" element to endpoints that are watching
757 other endpoints subscribed to presence information (c.f., Section
758 4.3).
760 The "notify" element has a "subscriber" attribute, a "transID"
761 attribute, a "duration" attribute, an "action" attribute, and no
762 content:
764 o the "subscriber" attribute specifies the endpoint that is
765 subscribed to presence information; and,
767 o the "transID" attribute specifies the transaction-identifier
768 associated with the watch operation that caused this "notify"
769 element to be sent;
771 o the "action" attribute specifies whether a subscription or its
772 termination has occurred; and,
774 o if a subscription is being reported, the "duration" attribute
775 specifies the requested duration of the subscription.
777 No reply is sent by the receiving endpoint.
779 4.7 The Reply Operation
781 While processing operations, the service may respond with a "reply"
782 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for
783 the definition and an exposition of the syntax of the reply element.
785 5. Registration: The Presence Service
787 Well-Known Endpoint: apex=presence
789 Syntax of Messages Exchanged: c.f., Section 6
791 Sequence of Messages Exchanged: c.f., Section 4
793 Access Control Tokens: presence:subscribe, presence:watch,
794 presence:publish
796 Contact Information: c.f., the "Authors' Addresses" section of this
797 memo
799 6. The Presence Service DTD
801
811
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 References
900 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
901 Core", draft-ietf-apex-core-04 (work in progress), July 2001.
903 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
904 3080, March 2001.
906 [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service",
907 draft-ietf-apex-access-06 (work in progress), July 2001.
909 Authors' Addresses
911 Marshall T. Rose
912 Invisible Worlds, Inc.
913 131 Stony Circle
914 Suite 500
915 Santa Rosa, CA 95401
916 US
918 Phone: +1 707 578 2350
919 EMail: mrose@invisible.net
920 URI: http://invisible.net/
922 Graham Klyne
923 Baltimore Technologies
924 1310 Waterside
925 Arlington Business Park
926 Theale, Reading RG7 4SA
927 UK
929 Phone: +44 118 903 8000
930 EMail: gk@acm.org
932 David H. Crocker
933 Brandenburg Consulting
934 675 Spruce Drive
935 Sunnyvale, CA 94086
936 US
938 Phone: +1 408 246 8253
939 EMail: dcrocker@brandenburg.com
940 URI: http://www.brandenburg.com/
942 Appendix A. Acknowledgements
944 The authors gratefully acknowledge the contributions of: Neil Cook,
945 Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
947 Appendix B. Revision History
949 B.1 Changes from draft-ietf-apex-presence-03
951 o The new date-time format referenced in the core document is now
952 used for the timestamp data-type.
954 o The relationship of the "reply" element to the core document was
955 clarified.
957 B.2 Changes from draft-ietf-apex-presence-02
959 o Re-organization previous version for consistency.
961 B.3 Changes from draft-ietf-apex-presence-01
963 o Grammar error in Security Considerations.
965 o Extraneous sentence in Step 6.2 of Section 4.3.
967 o Notifications are now sent when a subscription is terminated.
969 B.4 Changes from draft-ietf-apex-presence-00
971 o Change "subaddress" convention from RFC 2846 to APEX's custom
972 ABNF.
974 Full Copyright Statement
976 Copyright (C) The Internet Society (2001). All Rights Reserved.
978 This document and translations of it may be copied and furnished to
979 others, and derivative works that comment on or otherwise explain it
980 or assist in its implementation may be prepared, copied, published
981 and distributed, in whole or in part, without restriction of any
982 kind, provided that the above copyright notice and this paragraph are
983 included on all such copies and derivative works. However, this
984 document itself may not be modified in any way, such as by removing
985 the copyright notice or references to the Internet Society or other
986 Internet organizations, except as needed for the purpose of
987 developing Internet standards in which case the procedures for
988 copyrights defined in the Internet Standards process must be
989 followed, or as required to translate it into languages other than
990 English.
992 The limited permissions granted above are perpetual and will not be
993 revoked by the Internet Society or its successors or assigns.
995 This document and the information contained herein is provided on an
996 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
997 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
998 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
999 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1000 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1002 Acknowledgement
1004 Funding for the RFC Editor function is currently provided by the
1005 Internet Society.