idnits 2.17.1 draft-singh-geopriv-pidf-lo-dynamic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 593. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (August 2006) is 6457 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '8' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 432, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 436, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 441, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '6') (Obsoleted by RFC 6225) == Outdated reference: A later version (-03) exists of draft-thomson-geopriv-geo-shape-02 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-00 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-04 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-08 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Singh 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia U. 5 Expires: February 2, 2007 H. Tschofenig 6 Siemens 7 August 2006 9 Dynamic Feature Extensions to the Presence Information Data Format 10 Location Object (PIDF-LO) 11 draft-singh-geopriv-pidf-lo-dynamic-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 2, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The Geopriv Location Object introduced by the Presence Information 45 Data Format Location Object (PIDF-LO), RFC 4119, defines a basic XML 46 format for carrying geographical information of a presentity. This 47 document extends the element specified in RFC 4119 to 48 carry temporal feature elements useful for tracking moving objects. 50 It defines four elements, namely speed, bearing, acceleration, and 51 elevation. The document also specifies mechanism to carry multiple 52 moving object's status elements and proposes mechanism to indicate 53 the type of the PIDF-LO content. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Indicating Use of Dynamic Feature PIDF-LO . . . . . . . . 5 61 3.2. Units of Measure . . . . . . . . . . . . . . . . . . . . . 5 62 4. Transferring Multiple Location Objects . . . . . . . . . . . . 5 63 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Intellectual Property and Copyright Statements . . . . . . . . . . 14 75 1. Introduction 77 The existing Geopriv location object [5] gives presence information 78 which is geographical location of the presentity. This corresponds 79 to a physical location at a given instance of time. A large number 80 of applications, specifically in the transportation industry, fleet 81 management applications, goods delivery and postal companies require 82 to track not only the geographical location but also the rate of 83 change of location of the entities. 85 Some of the use case scenarios for such an extension are tracking the 86 location of vehicles, monitoring if vehicles are deviating from their 87 planned routes or pre-specified speed-limits, reporting the direction 88 of movement of ships and airplanes at different instances of time, 89 tracking kidnapped/trapped victims for emergency services and 90 tracking of culprits by the police. The applications may be for 91 safety and security of personals and vehicles, productivity 92 management of mobile crews, monitoring to ensure schedules, 93 monitoring to ensure no deviation from scheduled paths. 95 This document defines location vector by extending the the 96 introduced by the Presence Information Data Format Location Object 97 (PIDF-LO), RFC 4119, to carry temporal feature elements. It defines 98 four elements, namely 'speed', 'bearing', 'acceleration', and 99 'elevation'. The description of these elements is taken from GML [1] 100 and repeated for completeness reasons: 102 speed: 104 This element points to a measure of the rate of motion. It 105 contains a 'uom' (Units Of Measure) attribute, which is a 106 reference to a reference system for the amount, often a ratio or 107 interval scale. The 'uom' attribute uses a URI to refer to a unit 108 of measure definition. The GML document defines a set of 109 convenience measure types described in ISO 19103. This is further 110 explained in section 3.2. 112 bearing: 114 The element is of type gml:DirectionPropertyType and can 115 contain a gml:DirectionVector, gml:CompassPoint, DirectionKeyword, 116 or a DirectionString element. gml:Directorvectors are specified by 117 providing components of a vector or two angles. A compass point 118 is specified by a simple enumeration string type (e.g., "N", 119 "NNE", "NE", ... "W"). Two elements to contain text-based 120 descriptions of direction are provided. If the direction is 121 specified using a term from a list, gml:KeyWord may be used, and 122 the list indicated using the value of the codeSpace attribute. If 123 the direction is described in prose, gml:DirectionString may be 124 used, allowing the value to be included inline or by reference. 126 acceleration: 128 This element specifies the rate (usually rapid) at which something 129 happens. Similarly to the and the element the 130 element conains a 'uom' (Units Of Measure) 131 attribute, which is a reference to a reference system for the 132 amount. 134 elevation: The height of a thing above a reference level; altitude. 135 Similarly to the and the element the 136 element contains a 'uom' (Units Of Measure) 137 attribute, which is a reference to a reference system for the 138 amount. The ability to use the 'elevation' element together with 139 geospatial location offers a more compact way of expressing 140 composite location information per RFC 3825 [6] location 141 information using a civic floor number. 143 This document therefore allows the existing location formats allowed 144 by the GML feature.xsd schema to be extended with dynamic 145 characteristics. The supported shapes are described in detail in 146 [7]. This document enhances this functionality and offers support 147 for moving objects. 149 2. Terminology 151 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 152 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 153 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 155 This document uses the terminology from [3]. 157 3. Protocol Behavior 159 The document describes the protocol requirements for dynamic feature 160 extensions, so that it can be transmitted by the location server and 161 understood correctly by the clients. The clients should be able to 162 indicate to the server that they can handle the dynamic feature 163 elements. The server should also indicate to the clients that the 164 type of location object is PIDF-LO + dynamic feature extensions. 165 Also, the unit of measurements should be communicated by server and 166 understood by the clients. 168 3.1. Indicating Use of Dynamic Feature PIDF-LO 170 The watcher can can indicate its capability using the SIP Accept 171 header. This document proposes to add a 'supported' parameter for 172 the application/pidf-xml media type. It enumerates the non default 173 namespaces supported by the UAS. An example is given below: 175 Accept: application/pidf+xml; 176 supported="urn:ietf:params:xml:ns:temporal1" 178 Alternatively, a token can be defined and used, an example is given: 180 Accept: application/pidf+xml; supported="geopriv-temporal-features" 182 The server can specify the type of content using Content-Type header. 183 The specific PIDF-LO type can be obtained by looking inside the XML 184 content. 186 Content-Type: application/pidf+xml; 188 3.2. Units of Measure 190 GML permits a range of units of measure for all parameters. This 191 document restricts this set to the following units: #m/s, #km/h and 192 #mph 194 Editor's Note: Need to find the URN for kph, m/s, km/h need to be 195 added here. Editor's Note: Need to find the URN for floor, if it 196 exists. It is only valid for the elevation element. 198 Only the above-listed units of measurements MUST be used for the uom 199 attribute. 201 4. Transferring Multiple Location Objects 203 Multiple location vector objects may be required to be transported 204 simultaneously. This can be achieved using defined 205 in RFC 4481 [4]. 207 Typically, the watcher applications can reconstruct the path as well 208 as dynamic behavior (speed, acceleration etc.) along the path by 209 storing the received location vector objects. However, a new watcher 210 may be interested in past location-vectors or may choose to receive 211 notifications at a slower rate without losing valuable information. 212 In other words, it can request to receive multiple location vector 213 objects together. For example, it may want to get one NOTIFY every 214 15 minutes with multiple location objects aggregated. 216 The structure of the document which can be used for tracking moving 217 objects using timed-status extension is shown below. An example is 218 given in section 6. 220 221 222 223 .......... 224 225 226 ..... 228 229 230 ............ 231 233 234 ........... 235 237 239 241 242 ....... 243 245 5. XML Schema 247 This section defines the XML schema consisting of four elements that 248 are conveyed inside the element defined by RFC 4119 249 [5]. The data types are taken from GML. 251 252 260 263 264 265 266 268 270 Figure 2: XML Schema 272 6. Example 274 The following example shows a PIDF-LO indicating geospatial location 275 information using the gml:Point structure. Outside the element the additional fields releated to temporal 277 characteristics are included. 279 280 285 286 287 288 289 290 291 -34.407 150.883 292 293 294 12 295 296 SE 297 298 299 300 no 301 2003-06-23T04:57:29Z 302 303 304 305 306 2003-06-22T20:57:29Z 307 308 310 Figure 3: Example of a PIDF-LO with Speed Information 312 The following example shows multiple PIDF-LO using . 314 315 320 321 322 323 324 325 326 140. -35. 327 328 329 12. 330 331 332 no 333 2003-06-23T04:57:29Z 334 335 336 337 338 2003-06-22T20:57:29Z 340 > 342 343 344 345 346 110. -35. 347 348 349 10 350 351 352 yes 353 2003-06-23T04:55:29Z 354 355 356 357 358 359 360 361 114. -35. 362 363 364 18. 365 366 367 yes 368 2003-06-23T04:53:29Z 369 370 371 372 374 375 377 Figure 4: Example showing multiple Location Vectors transmitted 378 simultaneously. 380 7. Security Considerations 382 This document defines additional location elements carried by PIDF-LO 383 (see [5]). The security considerations of RFC 4119 [5] are 384 applicable to this document. 386 8. IANA Considerations 388 A future version of this document will provide IANA considerations. 390 9. Acknowledgements 392 Add your name here. 394 10. References 396 10.1. Normative References 398 [1] "Geographic information - Geography Markup Language (GML), 399 OpenGIS 03-105r1, available at: 400 http://portal.opengeospatial.org/files/?artifact_id=4700", 401 April 2004. 403 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 404 Levels", RFC 2119, BCP 14, March 1997. 406 [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 407 Polk, "Geopriv Requirements", RFC 3693, February 2004. 409 [4] Schulzrinne, H., "Timed Presence Extensions to the Presence 410 Information Data Format (PIDF) to Indicate Status Information 411 for Past and Future Time Intervals", RFC 4481, July 2006. 413 [5] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 414 RFC 4119, December 2005. 416 10.2. Informative References 418 [6] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 419 Configuration Protocol Option for Coordinate-based Location 420 Configuration Information", RFC 3825, July 2004. 422 [7] Thomson, M., "Geodetic Shapes for the Representation of 423 Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-02 424 (work in progress), May 2006. 426 [8] Mahy, R., "A Document Format for Filtering and Reporting 427 Location Notications in the Presence Information Document 428 Format Location Object (PIDF-LO)", 429 draft-ietf-geopriv-loc-filters-00 (work in progress), 430 March 2006. 432 [9] Polk, J. and B. Rosen, "Session Initiation Protocol Location 433 Conveyance", draft-ietf-sip-location-conveyance-04 (work in 434 progress), August 2006. 436 [10] Schulzrinne, H., "Common Policy: A Document Format for 437 Expressing Privacy Preferences", 438 draft-ietf-geopriv-common-policy-11 (work in progress), 439 August 2006. 441 [11] Schulzrinne, H., "A Document Format for Expressing Privacy 442 Preferences for Location Information", 443 draft-ietf-geopriv-policy-08 (work in progress), February 2006. 445 Appendix A. Alternatives Considered 447 During the work on this document we encountered alternative 448 approaches. These approaches make use of the MovingObjectStatus or 449 its parent element track of dynamicFeature.xsd. MovingObjectStatus 450 contains child elements where no use cases are currently known, e.g., 451 validTime and contains elements that are already defined with 452 PIDF-LO, such as . Since it might not be know whether a 453 Location Recipient understands the location extension defined in this 454 document a PIDF-LO with a element inside the 455 will likely create problems. Including the 456 element twice, once as defined with RFC 4119 (PIDF-LO) and 457 again in , is unnecessary. The element 458 allows multiple to be used. Figure 5 shows such 459 an instance document carrying the element. 461 462 466 467 468 469 470 471 472 473 474 2005-11-28T13:00:00 475 476 477 478 479 480 140. -35. 481 482 483 12 484 485 SE 486 487 488 489 490 491 2005-11-28T14:00:00 492 493 494 495 496 497 140.1 -34.9 498 499 500 23. 501 502 ESE 503 504 505 506 507 508 no 509 2003-06-23T04:57:29Z 510 511 512 513 514 2003-06-22T20:57:29Z 515 516 518 Figure 5: Example of a PIDF-LO with a track Element 520 The authors decided to pick the simplest version. 522 Authors' Addresses 524 Singh Vishal 525 Columbia University 526 Department of Computer Science 527 450 Computer Science Building 528 New York, NY 10027 529 US 531 Email: vs2140@cs.columbia.edu 532 URI: http://www.cs.columbia.edu/~vs2140 534 Henning Schulzrinne 535 Columbia University 536 Department of Computer Science 537 450 Computer Science Building 538 New York, NY 10027 539 US 541 Phone: +1 212 939 7004 542 Email: hgs+ecrit@cs.columbia.edu 543 URI: http://www.cs.columbia.edu/~hgs 545 Hannes Tschofenig 546 Siemens 547 Otto-Hahn-Ring 6 548 Munich, Bavaria 81739 549 Germany 551 Phone: +49 89 636 40390 552 Email: Hannes.Tschofenig@siemens.com 553 URI: http://www.tschofenig.com 555 Full Copyright Statement 557 Copyright (C) The Internet Society (2006). 559 This document is subject to the rights, licenses and restrictions 560 contained in BCP 78, and except as set forth therein, the authors 561 retain all their rights. 563 This document and the information contained herein are provided on an 564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 566 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 567 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 568 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 571 Intellectual Property 573 The IETF takes no position regarding the validity or scope of any 574 Intellectual Property Rights or other rights that might be claimed to 575 pertain to the implementation or use of the technology described in 576 this document or the extent to which any license under such rights 577 might or might not be available; nor does it represent that it has 578 made any independent effort to identify any such rights. Information 579 on the procedures with respect to rights in RFC documents can be 580 found in BCP 78 and BCP 79. 582 Copies of IPR disclosures made to the IETF Secretariat and any 583 assurances of licenses to be made available, or the result of an 584 attempt made to obtain a general license or permission for the use of 585 such proprietary rights by implementers or users of this 586 specification can be obtained from the IETF on-line IPR repository at 587 http://www.ietf.org/ipr. 589 The IETF invites any interested party to bring to its attention any 590 copyrights, patents or patent applications, or other proprietary 591 rights that may cover technology that may be required to implement 592 this standard. Please address the information to the IETF at 593 ietf-ipr@ietf.org. 595 Acknowledgment 597 Funding for the RFC Editor function is provided by the IETF 598 Administrative Support Activity (IASA).