[Last-Call] Re: SDO references, was Re: Last Call: <draft-kucherawy-bcp97bis-05.txt> (Procedure for Standards Track Documents to Refer Normatively to External Documents) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On May 13, 2024, at 11:37 AM, John R Levine <johnl@xxxxxxxxx> wrote:
> 
>>> There are lots of standards where you can find close to final drafts or pirate copies on the net, but I wouldn't want to make a practice of depending on it.
>> 
>> That may be true in some cases, but the pertinent WGs of ISO/IEC JTC1/SC22 (WG14 for C, WG21 for C++ (*)) actively ensure that access to their specifications remains open through publicly available documents that are technically equivalent.  This has recently been fueled some more by JTC1 pretty much reneging on the previous approach of making IT related standards publicly available themselves [1].
>> 
>> The reality in this part of the universe is that the publicly available documents are the ones that actually get implemented, not the “official” ones you would need to buy access to.  We should acknowledge (and embrace!) that reality and make it dead easy for implementers to find the publicly available documents.
> 
> That is all fine, and I agree that when it is possible to use free documents we should do so.  But sometimes it isn't.  For many decades WGs and the IESG have dealt with this issue and I don't see anything new or different now that would merit a change.

This seems VERY technology and domain driven to me. Often enough IETF protocols have to work with technology standardized by other SDOs. In many cases to not work with them would be kind of dumb and make the IETF’s offering irrelevant.

For example, if CBOR had invented its own format for floating point numbers to avoid IEEE 754, it would be kind of dumb. IEEE 754 is built into CPU HW that IETF isn’t going to change.

Seems nice to avoid encumbered documents when possible, but it seems like the technical design and technical details are the main driver.

So agreeing with John.

LL

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux