Subject: RE: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026)

From: "Addison Phillips" <[email-masked]>
Date: Tue, 12 Jul 2005 15:00:27 -0700

+1

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mark Davis
> Sent: 2005年7月12日 14:23
> To: Randy Presuhn; [email-masked]
> Subject: Re: [Ltru] Adding more 2119 keywords (was: Re: Finishing off
> #1026)
> 
> I've looked them over, and I don't think any rise to the level that there
> will be a misunderstanding in what is required for interoperation or
> limited
> harmful behavior. So my vote would be to belay these to the next version
> (and ask John to do his next review before last call ;-)
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Randy Presuhn" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 12, 2005 13:03
> Subject: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026)
> 
> 
> > Hi -
> >
> > Both as an individual contributor and as a co-chair, I'd like to remind
> everyone
> > of the guidance RFC 2119 gives in the use of these keywords:
> >
> >    Imperatives of the type defined in this memo must be used with care
> >    and sparingly.  In particular, they MUST only be used where it is
> >    actually required for interoperation or to limit behavior which has
> >    potential for causing harm (e.g., limiting retransmisssions)
> >
> > Since we are in working group last call, I'd like all concerned to
> consider
> > carefully whether each proposed change of this type is actually
> > *necessary*.  If it is, fine.  Necessary fixes should be taken care of.
> > If the proposed keyword addition is not *necessary*, I suggest
> considering
> > whether the value of making the change is worth the risk of the changes
> > cumulatively necessitating a second last call.
> >
> > Randy
> >
> > ----- Original Message -----
> > From: "Addison Phillips" <[email-masked]>
> > To: "John.Cowan" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Tuesday, July 12, 2005 9:45 AM
> > Subject: RE: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?)
> >
> >
> > 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:[email-masked]]
> > > Sent: 2005?7?12? 7:00
> > > To: Addison Phillips
> > > Cc: [email-masked]
> > > 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,
> [email-masked]
> > > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru