| TOC |
|
This document describes filters that limit asynchronous location notifications to compelling events, designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO).
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, 2010.
Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
2.
Terminology
3.
Filter Definitions
3.1.
Movement
3.2.
Speed Changes
3.3.
Element Value Changes
3.4.
Entering or Exiting a Region
3.5.
Location Type
3.6.
Rate Control
4.
XML Schema
5.
Security Considerations
6.
IANA Considerations
6.1.
URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter
6.2.
Schema Registration For location-filter
7.
Contributors
8.
Acknowledgments
9.
References
9.1.
Normative References
9.2.
Informational References
§
Authors' Addresses
| TOC |
Conveying location information encapsulated with a PIDF-LO (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [RFC4119] document within SIP is described in [I‑D.ietf‑sipcore‑location‑conveyance] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” February 2010.). An alternative signaling approach, which uses asynchronous communication, is available with the SIP event notification mechanisms (see RFC 3265 [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.)). This document focuses on the event notification paradigm. Event notifications are technical more complex since location may be measured as a continuous gradient and unlike notifications using discrete-valued quantities, it is difficult to know when a change in location is large enough to warrant a notification. Event notifications [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) can be used with filters (see RFC 4661 [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.)) that allows the number of notifications to be reduced. The mechanism described in this document defines an extension to RFC 4661 [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.), which limits location notification to events that are of relevance to the subscriber. These filters persist until they are changed with a replacement filter.
The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without having to issue a large number of notifications that are not important to the application.
This document defines a new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering:
This document builds on the presence event package [RFC3856] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.), i.e. an existing event package for communicating location information inside the PIDF-LO.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
This document reuses terminology from [I‑D.ietf‑geopriv‑arch] (Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, “An Architecture for Location and Location Privacy in Internet Applications,” October 2009.).
| TOC |
This specification builds on top of a number of other specifications, as noted in Section 1 (Introduction). In order to reduce the number of options (and thereby decrease the chance of interoperability problems), the functionality of [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) listed in the sub-sections below MUST be implemented, namely the <ns-bindings> (see Section 3.3 of [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.)), the <filter> (Section 3.4 of [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.)), and the <trigger> (Section 3.6 of [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) excluding the functionality of the <added> and <removed> element).
| TOC |
The <moved> element MUST contain a value in meters indicates the minimum distance that the resource must have moved from the location of the resource since the last notification was sent in order to trigger this event. Note that the condition could be met by a change in any axis including altitude. The distance MUST be measured in meters absolutely from the point of last notification. The <moved> element MUST NOT appear more than once as a child element of the <filter> element.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:moved>300</lf:moved>
</trigger>
</filter>
</filter-set>
| Figure 1: Movement Filter Example |
| TOC |
Speed changes can be filtered by combining functionality from RFC 4661 with the PIDF-LO extensions for spatial orientation, speed, heading, and acceleration defined in [I‑D.singh‑geopriv‑pidf‑lo‑dynamic] (Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, “Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO),” March 2010.). The value of the <speed> element from [I‑D.singh‑geopriv‑pidf‑lo‑dynamic] (Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, “Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO),” March 2010.) MUST be defined in meters per second. Note that the condition could be met by a change in any axis including altitude.
Figure 2 (Speed Change Example) shows an example for a trigger that fires when the speed of the Target changes by 3 meters per second.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="dyn"
urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed by="3">
//dyn:speed
</changed>
</trigger>
</filter>
</filter-set>
| Figure 2: Speed Change Example |
An implementation MUST support the functionality as shown in Figure 2 (Speed Change Example) with <ns-bindings> replacing the prefix. No other variant is supported. The <changed> element comes with a few attributes but only the 'by' attribute MUST be implemented by this specification.
| TOC |
Changes in values, for example related to civic location information, is provided by the base functionality offered with RFC 4661 utilizing the <changed> element.
Figure 3 (Element Value Change Example) shows an example where a notification is sent when the civic address tokens A1, A2, A3, or PC change (all four must change in order to let the <trigger> element evaluate to TRUE).
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
<changed>//ca:A2</changed>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
| Figure 3: Element Value Change Example |
In times where it is desireable to know if any one element of a list of CAtypes changes, then they have to be put into separate <changes> filters to ensure you are notified when any of the element values change. Figure 4 (Element Value Change Example) shows such an example that illustrates the difference.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
| Figure 4: Element Value Change Example |
The following example illustrates a filter that triggers when the Target's location changes from 'FR' (France) to some other country.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
| Figure 5: Element Value Change Example (Country Change) |
An implementation MUST support the functionality as shown in Figure 3 (Element Value Change Example) with <ns-bindings> replacing the prefix. No other variant is supported. The <changed> element comes with a few attributes and the 'by', 'to' and 'from' attribute MUST be implemented to support this specification.
| TOC |
The <enterOrExit> condition is satisfied when the Target enters or exits a named 2-dimensional region described by a polygon (as defined in Section 5.2.2 of [RFC5491] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 2009.)), or a circle (as defined in Section 5.2.3 of [RFC5491] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 2009.)). The <enterOrExit> element MUST contain either a polygon or a circle as a child element. The <enterOrExit> element MUST NOT have more than one polygon and/or circle.
If the Target was previously outside the region, the notifier sends a notification when the Target's location is within the region with at least 50% confidence. Similarly, when a Target starts within the region, a notification is sent when the Target's location moves outside the region with at least 50% confidence.
Note that having 50% confidence that the Target is inside the area does not correspond to 50% outside. The confidence that the location is within the region, plus the confidence that the location is outside the region is limited to the confidence of the location. The total confidence depends on the confidence in the location, which is always less than 100% (95% is recommended in [RFC5491] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 2009.)). The benefit of this is that notifications are naturally limited: small movements at the borders of the region do not trigger notifications.
Figure 6 (<enterOrExit> Circle Filter Example) shows filter examples whereby a notification is sent when the Target enters or exits an area described by a circle and Figure 7 (<enterOrExit> Polygon Filter Example) describes an area using a polygon.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gs:Circle
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius
uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
| Figure 6: <enterOrExit> Circle Filter Example |
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
<gml:pos>43.111 -73.322</gml:pos>
<!--F-->
<gml:pos>43.111 -73.222</gml:pos>
<!--E-->
<gml:pos>43.311 -73.122</gml:pos>
<!--D-->
<gml:pos>43.411 -73.222</gml:pos>
<!--C-->
<gml:pos>43.411 -73.322</gml:pos>
<!--B-->
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
| Figure 7: <enterOrExit> Polygon Filter Example |
| TOC |
The <locationType> element MAY be included as a child element of the <what> element and it contains a list of location information types that are requested by the subscriber. The following list describes the possible values:
- any:
- The Notifier SHOULD attempt to provide LI in all forms available to it.
- geodetic:
- The Notifier SHOULD return a location by value in the form of a geodetic location.
- civic:
- The Notifier SHOULD return a location by value in the form of a civic address.
The Notifier SHOULD return the requested location type or types. The location types the Notifier returns also depends on the setting of the optional 'exact' attribute. If the 'exact' attribute is set to "true" then the Notifier MUST return either the requested location type or no location information. The 'exact' attribute does not apply (is ignored) for a request for a location type of "any".
In the case of a request for specific locationType(s) and the 'exact' attribute is "false", the Notifier MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type.
If the <locationType> element is absent, a value of "any" MUST be assumed as the default.
The Notifier SHOULD provide location in the response in the same order in which they were included in the "locationType" element in the request. Indeed, the primary advantage of including specific location types in a request when the 'exact' attribute is set to "false" is to ensure that one receives the available locations in a specific order. For example, a subscription for "civic" (with the 'exact' attribute set to "false") could yield any of the following location types in the response:
The default value of "false" for the 'exact' attribute allows the Notifier the option of returning something beyond what is specified, such as a set of location URIs when only a civic location was requested.
An example is shown in Figure 8 (<locationType> Filter Example) that utilizes the <locationType> element with the 'exact' and the 'responseTime' attribute.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true">
geodetic
</lf:locationType>
</what>
</filter>
</filter-set>
| Figure 8: <locationType> Filter Example |
| TOC |
[I‑D.ietf‑sipcore‑event‑rate‑control] (Niemi, A., Kiss, K., and S. Loreto, “Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control,” February 2010.) extends the SIP events framework by defining the following three "Event" header field parameters that allow a subscriber to set a minimum, a maximum and an average rate of event notifications generated by the notifier. This allows a subscriber to have overall control over the stream of notifications, for example to avoid being flooded. Two of the parameters, namely "min-interval" (which specifies a minimum notification time period between two notifications, in seconds) and "max-interval" (which specifies a maximum notification time period between two notifications, in seconds.) are used by this document. The implementation of only these two attributes is required from the complete set of attributes defined in [I‑D.ietf‑sipcore‑event‑rate‑control] (Niemi, A., Kiss, K., and S. Loreto, “Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control,” February 2010.). Whenever the time since the most recent notification exceeds the value in the "max-interval" parameter, the current state would be sent in its entirety, just like after a subscription refresh.
If complete state is not immediately available, then an empty NOTIFY is sent immediately and subsequently a separate NOTIFY containing location is generated some time between the time included in 'min-interval' and the time in 'max-interval'. An important use case for location based applications focuses on the behavior of the initial NOTIFY message(s) and the information it returns, for example in case of emergency call routing. When an initial NOTIFY is transmitted it might not include complete state.
Subscriber Notifier
|---SUBSCRIBE(1)--->| Request state subscription
|<-------200--------| Acknowledge subscription
|<-----NOTIFY(2)----| Return current state information
|-------200(3)----->|
|<-----NOTIFY(4)----| Return current state information
|--------200------->|
| Figure 9: SUBSCRIBE/NOTIFY with Rate Control |
Figure 9 (SUBSCRIBE/NOTIFY with Rate Control) shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE message (1) has filters attached and contains a 'max-interval' rate control parameter. In certain situations it is important to obtain some amount of location information within a relatively short and pre-defined period of time even if the obtained location information contains a high amount of uncertainty and location information with less uncertainty at a later point in time. An example is emergency call routing where a emergency services routing proxy may need to obtain location information suitable for routing rather quickly and subsequently a Public Safety Answering Point requests location information for dispatch.
To obtain location information in a timely fashion using the SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial SUBSCRIBE contains a 'max-interval' rate control parameter (with a small value) that is in a later message updated to a more sensible value. The 'max-interval' for this first request is therefore much lower than thereafter. Updating the 'max-interval' for the subscription can be performed in the 200 response (see message 3) to the NOTIFY that contains state. Depending on the value in the 'max-interval' parameter the Notifier may create a NOTIFY message (see message 2) immediately in response to the SUBSCRIBE that might be empty in case no location information is available at this point in time. The desired location information may then arrive in the subsequent NOTIFY message (see message 4).
| TOC |
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:location-filter"
xmlns:filter="urn:ietf:params:xml:ns:location-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml">
<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
<xs:element name="moved" type="filter:movedType"/>
<xs:complexType name="movedType">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="locationType" type="filter:locationTypeType"/>
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="filter:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
| Figure 10: XML Schema |
| TOC |
This document specifies one piece, namely filters, utilized in larger system. As such, this document builds on a number of specifications for the security of the complete solution, namely
Finally, this document indirectly (via the SIP presence event package) relies on PIDF-LO, described in RFC 4119 [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.), as the XML container that carries location information.
Each of these documents listed above comes with a security consideration section but the security and privacy aspects are best covered by the SIP presence event package, see Section 9 of [RFC3856] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.), and with the GEOPRIV architectural description found in [I‑D.ietf‑geopriv‑arch] (Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, “An Architecture for Location and Location Privacy in Internet Applications,” October 2009.).
The functionality offered by authorization policies to limit access to location information are provided by other protocols, such Common Policy [RFC4745] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, “Common Policy: A Document Format for Expressing Privacy Preferences,” February 2007.), Geolocation Policy [I‑D.ietf‑geopriv‑policy] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, “Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information,” January 2010.) or more recent work around HELD context [I‑D.winterbottom‑geopriv‑held‑context] (Winterbottom, J., Tschofenig, H., and M. Thomson, “Location URI Contexts in HTTP-Enabled Location Delivery (HELD),” October 2009.). Although [I‑D.ietf‑geopriv‑policy] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, “Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information,” January 2010.) defines a standardized format for geolocation authorization policies it does not define specific policies for controlling filters.
The functionality described in this document extends the filter framework with location specific filters. Local policies might be associated with the usage of certain filter constructs and with the amount of notifications specific filter settings might cause. Uploading filters have a significant effect on the ways in which the request is handled at a server. As a result, it is especially important that messages containing this extension be authenticated and authorised. RFC 4661 [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) discusses this security threat and proposed authentication and authorization solutions applicable by this specification.
| TOC |
| TOC |
This section registers a new XML namespace, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).
- URI:
- urn:ietf:params:xml:ns:location-filter
- Registrant Contact:
- IETF, GEOPRIV working group, <geopriv@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
- XML:
BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Location Filter Namespace</title> </head> <body> <h1>Namespace for PIDF-LO Location Filters</h1> <h2>urn:ietf:params:xml:ns:location-filter</h2> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> </body> </html> END
| TOC |
This specification registers a schema, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).
- URI: urn:ietf:params:xml:schema:location-filter
- Registrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).
- XML: The XML can be found as the sole content of Section 4 (XML Schema).
| TOC |
We would like to thank Martin Thomson and James Polk for their contributions to this document.
| TOC |
Thanks to Richard Barnes and Alissa Cooper, Randall Gellens, Carl Reed, Adam Roach, Allan Thomson, James Winterbottom for their comments.
Furthermore, we would like to thank Alexey Melnikov for his IESG review comments.
| TOC |
| TOC |
| TOC |
| [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-16 (work in progress), August 2009 (TXT). |
| [I-D.ietf-geopriv-policy] | Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, “Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information,” draft-ietf-geopriv-policy-21 (work in progress), January 2010 (TXT). |
| [I-D.ietf-sipcore-location-conveyance] | Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” draft-ietf-sipcore-location-conveyance-02 (work in progress), February 2010 (TXT). |
| [I-D.winterbottom-geopriv-held-context] | Winterbottom, J., Tschofenig, H., and M. Thomson, “Location URI Contexts in HTTP-Enabled Location Delivery (HELD),” draft-winterbottom-geopriv-held-context-05 (work in progress), October 2009 (TXT). |
| [RFC3688] | Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT). |
| [RFC4745] | Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, “Common Policy: A Document Format for Expressing Privacy Preferences,” RFC 4745, February 2007 (TXT). |
| TOC |
| Rohan Mahy | |
| Individual | |
| Email: | rohan@ekabal.com |
| Brian Rosen | |
| NeuStar | |
| 470 Conrad Dr. | |
| Mars, PA 16046 | |
| US | |
| Phone: | +1 724 382 1051 |
| Email: | br@brianrosen.net |
| Hannes Tschofenig | |
| Nokia Siemens Networks | |
| Linnoitustie 6 | |
| Espoo 02600 | |
| Finland | |
| Phone: | +358 (50) 4871445 |
| Email: | Hannes.Tschofenig@gmx.net |
| URI: | http://www.tschofenig.priv.at |