Internationalized Domain Name (idn)

Patrik Fältström | 1 Sep 18:03

Picon

Re: Document Status?

--On 2002-09-01 08.53 -0400 "vinton g. cerf" <vinton.g.cerf <at> wcom.com> wrote:

> I know I would need special software to render Hangul or Kanji, for
> instance, but I assume that the rendering packages also serve to make
> highlighting and cut/paste work.

The copy and paste problem is difficult, but not so hard as people belive
(I think).

I know how copy and paste work on the Apple Macintosh platform, and as that
has been around and worked that way for decades(!) I take for granted it
works the same way in for example Windows.

When doing "copy", the software "sending" the copied information identifies
the selection and calls a routine which notifies the operating system that
data exists in the paste buffer. The information passed include information
like what type(s) the data can be fetched as, the size(s) etc. Note that
several alternatives can be stored there.

It looks like the content-type mechanism in email. Very precise tagging of
the data.

Now, some other application have a menu which is to be drawn. The menu
includes an item called "paste". Before doing the actual drawing, it calls
a routine to check (a) if there is something in the paste buffer, and (b)
if the data is of a type which it can interpret. If both are true, the menu
item "paste" is _not_ shadowed.

The paste operation happens, and it can either grab data which is already
generated by the sender application, or the sender application is called

(Continue reading)

Soobok Lee | 1 Sep 20:59

Picon

Re: Document Status?

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.

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.

Soobok Lee

(Continue reading)

Eric A. Hall | 2 Sep 05:45

Re: Document Status?


on 9/1/2002 1:59 PM Soobok Lee wrote:

> I often run xterm and then launch MUTT (or PINE).

<snip>

This problem goes beyond xterm. For all practical purposes, all apps will
be required to use the text form for all exchanges, except in those cases
where the operating environment provides an "i18n domain name" data-type
as part of the clipboard protocol. Unless an application is willing to
explicitly claim support for ACE encoded domain names, there can be no
guarantee that the recipient application will be able to make sense of the
domain name.

Separately, the canonical problem here is managing multiple
representations and trying to negotiate over which representation should
be used for some specific function. This problem won't go away until the
i18n form is available in all protocols and applications directly. In this
regard, IDNA is a patch that introduces a new problem, not a cure to the
existing problem. Having said that, some degree of transition and
therefore negotiation is of course necessary. It should not be the end,
however. I would hate to think that we consider the problem resolved after
only having made it worse.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

(Continue reading)

Eric A. Hall | 2 Sep 06:03

Re: Document Status?


[oops]

on 9/1/2002 10:45 PM Eric A. Hall wrote:

> Unless an application is willing to explicitly claim support for
> ACE encoded domain names,
  ^^^^^^^^^^^
 internationalized

> there can be no guarantee that the recipient
> application will be able to make sense of the domain name.

...so the default will always be ASCII.

Proof: dozens if not hundreds of common applications that accept i18n data
as input and don't error out until the back-end protocol(s) fail.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Simon Josefsson | 1 Sep 21:34

Re: Document Status?

Soobok Lee <lsb <at> 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.

(Continue reading)

Patrik Fältström | 2 Sep 07:05

Picon

Re: Document Status?

--On 2002-09-01 21.34 +0200 Simon Josefsson <jas <at> extundo.com> wrote:

> 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.

It is not more strange than what we have for Subject-lines today.

Should the tty client display subject lines encoded according to RFC 2047,
or decoded? If you cut and paste via xterm something which is decoded, and
paste somewhere else, it is still up to the email client and other involved
applications "to do the right thing". Right thing is to see that non-IDNA
applications get the ACE encoded version of domain names.

   paf

Simon Josefsson | 2 Sep 08:25

Re: Document Status?

Patrik Fältström <paf <at> cisco.com> writes:

> --On 2002-09-01 21.34 +0200 Simon Josefsson <jas <at> extundo.com> wrote:
>
>> 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.
>
> It is not more strange than what we have for Subject-lines today.

There is a important difference; subject lines aren't used to route
mail or identify persons.

