Subject: [Ltru] Fw: Frank's comments

From: "Doug Ewell" <[email-masked]>
Date: Tue, 4 Dec 2007 20:54:46 -0800

(Resending this message, which apparently fell into a black hole)

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

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

Not at all.  If I thought it was unclear, I would probably use the 
Unicode (UAX #24) definition: all characters in the string have script 
value 'Latn' or 'Zyyy" (Common) or "Qaai' (Inherited).

The reloaded 4645bis Registry will contain some language subtags with 
only one Description field, which is not pure Latin-1.  These are things 
like a-with-macron and s-with-dot-below, for some Indian languages. 
This is still Latin.

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

Description fields are permitted in any imaginable script.  But one of 
the fields for a given subtag has to be in the Latin script.

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

Rules are better than relying on enlightened statesmen.

>>> 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.
>
> My list contained only one point wrt consensus, the disputed
> territories.  It was a summary of my objections + rationale.

I understand this.  What I don't understand is why you mentioned "it 
still contains the registered language subtags."  Of course it does; 
there was no agreement to change this.

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

As I said, I think this issue deserves serious discussion.  I don't 
recall it being discussed before.  But once we do reach a decision --  
preferably certified by a chair-declared consensus -- we should stick 
with it and not reopen the issue.

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

Tag content wisely.

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

'north' and 'south' and company, used generically, are not clearly 
defined.  Sometimes the concepts are clearly defined when used with a 
specific language, such as Armenian, but not in other cases.  How would 
one define "de-DE-north" and "de-DE-south"?

IPA and UPA are a completely different matter.  It is very clear when a 
non-trivial passage of text is written in IPA.

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

Don't forget, I argued for extensions for the IPA/UPA case.  The 
reaction was clear, from both the LTRU and ietf-languages lists: nobody 
wanted to see extensions used for this.

--
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: "Frank Ellermann" <[email-masked]>
Date: Wed, 5 Dec 2007 12:47:56 +0100

> This is still Latin.

I'm not sure if that actually is MES-1, let's assume it's not, then we have
two definitions of "Latin" by two participants, with an optional third based
on TUS 5.0 tables.  That's why I asked, "Latin" needs to be defined.  

E.g. the expert reviewer will think fonipa is perfect (guess, we can ask
Michael), while I'd think that anything not working on a box supporting
windows-1252 (among others) doesn't really help.

> But one of the fields for a given subtag has to be in the Latin script.

I don't exactly see why that "has to be", especially when "Latin" isn't
clearly defined.  I've no idea what the box where I write this actually
supports (the Cyril description was okay).

> Rules are better than relying on enlightened statesmen.

Just because 4646bis will say that he must read the rules doesn't
guarantee that he'll do it.  I could understand a SHOULD here, the
most disturbing part is the "MUST".

> As I said, I think this issue deserves serious discussion.  I don't recall it
> being discussed before.

Maybe we discussed the opposite, a union splitting again (DE breaking
up into "DE3" and DD again, recycling DD should be a no-brainer.  It's
ugly that DE3 is a proper subset of DE2 in this case, on the other hand
DE3 == DE1 as it was before the union.  All theoretical, of course... :-)

> Tag content wisely.

Picking fonipa when it really is fonipa would be wise.  And if it's about
one of those Slovenian dialects you could arrive at three variants.

> How would one define "de-DE-north" and "de-DE-south"?

If it's Bajuvarian using "south" if nothing better is available would be
tempting, I'm not arguing against generic variants because they are
anyway never usable.  

> IPA and UPA are a completely different matter.  It is very clear when 
> a non-trivial passage of text is written in IPA.

Likely I couldn't tell what's what, and would claim that whatever it is,
it's not proper Latin.  Somebody with a clue could decide that that's
bad enough to justify an explicit "Latn" subtag in addition to "fonipa".

> Don't forget, I argued for extensions for the IPA/UPA case.

Yeah, but writing an RFC isn't *that* easy, even if it's only about two
transliteration schemes.  Possibly more with a IANA registry, that's
why it's not trivial.

> The reaction was clear, from both the LTRU and ietf-languages lists:
> nobody wanted to see extensions used for this.

That's not how I recall it, *some* wanted no extension saying that it
confuses matching more than variants.  Most others simply didn't
volunteer to write a draft for an extension RFC while other solutions
like bothering ISO or registering generic variants exist(ed).

 Frank