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

From: "Addison Phillips" <[email-masked]>
Date: Tue, 12 Jul 2005 09:45:42 -0700

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Jul 2005 13:03:19 -0700

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 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

[Addison Phillips]

[Addison Phillips]
-examples all

[Addison Phillips]

[Addison Phillips]
-another example

[Addison Phillips]

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

[Addison Phillips]

+the first one

[Addison Phillips]

[Addison Phillips]

[Addison Phillips]

[Addison Phillips]

[Addison Phillips]

[Addison Phillips]

-explanatory text

[Addison Phillips]

[Addison Phillips]

[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:

To:

[Addison Phillips]

[Addison Phillips]

[Addison Phillips]

-shouldn't be normative.

[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.

[Addison Phillips]

+changed

[Addison Phillips]

[Addison Phillips]

-/+ changed to "exists"

[Addison Phillips]

+changed

[Addison Phillips]

In addition,

[Addison Phillips]

+first one
+second one

[Addison Phillips]

-first one

+second one

+third one

[Addison Phillips]

+changed

[Addison Phillips]

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 12 Jul 2005 14:23:03 -0700

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)

> Broadly, use of normative language represents a substantive change. Some
of these were specifically changed from normative to
> The first item is moot. That paragraph was rewritten to address Frank's
comments and I spent a good bit of editorial attention on
> <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
> 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
> Their syntax is described here so that implementations can be compatible
with any future revision of this document which does
> -unnecessary: this is discussing the likely attitude of ietf-languages
towards primary language subtag registrations.
> +/-Hmm... this sentence is a bit mushy, since it implies that IANA will be
actively maintaining these particular registry entries,
> +/-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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Jul 2005 00:31:58 +0200

Randy Presuhn wrote:

>| 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

ACK, can't say this often enough.  If a standard says "xyz are
letters", then it's unnecessary to replace it by "xyz NUST be
letters" for some imaginary normative effect.  The standard is
normative without any 2119-keywords, unless it explicitly says
"informative" (examples etc.).

> I suggest considering whether the value of making the change
> is worth the risk of the changes cumulatively necessitating
> a second last call.

So far I thought that an "internal last call" is something like
a dress rehearsal, it's not really required, and it's also not
necessary to repeat it.

Mark wrote in his reply:
| ask John to do his next review before last call ;-)

Better we find any "bugs" now than somebody else later in the
real "last call".  But IMO using _no_ 2119-keywords where they
are _not_ needed is no "bug", quite the contrary.

BTW, in <http://mid.gmane.org/[email-masked]>
Brian mentioned the case of a draft standard (3596) obsoleting
BCP 49 (3152), apparently that's possible:

<http://purl.net/net/rfc/3596> + <http://purl.net/net/rfc/3152>

                         Bye, Frank

---

From: "John.Cowan" <[email-masked]>
Date: Tue, 12 Jul 2005 22:15:32 -0400

Frank Ellermann scripsit:

> real "last call".  

Exactly.  For the record, when I posted that, I didn't yet know we were
in last-call status.

-- 
John Cowan  [email-masked]  www.reutershealth.com  www.ccil.org/~cowan
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye

---

From: "John.Cowan" <[email-masked]>
Date: Tue, 12 Jul 2005 22:29:47 -0400

>     stability of this document by reducing the likely need for future revisions

"Lend" without a direct object is unidiomatic.  I think you want "will
lend stability to this document".

-- 
As you read this, I don't want you to feel      John Cowan 
sorry for me, because, I believe everyone       [email-masked]
will die someday.                               http://www.reutershealth.com
        --From a Nigerian-type scam spam        http://www.ccil.org/~cowan

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Jul 2005 04:46:05 +0200

John.Cowan wrote:
 
> when I posted that, I didn't yet know we were in last-call
> status.

Randy posted it in
<http://mid.gmane.org/001001c585ed%245b049ee0%247f1afea9@oemcomputer>

I just found the "secret script" for this part of the process:

MUST and SHOULD:

ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld32.htm
ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld33.htm

WG Last Call

ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld35.htm
ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld36.htm

So we are at step 35 of 50, that's only 70% ;-)  Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Wed, 13 Jul 2005 06:24:30 +0200

>So we are at step 35 of 50, that's only 70% ;-)  Bye, Frank

Frank,
as you may note:

"Document must be reviewed and actively supported by a significant number 
of people, including experts in all applicable areas ... or it should not 
be sent to the IESG. Silent does not mean consent during this phase". I do 
not think this is fully matched up to now. I accept there are experts in 
this WG on various applicable parts, and that I am one of them, focusing on 
OPES, DNS, IDN, ccTLDs, Common of Reference Centers, but there are 
certainly many other areas. A list would be useful. And I do not support 
the Document in its present form as a replacement of RFC 3066 but I accept 
it with comments as a complement of RFC 3066. Otherwise the we are to do is 
to review all the RFC quoting RFC 3066 and proactively making sure they are 
not adversely affected. Both is in theory and in the way they are used.

"Document should be extensively reviewed both within the WG and across 
other areas". Due to the difference of point of view and the lack of common 
evaluation of the Charter, I consider myself as one of the "other areas". I 
will try as indicated before to provide a review before having to go on 
vacations.

But I am certainly disappointed by the lack of Charter clean sheet study 
(cf. 
ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld24.htm 
)

I strongly recommand to consider this:
ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld23.htm

jfc