Subject: Fw: [idn] (bias) summary of reordering discussion

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 6 Nov 2001 00:59:49 +0800

This is a reminder on focus on reordering draft.

http://www.ietf.org/internet-drafts/draft-ietf-idn-lsb-ace-02.txt

I suggest everyone to look at draft and also at the discussion on
reordering. If there is any comments, issues to raise, points to note,
arguments for or against, please bring them forward.

We hope to do a strawpoll very very soon.

Thanks.

-James Seng

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 24, 2001 12:32 AM
Subject: [idn] (bias) summary of reordering discussion

> On the questions posted:
>
> 1. Efficient - I accepted that reordering produce a shorter ACE
string,
> sometimes as much as 20%. This means instead of a "zq--zxcvbnmasdfg"
> label, I get a "zq--zxcvbnmasd". I do not buy the arguments it is
> helpful to naked eye, to memorised or save RAM however.
>
> 2. Compression efficient in future since statistic - Lee's counter
that
> compression "always SHORTER labels than usual". Mathematically, it can
> be proven this is wrong (very basic pigeon hole principle).
>
> 3. Referencing from established I18N organisation - ISO14651 is deem
> inappropriate and I agree with it. No alternative was proposed.
>
> 4. Stability of reordering - Lee's countered with the arguments that
> reordering tables would never changed. I am not sure if that is
possible
> but I agree with the assessment that it is possible to design
reordering
> to be stable. However, I like to see explictive statement in future
> draft.
>
> 5. Future additional of code points / changes to reordering - Lee's
> proposal is a two prefix solution, using prefix as a versioning tag. I
> do not like to solve a problem by creating others, especially one
which
> makes it even more complex. Lee have yet to address the process of how
> future additional of code points or changes to reordering could be
done.
> (IDN WG is not going to exist forever...I dream of finishing our work
> one day).
>
> 6. Reordering is never ending task - Lee's countered that so is
> Nameprep. My thoughts is two wrong dont make one right. (OTOH,
Nameprep
> which is based on UTC work have explicit principles on how it can be
> done. And Nameprep is not subjective to frequency analysis changes
which
> reordering is)
>
> Of the people participate in the reordering discussion
>
> Martin Duerst - explicit objection
> Mark Davis - not very supportive, not explicit
> Adam Costello - (no conclusion from comments)
> Doug Ewell - explicit objection
> Paul Hoffman - explicit objection
> Eric Brunner-William - somewhat supportive, not explicit
> Kenny Huang - (no conclusion from comments)
> James Seng - explicit objection
> Karlsson Kent - explicit objection
> Erik Nordmark - not very supportive
> David Hopwood - (no conclusion from comments)
>
> This is my rough read of the discussion on reordering so far (please
> correct me, and apologise in advance, if I am wrong).
>
> (Wearing my co-chair's hat) It is not a vote or even a strawpoll here
> obviously but I am trying to get a feel of the group consensus. But if
> these discussion is any indication of the group consensus, it does not
> indicate very little support for reordering. If there is other
comments,
> please bring them forward soon. Thanks.
>
> -James Seng
>
>

---

From: "Bruce Thomson" <[email-masked]>
Date: Fri, 9 Nov 2001 10:24:09 +0900

I took a good look at the re-ordering draft, and would like to offer
my opinion. The research is pretty thorough, and it is clear that a
(conceptually) simple approach will give us an improvement over
the non-re-ordered case.

However, although the concept is simple, the details are complex.
It is easy to say that the complexity is buried in the code in some
library and will not affect us, but actually it will affect us, as
it has to be frozen into permanent, public document, and adds
a whole new dimension of complexity to the specification of
something which could have been quite simple.

I say that the benefits do not justify all of this.

Bruce

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 9 Nov 2001 11:23:46 +0900

----- Original Message ----- 
From: "Bruce Thomson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 09, 2001 10:24 AM
Subject: Re: [idn] (bias) summary of reordering discussion

> something which could have been quite simple.

Yes. The output RFC may have  huge list of reordering parameters and
may look complex to authors and readers, not to the end users.

As i pointed out in the draft, NFKC/mapping/prohibition lists in nameprep
also have  huge lists of characters. 
Nameprep's casefolding table contains roughly over 3000 code points involved.
Nameprep's prohibition/unassigned code points  tables also have huge lists
of code  ranges, 70/400, respectively. 

Current REordering lists 5500 code points involved in its table.
Just +2000 code points compared to that of nameprep.

Moreover, nameprep hidden complexity around  NFKC is hidden in the UTR15 document .
REORDERINg has no external authority to quote character frequency 
statistics  in order to make the drafting work look simple
as nameprep refers to UTC NFKC.

Nameprep and reordering  *deal with individual code points*.
That's the source of the inevitable document complexity.

Soobok Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 9 Nov 2001 12:32:41 +0800

> something which could have been quite simple.

Bruce, thanks for the going thru the draft & evaluation.

Soobok Lee wrote:
> Moreover, nameprep hidden complexity around  NFKC is hidden in the
UTR15
> document. REORDERINg has no external authority to quote character
> frequency statistics  in order to make the drafting work look simple

This is the biggest problem I have with reordering, ie,

> That's the source of the inevitable document complexity.

Comparing Nameprep & reordering isnt the right approach.
You should compare the complexity vs the result.

Nameprep complexity justify what it achieve.
Reordering does not.

-James Seng

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 9 Nov 2001 13:55:23 +0900

----- Original Message ----- 
> Nameprep complexity justify what it achieve.

Disagree. Significant portion of real CJK and otherscript
registration contains 6 or more characters. That will be
increased by introduction of new future broader and diverse applications of IDN.

Most webhost/mailhost names are seldom typed in , but *clicked* through
from web pages or email clients. official long biz names are welcome in IDN.

think about  chinese <customer_Service>.<china_southern_airlines_inc>.cn.
Including This necessary subdomain length, the average length of 
native-script portion of IDN may usually exceed 10, i guess.

I can't understant why someone are so restrictive and pessimistic
about the applicability and popularity of long IDN.
To shot down REORDERING ?

Soobok Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 9 Nov 2001 13:06:34 +0800

> increased by introduction of new future broader and diverse
applications of IDN.

You forgot that this group is doing "Internationalization", not
"localization".  Therefore a draft merit should justify itself based on
its applicability to the global community (ie all script) not a just
particular locale (ie just some subset of script). No script should be
and must not be more important over the other.

I believe this point was raised in London by Paul, on how reordering is
going to work for other script. You have answer it a couple of times
but, correct me if I am wrong, summary of what you wrote as I read it is
"I dont know those scripts and I dont care".

> from web pages or email clients. official long biz names are welcome
in IDN.

Irrelevant. I still dont see why a bq--ewojasdje39a is better than
bq--sdkjs993k to naked eye (if and when they do see it). You mean you
are able to to remember bq--sdkjs993k?

> think about  chinese
<customer_Service>.<china_southern_airlines_inc>.cn.
> native-script portion of IDN may usually exceed 10, i guess.

This is the advantage of reordering. I have accepted that and I think so
has others. We are not disputing the advantage of reordering. We are
saying reordering have many disadvantages and these does not justify
putting reordering into the standard.

You should be working to address the problems of reordering. Repeating
the advantage of reordering over and over again is not going to make
these problems go away.

> To shot down REORDERING ?

In IETF, we do engineering trade-off. Sometimes, we drop a feature
because we dont think it is worth the effort. IMHO, reordering is one of
them. But that is my opinion only so I think a strawpoll will be able to
guage the consensus of the group better.

-James Seng

---

From: "Bruce Thomson" <[email-masked]>
Date: Fri, 9 Nov 2001 14:11:05 +0900

> To shot down REORDERING ?

In fact, I am much more of an optimist than you. Because I believe
that inherent limitations such as the length of domain names or
the set of characters mail gateways can handle will inevitably be
fixed to meet the demand. Also you seem to have discovered that Unicode
itself was not optimally ordered, right? And some of the discussions
in this wg indicate that Unicode's handling of CJK may be flawed as well.
I would prefer to take the long view and work to get those problems
corrected, even if it means wearing other hats and going to other
organizations to do these things.

Basically, this wg has gone way too far in the direction of trying to fix
things that should be fixed elsewhere.

Bruce

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 8 Nov 2001 21:15:20 -0800

>increased by introduction of new future broader and diverse 

CJK name parts of 6 characters are already allowed by AMC-Z. In fact, 
CJK name parts of around 20 characters are allowed.

>from web pages or email clients. official long biz names are welcome in IDN.

How is this relevant to the decision to use or not use reordering?

>native-script portion of IDN may usually exceed 10, i guess.

These names are already allowed by AMC-Z. Adding reordering doesn't 
help in those names.

Does reordering allow sensible names that are not allowed now? If so, 
can you give examples? (Of course reordering can help make very long 
nonsensical names possible, but that isn't a goal of this WG.) I 
apologize if you have already given examples and I missed them. What 
I remember was discussion of making ACE strings shorter, although I 
don't remember many folks saying that they thought that feature was 
very useful.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 9 Nov 2001 14:24:17 +0900

----- Original Message ----- 
From: "James Seng/Personal" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Bruce Thomson" <[email-masked]>; <[email-masked]>
Sent: Friday, November 09, 2001 2:06 PM
Subject: Re: [idn] summary of reordering discussion

> and must not be more important over the other.
You should not forget that 
han/hangeul are the disfavored script in ACE encoding.

> "I dont know those scripts and I dont care".

I had suggested a threshold. It was not thoroughly discussed.
The size of script of han/hangul exceed 10000. Others are not!
The size of script affects the ACE encoding efficiency.
They are already suggested in my draft. no one cited that in this list yet.

> are able to to remember bq--sdkjs993k?
no need to remember, but just compare or transscript. short lables help.
What if the are displayed in narrow wap phones?
ACE IDN will be used by and exposed to  over 6 billions, not only to handful of us engineers, 
but also to children, elders, educated, non-educated from various backgrounds.

see this:

bq--wqeqwkejwkqeqwewq
bq--ewqeqweeqww

bq--qweuiwqueqwiueoqwueoqwueoqwueqwueoqwueqwewq
bq--weqweqweqweqweqweeqweqewqw

For long CJK names, compression ratio reach 30%, and for frequent names up to 40%.

Soobok Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 9 Nov 2001 13:46:01 +0800

> han/hangeul are the disfavored script in ACE encoding.

This is news to me :-)

What is the cause of the problem? Is it because of ACE algorithm problem
or is it because of the large number of han/hanguel characters or is it
because of the placement of han/hanguel characters in ISO10646?

I suspect the problem is due to the latter two and not because ACE
algorithm.

Therefore, as an engineer going to solve the problem is either
a) reduce the large number of han/hanguel characters used
b) reorder the placement

