Subject: Re: [idn] The report from the design team

From: Marc Tamsky <[email-masked]>
Date: 13 Feb 2001 20:13:59 -0800

>>>>> On 15 Jan 2001 11:56:15 -0000, "D. J. Bernstein" <[email-masked]> said:

>>   The application-only solutions proposed are clearly easier to
>>   implement than the infrastructure solutions,

>  I don't believe you. We need facts about the actual deployment costs,
>  not buzzwords like ``application-only.''

>  I've started a web page at http://cr.yp.to/proto/idn.html to tally the
>  costs of the proposals. Specific contributions are welcome.

>>   However, we cannot simply put binary characters into the current DNS
>>   without breaking many protocols and many DNS servers.

>  Give us the details. Exactly which pieces of software break, and how?

I concur with Dan's line of questioning here.

Every argument to date has been hand-waving about "software that will
break."

Which pieces of software, that use what protocols will break when
UTF-8 appears in DNS RR?
How do they break?
Is the author/company still maintaining it?
Is it known how easy it is to work a fix?
Has a fix been published?
Is it an input system problem?
Does it depend on the OS resolver getting changed?

More of these questions need to be identified and cataloged.  Only
then can anyone say with some basis in fact, and not conjecture, that
one proposal creates more or less work than another.

Today, if those same "broken" pieces of software were to be fed
non-RFC DNS information and they crash, wouldn't that be material for
a new or existing CERT advisory?  (DOS vulnerability, host compromise
come to mind.)

Marc.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 13 Feb 2001 20:53:52 -0800

> Every argument to date has been hand-waving about "software that will

My .02 to this is that I don't believe we should be requiring that a
solution make all legacy implementations forward compatibile.

Note that this is different from backwards compatible. The requirements as
stated are trying to make legacy gear forward compatibile with some future
solution. Instead, it should be focused on ensuring that whatever future
solution is chosen does not willingly break legacy equipment.

We certainly don't design RRs so that they instantly function with all
legacy equipment. We don't design ESMTP extensions so that they
immediately function with legacy mailers. Instead we design so that we
don't break legacy stuff, and then leave it up to the net admins and
operators to upgrade when the feature is important.

IMO we should be treating IDNS the same way. We are limiting ourselves by
an artifical and unreasonable restriction when we demand that all
proposals must "allow any system anywhere to resolve any internationalized
domain name." That requirement should be removed from the spec completely.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Feb 2001 01:00:16 -0500

> domain name." That requirement should be removed from the spec completely.

the requirement might be overstated, but I don't think we can eliminate it
completely.  to put the question in a more practical light: if someone sends 
out mail with a return address that uses an IDN, is it acceptable if the 
recipient cannot reply to that message unless his mail reader and the chain 
of SMTPs between him and the original sender support IDNs?

personally, I don't think so.

Keith

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 13 Feb 2001 23:26:54 -0800

> the requirement might be overstated, but I don't think we can
> eliminate it completely.

Let me point out that this requirement prohibits the EDNS, DNSII, and new
Class proposals, and also prohibits longer labels and names (they will not
be forward compatible with legacy equipment). No change to DNS whatsoever
will be tolerated by the current requirement.

> to put the question in a more practical light: if someone sends
> out mail with a return address that uses an IDN, is it acceptable
> if the recipient cannot reply to that message unless his mail
> reader and the chain of SMTPs between him and the original sender
> support IDNs?

The end-user still has to upgrade the MUA to use ACE. If he doesn't, then
at least one of the SMTP servers will have to do the work (assuming they
accept an unconverted IDN from the MUA in the first place) whenever the
user clicks on the internationalized mailto: link.

We are talking about varying degrees of breakage. Anything that presents a
process with a local-format IDN has the potential to break things if the
systems aren't compliant with whatever solution is chosen, and this
includes ACE. Breakage of some degree is absolutely unavoidable.

As for how a new DNS message format would address this problem, no mail
server should accept MAIL FROM which includes a domain name that the MTA
doesn't recognize as legitimate, so in all likelihood a new ESMTP
extension would almost certainly be required in order to accomodate an IDN
solution that uses longer labels/names or non-ascii characters in the SMTP
envelope. This may be required even when ACE is used though. What then?

There are other examples which are also hard to deal with. Ancient print
servers that fire off alerts over SMTP aren't likely to be fixed easily,
and ACE allows them to work with IDNs after a manual conversion and
reconfiguration, while this would not be possible with a new DNS message
format. There are at least a dozen operational solutions to that kind of
problem however, even when a protocol solution is not available.

Tough question. I don't know the answer. It just seems to be a bad idea to
preclude all options up front.

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 14 Feb 2001 17:05:25 +0800

Before this discussion goes further, please put your specific changes to
the requirements with the proposed new wordings here. Thanks!

-James Seng

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 14 Feb 2001 01:34:41 -0800

> the requirements with the proposed new wordings here. Thanks!

James, as I said, I believe the clause should be removed.

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Feb 2001 08:02:42 -0500

> user clicks on the internationalized mailto: link.

you've changed test cases on me :)

the MUAs I use don't support mailto: links at all, so I don't care about
them as much as I care about reply functionality working.

(I generally find mailto: links pretty useless, since they force
me to use the web browser's mail reader, and they don't let me pick
and choose the addresses to which I want to send a single message.)

> includes ACE. Breakage of some degree is absolutely unavoidable.

agreed.

> envelope. This may be required even when ACE is used though. What then?

it would be possible to design an ACE that encoded a single IDN label
as multiple DNS labels.  we need some idea as to whether a single-label 
ACE that uses compression is "good enough" and I haven't seen that yet.

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 14 Feb 2001 20:52:04 +0100

>user clicks on the internationalized mailto: link.

I think Keith said "reply to an email", and I think that is the level 
of backward functionality which is really essential.

I.e. one reason why I wrote the IDNA proposal was exactly this scenario:

User A have an IDN capable email client, and he uses an email address 
in a domainname which is an "IDN"-domain. He sends an email with this 
email address as From address.

The recipient B have a client and/or server (or even a system which 
is behind a gateway, like lotus notes, first class or X.400) which 
receives the message.

Now, B want to reply to the message.

I want that to work, regardless of how the From address look like on 
the screen.

Because of this, B having non-IDN software, IDNA is needed.

Also, B can still add the From-address to his address book in his 
email client (the domainname still looks weird as the ACE is not 
decoded).

Broken as the ACE is not decoded -- yes -- but it is possible for A 
and B to continue to exchange email.

    Patrik

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2001 16:34:08 +0100

>domain name." That requirement should be removed from the spec completely.

I believe the intent of the paragraph was to say "allow any system anywhere 
THAT IMPLEMENTS THE IDN SPECIFICATION to resolve any internationalized 
domain name".

The scenario it was aimed to prevent was one where multiple enclaves of 
"IDN" names existed, where one could not resolve those names without 
passing through the gateways for that particular enclave.

I propose the version above (without caps) as replacement text.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]