<span>Here is the </span>doc that I'd put
together on remaining issues:<br><br><a href="http://www.macchiato.com/unicode/idna/open-issues" target="_blank">http://www.macchiato.com/unicode/idna/open-issues</a><br>
<br>(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.)<br><br>A copy below.<br><br>====<br><br><h3 id="goog-ws-page-title-header" class="goog-ws-page-title" style="">
<span id="goog-ws-page-title" dir="ltr">Open Issues</span>
</h3>
<hr size="2" width="100%">
<div>
<p> 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.<br></p><hr size="2" width="100%"><h3><a name="TOC-1"></a><br></h3><h3><a name="TOC-Security-Considerations"></a>Security Considerations
</h3>
Should we:<br>
<br>
<ol><li>
document how the compatibility problems between 2003 and 2008 can cause security problems (See <a href="http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8" title="http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8">http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8</a> )<br>
</li><li>
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). </li></ol>
<br>
<h3><a name="TOC-Local-Mapping"></a>
Local Mapping
</h3>
Should we:<br><br><div style="margin-left: 40px;">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.<br></div>
<br>
<h3><a name="TOC-Justify-unsupported-statements-in-R"></a>
Justify unsupported statements in Rationale
</h3>
Should we fix currently unsupported statements that:<br>
<br>
<ol><li>imply that changes from DISALLOWED to PVALID are harmful. (Rationale)<br>
</li><li>
say that "characters are permanently excluded". (Rationale)</li><ol><li>
As per John Klensin: <i>"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."</i>
</li></ol><li>
say that allowing UNASSIGNED in lookup is <i>"(something that is now recognized as a considerable source of risk)"</i>. (Defs)<br></li><li>
say <i>"because they are actively dangerous in URI, IRI, or similar contexts"</i>.</li></ol>
<br>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). <i>This does not request a change in the protocol, but just an avoidance of unsubstantiated claims.</i><br></div><br>
<h3><a name="TOC-Lookup-A-Label-requirements"></a>
Lookup A-Label requirements
</h3>
Should we require (or recommend) that:<br><br><div style="margin-left: 40px;">A-Labels be checked for validity when doing lookups?<br></div>
<p>
<br>
</p>
<h3><a name="TOC-Valid-Label-Stability"></a>
Valid Label Stability
</h3>
Should we document that the intent is for valid labels to be stable, that is:<br>
<br><div style="margin-left: 40px;">
Once a label is valid, it remains valid under any future version of
IDNA, including changes in the registry (CONTEXT). In particular:<br><br></div>
<ol style="margin-left: 40px;"><li>
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.<br>
</li><li>
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.</li></ol>
<br>
<h3><a name="TOC-Invalid-Label-Stability"></a>
Invalid Label Stability
</h3>
Should we document that:<br><div style="margin-left: 40px;">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: </div><ol style="margin-left: 40px;"><li>
Normally this will be because UNASSIGNED characters become ALLOWED, or because CONTEXT rules are broadened.
</li><li>
In rare cases, this will be because the IETF adds characters to the Exception list that were formerly DISALLOWED.
</li></ol>
<div style="margin-left: 40px;"><br></div>
<hr size="2" width="100%">
<h2><a name="TOC-Open-Issues"></a>
Open Issues
</h2>
The following are remaining open issues, that need more work before even a consensus can be reached.<br>
<br>
<h3><a name="TOC-Context-Rules"></a>
Context Rules
</h3>
The Context Rules are in very, very rough shape, and will require considerable work before they can be finalized.<br>
<h3><a name="TOC-Bidi"></a>
Bidi
</h3>
<ol><li>
Whether to allow Arabic-Indic and Extended Arabic-Indic digits in the same label?
</li><li>
Examining implementations to see whether or not the rules should be tightened based on existing practice as well as the spec.
</li></ol><br><br clear="all">Mark<br>