Difference between revisions of "RFC5962"

From RFC-Wiki
imported>Admin
(Created page with " Internet Engineering Task Force (IETF) H. SchulzrinneRequest for Comments: 5962 V. SinghCategory: Standards Track...")
 
Line 1: Line 1:
 +
Internet Engineering Task Force (IETF)                    H. Schulzrinne
 +
Request for Comments: 5962                                      V. Singh
 +
Category: Standards Track                            Columbia University
 +
ISSN: 2070-1721                                            H. Tschofenig
 +
                                              Nokia Siemens Networks
 +
                                                          M. Thomson
 +
                                                  Andrew Corporation
 +
                                                      September 2010
  
 +
    Dynamic Extensions to the Presence Information Data Format
 +
                    Location Object (PIDF-LO)
  
 
+
'''Abstract'''
 
 
 
 
 
 
Internet Engineering Task Force (IETF)                    H. SchulzrinneRequest for Comments: 5962                                      V. SinghCategory: Standards Track                            Columbia UniversityISSN: 2070-1721                                            H. Tschofenig                                              Nokia Siemens Networks                                                          M. Thomson                                                  Andrew Corporation                                                      September 2010
 
 
 
    Dynamic Extensions to the Presence Information Data Format                    Location Object (PIDF-LO)
 
Abstract
 
  
 
The Geopriv Location Object introduced by the Presence Information
 
The Geopriv Location Object introduced by the Presence Information
Data Format - Location Object (PIDF-LO), [[RFC4119|RFC 4119]], defines a basic
+
Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic
 
XML format for carrying geographical information of a presentity.
 
XML format for carrying geographical information of a presentity.
 
This document defines PIDF-LO extensions to convey information about
 
This document defines PIDF-LO extensions to convey information about
Line 17: Line 20:
 
spatial orientation, speed, and heading of the presentity.
 
spatial orientation, speed, and heading of the presentity.
  
Status of This Memo
+
'''Status of This Memo'''
  
 
This is an Internet Standards Track document.
 
This is an Internet Standards Track document.
Line 25: Line 28:
 
received public review and has been approved for publication by the
 
received public review and has been approved for publication by the
 
Internet Engineering Steering Group (IESG).  Further information on
 
Internet Engineering Steering Group (IESG).  Further information on
Internet Standards is available in Section 2 of [[RFC5741|RFC 5741]].
+
Internet Standards is available in Section 2 of RFC 5741.
  
 
Information about the current status of this document, any errata,
 
Information about the current status of this document, any errata,
Line 31: Line 34:
 
http://www.rfc-editor.org/info/rfc5962.
 
http://www.rfc-editor.org/info/rfc5962.
  
 
+
'''Copyright Notice'''
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Copyright Notice
 
  
 
Copyright (c) 2010 IETF Trust and the persons identified as the
 
Copyright (c) 2010 IETF Trust and the persons identified as the
 
document authors.  All rights reserved.
 
document authors.  All rights reserved.
  
This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal
+
This document is subject to BCP 78 and the IETF Trust's Legal
 
Provisions Relating to IETF Documents
 
Provisions Relating to IETF Documents
 
