Subject: [iucg] [vip] Draft on IDN Tables in XML

From: JFC Morfin <[email-masked]>
Date: Fri, 02 Mar 2012 14:14:59 +0100

http://iucg.org/wiki/IUWW_Draft-Davis-IDNTables

There is a proposition of Draft by Kim Davies (ICANN) for IDN Tables 
in XML format. The discussion is reproduced on the talk page.
This work seems interesting and could be used as a root model to 
extend for "rootlocale" files in the MDRS documenting the relational 
space of an Internet TLD.

There is however two missing metadata:

- the encoding scheme (unless we accept Unicode as a default value)
- the CLASS (unless we accept the ICANN/NTIA CLASS "IN" as a defaulf value)

jfc

---

From: JFC Morfin <[email-masked]>
Date: Tue, 06 Mar 2012 03:52:03 +0100

At 13:22 05/03/2012, Dillon, Chris wrote:
>Dear colleagues,
>
>I have been reading this correspondence with Chinese in mind and 
>would like to raise some questions.
>
>This is a case where there are two major forms of a script 
>(Simplified Chinese used, for example in mainland China and 
>Singapore) and Traditional Chinese, used elsewhere. Many characters 
>are the same everywhere but a subset of characters have been 
>abbreviated in the case of Simplified Chinese.
>
>There is an additional complication in the form of a small number of 
>characters that are only used e.g. in Hong Kong (for Cantonese) or 
>Singapore. What would be the best way to include those?
>
>In the RFC3743-style tables at 
>http://www.iana.org/domains/idn-tables/ typically Simplified Chinese 
>Preferred Variants and Traditional Chinese Preferred Variants have 
>their own columns.
>
>http://tools.ietf.org/html/rfc5646 gives the following example tags 
>for Chinese; which should be standard for Chinese in this XML-based system?

At 20:29 05/03/2012, Dmitry Belyavsky wrote:
>Greetings!
>
>What about "one-direction" variants? For example, Russian letter £ 
>can be replaced with Å and often is, but the letter Å can not be 
>replaced with £.
>
>Thank you!

Chris and Dmitry,

