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

From: "Doug Ewell" <[email-masked]>
Date: Fri, 7 Dec 2007 10:38:16 -0800

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

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

I'm assuming the letters are rendered correctly, of course, not as 
boxes.

"Eating" (i.e. not displaying) all combining characters following a 
non-displayed base letter is probably non-conformant, but as this isn't 
the Unicode list, I won't pursue that.

>> Technical limits should not be seen as the primary concern.
>
> There's an "I" and an "E" in "IETF".

"The field 'Description' contains a description of the tag or subtag in 
the record....  The 'Description' field is used for identification 
purposes and SHOULD NOT be taken to represent the actual native name of 
the language or variation or to be in any particular language."

This is neither "Internet" nor "engineering."  It is about an 
informative text field for humans to read and understand.

> Any protocol limited to Latin-1 (instead of ASCII) after RFC 2277 
> turned out to be a huge mistake.

I'm not the one proposing to limit anything to Latin-1.

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

Is the Language Subtag Registry meant to be read on cell phone browsers?

WG members, you have Frank's take on this matter and my take on this 
matter.  Please discuss it and come up with some proposed wording for 
RFC 4646bis for which the co-chairs can declare rough consensus.

--
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: "Mark Davis" <[email-masked]>
Date: Fri, 7 Dec 2007 11:50:04 -0800

I favor Doug's position: "Latin" meaning characters with the Latin script
(or Common or Inherited) according to the Unicode properties.

Mark

On Dec 7, 2007 10:38 AM, Doug Ewell <[email-masked]> wrote:

> http://home.roadrunner.com/~dewell <http://home.roadrunner.com/%7Edewell>

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Fri, 07 Dec 2007 13:38:37 -0800

Actually, I favor leaving the text alone. It currently doesn't define 
what "Latin script" means, on the assumption that the LSR and 
ietf-languages (at registration time) or Doug (at 4645bis time) can 
figure it out. We can discuss what it means for 4645bis purposes, but we 
already had consensus on this for 4646, let alone now.

It might turn out that this paragraph actually means "US-ASCII7" in 
practice. Note also that we allow for multiple description fields, in 
case we want multiple representations.

Addison

Mark Davis wrote:
> I favor Doug's position: "Latin" meaning characters with the Latin 
> script (or Common or Inherited) according to the Unicode properties.
> 
> Mark
> 
> 
> On Dec 7, 2007 10:38 AM, Doug Ewell < [email-masked] 
> <mailto:[email-masked]>> wrote:
> 

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 7 Dec 2007 17:14:39 -0800

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

> figure it out. We can discuss what it means for 4645bis purposes, but 
> we already had consensus on this for 4646, let alone now.

I think that's been our problem.  Rather than figure it out at run-time, 
we have a big long debate over it at run-time, every time, and it 
overshadows the main debate over the proposed subtag, and we end up with 
inconsistent results anyway.  Remember the discussion over the variant 
subtag 'baku1926' and how much time we spent haggling over 
transliterations of the Comments field; Michael wanted to have (and got) 
a duplicate ASCII rendition of every non-ASCII name for that alphabet.

> practice.

It better not.  In the current Registry, we have 15 Description fields 
with at least one non-ASCII letter.  Most of these are the sole 
description.  In 4645bis we will have about 430.

> Note also that we allow for multiple description fields, in case we 
> want multiple representations.

That has given us

Description: Ge&#x2BB;ez
Description: Ge'ez

and

Description: Hanunoo (Hanun&#xF3;o)

and I'm not convinced that this is the best thing for the Registry.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 8 Dec 2007 15:44:35 +0100

Addison Phillips wrote:

> Actually, I favor leaving the text alone.

The MUST would force the language review list to outsmart the
source standards if they happen to provide no "Latin de jour"
description.

It also forces the language review list to invent some kind
of "Latin transliteration" for variants, and I'm pretty sure
that this ends up as some <jfc> Anglosaxon </jfc> gibberish,
more or less pointless for the rest of the world.

> We can discuss what it means for 4645bis purposes

The TUS concept of "Latin" means nothing for registry users.
A bunch of "unsupported glyph" squares, worse than visible
Cyril.  I've no idea why one source uses u+02BB which is
annotated as Hawaian in TUS, but used for Ethiopian in the
registry.  I only care to know that it is u+02BB, and the
old NCR format managed this directly, for the new UTF-8
hell I'd need a decoder (in that case Doug did it for me)

> It might turn out that this paragraph actually means 
> "US-ASCII7" in practice.

Unlike Latin "US-ASCII" is at least a clearly defined set,
no moving target always ahead of really deployed fonts.

I'd be much more impressed if at least one description
for "registered languages" and variants MUST be in the
native language used by the corresponding community,
not only <jfc> Anglosaxon </jfc> "Latin".

 Frank