If I cut'n'paste a subject line and it is garbled, the only harm will
be a garbled subject line.

If I cut'n'paste an IDN email address and it is garbled, I will send
mail to the wrong person, potentially even encrypted mail embedding
sensitive information, as security systems like OpenPGP and S/MIME
uses email addresses to identify people.

Just making IDN "work", as in displaying fancy glyphs, isn't good
enough, it also shouldn't generate new security problems.  MIME only
dealt with the data, it did not modify interpretation of the
addressing system, and still managed to generate security problems.

Dave Crocker | 2 Sep 10:28

Re: Re: Document Status?

At 09:16 AM 9/2/2002 +0200, Patrik Fältström wrote:
>--On 2002-09-02 08.25 +0200 Simon Josefsson <jas <at> extundo.com> wrote:
> >> It is not more strange than what we have for Subject-lines today.
> > There is a important difference; subject lines aren't used to route
> > mail or identify persons.
>
>I was not thinking of what we use it for.

Folks,

Let's assume that these various "differences" do exist.

So what?

If someone is going to claim that IDNA will not work as it is designed to 
work, they need to explain how it will fail.

d/

----------
Dave Crocker <mailto:dave <at> tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

Patrik Fältström | 2 Sep 09:16

Picon

Re: Document Status?

--On 2002-09-02 08.25 +0200 Simon Josefsson <jas <at> extundo.com> wrote:

>> It is not more strange than what we have for Subject-lines today.
> 
> There is a important difference; subject lines aren't used to route
> mail or identify persons.

I was not thinking of what we use it for. 

I was thinking of the errors one can get.

   paf

Eric A. Hall | 2 Sep 08:12

Re: Re: Document Status?


on 9/2/2002 12:05 AM Patrik Fältström wrote:

> It is not more strange than what we have for Subject-lines today.

Except that Subject: is unstructured data which is not processed as
protocol data. And even when where parts of Subject: are interpreted as
data (such as "Re:"), they are required to be in ASCII for them to work.

Domain names are structured and used as protocol data everywhere. Any
strangeness with a domain name is an opportunity for total failure, even
outside the scope of the local application. It won't take long for folks
to figure out that they have to use ASCII for everything, except where
some function provides an explicit IDN data-type and can guarantee that it
will handle any necessary conversion.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

YangWoo Ko | 2 Sep 04:45

Picon

Re: Re: Document Status?

On Sun, Sep 01, 2002 at 09:34:26PM +0200, Simon Josefsson wrote:
> Soobok Lee <lsb <at> postel.co.kr> writes:
> >
> > 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.

Dear Simon,

Oops. Then I will encounter very ugly environment in the near future.

Dear idn-ers,

Please tell me that simon's understanding is wrong. Negotiation in IDNA
draft seems either poorly documented or poorly understood.

Korean mutt user.

(Continue reading)

Simon Josefsson | 2 Sep 05:16

Re: Document Status?

YangWoo Ko <yw <at> mrko.pe.kr> writes:

>> 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.
>
> Dear Simon,
>
> Oops. Then I will encounter very ugly environment in the near future.
>
> Dear idn-ers,
>
> Please tell me that simon's understanding is wrong. Negotiation in IDNA
> draft seems either poorly documented or poorly understood.

I agree the specifications aren't clear, but at least Patrik Fältström
answered clearly in another part of this thread, unless I
misunderstood him again -- which isn't unlikely, as I fail to locate
the text in the IDNA specification that back the claims made.  From
<35817839.1030912013 <at> localhost>:

Patrik Fältström wrote:

> Simon Josefsson wrote:
>
> If the
> strings are to be ACE encoded or raw encoded is not specified anywhere
> as far as I can tell, and different implementations will chose
> different strategies.

(Continue reading)

Soobok Lee | 2 Sep 04:43

Picon

Re: Re: Document Status?

