Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

Alex Bligh <alex@alex.org.uk> Fri, 06 November 2009 19:41 UTC

Return-Path: <alex@alex.org.uk>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7BD63A69DE for <dnsop@core3.amsl.com>; Fri, 6 Nov 2009 11:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Level:
X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599]
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 q26rNnHLnG70 for <dnsop@core3.amsl.com>; Fri, 6 Nov 2009 11:41:32 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [217.147.82.63]) by core3.amsl.com (Postfix) with ESMTP id ACBB53A69CB for <dnsop@ietf.org>; Fri, 6 Nov 2009 11:41:32 -0800 (PST)
Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id C8745C2DA3; Fri, 6 Nov 2009 19:41:54 +0000 (GMT)
Date: Fri, 06 Nov 2009 19:41:06 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Andrew Sullivan <ajs@shinkuro.com>, dnsop@ietf.org
Message-ID: <D345BEBEB0A33588E9D6A3D3@Ximines.local>
In-Reply-To: <20091106193323.GZ17456@shinkuro.com>
References: <20091105205921.GL17456@shinkuro.com> <8F5D82447C5F8BC6B50CD983@Ximines.local> <20091106193323.GZ17456@shinkuro.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2009 19:41:33 -0000

--On 6 November 2009 14:33:23 -0500 Andrew Sullivan <ajs@shinkuro.com> 
wrote:

>> I should probably declare my hand in that I think in most cases the
>> variant stuff is a non-problem (blocking is adequate apart from
>> where the user is likely to mistype themselves)
>
> According to some people I'm inclined to believe (I can't say this
> from personal experience), in non-alphabetic scripts there is indeed a
> serious problem with respect to variants.  It's not actually like the
> case of (say) colour vs. color, because users tend to have access to
> one version or another of the "same" character, but that character is
> actually encoded under Unicode as a different character.  This is, I
> am led to believe, a very common problem in areas where, for instance,
> Simplified and Traditional Chinese characters are both in regular use.
> The upshot is that every competent user of the language will recognize
> two different arrangements of symbols as "the same word", each user
> will be able to type one or the other of the arrangements (but not
> both) at their keyboard, and yet the two different arrangements do not
> constitute equvalent labels.  So, it's as though by configuring your
> system with locale en-CA, you were _unable_ to type "color.com" into a
> resolution context.  There is a genuine user problem here (though
> whether one should actually solve it is still an open question).

Right. So in that example, there is clearly a problem, and it
may well need addressing.

All I am saying is that not every problem needs addressing the same
way. To take your particular example, it is not inconceivable that
in the scheme you have mentioned, labels below the TLD either
have, or have not, commonly got the same variant problem.

-- 
Alex Bligh