idnits 2.17.1 draft-ietf-sedate-datetime-extended-01.txt: -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(434): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(435): 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 October 2021) is 891 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 2028 (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: 23 April 2022 Universität Bremen TZI 6 20 October 2021 8 Date and Time on the Internet: Timestamps with additional information 9 draft-ietf-sedate-datetime-extended-01 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 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 23 April 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Extended Date/Time format . . . . . . . . . . . . . . . . . . 4 53 3.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Namespaced . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.3. Multi-character Namespaces . . . . . . . . . . . . . . . 5 56 3.4. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . 7 57 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 62 6.2. Informative References . . . . . . . . . . . . . . . . . 10 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 Dates and times are used in a very diverse set of internet 69 applications, all the way from server-side logging to calendaring and 70 scheduling. 72 Each distinct instant in time can be represented in a descriptive 73 text format using a timestamp, and [ISO8601] standardizes a widely- 74 adopted timestamp format, which forms the basis of [RFC3339]. 75 However, this format only allows timestamps to contain very little 76 additional relevant information, which means that, beyond that, any 77 contextual information related to a given timestamp needs to be 78 either handled separately or attached to it in a non-standard manner. 80 This is already a pressing issue for applications that handle each 81 instant with an associated time zone name, to take into account 82 things like DST transitions. Most of these applications attach the 83 timezone to the timestamp in a non-standard format, at least one of 84 which is fairly well-adopted [JAVAZDT]. Furthermore, applications 85 might want to attach even more information to the timestamp, 86 including but not limited to the calendar system it needs to be 87 represented in. 89 This document defines an extension syntax for timestamps as specified 90 in [RFC3339] that has the following properties: 92 * The extension suffix is completely optional, making existing 93 [RFC3339] timestamps compatible with this format. 95 * The format is compatible with the pre-existing popular syntax for 96 attaching time zone names to timestamps ([JAVAZDT]). 98 * The format provides a generalized way to attach any additional 99 information to the timestamp. 101 2. Definitions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 UTC: Coordinated Universal Time, as maintained since 1988 by the 110 Bureau International des Poids et Mesures (BIPM) in conjunction 111 with leap seconds as announced by the International Earth Rotation 112 and Reference Frames Service [IERS]. From 1972 through 1987 UTC 113 was maintained entirely by Bureau International de l'Heure (BIH). 114 Before 1972 UTC was not generally recognized and civil time was 115 determined by individual jurisdictions using different techniques 116 for attempting to follow Universal Time based on measuring the 117 rotation of the earth. 119 UTC is often mistakenly referred to as GMT, an earlier time scale 120 UTC was designed to be a useful successor for. 122 ABNF: Augmented Backus-Naur Form, a format used to represent 123 permissible strings in a protocol or language, as defined in 124 [RFC5234]. The rules defined in Appendix B of [RFC5234] are 125 imported implictly. 127 Internet Date/Time Format: The date/time format defined in section 3 128 of this document. 130 Timestamp: This term is used in this document to refer to an 131 unambiguous representation of some instant in time. 133 Z: A suffix which, when applied to a time, denotes a UTC offset of 134 00:00; often spoken "Zulu" from the ICAO phonetic alphabet 135 representation of the letter "Z". 137 Time Zone: A time zone that is a included in the Time Zone Database 138 (often called tz or zoneinfo) maintained by IANA. 140 CLDR: Common locale data repository [CLDR], a project of the Unicode 141 Consortium to provide locale data to applications. 143 For more information about time scales, see Appendix E of [RFC1305], 144 Section 3 of [ISO8601], and the appropriate ITU documents 145 [ITU-R-TF.460-6]. 147 3. Extended Date/Time format 149 This section discusses desirable qualities of formats for the 150 timestamp extension suffix and defines such a format that extends 151 [RFC3339] for use in Internet protocols. 153 3.1. Informative 155 The format should allow implementations to specify additional 156 important information in addition to the bare timestamp. This is 157 done by defining _tags_, each with a _key_ and a _value_ separated by 158 an equals sign, and allowing implementations to include an 159 informative _suffix_ at the end with as many tags as required. The 160 value of a tag can be a hyphen delimited list of multiple values. 162 In case a key is repeated or conflicted, implementations MUST give 163 precedence to whichever value is positioned first. 165 3.2. Namespaced 167 Since tags can include all sorts of additional information, different 168 standards bodies/organizations need a way to identify which part 169 adheres to their standards. For this, all information needs to be 170 namespaced. Each key is therefore divided into two hyphen-separated 171 sections: the namespace and the key. For example, the calendar as 172 defined by the Unicode consortium could be included as u-ca=. 174 All single-character namespaces are reserved for [BCP47] extensions 175 recorded in the BCP47 extensions registry. For these namespaces: 177 * Case differences are ignored. 179 * The namespace is restricted to single alphanum, corresponding to 180 extension singletons ('x' can be used for a private use 181 extension). 183 * In addition, for CLDR extensions: 185 - There must be a namespace-key and it is restricted to 2 186 alphanum characters. 188 - A suffix-value is limited to 3*8alphanum. 190 3.3. Multi-character Namespaces 192 Multi-character namespaces can be registered specifically for use in 193 this format, see Section 4. The registration policy requires the 194 development of an RFC, which SHALL define the name, purpose, 195 processes, and procedures for maintaining the tags using the 196 namespace registered. 198 (This subsection uses BCP 14 language to describe the requirements on 199 the information interchanged indirectly by providing requirements on 200 the RFC registering a namespace and the principles of its evolution.) 202 The maintaining or registering authority, including name, contact 203 email, discussion list email, and URL location of the registry, MUST 204 be indicated clearly in the RFC. The RFC MUST specify each of the 205 following (directly or included by reference): 207 * The specification MUST reference the specific version or revision 208 of this document that governs its creation and MUST reference this 209 section of this document. 211 * The specification and all keys defined by the specification MUST 212 follow the ABNF and other rules for the formation of keys as 213 defined in this document. In particular, it MUST specify that 214 case is not significant and that keys MUST NOT exceed eight 215 characters in length. 217 * The specification MUST specify a canonical representation. 219 * The specification of valid keys MUST be available over the 220 Internet and at no cost. 222 * The specification MUST be in the public domain or available via a 223 royalty-free license acceptable to the IETF and specified in the 224 RFC. 226 * The specification MUST be versioned, and each version of the 227 specification MUST be numbered, dated, and stable. 229 * The specification MUST be stable. That is, namespace keys, once 230 defined by a specification, MUST NOT be retracted or change in 231 meaning in any substantial way. 233 * The specification MUST include, in a separate section, the 234 registration form reproduced in this section (below) to be used in 235 registering the namespace upon publication as an RFC. 237 * IANA MUST be informed of changes to the contact information and 238 URL for the specification. 240 IANA will maintain a registry of allocated multi-character 241 namespaces. This registry MUST use the record-jar format described 242 by the ABNF in [BCP47]. Upon publication of a namespace as an RFC, 243 the maintaining authority defined in the RFC MUST forward this 244 registration form to , who MUST forward the 245 request to . The maintaining authority of the 246 namespace MUST maintain the accuracy of the record by sending an 247 updated full copy of the record to with the 248 subject line "TIMESTAMP FORMAT NAMESPACE UPDATE" whenever content 249 changes. Only the 'Comments', 'Contact_Email', 'Mailing_List', and 250 'URL' fields MAY be modified in these updates. 252 Failure to maintain this record, maintain the corresponding registry, 253 or meet other conditions imposed by this section of this document MAY 254 be appealed to the IESG [RFC2028] under the same rules as other IETF 255 decisions (see [RFC2026]) and MAY result in the authority to maintain 256 the extension being withdrawn or reassigned by the IESG. 258 %% 259 Identifier: 260 Description: 261 Comments: 262 Added: 263 RFC: 264 Authority: 265 Contact_Email: 266 Mailing_List: 267 URL: 268 %% 270 Figure 1: Registration record for a multi-character namespace 272 'Identifier' contains the multi-character sequence assigned to the 273 namespace. The Internet-Draft submitted to define the namespace 274 SHOULD specify which sequence to use, although the IESG MAY change 275 the assignment when approving the RFC. 277 'Description' contains the name and description of the namespace. 279 'Comments' is an OPTIONAL field and MAY contain a broader description 280 of the namespace. 282 'Added' contains the date the namespace's RFC was published in the 283 "date-full" format specified in Figure 2. For example: 2004-06-28 284 represents June 28, 2004, in the Gregorian calendar. 286 'RFC' contains the RFC number assigned to the namespace. 288 'Authority' contains the name of the maintaining authority for the 289 namespace. 291 'Contact_Email' contains the email address used to contact the 292 maintaining authority. 294 'Mailing_List' contains the URL or subscription email address of the 295 mailing list used by the maintaining authority. 297 'URL' contains the URL of the registry for this namespace. 299 The determination of whether an Internet-Draft meets the above 300 conditions and the decision to grant or withhold such authority rests 301 solely with the IESG and is subject to the normal review and appeals 302 process associated with the RFC process. 304 3.4. Syntax Extensions to RFC 3339 306 The following rules extend the ABNF syntax defined in [RFC3339] in 307 order to allow the inclusion of an optional suffix: the extended 308 date/time format is described by the rule date-time-ext. 310 time-zone-initial = ALPHA / "." / "_" 311 time-zone-char = time-zone-initial / DIGIT / "-" / "+" 312 time-zone-part = time-zone-initial *13(time-zone-char) 313 ; but not "." or ".." 314 time-zone-name = time-zone-part *("/" time-zone-part) 315 time-zone = "[" time-zone-name "]" 317 namespace = 1*alphanum 318 namespace-key = 1*alphanum 319 suffix-key = namespace ["-" namespace-key] 321 suffix-value = 1*alphanum 322 suffix-values = suffix-value *("-" suffix-value) 323 suffix-tag = "[" suffix-key "=" suffix-values "]" 324 suffix = [time-zone] *suffix-tag 326 date-time-ext = date-time suffix 328 alphanum = ALPHA / DIGIT 330 Figure 2: ABNF grammar of extensions to RFC 3339 332 3.5. Examples 334 Here are some examples of Internet extended date/time format. 336 1996-12-19T16:39:57-08:00 338 Figure 3: RFC 3339 date-time with timezone offset 340 Figure 3 represents 39 minutes and 57 seconds after the 16th hour of 341 December 19th, 1996 with an offset of -08:00 from UTC. Note that 342 this is the same instant in time as 1996-12-20T00:39:57Z, expressed 343 in UTC. 345 1996-12-19T16:39:57-08:00[America/Los_Angeles] 347 Figure 4: Adding a timezone name 349 Figure 4 represents the exact same instant as the previous example 350 but additionally specifies the human time zone associated with it 351 ("Pacific Time") for time-zone-aware implementations to take into 352 account. 354 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew] 356 Figure 5: Projecting to the Hebrew calendar 358 Figure 5 represents the exact same instant but it informs calendar- 359 aware implementations that they should project it to the Hebrew 360 calendar. 362 1996-12-19T16:39:57-08:00[x-foo=bar][x-baz=bat] 364 Figure 6: Adding tags in private use namespaces 366 Figure 6, based on Figure 3, utilizes the private use namespace to 367 declare two additional pieces of information in the suffix that can 368 be interpreted by any compatible implementations and ignored 369 otherwise. 371 4. IANA Considerations 373 Multi-character namespaces are assigned by IANA using the "IETF 374 Review" policy defined by [RFC8126]; the IETF review process needs to 375 be based on the requirements laid out in Section 3.3. 377 5. Security Considerations 379 TBD 381 6. References 383 6.1. Normative References 385 [BCP47] Phillips, A. and M. Davis, "Matching of Language Tags", 386 BCP 47, RFC 4647, September 2006. 388 Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 389 Languages", BCP 47, RFC 5646, September 2009. 391 393 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 394 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 395 . 397 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 398 the IETF Standards Process", BCP 11, RFC 2028, 399 DOI 10.17487/RFC2028, October 1996, 400 . 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 408 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 409 . 411 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 412 Specifications: ABNF", STD 68, RFC 5234, 413 DOI 10.17487/RFC5234, January 2008, 414 . 416 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 417 Writing an IANA Considerations Section in RFCs", BCP 26, 418 RFC 8126, DOI 10.17487/RFC8126, June 2017, 419 . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 422 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 423 May 2017, . 425 6.2. Informative References 427 [CLDR] "Unicode CLDR Project", . 429 [IERS] "International Earth Rotation Service Bulletins", 430 . 433 [ISO8601] International Organization for Standardization, "Data 434 elements and interchange formats — Information interchange 435 — Representation of dates and times", ISO 8601:1988, June 436 1988, . 438 [ITU-R-TF.460-6] 439 "ITU-R TF.460-6. Standard-frequency and time-signal 440 emissions", February 2002, 441 . 443 [JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter: 444 ISO_ZONED_DATE_TIME", 445 . 448 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 449 Specification, Implementation and Analysis", RFC 1305, 450 DOI 10.17487/RFC1305, March 1992, 451 . 453 Appendix A. Acknowledgements 455 TBD 457 Authors' Addresses 459 Ujjwal Sharma 460 Igalia, S.L. 461 Bugallal Marchesi, 22, 1º 462 15008 A Coruña 463 Spain 465 Email: ryzokuken@igalia.com 466 Carsten Bormann 467 Universität Bremen TZI 468 Postfach 330440 469 D-28359 Bremen 470 Germany 472 Phone: +49-421-218-63921 473 Email: cabo@tzi.org