SM, While many exceptions have been made on a case-by-case basis, charging for ISO and IEC Standards documents obtained directly from the ISO or IEC sites in Geneva is routine, the rule rather than the exception. It is also common for an ISO/IEC standards document, especially those from ISO/IEC JTC1, to be available from ISO, from IEC, and from one or more national standards bodies, often at different prices. The proprietary of referencing such documents from IETF specifications has been debated endlessly; the conclusion has been that, like other encumbered technologies, decisions are made on a case by case basis. With the example you site of the basic syntax for ASN.1, decisions were made years and years ago that the IETF had little choice but to cite it although other sets of syntax rules were preferred for most specifications. While it is not clear to me what that ASN.1 spec has to do with the Inclusive Language question, I am, more generally, not clear what point you are trying to make and what it has to with with the NIST document on inclusive language (apparently caught up in the current US Administration's attack on anything they consider DEI) and IETF specifications. john --On Wednesday, June 4, 2025 17:07 -0700 S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote: > Hi Q, > At 03:26 AM 04-06-2025, Q Misell wrote: >> I currently have an RFC in the AUTH48 stage, and as part of this >> the RFC editor asks me to review my text for possible issues >> around inclusive and respectful language, or rather lack thereof. >> Unfortunately, the accepted reference document to check language >> against, and to provide guidance on the construction of inclusive >> text is NIST 8366 "Guidance for NIST Staff on Using Inclusive >> Language in Documentary Standards". There is nothing wrong with >> the (former) contents of this document, rather that if one tries >> to access it nowaday they are presented with a 1 page PDF simply >> stating that "this paper has been withdrawn to > > The comment from the RFC Editor was: "Note that our script did not > flag any words in particular, but this should still be reviewed as > a best practice". The person who wrote that note also provided a > reference to the "online Style Guide". > >> I recognise this situation is not anyone with the IETF community's >> fault - its a ludicrous situation to be placed in by the political >> whims of a wannabe authoritarian. But the problem exists, and we >> should probably do something about it. As a starting point, I >> suggest we adopt the joint inclusive language guidance of the ISO >> and the IEC [1]; as these are both well respected international >> standards organisations, this maintains the stated goal of >> adopting NIST 8366 - in that the language used in the IETF is >> standardised across industry [2]. >> >> I am, of course, open to other suggestions about what to do about >> this situation; and I particularly encourage the IESG to put >> forward their suggestions to the community. >> >> For now, I will continue editing my RFC based on my understanding >> of inclusive language, and hope that I do not make any mistakes >> that a solid reference would've prevented. > > A document can be retracted by its publisher. The case which you > mentioned was discussed on an IETF mailing list [1]. Nobody > suggested citing the ISO/IEC document as guidance. I was looking > up ISO/IEC 8824-1:2021. I found out that I would have to send > Swiss francs 221 to be able to read it [2]. Why is IEC providing > the guidance for Swiss franc 0 and charging Swiss francs 221 for > its standard? [3] Is the guidance a standard or something else? > > Regards, > S. Moonesamy > > 1. > https://mailarchive.ietf.org/arch/msg/terminology/hTbe8e2Iey_SvZNyj > DRRVZ_1Nws/ > 2. https://www.iso.org/standard/81416.html > 3. https://webstore.iec.ch/en/publication/69675
