Re: RFC abbreviations list

Joel Halpern Direct <jmh.direct@joelhalpern.com> Sat, 25 July 2020 23:00 UTC

Return-Path: <jmh.direct@joelhalpern.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 CD56D3A0B5C for <ietf@ietfa.amsl.com>; Sat, 25 Jul 2020 16:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 n--CobwQ4ZYy for <ietf@ietfa.amsl.com>; Sat, 25 Jul 2020 16:00:31 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6513A0B5B for <ietf@ietf.org>; Sat, 25 Jul 2020 16:00:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BDhPC1ySjz6G90M; Sat, 25 Jul 2020 16:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1595718031; bh=ktjOjUmRBX9SJSAhk0qHByMInwyHWs0oLQyisHZlauI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Bjw21RD5/pT46KNEx0XpIdwb3FsORl3Uo78cfaOlZ0eXAXqpGLLSSisrztiqTe1jV 48qC7mIPvB63bTbU8qbOmUuez8p2ByJw+PpkPUssHwMW4Llvle8vfvetCXra82kvSu atbuKVpIz/CqPla7d5vbaNO6H0HhmBXCJ8vdno0w=
X-Quarantine-ID: <uUZSD3sZdCcY>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BDhPB4W3nz6G7Mk; Sat, 25 Jul 2020 16:00:30 -0700 (PDT)
Subject: Re: RFC abbreviations list
To: Toerless Eckert <tte@cs.fau.de>
Cc: IETF list <ietf@ietf.org>
References: <35BE966B-63A2-438F-BD61-570E86ED2E1A@strayalpha.com> <297BF899-553D-44DB-AB56-04280F776F7A@employees.org> <6646575A-E6EA-4B4E-AC1B-F8B84B5A1203@strayalpha.com> <20200724225654.GB43465@faui48f.informatik.uni-erlangen.de> <8F6D2B44-1914-4B3B-9458-3F2BF2CFCA05@tzi.org> <20200725210457.GJ43465@faui48f.informatik.uni-erlangen.de> <9A6BE775-78B9-41C5-A3EE-A34C7D092CA0@tzi.org> <20200725221507.GL43465@faui48f.informatik.uni-erlangen.de> <b8163085-e988-ae6a-e93f-3702f33b0dd0@joelhalpern.com> <20200725225731.GP43465@faui48f.informatik.uni-erlangen.de>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <c1b8ce64-afe6-1590-2025-aa2e280c9e84@joelhalpern.com>
Date: Sat, 25 Jul 2020 19:00:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200725225731.GP43465@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ESpXEB_NEOh2GgVI14goV01mSDQ>
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: Sat, 25 Jul 2020 23:00:33 -0000

It may be that we are not doing a good job adding terms to the RFC list 
of abbreviations which do not need expansion on first use.

However, in terms of what you state below, an RFC which introduces a new 
abbreviation can almost never meet the requirements for that 
abbreviation appearing in the RFC Editor list.  As almost by definition 
the new term is not yet in wide  use and widely recognized without 
expansion.  (There may be an exception or two where the RFC is 
recognizing a term that is already in use.  I said almost.)

Yours,
Joel

On 7/25/2020 6:57 PM, Toerless Eckert wrote:
> Well, i will invite you to the next discuss where an AD wants to educate
> a WG as to the appropriate use of some abbreeviation for a new expansion
> by referring to the RFC abbreviation list.
> 
> I for once don't think it is difficult to get things added. Indeed, i
> have simply added to my drafts an RFC-editor note stating which new
> abbreviations i would like to have added, something i think that
> should bhave been done for other now ubiquouts abbreviations as
> well.
> 
> Just as a reminder, why this thread came into place: I think we're
> not doing a well structured job on the RFC abbreviations list and
> i was just pointing that out as a bad example for how to not do things
> for someting like a "recommended new replacement acronyms" list
> that probably would ahve to evolve from that other folks thred we're
> just having here on the list.
> 
> Cheers
>      Toerless
> 
> On Sat, Jul 25, 2020 at 06:30:08PM -0400, Joel M. Halpern wrote:
>> The ADs do not own the RFC Editor list of abbreviations which do not need
>> expansion.
>> As a first approximation, as long as an abbreviation is considered new, it
>> is extremely unlikely to be added by the RSE (or equivalent person). The
>> point of that list is to list things that are so well known even outside the
>> narrow field of use that it is reasonable to expect people to know the
>> abbreviation.
>>
>> Personally, I wouldn't care if that list were reduced to zero.  Out goal is
>> to write clear documents.  expanding abbreviations / acornyms on first use
>> is a good idea.  I do understand that we do not bother with things like IP,
>> TCP, HTTP.  So having a list is useful.  But if people complain about how
>> hard it is to get anything on the list, I will push to remove it entirely.
>>
>> Yours,
>> Joel
>>
>> On 7/25/2020 6:15 PM, Toerless Eckert wrote:
>>> If we can put the most important new standards into RFC abbreviation list
>>> even after i tell an AD twice, then i don't think we can deal with
>>> new technical terms in the organization any better.
>>>
>>> On Sat, Jul 25, 2020 at 11:34:43PM +0200, Carsten Bormann wrote:
>>>> On 2020-07-25, at 23:04, Toerless Eckert <tte@cs.fau.de> wrote:
>>>>>
>>>>> For exmple i have to observe a real bad execution on evolving the
>>>>> RFC abbreviations list, and every time i pointed to problems,
>>>>> they where not fixed, and ADs did not bother to pick up the problem.
>>>>
>>>> True.  One of these ???medium importance??? issues???  Hard to get attention for them.
>>>>
>>>> I think we need a calendar to attend to them once a year or so.
>>>>
>>>> Grüße, Carsten
>>>
>