On Mon, Sep 02, 2002 at 11:09:29AM +0900, YangWoo Ko wrote:
> On Sun, Sep 01, 2002 at 09:34:26PM +0200, Simon Josefsson wrote:
> > Soobok Lee <lsb <at> postel.co.kr> writes:
> > >
> > > 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.
> 
> Dear Simon,
> 
> Oops. Then I will encounter very ugly environment in the near future.

Yes, if and only if we enforce that the copy & paste buffer should *always* be filled 
with the ACE-encoded IDN . Otherwise,if we also allow in the paste buffer 
other local-charset-encoded IDN , instead, various interoperability problems 
will arise. Both situations seem ugly... 

Soobok Lee

Patrik Fältström | 2 Sep 07:09

Picon

Re: Re: Document Status?

--On 2002-09-02 11.43 +0900 Soobok Lee <lsb <at> postel.co.kr> wrote:

> Yes, if and only if we enforce that the copy & paste buffer should
> *always* be filled  with the ACE-encoded IDN .

Not needed if the copy-paste buffer can include tagged data. You talk about
transcoding tables, but for many non-unicode charsets the mapping table is
a 1:1 mapping, especially Unicode strings after Nameprep has been applied.
And, there is no problem with tagged data to say that "for this type, this
transcoding table is to be used.

You talk about X11 which only have charset information in the tagging, and
yes, there it might be problematic. On other operating systems, like MacOS,
there will be no problem.

But, as you point out, if an application is conservative and only give out
ACE to other applications, you will be safe, as all IDNA-aware applications
can detect and decode ACE.

Be conservative with what you send, and generous with what you receive.

    paf

Simon Josefsson | 1 Sep 19:42

Re: Document Status?

Patrik Fältström <paf <at> cisco.com> writes:

