Internationalized Domain Name (idn)

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

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