On 2025-05-06, at 16:26, Carsten Bormann <c...@tzi.org> wrote:
>
> I need to note though that one of us liked my original “Maybe" formulation
> for its consistency, unwrapping all of the acronyms.
> I generally agree with this RFC editor style policy (despite its sometimes
> comical results — which could be dodged e.g., with RFC 9528), but I think
> there are diminishing returns at some point,
A nice demonstration of where excessive expansion text can seriously confuse:
Original:
Examples include conveyance via
PCIe (Peripheral Component Interconnect Express) IDE (Integrity
and Data Encryption) or a TLS tunnel.
Current:
Examples include conveyance via
PCIe (Peripheral Component Interconnect Express), IDE (Integrity
and Data Encryption), or a TLS tunnel.
The first of the two targets of the “via" is known as "PCIe IDE", which gets
abbrev-expanded to PCIe (Peripheral Component Interconnect Express) IDE
(Integrity and Data Encryption) — not only the RFC editor will misread that as
a list of two items with the third being “TLS tunnel”.
So this extra comma needs to be reverted at least to:
NEW1:
Examples include conveyance via
PCIe (Peripheral Component Interconnect Express) IDE (Integrity
and Data Encryption), or a TLS tunnel.
NEW2 (no gratuitous comma):
Examples include conveyance via
PCIe (Peripheral Component Interconnect Express) IDE (Integrity
and Data Encryption) or a TLS tunnel.
Of course, properly working around this accident-waiting-to-happen we planted
there would be even better. (We did want to have PCIe IDE first, going up from
hardware to software.)
Grüße, Carsten
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
