idnits 2.17.1
draft-mrose-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 808 has weird spacing: '...itiates ser...'
== Line 825 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 25, 2001) is 8454 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)
-- Possible downref: Normative reference to a draft: ref. '1'
-- Possible downref: Normative reference to a draft: ref. '3'
Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M.T. Rose
3 Internet-Draft Invisible Worlds, Inc.
4 Expires: August 26, 2001 G. Klyne
5 Content Technologies Limited
6 D.H. Crocker
7 Brandenburg Consulting
8 February 25, 2001
10 The APEX Presence Service
11 draft-mrose-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 other
20 groups may also distribute working documents as Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on August 26, 2001.
35 Copyright Notice
37 Copyright (C) The Internet Society (2001). All Rights Reserved.
39 Abstract
41 This memo describes the APEX presence service, addressed as the well-
42 known endpoint "apex=presence". The presence service is used to
43 manage presence information for APEX endpoints.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Management of Presence Information . . . . . . . . . . . . . . 4
49 2.1 Update of Presence Information . . . . . . . . . . . . . . . . 5
50 2.2 Distribution of Presence Information . . . . . . . . . . . . . 7
51 2.3 Distribution of Watcher Information . . . . . . . . . . . . . 10
52 3. Format of Presence Entries . . . . . . . . . . . . . . . . . . 13
53 4. The Presence Service . . . . . . . . . . . . . . . . . . . . . 14
54 4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 15
55 4.2 The Subscribe Operation . . . . . . . . . . . . . . . . . . . 16
56 4.3 The Watch Operation . . . . . . . . . . . . . . . . . . . . . 18
57 4.4 The Publish Operation . . . . . . . . . . . . . . . . . . . . 20
58 4.5 The Terminate Operation . . . . . . . . . . . . . . . . . . . 22
59 4.6 The Notify Operation . . . . . . . . . . . . . . . . . . . . . 23
60 4.7 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 23
61 5. Registration: The Presence Service . . . . . . . . . . . . . . 24
62 6. The Presence Service DTD . . . . . . . . . . . . . . . . . . . 25
63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
64 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
66 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
67 B. Changes from IMXP . . . . . . . . . . . . . . . . . . . . . . 31
68 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32
70 1. Introduction
72 This memo describes a presence service that is built upon the APEX[1]
73 "relaying mesh". The APEX presence service is used to manage presence
74 information for APEX endpoints.
76 APEX, at its core, provides a best-effort datagram service. Within an
77 administrative domain, all relays must be able to handle messages for
78 any endpoint within that domain. APEX services are logically defined
79 as endpoints but given their ubiquitous semantics they do not
80 necessarily need to be associated with a single physical endpoint. As
81 such, they may be provisioned co-resident with each relay within an
82 administrative domain, even though they are logically provided on top
83 of the relaying mesh, i.e.,
85 +----------+ +----------+ +----------+ +---------+
86 | APEX | | APEX | | APEX | | |
87 | access | | presence | | report | | ... |
88 | service | | service | | service | | |
89 +----------+ +----------+ +----------+ +---------+
90 | | | |
91 | | | |
92 +----------------------------------------------------------------+
93 | |
94 | APEX core |
95 | |
96 +----------------------------------------------------------------+
98 That is, applications communicate with an APEX service by exchanging
99 data with a "well-known endpoint" (WKE).
101 APEX applications communicate with the presence service by exchanging
102 data with the well-known endpoint "apex=presence" in the
103 corresponding administrative domain, e.g.,
104 "apex=presence@example.com" is the endpoint associated with the
105 presence service in the "example.com" administrative domain.
107 Note that within a single administrative domain, the presence service
108 makes use of the APEX access[3] service in order to determine if an
109 originator is allowed to view or manage presence information.
111 2. Management of Presence Information
113 Management of presence information falls into three categories:
115 o applications may update the presence entry associated with an
116 endpoint;
118 o applications may subscribe to receive presence information about
119 an endpoint; and,
121 o applications may find out who is subscribed to receive presence
122 information.
124 Each is now described in turn.
126 2.1 Update of Presence Information
128 When an application wants to modify the presence entry associated
129 with an endpoint, it sends a publish operation to the service, e.g.,
131 +-------+ +-------+
132 | | -- data -------> | |
133 | appl. | | relay |
134 | | <--------- ok -- | |
135 +-------+ +-------+
137 C:
138
139
140
141
143
146
149
151
152
153
154
155 S:
157 Note that this example uses the subaddress-specification convention
158 of RFC 2846[4] (e.g., "fred/appl=im") to denote multiplexing of
159 traffic for a particular endpoint. Of course, popular applications
160 may have their own URI method assigned to them (e.g.,
161 "im:fred@example.com").
163 The service immediately responds with a reply operation containing
164 the same transaction-identifier, e.g.,
166 +-------+ +-------+
167 | | <------- data -- | |
168 | relay | | pres. |
169 | | -- ok ---------> | svc. |
170 +-------+ +-------+
172 C:
173
174
175
176
177
178
179 S:
181 2.2 Distribution of Presence Information
183 When an application wants to (periodically) receive the presence
184 entry associated with an endpoint, it sends a subscribe operation to
185 the service, e.g.,
187 +-------+ +-------+
188 | | -- data -------> | |
189 | appl. | | relay |
190 | | <--------- ok -- | |
191 +-------+ +-------+
193 C:
194
195
196
197
199
200
201 S:
203 The service immediately responds with a publish operation containing
204 the same transaction-identifier, e.g.,
206 +-------+ +-------+
207 | | <------- data -- | |
208 | relay | | pres. |
209 | | -- ok ---------> | svc. |
210 +-------+ +-------+
212 C:
213
214
215
216
218
221
224
225
226
227
228 S:
230 Subsequently, for up to the specified "duration", the service sends
231 new publish operations whenever there are any changes to the
232 endpoint's presence information. If the "duration" is zero-valued, a
233 one time poll of the presence information is achieved; otherwise, at
234 the end of the "duration", a terminate operation is sent.
236 Note that Step 5 of Section 4.4 requires that the "lastUpdate"
237 attribute of a presence entry be supplied in order to update that
238 entry; accordingly, applications must successfully retrieve an
239 publish entry prior to trying to update that entry. This is usually
240 accomplished by subscribing with a zero-valued duration.
242 Either the subscriber or the service may cancel a subscription by
243 sending a terminate operation, e.g.,
245 +-------+ +-------+
246 | | -- data -------> | |
247 | appl. | | relay |
248 | | <--------- ok -- | |
249 +-------+ +-------+
251 C:
252
253
254
255
256
257
258 S:
260 +-------+ +-------+
261 | | <------- data -- | |
262 | relay | | pres. |
263 | | -- ok ---------> | svc. |
264 +-------+ +-------+
266 C:
267
268
269
270
271
272
273 S:
275 or
276 +-------+ +-------+
277 | | <------- data -- | |
278 | relay | | pres. |
279 | | -- ok ---------> | svc. |
280 +-------+ +-------+
282 C:
283
284
285
286
287
288
289 S:
291 2.3 Distribution of Watcher Information
293 When an application wants to (periodically) receive notices about
294 endpoints that are subscribed to receive presence information, it
295 sends a watch operation to the service, e.g.,
297 +-------+ +-------+
298 | | -- data -------> | |
299 | appl. | | relay |
300 | | <--------- ok -- | |
301 +-------+ +-------+
303 C:
304
305
306
307
309
310
311 S:
313 The service immediately responds with a reply operation containing
314 the same transaction-identifier, e.g.,
316 +-------+ +-------+
317 | | <------- data -- | |
318 | relay | | pres. |
319 | | -- ok ---------> | svc. |
320 +-------+ +-------+
322 C:
323
324
325
327
328
329 S:
331 For each current subscriber, the service immediately sends a notify
332 operation containing the same transaction-identifier, e.g.,
334 +-------+ +-------+
335 | | <------- data -- | |
336 | relay | | pres. |
337 | | -- ok ---------> | svc. |
338 +-------+ +-------+
340 C:
341
342
343
344
345
346
347 S:
349 Subsequently, for up to the specified "duration", the service sends
350 new notify operations whenever an application subscribes
351 successfully. If the "duration" is zero-valued, a one time poll of
352 the watcher information is achieved; otherwise, at the end of the
353 "duration", a terminate operation is sent.
355 Either the watcher or the service may cancel the request by sending a
356 terminate operation, e.g.,
358 +-------+ +-------+
359 | | -- data -------> | |
360 | appl. | | relay |
361 | | <--------- ok -- | |
362 +-------+ +-------+
364 C:
365
366
367
368
369
370
371 S:
373 +-------+ +-------+
374 | | <------- data -- | |
375 | relay | | pres. |
376 | | -- ok ---------> | svc. |
377 +-------+ +-------+
379 C:
380
381
382
383
384
385
386 S:
388 or
389 +-------+ +-------+
390 | | <------- data -- | |
391 | relay | | pres. |
392 | | -- ok ---------> | svc. |
393 +-------+ +-------+
395 C:
396
397
398
399
400
401
402 S:
404 3. Format of Presence Entries
406 Each administrative domain is responsible for maintaining a "presence
407 entry" for each of its endpoints (regardless of whether those
408 endpoints are currently attached to the relaying mesh).
410 Section 6 defines the syntax for presence entries. Each presence
411 entry has a "publisher" attribute, a "lastUpdate" attribute, a
412 "publisherInfo" attribute, and contains one or more "tuple" elements:
414 o the "publisher" attribute specifies the endpoint associated with
415 the presence entry;
417 o the "lastUpdate" attribute specifies the date and time that the
418 service last updated the presence entry;
420 o the "publisherInfo" attribute specifies arbitrary information
421 about the publisher (using a URI); and,
423 o each "tuple" element specifies information about an entity
424 associated with the endpoint.
426 Each "tuple" element has a "destination" attribute, an
427 "availableUntil" attribute, a "tupleInfo" attribute, and contains
428 zero or more "capability" elements:
430 o the "destination" attribute identifies the entity as a URI (e.g.,
431 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
433 o the "availableUntil" attribute specifies the latest date and time
434 that the entity is capable of receiving messages;
436 o the "tupleInfo" attribute specifies arbitrary information about
437 the entity (using a URI); and,
439 o each "capability" element contains a specification as to the kinds
440 of content the entity is capable of receiving.
442 Each "capability" element contains arbitrary character data formatted
443 according to the standard indicated in the element's "baseline"
444 attribute.
446 4. The Presence Service
448 Section 5 contains the APEX service registration for the presence
449 service:
451 o Within an administrative domain, the service is addressed using
452 the well-known endpoint of "apex=presence".
454 o Section 6 defines the syntax of the operations exchanged with the
455 service.
457 o A consumer of the service initiates communications by sending data
458 containing the subscribe, watch, or publish operation.
460 o In addition to replying to these operations, the service may also
461 initiate communications by sending data containing the terminate,
462 publish, or notify operations.
464 An implementation of the service must maintain information about both
465 presence entries and in-progress operations in persistent storage.
467 Consult Section 6.1.1 of [1] for a discussion on the properties of
468 long-lived transaction-identifiers.
470 4.1 Use of XML and MIME
472 Section 4.1 of [1] describes how arbitrary MIME content is exchanged
473 as a BEEP[2] payload. For example, to transmit:
475
476
477
478
480 where "..." refers to:
482 then the corresponding BEEP message might look like this:
484 C: MSG 1 1 . 42 1234
485 C: Content-Type: multipart/related; boundary="boundary";
486 C: start="<1@example.com>";
487 C: type="application/beep+xml"
488 C:
489 C: --boundary
490 C: Content-Type: application/beep+xml
491 C: Content-ID: <1@example.com>
492 C:
493 C:
494 C:
495 C:
496 C:
497 C: --boundary
498 C: Content-Type: application/beep+xml
499 C: Content-ID: <2@example.com>
500 C:
501 C:
502 C: --boundary--
503 C: END
505 or this:
507 C: MSG 1 1 . 42 1234
508 C: Content-Type: application/beep+xml
509 C:
510 C:
511 C:
512 C:
513 C:
514 C:
515 C:
516 C:
517 C: END
519 4.2 The Subscribe Operation
521 When an application wants to (periodically) receive the presence
522 entry associated with an endpoint, it sends a "subscribe" element to
523 the service.
525 The "subscribe" element has a "publisher" attribute, a "duration"
526 attribute, a "transID" attribute, and no content:
528 o the "publisher" attribute specifies the endpoint associated with
529 the presence entry;
531 o the "transID" attribute specifies the transaction-identifier
532 associated with this operation; and,
534 o the "duration" attribute specifies the maximum number of seconds
535 for which the originator is interested in receiving updated
536 presence information.
538 When the service receives a "subscribe" element, we refer to the
539 "publisher" attribute of that element as the "subject", and the
540 service performs these steps:
542 1. If the subject is outside of this administrative domain, a
543 "reply" element having code 553 is sent to the originator.
545 2. If the subject does not refer to a valid endpoint, a "reply"
546 element having code 550 is sent to the originator.
548 3. If the subject's access entry does not contain a
549 "presence:subscribe" token for the originator, a "reply" element
550 having code 537 is sent to the originator.
552 4. If the originator already has an in-progress subscribe operation
553 for the subject, then the previous subscribe operation is
554 silently terminated, and processing continues.
556 5. If the "transID" attribute refers to an in-progress subscribe or
557 watch operation for the originator, a "reply" element having code
558 555 is sent to the originator.
560 6. Otherwise:
562 1. A "publish" element, corresponding to the subject's presence
563 entry, is immediately sent to the originator.
565 2. For each endpoint currently watching subscribers to the
566 subject's presence information, a "notify" element is
567 immediately as sent (c.f., Step 6.3 of Section 4.6).
569 3. For up to the amount of time indicated by the "duration"
570 attribute of the "subscribe" element, if the subject's
571 presence entry changes, an updated "presence" element is sent
572 to the originator using the publish operation (Section 4.4).
573 Finally, when the amount of time indicated by the "duration"
574 attribute expires, a terminate operation (Section 4.5) is
575 sent to the originator.
577 Note that if the duration is zero-valued, then the subscribe
578 operation is making a one-time poll of the presence information.
579 Accordingly, Step 6.3 above does not occur.
581 Regardless of whether a "publish" or "reply" element is sent to the
582 originator, the "transID" attribute is identical to the value found
583 in the "subscribe" element sent by the originator.
585 4.3 The Watch Operation
587 When an application wants to (periodically) receive notices about
588 endpoints that are subscribed to receive presence information, it
589 sends a "watch" element to the service.
591 The "watch" element has a "publisher" attribute, a "duration"
592 attribute, a "transID" attribute, and no content:
594 o the "publisher" attribute specifies the endpoint associated with
595 the presence entry;
597 o the "transID" attribute specifies the transaction-identifier
598 associated with this operation; and,
600 o the "duration" attribute specifies the maximum number of seconds
601 for which the originator is interested in watching subscribers.
603 When the service receives a "watch" element, we refer to the
604 "publisher" attribute of that element as the "subject", and the
605 service performs these steps:
607 1. If the subject is outside of this administrative domain, a
608 "reply" element having code 553 is sent to the originator.
610 2. If the subject does not refer to a valid endpoint, a "reply"
611 element having code 550 is sent to the originator.
613 3. If the subject's access entry does not contain a "presence:watch"
614 token for the originator, a "reply" element having code 537 is
615 sent to the originator.
617 4. If the originator already has an in-progress watch operation for
618 the subject, then the previous watch operation is silently
619 terminated, and processing continues.
621 5. If the "transID" attribute refers to an in-progress subscribe or
622 watch operation for the originator, a "reply" element having code
623 555 is sent to the originator.
625 6. Otherwise:
627 1. A "reply" element having code 250 is sent to the originator.
629 2. For each endpoint currently subscribing to the subject's
630 presence information, a "notify" element is immediately sent
631 to the originator (c.f., Section 4.6). Finally, when the
632 amount of time indicated by the "duration" attribute expires,
633 a terminate operation (Section 4.5) is sent to the
634 originator.
636 3. For up to the amount of time indicated by the "duration"
637 attribute of the "watch" element, whenever a subscribe
638 operation succeeds, a "notify" element is sent to the
639 originator. Finally, when the amount of time indicated by the
640 "duration" attribute expires, the a terminate operation
641 (Section 4.5) is sent to the originator.
643 Note that if the duration is zero-valued, then the watch
644 operation is making a one-time poll of the presence information.
645 Accordingly, Step 6.3 above does not occur.
647 Regardless of whether a "notify" or "reply" element is sent to the
648 originator, the "transID" attribute is identical to the value found
649 in the "presence" element sent by the originator.
651 4.4 The Publish Operation
653 When an application wants to modify the presence entry associated
654 with an endpoint, it sends a "publish" element to the service. In
655 addition, the service sends a "publish" element to endpoints that
656 have subscribed to see presence information (c.f., Section 4.2).
658 The "publish" element has a "publisher" attribute, a "transID"
659 attribute, a "timeStamp" attribute, and contains a "presence"
660 element:
662 o the "publisher" attribute specifies the endpoint to be associated
663 with the presence entry;
665 o the "transID" attribute specifies the transaction-identifier
666 associated with this operation;
668 o the "timeStamp" attribute specifies the application's notion of
669 the current date and time; and,
671 o the "presence" element contains the desired presence entry for the
672 endpoint.
674 When the service sends a "publish" element, the "transID" attribute
675 specifies the transaction-identifier associated with the subscribe
676 operation that caused this "publish" element to be sent, and the
677 "timeStamp" attribute specifies the service's notion of the current
678 date and time. No reply is sent by the receiving endpoint.
680 When the service receives a "publish" element, we refer to the
681 "publisher" attribute of that element as the "subject", and the
682 service performs these steps:
684 1. If the "publisher" attribute of the "publish" element doesn't
685 match the "publisher" attribute of the "presence" element
686 contained in the "publish" element, a "reply" element having code
687 503 is sent to the originator.
689 2. If the subject is outside of this administrative domain, a
690 "reply" element having code 553 is sent to the originator.
692 3. If the subject does not refer to a valid endpoint, a "reply"
693 element having code 550 is sent to the originator.
695 4. If the subject's access entry does not contain a
696 "presence:publish" token for the originator, a "reply" element
697 having code 537 is sent to the originator.
699 5. If the "lastUpdate" attribute of the "publish" element is not
700 semantically identical to the "lastUpdate" attribute of the
701 subject's presence entry, a "reply" element having code 555 is
702 sent to the originator. (This allows a simple mechanism for
703 atomic updates.)
705 6. Otherwise:
707 1. The subject's presence entry is updated from the "publish"
708 element.
710 2. The "lastUpdate" attribute of the presence entry is set to
711 the service's notion of the current date and time.
713 3. A "reply" element having code 250 is sent to the originator.
715 When sending the "reply" element, the "transID" attribute is
716 identical to the value found in the "publish" element sent by the
717 originator.
719 4.5 The Terminate Operation
721 When an application no longer wishes to subscribe to presence
722 information or to watch endpoints that are subscribed to receive
723 presence information, it sends a "terminate" element to the service;
724 similarly, when the service no longer considers an application to be
725 subscribing or watching, a "terminate" element is sent to the
726 application.
728 The "terminate" element contains only a "transID" attribute that
729 specifies the transaction-identifier associated an in-progress
730 subscribe or watch operation. Section 9.1 of [1] defines the syntax
731 for the "terminate" element.
733 When the service receives a "terminate" element, it performs these
734 steps:
736 1. If the transaction-identifier does not refer to a previous
737 subscribe or watch operation for the originator, an "error"
738 element having code 550 is returned.
740 2. Otherwise, the previous subscribe or watch operation for the
741 originator is terminated, and a "reply" element having code 250
742 is sent to the originator.
744 Note that following a terminate operation, the originator may receive
745 further presence or watcher updates. Although the service will send
746 no further updates after processing a terminate operation and sending
747 the reply operation, earlier updates may be in transit.
749 4.6 The Notify Operation
751 The service sends a "notify" element to endpoints that are watching
752 other endpoints subscribed to presence information (c.f., Section
753 4.3).
755 The "notify" element has a "subscriber" attribute, a "transID"
756 attribute, and no content:
758 o the "subscriber" attribute specifies the endpoint that is
759 subscribed to presence information; and,
761 o the "transID" attribute specifies the transaction-identifier
762 associated with the watch operation that caused this "notify"
763 element to be sent. No reply is sent by the receiving endpoint.
765 4.7 The Reply Operation
767 While processing operations, the service may respond with a "reply"
768 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for
769 the syntax and semantics of the reply operation.
771 5. Registration: The Presence Service
773 Well-Known Endpoint: apex=presence
775 Syntax of Messages Exchanged: c.f., Section 6
777 Sequence of Messages Exchanged: c.f., Section 4
779 Access Control Tokens: presence:subscribe, presence:watch,
780 presence:publish
782 Contact Information: c.f., the "Authors' Addresses" section of this
783 memo
785 6. The Presence Service DTD
787
797
799 %APEXCORE;
801
830
831
836
837
842
843
844
849
850
854
858
859
865
866
872
873
874
877 7. Security Considerations
879 Consult Section [1]'s Section 11 for a discussion of security issues.
881 References
883 [1] Rose, M.T., Klyne, G. and D.H. Crocker, "The Application
884 Exchange Core", draft-mrose-apex-core-03 (work in progress),
885 February 2001.
887 [2] Rose, M.T., "The Blocks Extensible Exchange Protocol Core",
888 draft-ietf-beep-framework-11 (work in progress), January 2001.
890 [3] Rose, M.T., Klyne, G. and D.H. Crocker, "The APEX Access
891 Service", draft-mrose-apex-access-02 (work in progress),
892 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 1179 North McDowell Boulevard
902 Petaluma, CA 94954-6559
903 US
905 Phone: +1 707 789 3700
906 EMail: mrose@invisible.net
907 URI: http://invisible.net/
909 Graham Klyne
910 Content Technologies Limited
911 1220 Parkview
912 Arlington Business Park
913 Theale, Reading RG7 4SA
914 UK
916 Phone: +44 118 930 1300
917 EMail: gk@acm.org
918 David H. Crocker
919 Brandenburg Consulting
920 675 Spruce Drive
921 Sunnyvale, CA 94086
922 US
924 Phone: +1 408 246 8253
925 EMail: dcrocker@brandenburg.com
926 URI: http://www.brandenburg.com/
928 Appendix A. Acknowledgements
930 The authors gratefully acknowledge the contributions of: Neil Cook,
931 Eric Dixon, Darren New, and Scott Pead.
933 Appendix B. Changes from IMXP
935 o s/IMXP/APEX/g
937 o Clarify the notion of co-residence for APEX services.
939 o Change data's originator from an attribute to an element.
941 o CPIM mapping moved to another document.
943 Full Copyright Statement
945 Copyright (C) The Internet Society (2001). All Rights Reserved.
947 This document and translations of it may be copied and furnished to
948 others, and derivative works that comment on or otherwise explain it
949 or assist in its implementation may be prepared, copied, published
950 and distributed, in whole or in part, without restriction of any
951 kind, provided that the above copyright notice and this paragraph are
952 included on all such copies and derivative works. However, this
953 document itself may not be modified in any way, such as by removing
954 the copyright notice or references to the Internet Society or other
955 Internet organizations, except as needed for the purpose of
956 developing Internet standards in which case the procedures for
957 copyrights defined in the Internet Standards process must be
958 followed, or as required to translate it into languages other than
959 English.
961 The limited permissions granted above are perpetual and will not be
962 revoked by the Internet Society or its successors or assigns.
964 This document and the information contained herein is provided on an
965 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
966 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
967 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
968 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
969 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
971 Acknowledgement
973 Funding for the RFC Editor function is currently provided by the
974 Internet Society.