Subject: [Ltru] Review of 4646bis-10, sections 3.5 to App. B

From: John Cowan <[email-masked]>
Date: Fri, 7 Dec 2007 16:37:56 -0500

Here's the rest of my review, except for the macrolanguage section of 4.1,
which is in a separate posting.  There is only one substantive point:

5.1: does ietf-languages-announcements really exist, and does IANA really
announce to it?

The rest are editorial:

3.5: s/all other fields/any other fields/.

3.5: remove single-sentence graf about extended language subtags.

3.5: draft has both "publicly" and "publically" in different places;
both are orthographically acceptable, but pick one and stick to it.

3.5: s/language is registered/language is already registered/.

3.8: rename section to "Replacement of the Language Subtag Registry";
s/update/replacement/; s/updated/replacement/.

3.8: s/Once published/Once the registry is published/.

4.1: s/Sometimes there is a choice/There is always a choice/, which is
much nearer the truth.

4.1: s/thus not be selected/thus will not be selected/.

4.1: s/zh-cmn/cmn/ (twice).

4.4: The definition of "canonical form" here shouldn't have MUSTard in
it; a definition is just a definition and shouldn't have any modal verbs.
Point 2, s/SHOULD be/are/.  Point 3, /MUST be/are/.   Point 4, same as 3.

4.5: suggested rewrite of grafs 1-3:

        The value and semantic meaning of private use tags and of
        the subtags used within such a language tag are not defined
        by this document.  Like all other subtags, they MUST conform
        to the format and content constraints in the ABNF. They have
        no meaning outside the private agreement between the parties
        that intend to use or exchange language tags that employ them,
        and so are are simply useless for information exchange without
        prior arrangement.  The same subtags MAY be used with a different
        meaning under a separate private agreement. They SHOULD NOT be
        used where alternatives exist and SHOULD NOT be used in content
        or protocols intended for general use.

        However, a language tag which combines private use subtags with
        other subtags conveys more information that a purely private use
        tag prefixed by the singleton subtag 'x'. For some applications,
        this additional information MAY be useful.

5.1: s/update the registry/replace the existing registry in its entirety/.

7: s/rendering engines sometimes use/rendering engines MAY use/.

8 [record-jar]: add "chapter 5".

Appendix B: divide final section into "Some Invalid Tags" and "Some
Ill-Formed Tags".  My suggestions for invalid tags are xxx-Defg-HQ,
de-1996-1996, en-nedis, and ar-a-aaa-b-bbb-a-ccc.  My suggestions
for ill-formed tags are de-419-DE, en-nuspelling, a-de, and perhaps a
few more.

Appendix C: change title to "Sample Registration Form".

-- 
John Cowan   http://ccil.org/~cowan    [email-masked]
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 8 Dec 2007 18:47:13 +0100

John Cowan wrote:

I abuse your reviews to look at the relevant sections
of the latest fantasy island manifest (i.e. what used
to be an LTRU WG draft posted by WG editors before -09)

| The form MUST be sent to [email-masked] by the Language
| Subtag Reviewer.

Why can't the reviewer and IANA use pigeons if that's
what works for them ?  Or more practical the Web form
offered by IANA ?  What is the idea of the MUST here ?

| IANA MUST

I consider a "MUST" while talking with IANA as rude.
There is far too much MUSTard in the I-D, MUSTard
should be reserved for cases where ignoring it is
both plausible and would cause havoc.

| Non-ASCII characters can be sent to IANA by attaching
| the registration form to the email message or by 
| using various encodings in the mail message body 
| (UTF-8 is recommended).  IANA will verify any unclear
| or corrupted characters with the Language Subtag 
| Reviewer prior to posting the updated registry.

Can we please at least consider that neither IANA nor
expert are idiots ?  It's no business of 4646bis to
discuss technical details of the MUAs used by IANA and
expert, as far as I'm concerned the expert can send
IANA an URL where to find the complete registration,
if IANA accepts this.  He could fax it, who cares ?

