draft-ietf-geopriv-loc-filters-04.txt   draft-ietf-geopriv-loc-filters-05.txt 
GEOPRIV R. Mahy GEOPRIV R. Mahy
Internet-Draft Plantronics Internet-Draft Plantronics
Intended status: Standards Track B. Rosen, Ed. Intended status: Standards Track B. Rosen, Ed.
Expires: January 14, 2010 NeuStar Expires: January 28, 2010 NeuStar
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
July 13, 2009 July 27, 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-04.txt draft-ietf-geopriv-loc-filters-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 14, 2010. This Internet-Draft will expire on January 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 16
This document describes filters that limit asynchronous location This document describes filters that limit asynchronous location
notifications to compelling events, designed as an extension to RFC notifications to compelling events, designed as an extension to RFC
4661 "An XML-Based Format for Event Notification Filtering". The 4661 "An XML-Based Format for Event Notification Filtering". The
resulting location information is conveyed in existing location resulting location information is conveyed in existing location
formats wrapped in the Presence Information Document Format formats wrapped in the Presence Information Document Format
(PIDF-LO). (PIDF-LO).
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Horizontal and Vertical Movement . . . . . . . . . . . . . 5 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Changes in Speed . . . . . . . . . . . . . . . . . . . . . 5 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Changes in Value . . . . . . . . . . . . . . . . . . . . . 6 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 6
3.4. Enter or Exit a Region . . . . . . . . . . . . . . . . . . 7 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 6
4. Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 8
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Content-type registration for 6.1. URN Sub-Namespace Registration for
'application/location-delta-filter+xml' . . . . . . . . . 12 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 14
7.2. URN Sub-Namespace Registration for 6.2. Schema Registration For location-filter . . . . . . . . . 14
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Schema Registration For location-filter . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informational References . . . . . . . . . . . . . . . . . 18
9.2. Informational References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. 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].
2. Introduction 1. Introduction
Conveying location in PIDF-LO [RFC4119] bodies is described in Conveying location in PIDF-LO [RFC4119] bodies is described in
[I-D.ietf-sip-location-conveyance]. Asynchronous notification of [I-D.ietf-sip-location-conveyance]. Asynchronous notification of
location information is unfortunately more complex since many forms location information is unfortunately more complex since many forms
of location are measured as a continuous gradient. Unlike of location are measured as a continuous gradient. Unlike
notifications using discret quantities, it is difficult to know when notifications using discret quantities, it is difficult to know when
a change in location is large enough to warrant a notification. The a change in location is large enough to warrant a notification. The
mechanism described in this document defines filters as an extension mechanism described in this document defines filters as an extension
to RFC 4661 [RFC4661], which limits location notification to events to RFC 4661 [RFC4661], which limits location notification to events
that are of relevance to the subscriber. These filters persist until that are of relevance to the subscriber. These filters persist until
they are changed with a replacement filter. they are changed with a replacement filter.
The frequency 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 frequency and able to get asynchronous notifications with appropriate frequency and
granularity, without having to issue a large number of notifications granularity, without having to issue a large number of notifications
that are not important to the application. This section of this that are not important to the application.
document defines an extension to [RFC4661]'s TriggerType element to
describe interesting conditions or events. The terminal elements in
this format are utilizing Geographic Markup Language (GML) [GML] data
types and civic address elements.
This document also defines a MIME type for this location filter
format, namely 'application/location-delta-filter+xml'.
This document defines the following as an initial list of events that This document defines the following as an initial list of events that
could be interesting to a subscriber: are relevant to a subscriber:
1. the Target moves more than a specified distance horizontally or 1. the Target moves more than a specified distance since the last
vertically since the last notification notification
2. the Target exceeds a specified speed 2. the Target exceeds a specified speed
3. the Target enters or exits one or more GML objects (for example, 3. the Target enters or exits a region (described by a circle or a
a set of 2-dimensional or 3-dimensional regions) included or polygon)
referenced in the filter.
4. one or more of the values of the specified address labels has 4. one or more of the values of the specified address labels have
changed for the location of the Target (for example, the value of changed for the location of the Target. For example, the value
the <A1> civic address element has changed from 'California' to of the <A1> civic address element has changed from 'California'
'Nevada') to 'Nevada'.
3. Filter Definitions 5. the type of location information being requested.
3.1. Horizontal and Vertical Movement 2. Terminology
Changes in the position of the Target require extensions to the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
functionality of RFC 4661 and a simplying assumption. The former "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
aspect refers to the need to enhance the capability to extract a document are to be interpreted as described in RFC 2119 [RFC2119].
value from inside an XML element, in our example from the <pos>
element, which describes the user's location. Regarding the latter
aspect we assume that the user's location information of any shape
and uncertainty is converted into a point before the comparison
regarding the movement with the previously notified location takes
place.
The example shown in Figure 1 references the latitude value (using 3. Filter Definitions
the "gml:pos[1]" notation) and the 'by' attribute of the <changed>
element indicates the desired change that triggers a notification to 3.1. Movement
be sent.
The <moved> element with a value in meters indicates the minimum
distance that the resource must have moved from the location of the
resource when the last notification was sent in order to trigger this
event. The distance is measured in meters absolutely from the point
of last notification rather than in terms of cumulative motion. The
<moved> element MUST only appear once as a child element of <filter>.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set
<ns-bindings> xmlns="urn:ietf:params:xml:ns:simple-filter"
<ns-binding prefix="pidf" xmlns:ext="urn:ietf:params:xml:ns:location-filter">
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"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <ext:moved>300</ext:moved>
<changed by="100">
/pidf:presence/pidf:device/gp:geopriv/
gp:location-info/gml:Point/gml:pos[1]
</changed>
</trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 1: Movement Filter Example Figure 1: Movement Filter Example
3.2. Changes in Speed 3.2. Speed Changes
Speed changes can be filtered with the help of RFC 4661 and the Speed changes can be filtered with the help of RFC 4661 and the
functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which
extends the PIDF-LO with support for spatial orientation, speed, extends the PIDF-LO with support for spatial orientation, speed,
heading, and acceleration. heading, and acceleration.
Figure 2 shows an example for a trigger that fires when the speed of Figure 2 shows an example for a trigger that fires when the speed of
the Target changes by 20 meters per second. the Target changes by 3 meters per second.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <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" <ns-binding prefix="dyn"
urn="urn:ietf:params:xml:schema:pidf:dynamic"/> urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<changed by="3"> <changed by="3">
/pidf:presence/pidf:tuple/pidf:status/ //dyn:speed
gp:geopriv/gp:location-info/dyn:Dynamic/dyn:speed
</changed> </changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 2: Speed Change Example Figure 2: Speed Change Example
3.3. Changes in Value 3.3. Element Value Changes
Changes in values, for example related to civic location information, Changes in values, for example related to civic location information,
can be provided by the base functionality offered with RFC 4661. can be provided by the base functionality offered with RFC 4661.
Figure 3 shows an example where a notification is sent when the civic Figure 3 shows an example where a notification is sent when the civic
address tokens A1, A2, A3, or PC change. address tokens A1, A2, A3, or PC change.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="pidf" <ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf"/> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="cl"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<changed> <changed>//ca:A1</changed>
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ <changed>//ca:A2</changed>
gp:location-info/cl:civilAddress/cl:A1 <changed>//ca:A3</changed>
</changed> <changed>//ca:PC</changed>
<changed>
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/cl:civilAddress/cl:A2
</changed>
<changed>
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/cl:civilAddress/cl:A3
</changed>
<changed>
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
gp:location-info/cl:civilAddress/cl:PC
</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 3: Speed Change Example Figure 3: Speed Change Example
3.4. Enter or Exit a Region 3.4. Entering or Exiting a Region
The <enterOrExit> condition is satisfied when the Target enters or The <enterOrExit> condition is satisfied when the Target enters or
exits a named 2-dimensional or 3-dimensional region described by a exits a named 2-dimensional region described by a polygon (as defined
polygon (as defined in Section 5.2.2 of [RFC5491]), or a circle (as in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section
defined in Section 5.2.3 of [RFC5491]). 5.2.3 of [RFC5491]).
Figure 4 and Figure 5 shows filter examples whereby a notification is Figure 4 shows filter examples whereby a notification is sent when
sent when the Target enters or exits an area described by a circle the Target enters or exits an area described by a circle and Figure 5
and by a 3d polygon. describes an area using a polygon.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set <filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:con="urn:ietf:params:xml:ns:pidf:geopriv10:containment" xmlns:ext="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"> xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<con:enterOrExit> <ext:enterOrExit>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos> <gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24 850.24
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</con:enterOrExit> </ext:enterOrExit>
</filter> </filter>
</filter-set> </filter-set>
Figure 4: <enterOrExit> (2D) Filter Example Figure 4: <enterOrExit> Circle Filter Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:con="urn:ietf:params:xml:ns:pidf:geopriv10:containment" xmlns:ext="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<con:enterOrExit> <ext:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList> <gml:posList>
43.311 -73.422 43.111 -73.322 43.311 -73.422 43.111 -73.322
43.111 -73.222 43.311 -73.122 43.111 -73.222 43.311 -73.122
43.411 -73.222 43.411 -73.322 43.411 -73.222 43.411 -73.322
43.311 -73.422 43.311 -73.422
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</con:enterOrExit> </ext:enterOrExit>
</filter> </filter>
</filter-set> </filter-set>
Figure 5: <enterOrExit> (3D) Filter Example Figure 5: <enterOrExit> Polygon Filter Example
4. Rate Control 3.5. Location Type
The throttle mechanisms [I-D.ietf-sipcore-event-rate-control] can be The <locationType> element MAY be included as a child element of the
used to control the rate of notifications. The "throttle", "force" <filter> element and it contains a list of location information types
and "average" settings can filter notications by time. that are requested by the subscriber. The following list describes
the possible values:
5. XML Schema any: The Notifier SHOULD attempt to provide LI in all forms
available to it.
<?xml version="1.0" encoding="UTF-8"?> geodetic: The Notifier SHOULD return a location by value in the form
<xs:schema of a geodetic location.
targetNamespace="urn:ietf:params:xml:ns:location-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml">
<!-- This element is an child element of the RFC 4661 civic: The Notifier SHOULD return a location by value in the form of
<filter> element. a civic address.
-->
<xs:element name="enterOrExit" type="gml:FeaturePropertyType"/>
</xs:schema>
Figure 6: XML Schema The Notifier SHOULD return the requested location type or types. The
location types the LIS returns also depend 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 provide an error response. The 'exact' attribute does not
apply (is ignored) for a request for a location type of "any".
6. Security Considerations 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. The "SHOULD"-strength
requirements on this parameter for specific location types are
included to allow for soft-failover.
Location information is typically very privacy sensitive. As such, If the <locationType> element is absent, a value of "any" MUST be
notifications MUST be encrypted and integrity protected. assumed as the default.
Additional privacy and security considerations are discussed in The Notifier SHOULD provide location in the response in the same
detail in [RFC5491]. 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:
7. IANA Considerations o civic
7.1. Content-type registration for 'application/ o civic, geodetic
location-delta-filter+xml'
This specification requests the registration of a new MIME type o geodetic (only if civic is not available)
according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023].
MIME media type name: application For the example above, if the 'exact' attribute was "true", then the
only possible response is either a "civic" location or an error
message.
MIME subtype name: location-delta-filter+xml As stated above, the <locationType> element MAY carry the 'exact'
attribute. When the 'exact' attribute is set to "true", it indicates
to the Notifier that the contents of the <locationType> element MUST
be strictly followed. The default value of "false" 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. A value of "true" indicates that the Notifier MUST
provide a location of the requested type or types or MUST provide an
error.
Mandatory parameters: none The <locationType> element MAY carry another attribute, the
'responseTime' attribute, to provide a time value indicating to the
Notifier how long the Subscriber is prepared to wait for a response
or a purpose for which the Subscriber needs the location. The former
functionality is more useful for a single SUBSCRIBE / NOTIFY
interaction.
Optional parameters: charset; Indicates the character encoding of In the case of emergency services, the purpose of obtaining the
enclosed XML. location information could be either for routing a call to the
appropriate Public Safety Answering Point (PSAP) or indicating the
location to which responders should be dispatched. The values
defined for the purpose, "emergencyRouting" and "emergencyDispatch",
will likely be governed by jurisdictional policies, and should be
configurable on the Notifier.
Encoding considerations: Uses XML, which can employ 8-bit The time value in the 'responseTime' attribute is expressed as a non-
characters, depending on the character encoding used. See RFC negative integer in units of milliseconds. The time value is
3023 [RFC3023], Section 3.2. indicative only and the Notifier is under no obligation to strictly
adhere to the time limit implied; any enforcement of the time limit
is left to the requesting Subscriber. The Notifier provides the most
accurate location information that can be determined within the
specified interval for the specific service.
Security considerations: See the "Security Considerations" section The Notifier may use the value of the time in the 'responseTime'
in this document. attribute as input when selecting the method of location
determination, where multiple such methods exist. If the
'responseTime' attribute is absent, then the Notifier should return
the most precise location information it is capable of determining,
with the time interval being implementation dependent.
Interoperability considerations: None An example is shown in Figure 6 that utilizes the <locationType>
element with the 'exact' and the 'responseTime' attribute.
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please <?xml version="1.0" encoding="UTF-8"?>
replace XXXX with the RFC number of this specification.] <filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:ext="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<ext:locationType exact="true" responseTime="emergencyRouting">
geodetic
</ext:locationType>
</filter>
</filter-set>
Applications which use this media type: This content type supports Figure 6: <locationType> Filter Example
the exchange of filters to throttle asynchronous notifications of
location information.
Additional information: 4. XML Schema
Magic Number: N/A <?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">
File Extension: N/A <!-- These elements are child elements of the RFC 4661
<filter> element.
-->
Macintosh file type code: N/A <xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
Personal and email address for further information: Brian Rosen, <xs:element name="moved" type="filter:movedType"/>
br@brianrosen.net
Intended usage: LIMITED USE
Author: <xs:complexType name="movedType">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
This specification is a work item of the IETF GEOPRIV working <xs:element name="locationType" type="filter:locationTypeType"/>
group, with mailing list address <geopriv@ietf.org>.
Change controller: <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>
The IESG <iesg@ietf.org> <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>
7.2. URN Sub-Namespace Registration for <xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
<xs:attribute name="responseTime"
type="filter:responseTimeType"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema>
Figure 7: XML Schema
5. Security Considerations
Location information is typically very privacy sensitive. As such,
notifications MUST be encrypted and integrity protected.
Additional privacy and security considerations are discussed in
detail in [RFC5491].
6. IANA Considerations
6.1. 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: 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">
skipping to change at page 14, line 5 skipping to change at page 14, line 38
<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
7.3. Schema Registration For location-filter 6.2. 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: urn:ietf:params:xml:schema:location-filter
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 5. 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 8. Acknowledgments
Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for Thanks to Allan Thomson, James Winterbottom, Richard Barnes and
their comments. Alissa Cooper for their comments.
9. References 9. References
9.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-sipcore-event-rate-control]
Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Protocol (SIP) Event Notification Extension for
Notification Rate Control",
draft-ietf-sipcore-event-rate-control-00 (work in
progress), May 2009.
[I-D.singh-geopriv-pidf-lo-dynamic] [I-D.singh-geopriv-pidf-lo-dynamic]
Schulzrinne, H., Singh, V., Tschofenig, H., and M. Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", Data Format Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-06 (work in progress), draft-singh-geopriv-pidf-lo-dynamic-06 (work in progress),
June 2009. 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.
 End of changes. 73 change blocks. 
196 lines changed or deleted 263 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/