Re: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)

Vint Cerf <vint@google.com> Mon, 07 July 2008 15:45 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375D928C1A9; Mon, 7 Jul 2008 08:45:57 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C613A6834 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 12:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5eHcvom5juW for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 12:34:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 6E6573A67F1 for <ietf@ietf.org>; Fri, 4 Jul 2008 12:34:09 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id m64JY6MD025879; Fri, 4 Jul 2008 20:34:06 +0100
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1215200048; bh=T27ulOnehWlZN0Xp4ctmAENGIHY=; h=DomainKey-Signature:In-Reply-To:References:Mime-Version: Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject: Date:To:X-Mailer; b=wgjEdXGzuKQZCxJSrIZ3kt4c++5IjaHVaLQ3FTrRqXE1eY op3fDB8ya/hy/ekjZbdp6ePxKqS72+FGIReEZE2w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:in-reply-to:references:mime-version:content-type: message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=do/5Twp3FBJ5eIAZEVCKBBaHJ/om6ugDKFwwdae6L0IVmrErG0lp7VxtdsubBNSC1 +CQkTQLeHW9jLy+yQ6wjQ==
Received: from smtp.corp.google.com (spacemonkey3.corp.google.com [192.168.120.116]) by wpaz21.hot.corp.google.com with ESMTP id m64JY3Fg030927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Jul 2008 12:34:05 -0700
Received: from [10.0.1.6] (ip68-98-162-154.dc.dc.cox.net [68.98.162.154]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m64JXxWf010378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Jul 2008 12:33:59 -0700
In-Reply-To: <392E87F9BBF8DC79E2167BA0@p3.JCK.COM>
References: <20080701223655.14768.qmail@simone.iecc.com> <C7F7E8A9-C844-4E1C-827D-189D4937BA6B@acm.org> <14AE948B18197467AE4D96A4@p3.JCK.COM> <558a39a60807021729m1fc299c2ted96064ce73228a7@mail.gmail.com> <D400669B-EA1C-4494-8094-20DC762F0EB5@acm.org> <558a39a60807031514ra9323c2n9395306e7865fef1@mail.gmail.com> <FA303A8B-80BC-4F75-B42E-47A6A28547A7@google.com> <392E87F9BBF8DC79E2167BA0@p3.JCK.COM>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <C743C857-9DB3-4497-A9E3-8134E30D449B@google.com>
From: Vint Cerf <vint@google.com>
Subject: Re: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
Date: Fri, 4 Jul 2008 15:33:18 -0400
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.753.1)
X-Mailman-Approved-At: Mon, 07 Jul 2008 08:45:52 -0700
Cc: James Seng <james@seng.sg>, idna-update@alvestrand.no, ietf@ietf.org, Lyman Chapin <lyman@acm.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

john,

my reaction was specific to IDN single character TLDs. In some  
languages these are complete words.

vint


On Jul 4, 2008, at 1:50 PM, John C Klensin wrote:

> Vint,
>
> In the ASCII space, there have been three explanations offered
> historically for the one-character prohibition on top and
> second-level domains.   I've written variations on this note
> several times, so will just try to summarize here.  Of the
> three, the first of these is at best of only historical interest
> and may be apocryphal and the second is almost certainly no
> longer relevant.  The third remains significant.
>
> (1) Jon has been quoted as suggesting that we could have
> eliminated many of the problems we now face with TLDs and
> simultaneously made the "no real semantics in TLD names" rule
> much more clear had we initially allocated "b".."y" as TLDs.
> Then, when someone asked for an assignment, it would have been
> allocated at random to one of those domains.  While this has a
> certain amount of appeal, at least in retrospect, there is
> probably no way to get from where we are today to that model...
> unless actions taken in the near future so ruin the current DNS
> tree as a locus for stable and predictable references that we
> need to start over with a new tree.  I don't think that a "have
> to start over" scenario is at all likely, but I no long believe
> it to be impossible.
>
> (2) There was an idea floating around for a while that, if some
> of the popular TLDs "filled up", one could create single-letter
> subdomains and push subsequent registrations down the tree a
> bit.  For example, if .COM were declared "full", then "a.com",
> "b.com", etc., would be allocated and additional reservations
> pushed into subdomains of those intermediate domains rather than
> being registered at the second level.  Until and unless the
> conventional wisdom that adding more names to .COM merely
> requires more hardware  and/or bandwidth, that won't be a
> "filled up" point at which this sort of strategy could be
> triggered.  Worse, trying to use single-letter subdomains as an
> expansion mechanism would raise political issues about putting
> latecomers at an advantage that would be, IMO, sufficient to
> completely kill the idea.  In the current climate, I think the
> community would decide that it preferred a disfunctional DNS if
> that were ever the choice (see the "start over" remark above).
>
> (3) At least in the discussions that led up to RFC 1591, and
> probably much earlier, there were concerns about reducing the
> likelihood of false hits if the end user made single-character
> typing errors.  With only 26 (or maybe 36) possible characters,
> it could just about be guaranteed that all of them would be
> registered and that _any_ typing error would yield a false
> match.  That, in itself, has been considered sufficient to
> prohibit single-letter labels and, by extension, to be fairly
> careful about two-letter ones.   There have been arguments on
> and off over the years as to whether this is a "technical"
> reason or an attempt to set policy.  Even though the mismatches
> would obviously not cause the network to explode or IP to stop
> working, at least some of us consider the informational
> retrieval and information theoretic reasons to insist on more
> information in domain name labels in order to lower the risk of
> false positive matches to be fully as "technical" as something
> that would have obvious lower-level network consequences.
> Others --frankly especially those who see commercial advantage
> in getting single-letter names-- have argued that this position
> is just a policy decision in disguise.
>
> Note that, with slight modifications, the second and third
> arguments apply equally well to TLD allocations and to SLD
> allocations, especially in popular domains.
>
> The reasoning associated with the third case also applies to any
> other script that contains a fairly small number of characters.
> One could manage a long philosophical discussion as to whether
> there are sufficient characters in the fully-decorated
> Latin-derived collection to eliminate the problem, but an
> analysis of keyboard and typing techniques/ input methods for
> that range of characters would, IMO, yield the same answer --
> single-letter domains are just not a good idea and two-letter
> ones near the top of the tree should be used only with great
> caution.
>
> On the other hand, the same reasoning would break down when
> confronted with a script that contains thousands of characters,
> such as the "ideographic" ones.  There are enough characters
> available in those scripts that one can presumably not worry
> about single-character typing errors (and one can perhaps worry
> even less if the usual input methods involve typing
> phonetically, using a different script, and then selecting the
> relevant characters from a menu -- in those cases, the phonetic
> representations are typically more than a character or two long
> and the menu selection provides an extra check about false
> matches).
>
>      john
>
>
>
> --On Thursday, 03 July, 2008 19:04 -0400 Vint Cerf
> <vint@google.com> wrote:
>
>> seems odd to me too, James.
>>
>> vint
>>
>>
>> On Jul 3, 2008, at 6:14 PM, James Seng wrote:
>>
>>>> At the moment, the condition is "no single Unicode code
>>>> point." To the extent that a single CJK ideograph can be
>>>> expressed using a single Unicode code point, this would
>>>> represent the situation to which you say you would object. I
>>>> will dig through my notes to find out why the "single
>>>> character" condition was adopted -
>>>
>>> Would you be able to explain why the condition is "no single
>>> Unicode code point"? Whats the technical basis for that?
>
>
>
>

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