idnits 2.17.1 draft-singh-geopriv-pidf-lo-dynamic-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2010) is 5136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GeoShape' is defined on line 395, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Schulzrinne 3 Internet-Draft V. Singh 4 Intended status: Standards Track Columbia University 5 Expires: September 7, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 M. Thomson 8 Andrew Corporation 9 March 6, 2010 11 Dynamic Extensions to the Presence Information Data Format Location 12 Object (PIDF-LO) 13 draft-singh-geopriv-pidf-lo-dynamic-08 15 Abstract 17 The Geopriv Location Object introduced by the Presence Information 18 Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic 19 XML format for carrying geographical information of a presentity. 20 This document defines PIDF-LO extensions to convey information about 21 moving objects. Elements are defined that enable expression of 22 spatial orientation, speed, heading, and acceleration of the 23 presentity. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 7, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Dynamic Elements . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Angular Measures and Coordinate Reference Systems . . . . 6 68 4. Dynamic Feature XML Schema . . . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Dynamic Feature Extensions Namespace Registration . . . . 9 72 6.2. Dynamic Feature Extensions Schema Registration . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Earth Centered, Earth Fixed Direction Vectors . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The Presence Information Data Format - Location Object (PIDF-LO) (see 83 RFC 4119 [RFC4119]) provides geographical location of a presentity. 84 This corresponds to a physical location at a given instance of time. 85 With the extensions defined in [RFC5491] more guidelines to 86 implementers are being provided with respect to the expression 87 location information in PIDF-LO. 89 The addition of rate of change information to the PIDF-LO enables a 90 range of use cases. These use cases either directly use dynamic 91 information, or use that information for smoother tracking of a 92 position over time. For example, an application that continuously 93 tracks a presentity could use velocity information to extrapolate 94 positions in between times location information is measured. A 95 shipping company could directly use speed to monitor delivery truck 96 speed to ensure speed limits are observed. 98 2. Terminology 100 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 102 and "OPTIONAL" are to be interpreted as described in RFC 2119 103 [RFC2119]. 105 This document uses the term "presentity", as defined in in RFC 2778 106 [RFC2778], through the document to refer to the device subject to 107 location determination. The similarity with presence concepts and 108 the abstract location privacy architecture, as described in RFC 4079 109 [RFC4079]), lead to re-use of the Presence Information Data Format 110 (PIDF), see RFC 3863 [RFC3863], and its enhancement for location 111 information with RFC 4119 [RFC4119]. Note that this document does 112 not differentiate between human and non-human objects and hence both 113 are in scope. 115 3. Dynamic Elements 117 This document defines a new element, , for the conveyance of 118 dynamic information. 120 Dynamic information MAY be included without any other location 121 information being present. When dynamic information is associated 122 with information about the instantaneous position of the presentity, 123 the element MUST be included in the same 124 element as the corresponding geodetic (or civic) location 125 information. 127 Dynamic information can be safely ignored by a recipient that does 128 not support this specification. 130 The element contains the following components: 131 orientation: 133 The element describes the spatial orientation of the 134 presentity; the direction that the object is pointing. For a 135 device, this orientation might depend on the type of device. See 136 Section 3.1 for details. 138 speed: 140 Speed is the time rate of change in position of a presentity 141 without regard for direction; the scalar component of velocity. 142 The value for the element is a measure that is defined in 143 meters per second. 145 heading: 147 Heading is directional component of velocity. See Section 3.1 for 148 details. 150 acceleration: 152 Acceleration is the time rate of change of velocity. This element 153 contains the scalar component of velocity, measured in meters per 154 second per second. 156 Each element can be omitted if no information is available. In the 157 following example the presentity is approximately oriented to the 158 North at a slightly elevated angle. The presentity is travelling 24 159 meters per second to the West: 161 162 169 170 171 172 173 -3 12 174 24 175 278 176 177 178 179 gps 180 181 2009-06-22T20:57:29Z 182 mac:1234567890ab 183 184 185 Another example shows a PIDF-LO document of the presentity 186 alice@example.com on a bike traveling 12 meters per second and with 187 an acceleration of 2 meters per second. Her position is indicated as 188 a circle. The values for speed and acceleration might be used by a 189 receiver to adjust the uncertainty over time. 191 192 200 201 202 203 204 42.5463 -73.2512 205 206 100 207 208 209 210 12 211 2 212 213 214 215 gps 216 217 2009-06-22T20:57:29Z 218 mac:1234567890ab 219 220 222 3.1. Angular Measures and Coordinate Reference Systems 224 [RFC5491] constrains the coordinate reference system (CRS) used in 225 PIDF-LO to World Geodetic System 1984 (WGS 84) using either the two- 226 dimensional (latitude, longitude) CRS identified by 227 "urn:ogc:def:crs:EPSG::4326" or the three-dimensional (latitude, 228 longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979". 229 Dynamic locations similarly assume that either of these coordinate 230 reference systems are used. 232 The and elements both describe a direction. 234 The element describes the "direction of facing"; the 235 element describes the "direction of travel". Both measures 236 contain one or two angular values that are expressed relative to the 237 current position of the presentity (see Appendix A). Angular 238 measures are expressed in degrees and values can be negative. If two 239 measures are present, the values MUST be separated by whitespace. 241 The first measure specifies the horizontal direction from the current 242 position of the presentity to a point that it is pointing towards 243 (for ) or travelling towards (for ). 244 Horizontal angles are measured from Northing to Easting. Horizontal 245 angles start from zero when pointing to or travelling towards the 246 North and increase towards the East. 248 The second measure, if present, specifies the vertical component of 249 this angle. This angle is the elevation from the local horizontal 250 plane. If the second angle value is omitted, the vertical component 251 is unknown. If only one angle is present, describes 252 only the horizontal component. For , the associated 253 measure contains only the horizontal component of speed. 255 4. Dynamic Feature XML Schema 257 258 265 267 268 269 270 271 273 275 277 279 281 282 283 284 285 287 288 289 290 291 292 294 295 296 298 300 5. Security Considerations 302 This document defines additional location elements carried by 303 PIDF-LO. These additional elements provide greater reason to observe 304 the privacy and security considerations described in RFC 4119 305 [RFC4119]. 307 RFC 4119 points back to RFC 3694 [RFC3694] and RFC 3693 [RFC3693] to 308 describe the threat model and the security requirements imposed on 309 the GEOPRIV architecture for sharing location information as result 310 of the threat model. It is important to note that these two 311 documents often refer to threats related to the current location 312 information of a presentity, while this document introduces dynamic 313 information that may be used by attackers to anticipate the future 314 location of a presentity. While already a series of location 315 snapshots is likely to offer information for guessing the future 316 location of a presentity it has to be said that including more 317 information in a PIDF-LO does increase the severity of an information 318 leak. Those who deploy location based services are in general 319 strongly advised to provide their users with ways to control the 320 distribution of location information to those who have been 321 authorized to see it. 323 6. IANA Considerations 325 This section registers a new XML namespace (as described in 326 [RFC3688]) and a new XML schema. 328 6.1. Dynamic Feature Extensions Namespace Registration 330 URI: urn:ietf:params:xml:ns:pidf:dynamic" 332 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 333 (hannes.tschofenig@gmx.net). 335 XML: 337 BEGIN 338 339 341 342 343 Dynamic Feature Extensions Namespace 344 345 346

