Re: [I18ndir] [art] Modern Network Unicode

[Carsten Bormann <[e-mail]>]

Hi John,

thank you for chiming in.  I would have summoned you (and i18ndir) in time; in the current phase of rapid respins of the document I was first trying to make it useful before trying to nail down the details.

I was a toddler when ASA X3.4-1963 was released, but I caught up to ASCII about a dozen years later.  I have used ASR33s (although I spent more time on LA36s), and I have fully internalized the teleprinter model that led to NVT.  (I also spent some time on glass tty models of teleprinters [1].)  But while the teleprinter model has originally shaped what became “text files”, the latter are now living a life of their own.  MNU in effect tries to codify the emancipation of text from the NVT model, and I’m not surprised that this breaking away causes some sorrow.

Some specific comments:

> developments.  It may be a bit ironic that your solution to some
> other problems is to devise yet another network-standard form,
> especially one that has options that basically encourage (or
> require) profiles (or, if you prefer, combinations of variances).

Most new applications will be fine with (1D) CMNU or (2D) MNU with lines.
But sometimes legacy rears its ugly head, and therefore additional variances are defined.  I believe it is much better to expressly define these variances than to lump all the legacy into one big blob (single profile) that confuses the cleaner applications of MNU.

Now what is text being used for?  Some is exclusively for display to humans in 1D (CMNU) or 2D (MNU with lines) environments.
Some is then also used by machines, and that is where easy comparison comes in.
But the advantages of reasonably predictable encoding go way beyond that; which is why NFC coding is a de facto standard in most places that would use MNU.
(NFKC is in the current document mostly as a reminder that variances can be made in normalization, as well; it is probably the only reasonable one beyond NFC among the normalization forms, but has its own problems as you note.)

The CRLF (which really has survived only because the ASR33 needed up to 200 ms for a CR and the LF was a good excuse to waste those other 100 ms) is no longer needed; with the exception of a single popular operating system family, bare LF has won the line ending competition.  CRLF is one legacy feature that it’s worth getting rid of (except maybe as the “CR-tolerance" variance), as is HT.  (I’m assuming FF and VT are no longer relevant in most of today’s applications.)  All this may be a bit opinionated, but it is also forward-looking.  If full NVT is needed, we can always reference RFC 5198; MNU is for the cases where that is not needed.

I hope this doesn’t come over as too brash — I really like RFC 5198 and the careful tradeoffs it makes, but there are lots of applications that need something simpler and MNU reflects current practice and is a sane design for the 2020s+ (*).

Grüße, Carsten

[1]: https://en.wikipedia.org/wiki/GNU_Screen
(*): Yes, I’m fully aware that nothing about text and writing systems is genuinely simple; Einstein/Sessions applies.