Re: [idn] I-D ACTION:draft-ietf-idn-vidn-00.txt

["Mark Davis" <mark@macchiato.com>]

My comments below.

Mark

----- Original Message -----
From: "FDU - Sung Jae Shim" <sshim@mailbox.fdu.edu>
To: "Mark Davis" <mark@macchiato.com>; <idn@ops.ietf.org>; "Paul Hoffman /
IMC" <phoffman@imc.org>
Sent: Monday, November 20, 2000 18:17
Subject: Re: [idn] I-D ACTION:draft-ietf-idn-vidn-00.txt


> Please see below for my responses to your comments.
>
> Sung
>
> ----- Original Message -----
> From: Mark Davis <mark@macchiato.com>
> To: DualName - ShimSungJae <shimsungjae@dualname.com>; <idn@ops.ietf.org>;
> Paul Hoffman / IMC <phoffman@imc.org>
> Sent: Sunday, November 19, 2000 9:14 PM
> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-vidn-00.txt
>
>
> > However it is done, what you are talking about is mapping the letters of
> > each and every language on Earth into [a-z,0-9,and hyphen]. Korean
Hangul
> > has the marked advantage of being relatively rather simple to map to and
> > from Latin letters without ambiguity. There are a huge number of
problems
> > with this approach in general:
> >
>
> Sung: Yes, VIDN maps the letters of non-English languages into [a-z,0-9,
and
> hyphen] that already exist in the DNS, in the same way that people in
> regions where English is not widely spoken, currently create their domain
> names in English.
>
> Sung: No, I do not think that Korean Hangul is relatively rather simple to
> map to and from Latin letters without ambiguity. Please take a look at the
> example cited in email from Paul Hoffman and its corresponding sets of
> characters in English. When we transliterate a person's name in Korean
> Hangul into English, the possibilities may include:
>
> gimgyeongseog
[snip]
> kimkyongseok

Korean Hangul *is* relatively simple. Many other characters from other
languages are much more difficult to represent unambiguously.

>
> Sung: The focus of VIDN is not on the side of the many possible sets of
> Sung: A huge number of problems you mentioned seem to be due to some
> Sung: It would be nice for those who speak local languages to have their
> Sung: VIDN does not need round-trip mapping, although it may be possible
to
> Sung: Without such standards, people speaking local languages have been
> Sung: The same character or set of characters in a local language may
> Sung: Again, VIDN does not need a round-trip mapping from English to local
> Sung: Please take a look at how those accented characters have been
actually
> Sung: Again, VIDN does not need a round-trip mapping from English into
local
> Sung: Please take a look at how those characters have been actually
> Sung: Again, please take a look at how those accented characters have been
> Sung: VIDN does not need a round-trip mapping, in using domain names in

All of the above was simply to say that VIDN will not do reliable round-trip
mapping. But if that is the case, then the user cannot type in
[KanjiX][KanjiY].com, and get to a website where the location bar will read
"[KanjiX][KanjiY].com". The same for European characters. This would not be
acceptable.

> Sung: VIDN provides more immediate and less costly solution to
> internationalized domain names than other methods. For example, developing
> the testing version of VIDN for Korean-English conversion has taken only a
> few months. A couple of programmers have developed it with consultation
with
> several experts in Korean and English phonemics and linguistics. With more
> resources, the development process can expedited significantly.
>
> Sung: Because of its small size (e.g., the testing version of VIDN for
> Korean-English conversion is about 800KB and the actual DLL file used for
> the conversion is about 250KB), VIDN can be easily embedded into user
> programs that use domain names, such as web browser and client email
> software. Alternatively, the knowledge base of conversion and the logic to
> process it can be embedded into operating systems as a library, so that
> client software such as web browser and email software can share them. The
> user will need only the module for conversion of his or her preferred
local
> language into English. Again, there is no need to convert the
romanizations
> back to native characters for every language.

Immediate and less costly? The translation from Unicode/10646 to LACE and
back is a couple of pages of code and some data tables. Size: at most about
50K total, and that covers all million possible Unicode/10646 characters.
And that is for translation into and out of LACE. The check as to whether a
name is valid would be shorter.

The cost of getting accurate transliterations -- for all letters in
Unicode -- not just Korean; and apparently on a language-by-language basis?
Cheap?

 I think not.

>
> > j. The process also lends itself to becoming completely and utterly
> > politicized.
> >
>
> Sung: VIDN does not need much of "the process," and so, I do not see any

Quaint. You apparently have not seen the battles that people fight in ISO
over simply the *name* of a single character, where that name actually will
never appear to users. Wait until it comes to deciding how to transliterate
Greek, Ukranian, or Azeri into English letters (without accents!)!

> Sung: VIDN method is not only interesting but also working. But creating

Working apparently for Korean. For all Unicode characters, for all
languages?