I dont forsee we can reduce the numbers of han characters used. In fact,
it seem to be growing as the days goes by. So IMHO, (a) is out.

Therefore, (b) seem to be right choice absolutely.

The next question you should ask is can it be done in IDN WG or should
this be done in ISO/IEC instead? In this case, I see the answer as
fairly obvious.

> What if the are displayed in narrow wap phones?

Irrelvant too. To naked eye, a gibberish is a gibberish, whether it is
ACE-gibberish or 8-bit gibberish (for UTF-8 etc), whether the gibberish
is longer or shorter.

A gibberish is always a gibberish.

> For long CJK names, compression ratio reach 30%, and for frequent
names up to 40%.

As I said,

"You should be working to address the problems of reordering. Repeating
the advantage of reordering over and over again is not going to make
these problems go away."

-James Seng

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 9 Nov 2001 14:59:50 +0900

----- Original Message ----- 
> A gibberish is always a gibberish.

Irrelvant.
IS there No need to compare and copy and transscript the "gibberish" ?
Think about ergonomics around dealing with the gibberish by ordinary users,
not by you engineers.

Soobok Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 9 Nov 2001 14:06:53 +0800

> Think about ergonomics around dealing with the gibberish by ordinary
users,

Erm, "ergonomics" of ACE? That is another news to me. (It appears you
like to keep your cards hidden and surprise others at a critical times
:-)

