Geopriv WG James Polk Internet-Draft Cisco Systems Expires: September 4, 2009 March 4, 2009 Intended Status: Standards Track (PS) Retrieving Specific Location from a Remote Entity using Session Initiation Protocol (SIP) Subscription Filters and Notifications draft-polk-geopriv-include-exclude-filters-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 4, 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 Polk Expires September 4, 2009 [Page 1] Internet-Draft Geopriv Include/Exclude Filters March 2009 rights and restrictions with respect to this document. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document creates and describes the SIP subscription filters necessary to acquire the desired location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) from a remote SIP user agent (UA). 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 [RFC 2119]. 1. Introduction Conveying the location of a SIP user agent (UA) towards another entity is defined in [ID-SIP-LOC]. SIP conveys location in two ways, by-value and by-reference. By-value is accomplished by sending a Presence Information Data Format - Location Object (PIDF-LO) [RFC4119] towards another entity. By-reference is accomplished by sending a location URI towards another entity, one that is then dereferenced by the receiving entity to attain the sending entity's location. This dereferencing also results in a PIDF-LO being sent to the dereferencing entity. This document creates and describes SIP subscription filters necessary to acquire the desired location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) from a remote SIP user agent (UA). This is sufficiently different than what is described in [ID-FILTERS] because that document focuses solely on (to quote the abstract of that doc): "This document describes filters which limit asynchronous Location notifications to compelling events." This document is not concerned with limiting anything, nor is it concerned with anything asynchronous, nor does this document concern itself with compelling events (such as Location Target movement). Polk Expires September 4, 2009 [Page 2] Internet-Draft Geopriv Include/Exclude Filters March 2009 This document focuses on the basics of these questions: o How do I ask for another entity's location? o How do I indicate I want that location returned in a certain format? o How can I tell the other entity I need X parts of location from them, and (I might) want Y more (which are not as necessary)? o How can I indicate I must have a minimum set of location elements, otherwise I need to receive an error? All of this is founded on the mechanisms defined in [RFC4661], XML based Subscription Filters. This document will create a set of location filters for acquiring location from another entity, to the point of specifically requesting which location elements are to be in the reply. Subscription replies are sent in SIP NOTIFYs. This document does not concern itself with the frequency of these notifies, as that is addressed here [ID-THROTTLE]. Nor is this document concerned with asynchronous location notifications to compelling events, as that is defined in [ID-LOC-FILTERS] - which has this limitation upon itself in its definitions section: "Notifications should only happen when the notification would be considered an Interesting Event to the subscriber." The mechanism in described in this document is simply a basic location retrieval mechanism. Presence is all about 'willingness to communicate'. The Presence event package is used here because the sensitivity of this information, i.e., where the user is located, might (some say will) affect the willingness to communicate with the seeking user. 2. Definition of the Filter for Location Retrieval Users wanting to learn where another user is varies upon the conditions of both what the seeking user wants to learn (to what degree of precision) and what the asked user is willing to reveal about their location. We can define here a simple "tell me where you are" filter (which we do define in this document), but the answer can be tailored to suit the location seeker based on what they want to receive. For example, o what format of location is being asked? Not all location seekers are going to want the location reply in the same location format (i.e., civic instead of geo). A means Polk Expires September 4, 2009 [Page 3] Internet-Draft Geopriv Include/Exclude Filters March 2009 if identifying which format is wanted optimizes this request. o what location elements are wanted? Specifics such as altitude may not be included normally by the Location Target, but the seeker could want to learn this about the Target. Perhaps specific elements sought are not hierarchical, such as wanting to learn only the country, city, floor and office number of a Target, and no other information. This reduces the bandwidth necessary for the reply (albeit only slightly), but it does concisely indicate exactly what is desired to satisfy the location request, which should prevent additional requests in the hope that other information is provided (that was not the first time). Another reason for the ability to specify specific location elements in the reply is a case in which the only thing wanted is the floor of a building, or the store in a shopping mall. o what level of precision of location is being sought? Perhaps the location seeker wants to learn the Target's location to the cube or office level, or the seeker only wants to find out what city it is in. Another reason for this is a case in which the only thing wanted is the floor of a building or the store in a shopping mall. Of course, all inquiries are subject to the rules and policies of the Ruleholder (which is the location service provider, the user, or a combination). Currently, PIDF-LO can provide location in two location formats, Geo and Civic. Sometimes, the location seeker can support one format, but not the other. Specifying in the location query which format is needed in the reply will make for fewer replies. Not having the ability to specify which format is sought will likely result in only one format being in the reply, ever, even in situations where the asked user knows its location in both formats. This likely will not be a common occurrence, but will prevent good communication even time it does happen to be the case. Taking this one step further, another capability is to allow the location seeking user the ability to ask for specific location elements in the reply to be mandatory, and some to be only desirable in the reply. 2.1 Location in Any Format Desired The ability to request location be returned in any format (geo or civic) is discussed here. Specifically, the filter includes both formats. Polk Expires September 4, 2009 [Page 4] Internet-Draft Geopriv Include/Exclude Filters March 2009 2.2 Geo-Only Location Format Desired The ability to request location be returned in either 2-dimensional (2D) or 3-dimensional (3D) geo format is discussed here. Specifically, the filter includes the geo, and excludes the civic. Each subsection here contains a unique facet of geo location, comprising the following characteristics: - either 2D or 3D - 2D only - 3D only, with altitude in various indications - in meters - in kilometers - 2D only, as a polygon (i.e., a 4+ point Linear Ring) - 3D only, as a polygon (i.e., a 4+ point Linear Ring) 2.3 Civic-Only Location Desired - Unspecified civic location - Specific Civic Location Elements Desired, some considered optional - Minimum group of civic location elements, or return a failure 2.4 Multi-Format Location Desired - Parts of Geo and parts of civic in the same location filter - 2D geo only, with altitude in floors TBD 3. Geo Examples 3.1 Example of Location in Any Format Desired For any location format to be returned, each (geo and civic) is listed as a separate element. Polk Expires September 4, 2009 [Page 5] Internet-Draft Geopriv Include/Exclude Filters March 2009 /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/c1:civilAddress /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/gml:location 3.2 Geo-Only Location in 2D or 3D Format Desired TBD /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/gml:location /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/c1:civilAddress Polk Expires September 4, 2009 [Page 6] Internet-Draft Geopriv Include/Exclude Filters March 2009 3.3 Example for coordinates in 2D The ability to request location be returned in 2-dimensional (2D) geo format is discussed here. Specifically, the filter includes both formats. TBD /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/gml:location /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/c1:civilAddress 3.4 Example for coordinates in 3D, altitude in meters 3.5 Example of 2D Linear Ring TBD For a 2D Linear Ring Polk Expires September 4, 2009 [Page 7] Internet-Draft Geopriv Include/Exclude Filters March 2009 3.4 Example of TBD 4. Civic-Only Location Desired /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/c1:civilAddress /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/gml:location 5. XML Schema for Location Filter Format TBD 6. Security considerations TBD 7. IANA considerations This document has IANA actions... Polk Expires September 4, 2009 [Page 8] Internet-Draft Geopriv Include/Exclude Filters March 2009 8. Acknowledgments Special thanks to Adam Roach and Rohan Mahy for their guidance in this effort. 9. References 9.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC4661] H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", RFC 4661, September 2006 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-sip-location-conveyance-12.txt, "work in progress", Oct 2008 [ID-Filters] R. Mahy, B. Rosen, " Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", "work in progress", Nov 2008 [ID-THROTTLE] [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 9.2. Informative References [] Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Polk Expires September 4, 2009 [Page 9]