IDNA decode?

John C Klensin klensin at jck.com
Fri May 27 14:44:27 CEST 2011



--On Friday, May 27, 2011 11:32 +0200 Simon Josefsson
<simon at josefsson.org> wrote:

> John C Klensin <klensin at jck.com> writes:
> 
>> Yes.   In retrospect, the reverse conversation might have been
>> spelled out a little better.  But the general design of the
>> IDNA2008 relationships (and RFC 5891 in particular) is to
>> establish the equivalence relationship between U-labels and
>> A-labels.  Conversions are valid if they preserve that
>> equivalence and invalid otherwise.  Unlike IDNA2008 or your
>> discussion below, there deliberately is no algorithm in
>> pseudo-code.

Sorry for the several typos in the above (e.g., "conversation"
-> "conversion", and "Unlike IDNA2008" -> "Unlike IDNA2003", but
you seem to have figured out what I meant.

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

Speaking personally (rather than as author of any of the
IDNA2008 docs), I think it would be great to have a careful
description of a practical implementation in the RFC series, as
long as it was clear that it was just a description of one
implementation and not normative.

   john



More information about the Idna-update mailing list