[idn] old version nameprep applications

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

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" <lsb@postel.co.kr>
 
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