One document matched: draft-singh-geopriv-pidf-lo-dynamic-04.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 RFC4481 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4481.xml'>
<!ENTITY I-D.ietf-geopriv-pdif-lo-profile PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-pdif-lo-profile.xml'>
]>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="exp" ipr="full3978" docName="draft-singh-geopriv-pidf-lo-dynamic-04.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 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="2008"/>
<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. The PIDF-LO specification made a subset of the functionality offered by the
Geography Markup Language (GML) standard 3.0 mandatory to implement. This document defines
child elements to the <location-info> 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.</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. The PIDF-LO specification made a subset of
the functionality offered by the Geography Markup Language (GML) standard 3.0 mandatory to
implement. With the extensions defined in <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>
more guidelines to implementers are being provided with respect to a number of location
shapes that have to be supported for usage within PIDF-LO. However, a number of applications
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>
</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="XML Extensions">
<t> This document defines a location vector by adding child elements to the
<location-info> element described in RFC 4119 <xref target="RFC4119"/>, to
carry temporal feature elements. A receiver MAY ignore the temporal elements defined in this
document if it does not understand this extension. </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 scalar, having magnitude
only, while velocity is a vector, 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 and a further explaination is
provided at the end of this section. <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 mandates applications using
this document to make use of the <DirectionVector> element only. <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>
<t>GML permits a range of units of measure for the uom attribute. This document restricts this
set to the #m/s (meters per second).</t>
</section>
<!-- **************************************************************************************** -->
<section title="XML Schema">
<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 anchor="example" title="Example">
<t>The following example shows a PIDF-LO document indicating geospatial location information
using the gml:Point structure. Following 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">
<device id="sg89ae">
<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>
<timestamp>2008-06-22T20:57:29Z</timestamp>
</device>
</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 document does not require actions by IANA.</t>
</section>
<!-- **************************************************************************************** -->
<section title="Acknowledgements">
<t>We would like to thank Klaus Darilion, Cullen Jennings, Rohan Mahy, Carl Reed, Brian Rosen,
and Martin Thomson 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> &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.ietf-geopriv-pdif-lo-profile; </references>
<!-- **************************************************************************************** -->
<section title="Transferring Multiple Location Objects within SIP">
<t> To show the path of an object, it may be useful to deliver multiple location vector
objects in one PIDF-LO document to reduce the number of notifications. The
<timed-presence> element <xref target="RFC4481"/> can contain multiple
location objects, with the structure shown in <xref target="multiple1"/> and an example in
<xref target="multiple2"/>. </t>
<t>
<figure anchor="multiple1" title="Structure of Handling Multiple Location Objects">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence>
<device>
<gp:geopriv>
..........
</gp:geopriv>
<timestamp>.....</timestamp>
<timed-status from="start-time" until="end-time">
<gp:geopriv>
............
</gp:geopriv>
<gp:geopriv>
...........
</gp:geopriv>
</timed-status>
</device>
<tuple>
.......
</tuple>
<person>
.......
</person>
</presence>
]]>
</artwork>
</figure>
</t>
<t>The following example shows multiple PIDF-LO using <timed-status>.</t>
<t>
<figure anchor="multiple2"
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">
<device id="sg89ae">
<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>
<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>
</device>
</presence>
]]></artwork>
</figure>
</t>
</section>
<!--
<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:geopriv20"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:geotarget@example.com">
<device id="sg89ae">
<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>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</device>
</presence>
]]></artwork>
</figure>
</t>
<t>The authors decided to pick the simplest version. The above-shown example is not backwards
compatible either.</t>
</section> -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:17:41 |