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

["Doug Ewell" <[e-mail]>]

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

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

One of the big objections that people had to switching to UTF-8 was that 
the non-ASCII characters might get munged in transit.  This passage was 
added specifically to calm those nerves.

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

People criticized the fact that 4646 didn't specify where the completed 
forms could be found.

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

We didn't want chains, but even more so, we didn't want to break the 
stability of the Preferred-Value field.

Regarding cycles, I think if you want to rely on IANA and the LSR to get 
things right rather than adding MUSTard, you surely ought to give them 
(or at least me, as Co-Designated Expert) credit for detecting and 
avoiding cycles.

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

This was added in direct response to fears expressed during LTRU 1.0 
(which I did not share) that people would abuse private subtags.

Most of the text in the draft is there for a reason, because the WG 
wanted it there or agreed to have it put there.  Addison and Mark (like 
me) are editors, not authors; our job is to write drafts that reflect 
the will of the group.  It's always fair to ask why something is there 
or how it got there, but the answer might well be "because everyone 
insisted on it N months or years ago."

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://home.roadrunner.com/~dewell
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ



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