Re: [idn] copy & paste

[Liana Ye <liana.ydisg@juno.com>]

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" <jseng@pobox.org.sg>
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
>