At 11:23 AM 4/2/2002 +0800, James Seng wrote: >Case 2: From IDNA A1 thru MIM to non-IDNA A2 >... >A2 receive ACE. But it is not able to understand ACE so it display the ACE >as-it-is.
So that we are clear: nothing breaks. The string is ugly, but it is legal and A2 does with that string whatever it usually does with ASCI DNS strings. >Case 3: From non-IDNA A1 thru MIM to IDNA A2 > >A1 capability to handle IDN is unknown. It may send out as-is in whatever >encoding the user specify. Sorry, no. If A1 is a non-IDNA DNS mechanism, then it supports non-IDN strings. In other words, it supports the existing set of ASCII DNS strings. You are specifying that a mechanism which is not converted to IDNA will somehow start issuing new strings that are neither current ASCII nor IDNA-encoded ASCII. Unless you can provide more detail to this example -- so that we can understand concretely how it could happen -- then the problem with the example is that it will not happen. >Case 4: From non-IDNA A1 thru MIN to IDNA A2 > >A1 capability to handle IDN is unknown. It may send out as-is in whatever >encoding the user specify. This example has the same problem as Case 3. The simple scenarios that ARE valid are simply: Reality 1: Old ASCII mechanism interacts with Old ASCII mechanism the same always. Reality 2: New IDNA mechanism interact with New IDNA mechanism, for extended names, as specified by IDNA. Reality 3: New IDNA mechanism interact with New IDNA mechanisms AND with Old ASCII mechanisms, for old names, the same as always. Reality 4: New IDNA mechanism interacts with Old ASCII mechanism, for extended the names, in the old way, except that the Old ASCII mechanism sees some truly ugly strings. Except for the lack of prettiness, the interaction with Old ASCII DNS mechanisms is unchanged. d/ ---------- Dave Crocker <mailto:[EMAIL PROTECTED]> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
