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

Peter Saint-Andre <stpeter@stpeter.im> Thu, 10 October 2013 02:16 UTC

Return-Path: <stpeter@stpeter.im>
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 A902021E80BA for <precis@ietfa.amsl.com>; Wed, 9 Oct 2013 19:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.11
X-Spam-Level:
X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 MOnvclOmpIJZ for <precis@ietfa.amsl.com>; Wed, 9 Oct 2013 19:16:26 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 98EE821E8264 for <precis@ietf.org>; Wed, 9 Oct 2013 19:16:21 -0700 (PDT)
Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 057B6414CD; Wed, 9 Oct 2013 20:22:19 -0600 (MDT)
Message-ID: <52560DF2.2020508@stpeter.im>
Date: Wed, 09 Oct 2013 20:16:18 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> <52554FE3.70504@stpeter.im> <5255C4FC.4060705@stpeter.im> <5256061F.1090108@it.aoyama.ac.jp>
In-Reply-To: <5256061F.1090108@it.aoyama.ac.jp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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 02:16:31 -0000

On 10/09/2013 07:42 PM, "Martin J. Dürst" wrote:
> On 2013/10/10 6:05, Peter Saint-Andre wrote:
>
>> Here is proposed text (for the end of section 9.5):
>>
>>     The challenges inherent in supporting the full range of Unicode code
>>     points has in the past led some to hope for a way to 
>> programmatically
>>     negotiate more restrictive ranges based on locale, script, or other
>>     relevant factors.  As a general-purpose internationalization
>>     technology, the PRECIS framework does not include such a negotiation
>>     mechanism.
>
> Mostly fine up to here, except that in this area, not only negotiation 
> mechanisms, but also augmenting the identifiers themselves with 
> language/locale information are regularly wished for. Using a specific 
> example, that chat[English] and chat[French] would be two separate 
> identifiers. We should also clearly warn against this.
>
>
>>                 Applications requiring a tighter binding to the user's
>>     linguistic environment might need to develop extensions to the 
>> PRECIS
>>     framework, or special-purpose internationalization technologies.
>
> I don't like this, because it essentially says "we don't do this, but 
> you may well want to do it". It's something that makes a lot of sense 
> e.g. in a content management system. But it does not make sense, and 
> we shouldn't give the impression that it does, in the context of 
> identifiers and similar stuff (even the PRECIS "FreeformClass" is 
> about identifiers, not about content.
You make several good points. How about this?

    The challenges inherent in supporting the full range of Unicode code
    points have in the past led some to hope for a way to
    programmatically negotiate more restrictive ranges based on locale,
    script, or other relevant factors, to tag the locale associated with
    a particular string, etc.  As a general-purpose internationalization
    technology, the PRECIS framework does not include such mechanisms.


Peter