The formal name is Noncharacter_Code_Point.<br><br>Note that there was a one-time cleanup of the Default Ignorable Code Point values in
Unicode 5.1.0, specifically to get it into good shape for IDNA
(<a href="http://www.unicode.org/versions/Unicode5.1.0/">http://www.unicode.org/versions/Unicode5.1.0/</a> - see "Rendering Default
Ignorable Code Points" and the section following). This changed the composition, so if
noncharacters are to be DISALLOWED, then they need to be specifically
mentioned. Functionally, it doesn't make a lot of difference, since the Noncharacter_Code_Point values are immutable, and will always be unassigned (gc=Cn), so they will never be part of valid labels. But they can be specifically excluded by making Noncharacter_Code_Point be specifically DISALLOWED, and for consistency I'd recommend doing that in the tables document. BTW, here are the code points: <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:Noncharacter_Code_Point=True">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:Noncharacter_Code_Point=True</a>:]<br>
<br>That immutability is part of the Unicode stability policies: see <a href="http://www.unicode.org/policies/stability_policy.html#Property_Value">http://www.unicode.org/policies/stability_policy.html#Property_Value</a>. Note that there were some additional constraints on property value stability added in conjunction with Unicode 5.1, largely for IDNA. Note however, that the property value table is organized not by when the policy became effective, but by the earliest version that the policy was true of. That is, if policy was imposed in the Unicode 5.0 timeframe, but actually was true for any version at or after Unicode 3.0, then it is listed under 3.0+.<br>
<br>Note there were also additional code points made Deprecated: see
<a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:Deprecated=True">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:Deprecated=True</a>:]
(Deprecated does not mean removed -- characters are never removed or
moved -- but means that they are strongly discouraged.) None of the
additions affect the tables document.<br><br>Mark<br><br><div class="gmail_quote">On Wed, Apr 30, 2008 at 8:45 AM, Erik van der Poel <<a href="mailto:erikv@google.com">erikv@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The trouble with that 2nd definition is that UnicodeData.txt does not<br>
contain "noncharacters" such as U+FFFF. I would prefer IDNA's<br>
"UNASSIGNED" to exclude Unicode "noncharacters", since they will never<br>
be reassigned to a different meaning.<br>
<br>
I suspect Ken would know how to state this properly. (Thanks in<br>
advance for any input you may provide.)<br>
<font color="#888888"><br>
Erik<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Wed, Apr 30, 2008 at 7:50 AM, Paul Hoffman <<a href="mailto:phoffman@imc.org">phoffman@imc.org</a>> wrote:<br>
> At 12:08 PM +0200 4/30/08, Patrik Fältström wrote:<br>
><br>
> > On 28 apr 2008, at 16.21, Paul Hoffman wrote:<br>
> ><br>
> ><br>
> > > I'm not suggesting changing the defined marks; just making 2064..2069<br>
> UNASSIGNED.<br>
> > ><br>
> ><br>
> > One view could be that as the block 2065..2069 is defined as<br>
> Other_Default_Ignorable_Code_Point, why would it not be DISALLOWED? Because<br>
> when the codepoint is assigned, this might change?<br>
> ><br>
> > Another view that all unassigned codepoints (as defined by not being<br>
> defined in UnicodeData.txt) are UNASSIGNED.<br>
> ><br>
> > What do you all on this list want? Today we are implementing the first.<br>
> ><br>
><br>
> The danger with implementing the first is that the Unicode Consortium folks<br>
> can easily change the boundaries of Other_Default_Ignorable_Code_Point if<br>
> they really want a non-ignorable code point to be at a certain position for<br>
> some bureaucratic or aesthetic reason. We in the IETF do that in some of our<br>
> IANA registries.<br>
><br>
> I think the second may be safer.<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>
><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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark