idnits 2.17.00 (12 Aug 2021) /tmp/idnits17544/draft-singh-geopriv-pidf-lo-dynamic-09.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 26, 2010) is 4432 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 383, 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 27, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 M. Thomson 8 Andrew Corporation 9 March 26, 2010 11 Dynamic Extensions to the Presence Information Data Format Location 12 Object (PIDF-LO) 13 draft-singh-geopriv-pidf-lo-dynamic-09 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, and heading of the presentity. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 27, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Dynamic Elements . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Angular Measures and Coordinate Reference Systems . . . . 6 67 4. Dynamic Feature XML Schema . . . . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. Dynamic Feature Extensions Namespace Registration . . . . 9 71 6.2. Dynamic Feature Extensions Schema Registration . . . . . . 10 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Appendix A. Earth Centered, Earth Fixed Direction Vectors . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The Presence Information Data Format - Location Object (PIDF-LO) (see 82 RFC 4119 [RFC4119]) provides geographical location of a presentity. 83 This corresponds to a physical location at a given instance of time. 84 With the extensions defined in [RFC5491] more guidelines to 85 implementers are being provided with respect to the expression 86 location information in PIDF-LO. 88 The addition of rate of change information to the PIDF-LO enables a 89 range of use cases. These use cases either directly use dynamic 90 information, or use that information for smoother tracking of a 91 position over time. For example, an application that continuously 92 tracks a presentity could use velocity information to extrapolate 93 positions in between times location information is measured. A 94 shipping company could directly use speed to monitor delivery truck 95 speed to ensure speed limits are observed. 97 2. Terminology 99 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 100 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 101 and "OPTIONAL" are to be interpreted as described in RFC 2119 102 [RFC2119]. 104 This document uses the term "presentity", as defined in in RFC 2778 105 [RFC2778], through the document to refer to the device subject to 106 location determination. The similarity with presence concepts and 107 the abstract location privacy architecture, as described in RFC 4079 108 [RFC4079]), lead to re-use of the Presence Information Data Format 109 (PIDF), see RFC 3863 [RFC3863], and its enhancement for location 110 information with RFC 4119 [RFC4119]. Note that this document does 111 not differentiate between human and non-human objects and hence both 112 are in scope. 114 3. Dynamic Elements 116 This document defines a new element, , for the conveyance of 117 dynamic information. 119 Dynamic information MAY be included without any other location 120 information being present. When dynamic information is associated 121 with information about the instantaneous position of the presentity, 122 the element MUST be included in the same 123 element as the corresponding geodetic (or civic) location 124 information. 126 Dynamic information can be safely ignored by a recipient that does 127 not support this specification. 129 The element contains the following components: 130 orientation: 132 The element describes the spatial orientation of the 133 presentity; the direction that the object is pointing. For a 134 device, this orientation might depend on the type of device. See 135 Section 3.1 for details. 137 speed: 139 Speed is the time rate of change in position of a presentity 140 without regard for direction; the scalar component of velocity. 141 The value for the element is a measure that is defined in 142 meters per second. 144 heading: 146 Heading is directional component of velocity. See Section 3.1 for 147 details. 149 Each element can be omitted if no information is available. In the 150 following example the presentity is approximately oriented to the 151 North at a slightly elevated angle. The presentity is travelling 24 152 meters per second to the West: 154 155 162 163 164 165 166 -3 12 167 24 168 278 169 170 171 172 gps 173 174 2009-06-22T20:57:29Z 175 mac:1234567890ab 176 177 178 Another example shows a PIDF-LO document of the presentity 179 alice@example.com on a bike traveling 12 meters per second. Her 180 position is indicated as a circle. The values for speed may be used 181 by a receiver to adjust the uncertainty over time. 183 184 192 193 194 195 196 42.5463 -73.2512 197 198 100 199 200 201 202 12 203 204 205 206 gps 207 208 2009-06-22T20:57:29Z 209 mac:1234567890ab 210 211 213 3.1. Angular Measures and Coordinate Reference Systems 215 [RFC5491] constrains the coordinate reference system (CRS) used in 216 PIDF-LO to World Geodetic System 1984 (WGS 84) using either the two- 217 dimensional (latitude, longitude) CRS identified by 218 "urn:ogc:def:crs:EPSG::4326" or the three-dimensional (latitude, 219 longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979". 220 Dynamic locations similarly assume that either of these coordinate 221 reference systems are used. 223 The and elements both describe a direction. 224 The element describes the "direction of facing"; the 225 element describes the "direction of travel". Both measures 226 contain one or two angular values that are expressed relative to the 227 current position of the presentity (see Appendix A). Angular 228 measures are expressed in degrees and values can be negative. If two 229 measures are present, the values MUST be separated by whitespace. 231 The first measure specifies the horizontal direction from the current 232 position of the presentity to a point that it is pointing towards 233 (for ) or travelling towards (for ). 234 Horizontal angles are measured from Northing to Easting. Horizontal 235 angles start from zero when pointing to or travelling towards the 236 North and increase towards the East. 238 The second measure, if present, specifies the vertical component of 239 this angle. This angle is the elevation from the local horizontal 240 plane. If the second angle value is omitted, the vertical component 241 is unknown. If only one angle is present, describes 242 only the horizontal component. For , the associated 243 measure contains only the horizontal component of speed. 245 4. Dynamic Feature XML Schema 247 248 255 257 258 259 260 261 263 265 267 269 270 271 272 273 275 276 277 278 279 280 282 283 284 286 288 5. Security Considerations 290 This document defines additional location elements carried by 291 PIDF-LO. These additional elements provide greater reason to observe 292 the privacy and security considerations described in RFC 4119 293 [RFC4119]. No further privacy or security measures are necessary. 295 RFC 4119 points back to RFC 3694 [RFC3694] and RFC 3693 [RFC3693] to 296 describe the threat model and the security requirements imposed on 297 the GEOPRIV architecture for sharing location information as result 298 of the threat model. It is important to note that these two 299 documents often refer to threats related to the current location 300 information of a presentity, while this document introduces dynamic 301 information that may be used by attackers to anticipate the future 302 location of a presentity. While already a series of location 303 snapshots is likely to offer information for guessing the future 304 location of a presentity it has to be said that including more 305 information in a PIDF-LO does increase the severity of an information 306 leak. Those who deploy location based services are in general 307 strongly advised to provide their users with ways to control the 308 distribution of location information to those who have been 309 authorized to see it. 311 6. IANA Considerations 313 This section registers a new XML namespace (as described in 314 [RFC3688]) and a new XML schema. 316 6.1. Dynamic Feature Extensions Namespace Registration 318 URI: urn:ietf:params:xml:ns:pidf:dynamic" 320 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 321 (hannes.tschofenig@gmx.net). 323 XML: 325 BEGIN 326 327 329 330 331 Dynamic Feature Extensions Namespace 332 333 334

Namespace for Dynamic Feature Extensions to PIDF-LO

335

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

336

See RFCXXXX 337 [NOTE TO IANA/RFC-EDITOR: 338 Please replace XXXX with the RFC number of this 339 specification.].

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