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.