Mark Davis mark.davis at
Mon Jul 28 12:49:03 CEST 2008

My purpose is not to see the mapping incorporated into the protocol
document; it is rather to provide a separate but concrete specification of
what that mapping should be, along the lines of what is in
That is, supply a mapping that is essentially the same as the one used in
IDNA2003, but logically and consistently extended to the repertoire of any
Unicode version, much like what Tables is doing in terms of rules.

My concern is that if we don't supply a precise specification of what a
compatible mapping would be, we will end up with all kinds of spurious
differences among mappings.

The open issue in my mind as to the draft document I put together is
whether it has to be absolutely compatible with IDNA2003, or whether
we can get rid of the small set of exclusions (Section 3.3 Exclusions)
and the mapping errors (Section
3.4.3. Retain Corrigendum #4: Five Unihan Canonical Mapping Errors), which
would be rather nice to do.

On Mon, Jul 28, 2008 at 12:11 AM, John C Klensin <klensin at> wrote:

> --On Monday, 28 July, 2008 08:07 +0100 Paul Hoffman
> <phoffman at> wrote:
> > At 12:41 AM -0400 7/28/08, John C Klensin wrote:
> >> As I read your note (and I would encourage anyone on the list
> >> who hasn't done so, and done so carefully, to fix that), I
> >> come away with the feeling that you assume that, in the
> >> absence of very specific guidance and instructions,
> >> implementers are likely to run wild and do things that we
> >> would agree are crazy.
> >
> > That is one interpretation of his message. Another is that
> > implementers are likely to do as little as possible and do
> > things that we would agree are lazy. Mark's list of possible
> > equivalents could just as easily show non-interop due to lazy
> > application/IME implementers as it could to wild/crazy ones.
> >
> > The IETF has a much richer history with lazy and/or rushed
> > implementers. It would be good for us to keep them in our
> > thoughts as we craft the documents.
> Absolutely.   If one makes the assumption of lazy and
> indifferent implementers and zone administrators --and, while I
> think the IDNA experience has been different, I certainly agree
> that we've seen large quantities of those in other areas-- then
> the odds are that we will see no mapping at all because it is
> easier to not do it than it is to do, much less thinks about.
>     john
> _______________________________________________
> Idna-update mailing list
> Idna-update at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Idna-update mailing list