From: http://www.ietf.org/internet-drafts/draft-peterson-geopriv-pres-00.txt Title: A Presence Architecture for the Distribution of Geopriv Location Objects Reference: draft-peterson-geopriv-pres-00 ------------------------------------------------------------------------------- GEOPRIV WG J. Peterson Internet-Draft NeuStar Expires: August 25, 2003 February 24, 2003 A Presence Architecture for the Distribution of Geopriv Location Objects draft-peterson-geopriv-pres-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 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Geopriv defines the concept of a 'using protocol', a protocol that carries geopriv location objects. Geopriv also defines various scenarios for the distribution of location objects that require the concept of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto geopriv architectures, and presents one pre-existing using presence protocol that might carry location objects. Peterson Expires August 25, 2003 [Page 1] Internet-Draft pres enumservice February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Framework Analysis . . . . . . . . . . . . . . . . . . . . . . . 3 3. Presence Architecture for Geopriv . . . . . . . . . . . . . . . 4 4. Geopriv Extensions to PIDF . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . . 7 A. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 Peterson Expires August 25, 2003 [Page 2] Internet-Draft pres enumservice February 2003 1. Introduction Geopriv is a standard for the transmission of location information over the Internet. Location information is a description of a particular spatial location, which may be represented as coordinates (via longitude, latitude, and so on), or as civil addresses (such as postal addresses), or in other ways. Geopriv focuses on the privacy and security issues, both from a technology perspective and a policy perspective, of sharing location information over the Internet; it essentially defines a secure container class capable of carrying both location information and policy data governing the distribution of this information. Geopriv also defines the concept of a 'using protocol', a protocol that carries the geopriv location object. At the time this document has been written, the geopriv object format has not been specified; only a framework and requirements for geopriv (see [1]) currently exists. Presence is a service defined in RFC2778 [2] that allows users of a communications service to monitor one another's availability and disposition in order to make decisions about communicating. Presence information is highly dynamic, and generally characterizes whether a not a user is online or offline, busy or idle, away from communications devices or nearby, and the like. This document shows the applicability of presence to geopriv, and argues that a presence protocol might be a suitable using protocol for geopriv. This document is not intended to demonstrate that presence is the only method by which geopriv location objects might be distributed. However, there are numerous applications of geopriv that depend on the fundamental subscription/notification architecture that also underlies presence. 2. Framework Analysis The geopriv framework [1] defines four primary network entities: a Location Generator, a Location Server, a Location Recipient, and a Rule Holder. Three interfaces between these entities are defined, including a publication interface and a notification interface. Geopriv specifies that a 'using protocol' is employed to transport location objects from one place to another. If the publication interface and notification interface are network connections, then a using protocol would be responsible for the transmission of the location object. Location Recipients may request that a Location Server provide them with geopriv location information concerning a particular Target. The Location Generator publishes Location Information to a Location Server, which, in coordination with Peterson Expires August 25, 2003 [Page 3] Internet-Draft pres enumservice February 2003 policies set by the Rule Maker, distributes the location information to Location Recipients as necessary. The geopriv requirements document shows three scenarios for the use of the geopriv protocol. In some of these scenarios (such as the third), a Location Recipient sends some kind of message to the Location Server to request the periodic transmission of location information. The location of a geopriv Target is likely to vary over time (if the Target is a person, or something similarly mobile) and consequently the concept of a persistent subscription to the location of a Target resulting in periodic notification is valuable to geopriv. In other scenarios, a Location Recipient may request a one- time notification of the geographical location of the Target. Geopriv places few requirements on using protocols. However, it is clear from the description above that there must be some mechanism to allow Location Recipients to establish a persistent subscription in order to receive regular notification of the geographical location of a Target as their location changes over time. There must also be a way for Location Generators to publish location information to a Location Server that applies further policies for distribution. This document adopts a model in which the using protocol is responsible for requesting subscriptions, handling publications, and sending notifications. There are other models for geopriv in which such operations might be built into location objects themselves. However, there is a significant amount of pre-existing work in the IETF related to managing publications, subscriptions and notifications for data sets that vary over time. In fact, these concepts all correspond exactly to architectures for presence that have been developed in support of real-time communications applications such as instant messaging, voice and video sessions. Note that there are some geopriv scenarios in which the Location Recipient does not actively request the location of a Target, but rather it receives an unsolicited notification of Target's location. This document focuses on the use of presence only for those scenarios in which the Location Recipient actively solicits location information. It is however possible that many of these base operations of the subscription/notification framework of presence could be reused in for cases in which the Location Recipient is passive. 3. Presence Architecture for Geopriv The Common Profile for Presence [4] (CPP) defines a set of operations for delivery of presence information. These primarily consist of subscription operations and notification operations. A subscription Peterson Expires August 25, 2003 [Page 4] Internet-Draft pres enumservice February 2003 creates a persistent connection between a 'watcher' (which corresponds to the Location Recipient of geopriv) and a 'presentity' (which corresponds roughly to the Location Server). When a watcher subscribes to a presentity, a persistent connection is created; notifications of presence information will henceforth be sent to the watcher as the presence information changes. CPP also supports unsubscriptions (terminating the persistent subscription) and fetches (one-time requests for presence information that result in no persistent subscription). CPP provides a number of attributes of these operations that flesh out the presence system. There is a system for automatically expiring subscriptions if they are not refreshed at user-defined intervals (in order to eliminate stale subscriptions). There are transaction and subscription identifiers used to correlate messages, and a URI scheme ("pres:") is defined to identify watchers and presentities. The IETF IMPP WG has also defined an XML data format for presence information called the Presence Information Data Format [6] (PIDF). PIDF is a body carried by presence protocols that contains presence information, including the current state of a presentity. PIDF is discussed in more detail in Section 4. At a high-level, then, the presence architecture seems to have considerable applicability to the problem of delivering geopriv information. However, the CPP framework is an abstract framework - it doesn't actually specify a protocol, it specifies a framework and a set of requirements to which presence protocols must conform. Also, CPP does not define any concept similar to a Location Server, nor any way for presence information to be published to a Location Server. SIMPLE, the application of the Session Initiation Protocol [7] (SIP) to instant messaging and presence, is one protocol that instantiates the CPP format and extends it in a number of important ways. SIP has native support for subscriptions and notifications (in its events framework [8]) and has added an event package [9] for presence in order to satisfy the requirements of CPP. Above and beyond CPP, SIMPLE has done work on a publication method [11] that will allow presence information to be published by presentities to a server that will apply various policies before sharing presence information with watchers (in the SIMPLE publication architecture, this server is known as a compositor). SIMPLE has also defined an interface [10] through which authorization policies can be provisioning in a presence server. In summary, like geopriv, presence requires an architecture for Peterson Expires August 25, 2003 [Page 5] Internet-Draft pres enumservice February 2003 publication, subscription, and notification for a mutable set of data associated with a principal. Presence has already tackled many of the harder issues associated with subscription management, including subscription expiration, development of identifiers for principals, and defining document formats for presence information. Rather than reinventing work that has been done elsewhere in the IETF, geopriv should if at all possible reuse this existing work by specifying presence protocols (such as SIMPLE) as geopriv using protocols. 4. Geopriv Extensions to PIDF As was mentioned above, the presence architecture developed in the IETF IMPP WG has defined a format for presence information called PIDF. PIDF is an XML format that provides presence information about a presentity - primarily, this consists of status information, but also optionally includes contact addresses (a way of reaching the presentity), timestamps, and textual notes with arbitrary content. PIDF is an extensible format. It defines an XML element for representing the status of a presentity (the status element), and gives some guidance on how this element might be extended. While the authors of PIDF viewed geographical location as a potential category of presence information, PIDF currently defines no way to do so. PIDF meets the security requirements given in RFC2779 [3] (see especially 5.1, 5.2 and 5.3), which parallel the security requirements of the geopriv location object given in the geopriv requirements [1]. CPP and PIDF specify mechanisms for mutual authentication of participants in a presence exchange as well as confidentiality and integrity properties for presence information. So in short, many of the requirements of geopriv objects map well onto the capabilities of PIDF. Today, geopriv has not yet settled on a format for location objects. However, it is likely that a format satisfying the current geopriv requirements (especially the requirement for a rich policy language) will either use XML, or be able to be carried by XML. In future revisions of this document, as the geopriv specification of location objects is further detailed, an appropriate extension to PIDF for carrying geopriv location objects will be defined, if possible. 5. Security Considerations Geopriv information, like presence information, has very sensitive security requirements. The requirements of RFC2779 [3], which are followed by CPP, PIDF and SIMPLE, map well onto the security requirements of the geopriv protocol, as defined in the geopriv requirements document and the geopriv threat analysis [12] document. Peterson Expires August 25, 2003 [Page 6] Internet-Draft pres enumservice February 2003 Specifically, the presence security requirements call for authentication of watchers, integrity and confidentiality properties, and similar measures to prevent abuse of presence information. 6. IANA Considerations This document introduces no considerations for the IANA. Informative References [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work in progress), February 2003. [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [4] Crocker, D. and J. Peterson, "A Model for Presence and Instant Messaging", draft-ietf-impp-pres-02 (work in progress), February 2003. [5] Crocker, D. and J. Peterson, "Address Resolution for Instant Messaging and Presence", draft-ietf-impp-srv-02 (work in progress), February 2003. [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "CPIM Presence Information Data Format", draft- ietf-impp-cpim-pidf-07 (work in progress), August 2001. [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [8] Roach, A., "Session Initiation Protocol(SIP)-Specific Event Notification", RFC 3265, June 2002. [9] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), Jan 2003. [10] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in SIMPLE Systems", draft-ietf-simple-data-reqs- 00 (work in progress), October 2002. [11] Campbell, B., Olson, S., Peterson, J., Rosenberg, J. and B. Peterson Expires August 25, 2003 [Page 7] Internet-Draft pres enumservice February 2003 Stucker, "SIMPLE Presence Publication Mechanism", Internet- Draft draft-ietf-simple-publish-00, February 2003. [12] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat Analysis of the geopriv Protocol", draft-ietf-geopriv-threats- 00 (work in progress), February 2003. [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Author's Address Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Appendix A. To Do This document will evolve as the geopriv location object format is more fully specified. Peterson Expires August 25, 2003 [Page 8] Internet-Draft pres enumservice 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. Peterson Expires August 25, 2003 [Page 9]