Re: [precis] WGLC: draft-ietf-precis-framework-09.txt

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 10 October 2013 01:20 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2A021F9C89 for <precis@ietfa.amsl.com>; Wed, 9 Oct 2013 18:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.123
X-Spam-Level:
X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ8XiBkiC12I for <precis@ietfa.amsl.com>; Wed, 9 Oct 2013 18:20:24 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2C99C21F9C7A for <precis@ietf.org>; Wed, 9 Oct 2013 18:20:23 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9A1KLXA027509; Thu, 10 Oct 2013 10:20:21 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 29c9_5054_21a724bc_314a_11e3_895c_001e6722eec2; Thu, 10 Oct 2013 10:20:20 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DA20ABFBBA; Thu, 10 Oct 2013 10:20:20 +0900 (JST)
Message-ID: <525600C7.1020703@it.aoyama.ac.jp>
Date: Thu, 10 Oct 2013 10:20:07 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <CADRqEyrNmY=RTVpUuVmj4qG2d5jy8LsL5uJuXHX7+YtGqkFxrA@mail.gmail.com> <52547128.5070909@stpeter.im> <52551BB3.4080407@it.aoyama.ac.jp> <52551DFE.8000608@it.aoyama.ac.jp> <52554D5A.7060300@stpeter.im>
In-Reply-To: <52554D5A.7060300@stpeter.im>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: precis@ietf.org
Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/precis>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2013 01:20:31 -0000

On 2013/10/09 21:34, Peter Saint-Andre wrote:
> On 10/9/13 3:12 AM, "Martin J. Dürst" wrote:

>> In addition, in the introduction, there is a paragraph:
>>
>>     5.  Leave various mapping operations (e.g., case preservation or
>>         lowercasing, Unicode normalization, mapping of certain characters
>>         to other characters or to nothing, handling of full-width and
>>         half-width characters, handling of right-to-left characters) as
>>         the responsibility of application protocols, as was done for
>>         IDNA2008 through an IDNA-specific mapping document [RFC5895].
>>
>> where "handling of right-to-left characters" is described as a mapping
>> operation. That doesn't make sense to me, I think it should be moved out
>> to a separate point.
>
>
> I think we can change "mapping operations" to "character-related
> operations".

Well, that wouldn't be wrong, but it would be extremely generic. There's 
nothing in the document that isn't about characters, or is there?

I think something like

5.  Leave various mapping operations (e.g., case preservation or
     lowercasing, Unicode normalization, mapping of certain characters
     to other characters or to nothing, handling of full-width and
     half-width characters) and the handling of right-to-left characters
     as the responsibility of application protocols, as was done for
     IDNA2008 through an IDNA-specific mapping document [RFC5895].

Would be at least slightly better.


Regards,   Martin.