Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Representation

Yangwoo Ko <newcat@icu.ac.kr> Tue, 28 December 2010 06:21 UTC

Return-Path: <yangwooko@gmail.com>
X-Original-To: ima@core3.amsl.com
Delivered-To: ima@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622713A6924 for <ima@core3.amsl.com>; Mon, 27 Dec 2010 22:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.825
X-Spam-Level:
X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
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 Yg9wBcloSrCi for <ima@core3.amsl.com>; Mon, 27 Dec 2010 22:21:57 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2212F3A6923 for <ima@ietf.org>; Mon, 27 Dec 2010 22:21:57 -0800 (PST)
Received: by qyj19 with SMTP id 19so9610717qyj.10 for <ima@ietf.org>; Mon, 27 Dec 2010 22:24:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=S1FmXebQXfxL31tVhaggQUf4+yMq2PUjG3SbfwvVbOc=; b=SXnFiRvsiXN1NVmoCGsnbVkCvbzqlZKF/9M4IYEz17RTaWcys8NNoTxdOfWCU7jWJk TAUcm5/sBb+n/CPdvnbtWU375s3ocO76npGWGp4kyL8bdVsNPWPMgp3A3elQcrdLJgoo z0I44OE8/PmKw5LAT4nRzAzsQH591IHu75HZ0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=BcQsv1wCGXqfUA0Yk2ucK0U3tRnyDke/r2VDftf0SaMf7uQES5k2oi5kLwkyMAOZsa ek/542rw2iYpHfIOlguaxlb6t3J//CDTWu7ymVQJ4LyajNnLCqOaFHES2Re9A65V+a5F Y+4LLei/gNu7EdzrpZx616iWTsWKn8JiYEzGg=
Received: by 10.224.67.12 with SMTP id p12mr12741826qai.57.1293517441932; Mon, 27 Dec 2010 22:24:01 -0800 (PST)
MIME-Version: 1.0
Sender: yangwooko@gmail.com
Received: by 10.220.202.134 with HTTP; Mon, 27 Dec 2010 22:23:41 -0800 (PST)
In-Reply-To: <61939C011F6BB4A93749804C@192.168.1.128>
References: <Pine.OSX.4.64.1012221602490.40683@mac-allocchio3.elettra.trieste.it> <68655A9F86D4BE7ED933F8A6@192.168.1.128> <4D192FF8.1030706@dcrocker.net> <9B48F59821946F2EA2DCDEA0@192.168.1.128> <4D19623F.3040804@dcrocker.net> <61939C011F6BB4A93749804C@192.168.1.128>
From: Yangwoo Ko <newcat@icu.ac.kr>
Date: Tue, 28 Dec 2010 15:23:41 +0900
X-Google-Sender-Auth: hR7kukci2yN834Q0CcvBZ2ZnaWk
Message-ID: <AANLkTi==F13UbALApdRFtNfhsDoJOAatmztwhPoAMi8a@mail.gmail.com>
To: John C Klensin <klensin@jck.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: dcrocker@bbiw.net, ima@ietf.org
Subject: Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Representation
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Dec 2010 06:21:59 -0000

On Tue, Dec 28, 2010 at 1:17 PM, John C Klensin <klensin@jck.com> wrote:
>>  If you have
>> alternative labeling, that would be great to consider.
>
> I hope someone in the WG will have a good suggestion.   If not,
> we may be back to "ASCII" versus "non-ASCII" as the disjoint
> pair, "Unicode"  to describe the international CCS (inclusive of
> ASCII), and "UTF-8" to describe the particular encoding that is
> used for this protocol and recommended by RFC 2277 (a
> recommendation that is reinforced by draft-iab-idn-encoding and
> other more recent work).

I hope so too. But I don't expect that we are going to have a nice
answer to this soon enough. If it still significantly matters, will it
be useful to list up the cases of possible confusions when current
terminogies are used? With the list, we may be able to add some notes
to one of our documents (possibly framework doc)  to address the known
possible confusions.

-- 
a human known as yangwooko@gmail.com @ gtalk