idnits 2.17.1 draft-ietf-apex-presence-05.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 (August 14, 2001) is 8291 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-05 ** 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-07 ** 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: February 12, 2002 G. Klyne 5 Baltimore Technologies 6 D. Crocker 7 Brandenburg Consulting 8 August 14, 2001 10 The APEX Presence Service 11 draft-ietf-apex-presence-05 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 February 12, 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-04 . . . . . . . . . . . 31 70 B.2 Changes from draft-ietf-apex-presence-03 . . . . . . . . . . . 31 71 B.3 Changes from draft-ietf-apex-presence-02 . . . . . . . . . . . 31 72 B.4 Changes from draft-ietf-apex-presence-01 . . . . . . . . . . . 31 73 B.5 Changes from draft-ietf-apex-presence-00 . . . . . . . . . . . 31 74 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32 76 1. Introduction 78 This memo describes a presence service that is built upon the APEX 79 [1] "relaying mesh". The APEX presence service is used to manage 80 presence information for APEX endpoints. 82 APEX, at its core, provides a best-effort datagram service. Within 83 an administrative domain, all relays must be able to handle messages 84 for any endpoint within that domain. APEX services are logically 85 defined as endpoints but given their ubiquitous semantics they do not 86 necessarily need to be associated with a single physical endpoint. 87 As such, they may be provisioned co-resident with each relay within 88 an administrative domain, even though they are logically provided on 89 top of the relaying mesh, i.e., 91 +----------+ +----------+ +----------+ +---------+ 92 | APEX | | APEX | | APEX | | | 93 | access | | presence | | report | | ... | 94 | service | | service | | service | | | 95 +----------+ +----------+ +----------+ +---------+ 96 | | | | 97 | | | | 98 +----------------------------------------------------------------+ 99 | | 100 | APEX core | 101 | | 102 +----------------------------------------------------------------+ 104 That is, applications communicate with an APEX service by exchanging 105 data with a "well-known endpoint" (WKE). 107 APEX applications communicate with the presence service by exchanging 108 data with the well-known endpoint "apex=presence" in the 109 corresponding administrative domain, e.g., 110 "apex=presence@example.com" is the endpoint associated with the 111 presence service in the "example.com" administrative domain. 113 Note that within a single administrative domain, the presence service 114 makes use of the APEX access [3] service in order to determine if an 115 originator is allowed to view or manage presence information. 117 2. Management of Presence Information 119 Management of presence information falls into three categories: 121 o applications may update the presence information associated with 122 an endpoint; 124 o applications may subscribe to receive presence information 125 associated with an endpoint; and, 127 o applications may find out who is subscribed to receive presence 128 information. 130 Each is now described in turn. 132 2.1 Update of Presence Information 134 When an application wants to modify the presence information 135 associated with an endpoint, it sends a publish operation to the 136 service, e.g., 138 +-------+ +-------+ 139 | | -- data -------> | | 140 | appl. | | relay | 141 | | <--------- ok -- | | 142 +-------+ +-------+ 144 C: 145 146 147 148 150 153 156 158 159 160 161 162 S: 164 Note that this example uses the "subaddress" convention specified in 165 Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of 166 traffic for a particular endpoint. Of course, popular applications 167 may have their own URI method assigned to them (e.g., 168 "im:fred@example.com"). 170 The service immediately responds with a reply operation containing 171 the same transaction-identifier, e.g., 173 +-------+ +-------+ 174 | | <------- data -- | | 175 | relay | | pres. | 176 | | -- ok ---------> | svc. | 177 +-------+ +-------+ 179 C: 180 181 182 183 184 185 186 S: 188 2.2 Distribution of Presence Information 190 When an application wants to (periodically) receive the presence 191 information associated with an endpoint, it sends a subscribe 192 operation to the service, e.g., 194 +-------+ +-------+ 195 | | -- data -------> | | 196 | appl. | | relay | 197 | | <--------- ok -- | | 198 +-------+ +-------+ 200 C: 201 202 203 204 206 207 208 S: 210 The service immediately responds with a publish operation containing 211 the same transaction-identifier, e.g., 213 +-------+ +-------+ 214 | | <------- data -- | | 215 | relay | | pres. | 216 | | -- ok ---------> | svc. | 217 +-------+ +-------+ 219 C: 220 221 222 223 225 228 231 232 233 234 235 S: 237 Subsequently, for up to the specified "duration", the service sends 238 new publish operations whenever there are any changes to the 239 endpoint's presence information. If the "duration" is zero-valued, a 240 one time poll of the presence information is achieved; otherwise, at 241 the end of the "duration", a terminate operation is sent. 243 Note that Step 5 of Section 4.4 requires that the "lastUpdate" 244 attribute of a presence entry be supplied in order to update that 245 entry; accordingly, applications must successfully retrieve an 246 publish entry prior to trying to update that entry. This is usually 247 accomplished by subscribing with a zero-valued duration. 249 Either the subscriber or the service may cancel a subscription by 250 sending a terminate operation, e.g., 252 +-------+ +-------+ 253 | | -- data -------> | | 254 | appl. | | relay | 255 | | <--------- ok -- | | 256 +-------+ +-------+ 258 C: 259 260 261 262 263 264 265 S: 267 +-------+ +-------+ 268 | | <------- data -- | | 269 | relay | | pres. | 270 | | -- ok ---------> | svc. | 271 +-------+ +-------+ 273 C: 274 275 276 277 278 279 280 S: 282 or 283 +-------+ +-------+ 284 | | <------- data -- | | 285 | relay | | pres. | 286 | | -- ok ---------> | svc. | 287 +-------+ +-------+ 289 C: 290 291 292 293 294 295 296 S: 298 2.3 Distribution of Watcher Information 300 When an application wants to (periodically) receive notices about 301 endpoints that are subscribed to receive presence information, it 302 sends a watch operation to the service, e.g., 304 +-------+ +-------+ 305 | | -- data -------> | | 306 | appl. | | relay | 307 | | <--------- ok -- | | 308 +-------+ +-------+ 310 C: 311 312 313 314 316 317 318 S: 320 The service immediately responds with a reply operation containing 321 the same transaction-identifier, e.g., 323 +-------+ +-------+ 324 | | <------- data -- | | 325 | relay | | pres. | 326 | | -- ok ---------> | svc. | 327 +-------+ +-------+ 329 C: 330 331 332 334 335 336 S: 338 For each current subscriber, the service immediately sends a notify 339 operation containing the same transaction-identifier, e.g., 341 +-------+ +-------+ 342 | | <------- data -- | | 343 | relay | | pres. | 344 | | -- ok ---------> | svc. | 345 +-------+ +-------+ 347 C: 348 349 350 351 353 354 355 S: 357 Subsequently, for up to the specified "duration", the service sends 358 new notify operations whenever an application subscribes successfully 359 or a subscription is terminated. If the "duration" is zero-valued, a 360 one time poll of the watcher information is achieved; otherwise, at 361 the end of the "duration", a terminate operation is sent. 363 Either the watcher or the service may cancel the request by sending a 364 terminate operation, e.g., 366 +-------+ +-------+ 367 | | -- data -------> | | 368 | appl. | | relay | 369 | | <--------- ok -- | | 370 +-------+ +-------+ 372 C: 373 374 375 376 377 378 379 S: 381 +-------+ +-------+ 382 | | <------- data -- | | 383 | relay | | pres. | 384 | | -- ok ---------> | svc. | 385 +-------+ +-------+ 387 C: 388 389 390 391 392 393 394 S: 396 or 397 +-------+ +-------+ 398 | | <------- data -- | | 399 | relay | | pres. | 400 | | -- ok ---------> | svc. | 401 +-------+ +-------+ 403 C: 404 405 406 407 408 409 410 S: 412 3. Format of Presence Entries 414 Each administrative domain is responsible for maintaining a "presence 415 entry" for each of its endpoints (regardless of whether those 416 endpoints are currently attached to the relaying mesh). 418 Section 6 defines the syntax for presence entries. Each presence 419 entry has a "publisher" attribute, a "lastUpdate" attribute, a 420 "publisherInfo" attribute, and contains one or more "tuple" elements: 422 o the "publisher" attribute specifies the endpoint associated with 423 the presence entry; 425 o the "lastUpdate" attribute specifies the date and time that the 426 service last updated the presence entry; 428 o the "publisherInfo" attribute specifies arbitrary information 429 about the publisher (using a URI); and, 431 o each "tuple" element specifies information about an entity 432 associated with the endpoint. 434 Each "tuple" element has a "destination" attribute, an 435 "availableUntil" attribute, a "tupleInfo" attribute, and contains 436 zero or more "capability" elements: 438 o the "destination" attribute identifies the entity as a URI (e.g., 439 "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com"); 441 o the "availableUntil" attribute specifies the latest date and time 442 that the entity is capable of receiving messages; 444 o the "tupleInfo" attribute specifies arbitrary information about 445 the entity (using a URI); and, 447 o each "capability" element contains a specification as to the kinds 448 of content the entity is capable of receiving. 450 Each "capability" element contains arbitrary character data formatted 451 according to the standard indicated in the element's "baseline" 452 attribute. 454 4. The Presence Service 456 Section 5 contains the APEX service registration for the presence 457 service: 459 o Within an administrative domain, the service is addressed using 460 the well-known endpoint of "apex=presence". 462 o Section 6 defines the syntax of the operations exchanged with the 463 service. 465 o A consumer of the service initiates communications by sending data 466 containing the subscribe, watch, or publish operation. 468 o In addition to replying to these operations, the service may also 469 initiate communications by sending data containing the terminate, 470 publish, or notify operations. 472 An implementation of the service must maintain information about both 473 presence entries and in-progress operations in persistent storage. 475 Consult Section 6.1.1 of [1] for a discussion on the properties of 476 long-lived transaction-identifiers. 478 4.1 Use of XML and MIME 480 Section 4.1 of [1] describes how arbitrary MIME content is exchanged 481 as a BEEP [2] payload. For example, to transmit: 483 484 485 486 488 where "..." refers to: 490 then the corresponding BEEP message might look like this: 492 C: MSG 1 1 . 42 1234 493 C: Content-Type: multipart/related; boundary="boundary"; 494 C: start="<1@example.com>"; 495 C: type="application/beep+xml" 496 C: 497 C: --boundary 498 C: Content-Type: application/beep+xml 499 C: Content-ID: <1@example.com> 500 C: 501 C: 502 C: 503 C: 504 C: 505 C: --boundary 506 C: Content-Type: application/beep+xml 507 C: Content-ID: <2@example.com> 508 C: 509 C: 510 C: --boundary-- 511 C: END 513 or this: 515 C: MSG 1 1 . 42 1234 516 C: Content-Type: application/beep+xml 517 C: 518 C: 519 C: 520 C: 521 C: 522 C: 523 C: 524 C: 525 C: END 527 4.2 The Subscribe Operation 529 When an application wants to (periodically) receive the presence 530 information associated with an endpoint, it sends a "subscribe" 531 element to the service. 533 The "subscribe" element has a "publisher" attribute, a "duration" 534 attribute, a "transID" attribute, and no content: 536 o the "publisher" attribute specifies the endpoint associated with 537 the presence entry; 539 o the "transID" attribute specifies the transaction-identifier 540 associated with this operation; and, 542 o the "duration" attribute specifies the maximum number of seconds 543 for which the originator is interested in receiving updated 544 presence information. 546 When the service receives a "subscribe" element, we refer to the 547 "publisher" attribute of that element as the "subject", and the 548 service performs these steps: 550 1. If the subject is outside of this administrative domain, a 551 "reply" element having code 553 is sent to the originator. 553 2. If the subject does not refer to a valid endpoint, a "reply" 554 element having code 550 is sent to the originator. 556 3. If the subject's access entry does not contain a 557 "presence:subscribe" token for the originator, a "reply" element 558 having code 537 is sent to the originator. 560 4. If the originator already has an in-progress subscribe operation 561 for the subject, then the previous subscribe operation is 562 silently terminated, and processing continues. 564 5. If the "transID" attribute refers to an in-progress subscribe or 565 watch operation for the originator, a "reply" element having code 566 555 is sent to the originator. 568 6. Otherwise: 570 1. A "publish" element, corresponding to the subject's presence 571 entry, is immediately sent to the originator. 573 2. For each endpoint currently watching subscribers to the 574 subject's presence information, a "notify" element is 575 immediately as sent (c.f., Step 6.3 of Section 4.6). 577 3. For up to the amount of time indicated by the "duration" 578 attribute of the "subscribe" element, if the subject's 579 presence entry changes, an updated "presence" element is sent 580 to the originator using the publish operation (Section 4.4). 581 Finally, when the amount of time indicated by the "duration" 582 attribute expires, a terminate operation (Section 4.5) is 583 sent to the originator. 585 Note that if the duration is zero-valued, then the subscribe 586 operation is making a one-time poll of the presence information. 587 Accordingly, Step 6.3 above does not occur. 589 Regardless of whether a "publish" or "reply" element is sent to the 590 originator, the "transID" attribute is identical to the value found 591 in the "subscribe" element sent by the originator. 593 4.3 The Watch Operation 595 When an application wants to (periodically) receive notices about 596 endpoints that are subscribed to receive presence entry, it sends a 597 "watch" element to the service. 599 The "watch" element has a "publisher" attribute, a "duration" 600 attribute, a "transID" attribute, and no content: 602 o the "publisher" attribute specifies the endpoint associated with 603 the presence entry; 605 o the "transID" attribute specifies the transaction-identifier 606 associated with this operation; and, 608 o the "duration" attribute specifies the maximum number of seconds 609 for which the originator is interested in watching subscribers. 611 When the service receives a "watch" element, we refer to the 612 "publisher" attribute of that element as the "subject", and the 613 service performs these steps: 615 1. If the subject is outside of this administrative domain, a 616 "reply" element having code 553 is sent to the originator. 618 2. If the subject does not refer to a valid endpoint, a "reply" 619 element having code 550 is sent to the originator. 621 3. If the subject's access entry does not contain a "presence:watch" 622 token for the originator, a "reply" element having code 537 is 623 sent to the originator. 625 4. If the originator already has an in-progress watch operation for 626 the subject, then the previous watch operation is silently 627 terminated, and processing continues. 629 5. If the "transID" attribute refers to an in-progress subscribe or 630 watch operation for the originator, a "reply" element having code 631 555 is sent to the originator. 633 6. Otherwise: 635 1. A "reply" element having code 250 is sent to the originator. 637 2. For each endpoint currently subscribing to the subject's 638 presence information, a "notify" element is immediately sent 639 to the originator (c.f., Section 4.6). 641 3. For up to the amount of time indicated by the "duration" 642 attribute of the "watch" element, whenever a subscribe 643 operation succeeds or a subscription is terminated, a 644 "notify" element is sent to the originator. Finally, when 645 the amount of time indicated by the "duration" attribute 646 expires, a terminate operation (Section 4.5) is sent to the 647 originator. 649 Note that if the duration is zero-valued, then the watch 650 operation is making a one-time poll of the presence information. 651 Accordingly, Step 6.3 above does not occur. 653 Regardless of whether a "notify" or "reply" element is sent to the 654 originator, the "transID" attribute is identical to the value found 655 in the "presence" element sent by the originator. 657 4.4 The Publish Operation 659 When an application wants to modify the presence entry associated 660 with an endpoint, it sends a "publish" element to the service. In 661 addition, the service sends a "publish" element to endpoints that 662 have subscribed to see presence information (c.f., Section 4.2). 664 The "publish" element has a "publisher" attribute, a "transID" 665 attribute, a "timeStamp" attribute, and contains a "presence" 666 element: 668 o the "publisher" attribute specifies the endpoint to be associated 669 with the presence entry; 671 o the "transID" attribute specifies the transaction-identifier 672 associated with this operation; 674 o the "timeStamp" attribute specifies the application's notion of 675 the current date and time; and, 677 o the "presence" element contains the desired presence entry for the 678 endpoint. 680 When the service sends a "publish" element, the "transID" attribute 681 specifies the transaction-identifier associated with the subscribe 682 operation that caused this "publish" element to be sent, and the 683 "timeStamp" attribute specifies the service's notion of the current 684 date and time. No reply is sent by the receiving endpoint. 686 When the service receives a "publish" element, we refer to the 687 "publisher" attribute of that element as the "subject", and the 688 service performs these steps: 690 1. If the "publisher" attribute of the "publish" element doesn't 691 match the "publisher" attribute of the "presence" element 692 contained in the "publish" element, a "reply" element having code 693 503 is sent to the originator. 695 2. If the subject is outside of this administrative domain, a 696 "reply" element having code 553 is sent to the originator. 698 3. If the subject does not refer to a valid endpoint, a "reply" 699 element having code 550 is sent to the originator. 701 4. If the subject's access entry does not contain a 702 "presence:publish" token for the originator, a "reply" element 703 having code 537 is sent to the originator. 705 5. If the "lastUpdate" attribute of the "publish" element is not 706 semantically identical to the "lastUpdate" attribute of the 707 subject's presence entry, a "reply" element having code 555 is 708 sent to the originator. (This allows a simple mechanism for 709 atomic updates.) 711 6. Otherwise: 713 1. The subject's presence entry is updated from the "publish" 714 element. 716 2. The "lastUpdate" attribute of the presence entry is set to 717 the service's notion of the current date and time. 719 3. A "reply" element having code 250 is sent to the originator. 721 When sending the "reply" element, the "transID" attribute is 722 identical to the value found in the "publish" element sent by the 723 originator. 725 4.5 The Terminate Operation 727 When an application no longer wishes to subscribe to presence 728 information or to watch endpoints that are subscribed to receive 729 presence information, it sends a "terminate" element to the service; 730 similarly, when the service no longer considers an application to be 731 subscribing or watching, a "terminate" element is sent to the 732 application. 734 The "terminate" element contains only a "transID" attribute that 735 specifies the transaction-identifier associated an in-progress 736 subscribe or watch operation. Section 9.1 of [1] defines the syntax 737 for the "terminate" element. 739 When the service receives a "terminate" element, it performs these 740 steps: 742 1. If the transaction-identifier does not refer to a previous 743 subscribe or watch operation for the originator, an "error" 744 element having code 550 is returned. 746 2. Otherwise, the previous subscribe or watch operation for the 747 originator is terminated, and a "reply" element having code 250 748 is sent to the originator. 750 Note that following a terminate operation, the originator may receive 751 further presence or watcher updates. Although the service will send 752 no further updates after processing a terminate operation and sending 753 the reply operation, earlier updates may be in transit. 755 4.6 The Notify Operation 757 The service sends a "notify" element to endpoints that are watching 758 other endpoints subscribed to presence information (c.f., Section 759 4.3). 761 The "notify" element has a "subscriber" attribute, a "transID" 762 attribute, a "duration" attribute, an "action" attribute, and no 763 content: 765 o the "subscriber" attribute specifies the endpoint that is 766 subscribed to presence information; and, 768 o the "transID" attribute specifies the transaction-identifier 769 associated with the watch operation that caused this "notify" 770 element to be sent; 772 o the "action" attribute specifies whether a subscription or its 773 termination has occurred; and, 775 o if a subscription is being reported, the "duration" attribute 776 specifies the requested duration of the subscription. 778 No reply is sent by the receiving endpoint. 780 4.7 The Reply Operation 782 While processing operations, the service may respond with a "reply" 783 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for 784 the definition and an exposition of the syntax of the reply element. 786 5. Registration: The Presence Service 788 Well-Known Endpoint: apex=presence 790 Syntax of Messages Exchanged: c.f., Section 6 792 Sequence of Messages Exchanged: c.f., Section 4 794 Access Control Tokens: presence:subscribe, presence:watch, 795 presence:publish 797 Contact Information: c.f., the "Authors' Addresses" section of this 798 memo 800 6. The Presence Service DTD 802 812 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 In addition, timestamps issued by the the presence service may 899 disclose location information. If this information is considered 900 sensistive, the special timezone value "-00:00" may be used. 902 References 904 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange 905 Core", draft-ietf-apex-core-05 (work in progress), August 2001. 907 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 908 3080, March 2001. 910 [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service", 911 draft-ietf-apex-access-07 (work in progress), August 2001. 913 Authors' Addresses 915 Marshall T. Rose 916 Invisible Worlds, Inc. 917 131 Stony Circle 918 Suite 500 919 Santa Rosa, CA 95401 920 US 922 Phone: +1 707 578 2350 923 EMail: mrose@invisible.net 924 URI: http://invisible.net/ 926 Graham Klyne 927 Baltimore Technologies 928 1310 Waterside 929 Arlington Business Park 930 Theale, Reading RG7 4SA 931 UK 933 Phone: +44 118 903 8000 934 EMail: gk@acm.org 936 David H. Crocker 937 Brandenburg Consulting 938 675 Spruce Drive 939 Sunnyvale, CA 94086 940 US 942 Phone: +1 408 246 8253 943 EMail: dcrocker@brandenburg.com 944 URI: http://www.brandenburg.com/ 946 Appendix A. Acknowledgements 948 The authors gratefully acknowledge the contributions of: Neil Cook, 949 Eric Dixon, Darren New, Scott Pead, and Bob Wyman. 951 Appendix B. Revision History 953 Note to RFC editor: please remove this entire appendix, and the 954 corresponding entries in the table of contents, prior to publication. 956 B.1 Changes from draft-ietf-apex-presence-04 958 o Corrected three typos. 960 o Removed the reference to "xml.resource.org" in the DTD. 962 o Changed the syntax of the "baseline" attribute to URI, to allow 963 for distributed registration of possible values. 965 o Added timezone warning to the "Security Considerations" section. 967 B.2 Changes from draft-ietf-apex-presence-03 969 o The new date-time format referenced in the core document is now 970 used for the timestamp data-type. 972 o The relationship of the "reply" element to the core document was 973 clarified. 975 B.3 Changes from draft-ietf-apex-presence-02 977 o Re-organization previous version for consistency. 979 B.4 Changes from draft-ietf-apex-presence-01 981 o Grammar error in Security Considerations. 983 o Extraneous sentence in Step 6.2 of Section 4.3. 985 o Notifications are now sent when a subscription is terminated. 987 B.5 Changes from draft-ietf-apex-presence-00 989 o Change "subaddress" convention from RFC 2846 to APEX's custom 990 ABNF. 992 Full Copyright Statement 994 Copyright (C) The Internet Society (2001). All Rights Reserved. 996 This document and translations of it may be copied and furnished to 997 others, and derivative works that comment on or otherwise explain it 998 or assist in its implementation may be prepared, copied, published 999 and distributed, in whole or in part, without restriction of any 1000 kind, provided that the above copyright notice and this paragraph are 1001 included on all such copies and derivative works. However, this 1002 document itself may not be modified in any way, such as by removing 1003 the copyright notice or references to the Internet Society or other 1004 Internet organizations, except as needed for the purpose of 1005 developing Internet standards in which case the procedures for 1006 copyrights defined in the Internet Standards process must be 1007 followed, or as required to translate it into languages other than 1008 English. 1010 The limited permissions granted above are perpetual and will not be 1011 revoked by the Internet Society or its successors or assigns. 1013 This document and the information contained herein is provided on an 1014 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1015 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1016 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1017 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1018 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1020 Acknowledgement 1022 Funding for the RFC Editor function is currently provided by the 1023 Internet Society.