idnits 2.17.1 draft-murchison-tzdist-geolocate-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (May 8, 2018) is 2178 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) ** Obsolete normative reference: RFC 7807 (Obsoleted by RFC 9457) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission K. Murchison 3 Internet-Draft FastMail 4 Intended status: Standards Track May 8, 2018 5 Expires: November 9, 2018 7 The Time Zone Data Distribution Service (TZDIST) Geolocate Extension 8 draft-murchison-tzdist-geolocate-02 10 Abstract 12 This document defines an extension to the Time Zone Data Distribution 13 Service (RFC 7808) to allow a client to determine the correct time 14 zone for a geographic point location using a 'geo' URI (RFC 5870). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 9, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 49 3. "geolocate" Action . . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Examples: geolocate 51 action . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 53 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 6.1. Service Action Registration . . . . . . . . . . . . . . . 6 56 6.2. Registration of invalid-location Error URN . . . . . . . 6 57 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 8.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Appendix A. Change History (To be removed by RFC Editor before 62 publication) . . . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 Clients using a Time Zone Data Distribution Service (TZDIST), 68 particularly mobile clients, may not have prior knowledge of which 69 time zone is appropriate for a particular geographic region. This 70 specification defines a new TZDIST service action to allow a client 71 to query a server with a geographic point location and have that 72 server determine if the location lies within the boundaries of an 73 existing time zone and return the corresponding time zone identifier. 75 This specification does not define the source of the time zone 76 boundary data. It is assumed that a reliable and accurate source is 77 available. One such source is the Time Zone Boundary Builder [TZBB]. 79 2. Conventions Used in This Document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 [RFC2119]. 86 This specification contains examples of HTTP requests and responses. 87 In some cases, additional line breaks have been introduced into the 88 request or response data to match maximum line-length limits of this 89 document. 91 3. "geolocate" Action 93 Name: geolocate 95 Request-URI Template: 96 {/service-prefix,data-prefix}/zones{?location} 98 Description: This action allows a client to query the time zone data 99 distribution service for the time zone identifier corresponding to 100 the given geographic point location, specified as a 'geo' URI 101 [RFC5870]. 103 If the 'geo' URI specifies an uncertainty value (";u=" parameter), 104 the server MUST return the time zone identifiers for all time 105 zones whose boundary passes through the radius of uncertainty. In 106 the absence of a client-supplied uncertainty value, the server MAY 107 use an implicit uncertainty to coincide with any uncertainty in 108 the time zone boundary data that it uses. 110 If the 'geo' URI specifies a coordinate reference system (";crs=" 111 parameter) that is unsupported by the server, the server SHOULD 112 return a JSON "problem details" object [RFC7807] in the response 113 body including a "type" member with an "invalid-location" error 114 URN as defined below. 116 Parameters: 118 location= REQUIRED, and MUST occur only once. 120 Response: The response has the same format as the "list" and "find" 121 actions (see [RFC7808] Section 6.2), with one result object for 122 each geolocated time zone. If for any reason the server can not 123 determine a time zone in which the point is located (e.g. 124 uninhabited location), it MUST return a "list" response containing 125 zero time zone objects. 127 Possible Error Codes 129 urn:ietf:params:tzdist:error:invalid-location The "location" URI 130 query parameter has an incorrect or unsupported value or 131 appears more than once. 133 3.1. Examples: geolocate action 135 The examples below presume that the timezone context path has been 136 discovered (see [RFC7808] Section 4.2.1) to be "/tzdist". 138 In this example the client asks for the time zone corresponding to 139 the Royal Observatory, Greenwich [ROG]. 141 >> Request << 143 GET /tzdist/zones?location=geo:51.47778,0.001388889 HTTP/1.1 144 Host: tz.example.com 146 >> Response << 148 HTTP/1.1 200 OK 149 Date: Thu, 09 Nov 2017 13:43:28 GMT 150 Content-Type: application/json; charset="utf-8" 151 Content-Length: xxxx 153 { 154 "synctoken": "2860088640-1510059107", 155 "timezones": [ 156 { 157 "tzid": "Europe/London", 158 "etag": "873664-1510059107", 159 "last-modified": "2017-11-07T12:51:47Z", 160 "publisher": "IANA Time Zone Database", 161 "version": "2017c", 162 "aliases": [ 163 "GB", 164 "GB-Eire", 165 "Europe/Isle_of_Man", 166 "Europe/Guernsey", 167 "Europe/Belfast", 168 "Europe/Jersey" 169 ] 170 } 171 ] 172 } 173 In this example the client asks for the timezone corresponding to the 174 Niagara Falls [NF] with an uncertainty of 50m. Note that the 175 cataracts are located on the border of Ontario, Canada, and New York, 176 United States, and therefore straddle a time zone boundary. 178 >> Request << 180 GET /tzdist/zones?location=geo:43.0799,-79.0747;u=50 HTTP/1.1 181 Host: tz.example.com 183 >> Response << 185 HTTP/1.1 200 OK 186 Date: Thu, 09 Nov 2017 13:58:07 GMT 187 Content-Type: application/json; charset="utf-8" 188 Content-Length: xxxx 190 { 191 "synctoken": "2860088640-1510059107", 192 "timezones": [ 193 { 194 "tzid": "America/New_York", 195 "etag": "6602582-1510059107", 196 "last-modified": "2017-11-07T12:51:47Z", 197 "publisher": "IANA Time Zone Database", 198 "version": "2017c", 199 "aliases": [ 200 "US/Eastern" 201 ] 202 }, 203 { 204 "tzid": "America/Toronto", 205 "etag": "3297806-1510059107", 206 "last-modified": "2017-11-07T12:51:47Z", 207 "publisher": "IANA Time Zone Database", 208 "version": "2017c", 209 "aliases": [ 210 "America/Montreal", 211 "Canada/Eastern" 212 ] 213 } 214 ] 215 } 217 4. Security Considerations 219 This specification does not introduce any additional security 220 concerns beyond those described in Section 8 of [RFC7808] 222 5. Privacy Considerations 224 A client that uses this extension will leak the precise location of a 225 user's device. The strategies described in Section 9 of [RFC7808] 226 can be used to diminish the ability of an untrusted server or network 227 observer to track the device. 229 6. IANA Considerations 231 6.1. Service Action Registration 233 This document defines the following new TZDIST Service Action to be 234 added to the registry defined in Section 10.3.1 of [RFC7808]: 236 +-------------+--------------------+ 237 | Action Name | Reference | 238 +-------------+--------------------+ 239 | geolocate | RFCXXXX, Section 3 | 240 +-------------+--------------------+ 242 6.2. Registration of invalid-location Error URN 244 This section registers the "urn:ietf:params:tzdist:error:invalid- 245 location" URN in the "TZDIST Identifiers" registry defined in 246 Section 10.4 of [RFC7808]. 248 URN: urn:ietf:params:tzdist:error:invalid-location 250 Description: Error code for incorrect use of the "location" URI 251 query parameter. 253 Specification: RFCXXXX, Section 3 255 Contact: IESG 257 Index value: N/A. 259 7. Acknowledgments 261 The author would like to thank the following individuals for 262 contributing their ideas and support for writing this specification: 263 Cyrus Daboo and Michael Douglass. 265 8. References 267 8.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 275 Identifier for Geographic Locations ('geo' URI)", 276 RFC 5870, DOI 10.17487/RFC5870, June 2010, 277 . 279 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 280 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 281 . 283 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 284 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 285 . 287 8.2. Informative References 289 [NF] Wikipedia, "Niagara Falls", 290 . 292 [ROG] Wikipedia, "Royal Observatory, Greenwich", 293 . 296 [TZBB] Siroky, E., "Timezone Boundary Builder", 297 . 299 Appendix A. Change History (To be removed by RFC Editor before 300 publication) 302 Changes since -01: 304 o Minor editorial changes. 306 Changes since -00: 308 o Updated author information. 310 o Changed locations used in examples. 312 o Closed issue "percent-encode 'geo' URI value" as unnecessary. 314 o Closed issue "advertise supported coordinate reference system" as 315 unnecessary (only "wgs84" is defined for RFC 5870). 317 o Closed issue "discuss territorial and/or international waters" as 318 unnecessary. 320 o Added privacy concern. 322 o Minor editorial changes. 324 Author's Address 326 Kenneth Murchison 327 FastMail Pty Ltd 328 1315 Walnut Street, Suite 320 329 Philadelphia, PA 19107 330 USA 332 Email: murch@fastmailteam.com