idnits 2.17.1 draft-winterbottom-geopriv-derived-loc-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 402. 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 28, 2008) is 5756 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) == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-11 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew Corporation 5 Expires: January 29, 2009 July 28, 2008 7 Specifying Derived Location in a PIDF-LO 8 draft-winterbottom-geopriv-derived-loc-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 29, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes how specify that a location in a PIDF-LO has 42 been derived or converted from a different location. The source 43 location may reside in the same PIDF-LO or be a remote document 44 referenced by a location URI and associated id fragement. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Linking Derived Locations In the Same Document . . . . . . . . 5 51 4. Linking to External Locations . . . . . . . . . . . . . . . . 7 52 5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 55 7.1. XML Schema Namespace Registration . . . . . . . . . . . . 10 56 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10 57 7.3. derived Token Registration . . . . . . . . . . . 11 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 59 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 61 Intellectual Property and Copyright Statements . . . . . . . . . . 15 63 1. Introduction 65 Some systems generate or determine location in one format, but the 66 application needing to comsume location requires it to be expressed 67 in a different form. A common example of this is a location 68 generator that uses wireless measurements to determine the location 69 of a device in geodetic coordinates, but this information needs to be 70 relayed to a delivery person that requires a street address. In this 71 case it is advantangeous to reverse geocode the location from 72 geodetic form to civic form. 74 The intended use of the location will not always be known ahead of 75 time, and it may be important to the ultimate consumer of location to 76 know not only that the location information being provided was 77 derived from a different location, but also what the original 78 location was. This can be done using ordering techniques with in the 79 PIDF-LO [RFC4119] , but this leads to issues if more that derived 80 location is provided, or if space is a constraint and the only one 81 location can comfortably be conveyed. 83 This specification provides a convenient and standard way to indicate 84 and link derived locations to their sources in a way that scales to 85 support multiple derived locations delievered, either in the same 86 document, or out of band through location URIs. 88 This memo requires the PIDF-LO be constructed using the rules laid 89 out in [I-D.ietf-geopriv-pdif-lo-profile]. Specifically rule #2 MUST 90 be adhered to to avoid amibuities in identifiying the correct source 91 location. 93 A small XML schema is created to provide a linking attribute. 94 Guidance on how to use the linking attribute is provided, and a new 95 PIDF-LO is registered is IANA to support the derived 96 location type. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 The term "geocoding" refers to the act of converting a civic location 105 into a corresponding geodetic location. 107 The term "reverse geocoding" refers to the act of converting a 108 geodetic location into a corresponding civic address. 110 3. Linking Derived Locations In the Same Document 112 A derived location is obtained by performing an operation on data 113 acquired from a source location. Consequently in a single document 114 two tags are required for derived location; a tag indicating which is 115 the source location, and a second tag indicating which location is 116 the derived location. 118 The source location is identified by an 'id' attribute associated 119 with a , , or element in a PIDF-LO. The 120 value of this 'id' MUST be unique in the scope of the entire document 121 as defined in [RFC4479]. Providing only one location is attributed 122 to this 'id' the source location can be unambiguously identified, and 123 it is for this reason that rule #2 from 124 [I-D.ietf-geopriv-pdif-lo-profile] MUST be adhered to. 126 Using the attribute from the schema defined in Section 5 a document 127 showing a civic location that was reverse geocoded from a geodetic 128 location would look similar to Figure 1. In this example the source 129 location is a circle, and is identified by the tuple id "nesspc-1". 130 The derived location, the civic location, is marked with the dl: 131 derivedFrom attribute that's value is a URI, in this case linking to 132 the location contained in the tuple with an 'id' attribute value of 133 "nesspc-1". 135 136 144 145 146 147 148 149 -34.410649 150.87651 150 151 30 152 153 154 155 156 GPS 158 159 160 2007-06-22T20:57:29Z 161 162 163 164 165 166 168 AU 169 NSW 170 Wollongong 171 North Wollongong 172 173 FlindersStreet 174 Campbell Street 175 176 Gilligan's Island 177 Corner 178 Main Bank 179 2500 180 398 181 store 182 Private Box 15 183 184 185 186 Derived 187 188 189 2007-06-24T12:28:04Z 190 191 193 Figure 1: Example Derived and Source Location 195 The example shown in Figure 1 can scale to any number of derived 196 locations. For example if a third location were subsequently derived 197 from the civic location then it would have a derivedFrom attribute 198 with a value of "#ness". 200 4. Linking to External Locations 202 The derivedFrom attribute is a URI, so while it can point a position 203 within the same PIDF-LO as shown in Figure 1, it can point to an 204 external source using a held, pres, sip or http URI. A location 205 derived from an external source is shown in Figure 2. 207 208 216 217 218 219 220 222 AU 223 NSW 224 Wollongong 225 North Wollongong 226 227 FlindersStreet 228 Campbell Street 229 2500 230 Private Box 15 231 232 233 234 Derived 235 236 237 2008-07-24T12:28:04Z 238 239 241 Figure 2: Example Derived and Source Location 243 5. Schema 245 This section defined the XML schema used to support derived location 246 linking. 248 249 252 253 255 Derived Location Schema 257 6. Security Considerations 259 Any location that has a value of _derived_ that does provide 260 a corresponding derivedFrom attribute link, or provides an invalid 261 derivedFrom link should be treated with the same degree of caution as 262 a location with a value of _Manual_ in that the 263 dependability of the location information cannot be assured. 265 This document does not introduce any security issues beyond those 266 already identified by PIDF-LO and the use of location URIs. 268 7. IANA Considerations 270 7.1. XML Schema Namespace Registration 272 This section registers a new XML namespace, 273 "urn:ietf:params:xml:ns:geopriv:derived", as per the guidelines in 274 [RFC3688]. 276 URI: urn:ietf:params:xml:ns:geopriv:derived 278 Registrant Contact: IETF, GEOPRIV working group, 279 (geopriv@ietf.org), James Winterbottom 280 (james.winterbottom@andrew.com). 282 XML: 284 BEGIN 285 286 288 289 290 PIDF-LO Derived Location Link Schema 291 292 293

