Hi, David >From clearer understanding of stringprep's strict restrictions on unassigned code >points, the exchange scenario of the enclosed second paragraph of my previous posting, cannot happen and two cases have even no chance to fail or succeed.
To send new script label, old application should be upgraded. Therefore, exchange scenario and its one direction of success case are possible only under uq--/zq-- scheme which does not prohibit old nameprep application to encode unassigned code points with uq-- prefix. Soobok Lee ----- Original Message ----- From: "Soobok Lee" <[EMAIL PROTECTED]> 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
