Re: [idn] (bias) summary of reordering discussion

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message ----- 
From: "David Hopwood" <david.hopwood@zetnet.co.uk>
To: "Soobok Lee" <lsb@postel.co.kr>; <idn@ops.ietf.org>
Sent: Wednesday, October 24, 2001 12:22 PM
Subject: Re: [idn] (bias) summary of reordering discussion


> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Soobok Lee wrote:
> > From: "David Hopwood" <david.hopwood@zetnet.co.uk>
> > >
> > > Make that an explicit objection - I think it's far too complicated to
> > > justify the marginal benefits. Also, any changes or additions to
> > > reordering would have disastrous consequences for name comparison, and
> > > Soobok Lee's zq--/uq-- proposal does not fix this.
> > 
> > I expect you clarify this assertions with detailed examples soon.
> 
> The problem is this: how does an application that doesn't support the
> latest version check whether a zq-- label is equivalent to a uq-- label?
> 
> For nameprep without reordering, an old application can perform matching
> that will be correct provided that the inputs are nameprepped (i.e.
> case folded NFC or NFKC), and this is sufficient for most purposes. In
> your proposal, OTOH, it must just give up, because it has no information
> about how characters are reordered in uq-- labels. I consider this to be
> a fatal flaw in the proposal.

That's  not new problem in uq--/zq-- scheme, but already in current single zq-- scheme.

let's assume new nameprep with new added script  which contains mapping X-->Y.
The mapping may be one of case folding/NFC/NFKC or others.
Old and New nameprep applications  exchanged  differenetly-encoded two 
X.com ACE labels  and  each  did comparisons on two labels. What happens
with single  zq-- scheme ?  Both applications will fail.
even users of new applications  are left clueless for the failure.

But with zq--/uq-- scheme, the new application would succeed, but old application
should give up and issue warning to users that new nameprep labels come in.
zq--/uq-- scheme provides the clues for the failure/inpasse and teach what to to for fallback
mechanisms. That's the virture of uq--/zq-- scheme.

Even without its intended connection to REORDERING issues,  zq--/uq-- scheme are still
worth to research for its pros/cons  for the sake of  consistent/safer handling of 
unassigned code points.  Let's think about more...

Soobok Lee


> 
> This flaw would not arise if reordering only applied to characters that
> are assigned now (i.e. in Unicode 3.1), and new scripts were never
> reordered. In that case the zq--/uq-- versioning wouldn't be needed.
> However, I still don't think that reordering is worthwhile even in that
> case.
> 
> - -- 
> David Hopwood <david.hopwood@zetnet.co.uk>
> 
> 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
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBO9YzrzkCAxeYt5gVAQHtVAgAmjLhWyYvhTnBRHoIcN55JoTY+cTc6JlB
> +kv6kYJ6x2CHJd4iG/3OyIY5J7ix4tqWbn9Zynhk0F4hleCZT+Yn1l7BRSNAnq7i
> TERrhaj2L+0Aw6cI/S1/OCL9TVEBDKA70eSXQH8nzCejG1Zjy3N5dheKwNTpbCyV
> UxpJ3g6CRsFzV1O7z3pItIS2M7DSDeKQzTYa3rJo42bepYv75oTmDfDEvHKLvcRD
> o5qaEnYWOhrWkdvyPPGiG6eW5D7by4kWxyYsnsKJ4ZpThYqRyB70YnWcuBT+/7J1
> k93JBDsgOg8iqCoXVVAxvhFB6IjN4knwIdkuBWCSmudQUleHYiJ4yg==
> =bt61
> -----END PGP SIGNATURE-----
>