draft-ietf-geopriv-loc-filters-03.txt   draft-ietf-geopriv-loc-filters-04.txt 
geopriv R. Mahy GEOPRIV R. Mahy
Internet-Draft Plantronics Internet-Draft Plantronics
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen, Ed.
Expires: May 7, 2009 NeuStar Expires: January 14, 2010 NeuStar
November 3, 2008 H. Tschofenig
Nokia Siemens Networks
July 13, 2009
A Document Format for Filtering and Reporting Location Notications in A Document Format for Filtering and Reporting Location Notications in
the Presence Information Document Format Location Object (PIDF-LO) the Presence Information Document Format Location Object (PIDF-LO)
draft-ietf-geopriv-loc-filters-03 draft-ietf-geopriv-loc-filters-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on January 14, 2010.
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 rights
and restrictions with respect to this document.
Abstract Abstract
This document describes filters which limit asynchronous location This document describes filters that limit asynchronous location
notifications to compelling events. The resulting location notifications to compelling events, designed as an extension to RFC
information is conveyed in existing location formats wrapped in 4661 "An XML-Based Format for Event Notification Filtering". The
GEOPRIV privacy extensions to the Presence Information Document resulting location information is conveyed in existing location
Format (PIDF-LO) formats wrapped in the Presence Information Document Format
(PIDF-LO).
Table of Contents Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Location Filter Format . . . . . . . . . . . . . 3 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Horizontal and Vertical Movement . . . . . . . . . . . . . 4 3.1. Horizontal and Vertical Movement . . . . . . . . . . . . . 5
3.2. Changes in value . . . . . . . . . . . . . . . . . . . . . 5 3.2. Changes in Speed . . . . . . . . . . . . . . . . . . . . . 5
3.3. Containment Within a Region . . . . . . . . . . . . . . . 6 3.3. Changes in Value . . . . . . . . . . . . . . . . . . . . . 6
3.4. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Enter or Exit a Region . . . . . . . . . . . . . . . . . . 7
3.5. XML Schema for filter format . . . . . . . . . . . . . . . 9 4. Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Containment schema . . . . . . . . . . . . . . . . . . . . . . 12 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. MIME Registration for 7.1. Content-type registration for
application/location-delta-filter+xml . . . . . . . . . . 16 'application/location-delta-filter+xml' . . . . . . . . . 12
6.2. URN Sub-Namespace Registration for 7.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 13
6.3. Schema Registration For location-filter . . . . . . . . . 17 7.3. Schema Registration For location-filter . . . . . . . . . 14
6.4. URN Sub-Namespace Registration for 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Schema Registration For containment . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Informational References . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informational References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Conventions 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview
Conveying static location in PIDF-LO [RFC4119] bodies is
straightforward. However the difficult part about asynchronous
notification of location information is that many forms of location
are measured as a continuous gradient. Unlike notifications using
discreet quantities, it is difficult to know when a change in
location is large enough to warrant a notification. Moreover,
different applications require a wide variety of location
resolutions. Any optimization made for one application would
ultimately result in wasteful polling or a sluggish user interface
for other applications.
The mechanism described here defines filters in XML [W3C.REC-xml]
documents which limit location notification to events which are of
relevance to the subscriber. These filters persist until they are
changed with a replacement filter.
In addition to the relevant filters, this document also defines a new 2. Introduction
XML schema [W3C.REC-xmlschema-1] which can be included in PIDF-LO
documents to indicate that the resource is inside or outside of a
container region.
3. Definition of Location Filter Format Conveying location in PIDF-LO [RFC4119] bodies is described in
[I-D.ietf-sip-location-conveyance]. Asynchronous notification of
location information is unfortunately more complex since many forms
of location are measured as a continuous gradient. Unlike
notifications using discret quantities, it is difficult to know when
a change in location is large enough to warrant a notification. The
mechanism described in this document defines filters as 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 changed with a replacement filter.
The granularity of notifications necessary for various geographic The frequency of notifications necessary for various geographic
location applications varies dramatically. The subscriber should be location applications varies dramatically. The subscriber should be
able to get asynchronous notifications with appropriate granularity able to get asynchronous notifications with appropriate frequency and
and accuracy, without having to poll or flood the network with granularity, without having to issue a large number of notifications
notifications which are not important to the application. that are not important to the application. This section of this
Notifications should only happen when the notification would be document defines an extension to [RFC4661]'s TriggerType element to
considered an Interesting Event to the subscriber. This section of describe interesting conditions or events. The terminal elements in
this document defines an XML filter format to describe interesting this format are utilizing Geographic Markup Language (GML) [GML] data
conditions or events. The terminal elements in this format are types and civic address elements.
defined in terms of existing Geographic Markup Language (GML) [GML]
data types or civic address elements.
This document also defines a MIME type for this location filter This document also defines a MIME type for this location filter
format: application/location-delta-filter+xml. format, namely 'application/location-delta-filter+xml'.
This document defines the following as an initial list of Interesting This document defines the following as an initial list of events that
Events: could be interesting to a subscriber:
1. the resource moves more than a specific distance horizontally or
1. the Target moves more than a specified distance horizontally or
vertically since the last notification vertically since the last notification
2. the resource exceeds a specific speed
3. the resource enters or exits one or more GML objects (for
example, a set of 2-dimensional or 3-dimensional regions)
included or referenced in the filter.
4. one or more of the values of the specified address labels has
changed for the resource (for example, the A1 value of the
civilAddress has changed from California to Nevada)
5. a mininum and maximum rate of reports regardless of movement
This specification makes use of XML namespaces [W3C.REC-xml-names]
for identifying location filter documents and document fragments.
The namespace URI for elements defined by this specification is a URN
[RFC2141], using the namespace identifier 'ietf' defined by [RFC2648]
and extended by [RFC3688]. This URN is:
urn:ietf:params:xml:ns:location-filter 2. the Target exceeds a specified speed
The filter format starts with a top-level XML element called 3. the Target enters or exits one or more GML objects (for example,
"<location-filter>", which contains one or more filter events. The a set of 2-dimensional or 3-dimensional regions) included or
semantics of multiple elements inside a location-filter generally is referenced in the filter.
a logical OR. In other words, if any of the individual filter events
occurs, the event satisfies the location-filter and triggers a 4. one or more of the values of the specified address labels has
notification. However the "maxRate" parameter is a logical AND, and changed for the location of the Target (for example, the value of
will limit events that otherwise would have been reported. the <A1> civic address element has changed from 'California' to
'Nevada')
3. Filter Definitions
3.1. Horizontal and Vertical Movement 3.1. Horizontal and Vertical Movement
The movedHoriz and movedVert filter events each indicate a minimum Changes in the position of the Target require extensions to the
horizontal motion or vertical distance (respectively) that the functionality of RFC 4661 and a simplying assumption. The former
resource must have moved from the location of the resource when the aspect refers to the need to enhance the capability to extract a
last notification was sent in order to trigger this event. The value from inside an XML element, in our example from the <pos>
distance is measured absolutely from the point of last notification element, which describes the user's location. Regarding the latter
rather than in terms of cumulative motion (For example, someone aspect we assume that the user's location information of any shape
pacing inside a room will not trigger an event if the trigger and uncertainty is converted into a point before the comparison
threshold is slightly larger than the room.) Each of these events regarding the movement with the previously notified location takes
can only appear once in a location-filter. These events have an place.
attribute "uom" (for "units of measure"), which indicates the units
of the element. The default unit for these events is meters.
Similarly, the speedExceeds filter event indicates a minimum The example shown in Figure 1 references the latitude value (using
horizontal speed of the resource before the speedExceeds event is the "gml:pos[1]" notation) and the 'by' attribute of the <changed>
triggered. This element can appear only once in a location-filter, element indicates the desired change that triggers a notification to
and has a "uom" attribute which defaults to meters per second if not be sent.
present.
This filter measures the horizontal component of speed in any <?xml version="1.0" encoding="UTF-8"?>
direction. It does not measure velocity. Note also that there is <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
no corresponding event triggered when speed drops below a <ns-bindings>
threshold. <ns-binding prefix="pidf"
urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="dyn"
urn="http://www.opengis.net/gml"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed by="100">
/pidf:presence/pidf:device/gp:geopriv/
gp:location-info/gml:Point/gml:pos[1]
</changed>
</trigger>
</filter>
</filter-set>
Below are some examples. In the first example if the resource moves Figure 1: Movement Filter Example
20m in the x,y direction or 3m in the z direction, send a
notification:
<location-filter> 3.2. Changes in Speed
<movedHoriz uom="urn:ogc:def:uom:EPSG::9001">20</movedHoriz>
<movedVert uom="urn:ogc:def:uom:EPSG::9001">3</movedVert>
</location-filter>
If the resource exceeds 3 meters per second (10.8 km/h), send a Speed changes can be filtered with the help of RFC 4661 and the
notification: functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which
extends the PIDF-LO with support for spatial orientation, speed,
heading, and acceleration.
<location-filter> Figure 2 shows an example for a trigger that fires when the speed of
<speedExceeds uom="#mps">3</speedExceeds> the Target changes by 20 meters per second.
</location-filter>
3.2. Changes in value <?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="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<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">
/pidf:presence/pidf:tuple/pidf:status/
gp:geopriv/gp:location-info/dyn:Dynamic/dyn:speed
</changed>
</trigger>
</filter>
</filter-set>
The valueChanges filter event contains a string which is interpreted Figure 2: Speed Change Example
as an XPath [W3C.xpath] expression evaluated within the context of
the location-info element of the PIDF-LO document which would be
generated by the notification. The XPath expression MUST evaluate to
only a single Xpath node. If the value of any of the elements in the
resulting node changes, then the filter event is triggered. Note
that the value of the resulting node changes if any of those nodes or
subnodes transitions from having a value to having no value or vice
versa. A location-filter may contain multiple valueChanges filters.
For example, given the following logical PIDF-LO document, If the 3.3. Changes in Value
state (A1), county (A2), city (A3), or postal code (PC) changes, send
a notification: Changes in values, for example related to civic location information,
can be provided by the base functionality offered with RFC 4661.
Figure 3 shows an example where a notification is sent when the civic
address tokens A1, A2, A3, or PC change.
PIDF-LO Location Document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" <ns-bindings>
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" <ns-binding prefix="pidf"
entity="pres:geotarget@example.com"> urn="urn:ietf:params:xml:ns:pidf"/>
<tuple id="sg89ae"> <ns-binding prefix="gp"
<status> urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<gp:geopriv> <ns-binding prefix="cl"
<gp:location-info> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
<cl:civilAddress> </ns-bindings>
<cl:country>US</cl:country> <filter id="123" uri="sip:presentity@example.com">
<cl:A1>NY</cl:A1> <trigger>
<cl:A3>New York</cl:A3> <changed>
<cl:RD>Broadway</cl:RD> /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
<cl:HNO>123</cl:HNO> gp:location-info/cl:civilAddress/cl:A1
<cl:UNIT>Suite 75</cl:UNIT> </changed>
<cl:PC>10027</cl:PC> <changed>
</cl:civilAddress> /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
</gp:location-info> gp:location-info/cl:civilAddress/cl:A2
<gp:usage-rules> </changed>
<gp:retransmission-allowed>yes</gp:retransmission-allowed> <changed>
<gp:retention-expiry>2003-06-23T04:57:29Z /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
</gp:retention-expiry> gp:location-info/cl:civilAddress/cl:A3
</gp:usage-rules> </changed>
</gp:geopriv> <changed>
</status> /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
<timestamp>2003-06-22T20:57:29Z</timestamp> gp:location-info/cl:civilAddress/cl:PC
</tuple> </changed>
</presence> </trigger>
</filter>
</filter-set>
Filter Document: Figure 3: Speed Change Example
<location-filter
xmlns="urn:ietf:params:xml:ns:location-filter"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc">
<valueChanges>cl:civilAddress/cl:A1</valueChanges>
<valueChanges>cl:civilAddress/cl:A2</valueChanges>
<valueChanges>cl:civilAddress/cl:A3</valueChanges>
<valueChanges>cl:civilAddress/cl:PC</valueChanges>
</location-filter>
3.3. Containment Within a Region 3.4. Enter or Exit a Region
The "enterOrExit" filter event is satisfied when the resource enters The <enterOrExit> condition is satisfied when the Target enters or
or exits a named 2-dimensional or 3-dimensional region described by exits a named 2-dimensional or 3-dimensional region described by a
one of the shapes defined in section 5 of polygon (as defined in Section 5.2.2 of [RFC5491]), or a circle (as
[I-D.ietf-geopriv-pdif-lo-profile]. These regions can be defined defined in Section 5.2.3 of [RFC5491]).
using inline snippets of GML, or externally referenced using a URI
(Uniform Resource Identifier).
These regions need a unique name or identifier so location with
respect to these regions can be described later (for example in a
notification). These regions are currently described as GML
Features so they can be named with a GML Name. Ideally each
region could be described instead as a GML geometry with some
associated name or identifier.
Any 2-dimensional region MUST be defined using the EPSG 4326 Figure 4 and Figure 5 shows filter examples whereby a notification is
coordinate reference system. Any 3-dimensional region MUST be sent when the Target enters or exits an area described by a circle
defined using the EPSG 4979 coordinate reference system. A location- and by a 3d polygon.
filter can contain more than one enterOrExit filter event.
Notifiers MAY support other more complex geometries or additional <?xml version="1.0" encoding="UTF-8"?>
coordinate reference systems. How the Subscriber negotiates <filter-set
support for more complex geometries or reference systems is out of xmlns="urn:ietf:params:xml:ns:simple-filter"
the scope of this document. xmlns:con="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
Likewise, this document does not describe how a subscriber xmlns:gml="http://www.opengis.net/gml"
discovers the existence of externally referenced features. This xmlns:gs="http://www.opengis.net/pidflo/1.0">
topic is out of scope of this document.
In most cases Subscribers that use location filters based on <filter id="123" uri="sip:presentity@example.com">
enterOrExit events are especially interested in the resource's <con:enterOrExit>
relationship to those named features. Consequently, the notifier <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
MUST include either a "containment" element for each feature <gml:pos>42.5463 -73.2512</gml:pos>
mentioned in the location-filter which has changed its containment <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
properties with respect to the resource since the last notification. 850.24
These elements are defined in Section 4. The notifier MAY include </gs:radius>
any other form of location that is relevant. </gs:Circle>
</con:enterOrExit>
</filter>
</filter-set>
For example, if the resource enters or exits Building 10 (which is Figure 4: <enterOrExit> (2D) Filter Example
defined by specific 2-D or 3-D rectangular coordinates), send a
notification:
Version in 2-Dimensions: <?xml version="1.0" encoding="UTF-8"?>
<location-filter> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
<enterOrExit> xmlns:con="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
<my:Building>
<gml:name>Building 10</gml:name>
<gml:extentOf>
<gml:Polygon
srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:posList
37.41188 -121.93243
37.41142 -121.93243
37.41142 -121.93132
37.41188 -121.93132
37.41188 -121.93243
</gml:posLis>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
</my:Building>
</enterOrExit>
</location-filter>
Version in 3-Dimensions: <filter id="123" uri="sip:presentity@example.com">
<location-filter> <con:enterOrExit>
<enterOrExit> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<my:Building>
<gml:name>Building 10</gml:name>
<gs:Prism
srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList> <gml:posList>
37.41188 -121.93243 0 43.311 -73.422 43.111 -73.322
37.41142 -121.93242 0 43.111 -73.222 43.311 -73.122
37.41142 -121.93132 0 43.411 -73.222 43.411 -73.322
37.41188 -121.93132 0 43.311 -73.422
37.41188 -121.93243 0
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gs:base> </con:enterOrExit>
<gs:height uom="urn:ogc:def:uom:EPSG::9001"> </filter>
24 </filter-set>
</gs:height>
</gs:Prism>
</my:Building>
</enterOrExit>
</location-filter>
If the resource enters or exits either the parking garage or any of
the conference rooms (both of which are externally defined), send a
notification:
<location-filter>
<enterOrExit>
<my:ParkingGarage
xlink:href="http://server.example.com/loc-defs/bldg-mgr/parking"/>
</enterOrExit>
<enterOrExit>
<my:ConferenceRooms
xlink:href="http://server.example.com/loc-defs/userdef/confrooms"/>
</enterOrExit>
</location-filter>
3.4. Rate Control
Although not part of the loc-filter function, the throttle mechanisms
[I-D.niemi-sipping-event-throttle] can be used to control the rate of
notifications. The "throttle", "force" and "average" settings can
filter notications by time
3.5. XML Schema for filter format
The XML Schema for this format is defined below.
<?xml version="1.0" encoding="UTF-8"?> Figure 5: <enterOrExit> (3D) Filter Example
<xs:schema
targetNamespace="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="location-filter"> 4. Rate Control
<xs:complexType>
<xs:sequence>
<xs:element name="movedHoriz" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="movedVert" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="speedExceeds" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<!-- this type needs to hold an XPath statement --> The throttle mechanisms [I-D.ietf-sipcore-event-rate-control] can be
<xs:element name="valueChanges" type="xs:string" used to control the rate of notifications. The "throttle", "force"
minOccurs="0" maxOccurs="unbounded"/> and "average" settings can filter notications by time.
<xs:element name="enterOrExit" type="gml:FeaturePropertyType" 5. XML Schema
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="minRate" type="xs:rate-spec"
minOccurs="0" maxOccurs="1"/>
<xs:element name="maxRate" type="xs:rate-spec"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="rate-spec">
<xs:complexType>
<xs:sequence>
<xs:attribute name="uom" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="seconds"></xs:enumeration>
<xs:enumeration value="minutes"></xs:enumeration>
<xs:enumeration value="hours"></xs:enumeration>
<xs:enumeration value="days"></xs:enumeration>
<xs:enumeration value="weeks"></xs:enumeration>
<xs:enumeration value="years"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:location-filter" targetNamespace="urn:ietf:params:xml:ns:location-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<xs:element name="location-filter"> <!-- This element is an child element of the RFC 4661
<xs:complexType> <filter> element.
<xs:sequence> -->
<xs:element name="movedHoriz" type="gml:MeasureType" <xs:element name="enterOrExit" type="gml:FeaturePropertyType"/>
minOccurs="0" maxOccurs="1"/>
<xs:element name="movedVert" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="speedExceeds" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<!-- this type needs to hold an XPath statement -->
<xs:element name="valueChanges" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="enterOrExit" type="gml:FeaturePropertyType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="minRate" type="xs:rate-spec"
minOccurs="0" maxOccurs="1"/>
<xs:element name="maxRate" type="xs:rate-spec"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="rate-spec">
<xs:complexType>
<xs:sequence>
<xs:attribute name="uom" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="seconds"></xs:enumeration>
<xs:enumeration value="minutes"></xs:enumeration>
<xs:enumeration value="hours"></xs:enumeration>
<xs:enumeration value="days"></xs:enumeration>
<xs:enumeration value="weeks"></xs:enumeration>
<xs:enumeration value="years"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema> </xs:schema>
<?xml version="1.0" encoding="UTF-8"?> Figure 6: XML Schema
<xs:schema
targetNamespace="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="location-filter">
<xs:complexType>
<xs:sequence>
<xs:element name="movedHoriz" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="movedVert" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="speedExceeds" type="gml:MeasureType"
minOccurs="0" maxOccurs="1"/>
<!-- this type needs to hold an XPath statement -->
<xs:element name="valueChanges" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="enterOrExit" type="gml:FeaturePropertyType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="minRate" type="xs:rate-spec"
minOccurs="0" maxOccurs="1"/>
<xs:element name="maxRate" type="xs:rate-spec"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="rate-spec">
<xs:complexType>
<xs:sequence>
<xs:attribute name="uom" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="seconds"></xs:enumeration>
<xs:enumeration value="minutes"></xs:enumeration>
<xs:enumeration value="hours"></xs:enumeration>
<xs:enumeration value="days"></xs:enumeration>
<xs:enumeration value="weeks"></xs:enumeration>
<xs:enumeration value="years"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
4. Containment schema 6. Security Considerations
This section describes a schema for describing the resource's Location information is typically very privacy sensitive. As such,
location relative to a region or list of regions which might contain notifications MUST be encrypted and integrity protected.
the resource. (These regions can be defined dynamically in an
"enterOrExit" element in a subscription filter, or defined on the
notifier using some out-of-band mechanism.) The "pidfResource"
element is placed inside the location-info element in a PIDF-LO
document. The pidfResource element can contain zero or more
"containment" elements. Each containment element has a GML Feature
sub-element (of type "FeaturePropertyType") and a mandatory attribute
which specifies if the PIDF resource is inside or outside of the
feature, or if the position of the resource with respect to the
region or region list is undefined.
In a future version of this specification, the GML Feature can
become a reference to a more preferable name or identifier type.
The GML Feature type is only used because it includes a name to
reference it.
If the subscriber is not authorized to know the relative position, Additional privacy and security considerations are discussed in
the notifier MUST NOT reveal this private information. The detail in [RFC5491].
RECOMMENDED way to prevent the subscriber from seeing private
location data of this type is to return a containment element whose
position attribute is "undefined". Note that in some cases, the
containment information may be more interesting than the actual raw
location. It is not necessary to convey a concrete civic or geo
location in a PIDF-LO if the subscriber is only interested in or
authorized to see the containment status.
<?xml version="1.0" encoding="UTF-8"?> 7. IANA Considerations
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"
xmlns:pr="urn:ietf:params:xml:ns:pidf:geopriv10:containment" >
<xs:element name="pidfResource">
<xs:complexType>
<xs:sequence>
<xs:element ref="pr:containment"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="containment">
<xs:complexType>
<xs:sequence>
<xs:any namespace="http://www.opengis.net/gml"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="position" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="inside"></xs:enumeration>
<xs:enumeration value="outside"></xs:enumeration>
<xs:enumeration value="undefined"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
Below is an example PIDF-LO document which indicates that the 7.1. Content-type registration for 'application/
resource is inside building 10, not outside the parking garage, and location-delta-filter+xml'
not permitted to know if the resource is in a conference room. Note
that in GML, these features could be referenced by their unique
identifiers instead.
<?xml version="1.0" encoding="UTF-8"?> This specification requests the registration of a new MIME type
<presence xmlns="urn:ietf:params:xml:ns:pidf" according to the procedures of RFC 4288 [RFC4288] and guidelines in
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" RFC 3023 [RFC3023].
xmlns:pr="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<pr:pidfResource>
<pr:containment position="inside">
<my:Building>
<gml:name>Building 10</gml:name>
</my:Building>
</pr:containment>
<pr:containment position="outside">
<my:ParkingGarage
xlink:href="http://server.example.com/loc-defs/bldg-mgr/parking"/>
</pr:containment>
<pr:containment position="undefined">
<my:ConferenceRooms
xlink:href="http://server.example.com/loc-defs/userdef/confrooms"/>
</pr:containment>
</pr:pidfResource>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5. Security Considerations MIME media type name: application
Location information is typically very privacy sensitive. As such, MIME subtype name: location-delta-filter+xml
GEOPRIV requires that notifications MUST be encrypted and integrity
protected.
Additional privacy and security considerations are discussed in Mandatory parameters: none
detail in [I-D.ietf-geopriv-pdif-lo-profile].
6. IANA Considerations Optional parameters: charset; Indicates the character encoding of
enclosed XML.
6.1. MIME Registration for application/location-delta-filter+xml Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], Section 3.2.
MIME media type name: application Security considerations: See the "Security Considerations" section
in this document.
MIME subtype name: application/location-delta-filter+xml Interoperability considerations: None
Required parameters: none. Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification.]
Optional parameters: none. Applications which use this media type: This content type supports
the exchange of filters to throttle asynchronous notifications of
location information.
Encoding considerations: Same as for XML. Additional information:
Security considerations: See the "Security Considerations" Magic Number: N/A
section in this document.
Interoperability considerations: none File Extension: N/A
Published specification: This document. Macintosh file type code: N/A
Applications which use this media: The application/ Personal and email address for further information: Brian Rosen,
location-delta-filter+xml application subtype supports the exchange br@brianrosen.net
of filters to throttle asynchronous notifications of location Intended usage: LIMITED USE
information.
Additional information: Author:
1. Magic number(s): N/A This specification is a work item of the IETF GEOPRIV working
group, with mailing list address <geopriv@ietf.org>.
2. File extension(s): N/A Change controller:
3. Macintosh file type code: N/A The IESG <iesg@ietf.org>
6.2. URN Sub-Namespace Registration for 7.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter urn:ietf:params:xml:ns:location-filter
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[RFC3688]. [RFC3688].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:location-filter. urn:ietf:params:xml:ns:location-filter.
Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>, Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>,
as delegated by the IESG <iesg@ietf.org>. as delegated by the IESG <iesg@ietf.org>.
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
skipping to change at page 17, line 25 skipping to change at page 14, line 5
<title>Location Filter Namespace</title> <title>Location Filter Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for PIDF-LO Location Filters</h1> <h1>Namespace for PIDF-LO Location Filters</h1>
<h2>urn:ietf:params:xml:ns:location-filter</h2> <h2>urn:ietf:params:xml:ns:location-filter</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
6.3. Schema Registration For location-filter 7.3. Schema Registration For location-filter
This specification registers a schema, as per the guidelines in This specification registers a schema, as per the guidelines in
[RFC3688]. [RFC3688].
URI: please assign. URI: please assign.
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 3.5.
6.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:containment
This section registers a new XML namespace, as per the guidelines in
[RFC3688].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:geopriv10:containment.
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>PIDF-LO Location Containment Namespace</title>
</head>
<body>
<h1>Namespace for PIDF-LO location containment elements</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:containment</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
6.5. Schema Registration For containment
This specification registers a schema, as per the guidelines in
[RFC3688].
URI: please assign.
Registrant Contact: IETF, GEOPRIV Working Group Registrant Contact: IETF, GEOPRIV Working Group
(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). (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. Acknowledgments XML: The XML can be found as the sole content of Section 5.
8. Acknowledgments
Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for
their comments. their comments.
8. References 9. References
8.1. Normative References 9.1. Normative References
[GML] OpenGIS, "Open Geography Markup Language (GML) [GML] OpenGIS, "Open Geography Markup Language (GML)
Implementation Specification", OpenGIS OGC 02-023r4, Implementation Specification", OpenGIS OGC 02-023r4,
January 2003, January 2003,
<http://www.opengis.org/techno/implementation.htm>. <http://www.opengis.org/techno/implementation.htm>.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-sipcore-event-rate-control]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-13
(work in progress), September 2008.
[I-D.niemi-sipping-event-throttle]
Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Protocol (SIP) Event Notification Extension for Protocol (SIP) Event Notification Extension for
Notification Throttling", Notification Rate Control",
draft-niemi-sipping-event-throttle-07 (work in progress), draft-ietf-sipcore-event-rate-control-00 (work in
October 2008. progress), May 2009.
[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)",
draft-singh-geopriv-pidf-lo-dynamic-06 (work in progress),
June 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[W3C.REC-xml] [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, Registration Procedures", BCP 13, RFC 4288, December 2005.
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[W3C.REC-xml-names]
Bray, T., Hollander, D., and A. Layman, "Namespaces in
XML", W3C REC-xml-names, January 1999,
<http://www.w3.org/TR/REC-xml-names>.
[W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1,
May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.xpath] [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Clark, J. and S. DeRose, "XML Path Language (XPath) Requena, "An Extensible Markup Language (XML)-Based Format
Version 1.0", W3C Recommendation xpath, November 1999, for Event Notification Filtering", RFC 4661,
<http://www.w3.org/TR/xpath>. September 2006.
8.2. Informational References [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.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 9.2. Informational References
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [I-D.ietf-sip-location-conveyance]
August 1999. Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Plantronics Plantronics
345 Encincal Street 345 Encincal Street
Santa Cruz, CA Santa Cruz, CA
USA USA
Email: rohan@ekabal.com Email: rohan@ekabal.com
Brian Rosen Brian Rosen (editor)
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
Full Copyright Statement Hannes Tschofenig
Nokia Siemens Networks
Copyright (C) The IETF Trust (2008). Linnoitustie 6
Espoo 02600
This document is subject to the rights, licenses and restrictions Finland
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Phone: +358 (50) 4871445
copyrights, patents or patent applications, or other proprietary Email: Hannes.Tschofenig@gmx.net
rights that may cover technology that may be required to implement URI: http://www.tschofenig.priv.at
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 92 change blocks. 
665 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/