Subject: [Ltru] Re: Non-Latin-1 Description fields in RFC 4645bis

From: "Doug Ewell" <[email-masked]>
Date: Thu, 6 Dec 2007 22:26:28 -0800

When thinking about how to define "the Latin script" for purposes of 
meeting the requirement in RFC 4646bis, section 3.1.4, it might be 
useful to consider why we have such a requirement in the first place.

We have generally copied Description fields for language, script, and 
region subtags from the respective ISO standard.  The various ISO MA's 
and RA's generally do not go overboard in character repertoire -- in 
particular, ISO 639-3/RA uses ordinary ASCII punctuation in place of 
true click letters -- but in this case they have seen fit to use 
"Māhārāṣṭri Prākrit" as a language name.  (I don't know what, if 
anything, the plain-ASCII equivalent "Maharastri Prakrit" means; I hope 
it's something I can say in public.)  We have committed ourselves to 
using the names from the ISO standards.  This issue mainly concerns the 
variant subtags.

Many of the fields in the Registry are intended for some type of 
automated processing, but the Description is really meant for human 
consumption.  Software certainly isn't going to do much with it, except 
display it.  Therefore, the Description field ought to be designed with 
human usability in mind.

While the names of languages, writing systems, countries, etc. could 
obviously be written in a huge variety of scripts, most humans 
(professional translators and linguists aside) are unlikely to be able 
to read more than two or three scripts, so it makes sense to impose a 
limit to help ensure scrutability.  Because of the nature of the rest of 
the Registry, some familiarity with the Latin script is more or less 
assumed.  Consequently, we imposed a requirement that every subtag have 
at least one Latin-script description.

There is no written language on earth that uses all of the letters of 
the Latin script, for any reasonable definition of "Latin script" (i.e. 
more than just ASCII).  Nevertheless, a reader can generally recognize 
Latin-script letters that are not part of that reader's alphabet.  For 
example, a Francophone should be able to recognize n-tilde (ñ) as a 
letter belonging to the broader "Latin script" even though it is not in 
the narrower "French alphabet."

Technical limits should not be seen as the primary concern.  The problem 
of limited font coverage, as explained months ago to CE Whitehead, is a 
temporary one that will not last forever.  Programs and operating 
systems are being localized to more and more languages, requiring more 
comprehensive font coverage, and rendering engines are becoming smart 
enough to substitute glyphs from alternative fonts instead of displaying 
square boxes.  On the other hand, an LTRU policy that restricts "the 
Latin script" to an artificial subset is something that will last until 
some future LTRU comes around to change it.

I suggest we adopt a liberal definition of "the Latin script," 
preferably one based on Unicode Standard Annex #24, "Script Names," 
rather than a narrow definition based on legacy character sets or 
subsets, keyboard layouts, or font coverage.

These are my opinions; yours may differ.

--
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: Fri, 7 Dec 2007 15:20:30 +0100

Doug Ewell wrote:

> some familiarity with the Latin script is more or less assumed.

IBTD, "might help" is a different description of the situation.

> There is no written language on earth that uses all of the
> letters of the Latin script, for any reasonable definition of
> "Latin script" (i.e. more than just ASCII).

With Maori you don't need an exception for US-ASCII.  The only
other "reasonable" definitions I'm aware of are MES-1, Latin-1,
Latin-9, and windows-1252.  Not the TUS definition, that's far
too theoretical.

> Nevertheless, a reader can generally recognize Latin-script 
> letters that are not part of that reader's alphabet.

The odd squares representing "unsupported glyph" are not Latin,
they are identical for all unsupported characters ("eating" at
least all combining code points to reduce the noise, I hope)

> Technical limits should not be seen as the primary concern.

There's an "I" and an "E" in "IETF".  Any protocol limited to
Latin-1 (instead of ASCII) after RFC 2277 turned out to be a
huge mistake.

> The problem of limited font coverage, as explained months ago
> to CE Whitehead, is a temporary one that will not last forever.

It will last forever, old devices might die, cheap devices with
limited capabilities won't.  A cell phone in Thailand has to
focus its efforts on Thai, it can't afford to handle u+02BB.

And the W2K on my box is no Thai cell phone, like CE Whitehead's
Win98, like my old OS/2 Warp.  I could check if u+02BB belongs
to the OS/2 glyph list, and I can guarantee that this list will
never be "upgraded", OS/2 is a historic 32bits OS not more
actively developped.  We don't need to talk about "PC DOS 7",
ancient Minix / Linux distributions, or similar platforms, but
anything used on mobile devices matters.

> On the other hand, an LTRU policy that restricts "the Latin 
> script" to an artificial subset is something that will last
> until some future LTRU comes around to change it.

My proposal was to pull the "Latin REQUIRED" as utter dubious.
Limitations to some "reasonable" subset (i.e. without u+02BB)
would be shaky, unless they are very radical (windows-1252 or
less).

 Frank