IDNA decode?

Ken Whistler kenw at sybase.com
Fri May 27 19:49:46 CEST 2011


On 5/27/2011 2:32 AM, Simon Josefsson wrote:
> Thanks -- this helps my understanding.  Having an algorithm defined only
> implicitly in terms of equivalences is nice from a theoretical view.
> > From a practical view, I think there are risks in having each
> implementer (attempt to) translate the properties into an algorithm, and
> pondering about each corner case.
I agree. This, by the way, is the essential reason that the Unicode 
Consortium
long ago adopted the position that for complicated derived properties that
we publish, the *list* itself is normative, whereas the algorithm used 
to define
that list is only informative. If somebody turns up a mismatch between the
statement of the derivation and/or algorithm involved and the list, then we
can fix the derivation, the algorithm, and/or the list at the next 
revision of the
standard. But in the meantime, the implementers aren't flailing around 
trying
to patch algorithms; they know exactly what to implement for a property 
for a particular
version of the standard: *the list*. And the list itself is unambiguous. 
That approach,
  we believe, promotes interoperability and early implementation.

This approach also means that the particular black magic involved in
working out the derivations and the algorithms for complex derivations
is contained within the UTC, and isn't scattered to implementers to
figure out corner cases on the fly.

--Ken

> When I revisit this aspect for my
> implementation, I'll write down the algorithm I will use with more
> details and publish that as a draft -- hopefully that can serve as an
> informational help to other implementers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110527/50c255f5/attachment.html>


More information about the Idna-update mailing list