After an update the registry MUST be valid UTF-8, that
would be MUSTard where I know what it means (it would
be not good enough to guarantee "grapheme-folding" and
NFC, but at least it would cover the worst errors)

| from 
| "http://www.iana.org/assignments/lang-subtags-templates/".

What next, tell their Web master what software they have
to use, or how to run backups ?  They told us that they
intend to reorganize their Web site, and everybody knows
that "cool" URIs are persistent.
 
> 5.1: does ietf-languages-announcements really exist,
> and does IANA really announce to it?

And WTH is a "self-subscribing list", asking IETF mail
experts what lists do with an existing Sender I got more
than three strictly incompatible answers from folks like
the 822 + email-arch author, 2822 author, MIME author,
and ASRG Chair.  The 2821 author noted another opinion
in the Last Called 2821bis.  

If IANA offers an atom feed I'd like that better than a
mailing list, and I don't any reason for a MUST about
this issue.

> The rest are editorial:
[...]
> 4.1: s/Sometimes there is a choice/There is always a choice/,
> which is much nearer the truth.

It's "almost always" then.  

> 4.4: The definition of "canonical form" here shouldn't
> have MUSTard in it; a definition is just a definition
> and shouldn't have any modal verbs.  

+1, there's an overall SHOULD in 4.4, and a MUST within
a SHOULD is confusing.  No MUSTard in definitions - if
"A" is ("B" or "C") by definition, then saying that "A"
MUST be "B" or "C" is redundant, saying that it SHOULD
be "B" or "C" would be erroneous, tertium non datur.

BTW, I vaguely recall that we didn't want chains:

| Note: In rare cases, the mapped value will also have
| a Preferred-Value.

If a subtag Y gets a new Preferred-Value Z, then all X
with Preferred-Value Y should be updated to say Z.

IMO a clear case where getting it right in the registry
once is better than asking obscure implementations to
follow chained mappings.  Let alone erroneous cycles,
such cycles could be related to "un-deprecated" codes. 

> Private use subtags, like all other subtags, MUST 
> conform to the format and content constraints in the
> ABNF.  They have no meaning outside the private
> agreement between the parties that intend to use or
> exchange language tags that employ them, and so are
> are simply useless for information exchange without
> prior arrangement.

Delete the whole paragraph, if folks don't know what
"private" means then I'm pretty sure that they don't
_want_ to know what it means, and adding text doesn't
help.  Your wording is already shorter than the draft,
but I think it's still too convoluted.    

> For some applications, this additional information 
> MAY be useful.

No 2119 MAY, actually it's obvious, otherwise there was
no valid reason to violate the two prior SHOULD NOT.

> 7: s/rendering engines sometimes use/rendering engines MAY use/.

s/MAY/are free to/ or "can", 4646bis isn't about rendering.

> 8 [record-jar]: add "chapter 5".

Not sure what you're talking about.  BTW, what does the
following paragraph in 5.1 try to say ?

| Future work on the Language Subtag Registry has been
| limited to inserting or replacing whole records 
| preformatted for IANA by the Language Subtag Reviewer
| as described in Section 3.3 of this document and archiving
| and making publically available the forwarded registration
| form.

Is that an attempt to kill the 4( ALPHA ) reservation ?

> My suggestions for invalid tags are xxx-Defg-HQ, 
> de-1996-1996, en-nedis, and ar-a-aaa-b-bbb-a-ccc.

The xxx-Defq-HQ isn't guaranteed to be invalid forever,
or did I miss a clue ?

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 8 Dec 2007 23:34:58 +0100

On Sat, Dec 08, 2007 at 06:47:13PM +0100,
 Frank Ellermann <[email-masked]> wrote 
 a message of 145 lines which said:

> to use, or how to run backups ?

You have some interesting points but this one, I cannot understand. Do
you mean we should *not* mandate a given URI? If so, I strongly
disagree, we need a stable URI and the best way to have it is to write
it down clearly in the RFC (of course, the IANA is welcome to tell us
that http://www.iana.org/assignments/templates/lang-subtags/ would be
better, if they prefer, but the important point is that it should be
written down and not modified afterwards).

