Re: 2606bis (was: .local)

John C Klensin <john-ietf@jck.com> Wed, 19 October 2005 10:08 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESArZ-00071v-F8; Wed, 19 Oct 2005 06:08:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESArW-00071k-I4 for ietf@megatron.ietf.org; Wed, 19 Oct 2005 06:07:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04068 for <ietf@ietf.org>; Wed, 19 Oct 2005 06:07:49 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESB3E-0005y1-Pw for ietf@ietf.org; Wed, 19 Oct 2005 06:20:05 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ESArP-000Oi3-7i; Wed, 19 Oct 2005 06:07:51 -0400
Date: Wed, 19 Oct 2005 06:07:50 -0400
From: John C Klensin <john-ietf@jck.com>
To: Frank Ellermann <nobody@xyzzy.claranet.de>
Message-ID: <C56AABD8019A5267529A992C@scan.jck.com>
In-Reply-To: <4355E8A4.7634@xyzzy.claranet.de>
References: <Pine.LNX.4.61.0509191647510.23762@internaut.com> <p0620074fbf5509dd070a@[192.168.2.2]> <Pine.LNX.4.61.0509192043550.28535@internaut.com> <4333DDFF.8020909@zurich.ibm.com> <4333F545.7619@xyzzy.claranet.de> <4355E8A4.7634@xyzzy.claranet.de>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: 2606bis (was: .local)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Frank, I'm going to comment on two of your remarks.  My not
commenting on the others does not imply that I agree with you
about them either.

--On Wednesday, 19 October, 2005 08:33 +0200 Frank Ellermann
<nobody@xyzzy.claranet.de> wrote:

>...
> This draft references the informational RfC 1591 as normative.
> So far I thought that 1591 in essence says that the internal
> business of a TLD is, well, its internal business.

First of all, there are a collection of RFCs that were issued by
the IANA that are, indeed, normative.  They aren't IETF
Standards because they weren't produced or ratified by the IETF.
It wasn't considered appropriate to ask the IETF to ratify them.
And they aren't BCPs or the equivalent, first because they
weren't IETF documents and second because there was no such
thing at the time.  RFC 1591 is one of those documents.  If you
want to think about it that way, what makes it normative is that
the operator of every TLD allocated in the pre-ICANN period
agreed to its provisions, including both the "trustee rule" (see
below) and the obligation to insist that any subdomains it
registered accept the same rules.

The "internal business" of a TLD is subject to an obligation to
act as a trustee for the global Internet community and to act in
the best interests of that community.  In that context,
agreements about naming conventions and protocols that are
reached through a plausible consensus process really are binding
on all TLDs and, indeed, on all domains.  Whether the relevant
authority is willing or able to enforce those norms and
agreements is a separate issue: at worst, the norms and
agreements constitute a guideline about good practices.

>...
> 3.2 prohibits single characters as SLD.  What's the technical
> purpose of this prohibition ?  It also prohibits two characters
> as SLD unless the government of the corresponding ccTLD, or if
> that doesn't exist the ISO 3166 MA allow it.
>...

The technical purpose for this long-standing restriction is the
avoidance (or minimization) of false positives.  If one has
several characters in a string, the odds are (or were) presumed
to be reasonable that a typing mistake (or something equivalent)
would yield a "no domain" answer.  If only one character in a
domain name label is permitted, the assumption was that all such
labels would swiftly be taken and the likelihood would be very
high that a single-character typing error would yield a false
positive. That was considered a problem to be avoided a dozen
years ago.  It seems to be that in today's more rapacious
Internet, where "traffic concentration" (i.e., registering
domain names with the express purpose of capturing false
positives for a profit) represents the most profitable activity
in the "names market", it is even more important.

      john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf