Open issues

[Mark Davis]

Here is the doc that I'd put together on remaining issues:

http://www.macchiato.com/unicode/idna/open-issues

(This message doesn't imply that Vint is in agreement any particular issues,
just that it is available for discussion. Both this and the label
categorization were from a little while back, before Paul's message, but I
hadn't had a chance to put them out.)

A copy below.

====

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.



Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090121/36ecffac/attachment.htm