Re: Diversity and offensive terminology in RFCs

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

 



Hi Adrian, all,

I read Adrian's post with interest, and have two comments and one suggestion

1. I think Adrian may have had in mind the term "faggot" for bundle?  (My guess is that not many non-native English speakers can make that connotation; I just happened to get across a blog post the other day where I learned the source of that word.)  Going just slightly later into ancient English history, the term "faggot" was not only used for the bundle (of sticks or whatever), but also for the low-class peasant who carried the bundle; often a serf of some kind.  Perfect replacement for the non-PC word "Slave".
2. As the term "Master" may not be sufficient PC, and the English word "Leader" is, as other have pointed out, inadequate because good leaders actually are willing to discuss with their followers (and at least occasionally revise?) their decisions--which is counter-productive in protocol design--how about "Fuehrer"?  Fuehrer is a German word, and certainly Germany's most recent "Fuehrer" had very limited inclinations to discuss his decisions, or revise them... so a perfect match for the desired functionality.
3. Therefore I propose a "Fuehrer - Faggot" relationship.  

(For avoidance of doubt: no, this is not to be taken as a serious proposal.)

Stephan
 


On 9/20/18, 06:22, "ietf on behalf of Adrian Farrel" <ietf-bounces@xxxxxxxx on behalf of adrian@xxxxxxxxxxxx> wrote:

    Long ago and far away, I did some code and documentation work for a large multinational. Part of the work described return codes carried on responses when the input parameters were not acceptable.
    
    We were told off for using the string "Invalid value" because that could be deemed offensive. There is still code out there that ambiguously reports "Parameter contains unexpected value." We did settle on "not valid" instead.
    
    Of course some terms have associated meanings that make the use of those terms unacceptable in any circumstance. (Who would be a supplier of bundles of sticks in the modern world? And possibly we are lucky to have picked the term "link bundle".) But those words were usually made bad by intended derogatory use not by the facts that they described. Thus, the only alternative way to correctly describe the relationship currently known as "master/slave" is to invent a new phrase that has exactly that meaning (such as "demanding-client/compelled-server") or to find another phrase that already exists and has exactly the same meaning.
    
    Given the disruption caused by a change in terminology, we should only act when there is need. As others have said, the best way to identify such a need is for those who are insulted or otherwise harassed to speak up. It is not efficient for others (many of whom, like me, have their own histories of benefit and oppression) to project. Of course, speaking up in public is hard and uncomfortable, but we have an Ombudsteam in place for exactly such issues and I am confident that they or any member of our leadership (ADs, IAB) would be very happy to hear of any concerns and would channel them with full confidentiality.
    
    Adrian
    
    > -----Original Message-----
    > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Niels ten Oever
    > Sent: 20 September 2018 12:41
    > To: Stewart Bryant; Riccardo Bernardini
    > Cc: IETF Discussion
    > Subject: Re: Diversity and offensive terminology in RFCs
    > 
    > On 09/20/2018 01:25 PM, Stewart Bryant wrote:
    > > The term master/slave is used when it is technically required that the
    > instruction is executed without equivocation.
    > 
    > Would leader/follower (as implemented by Django) not work just as well?
    > It seems to work for them for quite a while already.
    > 
    > Best,
    > 
    > Niels
    > 
    > --
    > Niels ten Oever
    > Researcher and PhD Candidate
    > Datactive Research Group
    > University of Amsterdam
    > 
    > PGP fingerprint	   2458 0B70 5C4A FD8A 9488
    >                    643A 0ED8 3F3A 468A C8B3
    
    





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

  Powered by Linux