Re: [rfc-i] Unicode in xml2rfc v3

On 2020-12-17, at 22:28, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> RFC 7997 opened the door, but not very wide. In earlier days ASCII was enforced.

A very typical mistake.

When some direction of travel is controversial, there is a tendency to make “compromises”.  This can have the effect that all the costs of taking that direction accrue (because they are not actually influenced by the compromise), but the benefits are artificially limited.

That is exactly what happened here.

We should have embraced the change that emanated from RFC 2277 and the contemporary groundswells in the industry, and two decades later (almost a decade after the first hesitant steps were made with the RFC format), the current status looks comical.

Emojis in RFCs don’t have to be ruled out by some mechanism (just as writing RFCs that are entirely about farting doesn't have to be); having a bit of (much more flexible) policy about this is fine (although we somehow never needed that for the second example).

By the way, authoring tools can still help prevent accidents; smart quotes were mentioned, as probably should be BOMs, various forms of zero-width (invisible) characters etc.  This is particularly relevant for source-code and code-spans, which can be mangled badly when such accidents happen.  None of this is new with going beyond ASCII, as various problems with backslashes in nroff times should remind us of, or the HT interpretation issue that led to the RFC 7386/7396 disaster.

Grüße, Carsten

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest