Subject: [idn] Who supports UDNS (ACE+UTF-8)

From: Dan <[email-masked]>
Date: Fri, 29 Jun 2001 09:57:38 +0200 (MEST)

As James & Marc want to know what documents are supported I
would like to know who supports my (or something based on) UDNS draft?

Please send your answer directely to me to avoid filling the mailing list.

In summary the UDNS draft gives you:
- full internationalisation in all parts of the DNS protocol
   (that is including TXT text fields and other places with
    character data).
- uses ACE for backward compatibility including supporting
  IDNA clients.
- uses UTF-8 as the standard format
- uses EDNS to allow longer labels than 63 bytes.

It is a solution supporting both ACE and UTF-8 from the start.
If would allow IDNA supporters to use IDNA and UTF-8 supporters
use UTF-8.

   Dan

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 29 Jun 2001 11:52:40 -0400

Dan,

I'm sorry I didn't comment on your draft earlier.

>    (that is including TXT text fields and other places with

I'm only interested in the name resource record -- the label space,
and PTR record return.

Fixing other bits is unnecessary, and where possible, one problem
at a time. Can you reduce the problem to its simplest form? As you
note "At a later date, IETF may change this."

> - uses ACE for backward compatibility including supporting

I'm not disinterested in compatibility with 37 (or 63) valued encodings,
however, in its simplest form, a utf8-over-the-wire proposal need not
make reference to any ACE. Can you reduce the problem to a simpler form?

> - uses UTF-8 as the standard format

Good.

> - uses EDNS to allow longer labels than 63 bytes.

Extending the number of octets used to form labels is both very hard,
and unnecessary to extend the set of valie values available to form
labels. [I appreciate that the limit hurts, but length is disctinct
from values allowed, and where possible, one problem at a time.]

Recommended additions:

  - uses EDNS to add a new class.

> If would allow IDNA supporters to use IDNA and UTF-8 supporters

A good goal, but the minima is operational success of one.

A nominal placeholder for one merged, or several revised, or even a new utf8
draft, is useful. Thanks for asking for private comment, but getting all or
some of the utf8 drafts responsive to the W vs T revised draft management
plan isn't best done in private, unless you (or who ever is collecting, and
one of the co-chairs could be doing this) ack your responses publically
(except where private is indicated), and periodically summarize any changes
planned in a pre-7/14 revised draft.

Thanks for reading this far.

Eric

---

From: "Edmon" <[email-masked]>
Date: Fri, 29 Jun 2001 18:20:13 -0400

First of all, I do support a UDNS type proposal.  And, I am working on an
I-D that enhances UDNS too.
Anyway...

> make reference to any ACE. Can you reduce the problem to a simpler form?

It is not a complete solution if ACE is not referenced.  What happens when
an application obtains DNS information (such as an A record) from the DNS in
UTF8 (probably via EDNS) and then try to contact a destination server (such
as http) that is non-IDN aware with the domain name?  In this case, the
application must know what or how to use an appropriate ACE name to contact
the http server.

> from values allowed, and where possible, one problem at a time.]

Perhaps if we use UCS directly then the "count" can actually be the number
of Unicode code points and every language will have 63 "character" spaces to
use.

Edmon

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 29 Jun 2001 19:00:53 -0400

...
> And, I am working on an I-D that enhances UDNS too.

Please accept my suggestion that the arch-1 or arch-2 (binary: skwan
and doscarsson, respectively, etc.) frameworks are not improved by
following the ACE camp into a thicket of nominally different proposals.

> It is not a complete solution if ACE is not referenced.  What happens when

Interoperation is not a requirement for solutions in the space defined by
arch-1 or arch-3. Additionally, within the space defined by both arch-1
and arch-3, uniqueness of mechanism is not guaranteed, and if interoperation
is ment as a goal, it is underdefined at present, for all three frameworks.

This is one of the "wildly-ignored" issues.

> of Unicode code points and every language will have 63 "character" spaces to

Please also accept my suggestion that label length is not the primary
difficulty, and that the problem of length modification isn't improved
by using UCS code points as a metric.

Eric

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Jun 2001 19:39:48 -0400

--On Friday, 29 June, 2001 18:20 -0400 Edmon <[email-masked]>
wrote:

>...
> Perhaps if we use UCS directly then the "count" can actually
> be the number of Unicode code points and every language will
> have 63 "character" spaces to use.

Edmon,

