Subject: [Ltru] Re: proto-draft-10

From: "Doug Ewell" <[email-masked]>
Date: Mon, 3 Dec 2007 21:03:21 -0800

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> I have posted a version of draft-10 to inter-locale this morning. It 
> includes my proposed edits to remove extlang from standardization.

I will try to post a draft-4645bis-03 in the next few days that matches 
this proto-draft: no extlangs, Macrolanguage field that adheres strictly 
to 639-3, exceptionally reserved 3166 codes.

Since we're still debating the last two topics, it looks like these 
won't be the WGLC drafts either (sigh, coming up on a year behind), but 
they're a step closer.

--
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 3 Dec 2007 21:57:02 -0800

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.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 4 Dec 2007 08:54:18 +0100

> revisited over and over again.

Yes.  

Of course it also helps to look into the draft from time to time, I now saw
that  there are no biannual expert reappointments, good riddance.  I had
already visions of bothering NomCom with this business, or  copying
the recall procedure into 4646bis. 

>> It still contains "Latin transliterations of descriptions", without saying 
>> what Latin is,
 
> Do we need to provide a definition of the Latin script?

My definition is simple:  MES-1, optionally plus a few glyphs used on a
"popular" platform.  What's your definition, Latin-1 ?

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

Okay.  So what does the new MUSTard in the draft ?  Is it about the
variants or "registered languages", and why would anybody want say 
some fonipa transliteration in addition to the description(s) offered by
the requester ?  What's special with "Latn" in a broad Unicode sense,
why no Kore, Jpan, or Brai ?  For RFC 4646 we made sure that we 
have _no_ prejudice for Latn, and permit (in theory) all code points.

> We simply need to make sure we don't register 
> "Description: Тарашкевіца"

You hit an example that I can read, therefore I recall that the review
list managed this registration without a new MUST.

> Hopefully the advent of the UTF-8 Registry will put that to an end.

Apart from causing havoc for some users UTF-8 is still Unicode, and
we had that already in RFC 4646.  BTW, some weeks ago you said
that XML is not all.  With the advent of "ooXML" (valid or otherwise)
I'm confident that hex. NCRs will soon work everywhere.

> change this.  I wonder why you would call out Addison for not changing 

My list contained only one point wrt consensus, the disputed territories.
It was a summary of my objections + rationale.

> ground if you wish.

Will do.  Actually not 31, it's 35 for  5*8( ALPHA ) registered languages.
 
>> 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.
 
> un-deprecate a subtag was a stability promise.

IIRC we discussed cases of splits later re-uniting again for RFC 4646,
e.g. a new incarnation of YU, or CS.  And I thought that we made sure 
that this will work as everybody would expect it.

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

The "most perverse tag" has two variants.  With fonipa or fonupa it's
in theory three, or even four if a pervert manages to use fonipa and
fonupa simultaneously.

Just an example, for 4646 we discussed generic north south westx
eastx and similar cases arriving at SHOULD NOT, after fonipa and
company I'm ready for MUST NOT.
 
> 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.

With a MUST NOT for generic variants folks might manage it.   If
more cases like fonipa + fonupa are identified maybe it will result
in the first extension.   Arguably better than more generic variants,
each extension can have its own rules.  It's hard to decide if 1996
and fonupa in the same tag could make sense or not, and what 
the best order should be.

 Frank

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 4 Dec 2007 11:18:46 +0100

> 3166 codes?  I'm not even asking any more for my position to 
> be heard; I just want to know what the decision is.

Just to voice my opinion on this:

I don't much mind adding *ALL* of the "exceptionally reserved" codes,
but then it should be *ALL* of them (in particular including "UK",
as deprecated with a preferred value, which currently is strangely
excluded).

	/kent k