[Ltru] Frank's comments (was: Re: proto-draft-10)

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

> I also note that it still contains the fantasy island codes,
> Chairs, please produce the consensus for this modification
> in -09.

I'd really like the chairs to declare consensus on a number of topics, 
because otherwise this happens: old decisions and non-decisions are 
revisited over and over again.

Chairs: *do* we have consensus for adding the exceptionally reserved 
3166 codes?  I'm not even asking any more for my position to be heard; I 
just want to know what the decision is.

> It still contains "Latin transliterations of descriptions",
> without saying what Latin is,

Do we need to provide a definition of the Latin script?

> or why the subtag review list
> should create "transliterations" when the source standard
> didn't bother for whatever reasons.

The source (ISO) standards will always provide Latin-script 
descriptions.  It's the independently registered subtags that need to 
have this specified.  We simply need to make sure we don't register 
"Description: Тарашкевіца" without providing a suitable Latin-script 
equivalent.

Personally I'm satisfied with the existing wording, because it does not 
go any farther than 4646 in recommending ASCII-only transcriptions. 
That was a popular thing to request a year or so ago.  Hopefully the 
advent of the UTF-8 Registry will put that to an end.

> It still contains the unused 5*8ALPHA "registered languages"
> instead of reviving the good tradition of i-whatever tags
> for this in the times of 639-3 likely unnecessary loophole.

I don't believe there is any popular sympathy, let alone consensus, to 
change this.  I wonder why you would call out Addison for not changing 
it.

> As a consequence of not removing the extlang syntax it still
> contains the answer 42 instead of a much more MIME friendly
> limit 30 (or 31 for a 639-6 language).

You guys can beat the maximum-theoretical-tag-length issue into the 
ground if you wish.  I'll just be happy if implementers would stop 
getting confused in the presence of a script subtag.

> Allegedly it's unclear that a subtag can be "undrepecated"
> if say (in theory) ISO 3166-1 revives FX.  Or rather Doug
> said that it's clearly not allowed, IMO that would be a bug.

I think it's extremely clear in 4646.  Whether that's a bug is another 
question, one I think deserves serious discussion.  But we should be 
careful about breaking our own stability promises, and refusing to 
un-deprecate a subtag was a stability promise.

> It still allows "generic" variants without prefix, they're
> known to be cumbersome (fonipa + fonupa).

I don't see how they're "cumbersome."  They serve the purpose they were 
meant to serve: too many languages can be, and are, written in IPA to 
make it worthwhile to enumerate them all.

In any case, like removing the registered languages, I haven't seen no 
popular support for changing this.  (Another case where a declaration of 
consensus would be useful.)

Later:

> There are no registered languages, so what's the point of
> allowing the full set of BCP 47 features for them ?  For
> cases like i-default I don't miss any default-Hant-fonupa
> opportunity.

You're probably more likely to see a 5- to 8-letter registered language 
subtag before you see an extension.  The barriers to creating an 
extension are just too high.

> As explained earlier  5*8( ALPHA )  limits implementation
> freedom if there would be ever a variant and a language
> using the same subtag.

John Cowan replied to this:

> Rules for the first subtag don't apply to later subtags, period.
> The fact that you'd like them all to be unique doesn't make it so.

Exactly; they belong to different namespaces.

Or, to provide a wholly unnecessary analogy:  I work in an open office 
environment (no petitions, please; I'm talking physical offices), and as 
it turns out, I'm the only Doug in my building.  This makes certain 
petty operations a bit simpler: my co-workers can talk unambiguously 
about "Doug" without using, or even knowing, my surname, and when 
someone calls out "Doug" I can look up right away, confident in the 
knowledge that they mean me.  But this is no justification for my 
company to refuse to hire other, well-qualified Dougs.

--
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@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru