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 <FLR>
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 <include> element.
Polk Expires September 4, 2009 [Page 5]
Internet-Draft Geopriv Include/Exclude Filters March 2009
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="cl"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
<ns-binding prefix="gml"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:gml"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/c1:civilAddress
</include>
<include type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/gml:location
</include>
</what>
</filter>
</filter-set>
3.2 Geo-Only Location in 2D or 3D Format Desired
TBD
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="cl"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
<ns-binding prefix="gml"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:gml"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/gml:location
</include>
<exclude type="xpath">
/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
</exclude>
</what>
</filter>
</filter-set>
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
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="cl"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
<ns-binding prefix="gml"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:gml"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/gml:location
</include>
<exclude type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/c1:civilAddress
</exclude>
</what>
</filter>
</filter-set>
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
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="cl"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
<ns-binding prefix="gml"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:gml"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/c1:civilAddress
</include>
<exclude type="xpath">
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/gml:location
</exclude>
</what>
</filter>
</filter-set>
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]