Draft: draft-ietf-sedate-datetime-extended

Commentary: 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 .  ,  
 ( 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 could n’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 .  ,    , 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 ,  was not making my life any easier .
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,
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.
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,
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.
This is already a pressing issue for applications that handle each
instant with an associated time zone name, to take into account
things like DST transitions.  Most of these applications attach the
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,
including but not limited to the calendar system it must be
represented in.
This is already a pressing issue for applications that handle each
instant with an associated time zone name, to take into account
things like DST transitions.  Most of these applications attach the
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,
including but not limited to the calendar system it needs to be
represented in.
The format is compatible to the pre-existing popular syntax for
attaching time zone names to timestamps (JAVAZDT).
The format provides generalized way to attach any additional
information to the timestamp.
The format is compatible with the pre-existing popular syntax for
attaching time zone names to timestamps (JAVAZDT).
The format provides a generalized way to attach any additional
information to the timestamp.
For more information about time scales, see Appendix E of RFC1305,
Section 3 of ISO8601, and the appropriate ITU documents ITURTF460-6.
For more information about time scales, see RFC1305, Section 3 of
ISO8601, and the appropriate ITU documents ITU-R-TF.460-6.
The format should allow implementations to specify additional
important information in addition to the bare timestamp.  This is
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.
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
"u-ca=<value>".
at the end with as many tags as required.  The value of a tag can be
a hyphen delimited list of multiple values.
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
"u-ca=<value>".
Multi-character namespaces can be registered specifically for use in
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.
IANA will maintain a registry of allocated multi-character
namespaces.  This registry MUST use the record-jar format described
by the ABNF in RFC5646.  Upon publication of a namespace as an RFC,
the maintaining authority defined in the RFC MUST forward this
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
updated full copy of the record to <<mailto:iana@iana.org>> with the
subject line "TIMESTAMP FORMAT NAMESPACE UPDATE" whenever content
changes.  Only the 'Comments', 'Contact_Email', 'Mailing_List', and
'URL' fields MAY be modified in these updates.
IANA will maintain a registry of allocated multi-character
namespaces.  This registry MUST use the record-jar format described
by the ABNF in BCP47.  Upon publication of a namespace as an RFC, the
maintaining authority defined in the RFC MUST forward this
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
updated full copy of the record to <<mailto:iana@iana.org>> with the
subject line "TIMESTAMP FORMAT NAMESPACE UPDATE" whenever content
changes.  Only the 'Comments', 'Contact_Email', 'Mailing_List', and
'URL' fields MAY be modified in these updates.
The following rules extend the ABNF syntax defined in RFC3339 in
order to allow the inclusion of an optional suffix.
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.
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.
This represents the exact same instant but it informs calendar-aware
implementations that they should project it to the Hebrew calendar.
The following rules extend the ABNF syntax defined in RFC3339 in
order to allow the inclusion of an optional suffix: the extended
date/time format is described by the rule "date-time-ext".
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.
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.