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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.