[Ltru] MD48: conflicts in requirements
Addison Phillips <addison@yahoo-inc.com> Mon, 31 March 2008 20:02 UTC
Return-Path: <ltru-bounces@ietf.org>
X-Original-To: ltru-archive@megatron.ietf.org
Delivered-To: ietfarch-ltru-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD923A6ACE; Mon, 31 Mar 2008 13:02:35 -0700 (PDT)
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A163D28C3B7 for <ltru@core3.amsl.com>; Mon, 31 Mar 2008 13:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 fwG8fXq5qVjK for <ltru@core3.amsl.com>; Mon, 31 Mar 2008 13:02:27 -0700 (PDT)
Received: from rsmtp1.corp.yahoo.com (rsmtp1.corp.yahoo.com [207.126.228.149]) by core3.amsl.com (Postfix) with ESMTP id EF52E3A6B34 for <ltru@ietf.org>; Mon, 31 Mar 2008 13:02:27 -0700 (PDT)
Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m2VK2Olg075587 for <ltru@ietf.org>; Mon, 31 Mar 2008 13:02:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=YfRVSlfWXHBS0JsR1g/1mL5FrXy0lXtHuA0joj7LdHc1bCjMGTApAbWv71kAAlOI
Message-ID: <47F1434F.7000409@yahoo-inc.com>
Date: Mon, 31 Mar 2008 13:02:23 -0700
From: Addison Phillips <addison@yahoo-inc.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: 'LTRU Working Group' <ltru@ietf.org>
Subject: [Ltru] MD48: conflicts in requirements
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org
Mark previously wrote to the list about this issue, in an email dated 17 March at 17:27 Pacific time and titled "[Ltru] Editorial comments on draft-4646bis-12", appearing in the archive here: http://www.ietf.org/mail-archive/web/ltru/current/msg09656.html This comment turns on the fact that we added the requirement for valid tags to obey the Prefix field in one of the 4646bis drafts. It was not present in 4646. I support making the change Mark proposes. Failing that, we should modify 2.2.5 and 3.1.2 appropriately. Following the '====' is the complete text of Mark's comment. Addison ==== MD 48 Conflict We have two notions of "goodness" defined in Section 2.9. Well-formedness, and validity. Well-formed. It is well-formed when it follows the ABNF in Section 2.1. That is clear. Valid. We then say in 2.2.9 that it is valid when 3 conditions hold: A tag is considered "valid" if it well-formed and it also satisfies these conditions: * The tag is either a grandfathered tag, or all of its language, script, region, and variant subtags appear in the IANA language subtag registry as of the particular registry date. * There are no duplicate singleton (extension) subtags and no duplicate variant subtags. * For each subtag that has a 'Prefix' field in the registry, the Prefix matches the language tag using Extended Filtering (Phillips, A. and M. Davis, "Matching of Language Tags," September 2006.) [RFC4647]. That is, each subtag in the Prefix is present in the tag and in the same order. Furthermore, all of the Prefix's subtags MUST appear before the subtag. For example, the Prefix "zh-TW" matches the tag "zh-Hant-TW". We also define "valid" for a given extension. We explicitly do not list that a valid tag also satisfy all of the MUSTs in sections 2.2.1 through 2.2.9. That is because: 1. some of those MUSTs are actually requirements on the registration policy -- given that MUSTs have been obeyed, the contents of the registry can be assumed to be cool. 2. some of those MUSTs are just reflecting the ABNF (eg that the script subtag MUST follow the language subtag 3. all the other MUSTs are for extension tag stuff (and we define "valid for an extension" separately) After scanning through all these MUSTs, there are conflicts between 2.9 plus 3.1.2, which are in terms of MUST, and 2.2.5 and 3.1.2 which are SHOULD and "appropriate". 2.2.5. Variant Subtags ...The 'Prefix' indicates the language tag or tags that would make a suitable prefix (with other subtags, as appropriate) in forming a language tag with the variant. That is, each of the subtags in the prefix SHOULD appear, in order, before the variant... 3.1.7. Prefix Field The 'Prefix' field contains an extended language range whose subtags are appropriate to use with this subtag: each of the subtags in one of the subtag's Prefix fields MUST appear before the variant in a valid tag. For example, the variant subtag '1996' has a 'Prefix' field of "de". This means that tags starting with the sequence "de-" are appropriate with this subtag, so "de-Latg-1996" and "de-CH-1996" are both acceptable, while the tag "fr-1996" is an inappropriate choice. 3.1.2. Record Definitions ...For example, the 'Prefix' for the variant 'nedis' is 'sl', meaning that the tags "sl-nedis" and "sl-IT-nedis" are appropriate while the tag "is-nedis" is not. We can't say both that something is a SHOULD or simply "appropriate", and also that it is a MUST. We need to change this uniformly to be either MUST and use the term "valid", or change this uniformly to be SHOULD and use the term "appropriate". That is, the document as it stands is contradictory, and someone could take either position on how Prefixes need to be treated by conformant implementations. So we have to resolve this one way or another. My recommendation would be uniformly SHOULD/appropriate, mostly because prefixes are edge cases that simply aren't worth testing for. I'm perfectly happy saying that an implementation isn't conformant if it doesn't check the registry for subtag validity; but prefixes are just not so important that I'd be happy saying that an implementation isn't conformant if it doesn't check for them. The result would be changing 3.1.7 MUST to SHOULD and in 2.9 would be the following (with minor wordsmithing): A tag is considered "valid" when it satisfies these conditions: * The tag is well-formed. * The tag is either a grandfathered tag, or all of its language, script, region, and variant subtags appear in the IANA language subtag registry as of the particular registry date. * The tag has no duplicate singleton (extension) subtags and no duplicate variant subtags. ==== END OF MARK'S COMMENT ==== -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru
- [Ltru] MD48: conflicts in requirements Addison Phillips