I have having trouble understanding what you are proposing here.
The limit of 63 octets is a fundamental DNS limitation, at least
within Class=IN (I can imagine having rules that would extend it
in other Classes, just as I can imagine EDNS rules that would
extend it).  Consequently, "use of UCS[-4?] directly" presumably
means that every language gets 15 character names (and you still
need code tagging, but maybe we can make the three spare octets
sufficient for that).

Or are you planning a "flag day" replacement for the DNS?

What am I missing?

   john

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 29 Jun 2001 23:38:29 -0500

> Perhaps if we use UCS directly then the "count" can actually be the
> number of Unicode code points and every language will have 63
> "character" spaces to use.

Allowing for 63 characters (instead of 63 octets) per label by way of EDNS
would certainly help to motivate adoption.

I think that it is probably also feasible to adopt a "continuation" syntax
in ACE as part of a backwards compatibility. Perhaps a special byte
sequence (like soft-hyphen) could be reserved for this purpose, allowing a
pair of ACE labels to be interpreted as a single label.

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

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 30 Jun 2001 06:34:58 +0000

"Eric A. Hall" <[email-masked]> wrote:

> I think that it is probably also feasible to adopt a "continuation"
> syntax in ACE as part of a backwards compatibility.

This has been proposed before.  It's certainly a clever idea, but
it's not clear that it wouldn't create more compatibility problems.
Applications sometimes pay attention to the number of components in a
domain name (the web cookie protocol is one example), and sometimes
chop them up.  If the name appeared to have a different number of
components when viewed by an IDN-aware application versus an IDN-unaware
application, there could be subtle interoperability problems.

Consider an IDN FOOBAR.org whose ACE is ace1.ace2.org.  An application
might be faced with the question of whether FOOBAR.org is a subdomain of
ace2.org.  Is there a right answer?

The nicest thing about the ACE approach is that it obviously breaks no
software or protocols.  That would no longer be obvious if continuations
are possible.  My get feeling is that it would be more trouble than
it's worth, but if you want to pursue this, please try to work out some
semantics that are consistent and demonstrably safe.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 30 Jun 2001 10:17:05 -0500

> it's not clear that it wouldn't create more compatibility problems.

Yeah, very difficult. This has been what's been keeping my own dual-mode
draft from being finished. You raised some good points, but the one that
has me bugged is the max length; providing continuation labels just moves
the problem to the max length restriction, rather than really fixing it.

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 30 Jun 2001 18:50:03 -0400

>semantics that are consistent and demonstrably safe.

I concur with Adam. Continuation of idn over multiple labels looks clever 
but makes a more fondamental shift in the dns where labels are no more 
separated by a dot.  To me, it looks really dangerous.

Either we stick on ace with restricted-length encoded idn (i.e. keep the 
limit of 63 octets), or we use edns or a new class to signal this new 
"feature". (Even with that, on the application side, still looks crazy to me).

Marc.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 30 Jun 2001 19:32:57 -0400

As I suggested, length isn't the reason we're here, and extending it
won't make everyone sigh with relief and go back to better, or less
contentous, tasks. Therefore, it isn't a design point.

Besides, anyone have any guesses as to how hard it would actually be,
ignoring the (useful, later) suggestion of abstracting display width
from byte count?

Let's all, arch-1 and arch-3, and any surviving arch-2, put label length
aside until more important problems are solved.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 1 Jul 2001 09:09:04 +0800

> would certainly help to motivate adoption.

There is no reason why there is a 63 octet limit in Domain Names, other
than by designed, someone decided that 63 octet is sufficient and able
to fix into the UDP packet.

Thus, *if* we have the opportunity to 'fix' this, why do we need to
change to 63 Unicode character limit too? Why not more just in case?

Secondly, "chair" in English which take up 5 Unicode character would
only take two Unicode ideographic character in Chinese. Thus, is 63
Unicode character 'fair' for all? This is a topic I hate to dive into
here.

> I think that it is probably also feasible to adopt a "continuation"
syntax
> pair of ACE labels to be interpreted as a single label.

This is a proposal that pops up from time to time.

-James Seng

---

From: [email-masked] (deng)
Date: Sun, 1 Jul 2001 11:05:27 +0800

> -James Seng wrote:
 
> Unicode character 'fair' for all? This is a topic I hate to dive into

The length limitation is a problem which is belong to technological 
discussiale category.

Chinese character is ideographic character, it means that each character 
has meaning. so if we want to translate a Chinese character into English, 
in many cases,we should use several English words(not just several letters). 
Reverse, if we want to translate a English word into Chinese, it's same.

In DNS, there is no meaning, just codepoint which user choose, and user 
want to express some meaning. From this point,there is no different among 
Unicode.

Deng xiang