Subject: [idn] Using a new class for IDN

From: Dan Oscarsson <[email-masked]>
Date: Sun, 02 Jun 2002 10:58:31 +0200

John C Klensin published the idea to use a new class in DNS
for IDN. As I now feel that there is no way to stop IDNA, I have
looked on how to introduce native handling of non-ASCII in DNS
in a easy way. While it can be done by EDNS and a new label type,
I think a cleaner, and probably easier to implement, way is
to use a new class. Using a new class you get:
- a simple flag telling the DNS server that all text data (both
  labels and other) are in a well defined encoding of UCS.
- clients get a error response if server do not support new class.
  Telling the client to retry using old IN class.
- Basic support in DNS can be added by just defining all records
  in IN and new class. When in IN, use ACE encoded labels.
  When in new class, use UCS. A more efficient implementation can
  be added later.
- A clean break from the old DNS world.
- Compared to IDNA you get the same native encoding of
  characters everywhere (all labels get internationalised, and
  text fields like those in HINFO and TXT gets well defined) and
  case can be preserved in responses.

I could write a draft for this, if some of you would support it.

IDNA as it is today, does complicate the above way in at least two
ways:
- The count of characters that can fit into 63 octets differ
  when using ACE-names and native UCS-names.
  The above solution is very simple if we can require all
  names to fit in 63 octets. Then no new label types are needed
  and the DNS server use exactly the same records in both
  classes, only encoding in labels differ.
- IDNA does not define that the same ACE/string preparation should
  be used in all labels.

To make things easier for the future, IDNA should require that
the IDN in the ToUnicode form must not be longer than 63 octets.
That is, both the ACE-form and the UCS form must fit in
63 octets.

Do we plan for a future with a fully internationalised DNS now?
Or maybe we do not need one?

Regards,

   Dan

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 2 Jun 2002 21:34:19 +0000

Dan Oscarsson <[email-masked]> wrote:

> - The count of characters that can fit into 63 octets differ when
>   using ACE-names and native UCS-names.

True.  As an extreme example, consider a label consisting of many
repetitions of the same character outside plane 0.  UTF-8, UTF-16, and
UTF-32 all use 4 octets per character, while Punycode uses about 1.

As an extreme example the other way, consider a label consisting of
random characters from plane 0.  UTF-16 uses 2 octets per character,
while Punycode uses about 3.5.

> To make things easier for the future, IDNA should require that the IDN
> in the ToUnicode form must not be longer than 63 octets.

ToUnicode does not output octets, it outputs code points.  Which
encoding form did you have in mind, UTF-8, UTF-16, or UTF-32?

UTF-32 is always at least as large as UTF-16, sometimes larger, so I'll
assume you don't want that one.

If you go with UTF-16, then all existing ASCII labels over 31 characters
become retroactively invalid, which seems very bad.

If you go with UTF-8, then Indian scripts can fit only 21 characters per
label, versus about 40 for ACE.  It's seems a shame to halve the limit
for a billion users.  I'd really rather not.

AMC

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 3 Jun 2002 07:40:04 -0400

Hi Dan,
As an advocate for a clean approach to IDN I would like to offer my support.
Though I think EDNS is a better solution because IDN is really just another
domain name and should exist in both classes, I dont mind seeing a new class
being created for IDNs because I believe that the world wants a good forward
looking architecture for IDN and will move towards the new class as it
becomes available.
Edmon

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jun 2002 10:58:44 -0400

--On Monday, 03 June, 2002 07:40 -0400 Edmon Chung
<[email-masked]> wrote:

> Hi Dan,
> As an advocate for a clean approach to IDN I would like to
> offer my support. Though I think EDNS is a better solution
> because IDN is really just another domain name and should
> exist in both classes, I dont mind seeing a new class being
> created for IDNs because I believe that the world wants a good
> forward looking architecture for IDN and will move towards the
> new class as it becomes available.

Edmon,

A few observations:  The advantage of both EDNS and a new Class
approach is that they require explicit action on the part of the
part of the client to get "idn" treatment of a name.  Without
that action, and agreement from the server in some appropriate
form, nothing is going to happen, which means no heuristics
about how names are to be interpreted, no nonsense strings
showing up in front of users (at least with decent-quality
implementations), etc.  The disadvantage is what it always has
been and what caused the WG (I think) to ignore these solutions
from the beginning -- they are infrastructure changes, not quick
fixes, and the WG has been focused on quick fixes.

