Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)
draft-singh-geopriv-pidf-lo-dynamic-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 22, 2008.

Abstract

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.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Behavior
    3.1.  Indicating Use of Dynamic Feature PIDF-LO using SIP
    3.2.  Indicating Use of Dynamic Feature PIDF-LO using HELD
    3.3.  Units of Measure
    3.4.  GML DynamicFeature Schema Usage
4.  Transferring Multiple Location Objects
5.  Example
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Alternatives Considered
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The Presence Information Data Format - Location Object (PIDF-LO) (see RFC 4119 [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.)) 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.

This document defines a location vector by extending the the <location>, introduced by RFC 4119, to carry temporal feature elements:

speed:

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.)

This element contains a 'uom' (Units Of Measure) attribute, which is a reference to a reference system for the amount. 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 Section 3.3 (Units of Measure).

bearing:

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.

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.

acceleration:

This element specifies the rate (usually rapid) at which something happens. The <acceleration> element also contains a 'uom' attribute.

directionOfObject:

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.

2.  Terminology

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 [2] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document uses the terminology from [3] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.).

3.  Protocol Behavior

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.

3.1.  Indicating Use of Dynamic Feature PIDF-LO using SIP

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:

Accept: application/pidf+xml; supported="geopriv-temporal-features"

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.

Content-Type: application/pidf+xml;

3.2.  Indicating Use of Dynamic Feature PIDF-LO using HELD

There are two areas where it is useful to provide feature indication; the HELD context draft [6] (Winterbottom, J., Tschofenig, H., and M. Thomson, “Location URI Contexts in HTTP-Enabled Location Delivery (HELD),” October 2009.)" 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.

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.

In a future version of this document the above-described functionality will be added.

3.3.  Units of Measure

GML permits a range of units of measure for the uom attribute. This document restricts this set to the #m/s

[ Editor's Note: Need to find the URN for #m/s]

3.4.  GML DynamicFeature Schema Usage

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>.

These four elements are conveyed inside the <location-info> element defined by RFC 4119 [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.).

4.  Transferring Multiple Location Objects

Multiple location vector objects may be required to be transported simultaneously. This can be achieved using <timed-presence> defined in RFC 4481 [4] (Schulzrinne, H., “Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals,” July 2006.).

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.

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 Section 5 (Example).

   <?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>

5.  Example

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.

<?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>

The following example shows multiple PIDF-LO using <timed-status>.

<?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>

6.  Security Considerations

This document defines additional location elements carried by PIDF-LO (see [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.)). The security considerations of RFC 4119 [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) are applicable to this document.

7.  IANA Considerations

This section needs to register a token for indicating the dynamic feature capability, see Section 3.1 (Indicating Use of Dynamic Feature PIDF-LO using SIP).

8.  Acknowledgements

We would like to thank Carl Reed, Rohan Mahy, Cullen Jennings, Martin Thomson, Brian Rosen, and Klaus Darilion for their comments.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Alternatives Considered

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. Figure 3 (Example of a PIDF-LO with a track Element) shows such an instance document carrying the <track> element.

<?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>

The authors decided to pick the simplest version.

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.