Namespace for derived location linking attributes

294

urn:ietf:params:xml:ns:geopriv:derived

295 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 296 with the RFC number for this specification.]] 297

See RFCXXXX.

298 299 300 END 302 7.2. XML Schema Registration 304 This section registers an XML schema as per the guidelines in 305 [RFC3688]. 307 URI: urn:ietf:params:xml:schema:geopriv:derived 309 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 310 James Winterbottom (james.winterbottom@andrew.com). 312 Schema: The XML for this schema can be found as the entirety of 313 Section 5 of this document. 315 7.3. derived Token Registration 317 This section registers a new 'method' token in the IANA geopriv 318 'method' token registry. This new token is called 'derived' and is 319 used then the location being represented has been derived from a 320 different location. 322 8. Acknowledgements 324 Thanks to Brian Rosen for raising the issue of derived location 326 9. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 332 Format", RFC 4119, December 2005. 334 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 335 January 2004. 337 [I-D.ietf-geopriv-pdif-lo-profile] 338 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 339 PIDF-LO Usage Clarification, Considerations and 340 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 341 (work in progress), February 2008. 343 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 344 July 2006. 346 Authors' Addresses 348 James Winterbottom 349 Andrew Corporation 350 PO Box U40 351 University of Wollongong, NSW 2500 352 AU 354 Email: james.winterbottom@andrew.com 356 Martin Thomson 357 Andrew Corporation 358 PO Box U40 359 University of Wollongong, NSW 2500 360 AU 362 Email: martin.thomson@andrew.com 364 Full Copyright Statement 366 Copyright (C) The IETF Trust (2008). 368 This document is subject to the rights, licenses and restrictions 369 contained in BCP 78, and except as set forth therein, the authors 370 retain all their rights. 372 This document and the information contained herein are provided on an 373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 375 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 376 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 377 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 380 Intellectual Property 382 The IETF takes no position regarding the validity or scope of any 383 Intellectual Property Rights or other rights that might be claimed to 384 pertain to the implementation or use of the technology described in 385 this document or the extent to which any license under such rights 386 might or might not be available; nor does it represent that it has 387 made any independent effort to identify any such rights. Information 388 on the procedures with respect to rights in RFC documents can be 389 found in BCP 78 and BCP 79. 391 Copies of IPR disclosures made to the IETF Secretariat and any 392 assurances of licenses to be made available, or the result of an 393 attempt made to obtain a general license or permission for the use of 394 such proprietary rights by implementers or users of this 395 specification can be obtained from the IETF on-line IPR repository at 396 http://www.ietf.org/ipr. 398 The IETF invites any interested party to bring to its attention any 399 copyrights, patents or patent applications, or other proprietary 400 rights that may cover technology that may be required to implement 401 this standard. Please address the information to the IETF at 402 ietf-ipr@ietf.org. 404 Acknowledgment 406 Funding for the RFC Editor function is provided by the IETF 407 Administrative Support Activity (IASA).