Re: WG Review: Effective Terminology in IETF Documents (term)

John C Klensin <john-ietf@jck.com> Fri, 09 April 2021 23:09 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2CF3A15EE for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 16:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp9Tls8NO7Pz for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 16:09:48 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF533A15ED for <ietf@ietf.org>; Fri, 9 Apr 2021 16:09:48 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lV0G2-000E7C-3S; Fri, 09 Apr 2021 19:09:46 -0400
Date: Fri, 09 Apr 2021 19:09:40 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Nico Williams <nico@cryptonector.com>
cc: ietf@ietf.org
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
Message-ID: <BF5F92A7C0F2FF96BBE6C110@PSB>
In-Reply-To: <a9698e3a-bee7-aadc-028e-647b7033a016@gmail.com>
References: <89383942-204e-a94e-3350-42bfb4165ba0@comcast.net> <792c4815-8c36-e5fa-9fbe-2e1cfa97239f@comcast.net> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <f52c46cf-03fb-6692-3a87-9b7db639f2e9@gmail.com> <130eadf6-70c2-9035-6ac2-b20dea7e9dba@joelhalpern.com> <20210406212509.GS3828@localhost> <046922BE-F850-4B09-8527-D2B014505C44@juniper.net> <20210409160539.GA9612@localhost> <fc12b265-f303-f8bf-da08-ed4616a6dba6@gmail.com> <20210409213907.GC9612@localhost> <a9698e3a-bee7-aadc-028e-647b7033a016@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JVvl4C_L2ZqmCa1NXCpqA87nez4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2021 23:09:50 -0000


--On Saturday, April 10, 2021 10:06 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

>> We're talking about a s/X/Y/g substitution that would be
>> recommended or required by the STYLE guide and which may not
>> get applied.  The idea with eliding IESG approval and IETF LC
>> at this stage is that if this was controversial, it would
>> have been caught earlier, and to avoid divisive later
>> controversy like what we're seeing.
> 
> It's much better for everybody, I think, if it was caught
> earlier.
>...

Ah.  There is another part of the above that is worth commenting
on.  Experience (and my shelf of style manuals contains pieces
on, e.g., non-sexist writing and associated terminology changes
go back to the 1970s --the terms of greatest interest may be
relatively new, but the discussions are not) suggests that many
of the substitutions will not be s/X/Y/g and that some may
require subtle editorial judgments and then enforcement of
consistency.  Two simple examples:  if "we" decide that the
solution for "he" and "she" is "them", then, if the author wrote
"he or she" you would not want to end up with "them or them",
which is what that sort of mechanism substitution would give
you.  In addition, someone needs to decide whether, if "them" is
substituted for "he" as the subject of a sentence, it takes a
plural or singular verb.   I stopped caring about the choice
long ago but it should be made in a way that is consistent, and
consistently applied, across the RFC Series or at least within
individual documents.

On the other hand, if this really were s/X/Y/g, the IESG could
decide to build it into the mandatory part of the nits checker
and avoid the whole "enforcement" discussion.

   john