Re: [idn] call for comments for REORDERING

["James Seng/Personal" <jseng@pobox.org.sg>]

Your answer does not answer how we going to update re-ordering in future
with new codepoints. Do you expect to continue to work with this and to
have update RFC for it? And we going to update RFC again and again? The
typical solution IETF use for this is IANA action and that involves a
well-defined policy which IANA could reused for future addition. But if
we do so, we also need to consider if we are imposing codepoints issues
which is best dealt with other organisation.

As I repeated, I really like to point to another organisation for these
tables if possible. If ISO 14651 is not suitable (as Ken & Mark said),
then we look at some others. If there is none, then maybe we should
consider NOT to do it at all.

-James Seng

----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: "James Seng/Personal" <jseng@pobox.org.sg>; <idn@ops.ietf.org>;
"Martin Duerst" <duerst@w3.org>
Sent: Friday, October 19, 2001 11:13 AM
Subject: Re: [idn] call for comments for REORDERING


HI, James

I will answer one by one for your  questions.

----- Original Message -----
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Soobok Lee" <lsb@postel.co.kr>; <idn@ops.ietf.org>; "Martin Duerst"
<duerst@w3.org>
Sent: Friday, October 19, 2001 10:09 AM
Subject: Re: [idn] call for comments for REORDERING


>
> And with the existing draft, it does not explain how it going to deal
> with new codepoints in ISO10646 in the future, nor does it explain the
> process to implementing them. The critia here is stablity - if new
code
> is added and tables for re-ordering expand, then the algorithm should
> not make existing names invalided.

REORDERING's mapping occurs within each script block, NOT across script
blocks.
Therefore, new additions of script block won't invalidate or collide
with existing names. Even additions of new rarely used characters in
existing script block won't affect the performance of REORDERING.
In this respect, REORDERING maintains stability over time.

Current IDNA/nameprep does not prohibit, but discourage including
unassigned code points in legal IDN labels, because new
normalization/case mappings
would be defined on them in the future. some ACE labels including
unsigned code block (tagalog?) might be proven invalid in the future.
Nameprep/NFKC Versioning tag schems using new ACE prefix will be needed
in the future, i guess.

Therefore, REORDERING  follows the same IDNA/nameprep recommendations on
the issues
of new SCTIPT blocks/unsigned code points.

This statements will be included in the final version of REORDERING I-D.

Thanks.

Soobok Lee