idnits 2.17.00 (12 Aug 2021) /tmp/idnits55133/draft-george-geopriv-address-translation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document date (October 25, 2009) is 4590 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: 'I-D.ietf-geopriv-civic-address-recommendations' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-http-location-delivery' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC3693' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC4776' is defined on line 520, but no explicit reference was found in the text -- No information found for draft-ietf-geopriv-civic-address-recommendations - is the name correct? == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV R. George 3 Internet-Draft Q. Sun 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 28, 2010 C. Reed 6 GIS 7 October 25, 2009 9 Geodetic-Civic Address Translation Protocol 10 draft-george-geopriv-address-translation-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 April 28, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document explains how to map a geodetic datum to a civic address 49 and vice versa. Server accepts an HTTP POST with one form of user 50 specified location addresses and return whatever other form it has. 52 [Open Issue : re-frame this draft as more about the inclusion of a 53 element in a HELD request, rather than about geocoding 54 specifically, since there are other applications. E.g., we might 55 provide a rough location in our request to help the server provide us 56 with GPS assistance data.] 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology Used in This Document . . . . . . . . . . . . . . 3 62 3. Coordinate System Translation . . . . . . . . . . . . . . . . 3 63 3.1. Reverse Geocoding: Geodetic-Civic Translation . . . . . . 3 64 3.1.1. Reverse Geocoder Service Requirements . . . . . . . . 4 65 3.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Geocoding: Civic-Geodetic Translation . . . . . . . . . . 7 67 3.2.1. Geocoder Service Requirements . . . . . . . . . . . . 7 68 3.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. The Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5. The Error Codes . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 The growth of location-based services and increased access to real 81 time sensor feeds, the ability to access and exchange real- 82 time,dynamic geolocation information becomes more important. This 83 draft describes how to convert civic addresses as defined in 84 [RFC5139] to geodetic coordinates and vice versa. 86 An example of a simple Civic Address is 'Washington, DC'. Using a 87 Gazetteer service to geocode the address, a geodetic coordinate of 88 (40.8N, 73.9W) might be returned. Conversely, entering (40.8N, 89 73.9W) into a reverse geocoding service might return 'Washington DC'. 91 It is sending PIDF-LO (civic) to the server and getting a geodetic 92 address back. To use it, look up your location's co-ordinates, and 93 then enter them in the request. The corresponding response will 94 return the civic address of the requested coordinates. In the same 95 way the geodetic address obtained, if civic address information has 96 provided in the request. 98 The Geodetic-civic address translation SHOULD return standard errors 99 and status codes. The possible errors conditions are listed in the 100 Section 5. 102 2. Terminology Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Coordinate System Translation 110 3.1. Reverse Geocoding: Geodetic-Civic Translation 112 This method performs the conversion of a latitude/longitude pair into 113 human-readable addresses. A reverse geocoder service is a network- 114 accessible service that transforms a given position (geodetic 115 coordinate) into a normalized description of a feature location 116 (Address with Point), where the address may be defined as a street 117 address, intersection address, place name or postal code. A reverse 118 geocoding service could be a service supported in a location server. 120 The client or server sends a request to the location server/reverse 121 geocoding service containing the position expressed as geodetic 122 coordinates. If the address was successfully located, it sent back 123 to the requester. The response is a civic address for the given 124 geodetic address, and the response encoding (format) is described in 125 RFC [RFC5139]. In case of ambiguous addresses, only the point for 126 the best match is passed in the response. 128 3.1.1. Reverse Geocoder Service Requirements 130 The following requirements must be supported by the Reverse Geocoder 131 Service. 133 Given a Position ADT, must be able to return one or more locations 134 (i.e., Address ADTs with associated Point geometries), and 135 optionally, the ranges of these locations from the given position, as 136 it is defined in the Position ADT. 138 The form of the returned address(es) must be based upon the user's 139 preference, as stated in the request. The user should be able to 140 specify a preference of StreetAddress, StreetIntersection, or 141 PositionOfInterest (Place and/or PostalCode). If not specified, the 142 service should default to StreetAddress. 144 Must be capable of returning all location information of a preferred 145 type within an area of interest (AOI ADT - a Circle, Polygon or Box). 147 Must be able to indicate the number of matches in the response 148 (possibly zero) for a given request. 150 3.1.2. Example 151 POST /location HTTP/1.1 152 Host: lis.example.com:49152 153 Content-Type: application/held+xml 154 Content-Length: 1043 156 157 162 164 165 civic 166 168 169 170 171 172 174 -34.407 150.88001 175 176 177 178 179 180 2006-01-10T03:42:28+00:00 181 182 183 185 Requesting server to send the civic address of the latitude/longitude 186 pair given in the request. 188 HTTP/1.1 200 OK 189 Server: Example LIS 190 Date: Tue, 10 Jan 2006 03:42:29 GMT 191 Expires: Tue, 10 Jan 2006 03:42:29 GMT 192 Cache-control: private 193 Content-Type: application/held+xml 194 Content-Length: 1062 196 197 199 200 201 202 203 206 AU 207 NSW 208 Wollongong 209 Gwynneville 210 Northfield Avenue 211 University of Wollongong 212 2 213 Andrew Corporation 214 2500 215 39 216 WS-183 217 U40 218 219 220 221 222 223 2006-01-10T03:42:28+00:00 224 225 226 228 The given response is the result for a civic address request, where 229 the geodetic address is -34.407 150.88001. 231 The civic address includes the header fields that are defined in 232 [RFC5139]. We recommend that if a national or regional standard (and 233 schema) exists for encoding addresses, such as the US national 234 address coding standard, that this schema be supported in the 235 response. See also 236 draft-ietf-geopriv-civic-address-recommendations-03. 238 One thing that needs explanation is accuracy, which is a measure of 239 how accurately the system is returning location information. It 240 allows to specify whether it is 'exact', 'neighborhood' etc. 241 However, it is worth specifying how much deviation from the requested 242 location in terms of meters. If client sends a request with geodetic 243 address and there is no mapping found in the server, server could 244 return civic address which is close by. Also specify how much 245 deviation from the requested location in terms of meters. 247 3.2. Geocoding: Civic-Geodetic Translation 249 A geocoding service is a network-accessible service that transforms a 250 description of a location, such as a place name, street address or 251 postal code, into a normalized description of the location with a 252 Point geometry (geodetic coordinate). A geocoding service could be a 253 service supported in a location server to parse the given civic 254 address and get response back. 256 The server will attempt to find the closest addressable location 257 within a certain tolerance; if no match is found, the server will 258 usually return a status code, unknown addresses. 260 3.2.1. Geocoder Service Requirements 262 The following requirements must be supported by the Geocoder Service. 264 Given a Civic Address, must be capable of using an address matching 265 Geocoding algorithm to determine a position (geodetic coordinate) for 266 the specified address. 268 Must be capable of performing geocoding using an incomplete address 269 and return the complete set of address information (i.e., a 270 normalized address). 272 Must be able to indicate the number of matches in the response 273 (possibly zero) for a particular address supplied in the geocoding 274 request. 276 Must be capable of processing one or more addresses in a single 277 geocoding request. 279 May provide information on the quality of the result using a match 280 code. 282 May return the centroid of a zip code if an address is not complete. 284 May return an altitude if the service supports this capability. 286 3.2.2. Example 287 POST /location HTTP/1.1 288 Host: lis.example.com:49152 289 Content-Type: application/held+xml 290 Content-Length: 1484 292 293 298 300 301 geodetic 302 304 305 306 307 308 311 AU 312 NSW 313 Wollongong 314 Gwynneville 315 Northfield Avenue 316 University of Wollongong 317 2 318 Andrew Corporation 319 2500 320 39 321 WS-183 322 U40 323 324 325 326 327 328 2006-01-10T03:42:28+00:00 329 330 331 333 Sends a civic address to the server. 335 HTTP/1.1 200 OK 336 Server: Example LIS 337 Date: Tue, 10 Jan 2006 03:42:29 GMT 338 Expires: Tue, 10 Jan 2006 03:42:29 GMT 339 Cache-control: private 340 Content-Type: application/held+xml 341 Content-Length: 619 343 344 346 347 348 349 350 352 -34.407 150.88001 353 354 355 356 357 358 2006-01-10T03:42:28+00:00 359 360 361 363 Hence, the corresponding response from the server. 365 Result for a civic address request contains each individual response. 366 More than one result may be returned if the given address is 367 ambiguous. Possible values, from most specific to most general are: 368 address, street, zip, city, state, country etc. : If the 369 exact address was not found, the closest available match will be 370 noted here. 372 4. The Accuracy 374 Location translation service returns an Accuracy value within each 375 returned address. This value indicates the resolution of the given 376 result, but not necessarily the correctness of the result. For 377 example, a civic address of "111 8th Avenue, New York, NY" may return 378 8 (Address) level accuracy, indicating that the given address is on 379 the order of resolution of a street address. A civic address for 380 "France" would only return 1 (Country) level accuracy. 382 The following table lists the accuracy values returned by the Geo- 383 Civic address translation service. Note that these accuracy values 384 only indicate the expected resolution. 386 Value Description 388 0 Unknown accuracy. 390 1 Country level accuracy. 392 2 Region (state, province, prefecture, etc.) level accuracy. 394 3 Sub-region (county, municipality, etc.) level accuracy. 396 4 Town (city, village) level accuracy. 398 5 Post code (zip code) level accuracy. 400 6 Street level accuracy. 402 7 Intersection level accuracy. 404 8 Address level accuracy. 406 9 Premise (building name, property name, shopping center, etc.) level 407 accuracy. 409 Consider an example for with accuracy information. 411 HTTP/1.1 200 OK 412 Server: Example LIS 413 Date: Tue, 10 Jan 2006 03:42:29 GMT 414 Expires: Tue, 10 Jan 2006 03:42:29 GMT 415 Cache-control: private 416 Content-Type: application/held+xml 417 Content-Length: 957 419 420 422 423 424 425 426 429 AU 430 NSW 431 Wollongong 432 Gwynneville 433 Northfield Avenue 434 University of Wollongong 435 2 436 Andrew Corporation 437 2500 438 39 439 WS-183 440 U40 441 442 443 444 445 446 2006-01-10T03:42:28+00:00 447 448 449 451 5. The Error Codes 453 There may occur few errors during the request processing. For 454 example the parameters passed to the server did not match as 455 expected. This document should re-use the HELD error codes. In 456 particular, the server should always return a 200/OK, possibly with a 457 HELD element. In addition to HELD errors codes, following is 458 a list of error codes that you may encounter. 460 accessDenied: You do not have permission to access this resource. 462 internaleError: An internal problem prevents from returning data. 464 notDefined: The address translation process failed due to an error 465 not covered by the definition of any other error code in this 466 interface. 468 For each error, you'll receive an XML response of the following form. 470 HTTP/1.1 200 OK 471 Server: Example LIS 472 Expires: Tue, 10 Jan 2006 03:49:20 GMT 473 Cache-control: private 474 Content-Type: application/held+xml 475 Content-Length: 182 477 478 480 Unable to determine location 481 482 484 6. Security Considerations 486 TBD 488 7. IANA Considerations 490 TBD 492 8. References 494 8.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 8.2. Informative References 501 [I-D.ietf-geopriv-civic-address-recommendations] 502 Wolf, K. and A. Mayrhofer, "Considerations for Civic 503 Addresses in PIDF-LO - Guidelines and IANA Registry 504 Definition", 505 draft-ietf-geopriv-civic-address-recommendations-03 (work 506 in progress), July 2009. 508 [I-D.ietf-geopriv-http-location-delivery] 509 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 510 "HTTP Enabled Location Delivery (HELD)", 511 draft-ietf-geopriv-http-location-delivery-15 (work in 512 progress), June 2009. 514 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 515 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 517 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 518 Format", RFC 4119, December 2005. 520 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 521 (DHCPv4 and DHCPv6) Option for Civic Addresses 522 Configuration Information", RFC 4776, November 2006. 524 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 525 Format for Presence Information Data Format Location 526 Object (PIDF-LO)", RFC 5139, February 2008. 528 Authors' Addresses 530 Robins George 531 Huawei Technologies 532 Huawei Base, Bantian, Longgang District 533 Shenzhen, Guangdong 518129 534 P. R. China 536 Phone: +86-755-28788314 537 Email: robinsg@huawei.com 538 Qian Sun 539 Huawei Technologies 540 Huawei Base, Bantian, Longgang District 541 Shenzhen, Guangdong 518129 542 P. R. China 544 Phone: +86-755-28787351 545 Email: sunqian@huawei.com 547 Carl Reed 548 Open GIS Consortium, Inc 549 35 Main Street, Suite 5 550 Wayland, MA 01778-5037 518129 551 USA 553 Email: creed@opengeospatial.org