Re: RFC abbreviations list

[Carsten Bormann <[e-mail]>]

On 2020-07-26, at 08:11, Joel M. Halpern <[e-mail]> wrote:
> 
> The text above the list states that titles are a judgment call and that they will sometimes allow omission of expansions in titles if the alternative looks too ugly.  Using judgment does seem to be what we want.

Completely agree.  The question is what input is available to make that judgement.  I can’t imagine that the RFC editor is in a good position to judge whether RSASSA-PSS is "well-known and immediately obvious to anyone...”.

So the abbreviation list could serve a purpose recording some of that information.

> Having said that, yes, some periodic housekeeping would seem to be useful.

Indeed.

> My disagreement was with the apparent claim by others that the "*" list ought to be easily updatable by an RFC that issues a new abbreviation. It may be that the person proposing that meant inclusion in the general list, rather than the "*" subset.  Or I may have misudnerstood something even more basic.

I think that an RFC cannot by itself “update” that list.
But just as the RFC editor asks about “keywords” for an RFC, they could indicate/ask about abbreviations used and created.  This would create a conscious point where authors/ADs and RFC editor could interact about moving the list forward.

Grüße, Carsten


> 
> Yours,
> Joel
> 
> On 7/26/2020 1:52 AM, Carsten Bormann wrote:
>> What I was trying to say was that the bar:
>>> that
>>> the abbreviation be well-known and immediately obvious to anyone
>>> with a significant Internet technical or operational background
>>> and experience.
>> … for getting starred is too high.  RSASSA-PSS is also an example how the “starred” list doesn’t really work that well (the RFC title doesn’t expand it although it is not starred), as are many other cases.
>> So the putative criteria is wrong, (partially as a result of that, and partially because the whole concept doesn’t quite work) the list is applied inconsistently, and it seems that there is no uniformity in the result.
>> Looks like something that needs work.
>> Maybe not urgently, but it is one of those pieces of technical debt that come up each time an RFC is published, the main damage being that their titles are often mangled beyond recognition, which makes them harder, not easier, to understand.
>> Giving some regular attention (*) to that list could ease the pain, which is what I was trying to point out.
>> In the end we’ll also need a better policy to handle the expansion issue.
>> Maybe all stuff to do for the RSE-ng, but stuff to do it is.
>> Grüße, Carsten
>> (*) Randomly poking:
>> 6CIO       - 6LoWPAN Capability Indication (6CIO)
>> 6CO        - 6LoWPAN Context Option (6CO)
>> (Both should say “Option”)
>> ARMv4     *- Advanced RISC Machine version 4
>> (This surely shouldn’t be starred under the criteria above, but then it also doesn’t make sense to expand it.  It is used in a single RFC, 6366, in an example.  This is a mid-1990s technology...)
>> Because the > 2500 lines are in no way sourced or even dated, it does not lend itself to divvying up the work to clean this up.  Maybe some mining in the RFCs can help do that, e.g. assigning IETF areas to the abbrevs.  But we need to understand how this list is being used, how the list could be improved to help these use cases, and what the appropriate criteria might be for them.
>