(http://trustee.ietf.org/license-info) in effect on the date of
 
(http://trustee.ietf.org/license-info) in effect on the date of
Line 66: Line 52:
  
 
The Presence Information Data Format - Location Object (PIDF-LO) (see
 
The Presence Information Data Format - Location Object (PIDF-LO) (see
[[RFC4119|RFC 4119]] [RFC4119]) provides geographical location of a presentity.
+
RFC 4119 [[[RFC4119]]]) provides geographical location of a presentity.
 
This corresponds to a physical location at a given instance of time.
 
This corresponds to a physical location at a given instance of time.
[[RFC5491|RFC 5491]] [RFC5491] extends PIDF-LO and provides additional guidelines
+
RFC 5491 [[[RFC5491]]] extends PIDF-LO and provides additional guidelines
 
to implementers.
 
to implementers.
  
Line 75: Line 61:
 
information to the PIDF-LO enables a range of use cases.  These use
 
information to the PIDF-LO enables a range of use cases.  These use
 
cases either use dynamic information directly or use that information
 
cases either use dynamic information directly or use that information
 
 
 
 
 
 
 
 
  
 
for smoother tracking of a position over time.  For example, an
 
for smoother tracking of a position over time.  For example, an
Line 94: Line 72:
 
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
 
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in [[RFC2119|RFC 2119]]
+
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119].
+
[[[RFC2119]]].
  
This document uses the term "presentity", as defined in [[RFC2778|RFC 2778]]
+
This document uses the term "presentity", as defined in RFC 2778
[RFC2778], to refer to the device subject to location determination.
+
[[[RFC2778]]], to refer to the device subject to location determination.
 
The similarity to presence concepts and the abstract location privacy
 
The similarity to presence concepts and the abstract location privacy
architecture, as described in [[RFC4079|RFC 4079]] [RFC4079], led to re-use of
+
architecture, as described in RFC 4079 [[[RFC4079]]], led to re-use of
the Presence Information Data Format (PIDF) (see [[RFC3863|RFC 3863]] [RFC3863]),
+
the Presence Information Data Format (PIDF) (see RFC 3863 [[[RFC3863]]]),
and its enhancement for location information (see [[RFC4119|RFC 4119]]
+
and its enhancement for location information (see RFC 4119
[RFC4119]).  Note that this document does not differentiate between
+
[[[RFC4119]]]).  Note that this document does not differentiate between
 
human and non-human objects, and hence both are in scope.
 
human and non-human objects, and hence both are in scope.
  
Line 128: Line 106:
 
   device, this orientation might depend on the type of device.  See
 
   device, this orientation might depend on the type of device.  See
 
   Section 3.1 for details.
 
   Section 3.1 for details.
 
 
 
 
 
 
 
 
  
 
speed:
 
speed:
Line 178: Line 148:
 
     </dm:device>
 
     </dm:device>
 
</presence>
 
</presence>
 
 
 
 
 
 
 
 
 
 
 
  
 
Another example shows a PIDF-LO document of the presentity
 
Another example shows a PIDF-LO document of the presentity
Line 227: Line 186:
 
=== Angular Measures and Coordinate Reference Systems ===
 
=== Angular Measures and Coordinate Reference Systems ===
  
[RFC5491] constrains the coordinate reference system (CRS) used in
+
[[[RFC5491]]] constrains the coordinate reference system (CRS) used in
 
PIDF-LO to World Geodetic System 1984 (WGS 84), using either the two-
 
PIDF-LO to World Geodetic System 1984 (WGS 84), using either the two-
 
dimensional (latitude, longitude) CRS identified by
 
dimensional (latitude, longitude) CRS identified by
Line 238: Line 197:
 
The <orientation> element describes the "direction of facing"; the
 
The <orientation> element describes the "direction of facing"; the
 
<heading> element describes the "direction of travel".  Both measures
 
<heading> element describes the "direction of travel".  Both measures
 
 
 
 
  
 
contain one or two angular values that are expressed relative to the
 
contain one or two angular values that are expressed relative to the
Line 291: Line 246:
 
     </xs:complexContent>
 
     </xs:complexContent>
 
   </xs:complexType>
 
   </xs:complexType>
 
 
 
 
  
 
   <xs:simpleType name="directionType">
 
   <xs:simpleType name="directionType">
Line 313: Line 264:
 
This document defines additional location elements carried by
 
This document defines additional location elements carried by
 
PIDF-LO.  These additional elements provide greater reason to observe
 
PIDF-LO.  These additional elements provide greater reason to observe
the privacy and security considerations described in [[RFC4119|RFC 4119]]
+
the privacy and security considerations described in RFC 4119
[RFC4119].  No further privacy or security measures are necessary.
+
[[[RFC4119]]].  No further privacy or security measures are necessary.
  
[[RFC4119|RFC 4119]] points back to [[RFC3694|RFC 3694]] [RFC3694] and [[RFC3693|RFC 3693]] [RFC3693] to
+
RFC 4119 points back to RFC 3694 [[[RFC3694]]] and RFC 3693 [[[RFC3693]]] to
 
describe the threat model and the security requirements imposed on
 
describe the threat model and the security requirements imposed on
 
the GEOPRIV architecture for sharing location information as a result
 
the GEOPRIV architecture for sharing location information as a result
Line 335: Line 286:
  
 
This section registers a new XML namespace (as described in
 
This section registers a new XML namespace (as described in
[RFC3688]) and a new XML schema.
+
[[[RFC3688]]]) and a new XML schema.
  
 
=== Dynamic Feature Extensions Namespace Registration ===
 
=== Dynamic Feature Extensions Namespace Registration ===
Line 343: Line 294:
 
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig
 
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig
  
 
 
 
 
 
  
 
XML:
 
XML:
Line 392: Line 338:
 
Hilarie Orman for her SECDIR review, and Joel Jaeggli for his
 
Hilarie Orman for her SECDIR review, and Joel Jaeggli for his
 
Operations Directorate review.
 
Operations Directorate review.
 
 
 
 
 
 
 
 
 
  
 
== References ==
 
== References ==
Line 406: Line 343:
 
=== Normative References ===
 
=== Normative References ===
  
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate           Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
+
[[[RFC2119]]]  Bradner, S., "Key words for use in RFCs to Indicate
[RFC3688]  Mealling, M., "The IETF XML Registry", [[BCP81|BCP 81]], [[RFC3688|RFC 3688]],            January 2004.
+
            Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object            Format", [[RFC4119|RFC 4119]], December 2005.
 
=== Informative References ===
 
 
 
[RFC2778]  Day, M., Rosenberg, J., and H. Sugano, "A Model for            Presence and Instant Messaging", [[RFC2778|RFC 2778]], February 2000.
 
[RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and            J. Polk, "Geopriv Requirements", [[RFC3693|RFC 3693]], February 2004.
 
[RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,            "Threat Analysis of the Geopriv Protocol", [[RFC3694|RFC 3694]],            February 2004.
 
[RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,            W., and J. Peterson, "Presence Information Data Format            (PIDF)", [[RFC3863|RFC 3863]], August 2004.
 
[RFC4079]  Peterson, J., "A Presence Architecture for the            Distribution of GEOPRIV Location Objects", [[RFC4079|RFC 4079]],            July 2005.
 
[RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig,            "GEOPRIV Presence Information Data Format Location Object            (PIDF-LO) Usage Clarification, Considerations, and            Recommendations", [[RFC5491|RFC 5491]], March 2009.
 
 
 
 
 
 
 
 
 
 
 
  
 +
[[[RFC3688]]]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
 +
            January 2004.
  
 +
[[[RFC4119]]]  Peterson, J., "A Presence-based GEOPRIV Location Object
 +
            Format", RFC 4119, December 2005.
  
 +
=== Informative References ===
  
 +
[[[RFC2778]]]  Day, M., Rosenberg, J., and H. Sugano, "A Model for
 +
            Presence and Instant Messaging", RFC 2778, February 2000.
  
 +
[[[RFC3693]]]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
 +
            J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
  
 +
[[[RFC3694]]]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
 +
            "Threat Analysis of the Geopriv Protocol", RFC 3694,
 +
            February 2004.
  
 +
[[[RFC3863]]]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
 +
            W., and J. Peterson, "Presence Information Data Format
 +
            (PIDF)", RFC 3863, August 2004.
  
 +
[[[RFC4079]]]  Peterson, J., "A Presence Architecture for the
 +
            Distribution of GEOPRIV Location Objects", RFC 4079,
 +
            July 2005.
  
 +
[[[RFC5491]]]  Winterbottom, J., Thomson, M., and H. Tschofenig,
 +
            "GEOPRIV Presence Information Data Format Location Object
 +
            (PIDF-LO) Usage Clarification, Considerations, and
 +
            Recommendations", RFC 5491, March 2009.
  
 
Appendix A.  Earth Centered, Earth Fixed Direction Vectors
 
Appendix A.  Earth Centered, Earth Fixed Direction Vectors
The absolute orientation or heading of a presentity depends on itslatitude and longitude.  The following vectors can be used todetermine the absolute direction in the WGS 84 Earth Centered, EarthFixed (X, Y, Z) coordinate space.
 
The direction of North as a unit vector in Earth Centered, EarthFixed (ECEF) coordinates is:
 
  North = [ -1 * sin(latitude) * cos(longitude),            -1 * sin(latitude) * sin(longitude),            cos(latitude) ]
 
The direction of "up" (the upward normal of the horizontal plane) asa unit vector in ECEF coordinates is:
 
  Up = [ cos(latitude) * cos(longitude),          cos(latitude) * sin(longitude),          sin(latitude) ]
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 +
The absolute orientation or heading of a presentity depends on its
 +
latitude and longitude.  The following vectors can be used to
 +
determine the absolute direction in the WGS 84 Earth Centered, Earth
 +
Fixed (X, Y, Z) coordinate space.
  
 +
The direction of North as a unit vector in Earth Centered, Earth
 +
Fixed (ECEF) coordinates is:
  
 +
  North = [ -1 * sin(latitude) * cos(longitude),
 +
            -1 * sin(latitude) * sin(longitude),
 +
            cos(latitude) ]
  
 +
The direction of "up" (the upward normal of the horizontal plane) as
 +
a unit vector in ECEF coordinates is:
  
 +
  Up = [ cos(latitude) * cos(longitude),
 +
          cos(latitude) * sin(longitude),
 +
          sin(latitude) ]
  
 
Authors' Addresses
 
Authors' Addresses
Line 482: Line 410:
  
 
URI:  http://www.cs.columbia.edu/
 
URI:  http://www.cs.columbia.edu/
 
  
 
Vishal Singh
 
Vishal Singh
Line 493: Line 420:
  
 
URI:  http://www.cs.columbia.edu/~vs2140
 
URI:  http://www.cs.columbia.edu/~vs2140
 
  
 
Hannes Tschofenig
 
Hannes Tschofenig
Line 504: Line 430:
  
 
URI:  http://www.tschofenig.priv.at/
 
URI:  http://www.tschofenig.priv.at/
 
  
 
Martin Thomson
 
Martin Thomson
Line 512: Line 437:
  
  
 
 
 
 
 
 
 
 
  
 
[[Category:Standards Track]]
 
[[Category:Standards Track]]

Revision as of 02:39, 1 October 2020

Internet Engineering Task Force (IETF) H. Schulzrinne Request for Comments: 5962 V. Singh Category: Standards Track Columbia University ISSN: 2070-1721 H. Tschofenig

                                              Nokia Siemens Networks
                                                          M. Thomson
                                                  Andrew Corporation
                                                      September 2010
   Dynamic Extensions to the Presence Information Data Format
                   Location Object (PIDF-LO)

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 defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5962.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Introduction

The Presence Information Data Format - Location Object (PIDF-LO) (see RFC 4119 [[[RFC4119]]]) provides geographical location of a presentity. This corresponds to a physical location at a given instance of time. RFC 5491 [[[RFC5491]]] extends PIDF-LO and provides additional guidelines to implementers.

This document extends PIDF-LO to convey spatial orientation, speed, and heading of a presentity. The addition of rate-of-change information to the PIDF-LO enables a range of use cases. These use cases either use dynamic information directly or use that information

for smoother tracking of a position over time. For example, an application that continuously tracks a presentity could use velocity information to extrapolate positions in between times that location information is measured. A shipping company could directly use speed to monitor delivery truck speed to ensure speed limits are observed.

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 [[[RFC2119]]].

This document uses the term "presentity", as defined in RFC 2778 [[[RFC2778]]], to refer to the device subject to location determination. The similarity to presence concepts and the abstract location privacy architecture, as described in RFC 4079 [[[RFC4079]]], led to re-use of the Presence Information Data Format (PIDF) (see RFC 3863 [[[RFC3863]]]), and its enhancement for location information (see RFC 4119 [[[RFC4119]]]). Note that this document does not differentiate between human and non-human objects, and hence both are in scope.

Dynamic Elements

This document defines a new element, <Dynamic>, for the conveyance of dynamic information.

Dynamic information MAY be included without any other location information being present. When dynamic information is associated with information about the instantaneous position of the presentity, the <Dynamic> element MUST be included in the same <location-info> element as the corresponding geodetic (or civic) location information.

Dynamic information can be safely ignored by a recipient that does not support this specification. The <Dynamic> element contains the following components:

orientation:

  The <orientation> element describes the spatial orientation of the
  presentity -- the direction that the object is pointing.  For a
  device, this orientation might depend on the type of device.  See
  Section 3.1 for details.

speed:

  Speed is the time rate of change in position of a presentity
  without regard for direction: the scalar component of velocity.
  The value for the <speed> element is a measure that is defined in
  meters per second.

heading:

  Heading is the directional component of velocity.  See Section 3.1
  for details.

Each element can be omitted if no information is available. In the following example, the presentity is approximately oriented to the North at a slightly elevated angle. The presentity is travelling 24 meters per second to the West:

<?xml version="1.0" encoding="UTF-8"?> <presence

   xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
   xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
   xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
   xmlns:gml="http://www.opengis.net/gml"
   entity="pres:[email protected]">
   <dm:device id="abc123">
       <gp:geopriv>
           <gp:location-info>
               <dyn:Dynamic>
                   <dyn:orientation>-3 12</dyn:orientation>
                   <dyn:speed>24</dyn:speed>
                   <dyn:heading>278</dyn:heading>
               </dyn:Dynamic>
           </gp:location-info>
           <gp:usage-rules/>
           <method>gps</method>
       </gp:geopriv>
       <timestamp>2009-06-22T20:57:29Z</timestamp>
       <dm:deviceID>mac:1234567890ab</dm:deviceID>
   </dm:device>

</presence>

Another example shows a PIDF-LO document of the presentity [email protected] on a bike travelling 12 meters per second. Her position is indicated as a circle. The values for speed may be used by a receiver to adjust the uncertainty over time.

<?xml version="1.0" encoding="UTF-8"?> <presence

   xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
   xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
   xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0"
   entity="pres:[email protected]">
   <dm:device id="abc123">
       <gp:geopriv>
           <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                   <gml:pos>42.5463 -73.2512</gml:pos>
                   <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                       100
                   </gs:radius>
               </gs:Circle>
               <dyn:Dynamic>
                   <dyn:speed>12</dyn:speed>
               </dyn:Dynamic>
           </gp:location-info>
           <gp:usage-rules/>
           <method>gps</method>
       </gp:geopriv>
       <timestamp>2009-06-22T20:57:29Z</timestamp>
       <dm:deviceID>mac:1234567890ab</dm:deviceID>
   </dm:device>

</presence>

Angular Measures and Coordinate Reference Systems

[[[RFC5491]]] constrains the coordinate reference system (CRS) used in PIDF-LO to World Geodetic System 1984 (WGS 84), using either the two- dimensional (latitude, longitude) CRS identified by "urn:ogc:def:crs:EPSG::4326" or the three-dimensional (latitude, longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979". Dynamic locations similarly assume that either of these coordinate reference systems will be used.

The <orientation> and <heading> elements both describe a direction. The <orientation> element describes the "direction of facing"; the <heading> element describes the "direction of travel". Both measures

contain one or two angular values that are expressed relative to the current position of the presentity (see Appendix A). Angular measures are expressed in degrees, and values can be negative. If two measures are present, the values MUST be separated by whitespace.

The first measure specifies the horizontal direction from the current position of the presentity to a point that it is pointing towards (for <orientation>) or travelling towards (for <heading>). Horizontal angles are measured from Northing to Easting. Horizontal angles start from zero when pointing to or travelling towards the North and increase towards the East.

The second measure, if present, specifies the vertical component of this angle. This angle is the elevation from the local horizontal plane. If the second angle value is omitted, the vertical component is unknown. If only one angle is present, <orientation> describes only the horizontal component. For <heading>, the associated <speed> measure contains only the horizontal component of speed.

Dynamic Feature XML Schema

<?xml version="1.0"?> <xs:schema

   targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
   xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified"
   attributeFormDefault="unqualified">
 <xs:element name="Dynamic" type="dyn:dynamicType"/>
 <xs:complexType name="dynamicType">
   <xs:complexContent>
     <xs:restriction base="xs:anyType">
       <xs:sequence>
         <xs:element name="orientation" minOccurs="0"
                     type="dyn:directionType"/>
         <xs:element name="speed" minOccurs="0"
                     type="xs:double"/>
         <xs:element name="heading" minOccurs="0"
                     type="dyn:directionType"/>
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:restriction>
   </xs:complexContent>
 </xs:complexType>
 <xs:simpleType name="directionType">
   <xs:restriction base="dyn:doubleListType">
     <xs:minLength value="1"/>
     <xs:maxLength value="2"/>
   </xs:restriction>
 </xs:simpleType>
 <xs:simpleType name="doubleListType">
   <xs:list itemType="xs:double"/>
 </xs:simpleType>

</xs:schema>

Security Considerations

This document defines additional location elements carried by PIDF-LO. These additional elements provide greater reason to observe the privacy and security considerations described in RFC 4119 [[[RFC4119]]]. No further privacy or security measures are necessary.

RFC 4119 points back to RFC 3694 [[[RFC3694]]] and RFC 3693 [[[RFC3693]]] to describe the threat model and the security requirements imposed on the GEOPRIV architecture for sharing location information as a result of the threat model. It is important to note that these two documents often refer to threats related to the current location information of a presentity, while this document introduces dynamic information that may be used by attackers to anticipate the future location of a presentity. While already a series of location snapshots is likely to offer information for guessing the future location of a presentity, it has to be said that including more information in a PIDF-LO does increase the severity of an information leak. Those who deploy location-based services are in general strongly advised to provide their users with ways to control the distribution of location information to those who have been authorized to see it.

IANA Considerations

This section registers a new XML namespace (as described in [[[RFC3688]]]) and a new XML schema.

Dynamic Feature Extensions Namespace Registration

URI: urn:ietf:params:xml:ns:pidf:geopriv10:dynamic

Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig

  ([email protected]).

XML:

  BEGIN
  <?xml version="1.0"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
    "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Dynamic Feature Extensions Namespace</title>
  </head>
  <body>

Namespace for Dynamic Feature Extensions to PIDF-LO

urn:ietf:params:xml:ns:pidf:geopriv10:dynamic

See <a href= "http://www.rfc-editor.org/rfc/rfc5962.txt"> RFC5962</a>.

  </body>
  </html>
  END

Dynamic Feature Extensions Schema Registration

URI: urn:ietf:params:xml:schema:pidf:dynamic

Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig

  ([email protected])

XML: The XML schema registered is contained in Section 4. Its first

  line is

<?xml version="1.0"?>

and its last line is

</xs:schema>

Acknowledgements

We would like to thank Klaus Darilion, Cullen Jennings, Rohan Mahy, Carl Reed, and Brian Rosen for their comments. Furthermore, we would like to thank Alexey Melnikov, Adrian Farrel, Tim Polk, Dan Romascanu for his IESG review comments, Avshalom Houri for his GenArt review, Hilarie Orman for her SECDIR review, and Joel Jaeggli for his Operations Directorate review.

References

Normative References

[[[RFC2119]]] Bradner, S., "Key words for use in RFCs to Indicate

           Requirement Levels", BCP 14, RFC 2119, March 1997.

[[[RFC3688]]] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,

           January 2004.

[[[RFC4119]]] Peterson, J., "A Presence-based GEOPRIV Location Object

           Format", RFC 4119, December 2005.

Informative References

[[[RFC2778]]] Day, M., Rosenberg, J., and H. Sugano, "A Model for

           Presence and Instant Messaging", RFC 2778, February 2000.

[[[RFC3693]]] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and

           J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

[[[RFC3694]]] Danley, M., Mulligan, D., Morris, J., and J. Peterson,

           "Threat Analysis of the Geopriv Protocol", RFC 3694,
           February 2004.

[[[RFC3863]]] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,

           W., and J. Peterson, "Presence Information Data Format
           (PIDF)", RFC 3863, August 2004.

[[[RFC4079]]] Peterson, J., "A Presence Architecture for the

           Distribution of GEOPRIV Location Objects", RFC 4079,
           July 2005.

[[[RFC5491]]] Winterbottom, J., Thomson, M., and H. Tschofenig,

           "GEOPRIV Presence Information Data Format Location Object
           (PIDF-LO) Usage Clarification, Considerations, and
           Recommendations", RFC 5491, March 2009.

Appendix A. Earth Centered, Earth Fixed Direction Vectors

The absolute orientation or heading of a presentity depends on its latitude and longitude. The following vectors can be used to determine the absolute direction in the WGS 84 Earth Centered, Earth Fixed (X, Y, Z) coordinate space.

The direction of North as a unit vector in Earth Centered, Earth Fixed (ECEF) coordinates is:

  North = [ -1 * sin(latitude) * cos(longitude),
            -1 * sin(latitude) * sin(longitude),
            cos(latitude) ]

The direction of "up" (the upward normal of the horizontal plane) as a unit vector in ECEF coordinates is:

  Up = [ cos(latitude) * cos(longitude),
         cos(latitude) * sin(longitude),
         sin(latitude) ]

Authors' Addresses

Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US

Phone: +1 212 939 7004 EMail: [email protected] URI: http://www.cs.columbia.edu/

Vishal Singh Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US

EMail: [email protected] URI: http://www.cs.columbia.edu/~vs2140

Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland

Phone: +358 (50) 4871445 EMail: [email protected] URI: http://www.tschofenig.priv.at/

Martin Thomson Andrew Corporation Wollongong NSW Australia

EMail: [email protected]