This has nothing to do with the HTTP server they use because URI are
seen externally so they are important for users of the RFC (unlike the
backup policy, where only the result matters).

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 9 Dec 2007 00:22:39 +0100

Stephane Bortzmeyer wrote:
 
> Do you mean we should *not* mandate a given URI?

Yes.  

They have old Web pages, among them "numbers.html", and if 
I pick "L" (for language tags) I arrive at:

| Language Tags 
| Language Subtag Registry                          RFC4646 
|   Expert Review (Experts - Michael Everson and Doug Ewell) 
| Language Subtag Registry - Registration Templates RFC4646
|   These are the Registration Templates only. 
[... and more for the old 3066 registry ...]

They also have new pages below http://beta.iana.org, with
http://www.iana.org/assignments/lang-subtags-forms/index.html
(broken link, maybe they forgot to run a checklink, or they
 intend to create a new overview page for the new site later)

We better don't try a micromanagement of their Web pages in
4646bis.

> If so, I strongly disagree, we need a stable URI and the
> best way to have it is to write it down clearly in the RFC

I'd be pissed if they move the collected templates around,
but I wouldn't go so far to say this in an RFC.  

> the important point is that it should be written down and
> not modified afterwards

Written down on their matrix page, or in 4646bis ?  I'd hate
it if the URL in the RFC is broken, I'd hate it if they move
pages around, and I hate it that the beta-link doesn't work.

 Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 9 Dec 2007 00:57:51 -0500

> I consider a "MUST" while talking with IANA as rude.

What, after they just botched updating the File-Date record?  Give me
a break.

> both plausible and would cause havoc.

It has been ignored in the past and it has created havoc.

> expert are idiots ?

Idiots, no; prone to careless mistakes, definitely.  People are not
protocol engines.

> It's "almost always" then.  

Can you think of a counterexample?  (Hint: It requires a language with
no language distinctions, script distinctions, or variant distinctions.)

> BTW, I vaguely recall that we didn't want chains:

You didn't want them, you mean.  Everyone else had no trouble with them.

> Not sure what you're talking about.  

The bibliographic entry for [record-jar] is incomplete.

> Is that an attempt to kill the 4( ALPHA ) reservation ?

Of course not.  It means that under *this* (future) RFC there won't
be any.  BCP 47 can always be revised by issuing a new RFC.

> The xxx-Defq-HQ isn't guaranteed to be invalid forever,

There are four reasons for invalidity, expressed by the four examples.
One is inherently temporal (unknown subtag); the others are eternal.

-- 
John Cowan   [email-masked]    http://ccil.org/~cowan
I come from under the hill, and under the hills and over the hills my paths
led. And through the air. I am he that walks unseen.  I am the clue-finder,
the web-cutter, the stinging fly. I was chosen for the lucky number.  --Bilbo

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 9 Dec 2007 10:36:10 +0100

> What, after they just botched updating the File-Date
> record?  Give me a break.

<br class="for-john" clear="all" />  Do you think they
will be more careful when we're rude in 4646bis ?

Don't try this approach with me, it would backfire ;-)

>> Can we please at least consider that neither IANA 
>> nor expert are idiots ?
 
> Idiots, no; prone to careless mistakes, definitely.
> People are not protocol engines.

Full metal jacket, they're also not Marines following orders.

>>> /There is always a choice/, which is much nearer the truth.
 
> Can you think of a counterexample?  (Hint: It requires a
> language with no language distinctions, script distinctions,
> or variant distinctions.)

Yes, I had i-default in mind, but noting why I think that
there is no choice by definition would be an essay.  And
I was too lazy to check if any other i-whatever is left
(= not deprecated).

> You didn't want them, you mean.  Everyone else had no

Maybe.  It's a plausible source of unnecessary trouble,
see "prone to careless mistakes" above, that also hits
implementors and other registry users.

> Of course not.  It means that under *this* (future) RFC
> there won't be any.  BCP 47 can always be revised by 
> issuing a new RFC.

