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

["FDU - Sung Jae Shim" <sshim@mailbox.fdu.edu>]

The same email was sent from an email account which is not listed on the
mailing list. I am sorry about that.

Sung


----- Original Message -----
From: DualName - ShimSungJae <shimsungjae@dualname.com>
To: <idn@ops.ietf.org>; Paul Hoffman / IMC <phoffman@imc.org>
Sent: Sunday, November 19, 2000 6:10 PM
Subject: Re: [idn] I-D ACTION:draft-ietf-idn-vidn-00.txt


> Paul,
>
> Thank you for your comments on the document. Please see below for my
> responses to your comments.
>
> Sung
>
> ----- Original Message -----
> From: Paul Hoffman / IMC <phoffman@imc.org>
> To: <idn@ops.ietf.org>
> Sent: Thursday, November 16, 2000 12:57 PM
> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-vidn-00.txt
>
>
> > This document has a patent statement at the end of the document, but
> > nothing appears in the IETF IPR directory for it. If they haven't
> > already done so, it would be a good first gesture for the authors to
> > follow RFC 2026 and put their statement in the IETF repository.
> >
>
> Sung: I have sent a patent statement to the IETF secretariat.
>
> > As a second comment, please note that there is wide disagreement
> > about any single method for phonemic transformations from other
> > languages to English. This document specifically covers Korean, for
> > which there are at least two different romanization schemes in
> > current use. For a perfect example of this, one of the contributors
> > to this working group offers two different romanized spellings of his
> > last and first names:
> >
> > GIM Gyeongseog
> > KIM Kyongsok
> >
>
> Sung: There is a Romanization scheme in Korea, which has been revised
> recently. But the problem is that many people do not follow this
> Romanization scheme. For illustration, the possible results from
> transliteration of the above example in Korean into English may include:
>
> gimgyeongseog
> gimgyeongseok
> kimkyungsuk
> kimkyoungsuk
> kimkyungsok
> gimkyungsuk
> kimkyongsuk
> kimkyungseok
> gimkyoungsuk
> gimkyungsok
> kimkyoungsok
> kimkyungsuck
> kimkyeongsuk
> kimkyoungseok
> gimkyongsuk
> kimkyongsok
> gimkyungseok
> gimkyoungsok
> kimkyoungsuck
> gimkyungsuck
> kimkyongseok
>
> As shown above, the transliteration from Korean into English is very wild.
> But first, VIDN converts the input characters entered in a local language
> into possible domain names in English, including "GIM Gyeongseog," "KIM
> Kyongsok" and more in this example. This is one-to-many mapping of VIDN.
> Second, VIDN matches only one of these, for instance "GIM Gyeongseok,"
with
> the person's name entered in Korean, with the coding scheme designed for
> one-to-one matching (see the document for details), and the others can be
> listed as alternatives so that the user may try them.
>
> For the conversion from a local language into English, VIDN does not
> rely on a single set of "preferred" transliteration rules which may change
> over time, but it uses a much more fundamental approach. VIDN uses the
> phonemes of the respective two languages (a local language and English) as
a
> medium of the transliteration, and so, there is no need to change the
> underlying domain names in English. In fact, most transliteration rules
are
> based upon the systems of sounds of the respective languages, and the
units
> of such systems are phonemes. Therefore, VIDN incorporates most, if not
> all, possible transliteration rules, including all those "preferred,"
> customary, old, or new ones.
>
> > The draft proposes that every possible romanization using each
> > possible phoneme be kept by the authoritative DNS server, and only
> > one combined romanization can be returned. This assumes that the
> > complete set of romanization tables is known today, and that the set
> > will never grow. Both of these assumptions may be incorrect.
> >
>
> Sung: VIDN does not propose that every possible romanization using each
> possible phoneme be kept by the authoritative DNS server. VIDN first
checks
> which ones of the possible domain names in English are active and then
> checks which one of the active domain names has the pre-assigned code
> matching with the code generated in the user applications by VIDN. When
VIDN
> locates the active domain name in English whose code matches with the code
> generated in the user applications, VIDN connects the user host with the
> server host, following the same procedure as in the current DNS, and lists
> the other active domain names as alternatives so that the use may try
them.
>
> Sung: VIDN does not assume that the complete set of romanization tables is
> known today, and that the set will never grow. Again, VIDN does not
> rely on a single set of "preferred" transliteration rules which may change
> over time, but it uses a much more fundamental approach. VIDN uses the
> phonemes of languages, which are very universal, being applicable to any
> languages, as a medium of the transliteration.
>
> > Further, there is the legacy problem. For example, both kim.com and
> > gim.com exist today. Even if the romanizaiton table problem can be
> > solved, the names returned would have to be different than current
> > names. Maybe the authors could use a prefix hack similar to the ones
> > the ACE authors have saddled ourselves with.
> >
>
> Sung: The names returned by VIDN do not need to be different from current
> names. In fact, one of the possibilities can be returned, for instance
"GIM
> Gyeongseok" in the above example, using the coding scheme described in the
> document. VIDN considers only the possibilities whose phonemes have the
same
> or very proximate sounds as the phoneme represented by the input
characters.
> This can significantly reduce the risk of domain name squatting. In other
> approaches using UCS encoding schemes or separate directory services for
> internationalized domain names, even "lee.com" in English that has nothing
> to do with the person's name in Korean can be matched with the person's
name
> in Korean.
>
> Sung: Please note that VIDN does NOT actually create and require domain
> names to be registered in local languages, but it allows using virtual
> domain
> names in local languages as the user wishes. Of course, there may be some
> domain names in English to be changed so that users can use the
> corresponding
> virtual domain names in a local language more easily and intuitively. But
> compare the number of internationalized domain names that we have to
> actually create and register when we use special UCS encoding schemes or
> separate directory services, with the number of domain names in English
that
> we need to add to follow the transliteration principles of VIDN.
>
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >
>