search

tlswg / draft-ietf-tls-esni

TLS Encrypted Client Hello
https://tlswg.github.io/draft-ietf-tls-esni/#go.draft-ietf-tls-esni.html
Other
229 stars 56 forks source link

Experimental proposal to add an Abbreviation section ommitting 'well … #590

Closed taddhar closed 7 months ago

taddhar commented 10 months ago

…known' ones.

So this one is an experimental proposal because indeed I couldn't see many Abbreviation sections in any RFCs. I found an abbreviation list from 'Editors' but it stops being updated in 2021 (wondering the story behind this one). But I liked the concept of well known abbreviations vs not well known ones.

In general when I read a text and moreover a complicated text, I hate to have to guess what means acronym A, B, C and or to have my brain to 'calculate' on the fly what it is or to have to research in another document. In my mind, it is 'basic respect' to the reader to put the acronym in plain.

OF COURSE I do understand that for developers these are completely obvious. I get that. But for Operational people or other persona, sorry, I am not coding TLS every day so I made a mistake to understand HRR or EE and for example AAD has two meanings ... which is calling why we might want to put more definitions (See my other PR on definitions).

Anyway we can debate if X or Y or Z is well known or not but I think there are too many new things in this one and an Abbreviation section would help.

As said in IETF 118, ECH is complex, so am trying to help a little bit on that line, but if nobody happy with it, just reject it.

ekr commented 7 months ago

I don't think this is necessary. Most of these are terms of art in TLS. I don't see how it's possible to understand this specification in the context of TLS without knowing what AEAD is, for instance.