One document matched: draft-singh-geopriv-pidf-lo-dynamic-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml'>
<!ENTITY RFC3693 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml'>
<!ENTITY RFC4481 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4481.xml'>
<!ENTITY I-D.winterbottom-geopriv-held-context PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-held-context.xml'>
]>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="std" ipr="full3978" docName="draft-singh-geopriv-pidf-lo-dynamic-02.txt">
<front>
<title abbrev="Dynamic Feature Extensions to PIDF-LO">Dynamic Feature Extensions to the Presence
Information Data Format Location Object (PIDF-LO)</title>
<author initials="V." surname="Singh" fullname="Singh Vishal">
<organization/>
<address>
<postal>
<street/>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>singh.vishal@gmail.com</email>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<city>450 Computer Science Building</city>
<region>New York, NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2007"/>
<abstract>
<t>The Geopriv Location Object introduced by the Presence Information Data Format - Location
Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information
of a presentity. This document extends the <location> element specified in RFC
4119 to carry temporal feature elements useful for tracking moving objects. It defines five
elements, namely speed, bearing, acceleration elevation and directionOfObject. The document
also specifies mechanisms to carry multiple moving object's status elements and proposes a
mechanism to indicate the type of the PIDF-LO content. </t>
</abstract>
</front>
<middle>
<!-- **************************************************************************************** -->
<section title="Introduction">
<t>The Presence Information Data Format - Location Object (PIDF-LO) (see RFC 4119 <xref
target="RFC4119"/>) provides geographical location of the presentity. This corresponds to
a physical location at a given instance of time. However, a number of applications,
described below, can benefit from having access to information about changes in location.
Location change information is likely to be useful for logistics and public safety. For
example, shipping companies or dispatch centers can use it to track whether vehicles are
deviating from an established path or exceeding speed limits. </t>
<t> This document defines a location vector by extending the the <location>,
introduced by RFC 4119, to carry temporal feature elements: </t>
<t>
<list style="hanging">
<t hangText="speed:"><vspace blankLines="1"/>Speed is the rate of motion. (The terms speed
and velocity are often used interchangeably, but speed is a scaler, having magnitude
only, while velocity is a vector quantity, having both magnitude and direction.) <vspace
blankLines="1"/> This element contains a 'uom' (Units Of Measure) attribute, which is
a reference to a reference system for the amount.
<!--
This PIDF extension expresses speed using the GML <speed> element with the
unit of measure being meters per second (#ms).
-->
The 'uom' attribute uses a URI to refer to a unit of measure definition. The GML
document defines a set of convenience measure types described in ISO 19103. This is
further explained in <xref target="uoms"/>. <vspace blankLines="1"/>
</t>
<t hangText="bearing:"><vspace blankLines="1"/> Bearing is defined as the horizontal
direction of one terrestrial point from another, expressed as the angular distance from
a reference direction. It is usually measured from 000 degrees at the reference
direction clockwise through 360 degrees. <vspace blankLines="1"/> The
<bearing> element is of type gml:DirectionPropertyType and contains a
gml:DirectionVector, gml:CompassPoint, DirectionKeyword, or a DirectionString element.
This document profiles the usage of this GML element and suggests the usage of the
<DirectionVector> element. <vspace blankLines="1"/>
</t>
<!-- gml:Directorvectors are specified by
providing components of a vector or two angles. A compass point is specified by a simple
enumeration string type (e.g., "N", "NNE", "NE", ... "W"). Two elements to contain
text-based descriptions of direction are provided. If the direction is specified using a
term from a list, gml:KeyWord may be used, and the list indicated using the value of the
codeSpace attribute. If the direction is described in prose, gml:DirectionString may be
used, allowing the value to be included inline or by reference.<vspace blankLines="1"/>
</t>
-->
<t hangText="acceleration:"><vspace blankLines="1"/>This element specifies the rate
(usually rapid) at which something happens. The <acceleration> element also contains a
'uom' attribute.<vspace blankLines="1"/>
</t>
<!--
<t hangText="elevation:">
<vspace blankLines="1"/>The height of a thing above a reference level; altitude.
Similarly to the <speed> and the <elevation> element the
<acceleration> element contains a 'uom' (Units Of Measure) attribute,
which is a reference to a reference system for the amount. The ability to use the
'elevation' element together with geospatial location offers a more compact way of
expressing composite location information per RFC 3825 <xref target="RFC3825"/> location
information using a civic floor number.<vspace blankLines="1"/>
</t>
-->
<t hangText="directionOfObject:"> <vspace blankLines="1"/>The <directionOfObject> describes the
instantaneous horizontal of the front of the object relative to true north and the
vertical angle relative to the earth's spheroid. It uses the GML
<directionVector> element.
<!-- This element is similar to 'bearing' except that it
defines the direction in which an object is present from the point of observer. It will
be relative to a fixed reference direction like magnetic north.
-->
</t>
</list>
</t>
</section>
<!-- **************************************************************************************** -->
<section title="Terminology">
<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 <xref target="RFC2119"/>. </t>
<t> This document uses the terminology from <xref target="RFC3693"/>. </t>
</section>
<!-- **************************************************************************************** -->
<section title="Protocol Behavior">
<t> The document describes the protocol requirements for dynamic feature extensions, so that
it can be transmitted by the Location Server or the Location Information Server and
understood correctly by Location Recipients. Location Recipients should be able to indicate
to the server that they can handle the dynamic feature elements. The server should also
indicate to the clients that the type of location object is PIDF-LO including the dynamic
feature extension. Also, the unit of measurements should be communicated by server and
understood by the clients. </t>
<section anchor="capability" title="Indicating Use of Dynamic Feature PIDF-LO using SIP">
<t> The watcher can can indicate its capability using the SIP Accept header. This document
proposes to add a 'supported' parameter for the application/pidf-xml media type. It
enumerates the non default namespaces supported by the UAS. An example is given below: </t>
<!-- <t> Accept: application/pidf+xml; supported="urn:ietf:params:xml:ns:temporal1" </t>
<t> Alternatively, a token can be defined and used, an example is given: </t> -->
<t> Accept: application/pidf+xml; supported="geopriv-temporal-features" </t>
<t> The server can specify the type of content using Content-Type header. The specific
PIDF-LO type can be obtained by looking inside the XML content. </t>
<t> Content-Type: application/pidf+xml; </t>
</section>
<section title="Indicating Use of Dynamic Feature PIDF-LO using HELD">
<t>There are two areas where it is useful to provide feature indication; the HELD context
draft <xref target="I-D.winterbottom-geopriv-held-context"/>" allows a Target (or an
entity acting on behalf of the Target) to constraint the dereferencing procedure. Hence,
it is useful to indicate whether dynamic features should or should not presented to the
Location Recipient when a location URI is dereferenced.</t>
<t>Furthermore, when a dereferencing protocol based on HTTP is used then the Location
Recipient might want to express the desire to receive a specific response, for example a
PIDF-LO that contains a trace. </t>
<t>In a future version of this document the above-described functionality will be added.</t>
</section>
<!-- **************************************************************************************** -->
<section anchor="uoms" title="Units of Measure">
<t>GML permits a range of units of measure for the uom attribute. This document restricts this
set to the #m/s</t>
<t>[ Editor's Note: Need to find the URN for #m/s]</t>
</section>
<!-- **************************************************************************************** -->
<section title="GML DynamicFeature Schema Usage">
<t>This document does not define a new schema but instead re-uses a subset of the
dynamicFeature.xsd schema available with GML 3.1.1, namely
<speed>, <bearing>, <acceleration>, and <directionOfObject>.
</t>
<t>These four elements are conveyed inside
the <location-info> element defined by RFC 4119 <xref target="RFC4119"/>.
</t>
</section>
</section>
<!-- **************************************************************************************** -->
<section title="Transferring Multiple Location Objects">
<t> Multiple location vector objects may be required to be transported simultaneously. This
can be achieved using <timed-presence> defined in RFC 4481 <xref
target="RFC4481"/>. </t>
<t> Typically, the watcher applications can reconstruct the path as well as dynamic behavior
(speed, acceleration etc.) along the path by storing the received location vector objects.
However, a new Location Recipient may be interested in past location-vectors or may choose
to receive notifications at a slower rate without losing valuable information. In other
words, it can request to receive multiple location vector objects together. For example, it
may want to get one NOTIFY every 15 minutes with multiple location objects aggregated. </t>
<t> The structure of the document which can be used for tracking moving objects using
timed-status extension is shown below. An example is given in <xref target="example"/>. </t>
<t>
<figure>
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence>
<tuple>
<status>
<gp:geopriv>
..........
</gp:geopriv>
</status>
<timestamp>.....</timestamp>
<timed-status from="start-time" until="end-time">
<gp:geopriv>
............
</gp:geopriv>
<gp:geopriv>
...........
</gp:geopriv>
</timed-status>
</tuple>
<device>
.......
</device>
<person>
.......
</person>
</presence>
]]>
</artwork>
</figure>
</t>
</section>
<!-- **************************************************************************************** -->
<!-- **************************************************************************************** -->
<section anchor="example" title="Example">
<t>The following example shows a PIDF-LO indicating geospatial location information using the
gml:Point structure. Outside the <gml:location/> element the additional fields
releated to temporal characteristics are included.</t>
<t>
<figure anchor="example-speed" title="Example of a PIDF-LO with Speed Information">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
</gml:location>
<gml:speed uom="#m/s">12</gml:speed>
<gml:bearing>
<gml:DirectionVector>
<gml:vector> 270.0 -60.0</gml:vector>
</gml:DirectionVector>
</gml:bearing>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2008-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
</t>
<t>The following example shows multiple PIDF-LO using <timed-status>.</t>
<t>
<figure anchor="example-speed-multiple-location-objects-simultaneous"
title="Example showing multiple Location Vectors transmitted simultaneously.">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point>
<gml:pos>140. -35.</gml:pos>
</gml:Point>
</gml:location>
<gml:speed uom="#m/s">12</gml:speed>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</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>
<timed-statusfrom="2005-08-15T10:20:00.000-05:00"
until="2005-08-22T19:30:00.000-05:00">>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point>
<gml:pos>110. -35.</gml:pos>
</gml:Point>
</gml:location>
<gml:speed uom="#m/s">10</gml:speed>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:55:29Z
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point>
<gml:pos>114. -35.</gml:pos>
</gml:Point>
</gml:location>
<gml:speed uom="#m/s">18</gml:speed>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:53:29Z
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</timed-status>
</tuple>
</presence>
]]></artwork>
</figure>
</t>
</section>
<!-- **************************************************************************************** -->
<section title="Security Considerations">
<t>This document defines additional location elements carried by PIDF-LO (see <xref
target="RFC4119"/>). The security considerations of RFC 4119 <xref target="RFC4119"/> are
applicable to this document. </t>
</section>
<!-- **************************************************************************************** -->
<section title="IANA Considerations">
<t>This section needs to register a token for indicating the dynamic feature capability,
see <xref target="capability"/>.</t>
</section>
<!-- **************************************************************************************** -->
<section title="Acknowledgements">
<t>We would like to thank Carl Reed, Rohan Mahy, Cullen Jennings, Martin Thomson, Brian Rosen,
and Klaus Darilion for their comments.</t>
</section>
<!-- **************************************************************************************** -->
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
</reference> &RFC3693; &RFC4119; <reference anchor="GML">
<front>
<title abbrev="">Geographic information - Geography Markup Language (GML), OpenGIS
03-105r1, available at: http://portal.opengeospatial.org/files/?artifact_id=4700 </title>
<author fullname="Cox, S.">
<organization/>
</author>
<author fullname="Daisey, P.">
<organization/>
</author>
<author fullname="Lake, R.">
<organization/>
</author>
<author fullname="Portele, C.">
<organization/>
</author>
<author fullname="Whiteside, A.">
<organization/>
</author>
<date month="April" year="2004"/>
</front>
</reference> &RFC4481; </references>
<references title="Informative References">
&I-D.winterbottom-geopriv-held-context; </references>
<!-- **************************************************************************************** -->
<section title="Alternatives Considered">
<t>During the work on this document we encountered alternative approaches. These approaches
make use of the MovingObjectStatus or its parent element track of dynamicFeature.xsd.
MovingObjectStatus contains child elements where no use cases are currently known, e.g.,
validTime and contains elements that are already defined with PIDF-LO, such as
<location>. Since it might not be know whether a Location Recipient
understands the location extension defined in this document a PIDF-LO with a
<location> element inside the <MovingObjectStatus> will likely
create problems. Including the <location> element twice, once as defined with
RFC 4119 (PIDF-LO) and again in <MovingObjectStatus>, is unnecessary. The
<track> element allows multiple <MovingObjectStatus> to be used.
<xref target="track-example"/> shows such an instance document carrying the
<track> element.</t>
<t>
<figure anchor="track-example" title="Example of a PIDF-LO with a track Element">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:track>
<gml:MovingObjectStatus>
<gml:validTime>
<gml:TimeInstant>
<gml:timePosition>2005-11-28T13:00:00
</gml:timePosition>
</gml:TimeInstant>
</gml:validTime>
<gml:location>
<gml:Point>
<gml:pos>140. -35.</gml:pos>
</gml:Point>
</gml:location>
<gml:speed uom="#kph">12</gml:speed>
<gml:bearing>
<gml:CompassPoint>SE</gml:CompassPoint>
</gml:bearing>
</gml:MovingObjectStatus>
<gml:MovingObjectStatus>
<gml:validTime>
<gml:TimeInstant>
<gml:timePosition>2005-11-28T14:00:00
</gml:timePosition>
</gml:TimeInstant>
</gml:validTime>
<gml:location>
<gml:Point>
<gml:pos>140.1 -34.9</gml:pos>
</gml:Point>
</gml:location>
<gml:speed uom="#kph">23.</gml:speed>
<gml:bearing>
<gml:CompassPoint>ESE</gml:CompassPoint>
</gml:bearing>
</gml:MovingObjectStatus>
</gml:track>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</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>
]]></artwork>
</figure>
</t>
<t>The authors decided to pick the simplest version.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:17:38 |