Re: Diversity and offensive terminology in RFCs

[John C Klensin <[e-mail]>]

Two quick observations that I don't think have been made already
in favor of being much more careful about terminology we
introduce in the future but probably letting most existing and
well-established terminology stand.

(1) To further illustrate the difficulties in trying to prohibit
terms that someone would find offensive, even those who are
inclined to look for things to be offended about (a category
that I am confident includes no IETF participants), it is
possible to construe "client/server" (and "server" in
particular) and "protocol" in ways that would make them
offensive. Lloyd has already identified "whitespace" and some
specifications we don't control (parts of the Unicode collection
come to mind) are target-rich environments.  It seems to me that
this is a slippery slope at a very high angle.  We could, of
course, go through existing terms one by one and try to reach
community consensus about what to do about each one, but let's
try to remember that even having the discussion we are already
having is quite expensive for the community in terms of other
work that doesn't get done.  It is also hard work.  As an
example, I've always found "man-in-the-middle" terminology
problematic, but at least as much because it implies human
intervention rather than something more automated as because of
gender.  Yes, there is a gender issue, but
"monkey-in-the-middle" or even "donkey-in-the-middle" are still
problematic.   "Agent-in-the-middle" or maybe the "spy"
suggestion (but that may have the wrong implications too -- not
because there are no women spies but because, in many language
contexts, the term implies observing and not intervening), might
be better, but...

(2) There isn't any starting from a clean slate as of today (or
any other convenient date).   If there is a term that we have
been using as a term of art for some time and we decide to
substitute a newer and better one, existing documents --our RFCs
and tutorials, manuals, etc., written by others-- aren't going
to change.  So, unless the relationship between the earlier
terms and the later ones are completely obvious, everyone is
going to need a glossary that maps both ways between the new
ones and that older ones and explains any non-exact mappings.
What is "obvious" to one person may not be to another: using the
monkey example again, if "monkey-in-the-middle" shows up in a
document in a context in which "man-..." would have been
expected earlier, clearly one possibility is that the authors
were trying to use less problematic language.  However, if even
a few people wonder whether the new term is intended to identify
a difference in circumstances or protocol relationships (not
just substitution of less problematic terminology), the costs to
the community and the clarity of our specifications are actually
very high.

  best,
    john

p.s. I agree with Mike St. Johns's note too and don't feel a
need to repeat it but let me add a pair of closely-related
suggestions about his conclusion.   First, if you want to
introduce newer and better terminology, make sure you do it
before IETF Last Call and don't try to slip it in at AUTH48.
The latter would be unfair to the community and risks
introducing subtle changes for which there is no consensus (that
is another reason why trying to pass responsibility for this
onto the RFC Editor is a bad idea).  And, second, if you are
introducing new terms to substitute for older ones, please call
that out (in introductory material in the document and in IETF
Last Call) and explain what you are doing so as to mitigate some
of the difficulties described above.