idnits 2.17.1
draft-ietf-apex-presence-00.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 809 has weird spacing: '...itiates ser...'
== Line 826 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 (February 2001) is 8464 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-00
** 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-00
** 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: August 2, 2001 G. Klyne
5 Baltimore Technologies
6 D. Crocker
7 Brandenburg Consulting
8 February 2001
10 The APEX Presence Service
11 draft-ietf-apex-presence-00
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 August 2, 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 . . . . . . . . . . . . . . . . . . . . . . . 31
68 B. Changes from IMXP . . . . . . . . . . . . . . . . . . . . . . 32
69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
71 1. Introduction
73 This memo describes a presence service that is built upon the APEX
74 [1] "relaying mesh". The APEX presence service is used to manage
75 presence information for APEX endpoints.
77 APEX, at its core, provides a best-effort datagram service. Within
78 an administrative domain, all relays must be able to handle messages
79 for any endpoint within that domain. APEX services are logically
80 defined as endpoints but given their ubiquitous semantics they do not
81 necessarily need to be associated with a single physical endpoint.
82 As such, they may be provisioned co-resident with each relay within
83 an administrative domain, even though they are logically provided on
84 top of the relaying mesh, i.e.,
86 +----------+ +----------+ +----------+ +---------+
87 | APEX | | APEX | | APEX | | |
88 | access | | presence | | report | | ... |
89 | service | | service | | service | | |
90 +----------+ +----------+ +----------+ +---------+
91 | | | |
92 | | | |
93 +----------------------------------------------------------------+
94 | |
95 | APEX core |
96 | |
97 +----------------------------------------------------------------+
99 That is, applications communicate with an APEX service by exchanging
100 data with a "well-known endpoint" (WKE).
102 APEX applications communicate with the presence service by exchanging
103 data with the well-known endpoint "apex=presence" in the
104 corresponding administrative domain, e.g.,
105 "apex=presence@example.com" is the endpoint associated with the
106 presence service in the "example.com" administrative domain.
108 Note that within a single administrative domain, the presence service
109 makes use of the APEX access [3] service in order to determine if an
110 originator is allowed to view or manage presence information.
112 2. Management of Presence Information
114 Management of presence information falls into three categories:
116 o applications may update the presence entry associated with an
117 endpoint;
119 o applications may subscribe to receive presence information about
120 an endpoint; and,
122 o applications may find out who is subscribed to receive presence
123 information.
125 Each is now described in turn.
127 2.1 Update of Presence Information
129 When an application wants to modify the presence entry associated
130 with an endpoint, it sends a publish operation to the service, e.g.,
132 +-------+ +-------+
133 | | -- data -------> | |
134 | appl. | | relay |
135 | | <--------- ok -- | |
136 +-------+ +-------+
138 C:
139
140
141
142
144
147
150
152
153
154
155
156 S:
158 Note that this example uses the subaddress-specification convention
159 of RFC 2846 [4] (e.g., "fred/appl=im") to denote multiplexing of
160 traffic for a particular endpoint. Of course, popular applications
161 may have their own URI method assigned to them (e.g.,
162 "im:fred@example.com").
164 The service immediately responds with a reply operation containing
165 the same transaction-identifier, e.g.,
167 +-------+ +-------+
168 | | <------- data -- | |
169 | relay | | pres. |
170 | | -- ok ---------> | svc. |
171 +-------+ +-------+
173 C:
174
175
176
177
178
179
180 S:
182 2.2 Distribution of Presence Information
184 When an application wants to (periodically) receive the presence
185 entry associated with an endpoint, it sends a subscribe operation to
186 the service, e.g.,
188 +-------+ +-------+
189 | | -- data -------> | |
190 | appl. | | relay |
191 | | <--------- ok -- | |
192 +-------+ +-------+
194 C:
195
196
197
198
200
201
202 S:
204 The service immediately responds with a publish operation containing
205 the same transaction-identifier, e.g.,
207 +-------+ +-------+
208 | | <------- data -- | |
209 | relay | | pres. |
210 | | -- ok ---------> | svc. |
211 +-------+ +-------+
213 C:
214
215
216
217
219
222
225
226
227
228
229 S:
231 Subsequently, for up to the specified "duration", the service sends
232 new publish operations whenever there are any changes to the
233 endpoint's presence information. If the "duration" is zero-valued, a
234 one time poll of the presence information is achieved; otherwise, at
235 the end of the "duration", a terminate operation is sent.
237 Note that Step 5 of Section 4.4 requires that the "lastUpdate"
238 attribute of a presence entry be supplied in order to update that
239 entry; accordingly, applications must successfully retrieve an
240 publish entry prior to trying to update that entry. This is usually
241 accomplished by subscribing with a zero-valued duration.
243 Either the subscriber or the service may cancel a subscription by
244 sending a terminate operation, e.g.,
246 +-------+ +-------+
247 | | -- data -------> | |
248 | appl. | | relay |
249 | | <--------- ok -- | |
250 +-------+ +-------+
252 C:
253
254
255
256
257
258
259 S:
261 +-------+ +-------+
262 | | <------- data -- | |
263 | relay | | pres. |
264 | | -- ok ---------> | svc. |
265 +-------+ +-------+
267 C:
268
269
270
271
272
273
274 S:
276 or
277 +-------+ +-------+
278 | | <------- data -- | |
279 | relay | | pres. |
280 | | -- ok ---------> | svc. |
281 +-------+ +-------+
283 C:
284
285
286
287
288
289
290 S:
292 2.3 Distribution of Watcher Information
294 When an application wants to (periodically) receive notices about
295 endpoints that are subscribed to receive presence information, it
296 sends a watch operation to the service, e.g.,
298 +-------+ +-------+
299 | | -- data -------> | |
300 | appl. | | relay |
301 | | <--------- ok -- | |
302 +-------+ +-------+
304 C:
305
306
307
308
310
311
312 S:
314 The service immediately responds with a reply operation containing
315 the same transaction-identifier, e.g.,
317 +-------+ +-------+
318 | | <------- data -- | |
319 | relay | | pres. |
320 | | -- ok ---------> | svc. |
321 +-------+ +-------+
323 C:
324
325
326
328
329
330 S:
332 For each current subscriber, the service immediately sends a notify
333 operation containing the same transaction-identifier, e.g.,
335 +-------+ +-------+
336 | | <------- data -- | |
337 | relay | | pres. |
338 | | -- ok ---------> | svc. |
339 +-------+ +-------+
341 C:
342
343
344
345
346
347
348 S:
350 Subsequently, for up to the specified "duration", the service sends
351 new notify operations whenever an application subscribes
352 successfully. If the "duration" is zero-valued, a one time poll of
353 the watcher information is achieved; otherwise, at the end of the
354 "duration", a terminate operation is sent.
356 Either the watcher or the service may cancel the request by sending a
357 terminate operation, e.g.,
359 +-------+ +-------+
360 | | -- data -------> | |
361 | appl. | | relay |
362 | | <--------- ok -- | |
363 +-------+ +-------+
365 C:
366
367
368
369
370
371
372 S:
374 +-------+ +-------+
375 | | <------- data -- | |
376 | relay | | pres. |
377 | | -- ok ---------> | svc. |
378 +-------+ +-------+
380 C:
381
382
383
384
385
386
387 S:
389 or
390 +-------+ +-------+
391 | | <------- data -- | |
392 | relay | | pres. |
393 | | -- ok ---------> | svc. |
394 +-------+ +-------+
396 C:
397
398
399
400
401
402
403 S:
405 3. Format of Presence Entries
407 Each administrative domain is responsible for maintaining a "presence
408 entry" for each of its endpoints (regardless of whether those
409 endpoints are currently attached to the relaying mesh).
411 Section 6 defines the syntax for presence entries. Each presence
412 entry has a "publisher" attribute, a "lastUpdate" attribute, a
413 "publisherInfo" attribute, and contains one or more "tuple" elements:
415 o the "publisher" attribute specifies the endpoint associated with
416 the presence entry;
418 o the "lastUpdate" attribute specifies the date and time that the
419 service last updated the presence entry;
421 o the "publisherInfo" attribute specifies arbitrary information
422 about the publisher (using a URI); and,
424 o each "tuple" element specifies information about an entity
425 associated with the endpoint.
427 Each "tuple" element has a "destination" attribute, an
428 "availableUntil" attribute, a "tupleInfo" attribute, and contains
429 zero or more "capability" elements:
431 o the "destination" attribute identifies the entity as a URI (e.g.,
432 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
434 o the "availableUntil" attribute specifies the latest date and time
435 that the entity is capable of receiving messages;
437 o the "tupleInfo" attribute specifies arbitrary information about
438 the entity (using a URI); and,
440 o each "capability" element contains a specification as to the kinds
441 of content the entity is capable of receiving.
443 Each "capability" element contains arbitrary character data formatted
444 according to the standard indicated in the element's "baseline"
445 attribute.
447 4. The Presence Service
449 Section 5 contains the APEX service registration for the presence
450 service:
452 o Within an administrative domain, the service is addressed using
453 the well-known endpoint of "apex=presence".
455 o Section 6 defines the syntax of the operations exchanged with the
456 service.
458 o A consumer of the service initiates communications by sending data
459 containing the subscribe, watch, or publish operation.
461 o In addition to replying to these operations, the service may also
462 initiate communications by sending data containing the terminate,
463 publish, or notify operations.
465 An implementation of the service must maintain information about both
466 presence entries and in-progress operations in persistent storage.
468 Consult Section 6.1.1 of [1] for a discussion on the properties of
469 long-lived transaction-identifiers.
471 4.1 Use of XML and MIME
473 Section 4.1 of [1] describes how arbitrary MIME content is exchanged
474 as a BEEP [2] payload. For example, to transmit:
476
477
478
479
481 where "..." refers to:
483 then the corresponding BEEP message might look like this:
485 C: MSG 1 1 . 42 1234
486 C: Content-Type: multipart/related; boundary="boundary";
487 C: start="<1@example.com>";
488 C: type="application/beep+xml"
489 C:
490 C: --boundary
491 C: Content-Type: application/beep+xml
492 C: Content-ID: <1@example.com>
493 C:
494 C:
495 C:
496 C:
497 C:
498 C: --boundary
499 C: Content-Type: application/beep+xml
500 C: Content-ID: <2@example.com>
501 C:
502 C:
503 C: --boundary--
504 C: END
506 or this:
508 C: MSG 1 1 . 42 1234
509 C: Content-Type: application/beep+xml
510 C:
511 C:
512 C:
513 C:
514 C:
515 C:
516 C:
517 C:
518 C: END
520 4.2 The Subscribe Operation
522 When an application wants to (periodically) receive the presence
523 entry associated with an endpoint, it sends a "subscribe" element to
524 the service.
526 The "subscribe" element has a "publisher" attribute, a "duration"
527 attribute, a "transID" attribute, and no content:
529 o the "publisher" attribute specifies the endpoint associated with
530 the presence entry;
532 o the "transID" attribute specifies the transaction-identifier
533 associated with this operation; and,
535 o the "duration" attribute specifies the maximum number of seconds
536 for which the originator is interested in receiving updated
537 presence information.
539 When the service receives a "subscribe" element, we refer to the
540 "publisher" attribute of that element as the "subject", and the
541 service performs these steps:
543 1. If the subject is outside of this administrative domain, a
544 "reply" element having code 553 is sent to the originator.
546 2. If the subject does not refer to a valid endpoint, a "reply"
547 element having code 550 is sent to the originator.
549 3. If the subject's access entry does not contain a
550 "presence:subscribe" token for the originator, a "reply" element
551 having code 537 is sent to the originator.
553 4. If the originator already has an in-progress subscribe operation
554 for the subject, then the previous subscribe operation is
555 silently terminated, and processing continues.
557 5. If the "transID" attribute refers to an in-progress subscribe or
558 watch operation for the originator, a "reply" element having code
559 555 is sent to the originator.
561 6. Otherwise:
563 1. A "publish" element, corresponding to the subject's presence
564 entry, is immediately sent to the originator.
566 2. For each endpoint currently watching subscribers to the
567 subject's presence information, a "notify" element is
568 immediately as sent (c.f., Step 6.3 of Section 4.6).
570 3. For up to the amount of time indicated by the "duration"
571 attribute of the "subscribe" element, if the subject's
572 presence entry changes, an updated "presence" element is sent
573 to the originator using the publish operation (Section 4.4).
574 Finally, when the amount of time indicated by the "duration"
575 attribute expires, a terminate operation (Section 4.5) is
576 sent to the originator.
578 Note that if the duration is zero-valued, then the subscribe
579 operation is making a one-time poll of the presence information.
580 Accordingly, Step 6.3 above does not occur.
582 Regardless of whether a "publish" or "reply" element is sent to the
583 originator, the "transID" attribute is identical to the value found
584 in the "subscribe" element sent by the originator.
586 4.3 The Watch Operation
588 When an application wants to (periodically) receive notices about
589 endpoints that are subscribed to receive presence information, it
590 sends a "watch" element to the service.
592 The "watch" element has a "publisher" attribute, a "duration"
593 attribute, a "transID" attribute, and no content:
595 o the "publisher" attribute specifies the endpoint associated with
596 the presence entry;
598 o the "transID" attribute specifies the transaction-identifier
599 associated with this operation; and,
601 o the "duration" attribute specifies the maximum number of seconds
602 for which the originator is interested in watching subscribers.
604 When the service receives a "watch" element, we refer to the
605 "publisher" attribute of that element as the "subject", and the
606 service performs these steps:
608 1. If the subject is outside of this administrative domain, a
609 "reply" element having code 553 is sent to the originator.
611 2. If the subject does not refer to a valid endpoint, a "reply"
612 element having code 550 is sent to the originator.
614 3. If the subject's access entry does not contain a "presence:watch"
615 token for the originator, a "reply" element having code 537 is
616 sent to the originator.
618 4. If the originator already has an in-progress watch operation for
619 the subject, then the previous watch operation is silently
620 terminated, and processing continues.
622 5. If the "transID" attribute refers to an in-progress subscribe or
623 watch operation for the originator, a "reply" element having code
624 555 is sent to the originator.
626 6. Otherwise:
628 1. A "reply" element having code 250 is sent to the originator.
630 2. For each endpoint currently subscribing to the subject's
631 presence information, a "notify" element is immediately sent
632 to the originator (c.f., Section 4.6). Finally, when the
633 amount of time indicated by the "duration" attribute expires,
634 a terminate operation (Section 4.5) is sent to the
635 originator.
637 3. For up to the amount of time indicated by the "duration"
638 attribute of the "watch" element, whenever a subscribe
639 operation succeeds, a "notify" element is sent to the
640 originator. Finally, when the amount of time indicated by
641 the "duration" attribute expires, the a terminate operation
642 (Section 4.5) is sent to the originator.
644 Note that if the duration is zero-valued, then the watch
645 operation is making a one-time poll of the presence information.
646 Accordingly, Step 6.3 above does not occur.
648 Regardless of whether a "notify" or "reply" element is sent to the
649 originator, the "transID" attribute is identical to the value found
650 in the "presence" element sent by the originator.
652 4.4 The Publish Operation
654 When an application wants to modify the presence entry associated
655 with an endpoint, it sends a "publish" element to the service. In
656 addition, the service sends a "publish" element to endpoints that
657 have subscribed to see presence information (c.f., Section 4.2).
659 The "publish" element has a "publisher" attribute, a "transID"
660 attribute, a "timeStamp" attribute, and contains a "presence"
661 element:
663 o the "publisher" attribute specifies the endpoint to be associated
664 with the presence entry;
666 o the "transID" attribute specifies the transaction-identifier
667 associated with this operation;
669 o the "timeStamp" attribute specifies the application's notion of
670 the current date and time; and,
672 o the "presence" element contains the desired presence entry for the
673 endpoint.
675 When the service sends a "publish" element, the "transID" attribute
676 specifies the transaction-identifier associated with the subscribe
677 operation that caused this "publish" element to be sent, and the
678 "timeStamp" attribute specifies the service's notion of the current
679 date and time. No reply is sent by the receiving endpoint.
681 When the service receives a "publish" element, we refer to the
682 "publisher" attribute of that element as the "subject", and the
683 service performs these steps:
685 1. If the "publisher" attribute of the "publish" element doesn't
686 match the "publisher" attribute of the "presence" element
687 contained in the "publish" element, a "reply" element having code
688 503 is sent to the originator.
690 2. If the subject is outside of this administrative domain, a
691 "reply" element having code 553 is sent to the originator.
693 3. If the subject does not refer to a valid endpoint, a "reply"
694 element having code 550 is sent to the originator.
696 4. If the subject's access entry does not contain a
697 "presence:publish" token for the originator, a "reply" element
698 having code 537 is sent to the originator.
700 5. If the "lastUpdate" attribute of the "publish" element is not
701 semantically identical to the "lastUpdate" attribute of the
702 subject's presence entry, a "reply" element having code 555 is
703 sent to the originator. (This allows a simple mechanism for
704 atomic updates.)
706 6. Otherwise:
708 1. The subject's presence entry is updated from the "publish"
709 element.
711 2. The "lastUpdate" attribute of the presence entry is set to
712 the service's notion of the current date and time.
714 3. A "reply" element having code 250 is sent to the originator.
716 When sending the "reply" element, the "transID" attribute is
717 identical to the value found in the "publish" element sent by the
718 originator.
720 4.5 The Terminate Operation
722 When an application no longer wishes to subscribe to presence
723 information or to watch endpoints that are subscribed to receive
724 presence information, it sends a "terminate" element to the service;
725 similarly, when the service no longer considers an application to be
726 subscribing or watching, a "terminate" element is sent to the
727 application.
729 The "terminate" element contains only a "transID" attribute that
730 specifies the transaction-identifier associated an in-progress
731 subscribe or watch operation. Section 9.1 of [1] defines the syntax
732 for the "terminate" element.
734 When the service receives a "terminate" element, it performs these
735 steps:
737 1. If the transaction-identifier does not refer to a previous
738 subscribe or watch operation for the originator, an "error"
739 element having code 550 is returned.
741 2. Otherwise, the previous subscribe or watch operation for the
742 originator is terminated, and a "reply" element having code 250
743 is sent to the originator.
745 Note that following a terminate operation, the originator may receive
746 further presence or watcher updates. Although the service will send
747 no further updates after processing a terminate operation and sending
748 the reply operation, earlier updates may be in transit.
750 4.6 The Notify Operation
752 The service sends a "notify" element to endpoints that are watching
753 other endpoints subscribed to presence information (c.f., Section
754 4.3).
756 The "notify" element has a "subscriber" attribute, a "transID"
757 attribute, and no content:
759 o the "subscriber" attribute specifies the endpoint that is
760 subscribed to presence information; and,
762 o the "transID" attribute specifies the transaction-identifier
763 associated with the watch operation that caused this "notify"
764 element to be sent. No reply is sent by the receiving endpoint.
766 4.7 The Reply Operation
768 While processing operations, the service may respond with a "reply"
769 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for
770 the syntax and semantics of the reply operation.
772 5. Registration: The Presence Service
774 Well-Known Endpoint: apex=presence
776 Syntax of Messages Exchanged: c.f., Section 6
778 Sequence of Messages Exchanged: c.f., Section 4
780 Access Control Tokens: presence:subscribe, presence:watch,
781 presence:publish
783 Contact Information: c.f., the "Authors' Addresses" section of this
784 memo
786 6. The Presence Service DTD
788
798
800 %APEXCORE;
802
831
832
837
838
843
844
845
850
851
855
859
860
866
867
873
874
875
878 7. Security Considerations
880 Consult Section [1]'s Section 11 for a discussion of security issues.
882 References
884 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
885 Core", draft-ietf-apex-core-00 (work in progress), February
886 2001.
888 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
889 3080, March 2001.
891 [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service",
892 draft-ietf-apex-access-00 (work in progress), December 2000.
894 [4] Allocchio, C., "GSTN Address Element Extensions in E-mail
895 Services", RFC 2846, June 2000.
897 Authors' Addresses
899 Marshall T. Rose
900 Invisible Worlds, Inc.
901 131 Stony Circle
902 Suite 500
903 Santa Rosa, CA 95401
904 US
906 Phone: +1 707 578 2350
907 EMail: mrose@invisible.net
908 URI: http://invisible.net/
910 Graham Klyne
911 Baltimore Technologies
912 1220 Parkview
913 Arlington Business Park
914 Theale, Reading RG7 4SA
915 UK
917 Phone: +44 118 930 1300
918 EMail: gk@acm.org
919 David H. Crocker
920 Brandenburg Consulting
921 675 Spruce Drive
922 Sunnyvale, CA 94086
923 US
925 Phone: +1 408 246 8253
926 EMail: dcrocker@brandenburg.com
927 URI: http://www.brandenburg.com/
929 Appendix A. Acknowledgements
931 The authors gratefully acknowledge the contributions of: Neil Cook,
932 Eric Dixon, Darren New, and Scott Pead.
934 Appendix B. Changes from IMXP
936 o s/IMXP/APEX/g
938 o Clarify the notion of co-residence for APEX services.
940 o Change data's originator from an attribute to an element.
942 o CPIM mapping moved to another document.
944 Full Copyright Statement
946 Copyright (C) The Internet Society (2001). All Rights Reserved.
948 This document and translations of it may be copied and furnished to
949 others, and derivative works that comment on or otherwise explain it
950 or assist in its implementation may be prepared, copied, published
951 and distributed, in whole or in part, without restriction of any
952 kind, provided that the above copyright notice and this paragraph are
953 included on all such copies and derivative works. However, this
954 document itself may not be modified in any way, such as by removing
955 the copyright notice or references to the Internet Society or other
956 Internet organizations, except as needed for the purpose of
957 developing Internet standards in which case the procedures for
958 copyrights defined in the Internet Standards process must be
959 followed, or as required to translate it into languages other than
960 English.
962 The limited permissions granted above are perpetual and will not be
963 revoked by the Internet Society or its successors or assigns.
965 This document and the information contained herein is provided on an
966 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
967 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
968 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
969 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
970 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
972 Acknowledgement
974 Funding for the RFC Editor function is currently provided by the
975 Internet Society.