summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6447.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6447.txt')
-rw-r--r--doc/rfc/rfc6447.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc6447.txt b/doc/rfc/rfc6447.txt
new file mode 100644
index 0000000..f986341
--- /dev/null
+++ b/doc/rfc/rfc6447.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Mahy
+Request for Comments: 6447 Individual
+Category: Standards Track B. Rosen
+ISSN: 2070-1721 NeuStar
+ H. Tschofenig
+ Nokia Siemens Networks
+ January 2012
+
+
+ Filtering Location Notifications in
+ the Session Initiation Protocol (SIP)
+
+Abstract
+
+ This document describes filters that limit asynchronous location
+ notifications to compelling events. These filters are 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).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6447.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 1]
+
+RFC 6447 Location Filters January 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 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 Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 5
+ 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
+ 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
+ 6.1. URN Sub-Namespace Registration for
+ urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16
+ 6.2. Schema Registration for location-filter . . . . . . . . . 16
+ 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 2]
+
+RFC 6447 Location Filters January 2012
+
+
+1. Introduction
+
+ Conveying location information encapsulated with a Presence
+ Information Data Format Location Object (PIDF-LO) [RFC4119] document
+ within SIP is described in [SIP-LOC]. An alternative signaling
+ approach to location conveyance, which uses asynchronous
+ communication, is available with the SIP event notification
+ mechanisms (see RFC 3265 [RFC3265]). This approach conveys location
+ information in PIDF-LO format using the presence event package
+ [RFC3856]. This document focuses on the event notification paradigm.
+
+ Determining when to send event notifications with location
+ information is technically more challenging than deciding when to
+ send other categories of notifications, since location may be
+ measured as a continuous gradient. Unlike notifications using
+ discrete-valued quantities, it is difficult to know when a change in
+ location is sufficiently large to warrant a notification. Event
+ notifications [RFC3265] can be used with filters (see RFC 4661
+ [RFC4661]) that allow the number of notifications to be reduced. The
+ mechanism described in this document defines an extension to RFC 4661
+ [RFC4661], which limits location notification to events that are of
+ relevance to the subscriber. These filters persist until they are
+ replaced with a newer filter or until the subscription itself is
+ terminated.
+
+ 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 being flooded with a large number of
+ notifications that are not important to the application.
+
+ This document defines new event filters and describes others using
+ existing mechanisms that may be relevant to a subscriber in the
+ context of location filtering. Based on the functionality defined in
+ this document, notifications can be provided in the following cases:
+
+ 1. the Target moves more than a specified distance since the last
+ notification (see Section 3.1).
+
+ 2. the Target exceeds a specified speed (see Section 3.2).
+
+ 3. the Target enters or exits a 2-dimensional region, described by a
+ circle or a polygon (see Section 3.4).
+
+ 4. one or more of the values of the specified civic location have
+ changed for the location of the Target (see Section 3.3). For
+ example, the value of the civic address '<A1>' element has
+ changed from 'California' to 'Nevada'.
+
+
+
+Mahy, et al. Standards Track [Page 3]
+
+RFC 6447 Location Filters January 2012
+
+
+ 5. the type of location information requested (see Section 3.5)
+ changes, for example, from civic to geodetic location or vice
+ versa.
+
+ 6. a certain amount of time passes (see Section 3.6).
+
+2. 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 RFC 2119 [RFC2119].
+
+ This document reuses terminology from [RFC6280].
+
+3. Filter Definitions
+
+ This specification builds on a number of other specifications, as
+ noted in Section 1. In order to reduce the number of options (and
+ thereby decrease the chance of interoperability problems), the
+ functionality described in the following sub-sections of [RFC4661]
+ MUST be implemented: the <ns-bindings> element (see Section 3.3 of
+ [RFC4661]); the <filter> element (Section 3.4 of [RFC4661]); and the
+ <trigger> element (Section 3.6 of [RFC4661]), except for the <added>
+ and <removed> sub-elements.
+
+3.1. Movement
+
+ The <moved> element MUST contain a value in meters indicating 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. The distance MUST be measured in meters
+ absolutely from the point of the last notification, and must include
+ vertical movement. 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
+
+
+
+
+Mahy, et al. Standards Track [Page 4]
+
+RFC 6447 Location Filters January 2012
+
+
+3.2. Speed Changes
+
+ 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 [RFC5962]. The value of the
+ <speed> element from [RFC5962] MUST be defined in meters per second.
+ Note that the condition could be met by a change in any axis,
+ including altitude.
+
+ Figure 2 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 <ns-bindings> to replace the namespace
+ prefix. The XPath expression MUST start with a '//' followed by a
+ single element. No other form of XPath expression is supported. The
+ <changed> element comes with a few attributes but only the 'by'
+ attribute MUST be implemented by this specification.
+
+3.3. Element Value Changes
+
+ Changes in values, for example related to civic location information,
+ is provided by the base functionality offered with RFC 4661 utilizing
+ the <changed> element.
+
+ The following example illustrates a filter that triggers when the
+ Target's location changes from 'FR' (France) to some other country.
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 5]
+
+RFC 6447 Location Filters January 2012
+
+
+ <?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 3: Element Value Change Example (Country Change)
+
+ At times when it is desirable to know if any one element of a list of
+ CAtypes changes, then they have to be put into separate <changes>
+ filters to ensure the subscriber is notified when any of the element
+ values change. Figure 4 shows such an example that illustrates the
+ difference.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 6]
+
+RFC 6447 Location Filters January 2012
+
+
+ (A change in value of ANY of the five tokens triggers an event.)
+
+ <?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:country</changed>
+ </trigger>
+ <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
+
+ Finally, Figure 5 shows an example where a notification is sent when
+ the civic address tokens A3 and PC change (BOTH elements must change
+ in order to let the <trigger> element evaluate to TRUE).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 7]
+
+RFC 6447 Location Filters January 2012
+
+
+ (Only a change in BOTH tokens triggers an event.)
+
+ <?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:A3</changed>
+ <changed>//ca:PC</changed>
+ </trigger>
+ </filter>
+ </filter-set>
+
+ Figure 5: Element Value Change Example
+
+ Note: The civic address tokens country, A1, A2, ..., A6 are
+ hierarchical. It is likely that a change in one civic address token
+ therefore leads to changes of tokens lower in the hierarchy, e.g., a
+ change in A3 ('city or town') may cause a change in A4, A5, and A6.
+
+ An implementation MUST support <ns-bindings> to replace the namespace
+ prefix. The XPath expression MUST start with a '//' followed by a
+ single element. No other form of XPath expression is supported. 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.
+
+3.4. Entering or Exiting a Region
+
+ The <enterOrExit> condition is satisfied when the Target enters or
+ exits a 2-dimensional region described by a polygon (as defined in
+ Section 5.2.2 of [RFC5491]) or a circle (as defined in Section 5.2.3
+ of [RFC5491]). 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
+
+
+
+Mahy, et al. Standards Track [Page 8]
+
+RFC 6447 Location Filters January 2012
+
+
+ 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]). The benefit
+ of this is that notifications are naturally limited: small movements
+ (relative to the uncertainty of the location) at the borders of the
+ region do not trigger notifications.
+
+ Figure 6 shows filter examples whereby a notification is sent when
+ the Target enters or exits an area described by a circle, and
+ Figure 7 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 9]
+
+RFC 6447 Location Filters January 2012
+
+
+ <?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
+
+3.5. Location Type
+
+ The <locationType> element MAY be included as a child element of the
+ <what> element. 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 location information in
+ all forms available to it.
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 10]
+
+RFC 6447 Location Filters January 2012
+
+
+ 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 civic and geodetic location information
+ in the response in the same order in which they were included in the
+ "locationType" element in the request, if both were explicitly
+ requested. 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:
+
+ o civic
+
+ o civic, geodetic
+
+ o geodetic (only if civic is not available)
+
+ 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 that utilizes the <locationType>
+ element with the 'exact' attribute.
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 11]
+
+RFC 6447 Location Filters January 2012
+
+
+ <?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
+
+3.6. Rate Control
+
+ [RFC6446] extends the SIP events framework by defining three Event
+ header field parameters that allow a subscriber to set a minimum, a
+ maximum, and an adaptive minimum 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-rate" (which specifies a minimum
+ notification rate per second) and "max-rate" (which specifies a
+ maximum notification rate per second) are used by this document.
+ Only the implementation of these two attributes is required from the
+ attributes defined in [RFC6446]. Whenever the time since the most
+ recent notification exceeds the interval corresponding to 1 / "min-
+ rate", the current state would be sent in its entirety, just like
+ after a subscription refresh.
+
+ A notifier is required to send a NOTIFY request immediately after
+ creation of a subscription. If state is not available at that time,
+ then the NOTIFY request may be sent with no content. A separate
+ NOTIFY containing location is subsequently generated so that the rate
+ of notification since the last NOTIFY falls between "min-rate" and
+ "max-rate". 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.
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 12]
+
+RFC 6447 Location Filters January 2012
+
+
+ Subscriber Notifier
+ |---SUBSCRIBE(1)--->| Create subscription (w/large value
+ |<-------200--------| for min-rate and max-rate)
+ |<-----NOTIFY(2)----| Return initial notify with no state
+ |--------200------->|
+ | ... |
+ |<-----NOTIFY(3)----| Return full state (between min-rate
+ |--------200------->| and max-rate)
+ |---SUBSCRIBE(4)--->| Update subscription (to update
+ |<-------200--------| min-rate and max-rate)
+
+ Figure 9: SUBSCRIBE/NOTIFY with Rate Control
+
+ Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE
+ message (1) has filters attached and contains a "min-rate" 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 could be available at a later point in time. An
+ example is emergency call routing where an 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 contain a "min-rate" rate control parameter (with a large
+ value, corresponding to a very short delay before the next
+ notification) that is updated in a later message to a more sensible
+ value. This provides equivalent functionality to the 'responseTime'
+ attribute in Section 6.1 of [RFC5985]. The "min-rate" for this first
+ request is therefore much larger (much more rapid) than the updated
+ "min-rate" value. Depending on the value in the "min-rate"
+ parameter, the Notifier may immediately send the initial NOTIFY
+ message (see message 2) without a body if no location information is
+ available at this point in time. The desired location information
+ may then arrive in the subsequent NOTIFY message (see message 3).
+ Updating the "min-rate" for the subscription can be performed in the
+ 200 response (see message 3) to the NOTIFY that contains location
+ state, or in a subsequent SUBSCRIBE request (as in message 4).
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 13]
+
+RFC 6447 Location Filters January 2012
+
+
+4. XML Schema
+
+ <?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>
+
+
+
+Mahy, et al. Standards Track [Page 14]
+
+RFC 6447 Location Filters January 2012
+
+
+ <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
+
+5. Security Considerations
+
+ This document specifies one element, namely filters, utilized in
+ larger systems. As such, this document builds on a number of
+ specifications for the security of the complete solution, namely
+
+ o the SIP event notification mechanism, described in RFC 3265
+ [RFC3265], defining the SUBSCRIBE/NOTIFY messages.
+
+ o the presence event package, described in RFC 3856 [RFC3856], which
+ is a concrete instantiation of the general event notification
+ framework.
+
+ o the filter framework, described in RFC 4661 [RFC4661], to offer
+ the ability to reduce the amount of notifications being sent.
+
+ Finally, this document indirectly (via the SIP presence event
+ package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the
+ XML container that carries location information.
+
+ Each of the documents listed above comes with a Security
+ Considerations section but the security and privacy aspects are best
+ covered by the SIP presence event package; see Section 9 of
+ [RFC3856], and with the GEOPRIV architectural description found in
+ [RFC6280].
+
+ The functionality offered by authorization policies to limit access
+ to location information is provided by other protocols, such as
+ Common Policy [RFC4745], Geolocation Policy [GEO-POLICY], or more
+ recent work around HTTP-Enabled Location Delivery (HELD) context
+ [HELD]. Although [GEO-POLICY] 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
+
+
+
+Mahy, et al. Standards Track [Page 15]
+
+RFC 6447 Location Filters January 2012
+
+
+ associated with the usage of certain filter constructs and with the
+ amount of notifications that 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 authorized. RFC 4661 [RFC4661] discusses this security threat
+ and proposes authentication and authorization solutions applicable to
+ this specification.
+
+6. IANA Considerations
+
+6.1. URN Sub-Namespace Registration for
+ urn:ietf:params:xml:ns:location-filter
+
+ This section registers a new XML namespace, as per the guidelines in
+ [RFC3688].
+
+ 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="http://www.rfc-editor.org/rfc/rfc6447.txt">
+ RFC 6447</a>.</p>
+ </body>
+ </html>
+ END
+
+6.2. Schema Registration for location-filter
+
+ This specification registers a schema, as per the guidelines in
+ [RFC3688].
+
+
+
+
+Mahy, et al. Standards Track [Page 16]
+
+RFC 6447 Location Filters January 2012
+
+
+ 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.
+
+7. Contributors
+
+ We would like to thank Martin Thomson and James Polk for their
+ contributions to this document.
+
+8. Acknowledgments
+
+ Thanks to Richard Barnes, Alissa Cooper, Randall Gellens, Carl Reed,
+ Ben Campbell, Adam Roach, Allan Thomson, and James Winterbottom for
+ their comments.
+
+ Furthermore, we would like to thank Alexey Melnikov for his IESG
+ review comments.
+
+9. References
+
+9.1. Normative References
+
+ [GML] OpenGIS, "Open Geography Markup Language (GML)
+ Implementation Specification", OpenGIS OGC 02-023r4,
+ January 2003,
+ <http://www.opengis.org/techno/implementation.htm>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
+ Event Notification", RFC 3265, June 2002.
+
+ [RFC3856] Rosenberg, J., "A Presence Event Package for the
+ Session Initiation Protocol (SIP)", RFC 3856,
+ August 2004.
+
+ [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
+ Format", RFC 4119, December 2005.
+
+ [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J.
+ Costa-Requena, "An Extensible Markup Language (XML)-
+ Based Format for Event Notification Filtering",
+ RFC 4661, September 2006.
+
+
+
+
+Mahy, et al. Standards Track [Page 17]
+
+RFC 6447 Location Filters January 2012
+
+
+ [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig,
+ "GEOPRIV Presence Information Data Format Location
+ Object (PIDF-LO) Usage Clarification, Considerations,
+ and Recommendations", RFC 5491, March 2009.
+
+ [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
+ Thomson, "Dynamic Extensions to the Presence
+ Information Data Format Location Object (PIDF-LO)",
+ RFC 5962, September 2010.
+
+ [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+ Tschofenig, H., and H. Schulzrinne, "An Architecture
+ for Location and Location Privacy in Internet
+ Applications", BCP 160, RFC 6280, July 2011.
+
+ [RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
+ Protocol (SIP) Event Notification Extension for
+ Notification Rate Control", RFC 6446, January 2012.
+
+9.2. Informative References
+
+ [GEO-POLICY] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
+ Morris, J., and M. Thomson, "Geolocation Policy: A
+ Document Format for Expressing Privacy Preferences for
+ Location Information", Work in Progress, October 2011.
+
+ [HELD] Winterbottom, J., Tschofenig, H., and M. Thomson,
+ "Location URI Contexts in HTTP-Enabled Location
+ Delivery (HELD)", Work in Progress, October 2009.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
+ RFC 3688, January 2004.
+
+ [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.
+
+ [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
+ RFC 5985, September 2010.
+
+ [SIP-LOC] Polk, J., Rosen, B., and J. Peterson, "Location
+ Conveyance for the Session Initiation Protocol", Work
+ in Progress, September 2011.
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 18]
+
+RFC 6447 Location Filters January 2012
+
+
+Authors' Addresses
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al. Standards Track [Page 19]
+