Namespace for Dynamic Feature Extensions to PIDF-LO

347

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

348

See RFCXXXX 349 [NOTE TO IANA/RFC-EDITOR: 350 Please replace XXXX with the RFC number of this 351 specification.].

352 353 354 END 356 6.2. Dynamic Feature Extensions Schema Registration 358 URI: urn:ietf:params:xml:schema:pidf:dynamic 360 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 361 (hannes.tschofenig@gmx.net) 363 XML: The XML schema to be registered is contained in Section 4. Its 364 first line is 366 368 and its last line is 370 372 7. Acknowledgements 374 We would like to thank Klaus Darilion, Cullen Jennings, Rohan Mahy, 375 Carl Reed, and Brian Rosen for their comments. Furthermore, we would 376 like to thank Alexey Melnikov, Adrian Farrel, Tim Polk, Dan Romascanu 377 for his IESG review comments, Avshalom Houri for his Gen Art review, 378 Hilarie Orman for her SECDIR review, and Joel Jaeggli for his 379 Operations Directorate review. 381 8. References 382 8.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 388 January 2004. 390 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 391 Format", RFC 4119, December 2005. 393 8.2. Informative References 395 [GeoShape] 396 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 397 Application Schema for use by the Internet Engineering 398 Task Force (IETF)", Candidate OpenGIS Implementation 399 Specification 06-142, Version: 0.0.9, December 2006. 401 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 402 Presence and Instant Messaging", RFC 2778, February 2000. 404 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 405 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 407 [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, 408 "Threat Analysis of the Geopriv Protocol", RFC 3694, 409 February 2004. 411 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 412 W., and J. Peterson, "Presence Information Data Format 413 (PIDF)", RFC 3863, August 2004. 415 [RFC4079] Peterson, J., "A Presence Architecture for the 416 Distribution of GEOPRIV Location Objects", RFC 4079, 417 July 2005. 419 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 420 Presence Information Data Format Location Object (PIDF-LO) 421 Usage Clarification, Considerations, and Recommendations", 422 RFC 5491, March 2009. 424 Appendix A. Earth Centered, Earth Fixed Direction Vectors 426 The absolute orientation or heading of a presentity depends on its 427 latitude and longitude. The following vectors can be used to 428 determine the absolute direction in the WGS 84 Earth Centered, Earth 429 Fixed (X, Y, Z) coordinate space. 431 The direction of North as a unit vector in ECEF coordinates is: 433 North = [ -1 * sin(latitude) * cos(longitude), 434 -1 * sin(latitude) * sin(longitude), 435 cos(latitude) ] 437 The direction of "up" (the upward normal of the horizontal plane) as 438 a unit vector in ECEF coordinates is: 440 Up = [ cos(latitude) * cos(longitude), 441 cos(latitude) * sin(longitude), 442 sin(latitude) ] 444 Authors' Addresses 446 Henning Schulzrinne 447 Columbia University 448 Department of Computer Science 449 450 Computer Science Building, New York, NY 10027 450 US 452 Phone: +1 212 939 7004 453 Email: hgs@cs.columbia.edu 454 URI: http://www.cs.columbia.edu/ 456 Vishal Singh 457 Columbia University 458 Department of Computer Science 459 450 Computer Science Building, New York, NY 10027 460 US 462 Email: vs2140@cs.columbia.edu 463 URI: http://www.cs.columbia.edu/~vs2140 464 Hannes Tschofenig 465 Nokia Siemens Networks 466 Linnoitustie 6 467 Espoo 02600 468 Finland 470 Phone: +358 (50) 4871445 471 Email: Hannes.Tschofenig@gmx.net 472 URI: http://www.tschofenig.priv.at/ 474 Martin Thomson 475 Andrew Corporation 476 Wollongong 477 NSW Australia 479 Email: martin.thomson@andrew.com