Are you suggesting to make ACE meaningful to naked eyes of ordinary
users? If so, that is yet another news to me. Explain how reordering
does it.

If not, what do you mean by "ergonomics" of ACE.

-James Seng

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 9 Nov 2001 15:50:15 +0900

----- Original Message ----- 
From: "James Seng/Personal" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Bruce Thomson" <[email-masked]>; <[email-masked]>
Sent: Friday, November 09, 2001 3:06 PM
Subject: Re: [idn] summary of reordering discussion

> If not, what do you mean by "ergonomics" of ACE.

James, take a rest. and then, make a right guess on it 
before i give you an answer.  :-))

---

From: "xiaodong lee" <[email-masked]>
Date: Fri, 9 Nov 2001 19:35:58 +0800

Yes.
LDH dns use 63bytes,  it seems not to be useful, why?
especially for IDN, long domain name will more useful than LDH DNS.
Though IDN's language characterisc it is not considered in technical point, 
but for end users, they cares more about it.
When user use IDN, they could use a abbr to access the website if they 
remember it.  if not, they do hope to use the whole name to visit it.

----- Original Message ----- 
发件人: "Soobok Lee" <[email-masked]>
收件人: "James Seng/Personal" <[email-masked]>; "Bruce Thomson" <[email-masked]>; <[email-masked]>
发送时间: 2001年11月9日 下午 12:55
主题: Re: [idn] summary of reordering discussion

