idnits 2.17.1 draft-ietf-apex-presence-04.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 822 has weird spacing: '...itiates ser...' == Line 839 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 (July 9, 2001) is 8326 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-04 ** 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-06 ** 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: January 7, 2002 G. Klyne 5 Baltimore Technologies 6 D. Crocker 7 Brandenburg Consulting 8 July 9, 2001 10 The APEX Presence Service 11 draft-ietf-apex-presence-04 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 January 7, 2002. 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-03 . . . . . . . . . . . 31 70 B.2 Changes from draft-ietf-apex-presence-02 . . . . . . . . . . . 31 71 B.3 Changes from draft-ietf-apex-presence-01 . . . . . . . . . . . 31 72 B.4 Changes from draft-ietf-apex-presence-00 . . . . . . . . . . . 31 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32 75 1. Introduction 77 This memo describes a presence service that is built upon the APEX 78 [1] "relaying mesh". The APEX presence service is used to manage 79 presence information for APEX endpoints. 81 APEX, at its core, provides a best-effort datagram service. Within 82 an administrative domain, all relays must be able to handle messages 83 for any endpoint within that domain. APEX services are logically 84 defined as endpoints but given their ubiquitous semantics they do not 85 necessarily need to be associated with a single physical endpoint. 86 As such, they may be provisioned co-resident with each relay within 87 an administrative domain, even though they are logically provided on 88 top of the relaying mesh, i.e., 90 +----------+ +----------+ +----------+ +---------+ 91 | APEX | | APEX | | APEX | | | 92 | access | | presence | | report | | ... | 93 | service | | service | | service | | | 94 +----------+ +----------+ +----------+ +---------+ 95 | | | | 96 | | | | 97 +----------------------------------------------------------------+ 98 | | 99 | APEX core | 100 | | 101 +----------------------------------------------------------------+ 103 That is, applications communicate with an APEX service by exchanging 104 data with a "well-known endpoint" (WKE). 106 APEX applications communicate with the presence service by exchanging 107 data with the well-known endpoint "apex=presence" in the 108 corresponding administrative domain, e.g., 109 "apex=presence@example.com" is the endpoint associated with the 110 presence service in the "example.com" administrative domain. 112 Note that within a single administrative domain, the presence service 113 makes use of the APEX access [3] service in order to determine if an 114 originator is allowed to view or manage presence information. 116 2. Management of Presence Information 118 Management of presence information falls into three categories: 120 o applications may update the presence information associated with 121 an endpoint; 123 o applications may subscribe to receive presence information 124 associated with an endpoint; and, 126 o applications may find out who is subscribed to receive presence 127 information. 129 Each is now described in turn. 131 2.1 Update of Presence Information 133 When an application wants to modify the presence information 134 associated with an endpoint, it sends a publish operation to the 135 service, e.g., 137 +-------+ +-------+ 138 | | -- data -------> | | 139 | appl. | | relay | 140 | | <--------- ok -- | | 141 +-------+ +-------+ 143 C: 144 145 146 147 149 152 155 157 158 159 160 161 S: 163 Note that this example uses the "subaddress" convention specified in 164 Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of 165 traffic for a particular endpoint. Of course, popular applications 166 may have their own URI method assigned to them (e.g., 167 "im:fred@example.com"). 169 The service immediately responds with a reply operation containing 170 the same transaction-identifier, e.g., 172 +-------+ +-------+ 173 | | <------- data -- | | 174 | relay | | pres. | 175 | | -- ok ---------> | svc. | 176 +-------+ +-------+ 178 C: 179 180 181 182 183 184 185 S: 187 2.2 Distribution of Presence Information 189 When an application wants to (periodically) receive the presence 190 information associated with an endpoint, it sends a subscribe 191 operation to the service, e.g., 193 +-------+ +-------+ 194 | | -- data -------> | | 195 | appl. | | relay | 196 | | <--------- ok -- | | 197 +-------+ +-------+ 199 C: 200 201 202 203 205 206 207 S: 209 The service immediately responds with a publish operation containing 210 the same transaction-identifier, e.g., 212 +-------+ +-------+ 213 | | <------- data -- | | 214 | relay | | pres. | 215 | | -- ok ---------> | svc. | 216 +-------+ +-------+ 218 C: 219 220 221 222 224 227 230 231 232 233 234 S: 236 Subsequently, for up to the specified "duration", the service sends 237 new publish operations whenever there are any changes to the 238 endpoint's presence information. If the "duration" is zero-valued, a 239 one time poll of the presence information is achieved; otherwise, at 240 the end of the "duration", a terminate operation is sent. 242 Note that Step 5 of Section 4.4 requires that the "lastUpdate" 243 attribute of a presence entry be supplied in order to update that 244 entry; accordingly, applications must successfully retrieve an 245 publish entry prior to trying to update that entry. This is usually 246 accomplished by subscribing with a zero-valued duration. 248 Either the subscriber or the service may cancel a subscription by 249 sending a terminate operation, e.g., 251 +-------+ +-------+ 252 | | -- data -------> | | 253 | appl. | | relay | 254 | | <--------- ok -- | | 255 +-------+ +-------+ 257 C: 258 259 260 261 262 263 264 S: 266 +-------+ +-------+ 267 | | <------- data -- | | 268 | relay | | pres. | 269 | | -- ok ---------> | svc. | 270 +-------+ +-------+ 272 C: 273 274 275 276 277 278 279 S: 281 or 282 +-------+ +-------+ 283 | | <------- data -- | | 284 | relay | | pres. | 285 | | -- ok ---------> | svc. | 286 +-------+ +-------+ 288 C: 289 290 291 292 293 294 295 S: 297 2.3 Distribution of Watcher Information 299 When an application wants to (periodically) receive notices about 300 endpoints that are subscribed to receive presence information, it 301 sends a watch operation to the service, e.g., 303 +-------+ +-------+ 304 | | -- data -------> | | 305 | appl. | | relay | 306 | | <--------- ok -- | | 307 +-------+ +-------+ 309 C: 310 311 312 313 315 316 317 S: 319 The service immediately responds with a reply operation containing 320 the same transaction-identifier, e.g., 322 +-------+ +-------+ 323 | | <------- data -- | | 324 | relay | | pres. | 325 | | -- ok ---------> | svc. | 326 +-------+ +-------+ 328 C: 329 330 331 333 334 335 S: 337 For each current subscriber, the service immediately sends a notify 338 operation containing the same transaction-identifier, e.g., 340 +-------+ +-------+ 341 | | <------- data -- | | 342 | relay | | pres. | 343 | | -- ok ---------> | svc. | 344 +-------+ +-------+ 346 C: 347 348 349 350 352 353 354 S: 356 Subsequently, for up to the specified "duration", the service sends 357 new notify operations whenever an application subscribes successfully 358 or a subscription is terminated. If the "duration" is zero-valued, a 359 one time poll of the watcher information is achieved; otherwise, at 360 the end of the "duration", a terminate operation is sent. 362 Either the watcher or the service may cancel the request by sending a 363 terminate operation, e.g., 365 +-------+ +-------+ 366 | | -- data -------> | | 367 | appl. | | relay | 368 | | <--------- ok -- | | 369 +-------+ +-------+ 371 C: 372 373 374 375 376 377 378 S: 380 +-------+ +-------+ 381 | | <------- data -- | | 382 | relay | | pres. | 383 | | -- ok ---------> | svc. | 384 +-------+ +-------+ 386 C: 387 388 389 390 391 392 393 S: 395 or 396 +-------+ +-------+ 397 | | <------- data -- | | 398 | relay | | pres. | 399 | | -- ok ---------> | svc. | 400 +-------+ +-------+ 402 C: 403 404 405 406 407 408 409 S: 411 3. Format of Presence Entries 413 Each administrative domain is responsible for maintaining a "presence 414 entry" for each of its endpoints (regardless of whether those 415 endpoints are currently attached to the relaying mesh). 417 Section 6 defines the syntax for presence entries. Each presence 418 entry has a "publisher" attribute, a "lastUpdate" attribute, a 419 "publisherInfo" attribute, and contains one or more "tuple" elements: 421 o the "publisher" attribute specifies the endpoint associated with 422 the presence entry; 424 o the "lastUpdate" attribute specifies the date and time that the 425 service last updated the presence entry; 427 o the "publisherInfo" attribute specifies arbitrary information 428 about the publisher (using a URI); and, 430 o each "tuple" element specifies information about an entity 431 associated with the endpoint. 433 Each "tuple" element has a "destination" attribute, an 434 "availableUntil" attribute, a "tupleInfo" attribute, and contains 435 zero or more "capability" elements: 437 o the "destination" attribute identifies the entity as a URI (e.g., 438 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com"); 440 o the "availableUntil" attribute specifies the latest date and time 441 that the entity is capable of receiving messages; 443 o the "tupleInfo" attribute specifies arbitrary information about 444 the entity (using a URI); and, 446 o each "capability" element contains a specification as to the kinds 447 of content the entity is capable of receiving. 449 Each "capability" element contains arbitrary character data formatted 450 according to the standard indicated in the element's "baseline" 451 attribute. 453 4. The Presence Service 455 Section 5 contains the APEX service registration for the presence 456 service: 458 o Within an administrative domain, the service is addressed using 459 the well-known endpoint of "apex=presence". 461 o Section 6 defines the syntax of the operations exchanged with the 462 service. 464 o A consumer of the service initiates communications by sending data 465 containing the subscribe, watch, or publish operation. 467 o In addition to replying to these operations, the service may also 468 initiate communications by sending data containing the terminate, 469 publish, or notify operations. 471 An implementation of the service must maintain information about both 472 presence entries and in-progress operations in persistent storage. 474 Consult Section 6.1.1 of [1] for a discussion on the properties of 475 long-lived transaction-identifiers. 477 4.1 Use of XML and MIME 479 Section 4.1 of [1] describes how arbitrary MIME content is exchanged 480 as a BEEP [2] payload. For example, to transmit: 482 483 484 485 487 where "..." refers to: 489 then the corresponding BEEP message might look like this: 491 C: MSG 1 1 . 42 1234 492 C: Content-Type: multipart/related; boundary="boundary"; 493 C: start="<1@example.com>"; 494 C: type="application/beep+xml" 495 C: 496 C: --boundary 497 C: Content-Type: application/beep+xml 498 C: Content-ID: <1@example.com> 499 C: 500 C: 501 C: 502 C: 503 C: 504 C: --boundary 505 C: Content-Type: application/beep+xml 506 C: Content-ID: <2@example.com> 507 C: 508 C: 509 C: --boundary-- 510 C: END 512 or this: 514 C: MSG 1 1 . 42 1234 515 C: Content-Type: application/beep+xml 516 C: 517 C: 518 C: 519 C: 520 C: 521 C: 522 C: 523 C: 524 C: END 526 4.2 The Subscribe Operation 528 When an application wants to (periodically) receive the presence 529 information associated with an endpoint, it sends a "subscribe" 530 element to the service. 532 The "subscribe" element has a "publisher" attribute, a "duration" 533 attribute, a "transID" attribute, and no content: 535 o the "publisher" attribute specifies the endpoint associated with 536 the presence entry; 538 o the "transID" attribute specifies the transaction-identifier 539 associated with this operation; and, 541 o the "duration" attribute specifies the maximum number of seconds 542 for which the originator is interested in receiving updated 543 presence information. 545 When the service receives a "subscribe" element, we refer to the 546 "publisher" attribute of that element as the "subject", and the 547 service performs these steps: 549 1. If the subject is outside of this administrative domain, a 550 "reply" element having code 553 is sent to the originator. 552 2. If the subject does not refer to a valid endpoint, a "reply" 553 element having code 550 is sent to the originator. 555 3. If the subject's access entry does not contain a 556 "presence:subscribe" token for the originator, a "reply" element 557 having code 537 is sent to the originator. 559 4. If the originator already has an in-progress subscribe operation 560 for the subject, then the previous subscribe operation is 561 silently terminated, and processing continues. 563 5. If the "transID" attribute refers to an in-progress subscribe or 564 watch operation for the originator, a "reply" element having code 565 555 is sent to the originator. 567 6. Otherwise: 569 1. A "publish" element, corresponding to the subject's presence 570 entry, is immediately sent to the originator. 572 2. For each endpoint currently watching subscribers to the 573 subject's presence information, a "notify" element is 574 immediately as sent (c.f., Step 6.3 of Section 4.6). 576 3. For up to the amount of time indicated by the "duration" 577 attribute of the "subscribe" element, if the subject's 578 presence entry changes, an updated "presence" element is sent 579 to the originator using the publish operation (Section 4.4). 580 Finally, when the amount of time indicated by the "duration" 581 attribute expires, a terminate operation (Section 4.5) is 582 sent to the originator. 584 Note that if the duration is zero-valued, then the subscribe 585 operation is making a one-time poll of the presence information. 586 Accordingly, Step 6.3 above does not occur. 588 Regardless of whether a "publish" or "reply" element is sent to the 589 originator, the "transID" attribute is identical to the value found 590 in the "subscribe" element sent by the originator. 592 4.3 The Watch Operation 594 When an application wants to (periodically) receive notices about 595 endpoints that are subscribed to receive presence entry, it sends a 596 "watch" element to the service. 598 The "watch" element has a "publisher" attribute, a "duration" 599 attribute, a "transID" attribute, and no content: 601 o the "publisher" attribute specifies the endpoint associated with 602 the presence entry; 604 o the "transID" attribute specifies the transaction-identifier 605 associated with this operation; and, 607 o the "duration" attribute specifies the maximum number of seconds 608 for which the originator is interested in watching subscribers. 610 When the service receives a "watch" element, we refer to the 611 "publisher" attribute of that element as the "subject", and the 612 service performs these steps: 614 1. If the subject is outside of this administrative domain, a 615 "reply" element having code 553 is sent to the originator. 617 2. If the subject does not refer to a valid endpoint, a "reply" 618 element having code 550 is sent to the originator. 620 3. If the subject's access entry does not contain a "presence:watch" 621 token for the originator, a "reply" element having code 537 is 622 sent to the originator. 624 4. If the originator already has an in-progress watch operation for 625 the subject, then the previous watch operation is silently 626 terminated, and processing continues. 628 5. If the "transID" attribute refers to an in-progress subscribe or 629 watch operation for the originator, a "reply" element having code 630 555 is sent to the originator. 632 6. Otherwise: 634 1. A "reply" element having code 250 is sent to the originator. 636 2. For each endpoint currently subscribing to the subject's 637 presence information, a "notify" element is immediately sent 638 to the originator (c.f., Section 4.6). 640 3. For up to the amount of time indicated by the "duration" 641 attribute of the "watch" element, whenever a subscribe 642 operation succeeds or a subscription is terminated, a 643 "notify" element is sent to the originator. Finally, when 644 the amount of time indicated by the "duration" attribute 645 expires, a terminate operation (Section 4.5) is sent to the 646 originator. 648 Note that if the duration is zero-valued, then the watch 649 operation is making a one-time poll of the presence information. 650 Accordingly, Step 6.3 above does not occur. 652 Regardless of whether a "notify" or "reply" element is sent to the 653 originator, the "transID" attribute is identical to the value found 654 in the "presence" element sent by the originator. 656 4.4 The Publish Operation 658 When an application wants to modify the presence entry associated 659 with an endpoint, it sends a "publish" element to the service. In 660 addition, the service sends a "publish" element to endpoints that 661 have subscribed to see presence information (c.f., Section 4.2). 663 The "publish" element has a "publisher" attribute, a "transID" 664 attribute, a "timeStamp" attribute, and contains a "presence" 665 element: 667 o the "publisher" attribute specifies the endpoint to be associated 668 with the presence entry; 670 o the "transID" attribute specifies the transaction-identifier 671 associated with this operation; 673 o the "timeStamp" attribute specifies the application's notion of 674 the current date and time; and, 676 o the "presence" element contains the desired presence entry for the 677 endpoint. 679 When the service sends a "publish" element, the "transID" attribute 680 specifies the transaction-identifier associated with the subscribe 681 operation that caused this "publish" element to be sent, and the 682 "timeStamp" attribute specifies the service's notion of the current 683 date and time. No reply is sent by the receiving endpoint. 685 When the service receives a "publish" element, we refer to the 686 "publisher" attribute of that element as the "subject", and the 687 service performs these steps: 689 1. If the "publisher" attribute of the "publish" element doesn't 690 match the "publisher" attribute of the "presence" element 691 contained in the "publish" element, a "reply" element having code 692 503 is sent to the originator. 694 2. If the subject is outside of this administrative domain, a 695 "reply" element having code 553 is sent to the originator. 697 3. If the subject does not refer to a valid endpoint, a "reply" 698 element having code 550 is sent to the originator. 700 4. If the subject's access entry does not contain a 701 "presence:publish" token for the originator, a "reply" element 702 having code 537 is sent to the originator. 704 5. If the "lastUpdate" attribute of the "publish" element is not 705 semantically identical to the "lastUpdate" attribute of the 706 subject's presence entry, a "reply" element having code 555 is 707 sent to the originator. (This allows a simple mechanism for 708 atomic updates.) 710 6. Otherwise: 712 1. The subject's presence entry is updated from the "publish" 713 element. 715 2. The "lastUpdate" attribute of the presence entry is set to 716 the service's notion of the current date and time. 718 3. A "reply" element having code 250 is sent to the originator. 720 When sending the "reply" element, the "transID" attribute is 721 identical to the value found in the "publish" element sent by the 722 originator. 724 4.5 The Terminate Operation 726 When an application no longer wishes to subscribe to presence 727 information or to watch endpoints that are subscribed to receive 728 presence information, it sends a "terminate" element to the service; 729 similarly, when the service no longer considers an application to be 730 subscribing or watching, a "terminate" element is sent to the 731 application. 733 The "terminate" element contains only a "transID" attribute that 734 specifies the transaction-identifier associated an in-progress 735 subscribe or watch operation. Section 9.1 of [1] defines the syntax 736 for the "terminate" element. 738 When the service receives a "terminate" element, it performs these 739 steps: 741 1. If the transaction-identifier does not refer to a previous 742 subscribe or watch operation for the originator, an "error" 743 element having code 550 is returned. 745 2. Otherwise, the previous subscribe or watch operation for the 746 originator is terminated, and a "reply" element having code 250 747 is sent to the originator. 749 Note that following a terminate operation, the originator may receive 750 further presence or watcher updates. Although the service will send 751 no further updates after processing a terminate operation and sending 752 the reply operation, earlier updates may be in transit. 754 4.6 The Notify Operation 756 The service sends a "notify" element to endpoints that are watching 757 other endpoints subscribed to presence information (c.f., Section 758 4.3). 760 The "notify" element has a "subscriber" attribute, a "transID" 761 attribute, a "duration" attribute, an "action" attribute, and no 762 content: 764 o the "subscriber" attribute specifies the endpoint that is 765 subscribed to presence information; and, 767 o the "transID" attribute specifies the transaction-identifier 768 associated with the watch operation that caused this "notify" 769 element to be sent; 771 o the "action" attribute specifies whether a subscription or its 772 termination has occurred; and, 774 o if a subscription is being reported, the "duration" attribute 775 specifies the requested duration of the subscription. 777 No reply is sent by the receiving endpoint. 779 4.7 The Reply Operation 781 While processing operations, the service may respond with a "reply" 782 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for 783 the definition and an exposition of the syntax of the reply element. 785 5. Registration: The Presence Service 787 Well-Known Endpoint: apex=presence 789 Syntax of Messages Exchanged: c.f., Section 6 791 Sequence of Messages Exchanged: c.f., Section 4 793 Access Control Tokens: presence:subscribe, presence:watch, 794 presence:publish 796 Contact Information: c.f., the "Authors' Addresses" section of this 797 memo 799 6. The Presence Service DTD 801 811 813 %APEXCORE; 815 844 845 850 851 856 857 858 863 864 871 875 876 882 883 889 890 891 894 7. Security Considerations 896 Consult [1]'s Section 11 for a discussion of security issues. 898 References 900 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange 901 Core", draft-ietf-apex-core-04 (work in progress), July 2001. 903 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 904 3080, March 2001. 906 [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service", 907 draft-ietf-apex-access-06 (work in progress), July 2001. 909 Authors' Addresses 911 Marshall T. Rose 912 Invisible Worlds, Inc. 913 131 Stony Circle 914 Suite 500 915 Santa Rosa, CA 95401 916 US 918 Phone: +1 707 578 2350 919 EMail: mrose@invisible.net 920 URI: http://invisible.net/ 922 Graham Klyne 923 Baltimore Technologies 924 1310 Waterside 925 Arlington Business Park 926 Theale, Reading RG7 4SA 927 UK 929 Phone: +44 118 903 8000 930 EMail: gk@acm.org 932 David H. Crocker 933 Brandenburg Consulting 934 675 Spruce Drive 935 Sunnyvale, CA 94086 936 US 938 Phone: +1 408 246 8253 939 EMail: dcrocker@brandenburg.com 940 URI: http://www.brandenburg.com/ 942 Appendix A. Acknowledgements 944 The authors gratefully acknowledge the contributions of: Neil Cook, 945 Eric Dixon, Darren New, Scott Pead, and Bob Wyman. 947 Appendix B. Revision History 949 B.1 Changes from draft-ietf-apex-presence-03 951 o The new date-time format referenced in the core document is now 952 used for the timestamp data-type. 954 o The relationship of the "reply" element to the core document was 955 clarified. 957 B.2 Changes from draft-ietf-apex-presence-02 959 o Re-organization previous version for consistency. 961 B.3 Changes from draft-ietf-apex-presence-01 963 o Grammar error in Security Considerations. 965 o Extraneous sentence in Step 6.2 of Section 4.3. 967 o Notifications are now sent when a subscription is terminated. 969 B.4 Changes from draft-ietf-apex-presence-00 971 o Change "subaddress" convention from RFC 2846 to APEX's custom 972 ABNF. 974 Full Copyright Statement 976 Copyright (C) The Internet Society (2001). All Rights Reserved. 978 This document and translations of it may be copied and furnished to 979 others, and derivative works that comment on or otherwise explain it 980 or assist in its implementation may be prepared, copied, published 981 and distributed, in whole or in part, without restriction of any 982 kind, provided that the above copyright notice and this paragraph are 983 included on all such copies and derivative works. However, this 984 document itself may not be modified in any way, such as by removing 985 the copyright notice or references to the Internet Society or other 986 Internet organizations, except as needed for the purpose of 987 developing Internet standards in which case the procedures for 988 copyrights defined in the Internet Standards process must be 989 followed, or as required to translate it into languages other than 990 English. 992 The limited permissions granted above are perpetual and will not be 993 revoked by the Internet Society or its successors or assigns. 995 This document and the information contained herein is provided on an 996 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 997 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 998 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 999 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1000 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1002 Acknowledgement 1004 Funding for the RFC Editor function is currently provided by the 1005 Internet Society.