I-D Action:draft-ietf-idnabis-mappings-00.txt

Paul Hoffman phoffman at imc.org
Sun Jun 7 01:38:12 CEST 2009

At 7:02 PM -0400 6/6/09, John C Klensin wrote:
>I note that I don't believe there has been any substantive
>responses to my earlier note that outlined the above objections
>since I posted it.

I didn't want this to devolve to a dialog between the two of us, but you rightfully point out that it turned into a non-discussion.

>I continue to believe that use of NKFC without exclusion of
>character groups for which there are no justifications is

Pete's proposed mapping happens before the is-it-valid-IDNA2008 check. Why should we use a modified NFKC instead of plain-vanilla-NFKC and let the second step (is-it-valid-IDNA2008 check) happen as-is?

>(i) A violation of the "inclusion" model of IDNA2008

Completely agree. However, this whole document is a violation of the "no-mapping" model of IDNA2008, so that seems like an odd objection.

>(ii) A violation of the closely-related protocol design
>principle that one should include only those things for which
>one has both use and understanding because it is easier to add
>later than it is to remove.

Implementers of IDNA2008 will understand NFKC as well as implementers of IDNA2003.

>(iii) An increased risk, however slight, that we will, in the
>future, get strong demands from some particular community to
>treat a character classified by Unicode as "compatibility" as a
>real and distinct character.  If such a character is disallowed
>by virtue of not being mapped, we will have the difficult
>problem of changing a disallowed character to a PVALID one.
>But, if it is mapped to something else, we will have to revisit
>the very complex discussions that we have had over Eszett and
>Final Sigma.  We should not incur that risk unless there is a
>reason to do so.

There is: increased (but, of course, not full) backwards compatibility with the large installed base of IDNA2003.

More information about the Idna-update mailing list