I sent this almost a month ago, and got no reply. I'm assuming that the
lack of response was due to the holidays, and some discussion or
response for these items will be forthcoming soon.<br><br>Mark<br><br><div class="gmail_quote">On Dec 13, 2007 7:48 PM, Mark Davis &lt;<a href="mailto:mark.davis@icu-project.org">mark.davis@icu-project.org</a>&gt; wrote:
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><h1><a title="http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-05.txt" href="http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-05.txt" target="_blank">
</a> </h1>
<h2>Overview.</h2>Many nice improvements to the text.<br>
<br><i>This list does not list what was already commented on for </i><a title="http://www.ietf.org/internet-drafts/draft-klensin-idnabis-protocol-02.txt" href="http://www.ietf.org/internet-drafts/draft-klensin-idnabis-protocol-02.txt" target="_blank">

<i>draft-klensin-idnabis-protocol-02.txt</i></a><i> and </i><a title="http://www.ietf.org/internet-drafts/draft-faltstrom-idnabis-tables-03.txt" href="http://www.ietf.org/internet-drafts/draft-faltstrom-idnabis-tables-03.txt" target="_blank">

<i>draft-faltstrom-idnabis-tables-03.txt</i></a><br style="font-style: italic;"><br style="font-style: italic;">Issues-1.
IDNAbis has a major backwards compatibility issue with IDNA2003:
thousands of characters are excluded that used to be valid. What reason
might people have to believe that despite the terms NEVER and ALWAYS
that some future version, IDNAbis-bis, might not also do the same? <br><br>Issues-2.
IDNA provided for backwards compatibility, by disallowing Unassigned
characters in registration, but allowing them in lookup. That let old
clients work despite new software. While once we update to U5.1 that is
not as much of a problem, it should be made clear why this change is
made. <br><br>Issues-3. In general, whenever a statement is made about
some class of characters causing a problem, at least one clear example
should be provided, as in<a href="http://www.ietf.org/internet-drafts/draft-alvestrand-idna-bidi-01.txt" target="_blank"> draft-alvestrand-idna-bidi-01.txt</a> <br><br>Issues-4.
I would strongly suggest separating all of the &quot;why did we do this&quot; and
&quot;how is it different from IDNA2003&quot; into a separate document. It will
be of only historical interest after this becomes final, and will then
only clutter the document.<br><br>
<h2>Details.</h2><br>Issues-5.<br><pre>   IDNA uses the Unicode character repertoire, which avoids the<br>   significant delays that would be inherent in waiting for a different<br>   and specific character set be defined for IDN purposes, presumably by
<br>   some other standards developing organization.<br></pre>
<p>Seems odd. There are no other contenders in the wings. Would be
better, if this has to be said, to just cite other IETF documents
describing the reasons for using Unicode. </p><br>Issues-6.<br><pre>   To improve clarity, this document introduces three new terms.  A<br>   string is &quot;IDNA-valid&quot; if it meets all of the requirements of this<br>

   specification for an IDNA label.  It may be either an &quot;A-label&quot; or a<br>   &quot;U-label&quot;, and it is expected that specific reference will be made to<br>   the form appropriate to any context in which the distinction is
<br>   important.<br>...<br>   A &quot;U-label&quot; is an IDNA-valid string of<br>   Unicode-coded characters that is a valid output of performing<br>   ToUnicode on an A-label, again regardless of how the label is<br>   actually produced.
<p>These definitions appear circular, so they need to be teased out a bit. </p>
<div><pre>   Depending on the system involved, the major difficulty may not lie in<br>   the mapping but in accurately identifying the incoming character set<br>   and then applying the correct conversion routine.  It may be
<br>   especially difficult when the character coding system in local use is<br>   based on conceptually different assumptions than those used by<br>   Unicode about, e.g., how different presentation or combining forms<br>

   are handled.  Those differences may not easily yield unambiguous<br>   conversions or interpretations even if each coding system is<br>   internally consistent and adequate to represent the local language<br>   and script.
