Subject: Re: [idn] nameprep (Korean Nameprep)

From: Soobok Lee <[email-masked]>
Date: Fri, 01 Jun 2001 00:42:19 -0700

Hoffman / IMC <[email-masked]>, Kenneth Whistler <[email-masked]>
Sender: [email-masked]
Precedence: bulk

On Thu, 31 May 2001, Mark Davis wrote:

> 1. It is correct that neither the compatibility Jamo nor the
half-width Jamo
> are combined into Hangul syllables by the normalization algorithm.
However,
> those Jamo are not intented for use in constructing Hangul
syllables --
> instead, the conjoining Jamo are. And those are correctly composed
into
> syllables, if individual Jamo are input.
>
> It would be possible to deal separately with those characters in
nameprep --

I agree.

> although without more information it is not possible to completely
eliminate
> ambiguity in choosing whether a consonant is leading or trailing.

compatibility jamo sequences may be preserved unchanged. Otherwise,
they may be transformed into correct conjoinging jamo sequences before
nameprep based on hangul automata for contructing hangul syllables from
jamo (
this will make common nameprep codes include hangul-specific codes in
it).
We (KRNIC NC) have no consensus yet on whether these sequences
should be preserved or not.

> Do you
> believe this is, in practice, a really problem; that there are a large
> number of people that produce Korean text with compatibility or
half-width
> Jamo, instead of Hangul syllables?
>

Hangul compatibility jamo sequences are not rare in korean texts and
are useful for hangul consonant-letter acronyms for long hangul words
or phrases.  They will unburden  typing effors.

Soobok Lee, [email-masked]

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 1 Jun 2001 08:57:27 -0700

I don't think I have expressed myself clearly. In the writing of modern or
ancient Korean, as far as the Unicode encoding is concerned, only the
conjoining Jamo and the Hangul syllables are required. This is also
certainly be the case for IDN.

For consonant letter acronyms, the initial conjoining Jamo can be used,
since in the absence of medial conjoining Jamo they do not change in
nameprep. Any sequence of consonant letter acronyms using the compatibility
Jamo would simply be changed into conjoining Jamo, and thus still represent
consonant letter acronyms. Correct matching would take place, even if the
original sources were different. The only issue would be with medial
compatibility Jamo; however, those are not required as separate entities in
IDN for the representation of Korean. Thus nameprep is usable for IDN as it
stands.

Any specification that deals with text can be tweeked endlessly. After a
certain point, however, there are *rapidly* diminishing returns. If we
rejected any specification that could possibly be refined, we would never
accept anything ;-)

Mark

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 01, 2001 05:02
Subject: Re: [idn] nameprep (Korean Nameprep)

> Soobok and Mark,
>
> For whatever it is worth, this discussion reinforces, yet again,
> my belief that nameprep should be recast into a
>
>    yes
>    no
>    sometimes (better figure out how to get user input)
>
> model.  Then the protocol work should be structured to reflect
> the fact that there are fewer certain answers than, in a more
> hospitable world, we might wish for.
>
>     john
>
>
>

----- Original Message -----
From: "Soobok Lee" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Adam M. Costello" <[email-masked]>; <[email-masked]>; "Paul
Hoffman / IMC" <[email-masked]>; "Kenneth Whistler" <[email-masked]>
Sent: Thursday, May 31, 2001 23:59
Subject: Re: [idn] nameprep (Korean Nameprep)

> > 1. It is correct that neither the compatibility Jamo nor the half-width
Jamo
However,
> > those Jamo are not intented for use in constructing Hangul syllables --
> > instead, the conjoining Jamo are. And those are correctly composed into
nameprep --
eliminate
jamo (
> this will make common nameprep codes include hangul-specific codes in it).
half-width