Re: [idn] Re: REORDERING: stability issues and UTC solutions

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

We have no TAGALOG characters X,Y now. 
After we finalized nameprep/ACE,
TAGALOG script may be added to Unicode.
Then,
 
> My  question was that:
>   1) newly-approved TAGALOG characters X,Y  have   NFC X -> Y,
>   2) old Nameprep/ACE encodes X.com and Y.com as two distinct ACE labels,

unassingned code points are allowed in query from old version nameprep.
X.com Y.com are passed through into DNS servers which have no stored tagalog
labels before TAGALOG is added, but begin to accept it after it's approved & added.

>       because it don't know about NFC X -> Y
>   3) new Nameprep/ACE encodes X.com as the the same ACE label as
>       Y.com's       with NFC  X -> Y.
> 
> >   If X.com and Y.com are taken by two distinct registrants, there will
> >     be a mess. of course, it should have be blocked by careful
> registries.
> >   Even if new ACE libaries are distributed, some old ACE tools will
> still
> >     try to send X.com dns queries which may fail.
> 
this case is described in stringprep-00, section 6.3 paragraph 3.
that query should fail. Old nameprep/ACE applications should send
Y.com instead of X.com even when it gets native X.com from html page
(human input should contain only Y.com, not X.com). 
See the *HAS TO* sentence below.
In such case, end users should upgrade their old applications.
Until upgradea are finishied, someone would have complaints 
for such inconveniences.

****
Newer stored string -- Suppose that an requesting application is using
oldVersion and the stored string was created using a profile that uses
newVersion. Because the requesting application passed through any
unassigned code points, the user can query on stored strings that use
code points in newVersion. No stored strings can have code points that
are unassigned in newVersion, since that is illegal. In this case, the
querying application *HAS TO* enter the unassigned code points in the
correct order, and *HAS TO* to use unassigned code points that would make it
through both the mapping and the normalization steps.
*****
 
Soobok Lee
==============================================

http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt


6.2 Reasons for difference between stored strings and requests

Different software using different versions of a stringprep profile need
to interoperate with maximal compatibility. The scheme described in this
section (stored strings MUST NOT contain unassigned code points,
requests MAY include unassigned code points) allows that compatibility
without introducing any known security or interoperability issues.

The list below shows what happens if a request contains a code point
from category U that is allowed in a newer version of a profile. The
request either matches the string that was intended, or matches no
string at all. In this list, the request comes from an application using
version "oldVersion" of a profile, the stored string was created using
version "newVersion" of the same profile, and the code point X was in
category U in oldVersion, and has changed category to AO, MN, or D.
There are 3 possible scenarios:

1. X is assigned to AO -- In newVersion, X is in category AO. Because
the application passed X through, it gets back a correct match with the
stored string. There is one exceptional case, where X is a combining
mark.

The order of combining marks is normalized, so if another combining mark
Y has a lower combining class than X then XY will be put in the
canonical order YX. (Unassigned code points are never reordered, so this
doesn't happen in oldVersion). If the request contains YX, the request
will get correct match with the stored string. However, no string can be
stored with XY, so a request with XY will correctly get a negative
answer to the test for matching.

2. X is assigned to MN -- In newVersion, X is normalized to code point
"nX" and therefore X is now put in category MN. This cannot exist in any
stored string, so any request containing X will correctly get a negative
answer to the test for matching. Note, however, if the request had
contained the letter nX, it would have correctly matched.

3. X is assigned to D -- In newVersion, X is in category D. This cannot
exist in any stored string, so any request containing X will correctly
get a negative answer to the test for matching.

In none of the cases does the request get data for a stored string other
than the one it actually tried to match against.

The processing in this document is always stable. If a string S is the
result of processing on newVersion, then it will remain the same when
processed on oldVersion.

6.3 Versions of applications and stored strings

Another way to see that this versioning system works is to compare what
happens when an application uses a newer or older version of this
document.

Newer query application -- Suppose that a requesting application is
using version newVersion and the stored string was created using version
oldVersion. This case is simple: there will be no characters in the
stored string that cannot be requested by the application because the
new profile uses a superset of the code points used for making the
stored string.

Newer stored string -- Suppose that an requesting application is using
oldVersion and the stored string was created using a profile that uses
newVersion. Because the requesting application passed through any
unassigned code points, the user can query on stored strings that use
code points in newVersion. No stored strings can have code points that
are unassigned in newVersion, since that is illegal. In this case, the
querying application has to enter the unassigned code points in the
correct order, and has to use unassigned code points that would make it
through both the mapping and the normalization steps.


7. Security Considerations

The Unicode and ISO/IEC 10646 repertoires have many characters that look
similar. In many cases, users of security protocols might do visual
matching, such as when comparing the names of trusted third parties.
Stringprep does nothing to map similar-looking characters together.