Re: [I18n-discuss] comments on draft-freytag-troublesome-characters-01
Asmus Freytag <asmusf@ix.netcom.com> Mon, 07 August 2017 07:00 UTC
Return-Path: <asmusf@ix.netcom.com>
X-Original-To: i18n-discuss@ietfa.amsl.com
Delivered-To: i18n-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C86A129562; Mon, 7 Aug 2017 00:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.128
X-Spam-Level:
X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDs9f0aTjOAF; Mon, 7 Aug 2017 00:00:16 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE441296C9; Mon, 7 Aug 2017 00:00:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1502089216; bh=4bZXLelbvcsK7fPI/2KGDEYw+o23gElt/rcD fuQiQvs=; h=Received:From:Subject:To:References:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=FtFAQuF7RGUZCAHUkJfQycnKn8Q+e5xPv fVPhAy+KfwVbClbcqavBUDLPRWcLAuxdnXosTZbwLRpnBQlXKgDDqQgmTwVFC5QGgK8 WwLupqWTKdwnwkS5Zua/7lc+P0xfM7LlK8A00NIbsnRIEVNWYIMczMOZAJZ+3Wb3lUc Of3yFO3DaZGVMWRNULAqn+15t3FPdE8bLdxFQ3Cg2kMsPeyABw8dSHoNdWQAKymYTav ZEVND3sDmpEEme6Kq1Bi4EQ+2Lw4ZxpMRmm7Ky10DUDe1DsH6BHGEeM+Uw4OZsCRz5E pV+rvWHCV2ccodR1RFgdCASkjauHi0zh6lllg7Fsg==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=gQD0VhBabphkbGXaCA8jGQRD6+1bQgJQqicYWK8Sxr8BwI/QWQhOKgyBxep/D75b43VPhddWQ76LbHwbGe32dD6UY1yJUWTWgxb5XcKimjKAHMpnVUYo19lzm7yCaU9vVMmuznhFwXripPFF+petqHSp2FiFABqRA6a/zkayfYo457JkYeVloK3oll1ZroF6w1rLevClOBxstm2kY2Fil0U/6uK7+9mvGOniJXPVh++nW/4iFOi6wjXbiWheQgIidaaRWHCqc74Y3naY4nJflg5ZTEtcBAdqfhqoFqs2TrA47o7VmoiBOr8+gKEjDLd21u/zZTrIE243qXJafbFSSw==; h=Received:From:Subject:To:References:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [174.24.247.83] (helo=[192.168.0.5]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <asmusf@ix.netcom.com>) id 1dec1N-0004Mq-PW; Mon, 07 Aug 2017 03:00:14 -0400
From: Asmus Freytag <asmusf@ix.netcom.com>
To: Marc Blanchet <marc.blanchet@viagenie.ca>, i18n-discuss@iab.org, draft-freytag-troublesome-characters@ietf.org
References: <47C94F75-ADB0-4EEE-84F5-B5A7C6A2E372@viagenie.ca>
Message-ID: <596940f3-58e5-ffb6-9444-668acd8e2509@ix.netcom.com>
Date: Sun, 06 Aug 2017 19:14:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <47C94F75-ADB0-4EEE-84F5-B5A7C6A2E372@viagenie.ca>
Content-Type: multipart/alternative; boundary="------------F1867653E61741CA1B58F8DC"
Content-Language: en-US
X-ELNK-Trace: 464f085de979d7246f36dc87813833b245123d0f0160089e0f343d607c3e8bfc776ff66e47904a7d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 174.24.247.83
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18n-discuss/AzaCEyDv0jGIhKIvJlQeYw6ockc>
Subject: Re: [I18n-discuss] comments on draft-freytag-troublesome-characters-01
X-BeenThere: i18n-discuss@iab.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Internationalization Program Open Discussion List <i18n-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/i18n-discuss>, <mailto:i18n-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18n-discuss/>
List-Post: <mailto:i18n-discuss@iab.org>
List-Help: <mailto:i18n-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/i18n-discuss>, <mailto:i18n-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 07:00:18 -0000
On 7/9/2017 2:02 PM, Marc Blanchet wrote: > > The registry is updated by Expert Review. > > <MB> »Expert Review », as is, I disagree. As we all know and discussed > since the early days of idn wg, sometimes a single code point may > raise a lot of different opinions and perspectives. Therefore, a > single expert to me is not enough to approve changes to this registry. > I would suggest something in the form of the mime process, where the > proposal is sent to a specific mailing list for discussion and maybe a > reviewer (or two) will inform IANA of the conclusion. Or any public > process that includes more than one person isolated talking to IANA. > </MB> > > It ought to contain only > code points that are significant in identifiers and that need special > policies (including policies of exclusion). Only code points that > are eligible for use in identifiers (i.e. that are not DISALLOWED) > ought to be included. Code points that are CONTEXTJ or CONTEXTO > ought to only be included if concerns are identified that are not > mitigated by the existing IDNA context rules. > > <MB>I think this policy is not enough precise for the Expert Review > (or whatever process) to identify which one should be included or not. > Therefore, I would highly suggest that the authors define a set of > criteria to help the review process > </MB> > > <MB>I wonder if there should be some words about managing the changes > in this table. Specially, if later, things are found that make an > entry not « backward » compatible with an earlier version of the > table. I think assuming that the table will only add stuff may be > risky… And I think we can assume that this registry will be parsed by > software programs in registries, registrars, etc… Therefore, some > guidelines for both the expert review or whatever process and for the > implementor/reader about non-compatible changes is necessary. > </MB> > I am currently drafting the following text for this section. Comments welcome. A./ <section title="Maintenance" anchor="sec_maintenance" toc="default"> <t>The registry is updated by Expert Review using an open process. Code points that are DISALLOWED in IDNA 2008 are not eligible to be listed. Code points that are CONTEXTJ or CONTEXTO do not need to be included unless there are documented concerns that are not mitigated by the existing IDNA context rules. The focus should be on scripts that are significant for identifiers; code points from scripts that are historic or otherwise of limited use would normally not be considered - however exceptions might be made where authoritative information is readily available. Code points and code point sequences to be included are those that need special policies (including, but not limited to policies of exclusion).</t> <t>New code points of sequences are listed whenever information becomes available that identifies a specific issue that requires attention in crafting a policy for the use of that code point or sequence in network identifiers. Likewise cross references, categories, explanations and references cited may be updated. </t> <t>The contents of the registry should not represent original research but a collection of issues documented elsewhere, with appropriate references cited. An exception might be cases that are in clear analogy to existing entries, but not covered by existing references, for example, because the code point in question was recently added to Unicode. The use and nature of such analogy is to be documented.</t> <t>If a particular language or script community reaches an apparent consensus that some code point is problematic, or that of two identical code points or sequences one should be preferred over the other, such recommendations should be documented in this registry. In addition, if the Unicode Standard designates a code point as "deprecated" or identifies code points that are "intentionally identical", this is also something that should be reflected in the registry. Another source of potential information might be existing registry policies or recommended policies, particularly where it is apparent that they represent a careful analysis of the issue or a wider consensus, or both.</t> <t>Propsosed additions to the registry are to be shared on a mailing list to allow for broader comment and vetting.If there is a disagreement about the existence of an issue or its severity, it is preferable to document both the issue and the different evalutations of it. In all cases, the information and documentation presented must allow a user to fully evaluate the status of any entry in the registry.</t> <t>There is no requirement for the registry to be backward compatible or stable in any way. If new information emerges, code points may be added or reclassified. In case of significant changes, the explanation should note the nature of the change and cite a reference to document the basis for it.</t> </section>
- [I18n-discuss] comments on draft-freytag-troubles… Marc Blanchet
- Re: [I18n-discuss] comments on draft-freytag-trou… Asmus Freytag
- Re: [I18n-discuss] comments on draft-freytag-trou… Andrew Sullivan
- Re: [I18n-discuss] comments on draft-freytag-trou… Marc Blanchet
- Re: [I18n-discuss] comments on draft-freytag-trou… Marc Blanchet
- Re: [I18n-discuss] comments on draft-freytag-trou… Marc Blanchet
- Re: [I18n-discuss] comments on draft-freytag-trou… Asmus Freytag
- Re: [I18n-discuss] comments on draft-freytag-trou… Marc Blanchet