Hi John, thank you for providing some more detail about your considerations. > On 2023-06-14, at 17:52, John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --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. Yes, and that intention is a bit broken by the fact that -00:00 is defined by RFC 3339 but not allowed by ISO 8601:2000 and newer. > This specification takes it out of that category, > even wrt ISO 8601:1988. The update in Section 2 actually puts RFC 3339 back into that category. The new functionality in Section 3 and following is not updating RFC 3339 and has no relationship to ISO 8601. > 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". I generally try to avoid trying to get consensus on explanations of decisions where the explanation is more controversial than the decision. So unless you have a very, *very* strong reason to include that explanation, I’d like to pass. > 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. See above. The main reason is that the RFC 3339 profile of ISO 8601 does not need anything from the newer editions. > 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. Well, BGP2 is obviously different from BGP4, so I don’t understand the analogy. > 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. Oh. These rules are specifically about patent claims. The problems with paywalls are copyright problems. (Yes, I know that these legal fictions are often lumped together by legal practitioners as “IPR”, but in the IETF “IPR” surprisingly means patent claims only in almost all cases.) > 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. The choice was about the reference, not about the content. I would argue that, with RFC 3339, we spun out of the mold of ISO 8601, so what happened there afterwards is really irrelevant to RFC 3339. > 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. See above. >> 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. OK, I added this to the github issue. > 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. Exactly. >>> "For the intents and purposes >>> of the present specification," (rather awkward English) >> >> I hope the RFC editor will help... … with the awkward English, I meant. > 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. This is a great idea, except that I’d do the background (your 2.2) before the update (your 2.1). Now https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/49 Thank you! Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
