Network Working Group V. Singh Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia U. Expires: August 5, 2007 H. Tschofenig Siemens Feb 2007 Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO) draft-singh-geopriv-pidf-lo-dynamic-01.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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 element specified in RFC 4119 to carry temporal feature elements useful for tracking moving objects. Singh, et al. Expires August 5, 2007 [Page 1] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 It defines five elements, namely speed, bearing, acceleration elevation and directionOfObject. The document also specifies mechanism to carry multiple moving object's status elements and proposes mechanism to indicate the type of the PIDF-LO content. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Indicating Use of Dynamic Feature PIDF-LO . . . . . . . . 5 3.2. Units of Measure . . . . . . . . . . . . . . . . . . . . . 5 4. Transferring Multiple Location Objects . . . . . . . . . . . . 6 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Singh, et al. Expires August 5, 2007 [Page 2] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 1. Introduction The existing Geopriv location object [5] gives presence information which is geographical location of the presentity. This corresponds to a physical location at a given instance of time. A large number of applications, specifically in the transportation industry, fleet management applications, goods delivery and postal companies require to track not only the geographical location but also the rate of change of location of the entities. Some of the use case scenarios for such an extension are tracking the location of vehicles, monitoring if vehicles are deviating from their planned routes or pre-specified speed-limits, reporting the direction of movement of ships and airplanes at different instances of time, tracking kidnapped/trapped victims for emergency services and tracking of culprits by the police. The applications may be for safety and security of personals and vehicles, productivity management of mobile crews, monitoring to ensure schedules, monitoring to ensure no deviation from scheduled paths. This document defines location vector by extending the the introduced by the Presence Information Data Format Location Object (PIDF-LO), RFC 4119, to carry temporal feature elements. It defines five elements, namely 'speed', 'bearing', 'acceleration', 'elevation' and 'directionOfObject'. The 'speed' and 'accelearation' are used to describe the object which is moving. The 'bearing' is used for the direction of travel of the object and describes true bearing rather then magnetic bearing. The 'directionOfObject' is similar to 'bearing' but it is used to indicate a direction in which an object is present from the presentity. The description of these elements except 'directionOfObject' is taken from GML [1] and repeated for completeness reasons: speed: This element points to a measure of the rate of motion. It contains a 'uom' (Units Of Measure) attribute, which is a reference to a reference system for the amount, often a ratio or interval scale. 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.2. bearing: The element is of type gml:DirectionPropertyType and can contain a gml:DirectionVector, gml:CompassPoint, DirectionKeyword, or a DirectionString element. gml:Directorvectors are specified by Singh, et al. Expires August 5, 2007 [Page 3] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 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. acceleration: This element specifies the rate (usually rapid) at which something happens. Similarly to the and the element the element conains a 'uom' (Units Of Measure) attribute, which is a reference to a reference system for the amount. elevation: The height of a thing above a reference level; altitude. Similarly to the and the element the 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 [6] location information using a civic floor number. directionOfObject: 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. This document therefore allows the existing location formats allowed by the GML feature.xsd schema to be extended with dynamic characteristics. The supported shapes are described in detail in [7]. This document enhances this functionality and offers support for moving objects. 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]. Singh, et al. Expires August 5, 2007 [Page 4] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 3. Protocol Behavior The document describes the protocol requirements for dynamic feature extensions, so that it can be transmitted by the location server and understood correctly by the clients. The clients 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 + dynamic feature extensions. Also, the unit of measurements should be communicated by server and understood by the clients. 3.1. Indicating Use of Dynamic Feature PIDF-LO 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="urn:ietf:params:xml:ns:temporal1" Alternatively, a token can be defined and used, an example is given: 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. Units of Measure GML permits a range of units of measure for all parameters. This document restricts this set to the following units metre, kilometre and mile for distance and seconds for time. Hence, the acceptable units for speed are : #m/s, #km/h and #mph Editor's Note: Need to find the URN for kph, m/s, km/h need to be added here. Editor's Note: Need to find the URN for floor, if it exists. It is only valid for the elevation element. Only the above-listed units of measurements MUST be used for the uom attribute. Singh, et al. Expires August 5, 2007 [Page 5] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 4. Transferring Multiple Location Objects Multiple location vector objects may be required to be transported simultaneously. This can be achieved using 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 watcher 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 6. .......... ..... ............ ........... ....... Singh, et al. Expires August 5, 2007 [Page 6] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 5. XML Schema This section defines the XML schema consisting of five elements that are conveyed inside the element defined by RFC 4119 [5]. The data types are taken from GML except the 'directionOfObject' which may belong to a different namespace. Figure 2: XML Schema 6. Example The following example shows a PIDF-LO indicating geospatial location information using the gml:Point structure. Outside the element the additional fields releated to temporal characteristics are included. Singh, et al. Expires August 5, 2007 [Page 7] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 -34.407 150.883 12 SE no 2003-06-23T04:57:29Z 2003-06-22T20:57:29Z Figure 3: Example of a PIDF-LO with Speed Information The following example shows multiple PIDF-LO using . 140. -35. Singh, et al. Expires August 5, 2007 [Page 8] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 12. no 2003-06-23T04:57:29Z 2003-06-22T20:57:29Z > 110. -35. 10 yes 2003-06-23T04:55:29Z 114. -35. 18. yes 2003-06-23T04:53:29Z Singh, et al. Expires August 5, 2007 [Page 9] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 Figure 4: Example showing multiple Location Vectors transmitted simultaneously. 7. Security Considerations This document defines additional location elements carried by PIDF-LO (see [5]). The security considerations of RFC 4119 [5] are applicable to this document. 8. IANA Considerations A future version of this document will provide IANA considerations. 9. Acknowledgements Add your name here. 10. References 10.1. Normative References [1] "Geographic information - Geography Markup Language (GML), OpenGIS 03-105r1, available at: http://portal.opengeospatial.org/files/?artifact_id=4700", April 2004. [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] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. 10.2. Informative References [6] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. Singh, et al. Expires August 5, 2007 [Page 10] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 [7] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03 (work in progress), December 2006. [8] Mahy, R., "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", draft-ietf-geopriv-loc-filters-01 (work in progress), March 2007. [9] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-07 (work in progress), February 2007. [10] Schulzrinne, H., "Common Policy: A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-11 (work in progress), August 2006. [11] Schulzrinne, H., "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-11 (work in progress), February 2007. 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 . Since it might not be know whether a Location Recipient understands the location extension defined in this document a PIDF-LO with a element inside the will likely create problems. Including the element twice, once as defined with RFC 4119 (PIDF-LO) and again in , is unnecessary. The element allows multiple to be used. Figure 5 shows such an instance document carrying the element. Singh, et al. Expires August 5, 2007 [Page 11] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 2005-11-28T13:00:00 140. -35. 12 SE 2005-11-28T14:00:00 140.1 -34.9 23. ESE no 2003-06-23T04:57:29Z 2003-06-22T20:57:29Z Singh, et al. Expires August 5, 2007 [Page 12] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 Figure 5: Example of a PIDF-LO with a track Element The authors decided to pick the simplest version. Authors' Addresses Singh Vishal Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Email: vs2140@cs.columbia.edu URI: http://www.cs.columbia.edu/~vs2140 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Singh, et al. Expires August 5, 2007 [Page 13] Internet-Draft Dynamic Feature Extensions to PIDF-LO Feb 2007 Full Copyright Statement Copyright (C) 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Singh, et al. Expires August 5, 2007 [Page 14]