One document matched: draft-ietf-geopriv-loc-filters-07.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-07.txt">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Location Filters">Filtering Location Notifications in the Session Initiation
Protocol (SIP)</title>
<author initials="R." surname="Mahy" fullname="Rohan Mahy">
<organization>Individual</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<country/>
</postal>
<email>rohan@ekabal.com</email>
</address>
</author>
<author 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, and based on RFC 3856, the SIP presence event package. The resulting
location information is conveyed in existing location formats wrapped in the Presence
Information Data Format Location Object (PIDF-LO).</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************************* -->
<section anchor="introduction" title="Introduction">
<t> Conveying location information encapsulated with a <xref target="RFC4119">PIDF-LO</xref>
document within SIP is described in <xref target="I-D.ietf-sipcore-location-conveyance"/>.
An alternative signaling approach, which uses asynchronous communication, is available with
the SIP event notification mechanisms (see RFC 3265 <xref target="RFC3265"/>) and is used by
this document. Unfortunately, it is 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. SIP events <xref
target="RFC3265"/> can be used with filters (see RFC 4661 <xref target="RFC4661"/>) that
allows the number of notifications to be reduced. The mechanism described in this document
defines 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 a few new event filters and describes others using existing
mechanisms that may be relevant to a subscriber in the context of location filtering:<list
style="numbers">
<t>the Device moves more than a specified distance since the last notification </t>
<t>the Device exceeds a specified speed </t>
<t>the Device 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 Device. 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>
<t>the rate at which location information delivery is desired.</t>
</list></t>
<t>This document builds on the presence event package <xref target="RFC3856"/>, i.e. an
existing event package for communicating location information inside the PIDF-LO.</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>
<t>This document reuses terminology from <xref target="I-D.ietf-geopriv-arch"/>.</t>
</section>
<!-- ******************************************************************************* -->
<section title="Filter Definitions">
<t>This specification builds on top of a number of other specifications, as noted in <xref
target="introduction"/>. In order to reduce the number of options (and thereby increase
the chance of interoperability problems), only the functionality described in this document
MUST be implemented. Only the functionality of <xref target="RFC4661"/> listed in the
sub-sections below MUST be implemented, namely the <ns-bindings> (see Section 3.3 of <xref target="RFC4661"/>), the <filter> (Section 3.4 of <xref
target="RFC4661"/>), and the <trigger> (Section 3.6 of <xref
target="RFC4661"/> excluding the functionality of the <added> and <removed> element). </t>
<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:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<lf:moved>300</lf: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. The value of
<speed> in <xref target="I-D.singh-geopriv-pidf-lo-dynamic"/> is defined in
meters per second. This is the only supported measure and hence the value in the 'by'
attribute MUST be expressed in meters per second. </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>
<t>An implementation MUST support the functionality as shown in <xref target="speed-example"
/> with <ns-bindings> replacing the prefix. No other variant is supported. The
<changed> element comes with a few attributes but only the 'by' attribute
MUST be implemented by this specification.</t>
</section>
<section title="Element Value Changes">
<t>Changes in values, for example related to civic location information, is provided by the
base functionality offered with RFC 4661 utilizing the <changed> element.</t>
<t><xref target="value-change"/> shows an example where a notification is sent when the
civic address tokens A1, A2, A3, or PC change (all 4 must change in order to let the <trigger> element evaluate to TRUE).</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>
<t>The following example illustrates a filter that triggers when the Target's location
changes from 'FR' (France) to some other country.</t>
<t>
<figure anchor="value-change2" title="Speed Change Example (Country Change)">
<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 from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
<t>An implementation MUST support the functionality as shown in <xref target="value-change"
/> with <ns-bindings> replacing the prefix. No other variant is supported. The
<changed> element comes with a few attributes and the 'by', 'to' and 'from'
attribute MUST be implemented by this specification.</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"
/>). The <enterOrExit> element MUST have contain either a polygon or a circle as a
child element. More than one a polygon and/or a circle as a child element of
<enterOrExit> MUST NOT occur. </t>
<t>
If the Target was previously outside the region, the notifier sends a notification when the Target's location is within the region with at least 50% confidence. Similarly, when a Target starts within the region, a notification is sent when the Target's location moves outside the region with at least 50% confidence.</t>
<t>
Note that having 50% confidence that the Target is inside the area does not correspond to 50% outside. Confidence that the location is within the region, plus confidence that the location is outside the region cannot be 100%. The total confidence depends on the confidence in the original location, which is always less than 100% (95% is recommended in <xref target="RFC5491"/>). The benefit of this is that notifications are naturally limited: small movements at the borders of the region do not trigger notifications.
</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:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com">
<lf:enterOrExit>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</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:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com">
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:lferior>
<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>
</lf: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 no location information. 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>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:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<lf:locationType exact="true">
geodetic
</lf:locationType>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
</section>
<section title="Rate Control">
<t>
<xref target="I-D.ietf-sipcore-event-rate-control"/> defines an extension to the SIP
events framework defining the following three "Event" header field parameters that allow a
subscriber to set a minimum, a maximum and an average rate of event notifications
generated by the notifier. This document makes use of two of the parameters to accomplish
functionality equivalent to the 'responseTime' attribute used in HELD <xref
target="I-D.ietf-geopriv-http-location-delivery"/>, namely "min-interval" (which
specifies a minimum notification time period between two notifications, in seconds) and
"max-interval" (which specifies a maximum notification time period between two
notifications, in seconds.). This specification only defines the semantic for these two
attributes and requires implementation of these two from the set of attributes defined in
<xref target="I-D.ietf-sipcore-event-rate-control"/>. Whenever the time since the most
recent notification exceeds the value in the "max-interval" parameter, then the current
state would be sent in its entirety, just like after a subscription refresh. </t>
<t> If complete state is not immediately available, a NOTIFY containing state (i.e.
location) is generated some time between the time included in 'min-interval' and the time
in 'max-interval'. An important use case for location based applications focuses on the
behavior of the initial NOTIFY message(s) and the information it returns, for example in
case of emergency call routing. When an initial NOTIFY is transmitted it might not include
complete state. </t>
<t>
<figure anchor="rate" title="SUBSCRIBE/NOTIFY with Rate Control">
<artwork><![CDATA[
Subscriber Notifier
|---SUBSCRIBE(1)--->| Request state subscription
|<-------200--------| Acknowledge subscription
|<-----NOTIFY(2)----| Return current state information
|-------200(3)----->|
|<-----NOTIFY(4)----| Return current state information
|--------200------->|
]]></artwork>
</figure>
</t>
<t>
<xref target="rate"/> shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE message (1)
has filters attached and contains a 'max-interval' rate control parameter. In certain
situations it is important to obtain some amount of location information within a
relatively short and pre-defined period of time even if the obtained location information
contains a high amount of uncertainty and location information with less uncertainty at a
later point in time. An example is emergency call routing where a emergency services
routing proxy may need to obtain location information suitable for routing rather quickly
and subsequently a Public Safety Answering Point requests location information for
dispatch. </t>
<t>To obtain location information in a timely fashion using the SUBSCRIBE/NOTIFY mechanism,
it is RECOMMENDED that the initial SUBSCRIBE contains a 'max-interval' rate control
parameter (with a small value) that is in a later message updated to a more sensible
value. The 'max-interval' for this first request is therefore much lower than thereafter.
Updating the 'max-interval' for the subscription can be performed in the 200 response (see
message 3) to the NOTIFY that contains state. Depending on the value in the 'max-interval'
parameter the Notifier may create a NOTIFY message (see message 2) immediately in response
to the SUBSCRIBE that might be empty in case no location information is available at this
point in time. The desired location information may then arrive in the subsequent NOTIFY
message (see message 4). </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:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
]]></artwork>
</figure>
</t>
</section>
<!-- ******************************************************************************* -->
<section title="Security Considerations">
<t>This document builds on a number of specifications, namely </t>
<t>
<list style="symbols">
<t> the SIP event notification mechanism, described in RFC 3265 <xref target="RFC3265"/>,
defining the SUBSCRIBE/NOTIFY messages. </t>
<t>the presence event package, described in RFC 3856 <xref target="RFC3856"/>, which is a
concrete instantiation of the general event notification framework.</t>
<t>the filter framework, described in RFC 4661 <xref target="RFC4661"/>, to offer the
ability to reduce the amount of notifications being sent. </t>
</list>
</t>
<t>Finally, this document indirectly (via the SIP presence event package) relies on PIDF-LO,
described in RFC 4119 <xref target="RFC4119"/>, as the XML container that carries location
information.</t>
<t>Each of these documents listed above comes with a security consideration section but the
security and privacy aspects are best covered by the SIP presence event package, see Section
9 of <xref target="RFC3856"/>, and with the GEOPRIV architectural description found in <xref
target="I-D.ietf-geopriv-arch"/>. The functionality for uploading authorization policies
and other information that limit access to location information are provided by other
protocols, such Common Policy <xref target="RFC4745"/>, Geolocation Policy <xref
target="I-D.ietf-geopriv-policy"/> or more recent work around HELD context <xref
target="I-D.winterbottom-geopriv-held-context"/>. The functionality described in this
document extends the filter framework with location specific filters. Local policies might
be associated with the usage of certain filter constructs and with the amount of
notifications specific filter settings might cause. </t>
<t>Although <xref target="I-D.ietf-geopriv-policy"/> defines a standardized format for
authorization policies but it does not define specific policies for controlling filters
specifically.</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 Richard Barnes and Alissa Cooper, Carl Reed, Adam Roach, Allan Thomson, James
Winterbottom 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.4288" ?>
<?rfc include="reference.RFC.3023" ?>
<?rfc include="reference.RFC.3265" ?>
<?rfc include="reference.RFC.3856" ?>
<?rfc include="reference.RFC.5491" ?>
<?rfc include="reference.I-D.ietf-geopriv-arch" ?>
<?rfc include="reference.I-D.ietf-sipcore-event-rate-control" ?>
<?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.RFC.4745" ?>
<?rfc include="reference.I-D.ietf-geopriv-policy" ?>
<?rfc include="reference.I-D.ietf-sipcore-location-conveyance" ?>
<?rfc include="reference.I-D.ietf-geopriv-http-location-delivery" ?>
<?rfc include="reference.I-D.winterbottom-geopriv-held-context" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 07:53:07 |