| Internet-Draft | Avoiding Exclusionary Language in RFCs | August 2020 |
| Moore | Expires 27 February 2021 | [Page] |
It has been asserted that some language in IETF documents is "exclusionary" - that it offends some readers or groups of people, and/or discourages participation in IETF by doing so. While there is some debate about exactly which language is exclusionary, at least some cited examples of such language can credibly have such effects. It is believed that most instances of such language are accidental, and that most document authors and editors wish to avoid use of language that may be offensive. This memo therefore attempts to establish procedures that warn document authors and editors about language that may credibly having such effects, and thereby, to reduce both accidental and deliberate use of such language.¶
At the same time, it is recognized that in some cases there an be strong and conflicting opinions about whether or not particular language is desirable or appropriate. IETF's primary function is providing technical direction for the benefit of the Internet community, rather than social engineering. If a document can be blocked or substantially delayed over disputes about the proprietary of language in that document, this can be disruptive to IETF's primary function. This memo therefore makes recommendations to prevent such disputes from blocking progress on technical documents.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 February 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Various parties have raised concerns that language in some IETF documents is offensive to some readers or groups, that such language may have the effect of discouraging use of IETF documents and/or discouraging participation in IETF. This memo therefore considers both potential positive and potential negative effects of regulating use of certain words and kinds of language that are asserted to cause such harm.¶
The community of IETF participants wishes for its standards and other documents to be as widely usable as possible. Broadly speaking, language that offends some set of readers of a document is counterproductive, because it may discourage use of the document and/or distract from the technical content of the document. More broadly, such language in one RFC may discourage use of other RFCs if the IETF organization is seen as unfairly biased. Finally, such language may discourage participation in IETF by the aggrieved parties.¶
Most such offenses in existing RFCs are believed to be accidental, especially when using terms that have become well-established in technical vocabulary, or in the English language itself, long before today's emerging realization that such terms can be offensive or distracting. Also, many assertions of harm caused by particular words are believed to be uncontroversial, such that document authors and editors will willingly avoid use of such language if made aware of the potential harm.¶
Any efforts to prohibit use of certain words should, in general, be regarded with caution because of the harm that censorship can do to expression. However, because IETF's work is almost entirely technical in nature, this may be less of a concern for IETF than for language in general. While there may be disagreement about some terms that have multiple meanings, it is difficult to imagine that IETF has a need to use terms that are generally seen as derogatory or pejorative to any group of people.¶
Broadly speaking, it seems worthwhile to attempt to evolve the technical language we use to make it less likely to offend or distract. However, it should be realized that actual benefit from doing so is likely to be small, while the energy drain to IETF from doing so is potentially quite large. No matter how well intended, IETF changes to its language cannot significantly address great injustices done in the past or present. Such changes may have the effect of making IETF documents more accessible, or they may have the effect of making it appear that IETF is sweeping those injustices under a rug. Different people may reasonably have different opinions about these matters.¶
What this suggests is that IETF should consider and carry out such changes with humility, and with as little disruption to its ordinary work as possible, and that IETF should not inflate these actions with a sense of great purpose. (This may also make it easier to reach broad agreement on such actions.)¶
Long debates about offensive or distracting language can potentially be significant and unproductive diversions away from IETF's work. This is for several reasons:¶
Getting an RFC approved for publication can require many months or even years of effort, including working group discussion and multiple revisions, multiple working group last calls and additional revisions, followed by potentially multiple IESG last calls, and subsequent processing by the RFC Editor. Any effort that even implicitly threatens to block or significantly delay publication of documents, especially for non-technical reasons, may have a broad chilling effect on IETF work. It is therefore unsurprising if some efforts to restrict language invite significant community opposition.¶
For some words there is no consensus about whether use of that particular word actually causes harm or what appropriate substitutions might be. Arguments that the word causes (or does not cause) harm may be contentious even if (especially if) lacking in substance or robust supporting evidence.¶
Different people, even among the groups supposedly aggrieved by use of certain words, may reasonably have different ideas about the amount of harm or distraction caused by certain words. Debates over the propriety of some words and some kinds of language may never terminate.¶
Views about the propriety of certain words can be expected to change over time, which might potentially compel some documents to be revised multiple times in order to track then-current usage.¶
Experience suggests that there is a tendency to exaggerate the importance of rules governing the use of specific words. For example, RFC 2119 specifies words that have special meanings when written entirely in upper-case letters, in documents that explicitly invoke RFC 2119. This has often been mis-interpreted in various ways, including that words "should", "must" etc. must be written in upper-case letters when used in RFCs.¶
Late substitution of offensive (or supposedly-offensive) words in documents, with other words, may harm the clarity and readability of such documents.¶
Technical language borrows terms from ordinary language (or sometimes, other subject domains) in order to utilize readers' familiarity with other meanings of those terms. This often helps readers understand the technical meanings of those terms without their needing to learn entirely new words. This tactic generally improves the accessibility of the technical language.¶
Generally the author(s) or editor(s) of a document will have carefully selected the technical terms in the document to optimize readability and accessibility of the document. Other language in the document will have been crafted around use of those selected terms. Late substitution of alternate terms may impair readability if the new terms are not as readable or accessible, and may require significant document revision in order to try to restore clarity to the document, precisely because the newly-chosen words may be semantically somewhat different than the original ones. Ideally the best terms to use, taking all known factors into account, are chosen early in the process of writing a document. In some cases, clarity of a new document may be enhanced when its terminology is aligned with other documents (whether or not produced by IETF) needed to understand the new document or implement the specified protocol. In general the author(s), editor(s), and perhaps the working group, are likely in a better position to decide what terms to use, than any subsequent party.¶
It is possible that substitution of new terms in place of well-established or more descriptive terms may create confusion among readers, and thus make the technical content less accessible than otherwise. Thus there is a balance of interests that must be considered if the overall goal is to maximize the benefit of IETF-produced documents to Internet users. (To be fair, there may also be cases where substitution of new terms improves clarity.)¶
When making technical decisions there is often a "sweet spot" which appears to maximize technical benefit even when viewed from various points of view. It is less clear that such a "sweet spot" generally exists for "social" decisions such as the choice of language.¶
For the above reasons it is believed that measures taken by IETF to reduce use of offensive and distracting language should be mostly-voluntary on the part of authors and document editors, should leverage existing mechanisms and processes when possible in preference to creating new mechanisms or processes, and in general should be chosen to minimize disruption to IETF technical work.¶
The following recommendations are made in light of the above concerns.¶
The RFC Editor is requested to maintain, perhaps as part of its style guide, advice about language that may be offensive or distracting. Such advice should generally be stated in broad terms rather than specific words, but specific words may be cited as examples of language that is potentially offensive or distracting. The RFC Editor MAY also publish a list of specific words that are seen as potentially offensive or distracting, for the purpose of alerting document authors and editors to such potential.¶
If the RFC Editor is unwilling to provide such services, or funding for such services cannot be arranged, an alternate neutral party chosen by IETF Consensus may instead provide such services.¶
Any requests that RFCs avoid language that offends a certain group or individual SHOULD ideally come from the aggrieved parties - i.e. from aggrieved individuals or credible representatives of an aggrieved group or individual, rather than by other individuals or groups purporting to speak on behalf of the aggrieved parties.¶
Requests credibly originating from aggrieved parties should be treated as sincere expressions from those parties. Requests originating from third parties should be viewed with skepticism, unless perhaps accompanied by documentation of peer-reviewed controlled research with clearly described, robust and repeatable methods, ample sample sizes, and publicly-accessible detailed results.¶
In order to minimize disruption and delay in publishing documents, and also to distribute the workload associated with avoiding such language, the principal effort to avoid offensive or distracting language SHOULD be a voluntary one among document authors and editors. Authors and editors MAY of course consult with their Working Groups, Area Directors, or other advisors¶
To assist authors and editors in identifying potentially offensive or distracting language, Internet-Draft processing tools MAY be modified to indicate which words in a document have been identified as potentially offensive or distracting language, with messages containing references to the RFC Editor's advice about such language. However, the presence of such words MUST NOT be considered errors (since context is often very important), and MUST NOT block publication of the Internet-Draft. (but see below) Any messages issued by such tools about such words should be clearly described as advisory in nature.¶
Separate from the above, if there is IETF Consensus that specific words must be forbidden in Internet-Drafts, the Internet-Draft processing tools SHOULD treat presence of such words as errors and refuse to publish documents containing them.¶
While complaints about the use of language in a working group draft may be submitted to the working group at any time, working group Chairs MAY defer discussion of potentially offensive or distracting words until the first Working Group Last Call for a document in which such language appears. Working Group chairs MAY also limit debate about language in real-time meetings and/or on the mailing list. The intent is to avoid constant and endless discussion of such words which can distract from discussion of technical issues and delay progress in resolving such issues. It is also hoped that deferring group discussion of such language may provide an incentive for opposing parties to work out their differences in private email.¶
When considering use of language in working group documents, and in the absence of established IETF Consensus on the topic, IESG SHOULD defer to the working group's consensus about whether use of contested language is appropriate (given that the working group are subject matter experts).¶
Any policies that prohibit use of certain words or language, or impose additional process that may block or significantly delay documents containing certain words or language, MUST be described in IETF Consensus documents.¶
Since an effective choice of alternative language may depend on the specific requirements of a particular specification, there MUST NOT be any automatic substitution of prohibited or otherwise identified words.¶
Existing RFCs SHOULD NOT be revised merely because of the use of language that is now considered inappropriate. Revising published RFCs for any reason can be difficult and draining on IETF resources that could be better applied to addressing technical issues, especially as such revision provides an opportunity to revisit many old issues. Revising published RFCs also increases the burden on the users and implementers of such RFCs who must then attempt to reconcile the (potentially conflicting) different versions with their implementations.¶
As an alternative to revising old RFCs, a brief list of changes in an existing RFC's language MAY be published as Informational or BCP documents.¶
The desirability of these recommendations should be judged by their effect on RFCs published, as evaluated after some time, rather than by the strictness of the measures taken.¶
It is recognized that debates about proprietary of language may in some cases not be easily resolved, and that in some cases such debate may be deliberately used as a way to disrupt the normal operation of IETF. This document recommends some measures to limit debate whether or not it is a deliberate attempt to disrupt IETF.¶