Draft: draft-ietf-sedate-datetime-extended

Commentary: 5 h left ... 
 (   ) 
 Apologies for the late review , LGTM .
separated by an equals sign.  The key of a tag can be split into two
parts by including a hyphen/minus sign ""-""; the first part
(including the ""-"") can then be used as a namespace.  The value of
a tag can be one or more items delimited by hyphen/minus signs.
The format is intended to allow implementations to specify additional
important information in addition to the bare timestamp.
separated by an equals sign.  The value of a tag can be one or more
items delimited by hyphen/minus signs.
For example, if ""u-"" is a namespace for the Unicode Consortium, a
calendar as defined by that organization could be included as
"u-ca=<value>".
"u-" for keys defined by the Unicode Consortium.
"x-" for keys used within experiments.  Such keys are not for
general interchange and MUST be rejected by a recipient unless
that is specifically enabled for an experiment.  See RFC6648 for
additional considerations about "x-" namespaces.
There must be a "namespace-key" and it is restricted to 2
"alphanum" characters.
A "suffix-value" is limited to "3*8alphanum".
Additional namespaces can be registered under an Expert review
policy, providing a description for the intended use.  This may be a
general concept, or a specific organization that is intended to
register keys within this namespace.
'Identifier' contains the key name.  A key name ending with a hyphen/
minus sign ""-"" is a namespace that covers all timestamp tag keys
beginning with that prefix.
'Description' contains the name and description of the namespace.
'Comments' is an OPTIONAL field and MAY contain a broader description
of the namespace.
'Added' contains the date the key's definition was published in the
"date-full" format specified in grammar.  For example: 2004-06-28
represents June 28, 2004, in the Gregorian calendar.
'RFC' contains the RFC number assigned to the namespace.
'Authority' contains the name of the maintaining authority for the
namespace.
'Contact_Email' contains the email address used to contact the
maintaining authority.
'Mailing_List' contains the URL or subscription email address of the
mailing list used by the maintaining authority.
'URL' contains the URL of the registry for this namespace.
Actual suffix tag keys are registered by supplying the information
specified in this section.  This information is modeled after that
specified for the media type registry RFC6838; if in doubt, the
provisions of this registry should be applied analogously.
Key names that start with an underscore are intended for experiments
in controlled environments and cannot be registered; such keys MUST
NOT be used for interchange and MUST be rejected by implementations
not specifically configured to take part in such an experiment.  See
BCP178 for a discussion about the danger of experimental keys leaking
out to general production and why that MUST be prevented.
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.
IANA is requested to establish a registry called "Timestamp Suffix
Tag Keys".  Each entry in the registry shall consist of the
information described in registered.  Initial contents of the
registry are specified in namespaced.
The policy is "RFC required", "Specification Required", ??? RFC8126.
date-time-private, based on rfc3339-datetime, utilizes keys
identified as experimental by a leading underscore to declare two
additional pieces of information in the suffix; these can be
interpreted by implementations that take part in the controlled
experiment making use of these tag keys.
IANA is requested to establish a registry called "Timestamp Suffix
Tag Keys".  Each entry in the registry shall consist of the
information described in registered.  Initial contents of the
registry are specified in registered.
The registration policy RFC8126 is "Specification Required" for
permanent entries, and "Expert Review" for provisional ones.  In the
second case, the expert is instructed to ascertain that a basic
specification does exist, even if not complete or published yet.