[Ltru] Ltru] Extensions in general (was: Re: Fwd: draft-davis-t-langtag-ext )

[CE Whitehead <[e-mail]>]

Hi.From: "Doug Ewell" <doug at ewellic.org>Date: Sun, 10 Jul 2011 09:31:55 -0600Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:>> I'm not sure that I see where the "overhead" is.  Can you elaborate?> The overhead would be in revising BCP 47 to change the extension mechanism or> add a new one.>> Keeping everything in one place/list has got to be easier for the end user. I>> still cannot see any real reason for taking this out of IETF other than>> BCP47 allows for it.I think cldr is a suitable place for localization data, and this is localization data, so I think cldr is fine (if they want to keep this info that's nice)> Having everything in one place is easier for the user (which is why I don't like scattering> the values for either -t- or -u- across multiple files), but there is a> reason. It's not just that "BCP47 allows for it." We who worked on BCP 47 > *wanted* it to allow for this, so that "well-regulated" individuals and> organizations that came up with new needs for BCP 47 could implement them in> a systematic way, and not force the LTRU group to go back and rewrite the RFC> again, at an expense of several years and much political and bureaucratic> strife, and probable scope creep like last time.> By creating an extension, nothing is being "taken out of" ietf-languages that> was already there, except to the extent that transliterations etc. have> heretofore been handled by registering variants (through ietf-languages) and> would now be handled via the -t- extension. That is an issue that needs to be> addressedâfor example, should ietf-languages deprecate existing variants like >'pinyin' if they become available via -t-? Users are supposed to be able to> ignore extensions if they don't understand them or choose not to, but they> are not supposed to ignore variants.This could be an issue -- I can see having a period where zh-pinyin-t-zh-hans would be valid and zh-pinyin would also be and both would be essentially equivalent, but I am not sure that everyone will be happy with this solution.  And I can understand that. Oh well.> I agree with Addison that the question of whether the extension mechanism is> a good one (including delegating the administration of the data to a third-> party organization) is separate from the question of whether transliterations> etc. should be an extension or not, or whether draft-davis-t-langtag-ext has> any particular issues. I suggest that everyone read RFC 5646, Section 3.7 and> decide whether they feel this draft satisfies it.I feel it does, although I cannot with 100% certainty say what the intent was of 3.7;but first 2.2.6:2.2.6 Item 4" 4.  Extension subtags MUST meet whatever requirements are set by the       document that defines their singleton prefix and whatever       requirements are provided by the maintaining authority.  Note       that there might not be a registry of these subtags and       validating processors are not required to validate extensions." {ME:  2.2.6 Item 4 seems to leave this up to the defining draft to define what is a valid subtag for the extension }2.2.6 Item A
"   8.  All subtags following the singleton and before another singleton
       are part of the extension.  Example: In the tag "fr-a-Latn", the
       subtag 'Latn' does not represent the script subtag 'Latn' defined
       in the IANA Language Subtag Registry.  Its meaning is defined by
       the extension 'a'."
{ME:  here I think some statement is needed in 2.1 of the draft that the registry subtags mean essentially what they do as defined in the registry -- although they indicate the "from" language when they follow -t.}And for 3.7:

"The maintaining or
   registering authority, including name, contact email, discussion list
   email, and URL location of the registry, MUST be indicated clearly in
   the RFC.  The RFC MUST specify or include each of the following:
. . .
" o  The specification and all subtags defined by the specification
      MUST follow the ABNF and other rules for the formation of tags and
      subtags as defined in this document.  In particular, it MUST
      specify that case is not significant and that subtags MUST NOT
      exceed eight characters in length.{ Mark's RFC has done this. }

   o  The specification MUST specify a canonical representation   o  The specification of valid subtags MUST be available over the
      Internet and at no cost."

{ It seems like the subtag registry mentioned in Mark's draft does all this . . . I can't find anything anywhere that says the registering authority for the extension has to register any subtags of its own; just an opinionfor what it's worth }

A few more comments:  I wish that following -t somewhere there could be a choice of options, tscrip (transcription), trlit (transliteration), or trlat (translation) but I know this is getting cumbersome.(There are of course many varied types of translations, some word-for-word with words only reordered as needed for grammar and annotated when there is a question about meaning, some not quite so literal, designed to capture the flavor, mood, created for different purposes, some technical, some literary; but the draft does allow for the registration of subtags valid after a field separator subtag together with the registration of additional field separator subtags and maybe this mechanism could handle such information if someone wanted to have such info specified.)I do agree with Ken and Dough that a zip file is a pain to access (I have not tried to yet on my mini) though I think cldr is the right place to keep this.Best,--C. E. [e-mail] > --
> Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell