SIMPLE B. Campbell Internet-Draft dynamicsoft Expires: August 12, 2003 S. Olson Microsoft J. Peterson NeuStar, Inc. J. Rosenberg dynamicsoft B. Stucker Nortel Networks, Inc. February 11, 2003 SIMPLE Presence Publication Requirements draft-ietf-simple-publish-reqs-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 12, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes requirements for an extension to the Session Initiation Protocol (SIP) [1]. The purpose of this extension would be to create a means for publishing event state used within the framework for SIP Event Notification (RFC3265 [2]). The first Campbell, et al. Expires August 12, 2003 [Page 1] Internet-Draft SIMPLE Pub Reqs February 2003 application of this extension is targeted at the publication of presence information as defined by the SIMPLE [5] working group. 1. Introduction 1.1 Publication Model The following sections outline a model for publication of event state, in particular presence information. This model further defines the problem that this mechanism is attempting to solve. The method described in this document allows presence information to be published to a presence agent on behalf of a user. This method can be extended to support publication of other event state, but it is not intended to be a general-purpose mechanism for transport of arbitrary data as there are better suited mechanisms for this purpose (ftp, http, etc.) This method is intended to be a simple, light- weight mechanism that employs SIP in order to support SIMPLE services. 1.1.1 Presence Composition Most existing presence services involve a single PUA that has complete presence for a given presentity. This allows for a very simple model where that PUA sends full presence state to a PA, which then distributes it to watchers. But this is a limited view of presence. In general, the presence state of a presentity may be derived from many different inputs. A complete view of presence for a presentity is likely to be derived from more than one source, where the the complete view of presence state is composed of the presence state from each source. Therefore, any given PUA is unlikely to be able to provide complete presence information. This document proposes a logical model for publishing presence information from multiple PUAs to a presence compositor, that can act as a presence agent. Presence composition is a logical function in a presence distribution system. This function is fulfilled by a logical element known as a "presence compositor". A presence compositor accepts presence inputs from one or more PUAs, and composes these inputs into a composite presence document. Campbell, et al. Expires August 12, 2003 [Page 2] Internet-Draft SIMPLE Pub Reqs February 2003 +-----------------+ +----------+ | Presence | | Presence | | Compositor +------+ Agent | | | | | | | | | +--------+--------+ +----------+ | | +----------+---------+ | | | | | | +--+--+ +--+--+ +--+--+ | PUA | | PUA | | PUA | +-----+ +-----+ +-----+ Each PUA publishes its view of presence to the Presence Compositor, which then relays the composed presence information to a presence agent for distribution. It must be possible for each PUA publishes a full view of presence from its perspective--each publication carries full state, and does not depend on previous states for the particular PUA. A PUA does not need to know whether or not other PUAs are also publishing presence information to the compositor. The transformations that a presence compositor uses for this composition are entirely a matter of local policy. The policy could be as simple as the creation of a combined CPIM PIDF [4] document where each input represents a separate tuple. It can also involve more complex transformations, such as modifying the information from one source based on information from another source. 1.1.2 Interface between the Compositor and the PA The interface between a compositor and a PA is also a matter of local policy. The compositor might act as a PUA itself, and publish presence to the PA just like any other PUA might. The compositor and the PA may be co-located, and communicate via local procedure calls. Specification of this interface is beyond the scope of this document. 1.2 Why use SIP for publication? Two principal protocol candidates have been evaluated for presence state publication from a PUA to a presence compositor: HTTP and SIP. This document recommends the use of SIP for presence publication for the following reasons. Campbell, et al. Expires August 12, 2003 [Page 3] Internet-Draft SIMPLE Pub Reqs February 2003 1.2.1 HTTP HTTP is well suited for moving data around in the form of MIME body parts. An HTTP client-to-server publication solution would not require much work to specify. A SOAP over HTTP solution would additionally allow complex transaction semantics with little additional work. HTTP, however, does not have a well-defined routing model at the application level. It works fine if the publication point is well known and fairly static, but it will require additional work to deal with situations where the publication point changes dynamically. 1.2.2 SIP SIP, on the otherhand, is built around the concept of mobility of endpoints. The SIP proxy, registrar, and location service concepts provide a rich mechanism of finding a dynamically changing endpoint from and address of record. The application-level routing capabilities of SIP can be very useful for presence publication. If all PUAs for a given presentity exist in the same administrative domain, then they can most likely publish directly to a compositor. But if PUAs exist outside the administrative domain, it is likely they will not be able to do so. For example, suppose that Alice uses a presence service that allows multiple PUAs to publish to a compositor inside the service provider network. Further suppose that Alice wishes to incorporate presence information from an external provider, that has no business relationship with her primary provider. For this example, Alice wishes to use a shared browsing service that tracks the "location" she is currently browsing in the web. That service acts as a PUA on Alice's behalf, and publishes the information to her primary presence provider. Other users of the shared browsing service can subscribe to her presence information, and determine when they are browsing the same site. The presence provider is highly unlikely to allow the external PUA to send data directly to the compositor. But if Alice registers a contact with a methods parameter value of "PUBLISH", that PUA can send a publish request to an edge proxy in the presence providers network, and use Alice's address of record as the requestURI. This AoR could be her normal SIP URI, or it could be a special AoR for the purposes of presence publication. The proxy forwards the request to the compositor, without the external PUA having to talk directly to the compositor, or even know its IP address. Now consider that Alice's primary providor is actually an enterprise. That enterprise has different compositors for different departments. Campbell, et al. Expires August 12, 2003 [Page 4] Internet-Draft SIMPLE Pub Reqs February 2003 The external provider has no way of knowing this internal organization, nor does it know what department Alice works in. Still, Alice register's her publication contact at an enterprise registrar, the external provider sends the publish request to Alice's address of record, and the companies internal SIP network handles things from there, eventually getting the request to the correct compositor. The composition model does not at first appear to require publishing to dynamically changing PAs. But a very powerful, but often forgotten, aspect of SIMPLE is it allows a PA to exist on an end-user device. Indeed, some early implentations of SIMPLE rely on exactly that model. It is reasonable to expect the composition model above to co-exist with end-user device PAs, where the PA location changes dynamically. For example, imagine Alice hosts a PA on her PC, which aquires its IP address via DHCP. This address changes relatively frequently, and registers a publish contact with an enterprise registrar. Now, imagine she also has a mobile phone which contains a PUA. She wants her presence document to show a combined view of her PCs concept of her presence and her mobile phone service's concept of her precence. She cannot simply tell the mobile service her PC address since it changes often. Instead, she tells the service an AoR to publish presence to. The mobile service publishes presence state to that AoR, which resolves to a SIP proxy or redirect server. Normal SIP proxy or redirect behavior is invoked to get the publication to Alice's PC based on her publish contact registration. 1.2.3 Conclusions It is our opinion that SIP style routing is very useful for presence publication. Without the application level routing capabilities of SIP, it would be difficult to build these sort of services. It is more appropriate to add a publication mechanism to SIP than to standardize SIP-style routing features for HTTP proxies. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. Publication Requirements Any presence publication mechanism for SIP must meet the following requirements. Campbell, et al. Expires August 12, 2003 [Page 5] Internet-Draft SIMPLE Pub Reqs February 2003 1. The presence publication mechanism must provide a way for a PUA to publish presence to a presence compositor. 2. The presence publication mechanism must define a new SIP method for presence publication, or describe how some existing method can perform this function. 3. The presence publication mechanism must define a mandatory-to- implement format for expressing presence information. This format must have a registered MIME type. It is recommended that this format be the Presence Information Data Format [4]. Other formats in addition to the single mandatory-to-implement format may be suggested. 4. The publication mechanism must support the simultaneous publication from several distinct PUAs of presence information concerning the same presentity. 5. The publication mechanism must allow for the fact that any individual PUA may not know the total presence state of the user. Publications from any given PUA may contain only part of the total presence of the presentity. 6. It must be possible to order a published sequence of presence information originating from a particular PUA. 7. It must be possible for a compositor to reject a publication request. 8. The publication mechanism must support a means for a presence compositor to compose presence information received from multiple PUAs at different times into a single presence document. The compositor function must be able to detect and reconcile conflicts or overlaps in publications from different PUAs. 9. The publication mechanism must support a means for large content to be sent as a part of presence information. 10. It must be possible for a PUA to send full presence information (all of the presence information that the PUA knows about a presentity) in a publication, and there should also be a way for PUAs to send partial or incremental presence information. 11. The publication mechanism must support a way to uniquely identify segments of presence information (for example, the tuple elements in PIDF are uniquely identified by a tuple ID). Campbell, et al. Expires August 12, 2003 [Page 6] Internet-Draft SIMPLE Pub Reqs February 2003 12. There must be a way to uniquely identify segments of presence information for a particular presentity that is independent of the PUA that generated this segment. The tuple identifier from PIDF is an example of such a unique identifier. 13. The publication mechanism must allow two PUAs to publish information for the same segment of presence information. 14. PUAs must have a capability that allows them to query for the identifiers of all of the segments of presence information that have currently been published for a presentity (provided that the PUA is authorized to receive this information). 15. It must be possible for the publication of presence information for a particular segment to overwrite existing information for that segment, even if the existing information had been published by a different PUA. Overwrites could occur, for example, on the basis of a timestamp indicating when the segment was last modified (i.e. more recent segments overwrite older segments). 16. There must be a way for a compositor to reject a published segment of presence information from a PUA because the segment has been replaced by one published by another PUA. 17. It must be possible for a compositor to authenticate a publisher of presence information. 18. The presence publication architecture must support a means for principals to authorize the disclosure of segments of presence information to particular watchers. 19. There must be a way for a publisher to tell a presence agent that a piece of published presence should be passed on to watchers without modification. 4. IANA Considerations This document introduces no considerations for IANA. 5. Security Considerations A presence compositor should authenticate publishing User Agents, and may apply authorization policies. The composition model makes no assumptions that all input sources for a compositor are on the same network, or in the same administrative domain. Campbell, et al. Expires August 12, 2003 [Page 7] Internet-Draft SIMPLE Pub Reqs February 2003 Authorization of watchers becomes more complicated in a presence publication architecture. Principals should have some way to manage the authorization of watchers who wish to published presence information. Since they may not directly control the presence agent to which watchers subscribe, this introduces some mechanism requirements. The compositor should throttle incoming publications and the corresponding notifications resulting from the changes in event state. As a first step careful selection of default Expires: values for the supported event packages at a compositor can help limit refreshes of event state. Additional throttling and debounce logic at the compositor is advisable to further reduce the notification traffic produced as a result of a PUBLISH method. 6. Acknowledgments The authors would like to thank Krisztian Kiss and Aki Niemi for their suggestions. Normative References [1] Rosenberg, J., Schulzrinne, Camarillo, Johnston, Peterson, Sparks, Handley and Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A., "Session Initiation Protocol(SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "Common Presence and Instant Messaging (CPIM) Presence Information Data Format", draft-ietf-impp-cpim-pidf-07 (work in progress), May 2002. [5] Campbell, et al. Expires August 12, 2003 [Page 8] Internet-Draft SIMPLE Pub Reqs February 2003 Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75025 US EMail: bcampbell@dynamicsoft.com Sean Olson Microsoft One Microsoft Way Redmond, WA 98052 US Phone: +1-425-707-2846 EMail: seanol@microsoft.com URI: http://www.microsoft.com/rtc Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1-925-363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 US EMail: jdrosen@dynamicsoft.com Campbell, et al. Expires August 12, 2003 [Page 9] Internet-Draft SIMPLE Pub Reqs February 2003 Brian Stucker Nortel Networks, Inc. 2380 Performance Drive Richardson, TX 75082 US EMail: bstucker@nortelnetworks.com Campbell, et al. Expires August 12, 2003 [Page 10] Internet-Draft SIMPLE Pub Reqs February 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Campbell, et al. Expires August 12, 2003 [Page 11]