Jamo [RE: Consensus Call Tranche 8 (Character Adjustments)]

Thu Oct 16 14:46:40 CEST 2008

I agree with the line of thought that we really should not disregard the results of the consensus position established by the most relevant language community after a rather extensive consensus process, so in general, I would side with the experts in Korea.

Nevertheless, having been through this discussion for many times, I understand that there are opinions otherwise and am hoping to make a suggestion that could reconcile the lines of thought and be consistent with our architecture.  When we last discussed the issue of conjoining Hangul Jamo, I had suggested exploring the possibility of addressing them in the following manner:

1. categorize all Hangul Jamo as CONTEXTO

2. add stability contextual rule for these codepoints where the following must be true:

toNFKC(toCaseFolded(toNFKC(label))) != label

I am not familiar enough with Korean, but this might strike a graceful balance between disallowing conjoining jamo that forms a modern hangul and continue to allow archaic Jamo without creating too much of a confusion?... 

If I recall correctly, there was response that it seemed interesting, but was not further discussed.  Do people think it might be a viable approach to resolve the issue?

Edmon

From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no] On Behalf Of Vint Cerf
Sent: Thursday, October 16, 2008 7:19 PM
To: Patrik Fältström
Cc: Martin Duerst; idna-update at alvestrand.no; Andrew Sullivan
Subject: Re: Consensus Call Tranche 8 (Character Adjustments)

I am traveling in Oregon at the moment and will try to summarize the state of responses tonight to the latest set of consensus questions.

I confess that I share Patrik's concern for disregarding a consensus process from a specific language expert group.

vint

NOTE NEW BUSINESS ADDRESS AND PHONE

Vint Cerf

Google

1818 Library Street, Suite 400

Reston, VA 20190

202-370-5637

vint at google.com

On Oct 16, 2008, at 1:33 AM, Patrik Fältström wrote:

On 16 okt 2008, at 06.08, Martin Duerst wrote:

I had a look at the document again. For those points of the

proposal where it disagrees with what we currently have,

the words "not needed" are used. Nothing that even comes

close to words such as "harmful", "confusing", or the like

appears for points 1 and 2. The word "confusing appears for

point 3, Hangul Compatibility Jamo, which we already disallow.

Of course writing and reading such documents is always frought

with difficulties, but I don't think that the hypothesis that

the authors understand the difference between "we don't need

them" and "these are dangerous" is far-fetched.

Fair. Thanks Martin for taking time to read this document again.

This because I think having an IETF wg make a decision about consensus  

that is _against_ a proposal from a formal organisation like NIDA that  

say they have been running a consensus driven process in Korea with  

participants from Korean Agency for Technology and Standards (National  

Body of ISO and IEC), the National Institute of The Korean Language,  

etc, is serious.

If we had a similar situation in Sweden where IETF ruled against what  

similar consensus driven process in Sweden about Swedish...well, I  

would start asking serious questions on how consensus in IETF was  

reached.

So, I am as editor of the tables document neutral in the issue. I just  

envision that for 8.c, we will get questions given what the consensus  

seems to be at the moment.

    Patrik

Regards,    Martin.

At 04:31 08/10/16, Patrik F舁tstr? wrote:

On 15 okt 2008, at 20.36, Andrew Sullivan wrote:

On Wed, Oct 15, 2008 at 08:20:05PM +0200, Patrik F舁tstr? wrote:

Understood. Note that if we look at the proposals eszett and the  

one

from korea, the eszett is an exception, while the korean proposal

uses

the Unicode properties.

Hmm.  If this is the case (and at least in the Korean proposal, my

notes make me think that we have a different meaning of "Unicode

properties" in the above, but I'm certainly not willing to assert  

that

I'm right), then I'm even more confused than I at first thought I  

was.

So I'm going to shut up about this topic, but I _still_ have to say

"no", since the consensus call said explictly that silence would be

counted as support (and I obviously can't support what I don't

understand).

I understand your statement, and view.

I am just confused over the reaction in general from people.

I have attached the Korean proposal, which in short is:

1. Add Hangul Jamo to blocks to disallow (i.e. "2.1.4 IgnorableBlocks

(D)")

2. Add two codepoints (that is "Inherited", but not DISALLOWED by

other means) to DISALLOWED

I.e. I must correct myself when I said that the proposal is only  

using

Unicode properties. I can not (but I am tired...) see how to catch  

the

two Bangjeom codepoints U+302E and U+302F without using exceptions.

People interested in this discussion should also re-read the messages

from Ken where he explain his view is that this is something that

should be expressed by a registry policy.

Message-Id: <200807281913.m6SJDpL01810 at birdie.sybase.com>

Date: Mon, 28 Jul 2008 12:13:51 -0700 (PDT)

  Patrik

_______________________________________________

Idna-update mailing list

Idna-update at alvestrand.no

http://www.alvestrand.no/mailman/listinfo/idna-update

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University

#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp

_______________________________________________

Idna-update mailing list

Idna-update at alvestrand.no

http://www.alvestrand.no/mailman/listinfo/idna-update

Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.8.0/1722 - Release Date: 15-Oct-2008 8:02 PM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081016/9c1777a2/attachment-0001.htm 