--On Tuesday, October 18, 2022 18:13 +0200 Carsten Bormann
<[email protected]> wrote:
>...
> OK, I casually looked at this in a corpus of email headers I
> happened to have lying around and only occasionally found
> -00:00, but it indeed is in actual use. This is data for the
> email header date format, which is unrelated to ISO 8601 and
> therefore does not suffer from compatibility issues with ISO
> 8601.
>
> Whoever invented the adaptation of -00:00 to the RFC 3339
> format did not have a copy of ISO 8601, did not bother to
> look, or didn't think that the resulting incompatibility
> would be a problem in practice. Turns out, it actually is.
More or less arbitrarily responding to this message rather than
one of the later ones, a few comments that are nearly separate
from each other.
(1) The language in RFC 5322 that describes the interpretation
of -00:00 (actually "-0000" in those specs -- while 8601 makes
the colon optional, 3339 requires it) and rules about it are
under review in EMAILCORE. If people have opinions about that,
please review those discussions and please, please, do not do
anything in SEDATE that would produce the possibility of a
conflicting definition between the two IETF specs.
(2) The discussion of the bad effects of standards that can
legally be obtained only at high prices is old news. Aspects of
the interactions of those policies with the Internet and its
development go back at least to Carl Malamud's efforts (starting
three decades or more ago) and publication of critical excerpts
of such standards in the RFC series even earlier, in the 1960s
(see, e.g., RFC 20). Largely (IMO) as a result of those
efforts, many documents that would have been available only at
high purchase prices years ago are now free even if others are
not. At least part of the problem is that SDOs like ISO have
not been able to figure out a better business model: there have
been few people in the leadership of those organizations in
recent years who believe that charging enough for standards to
prevent people from studying them is a good idea. Just my
opinion, but reinventing or rehashing those arguments is not a
good use of time and energy in this WG.
(3) We are, however, supposed to be about interoperability and
reality. ISO 8601 is very widely used in many contexts that
interact with the Internet. I hope we all agree that pretending
it could be safely ignored would be a terrible idea. Arguably,
we have RFC 3339 just because of the tradeoffs between
developing an IETF-exclusive spec, technical and financial
issues with ISO 8601, and places where 8601 allowed too much
flexibility for good interoperation (in ISO-speak, that is what
"profiles" are about).
(4) I don't remember the full history of RFC 3339, but assume
that the -00:00 convention was introduced for easy and accurate
transcoding from email date-times, notably that specified in RFC
2822. Unless someone actually has memories or documentation to
the contrary, it is not reasonable to assume that the
incompatibility with ISO 8601 was a mistake or due to "not
having a copy of" that spec. It is at least as likely that, had
everyone involved in 3339's development had ISO 8601 in front of
them, that provision for "-00:00" would have been put in anyway.
(4) I believe that there are at least two important lessons for
SEDATE in the above. First, extending ISO 8601:2019 and its
various parts where we can demonstrate and explain clear needs
is reasonable, especially when those extensions can be as
compatible as possible _and_ we document where we are extending
things (in retrospect, I believe 3339 failed in the latter
regard even though there is a good deal of information in the
opening paragraphs of Appendix A). Second, at an appropriate
time but certainly no later than when SEDATE's work is approved
for publication, we carefully and respectfully explain to ISO/TC
154/WG 5 (not just to some member of, or liaison to, them) what
extended functionality we concluded was needed, why, and the
extensions we specified as a result. Assuming they behave
reasonably, they might consider adding our extensions to a
future version of 8601-2 or at least avoid future extensions
with the same syntax but different definitions.
thanks,
john
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
