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

Phillip Hallam-Baker hallam at gmail.com
Fri Jul 27 14:01:41 PDT 2012


+1

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
function.

I deal with security and so the user experience is always an integral
part of my designs. If the IETF is not interested in the user
experience then it can't do security (or DNS for that matter).

The other reason for needing proper examples is that they expose
design issues that would not otherwise be apparent. For example, the
need to ensure that servers are capable of generating PIN sequences
that the user is capable of typing in. That resulted in a SHOULD to
support pure numeric keys as the lowest common denominator means of
input.


On Fri, Jul 27, 2012 at 4:03 PM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
> On Fri, Jul 27, 2012 at 09:39:45PM +0200, Martin Rex wrote:
>>
>> 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.
>
> What in the world does U-label/A-label conversion have to do with
> anything Phill was talking about?  U-label/A-label conversion is
> indeed well-understood and well-specified somewhere, and so it's
> possible just to point to that.
>
> But Phill was talking about a case where he is planning to put UTF-8
> _in the protocol_, and make that UTF-8 significant in the protocol;
> and he was quite correctly pointing out that providing zero examples
> to show how this could happen is an excellent way to ensure that some
> underpaid contract programmer with half an attention span will
> implement the protocol in the future without handling the UTF-8
> encoded protocol fields, and then there'll be an interoperability
> problem.  I agree with him.  (Indeed, the comparison with DNS is a
> good one, but in support of Phill's conclusion: all sorts of things we
> are or have been saddled with in the DNS are/were there because some
> developer read the examples but didn't understand the protocol.  This
> extends right down to the indifferent attention paid to the protocol
> instruction that labels are octets, not ASCII strings.)
>
> I have mostly tuned out of this discussion recently because of a
> vexing pattern of behaviour.  Every time someone suggests even the
> most modest accommodation to facts about the computing environment
> since, say, 1990 -- the rise of Unicode, the wide variety of display
> environments, the decline almost to irrelevance of fixed-line and
> length formats and terminal-type displays, the decline of printed
> matter in many computing environments, the complete lack of support by
> printers of older-style formatting -- some helpful reactionary is
> there to deny that any of these issues are even remotely important to
> him (it seems always to be him) and that therefore the topic is
> closed.  It's hard to see what the value is in participating in such a
> fruitless "discussion".
>
> Regards,
>
> A
>
> --
> Andrew Sullivan
> ajs at crankycanuck.ca
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest



-- 
Website: http://hallambaker.com/


More information about the rfc-interest mailing list