Good.  A pointless statement apparently, of course it's
not possible to modify a published RFC 4646bis, why do we
tell IANA this ?  IANA is familiar with the concept "RFC".

 Frank

---

From: Martin Duerst <[email-masked]>
Date: Tue, 11 Dec 2007 19:00:04 +0900

>will be more careful when we're rude in 4646bis ?

I concur with Frank that MUSTard in the IANA section
serves no purpose.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John Cowan <[email-masked]>
Date: Tue, 11 Dec 2007 10:17:22 -0500

> I concur with Frank that MUSTard in the IANA section

We have plenty of MUSTard in the LSR section, and in sections
describing the desired actions of people who submit forms for review.
Registration is a very complicated protocol with lots of human parts
as well as computers, and the human parts are the more important parts.
IANA is just one of those, neither better nor worse than the rest.

-- 
John Cowan      <[email-masked]>       http://www.ccil.org/~cowan
                Charles li reis, nostre emperesdre magnes,
                Set anz totz pleinz ad ested in Espagnes.

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 11 Dec 2007 07:46:13 -0800

+1

On Dec 11, 2007 7:17 AM, John Cowan <[email-masked]> wrote:

> John Cowan      <[email-masked]>       http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>

-- 
Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Dec 2007 17:16:03 +0100

On Tue, Dec 11, 2007 at 07:00:04PM +0900,
 Martin Duerst <[email-masked]> wrote 
 a message of 28 lines which said:

> I concur with Frank that MUSTard in the IANA section serves no
> purpose.

The purpose is to be sure that a *minimum* set of services is
provided. This is based on practical experience with IANA (such as the
archiving-of-forms issue). The IANA, through David Conrad, made very
clear that they already have a lot of work and were not eager to
maintain things where they were not explicitely asked to do so. When
queried about UTF-8 in the registry, for intance, IANA said basically
"what you want, but please write it down clearly".

[This mandate also helps IANA when they report to their higher
management layers.]

We defer to IANA to provide more services (such as the fact that their
Web server honors If-Modified-Since, which is very convenient when you
want to access the registry periodically, although it is not and
probably should no be mandated by the RFC), if they can/want.

And we rely on common sense and good engineering practices for things
such as backups :-)

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Dec 2007 18:16:36 +0100

> "what you want, but please write it down clearly".

Yes, but MUSTard isn't an essential ingredience of
clarity in IANA considerations.  s/MUST/is asked to/
or similar is also clear, an uppercase MUST sounds
like "requested and required".  They're no servants
just because they offer a service.

 Frank

---

From: Martin Duerst <[email-masked]>
Date: Wed, 12 Dec 2007 10:42:39 +0900

It has been well known in the IETF that the IANA favors clear
instructions that don't require any judgement. But as Frank
explains below, clear instructions can be given without
MUSTard, and that's the way it has been done for IANA
until now. IANA will follow these instructions carefully
even without MUSTs. Of course they will occasionally make
a mistake, because they are humans. Who doesn't. But the
addition of MUSTs doesn't change that at all.

Regards,   Martin.

---

From: John Cowan <[email-masked]>
Date: Tue, 11 Dec 2007 21:38:46 -0500

> addition of MUSTs doesn't change that at all.

Currently they are in.  If you want them out, propose text.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
Economists were put on this planet to make astrologers look good.
        --Leo McGarry

---

From: John Cowan <[email-masked]>
Date: Fri, 14 Dec 2007 15:58:42 -0500

Scripsi:

> which is in a separate posting.  

Only a few of these changes made it in to -11 either.

[This one is reworded]

Appendix B: divide final section into "Some Invalid Tags" and "Some
Ill-Formed Tags".  My suggestions for invalid tags are xxx-Defg-HQ,
en-nedis, (which may become valid at some future time), de-1996-1996, and
ar-a-aaa-b-bbb-a-ccc.  My suggestions for ill-formed tags are de-419-DE,
en-nuspelling, a-de, and perhaps a few more.