SIMPLE Working Group M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track H. Tschofenig Expires: September 7, 2009 Nokia Siemens Networks H. Schulzrinne Columbia University March 6, 2009 Indirect Presence Publication with the Session Initiation Protocol(SIP) draft-garcia-simple-indirect-presence-publish-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 September 7, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Garcia-Martin, et al. Expires September 7, 2009 [Page 1] Internet-Draft SIP Indirect Presence Publication March 2009 Abstract SIP is extended by the SIP-events framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence' and this presence information is carried in Presence Information Data Format (PIDF) documents. The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document is typically used when presentities publish their own presence since these presentities are typically the source of the information. However, there are cases when the presentity is not the direct source of the presence information. One such example is location information where the end host may obtain a reference to location information as opposed to as a value. The endpoint is typically not interested in knowing its own location information, but other users or entities might be. So, if the endpoint gets its own location information with a reference and wants to publish it embedded in its presence information, it first needs to de-reference it for getting a value, and then it can embed that value in its presence information. While this is certainly a correct sequence, it adds a round-trip to the presence publication, in addition to a demand processing power and network bandwidth consumption. There is a need for a mechanism that the presentity can use to publish indirect references, such as indirect location references. This document discusses a few variants that may be used to provide this functionality. Garcia-Martin, et al. Expires September 7, 2009 [Page 2] Internet-Draft SIP Indirect Presence Publication March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Geolocation Protocols Relationship . . . . . . . . . . . . 4 1.2. Case Study: Location URIs . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.2. Informational References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Garcia-Martin, et al. Expires September 7, 2009 [Page 3] Internet-Draft SIP Indirect Presence Publication March 2009 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] is extended by the SIP-events framework [RFC3265] to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence'. The presence information is typically carried in Extensible Markup Language (XML) [W3C.REC-xml-20060816] documents that are compliant with a given XML schema [W3C.REC-xmlschema-0-20041028]. These presence documents are called Presence Information Data Format (PIDF) documents [RFC3863]. The SIP PUBLISH method specified in RFC 3903 [RFC3903] carrying a PIDF document is typically used when presentities publish their own presence information. Usually the presentity can compose a quite detailed PIDF document, which is typically extended with a number of rich information, such as the Presence Data Model [RFC4479], Rich Presence Extensions to PIDF (RPID) [RFC4480], or the Contact Information to the Presence Information Data Format (CIPID) [RFC4481]. In the mentioned extensions, the presentity is typically the source of the extended rich presence information. However, there are occasions, when the presentity is not the direct source of the presence information. One of these cases occurs when a presentity acquires its own location information from a HELD server [I-D.ietf-geopriv-http-location-delivery]. The HELD client on the end host can request Location URI (location by reference) as opposed to as a value (location by value). 1.1. Geolocation Protocols Relationship Figure 1 depicts the geolocation protocol relationship. A Location URI points to a Location Configuration Protocol (LCP) server that is able to provide location of a specific target. The LCP server is able to associate the Location URI to the location of the target inside its administrative domain. A target of location information implements a Location Configuration Protocol (LCP) client. The LCP client first uses the location configuration protocol to acquire its location information (see step 1 in Figure 1). We assume this location information is delivered in the format of a reference. Then the LCP client needs to de-reference the acquired reference. This done in step 2 in Figure 1 and uses a location de-reference protocol to get a value of its location information. Last, the end host can embed its location information in the location conveyance protocol (step 3 in in Figure 1) and send it to a location recipient, such as a presence server. Garcia-Martin, et al. Expires September 7, 2009 [Page 4] Internet-Draft SIP Indirect Presence Publication March 2009 +-----------+ +------------+ | | | Location | | LCP | | recipient/ | | server | | Presence | | | | cerver | +-----------+ +------------+ ^ ^ ^ Geopriv | | Geopriv // Location | | Location // Dereference| | Configuration // Protocol | | Protocol // (2) | | (1) // | | // Geopriv Location v v // Conveyance Protocol +-----------+ // (e.g., SIP) | Target / | // (3) | End host |v | LCP client| +-----------+ Figure 1: Current Geolocation Protocols Relationship This document, though, discusses proposals for the scenario envisioned in Figure 2, where the target or end hosts acquires a reference via the location configuration protocol (step 1 in Figure 2), sends such reference in a location conveyance protocol or presence publication (step 2), and lets the location recipient or presence server to acquire the actual value according to the reference (step 3). The kind of reference that is first acquired and then send to the location recipient determines the value that the location recipient gets in step 3. Section 1.2 discusses location URIs. Garcia-Martin, et al. Expires September 7, 2009 [Page 5] Internet-Draft SIP Indirect Presence Publication March 2009 +-----------+ Geopriv +------------+ | | Location | Location | | LCP |<------------->| Recipient/ | | server | Dereference | Presence | | | Protocol (3) | Server | +-----------+ +------------+ ^ ^ | Geopriv // | Location // | Configuration // | Protocol // | (1) // | // Geopriv Location v // Conveyance Protocol +-----------+ // (e.g., SIP) | Target / | // (2) | End Host |v | LCP Client| +-----------+ Figure 2: Proposed Geolocation Protocols Relationship 1.2. Case Study: Location URIs A Location URI points to a Location Configuration Protocol (LCP) server that is able to provide location of a specific target. The LCP server is able to associate the Location URI to the location of the target inside its administrative domain. However, the resolution step from a Location URI to a Location Object may be influenced by different parameters and by the location URI itself. Depending on the value returned as an invocation to the reference URI, we can classify location URI in two cases: Static location URIs: Whenever a static location URI is de-referenced, the same static location is returned. These URIs are typically constrained by a start and a stop time. For example, the location of Alice on a her 21st birthday at 10:00 AM is a static location URI, because she was in a place at that time and date, so, the location does not change. The path that Alice took on the same day from 12 PM to 2 PM is also a static location URI, because as a result of its de-reference the location recipient will get the same collection of locations. Garcia-Martin, et al. Expires September 7, 2009 [Page 6] Internet-Draft SIP Indirect Presence Publication March 2009 Dynamic location URIs: Every time a dynamic location URI is de-referenced a new (potentially different) location is provided. Typically these URIs do not have a constraint with the time. Assume Alice acquires a URI that points to her current location, every time that a location recipient invokes the URI, he will get a different location (assuming that Alice's location changes). Another example can be when Alice acquires a URI that provides her location between today noon and now, so, when the location recipient invokes the URI, he will be accumulating further locations, providing that Alice is changing her location. Dynamic location URIs have stronger privacy considerations, because the target does not really know what is the location supplied at any time. However, the target has mechanisms to constraint the availability of a dynamic location URI, for example, by imposing a time when the reference expires. With either dynamic or location URIs there is a need for a mechanism that allows the presentity to publish indirect references. In absence of this mechanism, the presentity would need to retrieve its location information by value, compose a PIDF document that contains it, and publish it to the presence server. 1.3. 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 BCP 14, RFC 2119 [RFC2119]. This version of the document does not contain normative text at this point in time given the different options that are available to solve the described problem. 2. Overview of Operation A presentity first send a location request [I-D.ietf-geopriv-http-location-delivery] over the binding protocol, indicating the desire to receive its location by reference. This is done by including a element with the value set to "locationURI". The server responds with one or more elements, typically with different URI schemas. The presentity then selects a SIP or SIPS URI scheme, and: [[Editor's Note: We have several options here. We need to pick Garcia-Martin, et al. Expires September 7, 2009 [Page 7] Internet-Draft SIP Indirect Presence Publication March 2009 one.]] 1. Inserts the value of the locationURI in a Geolocation header field, as specified in the SIP Location Conveyance document [I-D.ietf-sip-location-conveyance]. Then, it sends it in a PUBLISH request, which may also contain a regular PIDF document. The drawback of this approach is that it is specific to geolocation and difficult to generalize. Furthermore, it is not possible to determine whether the server actually understands the provided references. 2. Inserts the locationURI value in a new extension to the PIDF to carry an indirect reference. The extension consists of a new element called "indirect-reference", which is inserted. Then, the PIDF is attached to a PUBLISH request and sent to the presence server. The drawback of this approach is that it is still not possible to determine whether the server supports it. Also, if the referred document is a PIDF, then the semantics would be "here is the reference to an additional PIDF document" as opposed to "include this position some elements that are indirectly referred". The advantage of this approach is that this extension is general enough to include any indirect reference, for example, to a calendar that can publish RFC 4481 extensions to PIDF. 3. Creates an additional XML document (independent of a PIDF document) and if the presentity also attaches a regular PIDF document, then both documents are put into a MIME multipart/ related wrapper, which becomes the payload of the PUBLISH request. Otherwise, the sole new XML document is attached to the PUBLISH request and sent to the presence server. The drawback of this approach is the shy support for multipart MIME bodies. The advantage is a clean solution with no interferences with PIDF. It also allows to include an indirect-reference of any kind. When the presence server receives a PUBLISH request that contains an indirect reference, it tries to de-reference, e.g., invoke the URI included there. If the result of such operation is that the presence server gets a presentity's PIDF document, then it should consider the document as directly published from the presentity, and should composed a merged PIDF document, potentially including other sources of presence information. Garcia-Martin, et al. Expires September 7, 2009 [Page 8] Internet-Draft SIP Indirect Presence Publication March 2009 3. IANA Considerations This document has no actions for IANA. 4. Security considerations The security considerations described in SIP Location Conveyance [I-D.ietf-sip-location-conveyance]are applicable to this document. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 5.2. Informational References [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006. [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", RFC 4481, July 2006. [W3C.REC-xml-20060816] Garcia-Martin, et al. Expires September 7, 2009 [Page 9] Internet-Draft SIP Indirect Presence Publication March 2009 Paoli, J., Yergeau, F., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml-20060816, August 2006, . [W3C.REC-xmlschema-0-20041028] Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, . [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sip-location-conveyance-12 (work in progress), November 2008. [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-13 (work in progress), February 2009. Authors' Addresses Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain Email: miguel.a.garcia@ericsson.com Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Garcia-Martin, et al. Expires September 7, 2009 [Page 10] Internet-Draft SIP Indirect Presence Publication March 2009 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Garcia-Martin, et al. Expires September 7, 2009 [Page 11]