idnits 2.17.00 (12 Aug 2021) /tmp/idnits59371/draft-ietf-sedate-datetime-extended-04.txt: -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(465): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 March 2022) is 54 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 informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Serialising Extended Data About Times and Events U. Sharma 3 Internet-Draft Igalia, S.L. 4 Intended status: Standards Track C. Bormann 5 Expires: 22 September 2022 Universität Bremen TZI 6 21 March 2022 8 Date and Time on the Internet: Timestamps with additional information 9 draft-ietf-sedate-datetime-extended-04 11 Abstract 13 This document defines an extension to the timestamp format defined in 14 RFC3339 for representing additional information including a time 15 zone. 17 About This Document 19 This note is to be removed before publishing as an RFC. 21 Status information for this document may be found at 22 https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime- 23 extended/. 25 Discussion of this document takes place on the Serialising Extended 26 Data About Times and Events (SEDATE) Working Group mailing list 27 (mailto:sedate@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/sedate/. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime- 32 extended. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 22 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Extended Date/Time format . . . . . . . . . . . . . . . . . . 6 70 2.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.2. Registered . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . . . 7 73 3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 6.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Dates and times are used in a very diverse set of internet 87 applications, all the way from server-side logging to calendaring and 88 scheduling. 90 Each distinct instant in time can be represented in a descriptive 91 text format using a timestamp, and [ISO8601:1988] standardizes a 92 widely-adopted timestamp format, which forms the basis of [RFC3339]. 93 However, this format only allows timestamps to contain very little 94 additional relevant information, which means that, beyond that, any 95 contextual information related to a given timestamp needs to be 96 either handled separately or attached to it in a non-standard manner. 98 This is already a pressing issue for applications that handle each 99 instant with an associated time zone name, to take into account 100 events such as daylight saving time transitions. Most of these 101 applications attach the time zone to the timestamp in a non-standard 102 format, at least one of which is fairly well-adopted [JAVAZDT]. 103 Furthermore, applications might want to attach even more information 104 to the timestamp, including but not limited to the calendar system in 105 which it should be represented. 107 1.1. Scope 109 This document defines an extension syntax for timestamps as specified 110 in [RFC3339] that has the following properties: 112 * The extension suffix is completely optional, making existing 113 [RFC3339] timestamps compatible with this format. 115 * The format is compatible with the pre-existing popular syntax for 116 attaching time zone names to timestamps ([JAVAZDT]). 118 * The format provides a generalized way to attach any additional 119 information to the timestamp. 121 This document does not address extensions to the format where the 122 semantic result is no longer a fixed timestamp that is referenced to 123 a (past or future) UTC time. For instance, it does not address: 125 * Future time given as a local time in some specified time zone, 126 where changes to the definition of that time zone (e.g., a 127 political decision to enact or rescind daylight saving time) 128 affect the instant in time corresponding with the timestamp. 130 * "Floating time", i.e., a local time without information describing 131 the UTC offset or time zone in which it should be interpreted. 133 * The use of time scales different from UTC, such as TAI. 135 However, additional information augmenting a fixed timestamp may be 136 sufficient to detect an inconsistency between intention and the 137 actual information in the timestamp, e.g., between the UTC offset and 138 time zone name in the timestamp. For instance, such an inconsistency 139 might arise because of: 141 * Political decisions as discussed above, or 143 * errors in the applications producing and consuming such a 144 timestamp. 146 While the information available is not generally sufficient to 147 resolve the inconsistency, it may be used to initiate some out of 148 band processing to obtain sufficient information for such a 149 resolution. 151 In order to address some of the requirements implied here, future 152 related specifications might define syntax and semantics of strings 153 similar to [RFC3339]. Note that the extension syntax defined in the 154 present document is designed in such a way that it can be useful for 155 such specifications as well. 157 1.2. Definitions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 UTC: Coordinated Universal Time, as maintained since 1988 by the 166 Bureau International des Poids et Mesures (BIPM) in conjunction 167 with leap seconds as announced by the International Earth Rotation 168 and Reference Frames Service [IERS]. From 1972 through 1987, UTC 169 was maintained entirely by Bureau International de l'Heure (BIH). 170 Before 1972, UTC was not generally recognized and civil time was 171 determined by individual jurisdictions using different techniques 172 for attempting to follow Universal Time based on measuring the 173 rotation of the earth. 175 UTC is often mistakenly referred to as GMT, an earlier time scale 176 UTC was designed to be a useful successor for. 178 ABNF: Augmented Backus-Naur Form, a format used to represent 179 permissible strings in a protocol or language, as defined in 180 [RFC5234]. The rules defined in Appendix B of [RFC5234] are 181 imported implicitly. 183 Internet Date/Time Format: The date/time format defined in section 3 184 of this document. 186 Timestamp: An unambiguous representation of some instant in time. 188 UTC Offset: Difference between a given local time and UTC, usually 189 given in negative or positive hours and minutes. For example, 190 local time in New York in the wintertime is 5 hours behind UTC, so 191 its UTC offset is "-05:00". 193 Z: A suffix which, when applied to a time, denotes a UTC offset of 194 00:00; often spoken "Zulu" from the ICAO phonetic alphabet 195 representation of the letter "Z". (Definition from Section 2 of 196 [RFC3339].) 198 Time Zone: A set of rules representing the relationship of local 199 time to UTC for a particular place or region. Mathematically, a 200 time zone can be thought of as a function that maps timestamps to 201 UTC offsets. Time zones can deterministically convert a timestamp 202 to local time. They can also be used in the reverse direction to 203 convert local time to a timestamp, with the caveat that some local 204 times may have zero or multiple possible timestamps due to nearby 205 Daylight Saving Time changes or other changes to the UTC offset of 206 that time zone. Unlike the UTC offset of a timestamp which makes 207 no claims about the UTC offset of other related timestamps (and 208 which is therefore unsuitable for performing local-time operations 209 such as "one day later"), a time zone also defines how to derive 210 new timestamps based on differences in local time. For example, 211 to calculate "one day later than this timestamp in San Francisco", 212 a time zone is required because the UTC offset of local time in 213 San Francisco can change from one day to the next. 215 IANA Time Zone: A named time zone that is included in the Time Zone 216 Database (often called tz or zoneinfo) maintained by IANA 217 [TZDB][BCP175]. Most IANA time zones are named for the largest 218 city in a particular region that shares the same time zone rules, 219 e.g. Europe/Paris or Asia/Tokyo [TZDB-NAMING]. Special IANA time 220 zones such as Etc/GMT+10 can be used to represent timestamps 221 outside country boundaries, e.g. a buoy in the middle of the 222 Pacific Ocean (note that the Etc/GMT+10 time zone has a constant 223 UTC Offset of -10:00 [sic!]). 225 Note that the rules defined for a named IANA time zone can change 226 over time. The use of a named IANA time zone implies that the 227 intent is for the rules that are current at the time of 228 interpretation to apply, i.e., the additional information conveyed 229 by using that time zone name is to change with the changed rules 230 as recorded in the IANA time zone database. 232 Offset Time Zone: A time zone defined by a specific UTC offset, e.g. 233 +08:45 and serialized using as its name the same numeric UTC 234 offset format used in an RFC 3339 timestamp. Although 235 serialization with offset time zones is supported in this document 236 for backwards compatibility with java.time.ZonedDateTime 237 [JAVAZDT], use of offset time zones is strongly discouraged. In 238 particular, programs MUST NOT copy the UTC offset from a timestamp 239 into an offset time zone in order to satisfy another program which 240 requires a time zone annotation in its input. Doing this will 241 improperly assert that the UTC offset of timestamps in that 242 location will never change, which can result in incorrect 243 calculations in programs that add, subtract, or otherwise derive 244 new timestamps from the one provided. For example, 2020-01- 245 01T00:00+01:00[Europe/Paris] will let programs add six months to 246 the timestamp while adjusting for Summer Time (Daylight Saving 247 Time). But the same calculation applied to 248 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result 249 that will be off by one hour in the timezone Europe/Paris. 251 CLDR: Common locale data repository [CLDR], a project of the Unicode 252 Consortium to provide locale data to applications. 254 For more information about time scales, see Appendix E of [RFC1305], 255 Section 3 of [ISO8601:1988], and the appropriate ITU documents 256 [ITU-R-TF.460-6]. 258 2. Extended Date/Time format 260 This section discusses desirable qualities of formats for the 261 timestamp extension suffix and defines such a format that extends 262 [RFC3339] for use in Internet protocols. 264 2.1. Informative 266 The format is intended to allow implementations to specify additional 267 important information in addition to the bare timestamp. 269 This is done by defining _tags_, each with a _key_ and a _value_ 270 separated by an equals sign. The value of a tag can be one or more 271 items delimited by hyphen/minus signs. 273 Applications can build an informative timestamp _suffix_ using any 274 number of these tags. 276 Keys are case-sensitive. Values are case-sensitive unless otherwise 277 specified. 279 When a suffix contains a repeated key or otherwise conflicting tags, 280 implementations MUST give precedence to whichever value is positioned 281 first. 282 // I'd rather place a MUST NOT for this case, first. This definitely 283 // needs to be expanded into some general text about error handling. 284 // 285 // -- --- cabo 287 2.2. Registered 289 Actual suffix tag keys are registered by supplying the information 290 specified in this section. This information is modeled after that 291 specified for the media type registry [RFC6838]; if in doubt, the 292 provisions of this registry should be applied analogously. 294 Key Identifier: The key. 296 Registration status: "Provisional" or "Permanent" 298 Description: A very brief description of the key. 300 Change controller: Who is in control of evolving the specification 301 governing values for this key. This information can include email 302 addresses of contact points and discussion lists, and references 303 to relevant web pages (URLs). 305 Reference: A reference. For permanent tag keys, this includes a 306 full specification. For provisional tag keys, there is an 307 expectation that some information is available even if that does 308 not amount to a full specification; in this case, the registrant 309 is expected to improve this information over time. 311 Key names that start with an underscore are intended for experiments 312 in controlled environments and cannot be registered; such keys MUST 313 NOT be used for interchange and MUST be rejected by implementations 314 not specifically configured to take part in such an experiment. See 315 [BCP178] for a discussion about the danger of experimental keys 316 leaking out to general production and why that MUST be prevented. 318 3. Syntax Extensions to RFC 3339 320 3.1. ABNF 322 The following rules extend the ABNF syntax defined in [RFC3339] in 323 order to allow the inclusion of an optional suffix. 325 The extended date/time format is described by the rule date-time-ext. 326 date-time and time-numoffset are imported from Section 5.6 of 327 [RFC3339], ALPHA and DIGIT from Appendix B.1 of [RFC5234]. 329 time-zone-initial = ALPHA / "." / "_" 330 time-zone-char = time-zone-initial / DIGIT / "-" / "+" 331 time-zone-part = time-zone-initial *13(time-zone-char) 332 ; but not "." or ".." 333 time-zone-name = time-zone-part *("/" time-zone-part) 334 time-zone = "[" time-zone-name / time-numoffset "]" 336 key-initial = ALPHA / "_" 337 key-char = key-initial / DIGIT / "-" 338 suffix-key = key-initial *key-char 340 suffix-value = 1*alphanum 341 suffix-values = suffix-value *("-" suffix-value) 342 suffix-tag = "[" suffix-key "=" suffix-values "]" 343 suffix = [time-zone] *suffix-tag 345 date-time-ext = date-time suffix 347 alphanum = ALPHA / DIGIT 349 Figure 1: ABNF grammar of extensions to RFC 3339 351 Note that a time-zone is syntactically similar to a suffix-tag, but 352 does not include an equals sign. This special case is only available 353 for time zone tags. 355 3.2. Examples 357 Here are some examples of Internet extended date/time format. 359 1996-12-19T16:39:57-08:00 361 Figure 2: RFC 3339 date-time with time zone offset 363 Figure 2 represents 39 minutes and 57 seconds after the 16th hour of 364 December 19th, 1996 with an offset of -08:00 from UTC. Note that 365 this is the same instant in time as 1996-12-20T00:39:57Z, expressed 366 in UTC. 368 1996-12-19T16:39:57-08:00[America/Los_Angeles] 370 Figure 3: Adding a time zone name 372 Figure 3 represents the exact same instant as the previous example 373 but additionally specifies the human time zone associated with it 374 ("Pacific Time") for time-zone-aware implementations to take into 375 account. 377 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew] 379 Figure 4: Projecting to the Hebrew calendar 381 Figure 4 represents the exact same instant, but it informs calendar- 382 aware implementations that they should project it to the Hebrew 383 calendar. 385 1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat] 387 Figure 5: Adding experimental tags 389 Figure 5, based on Figure 2, utilizes keys identified as experimental 390 by a leading underscore to declare two additional pieces of 391 information in the suffix; these can be interpreted by 392 implementations that take part in the controlled experiment making 393 use of these tag keys. 395 4. IANA Considerations 397 IANA is requested to establish a registry called "Timestamp Suffix 398 Tag Keys". Each entry in the registry shall consist of the 399 information described in Section 2.2. Initial contents of the 400 registry are specified in Section 2.2. 401 // We need to actually do this; see github issue #4. 403 The registration policy [RFC8126] is "Specification Required" for 404 permanent entries, and "Expert Review" for provisional ones. In the 405 second case, the expert is instructed to ascertain that a basic 406 specification does exist, even if not complete or published yet. 408 5. Security Considerations 410 TBD 412 6. References 414 6.1. Normative References 416 [BCP175] Lear, E. and P. Eggert, "Procedures for Maintaining the 417 Time Zone Database", BCP 175, RFC 6557, 418 DOI 10.17487/RFC6557, February 2012, 419 . 421 [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, 422 "Deprecating the "X-" Prefix and Similar Constructs in 423 Application Protocols", BCP 178, RFC 6648, 424 DOI 10.17487/RFC6648, June 2012, 425 . 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 433 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 434 . 436 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 437 Specifications: ABNF", STD 68, RFC 5234, 438 DOI 10.17487/RFC5234, January 2008, 439 . 441 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 442 Specifications and Registration Procedures", BCP 13, 443 RFC 6838, DOI 10.17487/RFC6838, January 2013, 444 . 446 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 447 Writing an IANA Considerations Section in RFCs", BCP 26, 448 RFC 8126, DOI 10.17487/RFC8126, June 2017, 449 . 451 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 452 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 453 May 2017, . 455 6.2. Informative References 457 [CLDR] "Unicode CLDR Project", . 459 [IERS] "International Earth Rotation Service Bulletins", 460 . 463 [ISO8601:1988] 464 International Organization for Standardization, "Data 465 elements and interchange formats — Information interchange 466 — Representation of dates and times", ISO 8601:1988, June 467 1988, . 469 [ITU-R-TF.460-6] 470 "ITU-R TF.460-6. Standard-frequency and time-signal 471 emissions", February 2002, 472 . 474 [JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter: 475 ISO_ZONED_DATE_TIME", 476 . 479 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 480 Specification, Implementation and Analysis", RFC 1305, 481 DOI 10.17487/RFC1305, March 1992, 482 . 484 [TZDB] "Sources for time zone and daylight saving time data", 485 . 487 [TZDB-NAMING] 488 "Theory and pragmatics of the tz code and data", 489 . 491 Acknowledgements 493 Richard Gibson provided some editorial improvements. 495 Contributors 497 Justin Grant 498 Email: justingrant.ietf.public@gmail.com 500 Your Name Here 502 Authors' Addresses 504 Ujjwal Sharma 505 Igalia, S.L. 506 Bugallal Marchesi, 22, 1º 507 15008 A Coruña 508 Spain 509 Email: ryzokuken@igalia.com 510 Carsten Bormann 511 Universität Bremen TZI 512 Postfach 330440 513 D-28359 Bremen 514 Germany 515 Phone: +49-421-218-63921 516 Email: cabo@tzi.org