+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: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org] On > Behalf Of Mark Davis > Sent: 2005年7月12日 14:23 > To: Randy Presuhn; ltru at ietf.org > 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" <randy_presuhn at mindspring.com> > To: <ltru at ietf.org> > 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" <addison.phillips at quest.com> > > To: "John.Cowan" <jcowan at reutershealth.com> > > Cc: <ltru at ietf.org> > > 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:jcowan at reutershealth.com] > > > Sent: 2005?7?12? 7:00 > > > To: Addison Phillips > > > Cc: ltru at 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 at 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 at lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru at lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru at lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.