Avoiding Exclusionary Language in RFCs

3.1. Potential Harm to Accessibility of IETF Documents

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.¶

3.2. Small Benefit, Potentially Large Cost

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.)¶

3.3. Potential For Unproductive Distraction

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.¶

3.4. Late Substitution of Words Considered Harmful

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.)¶

3.5. No Sweet Spot For Non-Technical Discussions

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.¶

3.6. Need to Minimize Disruption

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.¶

4.1. RFC Editor Requested To Advise Community About Potentially Exclusionary Language

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.¶

4.2. Complaints Preferred From Aggrieved Parties

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.¶

4.3. Authors/Editors Entrusted To Avoid Exclusionary Language

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¶

4.4. Embellishment of Internet-Drafts Tools

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.¶

4.5. Working Group Chairs May Limit Discussion of Language

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.¶

4.6. IESG Should Defer To Working Group Consensus On Language

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).¶

4.7. Blocking Based On Language Must be Based On IETF Consensus

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.¶

4.8. No Automatic Substitution Of Identified Words

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.¶

4.9. No Requirement To Revise Existing RFCs

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.¶

4.10. Evaluation Of These Recommendations

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.¶