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

["Frank Ellermann" <[e-mail]>]

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 [e-mail] 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.  
> Point 2, s/SHOULD be/are/.  Point 3, /MUST be/are/.
> Point 4, same as 3.

+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



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