</pre>I suggest the following rewrite:<br>
<p style="margin-left: 40px;">The main difficulty typically is that of&nbsp;
accurately identifying the incoming character set so as to apply the
correct conversion routine. Theoretically, conversion could be
difficult if the non-Unicode character encoding system were based on
conceptually different assumptions than those used by Unicode about,
e.g., how different presentation or combining forms are handled. Some
examples are the so-called &quot;font-encodings&quot; used on some Indian
websites. However, in modern software, such character sets are rarely
used except for specialized display. </p></div>
<p>&nbsp;</p>Issues-8.<br><pre>   That, in turn, indicates that the script community<br>   relevant to that character, reflecting appropriate authorities for<br>   all of the known languages that use that script, has agreed that the
<br>   script and its components are sufficiently well understood.  This<br>   subsection discusses characters, rather than scripts, because it is<br>   explicitly understood that a script community may decide to include
   some characters of the script and not others.<br><br>   Because of this condition, which requires evaluation by individual<br>   script communities of the characters suitable for use in IDNs (not<br>   just, e.g., the general stability of the scripts in which those
<br>   characters are embedded) it is not feasible to define the boundary<br>   point between this category and the next one by general properties of<br>   the characters, such as the Unicode property lists.</pre>There
is no justification given for this process. Moreover, it will be doomed
to failure. Merely the identification of &quot;script communities&quot; is an
impossible task. Who speaks for the Arabic script world? Saudi Arabia
(Arabic)? Iran (Persian,...)? Pakistan (Urdu,...)?, China (Uighur,...)?<br><br>Issues-9.<br><pre>      it is removed from Unicode.<br></pre>
<p>(multiple instances) </p>
<p>This is not necessary; characters aren&#39;t removed from Unicode. If
you really have to have it, then add &quot;(however, the Unicode stability
policies expressly forbid this)&quot; </p><br>
<p>Issues-10.<br></p><pre>   Applications are expected to not treat &quot;ALWAYS&quot; and &quot;MAYBE&quot;<br>   differently with regard to name resolution (&quot;lookup&quot;).  They may<br>   choose to provide warnings to users when labels or fully-qualified
<br>   names containing characters in the &quot;MAYBE&quot; categories are to be<br></pre>
<p>In practice, expecting applications to treat these differently is
wishful thinking; especially if it seems Eurocentric to users (see
other notes on MAYBE). In practice, registries always have the ability
to filter characters out. See above on removing Maybe.<br>
<p><br></p>Issues-11. <pre>   5.1.3.  CONTEXTUAL RULE REQUIRED<br></pre>
<p>I know what the point is supposed to be (and don&#39;t disagree), but this section was very hard to make out.</p>
<p>Issues-12.<br></p><pre>   Characters that are placed in the &quot;NEVER&quot; category are never removed<br>   from it or reclassified.  If a character is classified as &quot;NEVER&quot; in<br>   error and the error is sufficiently problematic, the only recourse is
<br>   to introduce a new code point into Unicode and classify it as &quot;MAYBE&quot;<br>   or &quot;ALWAYS&quot; as appropriate.<br></pre>
<p>The odds of this happening are extremely low. Anything in Never has to be extremely certain.</p><br>Issues-13.<br><pre>   Instead, we need to have a variety of approaches that, together,<br>   constitute multiple lines of defense.
<p>Defense against what? Without examples, it is hard to say what the problems are.</p><br>
<p>Issues-14.<br></p><pre>   Applications MAY<br>   allow the display and user input of A-labels, but are not encouraged<br>   to do so except as an interface for special purposes, possibly for<br>   debugging, or to cope with display limitations.  A-labels are opaque
<br>   and ugly, and, where possible, should thus only be exposed to users<br>   who absolutely need them.  Because IDN labels can be rendered either<br>   as the A-labels or U-labels, the application may reasonably have an
<br>   option for the user to select the preferred method of display; if it<br>   does, rendering the U-label should normally be the default.<br><br></pre>
<p>Add: <br>
<p>It is, however, now common practice to display a suspect U-Label (such as a mixture of Latin and Cyrillic) as an A-Label.</p>
<p><br></p>Issues-15.<pre>   6.3.  The Ligature and Digraph Problem<br><br>   There are a number of languages written with alphabetic scripts in<br>   which single phonemes are written using two characters, termed a<br><br>

   &quot;digraph&quot;, for example, the &quot;ph&quot; in &quot;pharmacy&quot; and &quot;telephone&quot;.<br></pre>
<p>The text has been improved considerably from earlier versions, but
the whole issue is just a special case of the fact that words are
spelled different ways in different languages or language variants. And
it has really nothing to do with ligatures and diagraphs. The same
issue is exhibited between <a href="http://theatre.com" target="_blank">theatre.com</a> and <a href="http://theater.com" target="_blank">theater.com</a> as between a
Norwegian URL with ae and a Swedish one with a-umlaut.</p><br>
<p>So if you retain this section, it should be recast as something like <br></p>
<p style="margin-left: 40px;">6.3 Linguistic Expectations</p>
<div style="margin-left: 40px;"><br>

<p style="margin-left: 40px;">Users often have certain expectations
based on their language. A Norwegian user might expect a label with the
ae-ligature to be treated as the same label using the Swedish spelling
with a-umlaut. A user in German might expect a label with a u-umlaut
and the same label with &quot;ae&quot; to resolve the same. For that matter, an
English user might expect &quot;<a href="http://theater.com" target="_blank">theater.com</a>&quot; and &quot;<a href="http://theatre.com" target="_blank">theatre.com</a>&quot; to resolve
the same. [more in that vein].<br></p>
<div style="margin-left: 40px; font-family: Courier New;">          there is no evidence that<br>
          they are important enough to Internet operations or<br>
          internationalization to justify large numbers of special cases<br>
          and character-specific handling (additional discussion and<br>
I suggest the following wording instead:<br>
<div style="margin-left: 40px;"><span style="font-family: Courier New;">          there is no evidence that</span><br style="font-family: Courier New;">
<span style="font-family: Courier New;">          they are important enough to Internet operations or</span><br style="font-family: Courier New;">
<span style="font-family: Courier New;">          internationalization to justify inclusion (additional discussion and</span><br>
<p>It doesn&#39;t actually involve &quot;large numbers of special cases&quot;, there
are a rather small percentage of demonstrable problems in the
symbol/punctuation area. What we could say is that there is general
consensus that removing all but letters, digits, numbers, and marks
(with some exceptions) causes little damage in terms of backwards
compatibility, and does remove some problematic characters like
fraction slash.<br></p>
<p>&nbsp;</p>Issues-17.<br><pre>   For example, an essential<br>   element of the ASCII case-mapping functions is that<br>   uppercase(character) must be equal to<br>   uppercase(lowercase(character)).<br><br></pre>
<p>Remove or rephrase. It is a characteristic, but not an essential
one. In fact, case mappings of strings are lossy; once you lowercase
&quot;McGowan&quot;, you can&#39;t recover the original.</p>
<p><br></p>Issues-18.<br><pre>   o  Unicode names for letters are fairly intuitive, recognizable to<br>      uses of the relevant script, and unambiguous.  Symbol names are<br>      more problematic because there may be no general agreement on
<br>      whether a particular glyph matches a symbol, there are no uniform<br>      conventions for naming, variations such as outline, solid, and<br></pre>
<p>Actually, the formal Unicode names are often far from intuitive to
users of the relevant script. That&#39;s because the constraints of using
ASCII for the name, to line up with ISO standards for character
<p>This section is not really needed. The use of I&lt;heart&gt;NY.com
is not really problematic; the main justification for removing it is
that we don&#39;t think it is needed (and has not been used much since IDNA
was introduced). Better to just stick with that.</p>
<p><br></p>Issues-19<br><pre>   11.  IANA Considerations<br><br>   11.1.  IDNA Permitted Character Registry<br><br>   The distinction between &quot;MAYBE&quot; code points and those classified into<br>   &quot;ALWAYS&quot; and &quot;NEVER&quot; (see Section 5) requires a registry of
<br>   characters and scripts and their categories.  IANA is requested to<br></pre><br>
<p>Expecting an IANA registry to maintain this is setting it up for
failure. If this were to be done, precise and lengthy guidance as to
the criteria for removing characters (moving to NEVER) would have to be
supplied, because of the irrevocable nature of this step. The odds of a
registry being able to perform this correctly are very small.<br></p>
<p>The best alternative would be to simply have all the non-historic scripts have the same status in <a title="http://www.ietf.org/internet-drafts/draft-faltstrom-idnabis-tables-03.txt" href="http://www.ietf.org/internet-drafts/draft-faltstrom-idnabis-tables-03.txt" target="_blank">

<i>draft-faltstrom-idnabis-tables-03.txt</i></a>, by moving the non-historic scripts to the same status as Latin, Greek, and Cyrillic.</p><br>
<p>The second best would be to have the Unicode consortium make the determinations (and take the heat for objections).<br>
<p><br></p>Issues-20 <pre>   Some specific suggestion<br>   about identification and handling of confusable characters appear in<br>   a Unicode Consortium publication [???]<br><br>Use: [<a name="116d6c49dc02e122_UTR36">
UTR36</a>]<br>      UTR #36: 
<i>Unicode Security Considerations</i><br>      <a href="http://www.unicode.org/reports/tr36/" target="_blank">http://www.unicode.org/reports/tr36/</a></pre>
</blockquote></div><br><br clear="all"><br>-- <br>Mark