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

From: Johnny Eriksson <[email-masked]>
Date: Tue, 20 Mar 2001 23:00:02 WET

Mark Welter <[email-masked]> wrote:

>    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).

...and since speeding is illegal, we can do away with the highway patrol.

>     Mark Welter

--Johnny

---

From: Mark Welter <[email-masked]>
Date: Tue, 20 Mar 2001 17:46:44 -0500

> ...and since speeding is illegal, we can do away with the highway patrol.

This is a great analogy.  Marc Blanchet made the point that registrars don't control
(most) third or lower level names.  The question then is, do we want to have the
highway patrol handing out speeding tickets for how fast you are driving in your own
back yard?  The related question is whether there should be back-yard speed limit.
   I think that zone file administrators can police themselves. If they are
"bad actors" we have other, bigger problems.  There are trade-offs here
that we should balance with an open mind.  For what it's worth, I don't think that
Brian Spolarich agrees with me.  We should be able to come up with reasons for our
positions.
   Mark Welter

---

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

> ...and since speeding is illegal, we can do away with the highway

Is this an argument in favor of checking for prohibited names in client
applications?  Today's client applications don't check for prohibited
names (like a+b.com), and this hasn't led to any catastrophes.  Today
canonicalization and prohibition are both performed on the server side.
Nameprep proposes to perform both functions on the client side.  I'm
suggesting that a less drastic change (performing canonicalization
but not prohibition on the client side) may be sufficient, and even
preferrable.

AMC

---

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

| Is this an argument in favor of checking for prohibited names in client
| applications?  Today's client applications don't check for prohibited
| names (like a+b.com), and this hasn't led to any catastrophes.  Today
| canonicalization and prohibition are both performed on the server side.
| Nameprep proposes to perform both functions on the client side.  I'm
| suggesting that a less drastic change (performing canonicalization
| but not prohibition on the client side) may be sufficient, and even
| preferrable.

  As I recall BIND (which as I pointed out is an implementation of the
spec, not the spec itself), makes the checking for prohibited characters 
in labels optional, so this is not without precedent.

  -bws

---

From: "Edmon" <[email-masked]>
Date: Tue, 20 Mar 2001 18:34:21 -0500

> but not prohibition on the client side) may be sufficient, and even

I think it only makes sense to do prohibition in the server end because if a
user types in a "prohibited" name it would probably be non-existent, and
therefore will not resolve anyway.  Just like leading and ending "-" today,
they are "prohibited" but applications usually send it out.  Zone
operators/registries usually do not allow these records to be created.
Edmon