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

"James Seng" <james@seng.sg> Thu, 03 July 2008 16:09 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 157233A6AAB; Thu, 3 Jul 2008 09:09:47 -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 BC3AE3A6987 for <ietf@core3.amsl.com>; Wed, 2 Jul 2008 17:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 tcG0C7uxAr2V for <ietf@core3.amsl.com>; Wed, 2 Jul 2008 17:29:33 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id A62A43A697A for <ietf@ietf.org>; Wed, 2 Jul 2008 17:29:33 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so652601wfd.31 for <ietf@ietf.org>; Wed, 02 Jul 2008 17:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.142.126.17 with SMTP id y17mr3302508wfc.189.1215044980960; Wed, 02 Jul 2008 17:29:40 -0700 (PDT)
Received: by 10.142.73.17 with HTTP; Wed, 2 Jul 2008 17:29:40 -0700 (PDT)
Message-ID: <558a39a60807021729m1fc299c2ted96064ce73228a7@mail.gmail.com>
Date: Thu, 03 Jul 2008 08:29:40 +0800
From: James Seng <james@seng.sg>
To: John C Klensin <john-ietf@jck.com>
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: <20080701223655.14768.qmail@simone.iecc.com> <C7F7E8A9-C844-4E1C-827D-189D4937BA6B@acm.org> <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@interisle.net>, 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-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thu, Jul 3, 2008 at 7:01 AM, John C Klensin <john-ietf@jck.com> 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. 6.cn have not kill any kittens yet)

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