Re: [EAI] UTF32

[John C Klensin <[e-mail]>]

--On Tuesday, April 21, 2015 16:07 +0300 Oleksandr Tsaruk
<[e-mail]> wrote:

> Is it possible to reconsider (in a very long run) EAI WG
> general approach to:
> 
> "This working group's previous experimental efforts
> investigated the use of UTF-32 as a general approach to email
> internationalization." In such case email/domaine
> internationalization problem could be solved in original
> scripts? 

In principle, yes.  In practice, given the increasing (and
increasingly universal) use of UTF-8 on the wire, probably not.

The more important question is what you think going to UTF-32
would accomplish.  It is fully isomorphic with UTF-8 -- there is
no information that can be represented one way and not the
other.  It is much less compact than UTF-8 for "western"
alphabetic scripts (including Cyrillic), less compact for any
BMP code point, and never worse (in terms of more bytes per code
point.  UTF-32 does not get involved with the "surrogate" mess,
but neither does UTF-8.  Neither helps at all with the various
normalization or comparison problems.   The only advantage I can
think of at the moment is that UTF-32 permits getting a count of
the number of code points present by counting octets and
dividing by four while UTF-8 (and UTF-16) require some
calculations.  However, one rarely cares about number of code
points as compared to, e.g., number of "print positions" or
"characters" and, given combining sequences and non-spacing
characters and marks, getting from a code point count to print
position information cannot be done without considerable
knowledge of the code points involved (and, for some scripts,
rendering procedures).

So, can you explain what you think a move to UTF-32, even if it
were possible, would accomplish?

    john