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