Reserved general punctuation

Mark Davis mark.davis at icu-project.org
Thu May 1 22:29:48 CEST 2008


>  If they assign
a letter relevant for IDNA in this position it is madness,
a concept of "blocks" has to mean something.

This is presuming something which is not the case for the standard. Except
in certain cases, blocks are simply an organizational device, not anything
more. In general, you cannot depend on only dingbats being assigned to in a
dingbat block.

However, there is an immutable property that does guarantee that nothing
letterlike will be included in certain unassigned areas of code points: it
is Pattern_Syntax:

 http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:Pattern_Syntax=True
:]

For more about this, see http://www.unicode.org/reports/tr31/

Mark

On Wed, Apr 30, 2008 at 7:26 PM, Frank Ellermann <
hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com> wrote:

> Paul Hoffman wrote:
>
> > The danger with implementing the first is that the Unicode
> > Consortium folks can easily change the boundaries of
> > Other_Default_Ignorable_Code_Point if they really want a
> > non-ignorable code point to be at a certain position for
> > some bureaucratic or aesthetic reason.
>
> What I had in mind, unassigned code points in the dingbats
> block, would best be described as "reserved".  They can
> leave it unassigned forever.  They can smuggle in some new
> dingbats unrelated to the original unassigned symbol which
> was found to be already listed elsewhere.  If they assign
> a letter relevant for IDNA in this position it is madness,
> a concept of "blocks" has to mean something.
>
> The table generator scripts could list such critical code
> points, maybe the Unicode folks are willing to guarantee
> to be not mad (with a new persistent property or similar).
>
> > I think the second may be safer.
>
> The meaning of such unassigned gaps *within* blocks (not
> at the beginning or end) is quite obvious, the "safer"
> approach could create convoluted abuse opportunities (?)
>
>  Frank
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080501/d61ff474/attachment-0001.html


More information about the Idna-update mailing list