[idn] Re: Document Status?

[Simon Josefsson <jas@extundo.com>]

Soobok Lee <lsb@postel.co.kr> writes:

> On Sun, Sep 01, 2002 at 06:03:00PM +0200, Patrik F?ltstr?m wrote:
>> 
>> (a) I get an email with IDNA encoded sender address. I want to add that to
>> some address book software. That imply copy and paste from email program to
>> address book program. The email address have ACE encoded labels in them.
>> 
>> (a1) The email program understand IDNA, but not the address book program.
>> As it understands IDNA, it will display (if the script and font exists) the
>> correct Unicode characters, and not the ACE encoded string. Now, the copy
>> operation happens, and I would if I were the email programmer put two (2)
>> things in the paste buffer: One "email address" which is the ACE encoded
>> string. Same thing as what is passed in SMTP or POP. One which is the
>> address in Unicode (or local script, which will be named as part of the
>> tag). The addressbook which fetches data from the paste buffer gets the
>> string, and notice it is ace encoded, and can choose to decode that if it
>> can/know etc.
>
> I often run xterm and then launch MUTT (or PINE).
> Even if MUTT would become IDNA-aware in the future, copy & paste operations 
> grab the IDN-like strings directly from the xterm, not from the MUTT.
> So, the MUTT cannot have any opportunity to toss ACE-encod the IDN into the 
> receiving applications or the clip board area. Text-based MUA does not have
> any copy&paste support to/from it. Xterm does all the job.

The specifications seems quite clear on what should happen here -- if
there is no negotiation, ACE should be used.  TTY MUAs therefor must
display ACE strings as there is no negotiation between xterm and the
MUA that an IDNA string is being displayed.

> Consistent IDNA-specific and IDNA-aware copy&paste operations, if we make any,
> should be implementable and meaningful also in xterm which has been regarded
> as a purely textual application.

Fully agree.  That's also why I think IDNA should not try to specify
cut'n'paste operations because it will require fundamental changes in
how cut'n'paste work in most operating systems and there are many
dragons there.  IDNA cut'n'paste won't be solved by this WG.

If the goal of IDNA was clearly defined, we wouldn't need to have this
discussion...