L2/09-040 - Mark Davis

IDNAbis - Open Issues

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.


Security Considerations

Should we:

  1. document how the compatibility problems between 2003 and 2008 can cause security problems (See http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8 )
  2. 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 bidi implementations).

Local Mapping

Should we:

Strongly 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:

  1. imply that changes from DISALLOWED to PVALID are harmful. (Rationale)
  2. say that "characters are permanently excluded". (Rationale)
    1. 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."
  3. say that allowing UNASSIGNED in lookup is "(something that is now recognized as a considerable source of risk)". (Defs)
  4. say "because they are actively dangerous in URI, IRI, or similar contexts".

For 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:

  1. 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.
  2. 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:
Invalid labels are clearly not stable, in that an invalid label may become valid in later versions of IDNA, or because of IANA registry updates:
  1. Normally this will be because UNASSIGNED characters become ALLOWED, or because CONTEXT rules are broadened.
  2. In rare cases, this will be because the IETF adds characters to the Exception list that were formerly DISALLOWED.

Open Issues

The following are remaining open issues, that need  more work before even a consensus can be reached.

Context Rules

The Context Rules are in very, very rough shape, and will require considerable work before they can be finalized.

Bidi

  1. Whether to allow Arabic-Indic and Extended Arabic-Indic digits in the same label?
  2. Examining implementations to see whether or not the rules should be tightened based on existing practice as well as the spec.