Subject: Re: [idn] Reality Check

From: Dan Oscarsson <[email-masked]>
Date: Fri, 13 Jul 2001 10:47:52 +0200 (MEST)

Adam M. Costello wrote:

>> What does the normal human beings of the real world expect from DNS?
>> The semantics of current DNS says:
>> - a name can have mixed upper and lower case letters
>> - names will be matched case insensitively
>> IDNA says:
>> - a name can only be in lower case
>> - names will be matched exactly
>> So IDNA breaks current semantics of DNS.
>
>No, IDNA does not say that.  Application protocols can transmit
>names in non-nameprep'd mixed-case form.  Applications can store
>and display names in non-nameprep'd mixed-case form.  The only
>time it is necessary to apply nameprep is just before comparing
>two names.  Nameprep is mainly just a way to do case-insensitive
>alternate-represenation-insensitive comparisons.
>

IDNA indirectely says the above!
IDNA says that over the DNS protocol namepreped ACE must be used.
Because of this, DNS can only return names in lower case.
So, while you can enter mixed case, the moment a name is sent or
received over the DNS protocol it is converted into lower case and
the mixed case information is lost.

   Dan

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Fri, 13 Jul 2001 10:55:12 -0400

| IDNA indirectely says the above!
| IDNA says that over the DNS protocol namepreped ACE must be used.
| Because of this, DNS can only return names in lower case.
| So, while you can enter mixed case, the moment a name is sent or
| received over the DNS protocol it is converted into lower case and
| the mixed case information is lost.

  This does not have to be the case.  An ACE encoder which takes case
information passed by nameprep can store case information for the decoded
name by setting case in the ACE sequence.  The decoder can then use these
hints when converting for display.

  This would require nameprep to capture case before squashing and passing
to an ACE which supports it.  Any of the ACEs which do not break codepoints
during their encoding steps could support this.  DUDE-02 does, as do all of
AMC's alternatives (I think).

  If the WG feels that case preservation in decoding is important, then 1)
it is not inconsistent with IDNA's architecture and 2) the ACE and NamePrep
can be modified to support it without adding too much complexity (beyond the
inherent complexities of case in general).

  -bws

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 13 Jul 2001 19:59:14 +0000

> Because of this, DNS can only return names in lower case.

IDNA says that it is possible to use today's DNS, with no changes, for
IDNs, and the way to do that is via nameprep'd ACE.  IDNA does not
forbid DNS extensions.

As Brian has already pointed out, nameprep'd ACE can easily retain
mixed-case information.  So it's still not necessary to change DNS.

If you don't like that solution, you could instead add some new resource
records, like ICNAME and IPTR, which would be just like CNAME and
PTR except that they would contain non-nameprep'd UTF-8 instead of
nameprep'd ACE.  DNS servers could return them along with the legacy
records.  One problem would be that for some names, the ACE will fit in
63 bytes but the UTF-8 will not.

Alternatively, you could alter the DNS protocol itself so that the
request can contain a flag inviting the server to put non-nameprep'd
UTF-8 directly into CNAME and PTR responses.  The length problem would
still exist unless the DNS protocol extension also increased the length
limit.

I recommend the first solution (mixed-case ACE), because it doesn't
have the length problem and appears to be the simplest (given that ACE
already needs to be supported).

> received over the DNS protocol it is converted into lower case and the
> mixed case information is lost.

Even if that were true (which it's not in light of mixed-case ACE),
keep in mind that names received from DNS are very rarely displayed to
users (except sysadmins).  CNAME records are usually just looked up
again for their address, and PTR records are usually used internally for
permissions checks, or written to log files or similarly unseen places
(like Received: headers).

AMC

---

From: Rick H Wesson <[email-masked]>
Date: Fri, 13 Jul 2001 15:30:59 -0700 (PDT)

Brian,

I do feel that it is important not to preserve case, furthermore I believe
that it is a major drawback of the DUDE draft that it could support
case preservation.

-rick

---

From: "D. J. Bernstein" <[email-masked]>
Date: 13 Jul 2001 23:11:45 -0000

Brian W. Spolarich writes:
> store case information for the decoded name by setting case in the ACE

If lowercase x is ACE-encoded as 75, how is uppercase X encoded?

Are you suggesting that the WG stop considering any encodings for which
there isn't at least one letter in the output per letter in the input?

Please, folks, think through the details of your proposals.

---Dan

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 14 Jul 2001 00:30:26 +0000

"D. J. Bernstein" <[email-masked]> wrote:

> Are you suggesting that the WG stop considering any encodings for
> which there isn't at least one letter in the output per letter in the
> input?

A few hours ago the working group stopped considering any encodings
without seven supporters, which I think leaves only DUDE, AMC-ACE-Z,
and maybe MACE (I hope we'll hear an announcement soon).  In each of
these encodings, every input letter is represented by a sequence of
output characters, the last of which is always a letter.  The last
proposal being considered by the ACE design team that didn't have this
property was LACE, which lost support on Jun-05 in favor of DUDE (which
is simpler than LACE, a little less efficient for Han and Hangul, and a
little more efficient for everything else).

It has been discovered that ACEs that use an integral number of output
characters per input character are simpler and need not be less
efficient, and once you're in that regime, it's easy to arrange for the
last character to always be a letter.

AMC

---

From: Martin Duerst <[email-masked]>
Date: Sat, 14 Jul 2001 11:31:37 +0900

>that it is a major drawback of the DUDE draft that it could support

Rick - can you give us a clue why?     Martin.