Re: Update of RFC 2606 based on the recent ICANN changes?

"James Seng" <> Thu, 03 July 2008 16:09 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 157233A6AAB; Thu, 3 Jul 2008 09:09:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC3AE3A6987 for <>; Wed, 2 Jul 2008 17:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tcG0C7uxAr2V for <>; Wed, 2 Jul 2008 17:29:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A62A43A697A for <>; Wed, 2 Jul 2008 17:29:33 -0700 (PDT)
Received: by with SMTP id 27so652601wfd.31 for <>; Wed, 02 Jul 2008 17:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=3/eKOmFvdwCJKVsmlTIdB54TIURdaMYZ7hyKjfypJ/E=; b=He+VqhrGtHJteixEdP3z6DGLNCfEnM5SA0HPKdezei/9Wz9TFyP6T8P0tdTx2rKLFR D8dP/nSQavaK9EuATzeCLVudo7Cnuys8brD8+9+wClse6Wtluqj9iNCt5fv0fyx/rg4D GmcwQclebAxBHyYeCV8z+dvkdxr2M0i891FrY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=njfpWiFGBrZTiEiLZ+K9AIrM+FrptFIVEi3KUVVZ9fR/TBTRFaaCNGoVdjBi0LTeOd DT0izjZDy/BfP1h5wP80XNPIOPzEQqjgAxdla0C+NFdd5ylCK+Fni0z0/8+8H7K5407j WzFL6EZN0wAv+/QvJ+2yW8EVYMOdUcHvImYos=
Received: by with SMTP id y17mr3302508wfc.189.1215044980960; Wed, 02 Jul 2008 17:29:40 -0700 (PDT)
Received: by with HTTP; Wed, 2 Jul 2008 17:29:40 -0700 (PDT)
Message-ID: <>
Date: Thu, 3 Jul 2008 08:29:40 +0800
From: "James Seng" <>
To: "John C Klensin" <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes?
In-Reply-To: <14AE948B18197467AE4D96A4@p3.JCK.COM>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <14AE948B18197467AE4D96A4@p3.JCK.COM>
X-Google-Sender-Auth: 33bf0a5963741f40
X-Mailman-Approved-At: Thu, 03 Jul 2008 09:09:44 -0700
Cc: Lyman Chapin <>,,, Lyman Chapin <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

On Thu, Jul 3, 2008 at 7:01 AM, John C Klensin <> wrote:
>> Any proposal for a new gTLD must satisfy a number of "string
>> criteria" that will be specified explicitly in the RFP,
>> including the requirements that the U-label must not:
>> (a) be identical to an existing TLD;
> Is "сом" identical to "com"? (the first of these is U+0441
> U+043E U+043C)

The current principle is that it should be be a "confusing string",
which is vague enough to cover the case above (but perhaps not able to
cover .co)

>> (b) be identical to a Reserved Name;
>> (c) consist of a single character;
> I've heard it argued repeatedly that this is an unreasonable
> rule for ideographic characters.   I don't have an opinion, but
> hope that ICANN has considered that case in full details.

This is where we dive into a discussion what is a "character". In
ideographic based language, there isnt a concept of a "word".

For example, Chinese, Japanese and Korean are actually "phonetics
language", and that ideograph characters are used to express the
phonetics. A "word" or more accurately "morphemes" can be express in a
single or more ideographs. A single latin character is unlikely to be
useful by itself (except of a and i) but thats not the case in CJK.

If the condition is that "no single ASCII character", I may be neutral
about it (since a single ideograph would never translate to a single
ASCII character in the zonefile, due to the xn-- prefix) but if the
"character" is defined more broadly to cover "U-label" character, then
I would have strong objections.

Incidentally, I remember it is a standing "tradition" that labels may
not be a single ascii character. But is there any technical reason we
should forbid it? (e.g. have not kill any kittens yet)

-James Seng
Ietf mailing list