----- Original Message ----- 

Soobok Lee

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 9 Nov 2001 09:07:10 -0800

>Think about ergonomics around dealing with the gibberish by ordinary users,

This is probably the basis of the disagreement that most people have 
with reordering.

In fact, there is no need for humans to compare or copy (by hand) or 
transcribe ACEs except in very rare cases, such as administrative 
debugging. And even in those cases, the types of names that you say 
will be typical in the Asian scripts that would be optimized are 
already very long.

Ordinary users will never be expected to type in ACE names. When an 
application leaks ACE names, it will always be a visual 
representation, not something that someone would have to type in by 
hand.

So, to answer your question: no, there is no such need.

--Paul Hoffman, Director

---

From: "Soobok Lee" <[email-masked]>
Date: Sat, 10 Nov 2001 09:32:17 +0900

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 10, 2001 2:07 AM
Subject: Re: [idn] summary of reordering discussion

> debugging. 

MOre than debugging. ALL adminstrative works around web/mail/ceritificate etc.
Do you think all the SW in the world  would be i18ned for IDN ?
There are numorous in-house legacy applications that are difficult to
to upgraded to support UTF8 GUI IDN supports for various reasons.

>And even in those cases, the types of names that you say 
???

> representation, not something that someone would have to type in by 
 
Such visual representation exists for ordinary users' comparisons and
copy&pase and transcription and verification.
You estimate ACE leakage will occur *rarely*. But I don't agree.
Europeans who don't know chinese and often have no installed chinese font sets
will prefer to verify and view them in their ACE form. That's true for arabic/hebrew/hindi/thai/tibetan. bi(tri)-lingualism across continents are 
not common. You i18n *experts* had better take the viewpoints of uni-lingual *laymen*. Think about the distributions of language/script usage and bi-ligualism usage across continents.

See the enclosed ML.com renewal invoice notices which contain ACE labels instead
of UTF8 ones. Why  does most registrars send its invoice with IDN labels in ACE form? Why?

Soobok Lee

==========================================================================
                         DOMAIN EXPIRATION NOTICE
==========================================================================
Greetings 

The domain name(s) listed below will expire on their respective expiration
dates.

However, to protect your valuable domain name(s) immediately, use the link
and instructions provided below to renew them today.

**************************************************************************
Domain(s)
--------------------------------------------------------------------------
bq--3cc6zr2ywpca.com  (Expires 2001-11-09)
bq--3ccujqfm26ea.com  (Expires 2001-11-09)
 
--------------------------------------------------------------------------
**************************************************************************

NOTE: For multilingual domains, the RACE string is listed.  To decode
      the race string and view the native characters, go to our
      Race String Decoder:
      http://www.alldomains.com/multilingual/
==========================================================================
Renewal Is Simple:
1. Log on to your manage page at the following URL 
   http://manage.alldomains.com/
   Username:  
   Password:  

2. Next to "Domain Renewal Options" you may view all the domains that
   expire within a certain date range by clicking "30", "60", or
   "90 Days".  Or you may select individual domains using the checkboxes
   at the end of each row in your domain list.

3. Click "Continue"

4. The next page shows you all of your domains expiring within the date
   range you selected.

5. Simply enter a payment method and your domains will automatically be
   renewed!
==========================================================================
Alldomains.com has created D-Safe(tm) a service designed to safeguard your
valuable domain names by auto-renewing them upon expiration.  Too often
domain holders do not receive their renewal notices due to email and/or
physical address changes only to find their domains registered by another
party after they expire. D-Safe will ensure that your domain names remain
your property by auto-renewing them for one additional year.

D-Safe only works for those customers that paid by credit card.  It will
attempt to charge the most recent credit card on file.  If you paid by
check, you must renew manually following the steps above.

If you do not wish to have your domains protected by D-Safe you may 
disable it for any domain simply by logging into our Domain Manager
at: http://manage.alldomains.com.  Click the domain you wish to disable
D-Safe for, scroll to the bottom, and uncheck the box.
**************************************************************************
Pre-Register your .INFO Domains Today!
---------------------------------------------
.INFO Domain Registrations go live Sept 12th.
If you pre-register yours today you'll have
the best chance of getting the domain.  If
you don't get the domain name you are not
charged!

