idnits 2.17.1 draft-ietf-sedate-datetime-extended-00.txt: -(350): 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 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 24 characters in excess of 72. ** The abstract seems to contain references ([RFC3339]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 August 2021) is 984 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) == Missing Reference: 'RFC5226' is mentioned on line 178, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 16 August 2021 5 Expires: 17 February 2022 7 Date and Time on the Internet: Timestamps with additional information 8 draft-ietf-sedate-datetime-extended-00 10 Abstract 12 This document defines an extension to the timestamp format defined in 13 [RFC3339] for representing additional information including a time 14 zone. 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 17 February 2022. 33 Copyright Notice 35 Copyright (c) 2021 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 (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Extended Date and Time format . . . . . . . . . . . . . . . . 3 52 3.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.2. Namespaced . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.3. Syntax Extensions to RFC3339 . . . . . . . . . . . . . . 7 55 3.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4. Normative References . . . . . . . . . . . . . . . . . . . . 8 57 5. Informative References . . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 60 1. Introduction 62 Dates and times are used in a very diverse set of internet 63 applications, all the way from server-side logging to calendaring and 64 scheduling. 66 Each distinct instant in time can be represented in a descriptive 67 text format using a timestamp, and [ISO8601] standardizes a widely- 68 adopted timestamp format, which forms the basis of [RFC3339]. 69 However, this format doesn't allow timestamps to contain any 70 additional relevant information, which means that any contextual 71 information related to a given timestamp needs to be either handled 72 separately or attached to it in a non-standard manner. 74 This is already a pressing issue for applications that handle each 75 instant with an associated time zone name, to take into account 76 things like DST transitions. Most of these applications attach the 77 timezone to the timestamp in a non-standard format, atleast one of 78 which is fairly well-adopted ([JAVAZDT]). Furthermore, applications 79 might want to attach even more information to the timestamp, 80 including but not limited to the calendar system it must be 81 represented in. 83 This document defines an extension syntax for timestamps as specified 84 in [RFC3339] that has the following properties: 86 * The extension suffix is completely optional, making existing 87 [RFC3339] timestamps compatible with this format. 89 * The format is compatible to the pre-existing popular syntax for 90 attaching time zone names to timestamps ([JAVAZDT]). 92 * The format provides generalized way to attach any additional 93 information to the timestamp. 95 2. Definitions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 UTC Coordinated Universal Time as maintained since 1988 by the 102 Bureau International des Poids et Mesures (BIPM) in conjunction 103 with leap seconds as announced by the International Earth Rotation 104 and Reference Frames Service [IERS]. From 1972 through 1987 UTC 105 was maintained entirely by Bureau International de l'Heure (BIH). 106 Before 1972 UTC was not generally recognized and civil time was 107 determined by individual jurisdictions using different techniques 108 for attempting to follow Universal Time based on measuring the 109 rotation of the earth. 111 ABNF Augmented Backus-Naur Form, a format used to represent 112 permissible strings in a protocol or language, as defined in 113 [RFC2234]. 115 Internet Date/Time Format The date/time format defined in section 3 116 of this document. 118 Timestamp This term is used in this document to refer to an 119 unambiguous representation of some instant in time. 121 Z A suffix which, when applied to a time, denotes a UTC offset of 122 00:00; often spoken "Zulu" from the ICAO phonetic alphabet 123 representation of the letter "Z". 125 Time Zone A time zone that is a included in the Time Zone Database 126 (often called "tz" or "zoneinfo") maintained by IANA. 128 For more information about time scales, see Appendix E of [RFC1305], 129 Section 3 of [ISO8601], and the appropriate ITU documents 130 [ITURTF460-6]. 132 3. Extended Date and Time format 134 This section discusses desirable qualities of formats for the 135 timestamp extension suffix and defines such a format that extends 136 [RFC3339] for use in Internet protocols. 138 3.1. Informative 140 The format should allow implementations to specify additional 141 important information in addition to the bare timestamp. This is 142 done by allowing implementations to include an informative suffix at 143 the end with as many tags as required, each with a key and value 144 separated by an equals sign. The value can be a hyphen delimited 145 list of multiple values. 147 In case a key is repeated or conflicted, implementations MUST give 148 precedence to whichever value is positioned first. 150 3.2. Namespaced 152 Since the suffix can include all sorts of additional information, 153 different standards bodies/organizations need a way to identify which 154 part adheres to their standards. For this, all information needs to 155 be namespaced. Each key is therefore divided into two hyphen- 156 separated sections: the namespace and the key. For example, the 157 calendar as defined by the Unicode consortium could be included as 158 "u-ca=". 160 All single-character namespaces are reserved for BCP47 extensions 161 recorded in the BCP47 extensions registry. For these namespaces: 163 * Case differences are ignored. 165 * The namespace is restricted to single alphanum, corresponding to 166 extension singletons ('x' can be used for a private use 167 extension). 169 * In addition, for CLDR extensions: 171 - There must be a "namespace-key" and it is restricted to 2 172 "alphanum" characters. 174 - A "suffix-value" is limited to "3*8alphanum". 176 Multi-character namespaces can be registered specifically for use in 177 this format. They are assigned by IANA using the "IETF Review" 178 policy defined by [RFC5226]. This policy requires the development of 179 an RFC, which SHALL define the name, purpose, processes, and 180 procedures for maintaining the subtags. The maintaining or 181 registering authority, including name, contact email, discussion list 182 email, and URL location of the registry, MUST be indicated clearly in 183 the RFC. The RFC MUST specify or include each of the following: 185 * The specification MUST reference the specific version or revision 186 of this document that governs its creation and MUST reference this 187 section of this document. 189 * The specification and all keys defined by the specification MUST 190 follow the ABNF and other rules for the formation of keys as 191 defined in this document. In particular, it MUST specify that 192 case is not significant and that keys MUST NOT exceed eight 193 characters in length. 195 * The specification MUST specify a canonical representation. 197 * The specification of valid keys MUST be available over the 198 Internet and at no cost. 200 * The specification MUST be in the public domain or available via a 201 royalty-free license acceptable to the IETF and specified in the 202 RFC. 204 * The specification MUST be versioned, and each version of the 205 specification MUST be numbered, dated, and stable. 207 * The specification MUST be stable. That is, namespace keys, once 208 defined by a specification, MUST NOT be retracted or change in 209 meaning in any substantial way. 211 * The specification MUST include, in a separate section, the 212 registration form reproduced in this section (below) to be used in 213 registering the namespace upon publication as an RFC. 215 * IANA MUST be informed of changes to the contact information and 216 URL for the specification. 218 IANA will maintain a registry of allocated multi-character 219 namespaces. This registry MUST use the record-jar format described 220 by the ABNF in [RFC5646]. Upon publication of a namespace as an RFC, 221 the maintaining authority defined in the RFC MUST forward this 222 registration form to , who MUST forward the 223 request to . The maintaining authority of the 224 namespace MUST maintain the accuracy of the record by sending an 225 updated full copy of the record to with the 226 subject line "TIMESTAMP FORMAT NAMESPACE UPDATE" whenever content 227 changes. Only the 'Comments', 'Contact_Email', 'Mailing_List', and 228 'URL' fields MAY be modified in these updates. 230 Failure to maintain this record, maintain the corresponding registry, 231 or meet other conditions imposed by this section of this document MAY 232 be appealed to the IESG [RFC2028] under the same rules as other IETF 233 decisions (see [RFC2026]) and MAY result in the authority to maintain 234 the extension being withdrawn or reassigned by the IESG. 236 %% 237 Identifier: 238 Description: 239 Comments: 240 Added: 241 RFC: 242 Authority: 243 Contact_Email: 244 Mailing_List: 245 URL: 246 %% 248 'Identifier' contains the multi-character sequence assigned to the 249 namespace. The Internet-Draft submitted to define the namespace 250 SHOULD specify which sequence to use, although the IESG MAY change 251 the assignment when approving the RFC. 253 'Description' contains the name and description of the namespace. 255 'Comments' is an OPTIONAL field and MAY contain a broader description 256 of the namespace. 258 'Added' contains the date the namespace's RFC was published in the 259 "date-full" format specified in Section 3.3. For example: 2004-06-28 260 represents June 28, 2004, in the Gregorian calendar. 262 'RFC' contains the RFC number assigned to the namespace. 264 'Authority' contains the name of the maintaining authority for the 265 namespace. 267 'Contact_Email' contains the email address used to contact the 268 maintaining authority. 270 'Mailing_List' contains the URL or subscription email address of the 271 mailing list used by the maintaining authority. 273 'URL' contains the URL of the registry for this namespace. 275 The determination of whether an Internet-Draft meets the above 276 conditions and the decision to grant or withhold such authority rests 277 solely with the IESG and is subject to the normal review and appeals 278 process associated with the RFC process. 280 3.3. Syntax Extensions to [RFC3339] 282 The following rules extend the ABNF syntax defined in [RFC3339] in 283 order to allow the inclusion of an optional suffix. 285 time-zone-char = ALPHA / "." / "_" 286 time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".." 287 time-zone-name = time-zone-part *("/" time-zone-part) 288 time-zone = "[" time-zone-name "]" 290 namespace = 1*alphanum 291 namespace-key = 1*alphanum 292 suffix-key = namespace ["-" namespace-key] 294 suffix-value = 1*alphanum 295 suffix-values = suffix-value *("-" suffix-value) 296 suffix-tag = "[" suffix-key "=" suffix-values "]" 297 suffix = [time-zone] *suffix-tag 299 date-time-ext = date-time suffix 301 3.4. Examples 303 Here are some examples of Internet extended date/time format. 305 1996-12-19T16:39:57-08:00 307 This represents 39 minutes and 57 seconds after the 16th hour of 308 December 19th, 1996 with an offset of -08:00 from UTC. Note that 309 this is equivalent to 1996-12-20T00:39:57Z in UTC. 311 1996-12-19T16:39:57-08:00[America/Los_Angeles] 313 This represents the exact same instant as the previous example but 314 additionally specifies the human time zone associated with it 315 ("Pacific Time") for time-zone-aware implementations to take into 316 account. 318 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew] 320 This represents the exact same instant but it informs calendar-aware 321 implementations that they should project it to the Hebrew calendar. 323 1996-12-19T16:39:57-08:00[x-foo=bar][x-baz=bat] 325 This timestamp utilizes the private use namespace to declare two 326 additional pieces of information in the suffix that can be 327 interpreted by any compatible implementations and ignored otherwise. 329 4. Normative References 331 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 332 Specifications: ABNF", RFC 2234, IETF RFC 2234, 333 DOI 10.17487/RFC2234, November 1997, 334 . 336 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 337 Specification, Implementation and Analysis", RFC 1305, 338 IETF RFC 1305, DOI 10.17487/RFC1305, March 1992, 339 . 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", RFC 2119, IETF RFC 2119, 343 DOI 10.17487/RFC2119, March 1997, 344 . 346 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 347 Languages", RFC 5646, IETF RFC 5646, DOI 10.17487/RFC5646, 348 September 2009, . 350 [RFC2026] Bradner, S., "The Internet Standards Process — Revision 351 3", RFC 2026, IETF RFC 2026, DOI 10.17487/RFC2026, October 352 1996, . 354 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 355 the IETF Standards Process", RFC 2028, IETF RFC 2028, 356 DOI 10.17487/RFC2028, October 1996, 357 . 359 5. Informative References 361 [ISO8601] International Organization for Standardization, "Data 362 elements and interchange formats", ISO 8601:1988, June 363 1988, . 365 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 366 Timestamps", RFC 3339, IETF RFC 3339, 367 DOI 10.17487/RFC3339, July 2002, 368 . 370 [ITURTF460-6] 371 "ITU-R TF.460-6. Standard-frequency and time-signal 372 emissions". 374 [IERS] "International Earth Rotation Service Bulletins", 375 . 378 [JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter: 379 ISO_ZONED_DATE_TIME", 380 . 383 Author's Address 385 Ujjwal Sharma 386 Igalia, S.L. 387 Bugallal Marchesi, 22, 1º 388 15008 A Coruña 389 Spain 391 Email: ryzokuken@igalia.com