idnits 2.17.1
draft-ietf-apex-presence-03.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 821 has weird spacing: '...itiates ser...'
== Line 838 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 (May 2001) is 8381 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-03
** 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-05
** 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: October 30, 2001 G. Klyne
5 Baltimore Technologies
6 D. Crocker
7 Brandenburg Consulting
8 May 2001
10 The APEX Presence Service
11 draft-ietf-apex-presence-03
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 October 30, 2001.
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-02 . . . . . . . . . . . 31
70 B.2 Changes from draft-ietf-apex-presence-01 . . . . . . . . . . . 31
71 B.3 Changes from draft-ietf-apex-presence-00 . . . . . . . . . . . 31
72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32
74 1. Introduction
76 This memo describes a presence service that is built upon the APEX
77 [1] "relaying mesh". The APEX presence service is used to manage
78 presence information for APEX endpoints.
80 APEX, at its core, provides a best-effort datagram service. Within
81 an administrative domain, all relays must be able to handle messages
82 for any endpoint within that domain. APEX services are logically
83 defined as endpoints but given their ubiquitous semantics they do not
84 necessarily need to be associated with a single physical endpoint.
85 As such, they may be provisioned co-resident with each relay within
86 an administrative domain, even though they are logically provided on
87 top of the relaying mesh, i.e.,
89 +----------+ +----------+ +----------+ +---------+
90 | APEX | | APEX | | APEX | | |
91 | access | | presence | | report | | ... |
92 | service | | service | | service | | |
93 +----------+ +----------+ +----------+ +---------+
94 | | | |
95 | | | |
96 +----------------------------------------------------------------+
97 | |
98 | APEX core |
99 | |
100 +----------------------------------------------------------------+
102 That is, applications communicate with an APEX service by exchanging
103 data with a "well-known endpoint" (WKE).
105 APEX applications communicate with the presence service by exchanging
106 data with the well-known endpoint "apex=presence" in the
107 corresponding administrative domain, e.g.,
108 "apex=presence@example.com" is the endpoint associated with the
109 presence service in the "example.com" administrative domain.
111 Note that within a single administrative domain, the presence service
112 makes use of the APEX access [3] service in order to determine if an
113 originator is allowed to view or manage presence information.
115 2. Management of Presence Information
117 Management of presence information falls into three categories:
119 o applications may update the presence information associated with
120 an endpoint;
122 o applications may subscribe to receive presence information
123 associated with an endpoint; and,
125 o applications may find out who is subscribed to receive presence
126 information.
128 Each is now described in turn.
130 2.1 Update of Presence Information
132 When an application wants to modify the presence information
133 associated with an endpoint, it sends a publish operation to the
134 service, e.g.,
136 +-------+ +-------+
137 | | -- data -------> | |
138 | appl. | | relay |
139 | | <--------- ok -- | |
140 +-------+ +-------+
142 C:
143
144
145
146
148
151
154
156
157
158
159
160 S:
162 Note that this example uses the "subaddress" convention specified in
163 Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of
164 traffic for a particular endpoint. Of course, popular applications
165 may have their own URI method assigned to them (e.g.,
166 "im:fred@example.com").
168 The service immediately responds with a reply operation containing
169 the same transaction-identifier, e.g.,
171 +-------+ +-------+
172 | | <------- data -- | |
173 | relay | | pres. |
174 | | -- ok ---------> | svc. |
175 +-------+ +-------+
177 C:
178
179
180
181
182
183
184 S:
186 2.2 Distribution of Presence Information
188 When an application wants to (periodically) receive the presence
189 information associated with an endpoint, it sends a subscribe
190 operation to the service, e.g.,
192 +-------+ +-------+
193 | | -- data -------> | |
194 | appl. | | relay |
195 | | <--------- ok -- | |
196 +-------+ +-------+
198 C:
199
200
201
202
204
205
206 S:
208 The service immediately responds with a publish operation containing
209 the same transaction-identifier, e.g.,
211 +-------+ +-------+
212 | | <------- data -- | |
213 | relay | | pres. |
214 | | -- ok ---------> | svc. |
215 +-------+ +-------+
217 C:
218
219
220
221
223
226
229
230
231
232
233 S:
235 Subsequently, for up to the specified "duration", the service sends
236 new publish operations whenever there are any changes to the
237 endpoint's presence information. If the "duration" is zero-valued, a
238 one time poll of the presence information is achieved; otherwise, at
239 the end of the "duration", a terminate operation is sent.
241 Note that Step 5 of Section 4.4 requires that the "lastUpdate"
242 attribute of a presence entry be supplied in order to update that
243 entry; accordingly, applications must successfully retrieve an
244 publish entry prior to trying to update that entry. This is usually
245 accomplished by subscribing with a zero-valued duration.
247 Either the subscriber or the service may cancel a subscription by
248 sending a terminate operation, e.g.,
250 +-------+ +-------+
251 | | -- data -------> | |
252 | appl. | | relay |
253 | | <--------- ok -- | |
254 +-------+ +-------+
256 C:
257
258
259
260
261
262
263 S:
265 +-------+ +-------+
266 | | <------- data -- | |
267 | relay | | pres. |
268 | | -- ok ---------> | svc. |
269 +-------+ +-------+
271 C:
272
273
274
275
276
277
278 S:
280 or
281 +-------+ +-------+
282 | | <------- data -- | |
283 | relay | | pres. |
284 | | -- ok ---------> | svc. |
285 +-------+ +-------+
287 C:
288
289
290
291
292
293
294 S:
296 2.3 Distribution of Watcher Information
298 When an application wants to (periodically) receive notices about
299 endpoints that are subscribed to receive presence information, it
300 sends a watch operation to the service, e.g.,
302 +-------+ +-------+
303 | | -- data -------> | |
304 | appl. | | relay |
305 | | <--------- ok -- | |
306 +-------+ +-------+
308 C:
309
310
311
312
314
315
316 S:
318 The service immediately responds with a reply operation containing
319 the same transaction-identifier, e.g.,
321 +-------+ +-------+
322 | | <------- data -- | |
323 | relay | | pres. |
324 | | -- ok ---------> | svc. |
325 +-------+ +-------+
327 C:
328
329
330
332
333
334 S:
336 For each current subscriber, the service immediately sends a notify
337 operation containing the same transaction-identifier, e.g.,
339 +-------+ +-------+
340 | | <------- data -- | |
341 | relay | | pres. |
342 | | -- ok ---------> | svc. |
343 +-------+ +-------+
345 C:
346
347
348
349
351
352
353 S:
355 Subsequently, for up to the specified "duration", the service sends
356 new notify operations whenever an application subscribes successfully
357 or a subscription is terminated. If the "duration" is zero-valued, a
358 one time poll of the watcher information is achieved; otherwise, at
359 the end of the "duration", a terminate operation is sent.
361 Either the watcher or the service may cancel the request by sending a
362 terminate operation, e.g.,
364 +-------+ +-------+
365 | | -- data -------> | |
366 | appl. | | relay |
367 | | <--------- ok -- | |
368 +-------+ +-------+
370 C:
371
372
373
374
375
376
377 S:
379 +-------+ +-------+
380 | | <------- data -- | |
381 | relay | | pres. |
382 | | -- ok ---------> | svc. |
383 +-------+ +-------+
385 C:
386
387
388
389
390
391
392 S:
394 or
395 +-------+ +-------+
396 | | <------- data -- | |
397 | relay | | pres. |
398 | | -- ok ---------> | svc. |
399 +-------+ +-------+
401 C:
402
403
404
405
406
407
408 S:
410 3. Format of Presence Entries
412 Each administrative domain is responsible for maintaining a "presence
413 entry" for each of its endpoints (regardless of whether those
414 endpoints are currently attached to the relaying mesh).
416 Section 6 defines the syntax for presence entries. Each presence
417 entry has a "publisher" attribute, a "lastUpdate" attribute, a
418 "publisherInfo" attribute, and contains one or more "tuple" elements:
420 o the "publisher" attribute specifies the endpoint associated with
421 the presence entry;
423 o the "lastUpdate" attribute specifies the date and time that the
424 service last updated the presence entry;
426 o the "publisherInfo" attribute specifies arbitrary information
427 about the publisher (using a URI); and,
429 o each "tuple" element specifies information about an entity
430 associated with the endpoint.
432 Each "tuple" element has a "destination" attribute, an
433 "availableUntil" attribute, a "tupleInfo" attribute, and contains
434 zero or more "capability" elements:
436 o the "destination" attribute identifies the entity as a URI (e.g.,
437 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
439 o the "availableUntil" attribute specifies the latest date and time
440 that the entity is capable of receiving messages;
442 o the "tupleInfo" attribute specifies arbitrary information about
443 the entity (using a URI); and,
445 o each "capability" element contains a specification as to the kinds
446 of content the entity is capable of receiving.
448 Each "capability" element contains arbitrary character data formatted
449 according to the standard indicated in the element's "baseline"
450 attribute.
452 4. The Presence Service
454 Section 5 contains the APEX service registration for the presence
455 service:
457 o Within an administrative domain, the service is addressed using
458 the well-known endpoint of "apex=presence".
460 o Section 6 defines the syntax of the operations exchanged with the
461 service.
463 o A consumer of the service initiates communications by sending data
464 containing the subscribe, watch, or publish operation.
466 o In addition to replying to these operations, the service may also
467 initiate communications by sending data containing the terminate,
468 publish, or notify operations.
470 An implementation of the service must maintain information about both
471 presence entries and in-progress operations in persistent storage.
473 Consult Section 6.1.1 of [1] for a discussion on the properties of
474 long-lived transaction-identifiers.
476 4.1 Use of XML and MIME
478 Section 4.1 of [1] describes how arbitrary MIME content is exchanged
479 as a BEEP [2] payload. For example, to transmit:
481
482
483
484
486 where "..." refers to:
488 then the corresponding BEEP message might look like this:
490 C: MSG 1 1 . 42 1234
491 C: Content-Type: multipart/related; boundary="boundary";
492 C: start="<1@example.com>";
493 C: type="application/beep+xml"
494 C:
495 C: --boundary
496 C: Content-Type: application/beep+xml
497 C: Content-ID: <1@example.com>
498 C:
499 C:
500 C:
501 C:
502 C:
503 C: --boundary
504 C: Content-Type: application/beep+xml
505 C: Content-ID: <2@example.com>
506 C:
507 C:
508 C: --boundary--
509 C: END
511 or this:
513 C: MSG 1 1 . 42 1234
514 C: Content-Type: application/beep+xml
515 C:
516 C:
517 C:
518 C:
519 C:
520 C:
521 C:
522 C:
523 C: END
525 4.2 The Subscribe Operation
527 When an application wants to (periodically) receive the presence
528 information associated with an endpoint, it sends a "subscribe"
529 element to the service.
531 The "subscribe" element has a "publisher" attribute, a "duration"
532 attribute, a "transID" attribute, and no content:
534 o the "publisher" attribute specifies the endpoint associated with
535 the presence entry;
537 o the "transID" attribute specifies the transaction-identifier
538 associated with this operation; and,
540 o the "duration" attribute specifies the maximum number of seconds
541 for which the originator is interested in receiving updated
542 presence information.
544 When the service receives a "subscribe" element, we refer to the
545 "publisher" attribute of that element as the "subject", and the
546 service performs these steps:
548 1. If the subject is outside of this administrative domain, a
549 "reply" element having code 553 is sent to the originator.
551 2. If the subject does not refer to a valid endpoint, a "reply"
552 element having code 550 is sent to the originator.
554 3. If the subject's access entry does not contain a
555 "presence:subscribe" token for the originator, a "reply" element
556 having code 537 is sent to the originator.
558 4. If the originator already has an in-progress subscribe operation
559 for the subject, then the previous subscribe operation is
560 silently terminated, and processing continues.
562 5. If the "transID" attribute refers to an in-progress subscribe or
563 watch operation for the originator, a "reply" element having code
564 555 is sent to the originator.
566 6. Otherwise:
568 1. A "publish" element, corresponding to the subject's presence
569 entry, is immediately sent to the originator.
571 2. For each endpoint currently watching subscribers to the
572 subject's presence information, a "notify" element is
573 immediately as sent (c.f., Step 6.3 of Section 4.6).
575 3. For up to the amount of time indicated by the "duration"
576 attribute of the "subscribe" element, if the subject's
577 presence entry changes, an updated "presence" element is sent
578 to the originator using the publish operation (Section 4.4).
579 Finally, when the amount of time indicated by the "duration"
580 attribute expires, a terminate operation (Section 4.5) is
581 sent to the originator.
583 Note that if the duration is zero-valued, then the subscribe
584 operation is making a one-time poll of the presence information.
585 Accordingly, Step 6.3 above does not occur.
587 Regardless of whether a "publish" or "reply" element is sent to the
588 originator, the "transID" attribute is identical to the value found
589 in the "subscribe" element sent by the originator.
591 4.3 The Watch Operation
593 When an application wants to (periodically) receive notices about
594 endpoints that are subscribed to receive presence entry, it sends a
595 "watch" element to the service.
597 The "watch" element has a "publisher" attribute, a "duration"
598 attribute, a "transID" attribute, and no content:
600 o the "publisher" attribute specifies the endpoint associated with
601 the presence entry;
603 o the "transID" attribute specifies the transaction-identifier
604 associated with this operation; and,
606 o the "duration" attribute specifies the maximum number of seconds
607 for which the originator is interested in watching subscribers.
609 When the service receives a "watch" element, we refer to the
610 "publisher" attribute of that element as the "subject", and the
611 service performs these steps:
613 1. If the subject is outside of this administrative domain, a
614 "reply" element having code 553 is sent to the originator.
616 2. If the subject does not refer to a valid endpoint, a "reply"
617 element having code 550 is sent to the originator.
619 3. If the subject's access entry does not contain a "presence:watch"
620 token for the originator, a "reply" element having code 537 is
621 sent to the originator.
623 4. If the originator already has an in-progress watch operation for
624 the subject, then the previous watch operation is silently
625 terminated, and processing continues.
627 5. If the "transID" attribute refers to an in-progress subscribe or
628 watch operation for the originator, a "reply" element having code
629 555 is sent to the originator.
631 6. Otherwise:
633 1. A "reply" element having code 250 is sent to the originator.
635 2. For each endpoint currently subscribing to the subject's
636 presence information, a "notify" element is immediately sent
637 to the originator (c.f., Section 4.6).
639 3. For up to the amount of time indicated by the "duration"
640 attribute of the "watch" element, whenever a subscribe
641 operation succeeds or a subscription is terminated, a
642 "notify" element is sent to the originator. Finally, when
643 the amount of time indicated by the "duration" attribute
644 expires, a terminate operation (Section 4.5) is sent to the
645 originator.
647 Note that if the duration is zero-valued, then the watch
648 operation is making a one-time poll of the presence information.
649 Accordingly, Step 6.3 above does not occur.
651 Regardless of whether a "notify" or "reply" element is sent to the
652 originator, the "transID" attribute is identical to the value found
653 in the "presence" element sent by the originator.
655 4.4 The Publish Operation
657 When an application wants to modify the presence entry associated
658 with an endpoint, it sends a "publish" element to the service. In
659 addition, the service sends a "publish" element to endpoints that
660 have subscribed to see presence information (c.f., Section 4.2).
662 The "publish" element has a "publisher" attribute, a "transID"
663 attribute, a "timeStamp" attribute, and contains a "presence"
664 element:
666 o the "publisher" attribute specifies the endpoint to be associated
667 with the presence entry;
669 o the "transID" attribute specifies the transaction-identifier
670 associated with this operation;
672 o the "timeStamp" attribute specifies the application's notion of
673 the current date and time; and,
675 o the "presence" element contains the desired presence entry for the
676 endpoint.
678 When the service sends a "publish" element, the "transID" attribute
679 specifies the transaction-identifier associated with the subscribe
680 operation that caused this "publish" element to be sent, and the
681 "timeStamp" attribute specifies the service's notion of the current
682 date and time. No reply is sent by the receiving endpoint.
684 When the service receives a "publish" element, we refer to the
685 "publisher" attribute of that element as the "subject", and the
686 service performs these steps:
688 1. If the "publisher" attribute of the "publish" element doesn't
689 match the "publisher" attribute of the "presence" element
690 contained in the "publish" element, a "reply" element having code
691 503 is sent to the originator.
693 2. If the subject is outside of this administrative domain, a
694 "reply" element having code 553 is sent to the originator.
696 3. If the subject does not refer to a valid endpoint, a "reply"
697 element having code 550 is sent to the originator.
699 4. If the subject's access entry does not contain a
700 "presence:publish" token for the originator, a "reply" element
701 having code 537 is sent to the originator.
703 5. If the "lastUpdate" attribute of the "publish" element is not
704 semantically identical to the "lastUpdate" attribute of the
705 subject's presence entry, a "reply" element having code 555 is
706 sent to the originator. (This allows a simple mechanism for
707 atomic updates.)
709 6. Otherwise:
711 1. The subject's presence entry is updated from the "publish"
712 element.
714 2. The "lastUpdate" attribute of the presence entry is set to
715 the service's notion of the current date and time.
717 3. A "reply" element having code 250 is sent to the originator.
719 When sending the "reply" element, the "transID" attribute is
720 identical to the value found in the "publish" element sent by the
721 originator.
723 4.5 The Terminate Operation
725 When an application no longer wishes to subscribe to presence
726 information or to watch endpoints that are subscribed to receive
727 presence information, it sends a "terminate" element to the service;
728 similarly, when the service no longer considers an application to be
729 subscribing or watching, a "terminate" element is sent to the
730 application.
732 The "terminate" element contains only a "transID" attribute that
733 specifies the transaction-identifier associated an in-progress
734 subscribe or watch operation. Section 9.1 of [1] defines the syntax
735 for the "terminate" element.
737 When the service receives a "terminate" element, it performs these
738 steps:
740 1. If the transaction-identifier does not refer to a previous
741 subscribe or watch operation for the originator, an "error"
742 element having code 550 is returned.
744 2. Otherwise, the previous subscribe or watch operation for the
745 originator is terminated, and a "reply" element having code 250
746 is sent to the originator.
748 Note that following a terminate operation, the originator may receive
749 further presence or watcher updates. Although the service will send
750 no further updates after processing a terminate operation and sending
751 the reply operation, earlier updates may be in transit.
753 4.6 The Notify Operation
755 The service sends a "notify" element to endpoints that are watching
756 other endpoints subscribed to presence information (c.f., Section
757 4.3).
759 The "notify" element has a "subscriber" attribute, a "transID"
760 attribute, a "duration" attribute, an "action" attribute, and no
761 content:
763 o the "subscriber" attribute specifies the endpoint that is
764 subscribed to presence information; and,
766 o the "transID" attribute specifies the transaction-identifier
767 associated with the watch operation that caused this "notify"
768 element to be sent;
770 o the "action" attribute specifies whether a subscription or its
771 termination has occurred; and,
773 o if a subscription is being reported, the "duration" attribute
774 specifies the requested duration of the subscription.
776 No reply is sent by the receiving endpoint.
778 4.7 The Reply Operation
780 While processing operations, the service may respond with a "reply"
781 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for
782 the syntax and semantics of the reply operation.
784 5. Registration: The Presence Service
786 Well-Known Endpoint: apex=presence
788 Syntax of Messages Exchanged: c.f., Section 6
790 Sequence of Messages Exchanged: c.f., Section 4
792 Access Control Tokens: presence:subscribe, presence:watch,
793 presence:publish
795 Contact Information: c.f., the "Authors' Addresses" section of this
796 memo
798 6. The Presence Service DTD
800
810
812 %APEXCORE;
814
843
844
849
850
855
856
857
862
863
870
874
875
881
882
888
889
890
893 7. Security Considerations
895 Consult [1]'s Section 11 for a discussion of security issues.
897 References
899 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
900 Core", draft-ietf-apex-core-03 (work in progress), June 2001.
902 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
903 3080, March 2001.
905 [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service",
906 draft-ietf-apex-access-05 (work in progress), June 2001.
908 Authors' Addresses
910 Marshall T. Rose
911 Invisible Worlds, Inc.
912 131 Stony Circle
913 Suite 500
914 Santa Rosa, CA 95401
915 US
917 Phone: +1 707 578 2350
918 EMail: mrose@invisible.net
919 URI: http://invisible.net/
921 Graham Klyne
922 Baltimore Technologies
923 1310 Waterside
924 Arlington Business Park
925 Theale, Reading RG7 4SA
926 UK
928 Phone: +44 118 903 8000
929 EMail: gk@acm.org
931 David H. Crocker
932 Brandenburg Consulting
933 675 Spruce Drive
934 Sunnyvale, CA 94086
935 US
937 Phone: +1 408 246 8253
938 EMail: dcrocker@brandenburg.com
939 URI: http://www.brandenburg.com/
941 Appendix A. Acknowledgements
943 The authors gratefully acknowledge the contributions of: Neil Cook,
944 Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
946 Appendix B. Revision History
948 B.1 Changes from draft-ietf-apex-presence-02
950 o Re-organization previous version for consistency.
952 B.2 Changes from draft-ietf-apex-presence-01
954 o Grammar error in Security Considerations.
956 o Extraneous sentence in Step 6.2 of Section 4.3.
958 o Notifications are now sent when a subscription is terminated.
960 B.3 Changes from draft-ietf-apex-presence-00
962 o Change "subaddress" convention from RFC 2846 to APEX's custom
963 ABNF.
965 Full Copyright Statement
967 Copyright (C) The Internet Society (2001). All Rights Reserved.
969 This document and translations of it may be copied and furnished to
970 others, and derivative works that comment on or otherwise explain it
971 or assist in its implementation may be prepared, copied, published
972 and distributed, in whole or in part, without restriction of any
973 kind, provided that the above copyright notice and this paragraph are
974 included on all such copies and derivative works. However, this
975 document itself may not be modified in any way, such as by removing
976 the copyright notice or references to the Internet Society or other
977 Internet organizations, except as needed for the purpose of
978 developing Internet standards in which case the procedures for
979 copyrights defined in the Internet Standards process must be
980 followed, or as required to translate it into languages other than
981 English.
983 The limited permissions granted above are perpetual and will not be
984 revoked by the Internet Society or its successors or assigns.
986 This document and the information contained herein is provided on an
987 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
988 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
989 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
990 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
991 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
993 Acknowledgement
995 Funding for the RFC Editor function is currently provided by the
996 Internet Society.