Subject: Re: IDN security violation? Please comment

From: Bruce Lilly <[email-masked]>
Date: Mon, 21 Feb 2005 13:20:54 -0500

>  Date: 2005-02-18 00:51
>  From: Martin Duerst <[email-masked]>

> At 11:02 05/02/12, Bruce Lilly wrote:
> 
>  >While I do not dispute that some mobile devices might use some subset
>  >of some version of Unicode for text in some languages, my point was,
>  >in response to John Klensin's "Until and unless every one of us has a
>  >keyboard that permits easy input of every Unicode character", that not
>  >only do I not expect to have a keyboard permitting *easy* entry (no,
>  >that doesn't mean "Grafiti" or "Decuma") of *every* Unicode character
>  >any time soon, I don't expect it *ever*, because the Unicode code space
>  >is expanding (in contradiction to the original Unicode Design Principles)
>  >faster than the available memory space on low-power, compact, mobile
>  >devices.
> 
> Bruce - Would you care to supply some sources for the argument above?
> Computer power, including mobile devices, is still pretty much
> increasing exponentially. Unicode space allocation has never
> increased exponentially, and is slowing down.

The low end of computing devices -- what one should take into account
per RFC 1958 section 3.1 -- has remained fairly constant in terms of
available memory and processor power (price, power consumption,
physical size, etc. have declined).  Also, bear in mind that these
devices may have a useful life of a decade or more, and that
(software/firmware/hardware) upgrades for some older devices still
in use might not be available, or might not be applied by some users.
Regarding keyboard input, again the capabilities have remained fairly
static at the low end, with input limited to about a dozen keys with
multiple characters overloaded onto each key, and limited character
selection.  Unicode code size increased overnight by more than 4
orders of magnitude (a factor of 65536) when it went from 16 bits
65536 code points) to 32 bits (over 4 billion code points) at the
same time that it incorporated musical notation etc. in contradiction
to the Unicode Design Principles.

So Unicode *everywhere* isn't likely to happen because there are and
will continue to be low end devices that simply don't have the
capacity to support normalization tables etc. for billions of code
points -- now perhaps some of those low-end devices might be able
to support Unicode version 2.1, but then there are the version
incompatibility issues that I mentioned.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 21 Feb 2005 23:48:37 +0100

--On mandag, februar 21, 2005 13:20:54 -0500 Bruce Lilly <[email-masked]> 
wrote:

> Unicode code size increased overnight by more than 4

Bruce,

it may be nice to check your facts before you trot them out....

at the moment (4.0.1), Unicode has approx. 96.000 codepoints, and is, 
according to Unicode, "running out of scripts to encode".

The range of Unicode characters is defined in 
<http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf>, page 24, as 0 to 
10FFFF(hex), which is 1.114.111 decimal - quite a bit larger than 65536, 
but quite a bit smaller than 4 billion.

(In my personal opinion, the 16-bit limit was a stupid one in the first 
place - it's been clear for a long time that 65.536 characters would not be 
enough to encode the Han characters. Which is why I never believed in UCS-2 
as a rational design point.)

And - if you want to call Unicode to task for violating its design 
principles, it might be nice to say which principle you claim it violates, 
and which one was violated by including musical notes, but not violated by 
(say) Dingbats.

Harald, who happens to be a board member of the Unicode consortium (but 
does not at all speak for the consortium)

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 22 Feb 2005 16:13:58 +0100

Bruce Lilly wrote:

> Unicode code size increased overnight by more than 4 orders
> of magnitude (a factor of 65536) when it went from 16 bits
> 65536 code points) to 32 bits (over 4 billion code points)

AFAIK it's only a factor 17 up to u+10FFFF, and the relevant
standards like STD 63 eplicitly restrict themselves to this
UTF-16 compatible range incl. many "private use" code points,
surrogates, (yet) unassigned code points, non-characters, etc.

> Unicode *everywhere* isn't likely to happen

Your points are valid even without this "31 bits horror trip".

                      Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 21 Feb 2005 15:16:26 -0800

Hi -

> From: "Bruce Lilly" <[email-masked]>
> To: <[email-masked]>
> Cc: "Martin Dürst" <[email-masked]>
> Sent: Monday, February 21, 2005 10:20 AM
> Subject: Re: IDN security violation? Please comment
...
> 65536 code points) to 32 bits (over 4 billion code points) at the
...

Only code points from U+0000 to U+10FFFF are permitted.
That's less than 32 bits worth of possible code point values.
See http://www.unicode.org/faq/basic_q.html#19 for details.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 23 Feb 2005 01:48:03 +0100

Bye, Frank