idnits 2.17.1 draft-singh-geopriv-pidf-lo-dynamic-04.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 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. 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 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 (October 30, 2008) is 5656 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'GML' is defined on line 213, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 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: Experimental H. Schulzrinne 5 Expires: May 3, 2009 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 30, 2008 10 Dynamic Feature Extensions to the Presence Information Data Format 11 Location Object (PIDF-LO) 12 draft-singh-geopriv-pidf-lo-dynamic-04.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 3, 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 The PIDF-LO specification made a subset of the functionality offered 45 by the Geography Markup Language (GML) standard 3.0 mandatory to 46 implement. This document defines child elements to the element specified in RFC 4119 to carry temporal feature 48 elements useful for tracking moving objects. It defines five 49 elements, namely speed, bearing, acceleration elevation and 50 directionOfObject. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. XML Extensions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Transferring Multiple Location Objects within SIP . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 The Presence Information Data Format - Location Object (PIDF-LO) (see 72 RFC 4119 [RFC4119]) provides geographical location of the presentity. 73 This corresponds to a physical location at a given instance of time. 74 The PIDF-LO specification made a subset of the functionality offered 75 by the Geography Markup Language (GML) standard 3.0 mandatory to 76 implement. With the extensions defined in 77 [I-D.ietf-geopriv-pdif-lo-profile] more guidelines to implementers 78 are being provided with respect to a number of location shapes that 79 have to be supported for usage within PIDF-LO. However, a number of 80 applications benefit from having access to information about changes 81 in location. Location change information is likely to be useful for 82 logistics and public safety. For example, shipping companies or 83 dispatch centers can use it to track whether vehicles are deviating 84 from an established path or exceeding speed limits. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL" are to be interpreted as described in RFC 2119 91 [RFC2119]. 93 3. XML Extensions 95 This document defines a location vector by adding child elements to 96 the element described in RFC 4119 [RFC4119], to carry 97 temporal feature elements. A receiver MAY ignore the temporal 98 elements defined in this document if it does not understand this 99 extension. 101 speed: 103 Speed is the rate of motion. (The terms speed and velocity are 104 often used interchangeably, but speed is a scalar, having 105 magnitude only, while velocity is a vector, having both magnitude 106 and direction.) 108 This element contains a 'uom' (Units Of Measure) attribute, which 109 is a reference to a reference system for the amount. The 'uom' 110 attribute uses a URI to refer to a unit of measure definition. 111 The GML document defines a set of convenience measure types and a 112 further explaination is provided at the end of this section. 114 bearing: 116 Bearing is defined as the horizontal direction of one terrestrial 117 point from another, expressed as the angular distance from a 118 reference direction. It is usually measured from 000 degrees at 119 the reference direction clockwise through 360 degrees. 121 The element is of type gml:DirectionPropertyType and 122 contains a gml:DirectionVector, gml:CompassPoint, 123 DirectionKeyword, or a DirectionString element. This document 124 profiles the usage of this GML element and mandates applications 125 using this document to make use of the element 126 only. 128 acceleration: 130 This element specifies the rate (usually rapid) at which something 131 happens. The element also contains a 'uom' 132 attribute. 134 directionOfObject: 136 The describes the instantaneous horizontal of 137 the front of the object relative to true north and the vertical 138 angle relative to the earth's spheroid. It uses the GML 139 element. 141 GML permits a range of units of measure for the uom attribute. This 142 document restricts this set to the #m/s (meters per second). 144 4. XML Schema 146 This document does not define a new schema but instead re-uses a 147 subset of the dynamicFeature.xsd schema available with GML 3.1.1, 148 namely , , , and . 150 These four elements are conveyed inside the element 151 defined by RFC 4119 [RFC4119]. 153 5. Example 155 The following example shows a PIDF-LO document indicating geospatial 156 location information using the gml:Point structure. Following the 157 element the additional fields releated to temporal 158 characteristics are included. 160 161 166 167 168 169 170 171 -34.407 150.883 172 173 174 12 175 176 177 270.0 -60.0 178 179 180 181 182 no 183 2003-06-23T04:57:29Z 184 185 186 187 2008-06-22T20:57:29Z 188 190 192 Figure 1: Example of a PIDF-LO with Speed Information 194 6. Security Considerations 196 This document defines additional location elements carried by PIDF-LO 197 (see [RFC4119]). The security considerations of RFC 4119 [RFC4119] 198 are applicable to this document. 200 7. IANA Considerations 202 This document does not require actions by IANA. 204 8. Acknowledgements 206 We would like to thank Klaus Darilion, Cullen Jennings, Rohan Mahy, 207 Carl Reed, Brian Rosen, and Martin Thomson for their comments. 209 9. References 211 9.1. Normative References 213 [GML] "Geographic information - Geography Markup Language (GML), 214 OpenGIS 03-105r1, available at: 215 http://portal.opengeospatial.org/files/?artifact_id=4700", 216 April 2004. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", RFC 2119, BCP 14, March 1997. 221 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 222 Format", RFC 4119, December 2005. 224 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 225 Presence Information Data Format (PIDF) to Indicate Status 226 Information for Past and Future Time Intervals", RFC 4481, 227 July 2006. 229 9.2. Informative References 231 [I-D.ietf-geopriv-pdif-lo-profile] 232 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 233 PIDF-LO Usage Clarification, Considerations and 234 Recommendations", draft-ietf-geopriv-pdif-lo-profile-13 235 (work in progress), September 2008. 237 Appendix A. Transferring Multiple Location Objects within SIP 239 To show the path of an object, it may be useful to deliver multiple 240 location vector objects in one PIDF-LO document to reduce the number 241 of notifications. The element [RFC4481] can contain 242 multiple location objects, with the structure shown in Figure 2 and 243 an example in Figure 3. 245 246 248 250 251 .......... 252 254 ..... 256 257 258 ............ 259 261 262 ........... 263 265 266 268 269 ....... 270 272 273 ....... 274 275 277 Figure 2: Structure of Handling Multiple Location Objects 279 The following example shows multiple PIDF-LO using . 281 282 286 287 288 289 290 291 140. -35. 292 293 294 12 295 296 297 no 298 2003-06-23T04:57:29Z 299 300 301 302 2003-06-22T20:57:29Z 304 > 306 307 308 309 310 110. -35. 311 312 313 10 314 315 316 yes 317 2003-06-23T04:55:29Z 318 319 320 321 322 323 324 325 114. -35. 326 327 328 18 329 330 331 yes 332 2003-06-23T04:53:29Z 333 334 335 336 338 340 342 Figure 3: Example showing multiple Location Vectors transmitted 343 simultaneously. 345 Authors' Addresses 347 Singh Vishal 349 Email: singh.vishal@gmail.com 351 Henning Schulzrinne 352 Columbia University 353 Department of Computer Science 354 450 Computer Science Building, New York, NY 10027 355 US 357 Phone: +1 212 939 7004 358 Email: hgs@cs.columbia.edu 359 URI: http://www.cs.columbia.edu 361 Hannes Tschofenig 362 Nokia Siemens Networks 363 Linnoitustie 6 364 Espoo 02600 365 Finland 367 Phone: +358 (50) 4871445 368 Email: Hannes.Tschofenig@gmx.net 369 URI: http://www.tschofenig.priv.at 371 Full Copyright Statement 373 Copyright (C) The IETF Trust (2008). 375 This document is subject to the rights, licenses and restrictions 376 contained in BCP 78, and except as set forth therein, the authors 377 retain all their rights. 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 382 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 383 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 384 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Intellectual Property 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org.