Subject: [Ltru] Re: Frank's comments

From: "Doug Ewell" <[email-masked]>
Date: Wed, 5 Dec 2007 07:43:35 -0800

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

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

MES-1 is completely irrelevant to me from the standpoint of deciding 
whether a letter is in the Latin script.  U+0114 LATIN CAPITAL LETTER E 
WITH BREVE is not in MES-1.  Neither are most of the Vietnamese Latin 
letters with hook and horn and what not.

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

How about this: I will put together a brief analysis of the letters used 
in Description fields in the proposed 4645bis Registry, which is coming 
soon now that Addison has submitted draft-4646bis-10, and we can talk 
about whether those all meet the "Latin" requirement as each of us 
understands it.  Then, we can talk about where to draw the line.

I can tell you that two of the new language subtags are "Ardhamāgadhī 
Prākrit" and "Māhārāṣṭri Prākrit".  Not all of those letters with macron 
or dot below will display on a Windows 95 box.

>> As I said, I think this issue [un-deprecation] 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... :-)

To play devil's advocate: WG members, what are the disadvantages of 
allowing a deprecated subtag to become un-deprecated, if it is 
resurrected in the underlying ISO standard?

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

Yes, you could.  And it's easy to imagine exactly that scenario; Dr. 
Steenwijk might want to use IPA to demonstrate how Lipovaz Resian is 
pronounced.  So... where is the problem?

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

I think the requirement to host and moderate a mailing list is another 
major hurdle to extensions.

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

I would have gladly written the RFC, though I think the mailing list 
would have been out of my reach.

--
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 18:32:57 +0100

Doug Ewell wrote:
 
> MES-1 is completely irrelevant to me from the standpoint of
> deciding whether a letter is in the Latin script.

For me it's relevant because I trust that the fonts I use (or
readers of my articles use) can handle it.

> U+0114 LATIN CAPITAL LETTER E WITH BREVE is not in MES-1.

http://purl.net/net/ucode/0114 lists some languages where
that's used, not exactly what I'd miss in a "multilingual
European subset" created by CEN.  Similarly Vietnamese,
I offer to tune my Latin "definition" down to Latin-1 :-)

> How about this: I will put together a brief analysis
> of the letters used in Description fields in the proposed
> 4645bis Registry, which is coming soon now that Addison
> has submitted draft-4646bis-10, and we can talk about
> whether those all meet the "Latin" requirement as each
> of us understands it.  Then, we can talk about where to
> draw the line.

Okay, let's see some interesting "Latin" click characters. 

> "Māhārāṣṭri Prākrit".  Not all of those letters with macron 

On W2K I can't see two char.s Mahara??ri.  And I think I use
"New Courier" (whatever that is, OS/2 had a real "Courier")
or "Lucida Console" (one serving as a "proportional" font :-)

> To play devil's advocate: WG members, what are the disadvantages
> of allowing a deprecated subtag to become un-deprecated, if it
> is resurrected in the underlying ISO standard?

+1 (seconding the question, Stéphane's point about FX)
 
>> And if it's about one of those Slovenian dialects you could arrive
>> at three variants.
 
> pronounced.  So... where is the problem?

With only two generic variants we arrived at a plausible longer "most
perverse tag", and we have two ways to sort three variants in the tag.
If other (unrelated) generic variants are registered it will be messy.

 [extensions] 
> I think the requirement to host and moderate a mailing list is 
> another major hurdle to extensions.

Oops, why should that be required ?  Depends on the extension, I think.

I've never tested it, but creating a Google or Yahoo group should be
simple, subscribe GMane to it, enjoy a clean interface with an archive,
news feed, NNTP, search, ...  Submit it to "other IETF lists" (toss a
coin for one of the two ADs who can handle "apps" lists), copy an IETF
NOTE WELL to the description, ready.  

Or ask another "hoster", Harald, Lisa, Paul, IASA (I've no idea how to
ask IASA, but AFAIK there are lists hosted directly by the IETF), etc.

> would have been out of my reach.

You could decree that proposed additions to the IPA + UPA registry are 
discussed on the language subtag list (unless Michael tells you to get
lost).  Or you decree that only transliteration schemes mentioned in
TUS can be registered, and IANA has to check it.  Or use the Unicode
list for this business.  Or decree that it's a closed extension with
exactly two values.  You could also let the IESG appoint an expert,
and while they are at it they have to create a list.  Even IANA has
its own mailing lists (but better don't try this at the moment, they 
need to fix their archiving software first).

 Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 06 Dec 2007 17:07:59 +0900

>> 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... :-)
>
>To play devil's advocate: WG members, what are the disadvantages of allowing a deprecated subtag to become un-deprecated, if it is resurrected in the underlying ISO standard?

Technically, I can see a difference between the case where there is
Preferred-Value: information, and the case where there is no such
value. Looking through the current registry, such a rule would
give reasonable results in most cases that I can envision, but
not necessarily in all of them (e.g. YU goes to CS).

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Kent Karlsson" <[email-masked]>
Date: Thu, 6 Dec 2007 22:01:37 +0100

> Okay, let's see some interesting "Latin" click characters. 

Extracts from draft-ietf-ltru-4645bis-02.txt:

Description: !O!ung
Description: !X&#xF3;&#xF5;	the "!" here should (IIUC) really be U+01C3, LATIN LETTER RETROFLEX CLICK

Description: Ju/'hoan
Description: N/u
Description: /Gwi
Description: /Xam			the "/" here should (IIUC) really be U+01C0, LATIN LETTER DENTAL CLICK

Description: Hai//om
Description: //Ani
Description: //Gana
Description: //Xegwi		the "//" here should (IIUC) really be U+01C1, LATIN LETTER LATERAL CLICK

Description: =/Hua		the "=/" here should (IIUC) really be U+01C2, LATIN LETTER ALVEOLAR CLICK

Description: =/Kx'au//'ein	...appears to have three instances of ASCII fallbacks for letters...

		/kent k