I think your four cases have covered all possible out comes. The case 4 is a dumb terminal assumes uniform display code on the screen and treats them the same, and it works.
Case 2 fails due to the IDNA application carrys its own display procedure, which is cut&paste enabled only within the application, not pastes outside the application. This is an understandable case. Liana Ye On Mon, 1 Apr 2002 09:57:04 +0800 "James Seng" <[EMAIL PROTECTED]> writes: > One of the interesting arguments on IDNA is on copy & paste. Although > the > general copy & paste problem is out of scope for the group, let me > drop a > stone into the water. > > Clipboard mechanism can be either "dumb" (i take what you give me) > to > "smart" (understanding how to process and tag strings). > > Assumption: Applications which runs on OS that have smart clipboard > are > likely able to copy & paste properly since the clipboard can do the > neccessary transcoding between different encodings, native, UTF-8, > ACE etc > between applications. Therefore, we only examine the cases whereby > the > clipboard is dumb. > > Case 1: Copy from IDNA Application (A1) to IDNA Application (A2) > > A1 is going to receive IDN in ACE format and would display the IDN > correctly > to the user. > > In order to display the IDN correctly to the user, A1 would display > the IDN > in some font encoding (not neccessary UTF-8). When copy occurs, the > dumb > clipboard will recieve it in font encoding and then paste it > as-it-is to the > A2. > > A2, occuring to the specification of IDNA, would transcode the font > encoding > it recieved from the paste to Unicode, then Nameprep it then apply > Punycode > which will gives us the exactly the same IDN as before. It would > also > display the IDN correctly. > > Therefore, resolving works, display works. > > Case 2: Copy from IDNA Application (A1) to non-IDNA Application (A2) > > A1 is going to receive IDN in ACE format and would display the IDN > correctly > to the user. > > In order to display the IDN correctly to the user, A1 would display > the IDN > in some font encoding (not neccessary UTF-8). When copy occurs, the > dumb > clipboard will recieve it in font encoding and then paste it > as-it-is to the > A2. > > A2 would take the font encoding and likely either to do name-check > and fail > or send-as-it-is. Either way, resolving fails, display works on A1 > but not > A2. > > Case 3: Copy from non-IDNA Application (A1) to IDNA Application (A2) > > A1 is going to receive IDN in ACE format but would not display the > IDN > correctly to the user, ie, it would display ACE to the user. > > When copy occurs, the dumb clipboard will recieve it in ACE, and > then paste > it as-it-is to A2. > > A2, occuring to the specification of IDNA, would transcode the ACE > it > recieved from the paste to Unicode, then Nameprep it then apply > Punycode > which will gives us the exactly the same ACE as before. It would > also > display the IDN properly (altho A1 wouldnt). > > Therefore, resolving works, display works on A2 but not A1. > > Case 4: Copy from non-IDNA Application (A1) to non-IDNA Application > (A2) > > A1 is going to receive IDN in ACE format but would not display the > IDN > correctly to the user, ie, it would display ACE to the user. > > When copy occurs, the dumb clipboard will recieve it in ACE, and > then paste > it as-it-is to A2. > > A2 would take the ACE, thinking it is some valid domain name, > continue > send-it-as-it-is. It will also not display correctly to the user. > > Therefore, resolving works, display fail for both A1 & A2. > > Summary: > > Case 1: resolving works, display works. > Case 2: resolving fails, display works on A1 but not A2. > Case 3: resolving works, display works on A2 but not A1. > Case 4: resolving works, display fail for both A1 & A2. > > Is there anything else I missed? > > -James Seng >
