idnits 2.17.1 draft-singh-geopriv-pidf-lo-dynamic-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. 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 Copyright Line does not match the current year -- 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 (November 19, 2007) is 5975 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: '5' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 401, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-held-context-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Singh 3 Internet-Draft 4 Intended status: Standards Track H. Schulzrinne 5 Expires: May 22, 2008 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 November 19, 2007 10 Dynamic Feature Extensions to the Presence Information Data Format 11 Location Object (PIDF-LO) 12 draft-singh-geopriv-pidf-lo-dynamic-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 22, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Geopriv Location Object introduced by the Presence Information 46 Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic 47 XML format for carrying geographical information of a presentity. 48 This document extends the element specified in RFC 4119 to 49 carry temporal feature elements useful for tracking moving objects. 50 It defines five elements, namely speed, bearing, acceleration 51 elevation and directionOfObject. The document also specifies 52 mechanisms to carry multiple moving object's status elements and 53 proposes a mechanism to indicate 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 using SIP . . . 4 61 3.2. Indicating Use of Dynamic Feature PIDF-LO using HELD . . . 4 62 3.3. Units of Measure . . . . . . . . . . . . . . . . . . . . . 5 63 3.4. GML DynamicFeature Schema Usage . . . . . . . . . . . . . 5 64 4. Transferring Multiple Location Objects . . . . . . . . . . . . 5 65 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Introduction 78 The Presence Information Data Format - Location Object (PIDF-LO) (see 79 RFC 4119 [1]) provides geographical location of the presentity. This 80 corresponds to a physical location at a given instance of time. 81 However, a number of applications, described below, can benefit from 82 having access to information about changes in location. Location 83 change information is likely to be useful for logistics and public 84 safety. For example, shipping companies or dispatch centers can use 85 it to track whether vehicles are deviating from an established path 86 or exceeding speed limits. 88 This document defines a location vector by extending the the 89 , introduced by RFC 4119, to carry temporal feature 90 elements: 92 speed: 94 Speed is the rate of motion. (The terms speed and velocity are 95 often used interchangeably, but speed is a scaler, having 96 magnitude only, while velocity is a vector quantity, having both 97 magnitude and direction.) 99 This element contains a 'uom' (Units Of Measure) attribute, which 100 is a reference to a reference system for the amount. The 'uom' 101 attribute uses a URI to refer to a unit of measure definition. 102 The GML document defines a set of convenience measure types 103 described in ISO 19103. This is further explained in Section 3.3. 105 bearing: 107 Bearing is defined as the horizontal direction of one terrestrial 108 point from another, expressed as the angular distance from a 109 reference direction. It is usually measured from 000 degrees at 110 the reference direction clockwise through 360 degrees. 112 The element is of type gml:DirectionPropertyType and 113 contains a gml:DirectionVector, gml:CompassPoint, 114 DirectionKeyword, or a DirectionString element. This document 115 profiles the usage of this GML element and suggests the usage of 116 the element. 118 acceleration: 120 This element specifies the rate (usually rapid) at which something 121 happens. The element also contains a 'uom' 122 attribute. 124 directionOfObject: 126 The describes the instantaneous horizontal of 127 the front of the object relative to true north and the vertical 128 angle relative to the earth's spheroid. It uses the GML 129 element. 131 2. Terminology 133 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 134 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 135 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 137 This document uses the terminology from [3]. 139 3. Protocol Behavior 141 The document describes the protocol requirements for dynamic feature 142 extensions, so that it can be transmitted by the Location Server or 143 the Location Information Server and understood correctly by Location 144 Recipients. Location Recipients should be able to indicate to the 145 server that they can handle the dynamic feature elements. The server 146 should also indicate to the clients that the type of location object 147 is PIDF-LO including the dynamic feature extension. Also, the unit 148 of measurements should be communicated by server and understood by 149 the clients. 151 3.1. Indicating Use of Dynamic Feature PIDF-LO using SIP 153 The watcher can can indicate its capability using the SIP Accept 154 header. This document proposes to add a 'supported' parameter for 155 the application/pidf-xml media type. It enumerates the non default 156 namespaces supported by the UAS. An example is given below: 158 Accept: application/pidf+xml; supported="geopriv-temporal-features" 160 The server can specify the type of content using Content-Type header. 161 The specific PIDF-LO type can be obtained by looking inside the XML 162 content. 164 Content-Type: application/pidf+xml; 166 3.2. Indicating Use of Dynamic Feature PIDF-LO using HELD 168 There are two areas where it is useful to provide feature indication; 169 the HELD context draft [6]" allows a Target (or an entity acting on 170 behalf of the Target) to constraint the dereferencing procedure. 171 Hence, it is useful to indicate whether dynamic features should or 172 should not presented to the Location Recipient when a location URI is 173 dereferenced. 175 Furthermore, when a dereferencing protocol based on HTTP is used then 176 the Location Recipient might want to express the desire to receive a 177 specific response, for example a PIDF-LO that contains a trace. 179 In a future version of this document the above-described 180 functionality will be added. 182 3.3. Units of Measure 184 GML permits a range of units of measure for the uom attribute. This 185 document restricts this set to the #m/s 187 [ Editor's Note: Need to find the URN for #m/s] 189 3.4. GML DynamicFeature Schema Usage 191 This document does not define a new schema but instead re-uses a 192 subset of the dynamicFeature.xsd schema available with GML 3.1.1, 193 namely , , , and . 195 These four elements are conveyed inside the element 196 defined by RFC 4119 [1]. 198 4. Transferring Multiple Location Objects 200 Multiple location vector objects may be required to be transported 201 simultaneously. This can be achieved using defined 202 in RFC 4481 [4]. 204 Typically, the watcher applications can reconstruct the path as well 205 as dynamic behavior (speed, acceleration etc.) along the path by 206 storing the received location vector objects. However, a new 207 Location Recipient may be interested in past location-vectors or may 208 choose to receive notifications at a slower rate without losing 209 valuable information. In other words, it can request to receive 210 multiple location vector objects together. For example, it may want 211 to get one NOTIFY every 15 minutes with multiple location objects 212 aggregated. 214 The structure of the document which can be used for tracking moving 215 objects using timed-status extension is shown below. An example is 216 given in Section 5. 218 219 220 221 222 223 .......... 224 225 227 ..... 229 230 231 ............ 232 234 235 ........... 236 238 239 241 242 ....... 243 245 246 ....... 247 248 250 5. Example 252 The following example shows a PIDF-LO indicating geospatial location 253 information using the gml:Point structure. Outside the element the additional fields releated to temporal 255 characteristics are included. 257 258 263 264 265 266 267 268 269 -34.407 150.883 270 271 272 12 273 274 275 270.0 -60.0 276 277 278 279 280 no 281 2003-06-23T04:57:29Z 282 283 284 285 286 2008-06-22T20:57:29Z 287 289 291 Figure 2: Example of a PIDF-LO with Speed Information 293 The following example shows multiple PIDF-LO using . 295 296 300 301 302 303 304 305 306 140. -35. 307 308 309 12 310 311 312 no 313 2003-06-23T04:57:29Z 314 315 316 317 318 2003-06-22T20:57:29Z 320 > 322 323 324 325 326 110. -35. 327 328 329 10 330 331 332 yes 333 2003-06-23T04:55:29Z 334 335 336 337 338 339 340 341 114. -35. 342 343 344 18 345 346 347 yes 348 2003-06-23T04:53:29Z 349 350 351 353 355 356 358 Figure 3: Example showing multiple Location Vectors transmitted 359 simultaneously. 361 6. Security Considerations 363 This document defines additional location elements carried by PIDF-LO 364 (see [1]). The security considerations of RFC 4119 [1] are 365 applicable to this document. 367 7. IANA Considerations 369 This section needs to register a token for indicating the dynamic 370 feature capability, see Section 3.1. 372 8. Acknowledgements 374 We would like to thank Carl Reed, Rohan Mahy, Cullen Jennings, Martin 375 Thomson, Brian Rosen, and Klaus Darilion for their comments. 377 9. References 379 9.1. Normative References 381 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 382 RFC 4119, December 2005. 384 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 385 Levels", RFC 2119, BCP 14, March 1997. 387 [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 388 Polk, "Geopriv Requirements", RFC 3693, February 2004. 390 [4] Schulzrinne, H., "Timed Presence Extensions to the Presence 391 Information Data Format (PIDF) to Indicate Status Information 392 for Past and Future Time Intervals", RFC 4481, July 2006. 394 [5] "Geographic information - Geography Markup Language (GML), 395 OpenGIS 03-105r1, available at: 396 http://portal.opengeospatial.org/files/?artifact_id=4700", 397 April 2004. 399 9.2. Informative References 401 [6] Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD Protocol 402 Context Management Extensions", 403 draft-winterbottom-geopriv-held-context-01 (work in progress), 404 October 2007. 406 Appendix A. Alternatives Considered 408 During the work on this document we encountered alternative 409 approaches. These approaches make use of the MovingObjectStatus or 410 its parent element track of dynamicFeature.xsd. MovingObjectStatus 411 contains child elements where no use cases are currently known, e.g., 412 validTime and contains elements that are already defined with 413 PIDF-LO, such as . Since it might not be know whether a 414 Location Recipient understands the location extension defined in this 415 document a PIDF-LO with a element inside the 416 will likely create problems. Including the 417 element twice, once as defined with RFC 4119 (PIDF-LO) and 418 again in , is unnecessary. The element 419 allows multiple to be used. Figure 4 shows such 420 an instance document carrying the element. 422 423 427 428 429 430 431 432 433 434 435 2005-11-28T13:00:00 436 437 438 439 440 441 140. -35. 442 444 445 12 446 447 SE 448 449 450 451 452 453 2005-11-28T14:00:00 454 455 456 457 458 459 140.1 -34.9 460 461 462 23. 463 464 ESE 465 466 467 468 469 470 no 471 2003-06-23T04:57:29Z 472 473 474 475 476 2003-06-22T20:57:29Z 477 478 480 Figure 4: Example of a PIDF-LO with a track Element 482 The authors decided to pick the simplest version. 484 Authors' Addresses 486 Singh Vishal 488 Email: singh.vishal@gmail.com 489 Henning Schulzrinne 490 Columbia University 491 Department of Computer Science 492 450 Computer Science Building, New York, NY 10027 493 US 495 Phone: +1 212 939 7004 496 Email: hgs@cs.columbia.edu 497 URI: http://www.cs.columbia.edu 499 Hannes Tschofenig 500 Nokia Siemens Networks 501 Otto-Hahn-Ring 6 502 Munich, Bavaria 81739 503 Germany 505 Email: Hannes.Tschofenig@nsn.com 506 URI: http://www.tschofenig.com 508 Full Copyright Statement 510 Copyright (C) The IETF Trust (2007). 512 This document is subject to the rights, licenses and restrictions 513 contained in BCP 78, and except as set forth therein, the authors 514 retain all their rights. 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org. 548 Acknowledgment 550 Funding for the RFC Editor function is provided by the IETF 551 Administrative Support Activity (IASA).