idnits 2.17.1 draft-singh-geopriv-pidf-lo-dynamic-03.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 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. 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 (July 12, 2008) is 5766 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 385, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 392, 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-02 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: January 13, 2009 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 July 12, 2008 10 Dynamic Feature Extensions to the Presence Information Data Format 11 Location Object (PIDF-LO) 12 draft-singh-geopriv-pidf-lo-dynamic-03.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 January 13, 2009. 39 Abstract 41 The Geopriv Location Object introduced by the Presence Information 42 Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic 43 XML format for carrying geographical information of a presentity. 44 This document extends the element specified in RFC 4119 to 45 carry temporal feature elements useful for tracking moving objects. 46 It defines five elements, namely speed, bearing, acceleration 47 elevation and directionOfObject. The document also specifies 48 mechanisms to carry multiple moving object's status elements and 49 proposes a mechanism to indicate the type of the PIDF-LO content. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Indicating Use of Dynamic Feature PIDF-LO using SIP . . . 4 57 3.2. Indicating Use of Dynamic Feature PIDF-LO using HELD . . . 4 58 3.3. Units of Measure . . . . . . . . . . . . . . . . . . . . . 5 59 3.4. GML DynamicFeature Schema Usage . . . . . . . . . . . . . 5 60 4. Transferring Multiple Location Objects . . . . . . . . . . . . 5 61 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . . . . 13 72 1. Introduction 74 The Presence Information Data Format - Location Object (PIDF-LO) (see 75 RFC 4119 [1]) provides geographical location of the presentity. This 76 corresponds to a physical location at a given instance of time. 77 However, a number of applications, described below, can benefit from 78 having access to information about changes in location. Location 79 change information is likely to be useful for logistics and public 80 safety. For example, shipping companies or dispatch centers can use 81 it to track whether vehicles are deviating from an established path 82 or exceeding speed limits. 84 This document defines a location vector by extending the the 85 , introduced by RFC 4119, to carry temporal feature 86 elements: 88 speed: 90 Speed is the rate of motion. (The terms speed and velocity are 91 often used interchangeably, but speed is a scaler, having 92 magnitude only, while velocity is a vector quantity, having both 93 magnitude and direction.) 95 This element contains a 'uom' (Units Of Measure) attribute, which 96 is a reference to a reference system for the amount. The 'uom' 97 attribute uses a URI to refer to a unit of measure definition. 98 The GML document defines a set of convenience measure types 99 described in ISO 19103. This is further explained in Section 3.3. 101 bearing: 103 Bearing is defined as the horizontal direction of one terrestrial 104 point from another, expressed as the angular distance from a 105 reference direction. It is usually measured from 000 degrees at 106 the reference direction clockwise through 360 degrees. 108 The element is of type gml:DirectionPropertyType and 109 contains a gml:DirectionVector, gml:CompassPoint, 110 DirectionKeyword, or a DirectionString element. This document 111 profiles the usage of this GML element and suggests the usage of 112 the element. 114 acceleration: 116 This element specifies the rate (usually rapid) at which something 117 happens. The element also contains a 'uom' 118 attribute. 120 directionOfObject: 122 The describes the instantaneous horizontal of 123 the front of the object relative to true north and the vertical 124 angle relative to the earth's spheroid. It uses the GML 125 element. 127 2. Terminology 129 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 130 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 131 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 133 This document uses the terminology from [3]. 135 3. Protocol Behavior 137 The document describes the protocol requirements for dynamic feature 138 extensions, so that it can be transmitted by the Location Server or 139 the Location Information Server and understood correctly by Location 140 Recipients. Location Recipients should be able to indicate to the 141 server that they can handle the dynamic feature elements. The server 142 should also indicate to the clients that the type of location object 143 is PIDF-LO including the dynamic feature extension. Also, the unit 144 of measurements should be communicated by server and understood by 145 the clients. 147 3.1. Indicating Use of Dynamic Feature PIDF-LO using SIP 149 The watcher can can indicate its capability using the SIP Accept 150 header. This document proposes to add a 'supported' parameter for 151 the application/pidf-xml media type. It enumerates the non default 152 namespaces supported by the UAS. An example is given below: 154 Accept: application/pidf+xml; supported="geopriv-temporal-features" 156 The server can specify the type of content using Content-Type header. 157 The specific PIDF-LO type can be obtained by looking inside the XML 158 content. 160 Content-Type: application/pidf+xml; 162 3.2. Indicating Use of Dynamic Feature PIDF-LO using HELD 164 There are two areas where it is useful to provide feature indication; 165 the HELD context draft [6]" allows a Target (or an entity acting on 166 behalf of the Target) to constraint the dereferencing procedure. 167 Hence, it is useful to indicate whether dynamic features should or 168 should not presented to the Location Recipient when a location URI is 169 dereferenced. 171 Furthermore, when a dereferencing protocol based on HTTP is used then 172 the Location Recipient might want to express the desire to receive a 173 specific response, for example a PIDF-LO that contains a trace. 175 In a future version of this document the above-described 176 functionality will be added. 178 3.3. Units of Measure 180 GML permits a range of units of measure for the uom attribute. This 181 document restricts this set to the #m/s 183 [ Editor's Note: Need to find the URN for #m/s] 185 3.4. GML DynamicFeature Schema Usage 187 This document does not define a new schema but instead re-uses a 188 subset of the dynamicFeature.xsd schema available with GML 3.1.1, 189 namely , , , and . 191 These four elements are conveyed inside the element 192 defined by RFC 4119 [1]. 194 4. Transferring Multiple Location Objects 196 Multiple location vector objects may be required to be transported 197 simultaneously. This can be achieved using defined 198 in RFC 4481 [4]. 200 Typically, the watcher applications can reconstruct the path as well 201 as dynamic behavior (speed, acceleration etc.) along the path by 202 storing the received location vector objects. However, a new 203 Location Recipient may be interested in past location-vectors or may 204 choose to receive notifications at a slower rate without losing 205 valuable information. In other words, it can request to receive 206 multiple location vector objects together. For example, it may want 207 to get one NOTIFY every 15 minutes with multiple location objects 208 aggregated. 210 The structure of the document which can be used for tracking moving 211 objects using timed-status extension is shown below. An example is 212 given in Section 5. 214 215 217 219 220 .......... 221 223 ..... 225 226 227 ............ 228 230 231 ........... 232 234 235 237 238 ....... 239 241 242 ....... 243 244 246 5. Example 248 The following example shows a PIDF-LO indicating geospatial location 249 information using the gml:Point structure. Outside the element the additional fields releated to temporal 251 characteristics are included. 253 254 259 260 261 262 263 264 -34.407 150.883 265 266 267 12 268 269 270 270.0 -60.0 271 272 273 274 275 no 276 2003-06-23T04:57:29Z 277 278 279 280 2008-06-22T20:57:29Z 281 283 285 Figure 1: Example of a PIDF-LO with Speed Information 287 The following example shows multiple PIDF-LO using . 289 290 294 295 296 297 298 299 140. -35. 301 302 303 12 304 305 306 no 307 2003-06-23T04:57:29Z 308 309 310 311 2003-06-22T20:57:29Z 313 > 315 316 317 318 319 110. -35. 320 321 322 10 323 324 325 yes 326 2003-06-23T04:55:29Z 327 328 329 330 331 332 333 334 114. -35. 335 336 337 18 338 339 340 yes 341 2003-06-23T04:53:29Z 342 343 344 345 347 348 349 Figure 2: Example showing multiple Location Vectors transmitted 350 simultaneously. 352 6. Security Considerations 354 This document defines additional location elements carried by PIDF-LO 355 (see [1]). The security considerations of RFC 4119 [1] are 356 applicable to this document. 358 7. IANA Considerations 360 [Editor's Note: This section needs to register a token for 361 indicating the dynamic feature capability, see Section 3.1.] 363 8. Acknowledgements 365 We would like to thank Carl Reed, Rohan Mahy, Cullen Jennings, Martin 366 Thomson, Brian Rosen, and Klaus Darilion for their comments. 368 9. References 370 9.1. Normative References 372 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 373 RFC 4119, December 2005. 375 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 376 Levels", RFC 2119, BCP 14, March 1997. 378 [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 379 Polk, "Geopriv Requirements", RFC 3693, February 2004. 381 [4] Schulzrinne, H., "Timed Presence Extensions to the Presence 382 Information Data Format (PIDF) to Indicate Status Information 383 for Past and Future Time Intervals", RFC 4481, July 2006. 385 [5] "Geographic information - Geography Markup Language (GML), 386 OpenGIS 03-105r1, available at: 387 http://portal.opengeospatial.org/files/?artifact_id=4700", 388 April 2004. 390 9.2. Informative References 392 [6] Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD Protocol 393 Context Management Extensions", 394 draft-winterbottom-geopriv-held-context-02 (work in progress), 395 February 2008. 397 Appendix A. Alternatives Considered 399 During the work on this document we encountered alternative 400 approaches. These approaches make use of the MovingObjectStatus or 401 its parent element track of dynamicFeature.xsd. MovingObjectStatus 402 contains child elements where no use cases are currently known, e.g., 403 validTime and contains elements that are already defined with 404 PIDF-LO, such as . Since it might not be know whether a 405 Location Recipient understands the location extension defined in this 406 document a PIDF-LO with a element inside the 407 will likely create problems. Including the 408 element twice, once as defined with RFC 4119 (PIDF-LO) and 409 again in , is unnecessary. The element 410 allows multiple to be used. Figure 3 shows such 411 an instance document carrying the element. 413 414 418 419 420 421 422 423 424 425 2005-11-28T13:00:00 426 427 428 429 430 431 140. -35. 432 433 434 12 435 436 SE 437 438 439 440 441 442 2005-11-28T14:00:00 443 444 445 446 447 448 140.1 -34.9 449 450 451 23. 452 453 ESE 454 455 456 457 458 459 no 460 2003-06-23T04:57:29Z 461 462 463 464 2003-06-22T20:57:29Z 465 466 468 Figure 3: Example of a PIDF-LO with a track Element 470 The authors decided to pick the simplest version. 472 Authors' Addresses 474 Singh Vishal 476 Email: singh.vishal@gmail.com 477 Henning Schulzrinne 478 Columbia University 479 Department of Computer Science 480 450 Computer Science Building, New York, NY 10027 481 US 483 Phone: +1 212 939 7004 484 Email: hgs@cs.columbia.edu 485 URI: http://www.cs.columbia.edu 487 Hannes Tschofenig 488 Nokia Siemens Networks 489 Linnoitustie 6 490 Espoo 02600 491 Finland 493 Phone: +358 (50) 4871445 494 Email: Hannes.Tschofenig@gmx.net 495 URI: http://www.tschofenig.priv.at 497 Full Copyright Statement 499 Copyright (C) The IETF Trust (2008). 501 This document is subject to the rights, licenses and restrictions 502 contained in BCP 78, and except as set forth therein, the authors 503 retain all their rights. 505 This document and the information contained herein are provided on an 506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 508 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 509 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 510 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Intellectual Property 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed to 517 pertain to the implementation or use of the technology described in 518 this document or the extent to which any license under such rights 519 might or might not be available; nor does it represent that it has 520 made any independent effort to identify any such rights. Information 521 on the procedures with respect to rights in RFC documents can be 522 found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use of 527 such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository at 529 http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at 535 ietf-ipr@ietf.org.