RE: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?)

"Addison Phillips" <addison.phillips@quest.com> Tue, 12 July 2005 16:46 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNtT-0002Iy-7s; Tue, 12 Jul 2005 12:46:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNtQ-0002Dz-Ob for ltru@megatron.ietf.org; Tue, 12 Jul 2005 12:46:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14964 for <ltru@ietf.org>; Tue, 12 Jul 2005 12:45:58 -0400 (EDT)
Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsOLe-00061Z-DU for ltru@ietf.org; Tue, 12 Jul 2005 13:15:11 -0400
Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 09:45:43 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?)
Date: Tue, 12 Jul 2005 09:45:42 -0700
Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com>
Thread-Topic: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?)
Thread-Index: AcWG6gGcEZDg04EOREaNAGRzdJ73EQAASMSA
From: Addison Phillips <addison.phillips@quest.com>
To: "John.Cowan" <jcowan@reutershealth.com>
X-OriginalArrivalTime: 12 Jul 2005 16:45:43.0288 (UTC) FILETIME=[24D98780:01C58701]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d
Content-Transfer-Encoding: quoted-printable
Cc: ltru@ietf.org
X-BeenThere: ltru@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@lists.ietf.org>
List-Help: <mailto:ltru-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@lists.ietf.org?subject=subscribe>
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Notes below.

Broadly, use of normative language represents a substantive change. Some of these were specifically changed from normative to non-normative language previously.

The other items I have gone through methodically, results interlinear below.

The first item is moot. That paragraph was rewritten to address Frank's comments and I spent a good bit of editorial attention on making it very clear and more rule-like. It now reads:

<t>UN M.49 has codes for both countries and areas (such as '276' for Germany) and geographical regions and sub-regions (such as '150' for Europe). UN M.49 country or area codes for which there is no corresponding ISO 3166 code SHOULD NOT be registered, except as a surrogate for an ISO 3166 code that is blocked from registration by an existing subtag. If such a code becomes necessary, then the registration authority for ISO 3166 SHOULD first be petitioned to assign a code to the region. If the petition for a code assignment by ISO 3166 is refused
or not acted on in a timely manner, the registration process described in <xref target="registrationProc"></xref> MAY then be used to register the corresponding UN M.49 code. At the time this document was written, there were only four such codes: 830 (Channel Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way UN M.49 codes remain available as the value of last resort in cases where ISO 3166 reassigns a deprecated value in the registry.</t>

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: John.Cowan [mailto:jcowan@reutershealth.com]
> Sent: 2005?7?12? 7:00
> To: Addison Phillips
> Cc: ltru@ietf.org
> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?)
> 
> Addison Phillips scripsit:
> 
> > If it becomes necessary to
> > identify a region for which only a UN M.49 code exists in language tags,
> > then the registration authority for ISO 3166 SHOULD be petitioned to
> > assign a code: such a code could then be registered for use in language
> > tags.
> 
> I think this "could" ==> SHOULD, or at the very least MAY.
> 
> While I'm at it, in the 2005-7-11 draft:
> 
> 	"could be included" in 3.4 ==> MAY;
[Addison Phillips] 
-not a normative statement; it's an example

> 	"might be interpreted", "could be taken", "could be regarded", "one
> 		could write", "could be used" ==> MAY;
[Addison Phillips] 
-examples all