I answer this privately not to raise unnecessary controversy. It is 
natural that ICANN works for their own business community and they 
make it plain when asked. As lead Internet Users (http://iutf.org and 
our liaison to the IETF http://iucg.org/wiki), we have the same and 
more needs:

1. a visual confusion algorithm against homography based on bitmaps 
(anti-phishing)
2. complete variant coverage, i.e. visual, combinational (several 
code points), orthotypographic (syntaxic [one way/two ways] 
correspondence and majuscules in a considered *language*), and 
cultural (semantic synonymies)
3. for every CLASS. There are 65,536 classes 
<http://www.iana.org/assignments/dns-parameters>http://www.iana.org/assignments/dns-parameters; 
ICANN is only concerned with CLASS 1 "IN".
4. for the entire WDNS (the "whole digital name system" of the whole 
digital ecosystem (WDE), further and beyond the sole Internet).

We, therefore, need two tables:

- UNIGRAPH, which is the table that you refer to, in a graphic bitmap 
format that permits computational comparisons.
- UNISIGN, which is a table that will document all the signs being 
used in the WDNS syntax.

1. We have parts of these tables,
2. However, we were unable to find a single complete Unicode table, 
including every code point and its description.
2. There exist different bitmap tables. Do we understand correctly 
that there is a Chinese official publication that documents the Han 
and Han bitmap sets?

Our target is to publish the table that you are looking for, with 
bitmaps, degree of confusability, ISO 3166 related specifics, ISO 
639/Linguasphere cross relations, IDNA2008 level, and ISO 10646 
definitions. And then to work on a multi-degree of confusability algorithm.

However, this part is of a complete review of the Internet Use 
architecture that calls for new collaborative working structures. I 
am documenting:

- that 
cooperation: 
<http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt>http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt
- the architectural framework : 
<http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt>http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt
- and preparing the reset of our working alliance with MAAYA and 
Linguasphere on the matter.

In this process, we will reactivate the UNIGRAPH and UNISIGN sites as 
FLOSS MDRS (WDE's continuation of the IANA).

Let us know if you are interested, and we will keep you posted.
Best
jfc

---

From: JFC Morfin <[email-masked]>
Date: Tue, 06 Mar 2012 20:19:40 +0100

Chris,
thank you for your response. Comments embedded in the text.

At 12:12 06/03/2012, Dillon, Chris wrote:
>However, I would like to pick up a couple of points at this stage.
>1. I feel that the visual confusion algorithm will need to go beyond 
>bitmaps. For example, in Chinese and especially in Arabic, there are 
>characters which differ by only one dot but are regarded as being 
>without visual confusion by the communities. The ideal algorithm 
>would be programmable to take into account this sort of thing that 
>would be missed by an entirely bitmap-based approach.

Actually, I am afraid there is no other basis than bitmaps. This is 
to do with the way the "HSS/NSP" (Homo Sapiens Sapiens/Natural 
Semantic Processor) works internally. The reason why is that for 
every other sense than vision, the brain takes time elements into 
account when it evaluates things, except in vision where it may not. 
This means that pattern (like in a flash) recognition is to be used, 
not sequence recognition (several chained patterns in sequence, 
vectors, history of the writing movement, etc.).

At the same time, this should not be a blocking problem. Because when 
Chinese and Arabs differentiate characters, their brains just do 
that. We are not at this stage yet, but I suppose that homographic 
confusion is related to fuzziness, and fuzziness may blur details to 
the point that a small point would disappear. One may imagine 
multiple programmatic responses:

1. there is a matter of density of the bitmap. How many bits in a 
dot, how many bits is the fuzziness threshold.
2. there is a matter of fount. The purpose is not for the bitmap to 
be beautiful, but to be not confusable, and sortable by the 
algorithm: the dot in the bitmap must be thick (width in bits) enough.
3. there is a matter of algorithmic conception: for example taking 
into account shape recognition to be more precise in cases one knows 
a confusion might result from the algorithm itself.
4. there is a matter of scientific approach in terms of pattern 
recognition, i.e. proceeding mathematically, informatically, or like 
a human brain (which only uses a very tiny part of the data it gets, 
but has learned to use it well: it does this not to be confused by 
the "noise", i.e. what we want ourselves, so there must be some 
common interest strategies to tackle the issue).

There MUST absolutely be no false homographic confusion. This 
algorithm should be used to register CLASS 0 digital names, to make 
sure that in any other CLASS there is no confusing labels. It is 
likely that if this target is accepted by TLD registries the 
algorithm will be used for passports, banking purposes, secure 
access, etc. and become an ISO standard. So, many people will most 
probably work on it. My personal target is just to bootstrap the 
concept, create a fuss over it between ICANN and Google+ as part of 
the Internet+ stratum architecture - for it to be noticed, and 
properly worked on by Governments and International Organizations as 
part of the resolution of all the changes the identification of the 
Internet+ architectural framework introduces in the whole digital 
ecosystem use (I did not invent it, I just try to document it, the 
way it already is in the Internet architecture, before it results in 
a real mess).

However, I fully agree with you: I do not think this will be achieved 
in one day, but one has to start. This means trying, testing 
different ways to check false confusions. Gain experience.

Today the only standard we have is ISO 10646, that is influenced by 
Unicode. It is great for typographer (i.e. people interested in the 
printer's side) not for orthotypographer (i.e. people considering the 
reader's side). We do not want to change it: we want to use it better.

>2. Semantic synonymies. I am familiar with what the VIP Greek Case 
>Study wrote in this area, but would be interested in finding out 
>more about the case for semantic synonymies. Incidentally, there is 
>also a paper by Jack Halpern which mentions possible Chinese cases 
>(The pitfalls of Chinese to Chinese conversion).

Do you have an URL? I found: http://www.cjk.org/cjk/joa/synclir.htm.

1) I add another kind of synonymy as being "polynymy", i.e. 
cross-language strict pragmatic synonymy.

2) As a remark, I am personally interested in the networked computer 
assisted facilitation pragmatic aspects, and how to support specific 
needs by subsidiarity. This means that I am eager of the details, not 
to address them directly, but to make sure that the final general 
concepts of the architecture will permit to address them seamlessly 
at their proper place, when they are needed, without breaking the 
holistic equilibrium (Universe harmony).

The "Mecalanguage, Telecoms, Internet, Internet+, Intersem" 
architectural sequence MUST be elegant if to be efficient. This IETF 
"MUST" results from the few existing (but truly inspired) 
architectural RFCs. They have defined this elegance so far as 
multilayered (RFC 1121), plug to plug robust (RFC 761), end to end 
adaptative (RFC 1958), over all simple (RFC 3439) and fringe to 
fringe subsidiary (IDNA2008).

The two most challenging ones are the mecalanguage (how to produce an 
utterance) and the Intersem (how to obtain intercomprehension) 
strata. This is mostly terra incognita. At this stage we are actually 
discussing the Internet+ stratum, (how to make the content of that 
utterance interintelligible).

What ITU and IETF have covered is "how to reliably transport the 
utterance" (Internet datagram) and "how to efficiently transmit the 
bytes of these datagrams". And ICANN has introduced an unstable way 
of making money with it :-)

>3. One of the members of the Chinese Case Study, Professor Joe Zhang 
>of Unihan Digital Technology Co. presented me with a copy of 
>"Zhongrihan changyong hanzi duibi fenxi" ISBN 978-7-100-06595-5 
>which is a comparative list of characters used in Chinese, Japanese 
>and Korean. He was the chief editor. It includes Unicode code 
>points, but not bitmaps. I shall e-mail him and ask him if he knows 
>whether a list with bitmaps exists.

Thank you.
Best
jfc

>Regards,
>
>Chris.
>==
>Research Associate in Linguistic Computing, Dept of Information 
>Studies, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 
>31599) ucl.ac.uk/dis/people/chrisdillon
>
>Chris and Dmitry,
>
>make it plain when asked. As lead Internet Users (http://iutf.org 
>and our liaison to the IETF http://iucg.org/wiki), we have the same 
>and more needs:
>
>cultural (semantic synonymies) 3. for every CLASS. There are 65,536 
>classes 
>- UNIGRAPH, which is the table that you refer to, in a graphic 
>bitmap format that permits computational comparisons.
>In this process, we will reactivate the UNIGRAPH and UNISIGN sites 
>as FLOSS MDRS (WDE's continuation of the IANA).
>

---

From: "J-F C. Morfin" <[email-masked]>
Date: Wed, 07 Mar 2012 14:21:17 +0100

Kim, Patrick,

this is what I wanted to underline: a graphical standard cannot be 
dependent on the external dispaly tool. ISO standards are depending 
on your wallet size. IETF standards want to be independent from the 
printer harware. Nothing in protocols forces me to use an UTF-8 
keyboard or printer (as long as punycode is supported somewhere down 
the line, in the IDNA case).

What is looked for is a fool printer proof solution. To my knowledge 
only raster bitmaps can provide this to the printer and to the brain 
? Hence the need of a complete Unicode raster table.
Best
jfc

At 08:10 07/03/2012, Patrik Fältström wrote:

>On 7 mar 2012, at 02:32, JFC Morfin wrote:
>
> > At 01:56 07/03/2012, Kim Davies wrote:
> >> Ä™ [U+0101] LATIN SMALL LETTER A WITH MACRON
> >> Ä" [U+0113] LATIN SMALL LETTER E WITH MACRON
> >> Ä« [U+012B] LATIN SMALL LETTER I WITH MACRON
> >> ÅŸ [U+014D] LATIN SMALL LETTER O WITH MACRON
> >> Å« [U+016B] LATIN SMALL LETTER U WITH MACRON
> >>
> >> kim
> >
> > Seems there is a problem with the display.
>
>Yes, problem with the display, but it was a correctly encoded email message:
>
>Content-Type: text/plain; charset="utf-8"
>Content-Transfer-Encoding: base64
>
>    Patrik
>
>_______________________________________________
>Idna-update mailing list
>[email-masked]
>http://www.alvestrand.no/mailman/listinfo/idna-update

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Mar 2012 15:19:14 +0100

On 7 mar 2012, at 14:21, J-F C. Morfin wrote:

> Nothing in protocols forces me to use an UTF-8 keyboard or printer (as long as punycode is supported somewhere down the line, in the IDNA case).

As the email from Kim was explicitly tagged with information that it was in charset UTF-8 it is possible for you, and up to you and your tools to do the best of the situation.

   Patrik

---

From: JFC Morfin <[email-masked]>
Date: Wed, 07 Mar 2012 17:27:22 +0100

At 15:19 07/03/2012, Patrik Fältström wrote:
> > Nothing in protocols forces me to use an UTF-8 keyboard or 
> printer (as long as punycode is supported somewhere down the line, 
> in the IDNA case).
>As the email from Kim was explicitly tagged with information that it 
>was in charset UTF-8 it is possible for you, and up to you and your 
>tools to do the best of the situation.

I might, but this would have three errors from Kim which are most 
common among us, but which affect users:

1. Architectural layer violation: to call for the implication of my 
"tool", i.e. application. Same error as the IDNA architecture itself 
which involves non-network (non end to end) applications.
2. Logical: Chris asks for a Unicode graphical table. Kim responds: 
you do not need one *if* you have one.
3. basic: if Kim answers us it is for his response to go through, not 
to force us to use/buy his tools. I only shown the response did not go through.

Now if I tag this mail as "fr-latn-fr" ce sera à toi de ton côté de 
te débrouiller pour tirer le meilleur parti de la situation.

All this is not to make a point, but to illustrate the problem we 
have at hand.

What I actually received were variants. Billions of people at one 
time or another may receive variants. Actually an A-label is a 
variant of its U-label. And each application can use its own 
character set. So, either UTF-8 becomes the sole standard charset of 
the Internet or we need to find a solution that does not implies a 
layer violation. It can be architectural (network end to end) or 
procedural (network use fringe to fringe) but it MUST be 100% secure 
and 100% independent from the applications core because we know that 
this is a security breach: there is no application to application or 
computer core to core protocol. Yet, with variants we must support 
psy to psy human protocols named natural languages which come with 
their own orthotypography. I know I am boring, but I am sorry, we 
work for Homo Sapiens Sapiens people, not for Homo Abilis ones.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2012 11:39:32 -0500

> - the encoding scheme (unless we accept Unicode as a default value)

You had another alternative?  IDNA uses Unicode.  Adding an
alternative encoding is just begging for trouble.

> - the CLASS (unless we accept the ICANN/NTIA CLASS "IN" as a defaulf value)

Why does this need to be classed?  I can see a reason to add it: maybe
a future CLASS would not need any ACE.  But thought experiments,
proposals, and experience with other protocols so far suggest that it
would be easier to create DNSng than it would be to add a new
widely-supported CLASS to the DNS.  We can't even get new RRTYPEs
widely supported in the DNS.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Mar 2012 18:01:55 +0100

> alternative encoding is just begging for trouble.

"utf-8" as mentioned in the email header is not the name of an encoding. It is a charset as registered with IANA.

   Patrik

---

From: JFC Morfin <[email-masked]>
Date: Thu, 08 Mar 2012 13:45:38 +0100

At 18:01 07/03/2012, Patrik Fältström wrote:
>"utf-8" as mentioned in the email header is not the name of an 
>encoding. It is a charset as registered with IANA.

This only means that a layer violation is registered with the IANA. 
OSI did worse things.

Patrick, let be candid. The Internet did not support the presentation 
layer. The presentation layer is necessary to support linguistic 
issues. So, it was actually implemented by IDNA2008 through fringe to 
fringe (RFC 1958) subsidiarity, but this is still fuzzy and for 
information (RFC 5895), hence my appeals to get an IESG/IAB position. 
We got the response: interesting but not the IETF 's cup of tea. What 
I do agree because it concerns every digital technology, not only the 
sole Internet.

This is why VIP, Precis, happiana, etc. have to try to find ways to 
deal with the Internet "half-presentation-layer" in many places. This 
is not easy if we do not acknowledge once for all that our pile of 
patches to circumvent the missing presentation layer is not correct 
Internet architecture.

Now, one cannot change the Internet architecture, even to make it 
consistent, in one day. This is why my position is do our best with 
the old-patches while accepting they are patches, and build the 
correct framework aside. It will not replace, nor conflict with 
patches, only make them obsolete because it only be "the" Internet 
consistent architecture. IDNA2008 gave us the concept we can 
reproduce (once IAB has endorsed it, once experimentation has proven 
it [my bet]). This example is to forget about IDNinApplication and to 
go for an ML-DNS IDNApplication. This is Google+ on the bigdata host 
side. And Internet+ on our IUser sides.

Best

---

From: "Dillon, Chris" <[email-masked]>
Date: Thu, 8 Mar 2012 12:30:25 +0000

Dear JFC,

Thank you for a thought-provoking e-mail.

I think we are in fact saying a similar thing in different ways about bitmaps. I regard bitmaps as being one possible starting point (input) but agree with
"This means that pattern (like in a flash) recognition is to be used, not sequence recognition (several chained patterns in sequence, vectors, history of the writing movement, etc.)."
although pattern recognition could be partly based on several chained patterns in sequence.

As you write further down:
"3. there is a matter of algorithmic conception: for example taking into account shape recognition to be more precise in cases one knows a confusion might result from the algorithm itself."
This is what I meant by the use of the word "programmable" in the context of an algorithm.

And:
"4. there is a matter of scientific approach in terms of pattern recognition, i.e. proceeding mathematically, informatically, or like a human brain (which only uses a very tiny part of the data it gets, but has learned to use it well: it does this not to be confused by the "noise", i.e. what we want ourselves, so there must be some common interest strategies to tackle the issue)."
The aim is certainly for an algorithm to act "like a human brain"; where the brain in question may be processing any language. Another aim is to minimise the gap between results an algorithm produces and the intuitions of native speakers.

"fuzziness may blur details to the point that a small point would disappear"
This is especially a problem with complex Chinese characters at small font sizes.

"there is a matter of font. The purpose is not for the bitmap to be beautiful, but to be not confusable, and sortable by the algorithm: the dot in the bitmap must be thick (width in bits) enough."
A key area is the browser address bar. It is easy to find out about the encodings used for text in HTML documents. However, the fonts used in the address bar in different browsers on different platforms in different languages present a major challenge.

"It is likely that if this target is accepted by TLD registries the algorithm will be used for passports, banking purposes, secure access, etc. and become an ISO standard."
I am not confident that there has not been progress in one of these sectors. Moreover, it sounds that even if there has been progress, they may not be too willing to share it. This is my way of asking the question "does anyone know more about this area?". Is it possible to borrow what has been done elsewhere, quite possibly adding to it, or does it really need to be done from scratch? It would be good to put resources discovered (sometimes with great difficulty from numerous organisations) and/or created in an area where it may be adopted for other uses.

The Pitfalls and Complexities of Chinese to Chinese Conversion is indeed at: http://www.cjk.org/cjk/c2c/c2cbasis.htm
It includes words which are typically different when Simplified Chinese and Traditional Chinese are used.

Professor Joe Zhang e-mail'd that companies such as Apple and Microsoft used to use bitmap fonts but now generally use True Type. Kai-style bitmaps at high resolution are available, but only individually, at www.unihan.com.cn/CoolHanzi .
I have copied him into this correspondence.

I would be interested in being part of current or future DIGs in this area. It involves a horribly complex matrix of criteria. Perhaps we can draw some comfort from machine translation which has made huge progress in a similarly inhospitable environment.

Regards,

Chris.
==
Research Associate in Linguistic Computing, Dept of Information Studies, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) ucl.ac.uk/dis/people/chrisdillon

-----Original Message-----
From: JFC Morfin [mailto:[email-masked]] 
Sent: 06 March 2012 19:20
To: Dillon, Chris; Dmitry Belyavsky
Cc: [email-masked]; [email-masked]; [email-masked]; G?rard Lang-Marconnet
Subject: RE: [vip] Draft on IDN Tables in XML

Chris,

At 12:12 06/03/2012, Dillon, Chris wrote:
>without visual confusion by the communities. The ideal algorithm would 
>be programmable to take into account this sort of thing that would be 
>missed by an entirely bitmap-based approach.

Actually, I am afraid there is no other basis than bitmaps. This is to do with the way the "HSS/NSP" (Homo Sapiens Sapiens/Natural Semantic Processor) works internally. The reason why is that for every other sense than vision, the brain takes time elements into account when it evaluates things, except in vision where it may not. 
This means that pattern (like in a flash) recognition is to be used, not sequence recognition (several chained patterns in sequence, vectors, history of the writing movement, etc.).

At the same time, this should not be a blocking problem. Because when Chinese and Arabs differentiate characters, their brains just do that. We are not at this stage yet, but I suppose that homographic confusion is related to fuzziness, and fuzziness may blur details to the point that a small point would disappear. One may imagine multiple programmatic responses:

1. there is a matter of density of the bitmap. How many bits in a dot, how many bits is the fuzziness threshold.
2. there is a matter of fount. The purpose is not for the bitmap to be beautiful, but to be not confusable, and sortable by the
algorithm: the dot in the bitmap must be thick (width in bits) enough.
3. there is a matter of algorithmic conception: for example taking into account shape recognition to be more precise in cases one knows a confusion might result from the algorithm itself.
4. there is a matter of scientific approach in terms of pattern recognition, i.e. proceeding mathematically, informatically, or like a human brain (which only uses a very tiny part of the data it gets, but has learned to use it well: it does this not to be confused by the "noise", i.e. what we want ourselves, so there must be some common interest strategies to tackle the issue).

There MUST absolutely be no false homographic confusion. This algorithm should be used to register CLASS 0 digital names, to make sure that in any other CLASS there is no confusing labels. It is likely that if this target is accepted by TLD registries the algorithm will be used for passports, banking purposes, secure access, etc. and become an ISO standard. So, many people will most probably work on it. My personal target is just to bootstrap the concept, create a fuss over it between ICANN and Google+ as part of the Internet+ stratum architecture - for it to be noticed, and properly worked on by Governments and International Organizations as part of the resolution of all the changes the identification of the 
Internet+ architectural framework introduces in the whole digital
ecosystem use (I did not invent it, I just try to document it, the way it already is in the Internet architecture, before it results in a real mess).

However, I fully agree with you: I do not think this will be achieved in one day, but one has to start. This means trying, testing different ways to check false confusions. Gain experience.

Today the only standard we have is ISO 10646, that is influenced by Unicode. It is great for typographer (i.e. people interested in the printer's side) not for orthotypographer (i.e. people considering the reader's side). We do not want to change it: we want to use it better.

>Study wrote in this area, but would be interested in finding out more 
>about the case for semantic synonymies. Incidentally, there is also a 
>paper by Jack Halpern which mentions possible Chinese cases (The 
>pitfalls of Chinese to Chinese conversion).

2) As a remark, I am personally interested in the networked computer assisted facilitation pragmatic aspects, and how to support specific needs by subsidiarity. This means that I am eager of the details, not to address them directly, but to make sure that the final general concepts of the architecture will permit to address them seamlessly at their proper place, when they are needed, without breaking the holistic equilibrium (Universe harmony).

