Carsten,
Thanks. I think we are converging, but are not there yet.
--On Wednesday, June 14, 2023 18:20 +0200 Carsten Bormann
<cabo@xxxxxxx> wrote:
> 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.
If that is the reason for the pointer to the earlier version,
then I expect to see a sentence or two that says, approximately,
"This is no longer a profile of ISO 8601 because they
departed from a feature we are using ("-00:00"),
prohibiting it in 2000 [ISO8601:2000] and later versions
and because this document extends the basic ISO 8601
framework in ways that, while not believed to be
incompatible today might become so in the future."
If I correctly understand what you are saying, I think that is
the truth and that we should not be shy about saying it.
Certainly it does not say anything that could be taken as
insulting like "meandering away" (see below).
>> 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.
Again, the document would be easier to read and understand if
that were said explicitly. I.e., we started from 8601 and
forked and that compatible relationships with 8601 are not to be
expected. (But see last paragraph.)
>> 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.
See below.
>> 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.
But, from ISO's perspective, that is not a good reason to avoid
referencing the most up-to-date (and only current) version of
the standard. Unlike our use of "Historic", which we have
declined to precisely define, "Withdrawn" in ISO-speak does have
a precise definition and we should not be referencing it in any
way that implies conformance. If you can get closer to
"inspired by" (see above and below), there is much less of a
problem.
>> 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.
I believe our colleagues at ISO would say that 8601-1:2019
(including ISO 8601-1:2019/Amd 1:2022) and 8601-2:2019 are
obviously different from 8601:1988, so they don't understand why
you 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.)
I would like to avoid going down that rathole if possible, but
the fact remains that, AFAICT, you are creating a new policy.
>> 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.
Well, plus or minus the -00:00 issue, 3339 is presented as a
profile --proper subset-- of 8601 not "spinning out of the
mold". That is at least part of the reason why some of us
insisted on this document updating 3339. So the present
document either cleanly extends 8601 (which, today, means the
2019 version) or constitutes a fork that heads off in another
direction. "Clearly extends" requires obtaining the current
documents (which I believe I've told the WG and AD how to do)
and doing an analysis. Forking doesn't but has other
implications (see below). Either way, just say what you are
doing rather than introducing confusion by making assertions
about spinning out of molds.
>> 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-DFWB3U1
>>> oF 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.
Thanks.
>> 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.
Ok, but it seems to me that the argument for referencing
8601:1988 and completely ignoring the existence of the 2019
version (and everything in between) thereby gets a bit harder.
>>>> "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-e
> xtended/issues/49
While I prefer the order I suggested, I don't think it is worth
an argument or even the time it would take to explain why. So,
as long as those three subsections are clearly identified, I can
live with it.
-----
"below", ISO standards, and very strong reasons:
We may disagree about this (and probably do), but at least I can
try to explain where I'm coming from... Just as I think it is
important that we try within the IETF to treat each other with
respect I think it is important to treat other Standards Bodies
with respect. That is especially important in areas where they,
and their standards, are far more established and recognized
than ours. While I think we should still behave respectfully,
things would be a bit different if someone came along and, e.g.,
tried to replace TCP/IP with WBNETECP (Whiz-Bang New End To End
Circuit Protocol). However, this is not one of those cases and
that leads to a rather pragmatic issue as distinct from the more
philosophical ones:
date-time information, especially as embodied in ISO 8601, is
not an IETF protocol over which the IETF can reasonably be
expected to dictate implements by saying, e.g., "for the
Internet". As a result, there are likely to be libraries out
there, ones that have been developed in other contexts, for 8601
date-times and that are consistent with current version of 8601,
not the quarter-century-old 1988 one. Now, 3339 is, with that
one obvious edge case, compatible with ISO 8601:2019 -- a
library written for one will be compatible with the other. But,
if what this spec is saying is that, while things that conform
to it look at lot like 8601 strings with some stuff added on,
they may not actually be compatible, you are inviting
non-interoperable implementations and libraries. If
interoperability continues to be something the IETF cares about,
the IETF either should not publish such a spec or the document
should carefully explain what the deviations are, why they are
needed, and how interoperability problems can be avoided and
libraries compatible with (and conformant to) both can be
written.
best,
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
