Change:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.

Discussion:
Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- adopted timestamp format, which forms the basis of RFC3339.  However, <del> this format doesn't allow timestamps to contain any additional relevant information, which means that any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </del> <ins> this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </ins> This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account

timezone to the timestamp in a non-standard format, at least one of which is fairly well-adopted JAVAZDT.  Furthermore, applications might want to attach even more information to the timestamp, <del> including but not limited to the calendar system it must be </del> <ins> including but not limited to the calendar system it needs to be </ins> represented in. This document defines an extension syntax for timestamps as specified

The extension suffix is completely optional, making existing RFC3339 timestamps compatible with this format. <del> The format is compatible to the pre-existing popular syntax for </del> <ins> The format is compatible with the pre-existing popular syntax for </ins> attaching time zone names to timestamps (JAVAZDT). <del> The format provides generalized way to attach any additional </del> <ins> The format provides a generalized way to attach any additional </ins> information to the timestamp. 2.

BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> For more information about time scales, see Appendix E of RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITURTF460-6. </del> <ins> For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6. </ins> 3.

The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is <del> done by allowing implementations to include an informative suffix at the end with as many tags as required, each with a key and value separated by an equals sign.  The value can be a hyphen delimited list of multiple values. </del> <ins> done by defining , each with a and a separated by an equals sign, and allowing implementations to include an informative at the end with as many tags as required.  The value of a tag can be a hyphen delimited list of multiple values. </ins> In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. 3.2. <del> Since the suffix can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards.  For this, all information needs to be namespaced.  Each key is therefore divided into two hyphen- separated sections: the namespace and the key.  For example, the calendar as defined by the Unicode consortium could be included as </del> <ins> Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards.  For this, all information needs to be namespaced.  Each key is therefore divided into two hyphen-separated sections: the namespace and the key.  For example, the calendar as defined by the Unicode consortium could be included as </ins> "u-ca=<value>". All single-character namespaces are reserved for BCP47 extensions

A "suffix-value" is limited to "3*8alphanum". <ins> 3.3. </ins> Multi-character namespaces can be registered specifically for use in <del> this format.  They are assigned by IANA using the "IETF Review" policy defined by RFC8126.  This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags.  The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC.  The RFC MUST specify or include each of the following: </del> <ins> this format, see iana-cons.  The registration policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the tags using the namespace registered. (This subsection uses BCP 14 language to describe the requirements on the information interchanged indirectly by providing requirements on the RFC registering a namespace and the principles of its evolution.) The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC.  The RFC MUST specify each of the following (directly or included by reference): </ins> The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this

IANA will maintain a registry of allocated multi-character namespaces.  This registry MUST use the record-jar format described <del> by the ABNF in RFC5646.  Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this </del> <ins> by the ABNF in BCP47.  Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this </ins> registration form to <<mailto:iesg@ietf.org>>, who MUST forward the request to <<mailto:iana@iana.org>>.  The maintaining authority of the namespace MUST maintain the accuracy of the record by sending an

solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. <del> 3.3. </del> <ins> 3.4. </ins> The following rules extend the ABNF syntax defined in RFC3339 in <del> order to allow the inclusion of an optional suffix. </del> <ins> order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext". </ins> <del> 3.4. </del> <ins> 3.5. </ins> Here are some examples of Internet extended date/time format. <del> This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note that this is equivalent to 1996-12-20T00:39:57Z in UTC. </del> <ins> rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note that this is the same instant in time as "1996-12-20T00:39:57Z", expressed in UTC. datetime-tzname represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. date-time-hebrew represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar. date-time-private, based on rfc3339-datetime, utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. 4. </ins> <del> This represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. </del> <ins> Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char. </ins> <del> This represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar. </del> <ins> 5. </ins> <del> This timestamp utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. </del> <ins> TBD </ins>