Pre-Register Here:
http://reg.alldomains.com/infostartup/
**************************************************************************
If you have any questions please contact Alldomains.com in one of the 
following ways.

Phone: +1-925-685-9600, 1-800-561-5131
Email: [email-masked]

Thank you,

The Alldomains.com Renewal Team
_________________________________________
A L L D O M A I N S . C O M
www.alldomains.com    www.hostcentric.com
Ph: +1.925.685.9600   Fx: +1.925.685.9620
A   H O S T C E N T R I C   C O M P A N Y

---

From: "Bruce Thomson" <[email-masked]>
Date: Mon, 12 Nov 2001 13:06:10 +0900

The re-ordering discussion has been a little difficult to follow,
and I am sure that many wg members could use some help
sorting through some of the complex issues involved so they
can participate in the straw poll.

I have prepared a formal analysis of the discussion so far,
which will at least serve as a starting point for those wanting
to research it in more detail. It is attached.

I have tried to be as neutral as possible, but of course
both sides will likely dispute this. :)

Enjoy!

Bruce

---

From: David Hopwood <[email-masked]>
Date: Mon, 12 Nov 2001 23:49:47 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Bruce Thomson wrote (in reordering.txt):
> 3) Reduced encoding lengths will make it less likely that an
> encoded name will be too long.
> 
>   True, but perhaps not of practical significance.
> 
>   The maximum length of a Hangeul domain name is limited by the
>   restriction that a DNS label name be 63 characters or less.
>   Therefore, without re-ordering and assuming a label of the
>   form:
> 
>   www.bq--<ACE-encoded Hangeul>.com.
> 
>   we can calculate the maximum number of Hangeul that can be
>   used in a domain name as:
> 
>   maxHangeul = (maxLabel - prefLength - suffixLength) / encodeRatio
>              = (63 - 8 - 5) / 3.04
>              = 16

The 63-octet limit applies to individual labels (the 255-octet limit
on a full name is not usually the limiting factor in practice).
Therefore the calculation should be:

  maxHangeul = (maxLabel - acePrefixLength) / encodeRatio
             = (63 - 4) / 3.04
             =~ 19 (rounded down)

> - Disadvantages
>
> 1) Might cause problems if new code points were added later.
>
>   Not a problem.
>
>   The algorithm only re-orders existing code points, and will not cause
>   conflicts with new definitions.
>
> 2) Would not be able to be improved if new scripts were added or
>    sub-optimalities discovered.
>
>   Not a problem.
>
>   The algorithm would probably be frozen for all time.

I agree that these are not problems if the reordering is actually
and *definitely* frozen for all time, but Soobok Lee was arguing that
it could be updated for new scripts.

> 5) Too much complexity for not enough benefits.
>
>   Controversial.
>
>   We have to decide if the benefits are worth the effort.

This section is supposed to be listing the disadvantages. The benefits
have already been listed. There's a lot more to be said about complexity
than just a single line without any supporting argument:

5) Reordering increases complexity and reduces efficiency.

  True (what is debatable is the degree of complexity and inefficiency).

  The draft includes 4096 mappings for Han, 1024 for Hangeul, and
  528 for Group 2 and 3 scripts.

  The mappings for Han and Hangeul are sparse: since it
  is undesirable to use tables that cover the whole of the Han and
  Hangeul syllables blocks, implementing them will require something
  like a binary search or hashtable. (The reference code in the draft
  uses linear search, but that has unacceptable performance for
  production code.)

  A more complex specification introduces more opportunities for
  implementation errors.

  The reordering draft argues that nameprep requires similarly
  complex code and tables; but see point 6) below.

Add to the end of point 6):

  Also, note that the nameprep mappings are from less-commonly to
  more-commonly used characters (often, the string will already be
  normalised). Reordering maps from every character in the affected
  scripts. Therefore, errors in reordering that affect a small number
  of characters are likely to be more significant than similar errors
  in nameprep.

Incidentally, I intend to propose a simplification of nameprep that
uses NFC instead of NFKC, and reduces the number of foldings (i.e.
step 1 of stringprep) to about 800. The remaining foldings have
regularities that allow them to be implemented with less than 1 Kbyte
of tables (compared to ~ 10 Kbytes for Han & Hangeul reordering).
This does not count tables needed for NFC normalisation, but those
may already be provided by libraries or the operating system.

