Subject: Re: [idn] IDN character repertoire, nameprep

From: Johnny Eriksson <[email-masked]>
Date: Tue, 20 Mar 2001 20:53:44 WET

"Adam M. Costello" <[email-masked]> wrote:

> It has occurred to me that nameprep is currently moving two distinct
> tasks from the DNS servers to the applications, when perhaps only one of
> those tasks should move.  The two tasks are:
> 
>  1) Finding equivalences, for example, ABC.com == abc.com.
>  2) Prohibiting some names, like a+b.com.
> 
> Currently, most applications do neither.  For example, ping is happy
> to send all three of those names, exactly as shown, to the DNS server.
> The DNS server performs canonicalization on each lookup, and performs
> prohibition when it loads the zone file.
> 
> Both tasks become more expensive for IDNs.  Since canonicalization must
> be done on each query, it makes sense to move it to the application.
> But since prohibition is done rarely, I think it should remain the
> job of the DNS server.  That way, if more characters are added to the
> allowed set, it is not necessary to upgrade applications, but only to
> upgrade the DNS servers, and it's only the servers for domains that
> wish to register names containing the new characters that need to be
> upgraded.

In order to prohibit characters, the DNS server has to undo the ACE
encoding.  You have just started to modify DNS, something that many
people try desperatly to avoid.

> AMC

--Johnny

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 20 Mar 2001 20:13:52 +0000

> people try desperatly to avoid.

Good point, let me slightly amend the model.  Whatever program
translates the domain names into ACE in the first place should perform
the prohibition at that time.  This function could be performed by an
enhanced DNS server that loads zone files containing natively-encoded
domain names, or by a separate program that creates zone files
containing ACEs.

AMC

---

From: "Edmon" <[email-masked]>
Date: Tue, 20 Mar 2001 15:50:25 -0500

> domain names, or by a separate program that creates zone files

I think this is probably the best way to do prohibition.  In other words, it
is done during domain registration at the registry/DNS server whether it is
local or at the TLD and not at all dns applications.  This way, new
characters could be more easily introduced.  Which brings us to Bill
Manning's comment yesterday at the working group session which reminds us
that music is one other language!... luckily, musical symbols are included
in unicode, so we will be able to use it for domian names soon!...

Edmon

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Tue, 20 Mar 2001 15:06:26 -0600

| In order to prohibit characters, the DNS server has to undo the ACE
| encoding.  You have just started to modify DNS, something that many
| people try desperatly to avoid.

  BIND != STD13

  -bws

---

From: Mark Welter <[email-masked]>
Date: Tue, 20 Mar 2001 16:27:57 -0500

> people try desperatly to avoid.

   I brought up the very point that Adam has been trying to make at the
49th meeting.  There is no need to decode an ACE to prohibit characters,
or in fact arbitrary strings.  You have to keep clearly in mind that the
"registration" process controls what can resolve.  If you don't pour junk into
your zone files, then junk won't resolve.  This is where the prohibition
belongs, in my opinion (and that's where WALID has been putting it).
   The world (wide web) being what it is, you can count on a dns server
getting lots of truly bizarre requests that it can politely reject.
   I'm behind, and haven't read Nameprep version 3, but version 2 made
the distinction between registration and resolution contexts.
    Mark Welter

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Tue, 20 Mar 2001 15:08:07 -0600

| luckily, musical symbols are included
| in unicode, so we will be able to use it for domian names soon!...

  Oh great.  Even more copyright concerns.  Lets see the UDRP try to
deal with THAT. :-p

  -bws

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 20 Mar 2001 16:45:23 -0500

At/À 16:27 2001-03-20 -0500, Mark Welter you wrote/vous écriviez:

>"registration" process controls what can resolve.

sorry, the "registration" process only controls 2nd level labels. It 
doesn't control 3nd, 4th, levels of labels.

Marc.

>  If you don't pour junk into

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 20 Mar 2001 22:42:59 +0000

Mark Welter wrote:

> There is no need to decode an ACE to prohibit characters, or in
> fact arbitrary strings.  You have to keep clearly in mind that the

> doesn't control 3nd, 4th, levels of labels.

True.  I don't know about Mark, but I'm not proposing to do the
prohibition only at registration time (though it should probably be done
there too).

Before an IDN can be put into a DNS response, it must have been
transformed into ACE.  This transformation might happen inside an
IDN-aware name server when it loads the zone file, or might happen
earlier when a separate preprocessor generates a zone file that already
contains ACEs (for use by an IDN-unaware name server).  I'm proposing
that whatever server-side software performs the transformation into ACE
should, at the same time, check for prohibited names.

Perhaps Mark's "registration" in quotes was intended to be a shorthand
for this transformation step.

If names are prohibited on the server side, then they need not (and
should not) be prohibited on the client side.

AMC