"issues" and "protocol" documents
John C Klensin
klensin at jck.com
Mon Jan 28 21:34:00 CET 2008
New versions of draft-klensin-idnabis-issues and
draft-klensin-idnabis-protocol have just been posted and
Several comments below may make reading and understanding these
documents, and comparing them to their predecessors and likely
successors, easier. Both documents contain many clarifications
and corrections in response to comments on this list. I
believe, except as noted below, that all such comments that
required textual changes have been reflected in the text (not
necessarily in a way that everyone will agree with, of course).
The comments in this note are intended to supplement, not
replace, the material in the "Change Log" sections of the two
As we move toward a proposal we could ask the IETF to review, a
good deal of tentative "we could do either this or that"
language has been removed. At this point, the intent is to have
language of that type only in sections that explicitly discuss
design choices or alternatives.
New text has been added to identify and clarify design decisions
made strictly on the basis of preserving compatibility with
IDNA2003. Those decisions are not comfortable ones, but we
believe that creating incompatibilities that would either cause
ambiguities at the A-label level or that would force a prefix
change is just not acceptable at this point. We might as well
face the unfortunate fact that, while we may be able to change
the treatment of characters for which information is lost in the
A-label encoding and we can invalidate characters that can
appear in those labels but not change their mappings and
definitions, we cannot either change prefixes or have an input
string that is valid for both IDNA2003 and IDNA200X and that
produces different interpretations for the two.
I also realized just after posting the draft that I left out one
important bit of text that I had intended to get in. That text
defines the syntax (and machine-processability) of Contextual
Rules. The new text is written, the current version is
The contextual rules themselves are regular
expressions, used to produce a result of "match"
(to be construed as "True" or "succeed") or "no
match" (to be evaluated as "False" or "fail"). In
cases where it is appropriate, the terms "True" or
"False", spelled exactly that way, may appear
instead of a regular expression. "False" is not
equivalent to having no rule at all because it will
pass tests for whether a rule is present while
rejecting the label if the rule is actually tested.
"^" and "$" may be used in usual way the regular
expression to denote the beginning or end of the
label so a regular expression starting with "^"
and ending with "$" may be used to test the entire
Suggestions welcome -- I probably won't post another version of
the draft for a couple of days.
This document has been extensively reorganized and rewritten.
The most important substantive difference is that NFC
normalization is applied in a different order in the resolution
protocol and is added to the registration one. Checks on
whether the new order is correct would be appreciated. I'm
fairly sure that the previous one does not, at least without a
lot more information in the "tables".
More information about the Idna-update