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.
