----- Original Message ----- From: "David Hopwood" <[EMAIL PROTECTED]> To: "Soobok Lee" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > > > > 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 <[EMAIL PROTECTED]> > > 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----- >
