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.