[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