> (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.

At least in X11 cut'n'paste works by transfering charset tagged but
otherwise opaque character arrays.  What you are proposing seem to
require a cut'n'paste protocol to be implemented in both the MUA and
the address book application.  The protocol must specify how the
structure containing the raw string and the ACE encoded string is
encoded and identified by both applications.  Will IDNA define this
protocol for X11, MacOS, Windows etc?

Assuming IDNA will limit itself to not require modifications to
cut'n'paste operations in various operating systems, you will only be
able to cut'n'paste charset tagged but opaque text strings.  If the
strings are to be ACE encoded or raw encoded is not specified anywhere
as far as I can tell, and different implementations will chose
different strategies.  If the application is running in a Unicode
environment, it might (only might!) make sense to transfer the raw
Unicode encoding, but if it is running in a non-Unicode environment
the IDNA specification leaves you in the cold as for how to implement

(Continue reading)

Adam M. Costello | 2 Sep 05:16

Re: Re: Document Status?

Simon Josefsson <jas <at> extundo.com> wrote:

> At least in X11 cut'n'paste works by transfering charset tagged but
> otherwise opaque character arrays.

Cut & paste in X11 works fine when everything is ASCII.  Otherwise, in
my experience, it is quite broken already, even before IDNs enter the
picture.

For example, I often run a text-mode editor in one kterm, and a
text-mode browser in another.  I can cut and paste English and Japanese
text between them with no problems.  However, if I try to copy Japanese
text from Netscape 4 into a kterm, it does not work.  I figured out how
it was broken and implemented a hack to make it possible (a small tcl/tk
program that provides a button that grabs the selection, performs the
transcoding, and re-exports the selection).

Now when I try to copy text from Mozilla 1.0 into a kterm, it doesn't
work, but it's broken in some other way that I haven't investigated
yet, so then what I do is copy the URL, load the page into my text-mode
browser, and copy the text from there.

So I think it's true that cutting and pasting IDNs in X11 will fail in
many cases, but not because IDNs are so difficult, but only because
cutting and pasting anything other than ASCII text is already broken to
begin with.

Patrik Fältström <paf <at> cisco.com> wrote:

> IDNA says that if no negotiation exists between two entities which

(Continue reading)

Simon Josefsson | 2 Sep 06:07

Re: Document Status?

"Adam M. Costello" <idn.amc+0 <at> nicemice.net.RemoveThisWord> writes:

> Simon Josefsson <jas <at> extundo.com> wrote:
>
>> At least in X11 cut'n'paste works by transfering charset tagged but
>> otherwise opaque character arrays.
>
> Cut & paste in X11 works fine when everything is ASCII.  Otherwise, in
> my experience, it is quite broken already, even before IDNs enter the
> picture.

Recent versions of X11 and various utilities work better (e.g., in the
Unicode based RedHat Linux beta), but there are still applications
that doesn't work fully.  Latin-1 cut'n'paste has worked for me for
years.

>> > 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 therefore must
>> display ACE strings as there is no negotiation between xterm and the
>> MUA that an IDNA string is being displayed.
>
> That conclusion does not follow from the IDNA spec.  ASCII forms are
> required only in IDN-unaware domain name slots.  The tty is not a domain

(Continue reading)

Adam M. Costello | 3 Sep 04:56

Re: Re: Document Status?

Simon Josefsson <jas <at> extundo.com> wrote:

> In the particular example of a MUA running in XTERM (or a Unicode unix
> console, for that matter), it will likely not work out as I'm not
> aware of any API between a TTY application and the terminal to query
> which unicode characters it can display, and whether it supports bidi,
> and in that case it seems this paragraph from 6.4 would apply,
> suggesting that MUAs should use ACE anyway:
> 
> ,----
> | If an application decodes an ACE name using ToUnicode but cannot
> | show all of the characters in the decoded name, such as if the
> | name contains characters that the output system cannot display,
> | the application SHOULD show the name in ACE format (which always
> | includes the ACE prefix) instead of displaying the name with the
> | replacement character (U+FFFD).
> `----

The spec says that an application SHOULD NOT show the ACE form if it can
correctly display the Unicode form, and it SHOULD show the ACE form if
it cannot correctly display the Unicode form.  Both recommendations have
equal weight.  If the application cannot know which Unicode characters
can be displayed, then it cannot know which recommendation applies.
If the application is optimistic about the display capabilities, it
risks violating the second recommendation, and if the application is
pessimistic, it risks violating the first recommendation.

The situation is symmetric.  I see no reason to conclude that the spec
favors optimism or pessimism.

(Continue reading)

YangWoo Ko | 2 Sep 06:36

Picon

Re: Re: Document Status?

Dear all,

Why should IETF WG handle implementation issues of specific OS/GUI ?
What about just let others handle them ?

Is it possible to remove every application-related features out of IDNA
document except IDN being ACE encoded somewhere and somehow outside of
DNS ? Does it help or harm ?

Regards

On Mon, Sep 02, 2002 at 06:07:23AM +0200, Simon Josefsson wrote:
> "Adam M. Costello" <idn.amc+0 <at> nicemice.net.RemoveThisWord> writes:
>
> > Simon Josefsson <jas <at> extundo.com> wrote:
> >
> >> At least in X11 cut'n'paste works by transfering charset tagged but
> >> otherwise opaque character arrays.
> >
> > Cut & paste in X11 works fine when everything is ASCII.  Otherwise, in
> > my experience, it is quite broken already, even before IDNs enter the
> > picture.
>
> Recent versions of X11 and various utilities work better (e.g., in the
> Unicode based RedHat Linux beta), but there are still applications
> that doesn't work fully.  Latin-1 cut'n'paste has worked for me for
> years.
>
> >> > Even if MUTT would become IDNA-aware in the future, copy & paste
> >> > operations grab the IDN-like strings directly from the xterm, not

(Continue reading)

YangWoo Ko | 2 Sep 06:59

Picon

Re: Re: Document Status?

Dear all,

Why should IETF WG handle implementation issues of specific OS/GUI ?   
What about just let others handle them ?

Is it possible to remove every application-related features out of IDNA
document except IDN being ACE encoded somewhere and somehow outside of
DNS ? Does it help or harm ?

Regards

On Mon, Sep 02, 2002 at 06:07:23AM +0200, Simon Josefsson wrote:
> "Adam M. Costello" <idn.amc+0 <at> nicemice.net.RemoveThisWord> writes:
> 
> > Simon Josefsson <jas <at> extundo.com> wrote:
> >
> >> At least in X11 cut'n'paste works by transfering charset tagged but
> >> otherwise opaque character arrays.
> >
> > Cut & paste in X11 works fine when everything is ASCII.  Otherwise, in
> > my experience, it is quite broken already, even before IDNs enter the
> > picture.
> 
> Recent versions of X11 and various utilities work better (e.g., in the
> Unicode based RedHat Linux beta), but there are still applications
> that doesn't work fully.  Latin-1 cut'n'paste has worked for me for
> years.
> 
> >> > Even if MUTT would become IDNA-aware in the future, copy & paste
> >> > operations grab the IDN-like strings directly from the xterm, not

(Continue reading)

Soobok Lee | 2 Sep 07:37

Picon

Re: Re: Document Status?

----- Original Message ----- 
From: "YangWoo Ko" <newcat <at> spsoft.co.kr>
To: "IETF idn working group" <idn <at> ops.ietf.org>
Sent: Monday, September 02, 2002 1:59 PM
Subject: Re: [idn] Re: Document Status?

> Dear all,
>    
> Why should IETF WG handle implementation issues of specific OS/GUI ?   
> What about just let others handle them ?

Implementation specifics and implementability issues are different. The latter 
one may be one of architectural/security issues which we should discuss on.

>   
> Is it possible to remove every application-related features out of IDNA
> document except IDN being ACE encoded somewhere and somehow outside of
> DNS ? Does it help or harm ?

If you begin to remove those features, only Punycode draft  will remain in the pool.
IDN is not only a problem of DNS server/client, but also problems around applications
which uses domain names as *local* identifiers and do comparisons on them.

Soobok Lee

>   
> Regards
>

(Continue reading)

Patrik Fältström | 1 Sep 20:26

Picon

Re: Document Status?

--On 2002-09-01 19.42 +0200 Simon Josefsson <jas <at> extundo.com> wrote:
> At least in X11 cut'n'paste works by transfering charset tagged but
> otherwise opaque character arrays.

Ok. Good.

> What you are proposing seem to
> require a cut'n'paste protocol to be implemented in both the MUA and
> the address book application.

Not at all.

What I say is that one should send the ACE encoded string in the paste
buffer. Further, that is what will happen when an application doesn't know
anything about IDNA at all. In cases like MacOS where one can have
alternative forms of the data, it is possible to define a new type for the
Unicode version of the domain name.

> If the
> strings are to be ACE encoded or raw encoded is not specified anywhere
> as far as I can tell, and different implementations will chose
> different strategies.

IDNA says that if no negotiation exists between two entities which exchange
domain names between them, ACE encoding should be used. There is no
difference between a protocol which uses IP or the paste buffer. It is the
same thing.

> In general, cut'n'paste of IDNA in the real world is not well defined,
> since IDNA only solves the IDNA problem for Unicode, and the real

(Continue reading)

Simon Josefsson | 1 Sep 21:21

Re: Document Status?

Patrik Fältström <paf <at> cisco.com> writes:

>> What you are proposing seem to
>> require a cut'n'paste protocol to be implemented in both the MUA and
>> the address book application.
>
> Not at all.

OK, then I misunderstood what you said.  Disregard my mail..

>> (d) Email program understands IDNA but is running in a non-Unicode
>>     environment.  The address is tagged and is transfered to address
>>     book application using e.g. ISO-8859-1.  IDNA doesn't handle or
>>     care about this scenario, but it do exists in the real world
>>     (e.g. my machine).
>
> See above, if the address is to be transferred to other application, it
> should either be negotiated that it is an IDN in a specific charset (like
> 8859-1) or sent as ACE.

Even tagging data as being an IDN encoded into a (legacy) coding
system isn't sufficient to use IDNA interoperably, as no transcoding
tables are specified.  But I'm starting to repeat myself from another
thread now.

Return

Return to gmane.ietf.idn.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane