[rfc-i] How lack of Unicode support in IDs is detrimental to design
mrex at sap.com
Fri Jul 27 15:59:08 PDT 2012
Martin Rex wrote:
>Phillip Hallam-Baker wrote:
>> And in point of fact, the specification does specify both the PIN as
>> it would be presented to the human user and the UTF8 byte code.
>> But it is rather difficult to write a spec that says the bytecode
>> value of "???? ?-???Z-?" is [21 01 21 03 ...] without being able to
>> give the PIN code in the form that it is intended to be presented to
>> the human user. Just giving the bytecode says absolutely nothing of
>> value as the spec already says that the bytes are fed into the MAC
> Except that the presentation is completely garbled and useless,
> and the hex dump is clear and umabiguous.
Really, the glyphs are pretty useless by themselves, because MOST of
them will be amgiguous or completely meaningless to readers anyway.
On a printed copy of an RFC, the following Unicode UTF-8 chars
2. CE 91
3. D0 90
only the first is guaranteed to as readable as the entire rest of
the document, whereas (2) + (3) will either come out garbled or
likely indistinguishable from (1), so that their use is unconditionally
from the "problem space", rather than the "solution space".
IETF document should create problems only by accident, not as an
intentional fashion statement of authors.
Consider that you wanted to send an EMail to someone (you barely know)
the information about a certain move of a figure in the board game chess.
The "old school" IETF approach would require you to send
"white pawn h2-h4".
But instead you're going to send a 3-D graphical animation (no sound)
of a chess board showing the pawn move h2-h4, render it as a flash
movie and attach it to your email.
Now what could happen is that the receipient uses some kind of
smart phone or tablet for reading his EMail, and that devices
happens to not support rendering of flash movies.
Or that recipient could be blind, and while his computing equipment
did support flash in principle, he is not in posession of accessibility
software that would turn your fancy graphical 3-D flash movie into
something that this person could understand.
I strongly believe that it is perfectly reasonable to expect from
someone who is not completely ignorant about chess to come up with
that text (as sender) or to figure out what it means when received.
And I don't think we should spend a lot of IETF resources into making
the chess-ignorant, but 3-D-flash-animation loving geeks happy.
More information about the rfc-interest