--On Wednesday, June 14, 2023 11:15 +0200 Carsten Bormann <cabo@xxxxxxx> wrote: > 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). Three observations: First, RFC 3339 was intended to be a profile of ISO 8601. This specification takes it out of that category, even wrt ISO 8601:1988. Even if there were no "newer version" issues, that should require some more careful documentation and explanation, not just "we are still referencing the old version". Second, and in line with my BGP comment, if you want to reference the old version (and expect the community to endorse that), I believe you need to be explicit as to why, not just reference the old version via a reference anchor. I think "why" needs to be a bit more specific than "meandered away" too. Again consider the BGP analogy. If that hypothetical other SDO said "we think the IETF got it wrong with BGP4 and are basing our work on the 1990 version instead", we wouldn't like it, but we should not consider ourselves above such criticism (especially if the reasons are spelled out). On the other hand, simply basing work on RFC 1163 without comments would just look like ignorance or stupidity. Finally, as I think also came up in the August discussion you mention below, we have long-standing policies that a WG can consider, and choose between, different approaches to a problem based on whether one is proprietary (e.g., requires licensing and probably payment) and other is free even if the latter may be technologically inferior. However, I'd not aware that we have ever made that choice between versions of the same standard based on whether the older one is more accessible because copies are available on the web that have not been taken down. IMO, making that argument would be a significant policy change. YMMD, but, either way, it reinforces my view that an explicit and careful explanation should be in the document and should have IETF consensus. > 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-e > xtended/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-DFWB3U1oF > hkVI-QEih0Q> ). Per that discussion (and as now mentioned at that Github link), if a link to the FIPS publication were added to the one to the ISO page, with a comment like "still available at", it would considerably mitigate my concern. However, see above. If you don't want to get involved with that policy discussion about paywalls (and risk a community bikeshed tour on the principles), probably you don't want to include it in the explanation. >> (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-e > xtended/pull/44/files And that proposed fix clarifies that neither of my interpretations (the convention in RFC 2822 or than in RFC 5322) was intended but that only the RFC 3339 one was at issue. That definitely helps. >> 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. While the proposed fix (on the Github page) probably solves the problem, the above didn't answer my question at all, reinforcing the idea that the old text was confusing. >> 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... Unless that comment applies only to the quoted text (rather than the whole section or even just everything starting with "Then, in the next...") and maybe even then, IMO, not a good answer and unfair to the RPC. When there are different possible interpretations of a given bit of text, handing things off to the RPC that way invites a situation in which they ask the authors (and maybe an AD) what the text is supposed to mean, get an answer, and implement it... even though there is a plausible chance that result may not represent IETF consensus because much of the IETF interpreted it differently (or glazed over and didn't comment). >> "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. I have no doubt that Section 2 is needed. I was (and am) just having trouble being confident I know what it is intended to say. >> 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*. Again, I agree that the section is needed. My problem is that, at least absent your explanation above, I don't think it is comprehensible ... again to the point that handing this to the RPC in this form would be unfair to them and risk publication of a document that does not actually represent community consensus. So, as an editorial matter -- but one with substantive impact-- consider splitting Section 2 into two or three subsections: Section 2.1: The actual change, i.e., the former paragraph 4 with, I hope, a bit of clarification (which might come out of paragraph 1). In the interest of clarity, I'd prefer that you actually say "3399 says '<quoted text'> and this changes that to '<quoted new text>'" but that is slightly more an editorial matter than the principle I'm trying to push. Section 2.2: History and context: versions of paragraphs 2, 3, and possibly 5. Section 2.3: Transition and interoperability issues: A variation on paragraph 6, not as "note also" but as a statement that incorporates some of what you say above. Or maybe 2.2 and 2.3 could be folded together because the main goal is to make the actual change clear. However, the more I think about it, the more I think they should be separate and that the process of organizing things into those three subsections would be likely to result in additional clarification. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
