Carsten,
You have just gone where I didn't want to go (at least on-list)
because it might take us into some IETF/IAB political issues
(past and present) but, yes, your students are good at their
work. Some generalizations (with the understanding that a few
details might be close but not exactly right these days):
(1) Many ISO standards started life as national ones and are
simply republished versions of those national ones. When the
national entities are governmental, there are often three nearly
identical versions: the national governmental entity's (NIST in
this case), the national member body's (ANSI here), and then
ISO. Each has its own charging policies for their own
documents, not merely wrt copies sold one at a time to the
general public but often different prices for different
categories of buyer. The only danger is that there are
sometimes differences as a document moves through the system so,
in principle, ANSI processes might tweak a NIST spec a bit as it
moves through the public/voluntary system and NIST might not
update their spec (I cannot remember a single case of that
happening but, again, in principle...). And the relevant ISO TC
might then tweak the ANSI standard (more common) and make a few
changes. Sometimes the originating body will adjust their
specification to match any changes made for the ISO one and
sometimes they won't. And, with details I just don't remember,
they get to re-publish the final ISO specification on their own.
Similar principles typically apply if a document is developed by
an entity that is not an ISO National Member Body but that has a
Category A Liaison and is allowed to propose documents for ISO
standardization directly. You've encountered aspects of that in
your CBOR work whether they were identified that way or not.
(2) Because there are no guarantees that a final ISO standard is
identical to whatever document was used as its starting point,
even if that starting document was identified as a standard by
the originating body, one has to be a little careful about
believing that the ISO standard is identical in every way to the
national one. This is really no different from the IETF
situation when nearly complete documents are brought in from the
outside and put into the IETF process. People may find issues
(in Last Call or earlier) and there may be community consensus
for making adjustments. Similar comments apply to copies of
documents that were balloted at the FDIS ("Final Draft
International Standard") level: officially they are not public,
but the system is leaky. If an FDIS document is approved, the
differences between it and the final published text are
typically zero other than boilerplate and front and back
material (unlike our "approve and then edit" model with AUTH48
at the end).
(3) ISO National Member Bodies are often the sales agents for
ISO documents in their countries and, subject to some rules I
don't remember (and that may have changed since I was involved
at a policy level), set their own prices, which might be zero.
As above, they may also have republication rights, especially if
the ISO documents are formally adopted as national standards.
In the NIST case, anything they publish as a FIPS document is a
national, governmental, standard not a voluntary private-sector
one (whether compliance is voluntary or at least nominally
required is a separate issue). When, for whatever reason, a
national or liaison body republishes an ISO standard with ISO
cover pages and headers (as with NIST link your students found),
it is almost always safe to believe that the it really is the
ISO spec in all the details. While it is much more common, even
"standard", outside high-tech fields, many ISO standards are
published in more than one language or translated later into
local languages by national bodies. Those translations are
generally produced by skilled and very careful people but, as
you certainly know from other experiences, perfection in
translation is hard to guarantee.
(4) I may not have been clear enough about it (in which case,
apologies) but when I said that superceded ISO documents are
dead and hard to obtain through ISO, that did not imply that
there are not copies (or copies of equivalent national versions)
around and available. In addition to cases like the ones your
students found, there are still entities called "libraries"
around the world who not only have copies of these standards but
are reluctant to discard older versions. Some of Ulrich's
comments are very relevant to that situation.
(5) ISO's rule about documents being free for standardization
purposes (and that is a crude paraphrase) applies to work in ISO
technical committee and national member bodies. Whether it
applies to liaison organizations or other bodies or not depends,
formally, on the category of liaison and on the particular
liaison relationship. At least in principle, nothing would
prevent Michael Douglas (with whatever approvals were needed
from IAB) from asking that current versions of ISO 8601 be made
available to participants in SEDATE or a selected subset of
them/us. As a matter of practice rather than policy, the
decision might depend on how many people we wanted to have
access to the documents on the basis: if the question was about
Michael (who already has access at least to FDIS specs), the WG
co-chairs, and a document editor or two, the odds of approval
are probably high. If it was about anyone who claimed to be
participating in SEDATE (or in the IETF because, on Last Call,
we are get to review and comment on SEDATE's work) probably
somewhat lower.
Bottom line: While it is reasonable to be concerned about
normative references to ISO Standards and whether a random
person could obtain one at a reasonable price and/or pain level,
claims that price (or anything else) makes those documents
essentially secret from an effort like SEDATE and its document
authors are hyperbole at best and plain bogus at worst. And
"we" largely chose whether to have a mutually respectful and
supportive relationship with particular ISO TCs to the make the
relationships adversarial and/or ones in which they need to
behave in a subservient fashion.
Hope that helps.
best,
john
--On Thursday, October 20, 2022 13:46 +0200 Carsten Bormann
<[email protected]> wrote:
> When I need information about a paywalled document, I usually
> ask my students, who have a supernatural capability to divine
> information about such documents.
>
> In this case, they were too lazy for actual divination, and I
> just got back a reference to a document apparently published
> by NIST:
>
> https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.
> pdf
>
> (This is missing the 1991 corrigendum, but it is a useful
> resource. Delete the blank verso pages...)
>...
> Interestingly, I cannot find a prohibition of -00:00 (and I
> cannot find what would actually allow +00:00 either). So the
> statement we got about -00:00 not being allowed by ISO 8601
> apparently refers to a different revision… (And I need to
> apologize to the RFC 3339 contributors who based their work on
> the 1988 revision, but then the RFC is also referencing
> ISO8601:2000, and that reference is also in
> draft-ietf-impp-datetime-04.)
>
> My students also divined that ISO 8601:2000 appears to rule
> out using a minus sign for non-negative values. One section
> that this can be inferred from is Section 5.1.1, but the
> result of that inference probably can be debated. More
> importantly, Section 5.3.4.1 shows a fix that lets one infer
> +00:00 is actually allowed, while -00:00 is not.
>
> Oh, and Library of Congress has this for us:
>
> https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso
> _wd_8601-1_2016-02-16.pdf
>
> In that draft document (which is likely to reflect published
> versions up to its date, but may differ from ISO 8601:2019,
> the relevant sections that support the hypotheses about +00:00
> being allowed and -00:00 not being allowed are 3.4.2 and
> 4.2.5.1. Same section numbers for ГОСТ Р 7.0.64-2018,
> which seems to be ИСО 8601:2004 in Russian language.
>
> Grüße, Carsten
>
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
