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