Second installment... > (1) ISO 8601 is a very widely adopted and used International > Standard. In addition to the sorts of uses that can reasonably > be expected to show up in contexts related to Internet protocols > (and the Java time format work), it is heavily used in the > notations of a number of scientific fields and incorporated into > regulations in some countries. While I have no problem at all > with the IETF extending 8601 in a way that is compatible with > that standard and how it might evolve, there is little or no > evidence in the document that serious consideration was given to > that issue. In particular, the document's references to ISO > 8601 are to the long-obsolete and withdrawn 1988 version of that > document and not to the current one(s) (the URL given in the > reference for [ISO8601:1988] leads to a page that says " Status: > Withdrawn" and does not even point to a current document). For > reasons that closely parallel some of the recent RSWG > discussions about obsolete references and links, this document > should either reference the current version of ISO 8601 and > explain why the extension syntax chosen is unlikely to cause > conflicts in the future or should carefully and respectfully > explain why not. If necessary, consider how the IETF would > react if some other SDO (possibly even an ISO subgroup) > referenced RFC 1163 and suggested it represented the IETF's > latest thinking on BGP and its use. I do not agree. While ISO 8601 has been revised considerably, it has meandered away from the original work that made it the natural basis of RFC 3339. We are referencing that old edition on purpose (as is reflected in the reference anchor). However, you point us to one flaw with doing so: The first edition of ISO 8601 that unambiguously outlawed -00:00 was the 2000 edition. So we have to be more careful in Section 2. Now https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/48 (Note that referencing a newer version would also erect a paywall that would hamper review; please remind yourself of the discussion we had around Archived-At: <https://mailarchive.ietf.org/arch/msg/sedate/bvn8eA-DFWB3U1oFhkVI-QEih0Q> ). > (2) Parts of the document are very confusing, to the point that > it is not clear what is being specified. Take Section 2 as an > example. The second paragraph includes "The latter convention > is in actual use, while the former always was handicapped...". To be fixed via https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/44/files > But the previous sentence points to RFC 5322 first and then to > RFC 2822. Is it the later spec (5322) that is "in actual use" > or is the earlier spec, listed second? And what does "in actual > use" mean? It means yours truly found several hundred email messages on his laptop that use -00:00. Whether that usage was critical for those messages is hard to say, of course. > There has been enough diversity in email systems, > especially various flavors of MUAs, that it is reasonable to > assume that someone, somewhere, implemented whatever 2822 or > 5322 specified. Then, in the next paragraph, the text goes on > to describe how, in the opinion of the authors (and, I presume, > the WG) "Z" has been used and then, in the one after says that > "Z" should now be interpreted differently. But then the last two > paragraphs of the section say that the old use is not deprecated > and then says "For the intents and purposes of the present > specification," (rather awkward English) I hope the RFC editor will help... > "the local offset Z can > be used in its place". That would seem to imply that we are > back to treating Z as a synonym for "-00:00" while the prior > paragraph starting "This specification updates..." seems to > imply that "Z" implies +00:00, which is consistent with most > international usage that allows single-letter time zone > indications. Single-letter time zone indications have never been a part of the RFC 3339 legacy. Z has been, but with different semantics in practice than specified. Hence Section 2. > It must be possible to write that section in a way that is > clear, that specifies how "Z" is to be interpreted, and that > identifies exactly what is being changed in 3339. If the rest > of the section is intended to provide historical context, then > separate that out and identify it as such. Indeed, some more editorial work would probably help (see also Joe Clarke’s comments). The problem with acknowledging changes like this is that these will have limited interoperability for quite some time: There might be implementations that actually do implement the specified semantics, and these do not get wrong suddenly, they now just have their limited interoperability documented. So we do need the discussion (which only amounts to less than a page). The fourth paragraph is the actual change (i.e., it says what that change is); the rest is just needed to help people understand what that change then *means*. Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