The "Mecalanguage, Telecoms, Internet, Internet+, Intersem" 
architectural sequence MUST be elegant if to be efficient. This IETF "MUST" results from the few existing (but truly inspired) architectural RFCs. They have defined this elegance so far as multilayered (RFC 1121), plug to plug robust (RFC 761), end to end adaptative (RFC 1958), over all simple (RFC 3439) and fringe to fringe subsidiary (IDNA2008).

The two most challenging ones are the mecalanguage (how to produce an
utterance) and the Intersem (how to obtain intercomprehension) strata. This is mostly terra incognita. At this stage we are actually discussing the Internet+ stratum, (how to make the content of that utterance interintelligible).

What ITU and IETF have covered is "how to reliably transport the utterance" (Internet datagram) and "how to efficiently transmit the bytes of these datagrams". And ICANN has introduced an unstable way of making money with it :-)

>3. One of the members of the Chinese Case Study, Professor Joe Zhang of 
>Unihan Digital Technology Co. presented me with a copy of "Zhongrihan 
>changyong hanzi duibi fenxi" ISBN 978-7-100-06595-5 which is a 
>comparative list of characters used in Chinese, Japanese and Korean. He 
>was the chief editor. It includes Unicode code points, but not bitmaps. 
>I shall e-mail him and ask him if he knows whether a list with bitmaps 
>exists.

Thank you.
Best
jfc

>natural that ICANN works for their own business community and they make 
>it plain when asked. As lead Internet Users (http://iutf.org and our 
>liaison to the IETF http://iucg.org/wiki), we have the same and more 
>needs:
>
>2. complete variant coverage, i.e. visual, combinational (several code 
>points), orthotypographic (syntaxic [one way/two ways] correspondence 
>and majuscules in a considered *language*), and cultural (semantic 
>synonymies) 3. for every CLASS. There are 65,536 classes 
><http://www.iana.org/assignments/dns-parameters>http://www.iana.org/ass
>ignments/dns-parameters; ICANN is only concerned with CLASS 1 "IN".
>- UNISIGN, which is a table that will document all the signs being used 
>in the WDNS syntax.
>
>2. There exist different bitmap tables. Do we understand correctly that 
>there is a Chinese official publication that documents the Han and Han 
>bitmap sets?
>
>architecture that calls for new collaborative working structures. I am 
>documenting:
>
>- that
>cooperation:
><http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt>http:
>//www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt
><http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt>ht
>tp://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt