[Ltru] Latin / "un-deprecation" / generic variants / extensions (was: Frank's comments)

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 
> or dot below will display on a Windows 95 box.

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.

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

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.

> I would have gladly written the RFC, though I think the mailing list 
> 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

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru