[rfc-i] How lack of Unicode support in IDs is detrimental to design

[mrex at sap.com (Martin Rex)]

Phillip Hallam-Baker wrote:
> I am just writing a draft that describes how to implement a PIN based
> challenge response.
> 
> To establish an initial connection to the server, the user presents a
> PIN value such as CS0F40-30LV09-K000.
> 
> Now the specification states that the PIN code is in UTF8. It probably
> does not make any good sense for a French implementation to use accent
> characters but I would hope that a implementer would have the sense to
> use the Greek alphabet for a Greek language deployment, Cyrillic for
> Russian and so on.

For most developers at the ~ 1 dozen software layers at and on top
of the network layer (below the UI), this information will be a
simple series of octets.  So for the vast amount of purposes,
the use of a hex dump is the most appropriate form to provide
the example in your specification.


> 
> Not being able to express these ideas in drafts means not being able
> to communicate them effectively.


Nope, it means helping the vast amount of developers at the network
layer and the dozen software layers below the UI being able to
easily understand your document.

It would be a real nightmare (for the document authors and the document
consumers) if every single document that uses DNS had to deal with
Unicode to A-label conversion over and over and over again.
The more reasonable approach is to put all that crap into a very
small amount of documents, and keep the world straight and simple
for all the rest.  


draft-ietf-dane-protocol-23.txt does not contain any unicode glyphs.
Adding such examples would make the document worse, because the support
of internationalized domain names is completely orthogonal to most
uses of the DNS protocol.  Adding examples with real unicode glyphs
to that document would only create confusion, complexity and problems
for rendering the document.


-Martin