<div><span style="font-family:'times new roman',serif">A quick note. </span></div><div><span style="font-family:'times new roman',serif"><br></span></div><div><pre style="line-height:1.2em;margin-top:0px;margin-bottom:0px;font-size:13px">
A sequence of multiple code points can be specified as a variant of a
   single code point.  For example, the sequence of "o" then "e" can be
   specified as a variant for an "o with umlaut" (U+00F6) as follows:

   <char cp="00F6">
     <var cp="006F 0065"/>
   </char></pre><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div><span><br></span></div><div><font face="times new roman,serif">It should be possible for a sequence to map to a character or sequence, rather than restricting to single code points. So the cp in either case should allow space-delimited hex codes. Eg (where x and y are code points)</font></div>
<div><font face="times new roman,serif"><br></font></div><div><pre style="font-size:13px;line-height:1.2em;margin-top:0px;margin-bottom:0px">   <char cp="x y">
     <var cp="y x"/>
   </char></pre></div><div><font face="times new roman,serif">===</font></div><div><font face="times new roman,serif"><br></font></div><div><pre style="line-height:1.2em;margin-top:0px;margin-bottom:0px;font-size:13px">
<char cp="200c">
     <var cp="0000"/>
   </char></pre></div><div><font face="times new roman,serif"><br></font></div><div><font face="times new roman,serif">I think this would be less prone to errors as simply</font></div><div><pre style="font-size:13px;line-height:1.2em;margin-top:0px;margin-bottom:0px">
<char cp="200c">
     <var cp=""/>
   </char></pre><pre style="font-size:13px;line-height:1.2em;margin-top:0px;margin-bottom:0px"><br></pre><pre style="font-size:13px;line-height:1.2em;margin-top:0px;margin-bottom:0px">===</pre></div><div><font face="times new roman,serif"><br>
</font></div><div><pre style="line-height:1.2em;margin-top:0px;margin-bottom:0px;font-size:13px">     <var cp="0673" when="arabic-isolated"/>
</pre></div><div><br></div><div>The spec needs to have an unambiguous way to determine when a character satisifies the 'when' clause.</div><div><br></div><div><font face="'times new roman', serif"><div style="margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
</div></font><span><hr></span></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><a href="https://plus.google.com/114199149796022210033" target="_blank">Mark</a></div>
<div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div><br>
<br><br><div class="gmail_quote">On Thu, Mar 1, 2012 at 11:15, Kim Davies <span dir="ltr"><<a href="mailto:kim.davies@icann.org">kim.davies@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Colleagues,<br>
<br>
I have posted a first draft regarding a format that could be used for representing IDN Tables in XML to the I-D Repository:<br>
<br>
        <a href="https://datatracker.ietf.org/doc/draft-davies-idntables/" target="_blank">https://datatracker.ietf.org/doc/draft-davies-idntables/</a><br>
<br>
After discussion with a number of folks that felt this would be good work to undertake, I've put together a first cut which is not comprehensive, but I think goes some way toward a potential format.<br>
<br>
Unless there is interest in this being a more formal activity, my assumption is to aim to publish the final result independently as an Informational RFC. However, the mechanism of publication is secondary to coming up with something useful that would benefit TLD registries and other implementors. A list of design goals, from the document, is as follows:<br>

<br>
        • MUST be in a format that can be implemented in a reasonably straightforward manner in software;<br>
        • The format SHOULD be able to be checked for formatting errors, such that common mistakes can be caught;<br>
        • An IDN Table MUST be able to express the set of valid code points that are allowed for registration under a specific zone administrator's policies;<br>
        • MUST be able to express computed alternatives to a given domain name based on a one-to-one, or one-to-many relationship. These computed alternatives are commonly known as "IDN variants";<br>
        • IDN Variants SHOULD be able to be tagged with specific categories, such that the categories can be used to support registry policy (such as whether to list the computed variant in the zone, or to merely block it from registration);<br>

        • IDN Variants MUST be able to stipulated based on contextual information. For example, specific variants may only be applicable when they follow another specific code point, or when the code point is displayed in a specific presentation form;<br>

        • The data contained within the table MUST be unambiguous, such that independent implementations that utilise the contents will arrive at the same results;<br>
        • IDN Tables SHOULD be suitable for comparison and re-use, such that one could easily compare the contents of two or more to see the differences, to merge them, and so on.<br>
        • As many existing IDN Tables are practicable SHOULD be able to be migrated to the new format with all applicable logic retained.<br>
<br>
It is explicitly NOT the goal of this format to:<br>
<br>
        • Stipulate what code points should be listed in an IDN Table by a zone administrator. What registration policies are used for a particular zone is outside the scope of this memo.<br>
        • Stipulate what a consumer of an IDN Table must do when they determine a particular domain is valid or invalid; or arrive at a set of computed IDN variants. IDN Tables are only used to describe rules for computing code points, but does not prescribe how registries and other parties utilise them.<br>

<br>
I'd appreciate any feedback.<br>
<br>
cheers,<br>
<br>
kim<br>
<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</blockquote></div><br></div>