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

"YAO Jiankang" <yaojk@cnnic.cn> Mon, 09 November 2009 00:34 UTC

Return-Path: <yaojk@cnnic.cn>
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 5F7E03A6A4C for <dnsop@core3.amsl.com>; Sun, 8 Nov 2009 16:34:52 -0800 (PST)
X-Quarantine-ID: <HeQgD9hvfV4g>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803]
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 HeQgD9hvfV4g for <dnsop@core3.amsl.com>; Sun, 8 Nov 2009 16:34:51 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 516A13A67A2 for <dnsop@ietf.org>; Sun, 8 Nov 2009 16:34:49 -0800 (PST)
Received: (eyou send program); Mon, 09 Nov 2009 08:35:16 +0800
Message-ID: <457726916.15156@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 09 Nov 2009 08:35:16 +0800
Message-ID: <026701ca60d4$80d6bb50$01125d85@whatisfuture>
From: YAO Jiankang <yaojk@cnnic.cn>
To: James Seng <james@seng.sg>, Andrew Sullivan <ajs@shinkuro.com>
References: <20091105205921.GL17456@shinkuro.com><8F5D82447C5F8BC6B50CD983@Ximines.local> <20091106193323.GZ17456@shinkuro.com> <457595832.16556@cnnic.cn>
Date: Mon, 09 Nov 2009 08:35:05 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0264_01CA6117.895EBD70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Mon, 09 Nov 2009 00:34:52 -0000

+1.
  ----- Original Message ----- 
  From: James Seng 
  To: Andrew Sullivan 
  Cc: dnsop@ietf.org 
  Sent: Saturday, November 07, 2009 8:10 PM
  Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt


  "There is a genuine user problem here (though whether one should actually solve it is still an open question)."

  It is a genuine user problem but I disagree with your latter statement.

  It is not an open question it must be solved. It is a serious enough problem for Chinese that it must be resolve for the Chinese user. The open question is "how", not "if".

  For some background on CJK ideograph, you may refer to an expired draft I wrote many years ago

  http://james.seng.sg/files/draft-ietf-idn-cjk-01.pdf

  RFC 3743 will also be a good point of reference.

  -James Seng


  On Sat, Nov 7, 2009 at 3:33 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:

    On Fri, Nov 06, 2009 at 07:06:38PM +0000, Alex Bligh 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).

    Best,


    A

    --
    Andrew Sullivan
    ajs@shinkuro.com
    Shinkuro, Inc.
    _______________________________________________

    DNSOP mailing list
    DNSOP@ietf.org
    https://www.ietf.org/mailman/listinfo/dnsop





------------------------------------------------------------------------------


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