This makes a significant difference for memory-constrained devices
that need to interpret HTML, because they can assume that the HTML is
already NFC-normalised, and can be designed so that this also applies
to user input (e.g. a user typing in a URL) [*]. With slight
modifications to stringprep, it is possible to avoid performing
the final NFC normalisation step when the input is known to already
be NFC-normalised. The result is that these devices would not need to
implement NFC at all.

[*] This assumes that they don't support decomposed characters for
    scripts that have some precomposed characters, but that's not an
    unreasonable assumption for constrained devices.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Bruce Thomson" <[email-masked]>
Date: Tue, 13 Nov 2001 16:31:50 +0900

Thanks for the comments David. I will include your modifications in
my report.

> it could be updated for new scripts.

Soobok, in an effort to please both the people who complained that there
was no way to make updates AND the people who thought updates were
way too difficult, basically said that it could be done either way.

My analysis made the assumption that the "freeze it" group would prevail
(for the reasons I gave). There is no problem in that case.

Best regards,
Bruce

----- Original Message ----- 
From: "David Hopwood" <[email-masked]>
To: "Bruce Thomson" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 13, 2001 8:49 AM
Subject: Re: [idn] summary of reordering discussion

> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBO++78zkCAxeYt5gVAQEbZwf/WBmPGo+6TQQ4WZ76bkCYGYSQtjAbbEuk
> D3LrFALySW6VqpgdZY+pL8i1meMGAeYBLLbUJP/cydzF68faQQTzjIe/MKnZ7LyF
> bV9JkKfdGnRBZXnKaCzc5AjZv79OC1wnoi/0K0MAbEOpNOuQO8YqV8+063WkjDP2
> SiGp/HJDA8Yzo6o8Xze2Zg0Q6Qv0tnbmfRPpnVOMXp/bio8RM948vegjKJ0k+rkX
> mptZrPK/UWKROlr49Xdhqj4WetL9RnTnXA6uC/lScDPPjAAzMcG4rcxkSn3ChmaM
> 1D/0pB9IY9+OiaMrd+eAYS+v649Lr8EepdEI+61OhODhtlyMWsXV2w==
> =ufos
> -----END PGP SIGNATURE-----
> 
>

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 13 Nov 2001 18:29:47 +0900

----- Original Message ----- 
From: "Bruce Thomson" <[email-masked]>
To: "David Hopwood" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 13, 2001 4:31 PM
Subject: Re: [idn] summary of reordering discussion

> > it could be updated for new scripts.

It depends on whether or not   nameprep's "query" could contain unassigned code 
points (UCP).

If no, reordering tables for new added scripts (UCP for old nameprep) can bea dded without any interference with older nameprep applications, because old application won't generate any UCP ACE labels.

If yes,  adding is impossible. But even in this case, There is a half-baked proposal :
 another dual prefixing scheme which may be useful
even for UCP handling  beyond  reordering contexts (see thread  "zq-- and uq-- scheme").

Patrick and Paul have given me different ideas on the desired answer to this UCP question.
I am waiting for new revision of nameprep or more WG concensus on that UCP handling issue.

In short, there is a way to support new reordering table for new script, but it depends on
other nameprep issues.

Thanks.

Soobok Lee.

---

From: David Hopwood <[email-masked]>
Date: Tue, 13 Nov 2001 08:43:28 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Soobok Lee wrote:
> It depends on whether or not nameprep's "query" could contain unassigned
> code points (UCP).

It can.

> If yes,  adding is impossible. But even in this case, There is a half-baked
> proposal : [snip]

Precisely: it is half-baked and introduces lots of problems. I won't spend
any more time refuting it unless the straw poll supports reordering (which I
think is very unlikely).

- --

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 13 Nov 2001 08:10:59 -0800

>It depends on whether or not   nameprep's "query" could contain 

Of course it can. The nameprep document is very clear on this, and 
has been for quite some time.

>Patrick and Paul have given me different ideas on the desired answer 

That is simply not true, and another ugly accusation. You have a 
habit of misquoting people who have tried to help you and the WG deal 
with the supposed problems that you bring up; the recent issues with 
you saying that Kent Karlsson said one thing when he said another is 
a good example of this.

It is disturbing that the main proponent of the reordering draft does 
not even understand the basics of the other protocols being discussed 
in this WG. It casts a very negative light on the reordering 
discussion. I hope that people voicing their opinions in the straw 
poll are not swayed by your misunderstandings.

--Paul Hoffman, Director