idnits 2.17.1 draft-murchison-tzdist-geolocate-03.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 (November 9, 2018) is 1993 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 November 9, 2018 5 Expires: May 13, 2019 7 The Time Zone Data Distribution Service (TZDIST) Geolocate Extension 8 draft-murchison-tzdist-geolocate-03 10 Abstract 12 This document defines an extension to the Time Zone Data Distribution 13 Service (RFC 7808) to allow a mobile device to retrieve the time 14 zones associated with a geographic location as specified by a 'geo' 15 URI (RFC 5870). 17 Open Issues 19 o Determine which, if any, GEOPRIV requirements we need to follow 20 and how they impact Security/Privacy considerations. 22 o Need a new field(s) in the response to indicate which time zone(s) 23 contain the point location vs those which are nearby (intersect 24 the radius of uncertainty). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 13, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 59 3. "geolocate" Action . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Examples: geolocate 61 action . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Service Action Registration . . . . . . . . . . . . . . . 7 66 6.2. Registration of invalid-location Error URN . . . . . . . 7 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Change History (To be removed by RFC Editor before 72 publication) . . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Updating time zone data with Time Zone Data Distribution (TZDIST) 78 requires prior knowledge of the time zone identifier. Such prior 79 knowledge may be inconvenient for mobile devices that may pass 80 through multiple time zones as their geographic location changes. 81 This specification defines a new TZDIST service action to allow a 82 client on a mobile device to retrieve the time zone identifiers 83 associated with its current location, as specified by a 'geo' URI 84 [RFC5870]. 86 This specification does not define the source of the time zone 87 boundary data. It is assumed that a reliable and accurate source is 88 available. One such source is the Time Zone Boundary Builder [TZBB]. 90 2. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. 97 This specification contains examples of HTTP requests and responses. 98 In some cases, additional line breaks have been introduced into the 99 request or response data to match maximum line-length limits of this 100 document. 102 3. "geolocate" Action 104 Name: geolocate 106 Request-URI Template: 107 {/service-prefix,data-prefix}/zones{?location} 109 Description: This action allows a client to query the time zone data 110 distribution service for the time zone identifier(s) corresponding 111 to the given geographic location, specified as a 'geo' URI 112 [RFC5870]. 114 If the 'geo' URI specifies a location that lies on a time zone 115 boundary or within multiple time zone boundaries (e.g. there is no 116 consensus as to the official time zone in the given region), the 117 server SHOULD return the time zone identifiers for all time zones 118 whose boundary contains the location. 120 If the 'geo' URI specifies an uncertainty value (";u=" parameter), 121 the server MUST return the time zone identifiers for all time 122 zones whose boundary passes through the radius of uncertainty. In 123 the absence of a client-supplied uncertainty value, the server MAY 124 use an implicit uncertainty to coincide with any uncertainty in 125 the time zone boundary data that it uses. 127 If the 'geo' URI specifies a coordinate reference system (";crs=" 128 parameter) that is unsupported by the server, the server SHOULD 129 return a JSON "problem details" object [RFC7807] in the response 130 body including a "type" member with an "invalid-location" error 131 URN as defined below. 133 Parameters: 135 location= REQUIRED, and MUST occur only once. 137 Response: The response has the same format as the "list" and "find" 138 actions (see [RFC7808] Section 6.2), with one result object for 139 each geolocated time zone. If for any reason the server can not 140 determine a time zone in which the point is located (e.g. 141 uninhabited location), it MUST return a "list" response containing 142 zero time zone objects. 144 Possible Error Codes 145 urn:ietf:params:tzdist:error:invalid-location The "location" URI 146 query parameter has an incorrect or unsupported value or 147 appears more than once. 149 3.1. Examples: geolocate action 151 The examples below presume that the timezone context path has been 152 discovered (see [RFC7808] Section 4.2.1) to be "/tzdist". 154 In this example the client asks for the time zone corresponding to 155 the Royal Observatory, Greenwich [ROG]. 157 >> Request << 159 GET /tzdist/zones?location=geo:51.47778,0.001388889 HTTP/1.1 160 Host: tz.example.com 162 >> Response << 164 HTTP/1.1 200 OK 165 Date: Fri, 09 Nov 2018 13:43:28 GMT 166 Content-Type: application/json; charset="utf-8" 167 Content-Length: xxxx 169 { 170 "synctoken": "2860088640-1510059107", 171 "timezones": [ 172 { 173 "tzid": "Europe/London", 174 "etag": "873664-1510059107", 175 "last-modified": "2017-11-07T12:51:47Z", 176 "publisher": "IANA Time Zone Database", 177 "version": "2017c", 178 "aliases": [ 179 "GB", 180 "GB-Eire", 181 "Europe/Isle_of_Man", 182 "Europe/Guernsey", 183 "Europe/Belfast", 184 "Europe/Jersey" 185 ] 186 } 187 ] 188 } 189 In this example the client asks for the time zone corresponding to 190 Urumqi, Xinjiang, China [Urumqi]. Note that there are two different 191 time standards [Xinjiang_Time] in use in this region. 193 >> Request << 195 GET /tzdist/zones?location=geo:43.825,87.6 HTTP/1.1 196 Host: tz.example.com 198 >> Response << 200 HTTP/1.1 200 OK 201 Date: Fri, 09 Nov 2018 13:45:31 GMT 202 Content-Type: application/json; charset="utf-8" 203 Content-Length: xxxx 205 { 206 "synctoken": "2860088640-1517192208", 207 "timezones": [ 208 { 209 "tzid": "Asia/Shanghai", 210 "etag": "914662-1517192208", 211 "last-modified": "2018-01-29T02:16:48Z", 212 "publisher": "IANA", 213 "version": "2018c", 214 "aliases": [ 215 "Asia/Chungking", 216 "Asia/Harbin", 217 "Asia/Chongqing", 218 "PRC" 219 ] 220 }, 221 { 222 "tzid": "Asia/Urumqi", 223 "etag": "229038-1517192208", 224 "last-modified": "2018-01-29T02:16:48Z", 225 "publisher": "IANA", 226 "version": "2018c", 227 "aliases": [ 228 "Asia/Kashgar" 229 ] 230 } 231 ] 232 } 233 In this example the client asks for the timezone corresponding to the 234 Niagara Falls [NF] with an uncertainty of 50m. Note that the 235 cataracts are located on the border of Ontario, Canada, and New York, 236 United States, and therefore straddle a time zone boundary. 238 >> Request << 240 GET /tzdist/zones?location=geo:43.0799,-79.0747;u=50 HTTP/1.1 241 Host: tz.example.com 243 >> Response << 245 HTTP/1.1 200 OK 246 Date: Fri, 09 Nov 2018 13:58:07 GMT 247 Content-Type: application/json; charset="utf-8" 248 Content-Length: xxxx 250 { 251 "synctoken": "2860088640-1510059107", 252 "timezones": [ 253 { 254 "tzid": "America/New_York", 255 "etag": "6602582-1510059107", 256 "last-modified": "2017-11-07T12:51:47Z", 257 "publisher": "IANA Time Zone Database", 258 "version": "2017c", 259 "aliases": [ 260 "US/Eastern" 261 ] 262 }, 263 { 264 "tzid": "America/Toronto", 265 "etag": "3297806-1510059107", 266 "last-modified": "2017-11-07T12:51:47Z", 267 "publisher": "IANA Time Zone Database", 268 "version": "2017c", 269 "aliases": [ 270 "America/Montreal", 271 "Canada/Eastern" 272 ] 273 } 274 ] 275 } 277 4. Security Considerations 279 This specification does not introduce any additional security 280 concerns beyond those described in Section 8 of [RFC7808] 282 5. Privacy Considerations 284 A client that uses this extension will leak the precise location of a 285 user's device. The strategies described in Section 9 of [RFC7808] 286 can be used to diminish the ability of an untrusted server or network 287 observer to track the device. 289 6. IANA Considerations 291 6.1. Service Action Registration 293 This document defines the following new TZDIST Service Action to be 294 added to the registry defined in Section 10.3.1 of [RFC7808]: 296 +-------------+--------------------+ 297 | Action Name | Reference | 298 +-------------+--------------------+ 299 | geolocate | RFCXXXX, Section 3 | 300 +-------------+--------------------+ 302 6.2. Registration of invalid-location Error URN 304 This section registers the "urn:ietf:params:tzdist:error:invalid- 305 location" URN in the "TZDIST Identifiers" registry defined in 306 Section 10.4 of [RFC7808]. 308 URN: urn:ietf:params:tzdist:error:invalid-location 310 Description: Error code for incorrect use of the "location" URI 311 query parameter. 313 Specification: RFCXXXX, Section 3 315 Contact: IESG 317 Index value: N/A. 319 7. Acknowledgments 321 The author would like to thank the following individuals for 322 contributing their ideas and support for writing this specification: 323 Cyrus Daboo, Michael Douglass, Paul Eggert, Eliot Lear, and Daniel 324 Migault. 326 8. References 328 8.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 336 Identifier for Geographic Locations ('geo' URI)", 337 RFC 5870, DOI 10.17487/RFC5870, June 2010, 338 . 340 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 341 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 342 . 344 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 345 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 346 . 348 8.2. Informative References 350 [NF] Wikipedia, "Niagara Falls", 351 . 353 [ROG] Wikipedia, "Royal Observatory, Greenwich", 354 . 357 [TZBB] Siroky, E., "Timezone Boundary Builder", 358 . 360 [Urumqi] Wikipedia, "Urumqi", 361 . 363 [Xinjiang_Time] 364 Wikipedia, "Xinjiang Time", 365 . 367 Appendix A. Change History (To be removed by RFC Editor before 368 publication) 370 Changes since -02: 372 o Made it clear that this extension is primarily for use by mobile 373 devices. 375 o Made it clear that multiple time zones may be returned for a 376 specified location (with example). 378 o Minor editorial changes. 380 Changes since -01: 382 o Minor editorial changes. 384 Changes since -00: 386 o Updated author information. 388 o Changed locations used in examples. 390 o Closed issue "percent-encode 'geo' URI value" as unnecessary. 392 o Closed issue "advertise supported coordinate reference system" as 393 unnecessary (only "wgs84" is defined for RFC 5870). 395 o Closed issue "discuss territorial and/or international waters" as 396 unnecessary. 398 o Added privacy concern. 400 o Minor editorial changes. 402 Author's Address 404 Kenneth Murchison 405 FastMail US LLC 406 1315 Walnut Street, Suite 320 407 Philadelphia, PA 19107 408 USA 410 Email: murch@fastmailteam.com