One document matched: draft-ietf-geopriv-loc-filters-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="std" ipr="trust200902" docName="draft-ietf-geopriv-loc-filters-05.txt">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Location Event Filters"> A Document Format for Filtering and Reporting Location
Notications in the Presence Information Document Format Location Object (PIDF-LO) </title>
<author initials="R." surname="Mahy" fullname="Rohan Mahy">
<organization>Plantronics</organization>
<address>
<postal>
<street>345 Encincal Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>rohan@ekabal.com</email>
</address>
</author>
<author role="editor" fullname="Brian Rosen" initials="B.R" surname="Rosen">
<organization>NeuStar</organization>
<address>
<postal>
<street>470 Conrad Dr.</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<phone>+1 724 382 1051</phone>
<email>br@brianrosen.net</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2009"/>
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>geopriv</keyword>
<keyword>location</keyword>
<abstract>
<t> This document describes filters that limit asynchronous location notifications to
compelling events, designed as an extension to RFC 4661 "An XML-Based Format for Event
Notification Filtering". The resulting location information is conveyed in existing location
formats wrapped in the Presence Information Document Format (PIDF-LO).</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************************* -->
<section title="Introduction">
<t> Conveying location in <xref target="RFC4119">PIDF-LO</xref> bodies is described in <xref
target="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 <xref target="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. </t>
<t> The frequency of notifications necessary for various geographic location applications
varies dramatically. The subscriber should be able to get asynchronous notifications with
appropriate frequency and granularity, without having to issue a large number of
notifications that are not important to the application.</t>
<t> This document defines the following as an initial list of events that are relevant to a
subscriber:<list style="numbers">
<t> the Target moves more than a specified distance since the last notification </t>
<t>the Target exceeds a specified speed </t>
<t>the Target enters or exits a region (described by a circle or a polygon) </t>
<t>one or more of the values of the specified address labels have changed for the location
of the Target. For example, the value of the <A1> civic address element
has changed from 'California' to 'Nevada'.</t>
<t>the type of location information being requested.</t>
</list></t>
</section>
<section title="Terminology">
<t> 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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<!-- ******************************************************************************* -->
<section title="Filter Definitions">
<section title="Movement">
<t> 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>. </t>
<t>
<figure anchor="movement-example" title="Movement Filter Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<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:moved>300</ext:moved>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
</section>
<section title="Speed Changes">
<t>Speed changes can be filtered with the help of RFC 4661 and the functionality provided in
<xref target="I-D.singh-geopriv-pidf-lo-dynamic"/>, which extends the PIDF-LO with
support for spatial orientation, speed, heading, and acceleration. </t>
<t><xref target="speed-example"/> shows an example for a trigger that fires when the speed
of the Target changes by 3 meters per second.</t>
<t>
<figure anchor="speed-example" title="Speed Change Example">
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<section title="Element Value Changes">
<t>Changes in values, for example related to civic location information, can be provided by
the base functionality offered with RFC 4661. <xref target="value-change"/> shows an
example where a notification is sent when the civic address tokens A1, A2, A3, or PC
change. </t>
<t>
<figure anchor="value-change" title="Speed Change Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
<changed>//ca:A2</changed>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
</section>
<section title="Entering or Exiting a Region">
<t> The <enterOrExit> condition is satisfied when the Target enters or exits a
named 2-dimensional region described by a polygon (as defined in Section 5.2.2 of <xref
target="RFC5491"/>), or a circle (as defined in Section 5.2.3 of <xref target="RFC5491"
/>). </t>
<t><xref target="containment-circle"/> shows filter examples whereby a notification is sent
when the Target enters or exits an area described by a circle and <xref
target="containment-polygon"/> describes an area using a polygon.</t>
<t>
<figure anchor="containment-circle"
title="<enterOrExit> Circle Filter Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:ext="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">
<ext: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>
</ext:enterOrExit>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
<t>
<figure anchor="containment-polygon"
title="<enterOrExit> Polygon Filter Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:ext="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com">
<ext:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
43.311 -73.422 43.111 -73.322
43.111 -73.222 43.311 -73.122
43.411 -73.222 43.411 -73.322
43.311 -73.422
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</ext:enterOrExit>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
</section>
<section title="Location Type">
<t> The <locationType> element MAY be included as a child element of the
<filter> element and it contains a list of location information types that
are requested by the subscriber. The following list describes the possible values: </t>
<t>
<list style="hanging">
<t hangText="any:">The Notifier SHOULD attempt to provide LI in all forms available to
it.</t>
<t hangText="geodetic:">The Notifier SHOULD return a location by value in the form of a
geodetic location. </t>
<t hangText="civic:">The Notifier SHOULD return a location by value in the form of a
civic address. </t>
</list>
</t>
<t> 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". </t>
<t> 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. </t>
<t>If the <locationType> element is absent, a value of "any" MUST be assumed
as the default. </t>
<t> The Notifier SHOULD provide location in the response in the same order in which they
were included in the "locationType" element in the request. Indeed, the primary advantage
of including specific location types in a request when the 'exact' attribute is set to
"false" is to ensure that one receives the available locations in a specific order. For
example, a subscription for "civic" (with the 'exact' attribute set to "false") could
yield any of the following location types in the response: </t>
<t>
<list style="symbols">
<t>civic</t>
<t>civic, geodetic</t>
<t>geodetic (only if civic is not available)</t>
</list>
</t>
<t> For the example above, if the 'exact' attribute was "true", then the only possible
response is either a "civic" location or an error message.</t>
<t> 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. </t>
<t>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. </t>
<t> In the case of emergency services, the purpose of obtaining the 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.</t>
<t> The time value in the 'responseTime' attribute is expressed as a non- negative integer
in units of milliseconds. The time value is 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.</t>
<t> The Notifier may use the value of the time in the 'responseTime' 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.</t>
<t>An example is shown in <xref target="locationType"/> that utilizes the
<locationType> element with the 'exact' and the 'responseTime' attribute. </t>
<t>
<figure anchor="locationType" title="<locationType> Filter Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<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>
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ******************************************************************************* -->
<section anchor="schema" title="XML Schema">
<t>
<figure anchor="schema-fig" title="XML Schema">
<artwork><![CDATA[
<?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">
<!-- These elements are child elements of the RFC 4661
<filter> element.
-->
<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
<xs:element name="moved" type="filter:movedType"/>
<xs:complexType name="movedType">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="locationType" type="filter:locationTypeType"/>
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="filter:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
<xs: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>
]]></artwork>
</figure>
</t>
</section>
<!-- ******************************************************************************* -->
<section title="Security Considerations">
<t> Location information is typically very privacy sensitive. As such, notifications MUST be
encrypted and integrity protected. </t>
<t> Additional privacy and security considerations are discussed in detail in <xref
target="RFC5491"/>. </t>
</section>
<!-- ******************************************************************************* -->
<section title="IANA Considerations">
<section title="URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter">
<t> This section registers a new XML namespace, as per the guidelines in <xref
target="RFC3688"/>. </t>
<t>
<list style="hanging">
<t hangText="URI:"> urn:ietf:params:xml:ns:location-filter</t>
<t hangText="Registrant Contact:"> IETF, GEOPRIV working group,
<geopriv@ietf.org>, as delegated by the IESG
<iesg@ietf.org>. </t>
<t hangText="XML:">
<figure>
<artwork>
<![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Location Filter Namespace</title>
</head>
<body>
<h1>Namespace for PIDF-LO Location Filters</h1>
<h2>urn:ietf:params:xml:ns:location-filter</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]>
</artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="Schema Registration For location-filter">
<t>This specification registers a schema, as per the guidelines in <xref target="RFC3688"/>.</t>
<t>
<list style="hanging">
<t>URI: urn:ietf:params:xml:schema:location-filter</t>
<t>Registrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by
the IESG (iesg@ietf.org).</t>
<t>XML: The XML can be found as the sole content of <xref target="schema"/>.</t>
</list>
</t>
</section>
</section>
<!-- ******************************************************************************* -->
<section title="Contributors">
<t>We would like to thank Martin Thomson and James Polk for their contributions to this
document. </t>
</section>
<!-- ******************************************************************************* -->
<section title="Acknowledgments">
<t> Thanks to Allan Thomson, James Winterbottom, Richard Barnes and Alissa Cooper for their
comments.</t>
</section>
<!-- ******************************************************************************* -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4119" ?>
<?rfc include="reference.RFC.4661" ?>
<?rfc include="reference.RFC.5491" ?>
<?rfc include="reference.RFC.4288" ?>
<?rfc include="reference.RFC.3023" ?>
<?rfc include="reference.I-D.singh-geopriv-pidf-lo-dynamic" ?>
<reference anchor="GML" target="http://www.opengis.org/techno/implementation.htm">
<front>
<title>Open Geography Markup Language (GML) Implementation Specification</title>
<author>
<organization> OpenGIS </organization>
</author>
<date month="January" year="2003"/>
</front>
<seriesInfo name="OpenGIS" value="OGC 02-023r4"/>
</reference>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.3688" ?>
<?rfc include="reference.I-D.ietf-sip-location-conveyance" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 07:53:34 |