Between the two, I see a fairly similar tradeoff.  EDNS is
easier to think about in terms of incremental deployment, but
raises complex issues about, e.g., handling of secondaries.
"New class" gives us the opportunity --but also the
probably-very-painful obligation-- to rethink almost everything
and get it right this time.

But let me repeat, and expand slightly, the advice I previously
gave Dan in an off-list note.  My "new class" I-D was nothing
more than a sketch of how it might be done and what some of the
issues would be about doing it.  It does contain at least some
of the justification, which ought to be useful, but it is
(deliberately) notably short on fine details.  David Lawrence
has raised issues I didn't explicitly address as has, more
recently, Eric Hall.  What is going to be needed if anyone is to
take "new class" seriously as a proposal (and not as yet-another
attempted blocking action (of which I am not accusing anyone in
particular, only noting that there have been far too many
suspicions along those lines in the WG)) is a coherent internet
draft that really does the case analysis and considers, and
offers at least tentative solutions for, the many issues,
questions, and loose ends.

And, while I'll promise to read such a draft, I'm not going to
be much help.  IDNA and the various (incomplete) EDNS and new
Class proposals ultimately differ in how they represent data,
how the query stream is handled, and a number of other details.
While --being very conservative about risks to the DNS and the
Internet-- I still prefer the new Class one, I see far more of
the important problems lying in the areas of acceptable
character repertoires and matching rules for those characters
that are permitted, and I've concluded that _those_ issues and
people's expectations about them can't be dealt with in the DNS
at all.

So, if this really interests you, and Dan, and David, and anyone
else who has read this far, _please_ go form yourselves into a
design team and produce a comprehensive draft.  Get it posted.
And then have a discussion with Erik and Thomas as to whether to
try to get it reviewed in this WG or in DNSEXT, as well as about
its impact on the IDN/ IDNA proposals.  But, while I wouldn't
presume to speak for the ADs or the IDN WG, I can't imagine
anyone taking "new Class" (or anything else) seriously as an
alternative to the IDNA proposal at this late date unless there
is a clear and complete I-D on the table.  So, again, please
start writing I-D text, rather than notes to the WG mailing list.

And good luck.

     john

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 03 Jun 2002 12:00:50 -0500

John C Klensin wrote:

> suspicions along those lines in the WG))

Unfortunately, your role gives these kinds of statements a lot more weight
than you probably intend them to have.

In response, I will say that the only blocking actions I have seen has

> fixes, and the WG has been focused on quick fixes.

Anybody who understands IDNA knows that it is anything but a quick fix.

Oh sure, it lets registrars *sell* domains quickly, but its success with
the user community hinges on every application in the world being upgraded
to perform conversion. Furthermore, it is known that this will be a
disruptive process which will absolutely cause interoperability failures.
There is nothing fast or resolute about this. The only thing going for it
is that it is backwards compatible. While that is a necessary attribute of
any solution, it is not by itself a "quick fix" for anybody other than
domain resellers.

Most of the alternative proposals seemed to have recognized that. None of
them have been attempts at derailing anything, AFAICT.

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jun 2002 14:56:03 -0400

--On Monday, 03 June, 2002 12:00 -0500 "Eric A. Hall"
<[email-masked]> wrote:

>> attempted blocking action (of which I am not accusing anyone
>> in particular, only noting that there have been far too many
> Unfortunately, your role gives these kinds of statements a lot
> more weight than you probably intend them to have.

Eric, _I_ have been accused, loudly and repeatedly, of
intentionally attempting to block action.  That isn't true, and
I'm certainly not trying to give it weight.

> In response, I will say that the only blocking actions I have
> seen has been to shutdown critical analysis of IDNA. To wit:
> 
>> from the beginning -- they are infrastructure changes, not
>> quick fixes, and the WG has been focused on quick fixes.
> 

I completely agree.  But I believe it is also correct to say
that the WG has tended, over its lifetime, to focus its
attention on things that appear to be quick fixes, in preference
to options that would take longer but that might be more
satisfactory.

> Oh sure, it lets registrars *sell* domains quickly, but its
> success with the user community hinges on every application in
> the world being upgraded to perform conversion. Furthermore,
> it is known that this will be a disruptive process which will
> absolutely cause interoperability failures. There is nothing
> fast or resolute about this. The only thing going for it is
> that it is backwards compatible. While that is a necessary
> attribute of any solution, it is not by itself a "quick fix"
> for anybody other than domain resellers.

Again, I agree.  But domain resellers, others who believe that
having "multilingual names" --somehow-- quickly are important,
and the fear that, if the WG doesn't do something... Right
Now... various sorts of interoperability catastrophies would
occur, have been the sources of huge pressures on the WG to try
to do _something_ that can be deployed quickly.   And "deployed"
has been defined in that context by ability to put names in
tables and get them back out.

One can believe that pattern was either good or bad, but I think
it is indisputable that the WG has been operating under pressure
--quite large by IETF averages-- to produce some solution
quickly.  Now, the fact that the WG has rejected the really
lousy solutions proposed as "quick fixes" is to its credit.
Similarly, it has avoided falling into the quick-fix traps that
would have permitted efficient use of some (typically
Latin-based) scripts other than English while pushing
non-Latin-based and non-alphabetic scripts even further back,
which is again to its credit.  And it has struck some sort of
balance between "quick" and careful consideration of
alternatives and implications which has certainly not been as
quick as some would like nor as careful as others would like --
if you subscribe to the principle that a successful consensus
position is one with which everyone is equally unhappy, IDNA may
be an excellent example.

> Most of the alternative proposals seemed to have recognized
> that. None of them have been attempts at derailing anything,
> AFAICT.

I don't think this is worth a long discussion at this stage, but
the accusations have been made and repeated, especially in the
direction of those of us who are concerned that IDNA (and
DNS-based solutions generally) will not satisfy the requirement
as seen by users, in the direction of some of those who have
focused strongly on issues with a small family of scripts or
languages, and in the direction of those who have proposed ideas
but not protocols (in the form of I-Ds that were detailed enough
to be analysed and seriously considered).

     john

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 3 Jun 2002 15:48:18 -0400

----- Original Message -----
From: "John C Klensin" <[email-masked]>
> tables and get them back out.

I think it is more important for registrars as well as the more critical
registrant to have multilingual domain names that are usable by the general
audience quickly.  That is the key I see the market demanding.  Whether we
use IDNA or EDNS or new class the transition is going to be as slow because
the major problem is getting the new client propagated.  The only real to
addresss market demands is a good "Transitional Strategy".  One which has to
include a brute-force approach whereby the name server resolving a request
containing a non-ascii domain request.

While I find it kind of ironic, though not surprising that the so heralded
"quick fix" method is not so "quick" afterall, perhaps our effort should now
(that the IDNA thing is more or less ready) move towards a solution that is
truly more "satisfactory" as you have mentioned.

By the way, just to make it clear, this is not intended to block or stall
the current IDNA effort, but pointing out the plain fact about a real world
demand and a real world transition path that has to take place for
multilingual domain names to become usable.

Edmon

---

From: "Kenny Huang" <[email-masked]>
Date: Tue, 4 Jun 2002 09:48:03 +0800

> truly more "satisfactory" as you have mentioned.

You try to identify the potential issue from a broader aspect. Which is out
of the wg concern.

> the current IDNA effort, but pointing out the plain fact about a 

Fact (or potential fact) may not be the key issue. You already mentioned
who can be benefited from the quick fix. It's not difficult to extend the logic.

Kenny

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 4 Jun 2002 12:19:28 +0900

----- Original Message ----- 
> tables and get them back out.

I have never seen any of such written threat or pressure appear in this WG.
maybe, behind the curtain: "Publish the RFC, Right now! 
if not, we will balkanize the DNS!".
For what reason should we be so generous to this kind of pressure?
I can't believe any registries make such threats. Most of them promise
they will switch to/adhrere to IETF-approve IDN standards in their homepages.

In the same time, from the opposite group of consumers and countries,
there has been public and written *strong pressure* on this WG to produce 
more mature and stable and interoperrable and long-term-safe solutions.
For what reason should we be so harsh on this appeal ?

> quickly.   

Do you say that  above standardization pattern was bad ?

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 4 Jun 2002 09:40:44 -0400

Hi Kenny,

> the current IDNA effort, but pointing out the plain fact about a

I am not sure what do you mean by:

"Fact (or potential fact) may not be the key issue. You already mentioned
who can be benefited from the quick fix. It's not difficult to extend the
logic."

I was pointing out that the real world needs a transition path not only an
end protocol.  Whether we like it or not, it is going to take a long time
for the new protocol, whatever it may be, to be adopted by the millions of
users on the internet today.  Therefore, in a registry's perspective, a
transition strategy that takes into consideration the usage of multilingual
domain names by applications and users who might not be aware of new
protocol requirements is most important to the successful roll out of IDNs.

Edmon