Subject: [idn] Needed changes to IDNA before last call

From: Dan Oscarsson <[email-masked]>
Date: Tue, 29 Jan 2002 16:21:56 +0100

As I have the feeling that the IDNA way be the internationalisation
of the DNS in the near future, at least, and we now also have
last call on the drafts for it, I have looked at what I think is needed
before they can replace a complete native UCS solutions.

A quick look at the latest drafts make me happy, they are much closer
to what is needed now than they were before. Previously they have been
too focused on "host names".

To be complete, all DNS labels containing non-ASCII must be ACE
encoded. All using the same encoding and stringprep profile.
This will allow us to use non-ASCII everywhere in DNS excpet in things
like for example TXT and HINFO records.

I suggest the following is done:

The draft: idn-nameprep
Title change: Stringprep profile for Internationalised DNS labels.
It is for more than host names. Unless my quick look is wrong
it should work for all types of labels.

The draft: idn-idna:
The ToASCII must be applied to ALL labels containing non-ASCII.
The steps need a slight change:
 - character restrictions will apply depending on label, it could be
   host name or e-mail name.
 - Encoding into ACE must use Punycode WITH case marking so that
   case can be restored when using ToUnicode.

ToUnicode is fine, but decoding Punycode must restore case.

-
With the above changes the IDNA way is much more acceptible.
It is now a general solution for non-ASCII in labels, not just
some special cases. And it preserves the case semantics of
current DNS while at the same time allows the simple ASCII
matching algorith to be used.

If you do this you get all important things I have wanted my
native UCS solution to do (except using native UCS) and I
can support it.

Keep up the good work, you are nearly there.

   Dan

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Jan 2002 07:49:17 -0800

>before they can replace a complete native UCS solutions.

8-bit Unicode is not a "native" encoding.

IDNA uses standard Unicode representations.

It is the ENCODING of that representation that differs from the standard 
encodings that are typical for Unicode, most of which are not "native".

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 30 Jan 2002 04:00:04 +0000

> Title change: Stringprep profile for Internationalised DNS labels.

I agree, except that I would recommend "Stringprep Profile for
Internationalized Domain Names", to be consistent with the title of the
IDNA draft.

> The ToASCII must be applied to ALL labels containing non-ASCII.

Rule 1 already says:

    Whenever a domain name is put into a generic domain name slot, every
    label MUST contain only ASCII characters.

"every label".

>    host name or e-mail name.

Step 3 of ToASCII already says "If the label is part of a host name (or
is subject to host name syntax rules) then perform these checks".

When you say "e-mail name" do you mean the local part (before the @)?
That's outside our jurisdiction.  Another working group will have to
decide how to internationalize email local parts.  We can only tell how
to deal with domain names.

You may be concerned about resource records that contain email addresses
represented as domain names (with the local part as the first label).
Currently there is no problem, because all email address local parts are
ASCII according to RFC 2822.

> ToUnicode is fine, but decoding Punycode must restore case.

I have already argued for mixed-case support as best I can.  I couldn't
quite get it *mentioned* in the IDNA and Nameprep documents.  You don't
have a prayer of getting it *required*.

Of course, the working group that internationalizes email local parts
would have the option of writing a spec that requires Punycode with
mixed-case support.

AMC

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 30 Jan 2002 07:54:00 +0100

> have a prayer of getting it *required*.

The problem is that the definition of "case" is very hard to make. And, if
you preserve case, why not preserve other steps of nameprep?

Preserving anything is the beginning of a very slippery slope which will
end in the need for a redesign of Punycode and Nameprep completely.

Remember, nameprep is done before punycode, so when the string is passed to
the punycode (transport) encoding, the original string is lost.

    paf