[idn] suggestion: two prefices scheme for unassigned code points treatments.

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

----- Original Message ----- 
From: "James Seng/Personal" <jseng@pobox.org.sg>

> Wait wait..new prefix??
> 
> You are going down a path whereby a *single* domain name may have *X*
> number of ACE, 

Yes,it may happen, but  only if we do it loosely.

To treat unassigned code points more consistenly and safely 
through out  all nameprep upgrade paths with/without reordering,
i propose the next new prefixing scheme with two prefices: uq-- and zq--.


Let's assume we adopt "zq--" prefix for valid ACE labels.
I suggest we use another "uq--" prefix for invalid ACE labels which contains at least one unassigned code point at one time. When the unassigned code points become *defined* later, new nameprep/ACE libraries may encode them using "zq--", no more with "uq--". Then we could devise some fallback mechanims on all "uq--????" labels coming from old nameprep/ACE   in application sides  receiving the uq-- labels.

all 'zq--????' labels can be trusted if registries
are careful enough to enforce the integrity.

All "uq--????" labels should not be trusted and all application/dns servers should
have some fallback/warning mechanisms form them. 

Case 1) a newly assigned code point don't have any NFC/NFKC/Case mapping:
Then, the native label containing it would be ACE-encoded into :
"uq--abcd" from old nameprep/ACE, and 
"zq--efgh" from new nameprep/ACE.
then  the authoritative dns server  for the native label,
of course, sets "uq--abcd"  to be an alias to the other "zq--efgh".
 
Case 2) a newly assigned code point is mapped into other code point by one
of NFC/NFKC/CaseMapping ( X->Y ):
Then the native label would have related three different ACE labels:
"uq--abcd" from old nameprep/ACE for X and 
"uq--ijkl" from old nameprep/ACE for Y and 
"zq--mnop" from new nameprep/ACE for Y.
then  the authoritative dns server  for the native label, should
set "uq--abcd" and "uq--ijkl" to be  aliases to the right "zq--mnop".
The number of such aliased labels would be combinatorically multiplied 
if the native label contains more than 1 mapped characters.

no dns server upgrade is needed. additional zone adminstration is enough.

But, the applications should issue warnings for all occurrences of "uq--xxxx" for security reasons, because all old(out-dated) online/offline-mode applications may fail to match "uq--abcd" and "uq--ijkl" and "zq--mnop" in Case 2) which should be regards as equal.
 
certificate authories should not issue website/email
certificates applied with identity information containing "uq--abcd".
Applicants should be warned to retry with upgraded software to 
generate their new email/website ACE addresses with "zq--" prefix.

If old email clients receives senders' addresses with "uq--",
then they should give warnings to end users that something dangerous
string may be in it. If the email clients is upgraded to know both old and new nameprep, the uq-- label is decoded into native label and then re-encoded into zq--
label with new nameprep/ACE and can try successful comparisons!!!
This may be the unique feature that  cannot be provided by current nameprep
versioning scheme.

Without this  "two prefices scheme", online/offline applications ( dns servers  are
adminstrated by intelligent and careful zone masters) may not know
whether "zq--????" labels are from dangerous old nameprep or new nameprep, and
don't know whether "zq--????" is equal to "uq--????" from old nameprep/ACE.

These new prefixing scheme ,of course, cannot be used to correct false NFC/NFKC.
But it provide more security.

Moreover,it may used to incorporate new reordering tables for newly approved scripts/newly assigned code points  even with single "zq--" prefix, whenever the native labels contain at least one of previously-unassigned-but-now-added code block for which we can make new-statitiscs-backed new reordering tables that cover only the code ranges consisting of the new added code points. Old reordering tables don't touch the unassigned code points. There  will be no collision because new zq-- labels will be unique in that old zq-- labels don't contain new code points. "uq--" has no reordering support for unassigned code points, only "zq--" does. "uq--" labels are always unique, too.

halfbaked idea. welcome any corrections and suggestions.

Soobok Lee

> each one with a different prefix, depending on the
> version number of re-ordering & nameprep. Great, please explain how the
> client going to do matching with different version, or client & server
> without some form of communication?
> 
> 
> -James Seng