Network Working Group V. Singh
Internet-Draft
Intended status: Standards Track H. Schulzrinne
Expires: January 13, 2009 Columbia University
H. Tschofenig
Nokia Siemens Networks
July 12, 2008
Dynamic Feature Extensions to the Presence Information Data Format
Location Object (PIDF-LO)
draft-singh-geopriv-pidf-lo-dynamic-03.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 January 13, 2009.
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
Singh, et al. Expires January 13, 2009 [Page 1]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
proposes a mechanism to indicate the type of the PIDF-LO content.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Indicating Use of Dynamic Feature PIDF-LO using SIP . . . 4
3.2. Indicating Use of Dynamic Feature PIDF-LO using HELD . . . 4
3.3. Units of Measure . . . . . . . . . . . . . . . . . . . . . 5
3.4. GML DynamicFeature Schema Usage . . . . . . . . . . . . . 5
4. Transferring Multiple Location Objects . . . . . . . . . . . . 5
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Singh, et al. Expires January 13, 2009 [Page 2]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
1. Introduction
The Presence Information Data Format - Location Object (PIDF-LO) (see
RFC 4119 [1]) 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.
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.
Singh, et al. Expires January 13, 2009 [Page 3]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
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].
This document uses the terminology from [3].
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]" allows a Target (or an entity acting on
Singh, et al. Expires January 13, 2009 [Page 4]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
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].
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].
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.
Singh, et al. Expires January 13, 2009 [Page 5]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
<?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>
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.
Singh, et al. Expires January 13, 2009 [Page 6]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
<?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>
Figure 1: Example of a PIDF-LO with Speed Information
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">
<device id="sg89ae">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point>
<gml:pos>140. -35.</gml:pos>
Singh, et al. Expires January 13, 2009 [Page 7]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
</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>
Singh, et al. Expires January 13, 2009 [Page 8]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
Figure 2: Example showing multiple Location Vectors transmitted
simultaneously.
6. Security Considerations
This document defines additional location elements carried by PIDF-LO
(see [1]). The security considerations of RFC 4119 [1] are
applicable to this document.
7. IANA Considerations
[Editor's Note: This section needs to register a token for
indicating the dynamic feature capability, see Section 3.1.]
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
[1] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, December 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[4] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals", RFC 4481, July 2006.
[5] "Geographic information - Geography Markup Language (GML),
OpenGIS 03-105r1, available at:
http://portal.opengeospatial.org/files/?artifact_id=4700",
April 2004.
Singh, et al. Expires January 13, 2009 [Page 9]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
9.2. Informative References
[6] Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD Protocol
Context Management Extensions",
draft-winterbottom-geopriv-held-context-02 (work in progress),
February 2008.
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 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">
<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>
Singh, et al. Expires January 13, 2009 [Page 10]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
<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>
Figure 3: Example of a PIDF-LO with a track Element
The authors decided to pick the simplest version.
Authors' Addresses
Singh Vishal
Email: singh.vishal@gmail.com
Singh, et al. Expires January 13, 2009 [Page 11]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building, New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Singh, et al. Expires January 13, 2009 [Page 12]
Internet-Draft Dynamic Feature Extensions to PIDF-LO July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Singh, et al. Expires January 13, 2009 [Page 13]