> 	"could be used" in 4.5 ==> MAY;
[Addison Phillips] 
+marginal case. (In case it isn't clear, my comments with - are rejects and + are where I made the change.)

> 	"cannot" in 2.2.3 ==> MUST NOT;
[Addison Phillips] 
-another example
 
> 	"can" in 2.2.4 ==> MAY;
[Addison Phillips] 

-explanatory text which should not be normative. Here's what it says:

Their syntax is described here so that implementations can be compatible with any future revision of this document which does provide for their registration.

> 	"cannot" in 2.2.6 items 1 and 3 ==> MUST NOT;
[Addison Phillips] 

+the first one
-the second one: it is in a sentence that explains the sentence before it (which is normative)

> 	"can be split" and "can use the registry" in 3.1 ==> MAY;
[Addison Phillips] 

-the first one: too pedantic
-the second one: this is explaining something that is possible, not a normative restriction.

> 	"can raise objections" in 3.4 ==> MAY;
[Addison Phillips] 

+this should be normative

> 	"can be registered" in 3.5 ==> MAY;
[Addison Phillips] 

+this should be normative

> 	"can only give possible examples" in 4.2 needs no modal, and
> 		==> "gives only possible examples";
[Addison Phillips] 

+although this is the original RFC 3066 text

> 	"can use" in 7 ==> MAY;
[Addison Phillips] 

-not really normative; could change this to "sometimes use"

> 	"ought not" in 4.1 ==> SHOULD NOT;
[Addison Phillips] 

-explanatory text

> 	"will" in 2.2.1 item 5 ==> SHOULD or perhaps MUST;
[Addison Phillips] 

-unnecessary: this is discussing the likely attitude of ietf-languages towards primary language subtag registrations.

> 	"will not be added" in 2.2.1 ==> MUST NOT;
[Addison Phillips] 

+this should be normative

> 	"will maintain" in 2.2.8 ==> MUST;
[Addison Phillips] 

+/-Hmm... this sentence is a bit mushy, since it implies that IANA will be actively maintaining these particular registry entries, which is not actually correct. Changed from:

--
IANA 
will maintain these tags in the registry under either the "grandfathered" 
or "redundant" type.
--

To:

--
These tags will be maintained in the registry in records of either the "grandfathered" or "redundant" type.
--

> 	"will be maintained" in 3 ==> MUST;
[Addison Phillips] 

-shouldn't be normative, although the sentence isn't very elegant

> 	"will consist" in 3.1 ==> MUST;
[Addison Phillips] 

-shouldn't be normative. Did change tense to 'consists'

> 	"no registration records will be maintained" in 3.1 ==>
> 		"registration records MUST NOT be maintained";
[Addison Phillips] 

-shouldn't be normative.

> 	"will be in a modified" in 3.1 ==> MUST;
[Addison Phillips] 

+/-changed from future to present tense, but not turned into a MUST. This section describes the registry and its format. All of the initialization and maintenance instructions use normative language that references this section. Littering this section with MUSTs will make it difficult to read and not add to the clarity of it.

> 	"will evaluate" in 3.2 ==> MUST;
[Addison Phillips] 

+changed

> 	"no new entries will be added and none of the entries will be
> removed"
> 		in 3.2 ==> "new entries MUST NOT be added or removed";
[Addison Phillips] 

+changed to: new entries in this section MUST NOT be added and existing entries MUST NOT be removed

> 	"will be maintained" in 3.4 ==> MUST;
[Addison Phillips] 

-/+ changed to "exists"

> 	"No subtags will be registered" in 3.5 ==> "Subtags MUST NOT
> 		be registered";
[Addison Phillips] 

+changed

> 	TYPO: "will lend" in 3.6 ==> "will tend";
[Addison Phillips] 

Not a typo. Here's the sentence:

In addition, 
    defining a mechanism for maintaining single-letter subtags will lend to the
    stability of this document by reducing the likely need for future revisions
    or updates.

> 	"will use" and "will forward" in 3.6 ==> MUST;
[Addison Phillips] 

+first one
+second one

> 	"will be initialized", "will be relabeled", "will be limited", and
> 		"will be sent" in 5.1 ==> MUST;
[Addison Phillips] 

-first one

+second one

+third one

> 	"will include" in 5.2 ==> MUST;
[Addison Phillips] 

+changed

> 	"will continue" in 8 ==> SHOULD;
[Addison Phillips] 

-not necessary (describes user's or application's choice of language tags)
> 
> Some of these changes may be inappropriate because of the broader context;
> I haven't fully investigated.
> 
> --
> Winter:  MIT,                                   John Cowan
> Keio, INRIA,                                    jcowan@reutershealth.com
> Issue lots of Drafts.                           http://www.ccil.org/~cowan
> So much more to understand!
> http://www.reutershealth.com
> Might simplicity return?                        (A "tanka", or extended
> haiku)


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru