What should I do?

Rémy Renardin renardinr at gmail.com
Sat Apr 18 01:44:19 CEST 2009


2009/4/17 Andrew Sullivan <ajs at shinkuro.com>

> > We completely oppose mapping at the protocol level (including all of what
> > actually can be equaled to mapping to nil).
>
> . . .I'd like to call this particular point of disagreement for what
> it is: nonsense.  The exceptions table was _always_ in the design, the
> charter was constructed when everyone knew about it, and there's
> nothing wrong with it.  It is mistaken to suggest that the particular
> example of what to do with the TATWEEL character is off-charter.  On
> the contrary, this sort of case is exactly what that exception table
> is for, as Patrik already pointed out more than once.


Dear Andrew,
I am afraid you confuse two things. exception tables and where the exception
applies.
The protocol is to explain where exception applies, what it means. But
exceptions tables are no part of the protocol.

The protocol concerns the relation with the DNS. The exception/mapping
tables concern the relation with the user entry.

At each layer the exception table must protect the entered layer from
dangerous, confusing entries. Punycode protects the LDH requirement. Tables
protect the application from confusion.

The difference we have is that you probably consider one single algorithm,
while we do not limit their number (starting with French case sensitivity).
One then sees easily that exceptions as you mean them must be at the bottom
of the user application layer.

But, it is true that the end to end principle is restored at user
application level and received a-labels may look meaningless or confusing to
applications ignoring the proper algorithm (carried in the prefix or
attached to the TLD). This is the difference between internationalization
and multilingualization (actually between unilateralisation and
multilateralisationsince other presentations types can be considered than
lingustic ones).

Rémy Renardin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090418/4bed8d12/attachment.htm 


More information about the Idna-update mailing list