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

"Frank Ellermann" <nobody@xyzzy.claranet.de> Sat, 08 December 2007 17:48 UTC

Return-path: <ltru-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J13nB-00072Y-Vj; Sat, 08 Dec 2007 12:48:45 -0500
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1J13nA-00071T-CL for ltru-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 12:48:44 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J13nA-00071L-2a for ltru@lists.ietf.org; Sat, 08 Dec 2007 12:48:44 -0500
Received: from main.gmane.org ([] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J13n7-0001eY-TV for ltru@lists.ietf.org; Sat, 08 Dec 2007 12:48:44 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J13kX-0003CP-SJ for ltru@lists.ietf.org; Sat, 08 Dec 2007 17:46:02 +0000
Received: from c-180-160-62.hh.dial.de.ignite.net ([]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ltru@lists.ietf.org>; Sat, 08 Dec 2007 17:46:01 +0000
Received: from nobody by c-180-160-62.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ltru@lists.ietf.org>; Sat, 08 Dec 2007 17:46:01 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: ltru@lists.ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sat, 08 Dec 2007 18:47:13 +0100
Organization: <http://purl.net/xyzzy>
Lines: 138
Message-ID: <fjel72$d7k$1@ger.gmane.org>
References: <20071207213756.GC3346@mercury.ccil.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-180-160-62.hh.dial.de.ignite.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
X-Spam-Score: -0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Subject: [Ltru] Re: Review of 4646bis-10, sections 3.5 to App. B
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

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 iana@iana.org 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 ?


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 ?


Ltru mailing list