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 Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.