There appear to be a relatively small number of issues
still remaining in IDNA2008. Here's my shot at identifying them. They are
stated as "consensus requests", but need more discussion before we'd put them out as such.
document how the compatibility problems between 2003 and 2008 can cause security problems (See http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8 )
document the security issues that can arise in BIDI where Label
Uniqueness and Character Grouping are not maintained. (These goals
cannot be guaranteed because of intra-label issues and variance among
discourage any local mapping except for a generic mapping aimed at
providing compability with 2003, to prevent interoperability and
security problems. Encourage use of the generic compatibility mapping
to provide for a smooth transition.
Justify unsupported statements in Rationale
Should we fix currently unsupported statements that:
- imply that changes from DISALLOWED to PVALID are harmful. (Rationale)
say that "characters are permanently excluded". (Rationale)
As per John Klensin: "People
have complained about statements that appear to predict what the IETF
will do in the future or to commit it to future actions and those
statements have been removed or corrected as they have been identified."
say that allowing UNASSIGNED in lookup is "(something that is now recognized as a considerable source of risk)". (Defs)
say "because they are actively dangerous in URI, IRI, or similar contexts".
example, for #5, if it is because of visual confusability with URI/IRI
syntax characters, then we should say so and give the paradigm example
(FRACTION SLASH). This does not request a change in the protocol, but just an avoidance of unsubstantiated claims.
Lookup A-Label requirements
Should we require (or recommend) that:
A-Labels be checked for validity when doing lookups?
Valid Label Stability
Should we document that the intent is for valid labels to be stable, that is:
Once a label is valid, it remains valid under any future version of
IDNA, including changes in the registry (CONTEXT). In particular:
A character cannot move from PVALID to CONTEXT, or from CONTEXT to
DISALLOWED, or (importantly) have CONTEXT rules changed in a way that
would invalidate labels.
Labels can move from invalid to valid. This will happen with each new
version of Unicode, for example, as DISALLOWED characters move to
PVALID. It will also happen if CONTEXT rules become more liberal for a
given characters. Only in extremis will it happen that DISALLOWED
characters move to either CONTEXT or PVALID.
Invalid Label Stability
Should we document that:
labels are clearly not stable, in that an invalid label may become
valid in later versions of IDNA, or because of IANA registry updates:
Normally this will be because UNASSIGNED characters become ALLOWED, or because CONTEXT rules are broadened.
In rare cases, this will be because the IETF adds characters to the Exception list that were formerly DISALLOWED.
The following are remaining open issues, that need more work before even a consensus can be reached.
The Context Rules are in very, very rough shape, and will require considerable work before they can be finalized.
Whether to allow Arabic-Indic and Extended Arabic-Indic digits in the same label?
Examining implementations to see whether or not the rules should be tightened based on existing practice as well as the spec.