Subject: Re: [Ltru] Status of RFC 4645bis

From: Martin Hosken <[email-masked]>
Date: Wed, 21 Mar 2007 13:30:01 +0700

Dear Doug,
> Since posting draft-ietf-ltru-4645bis-02, the only comments I've
> received about the draft or its proposed contents (other than the hex
> NCRs, which are an RFC 4646bis issue) were from Debbie, who mentioned
> some minor wording changes that I'm waiting for specifics on.
>
> Does this mean everyone loves the draft and feels it's about ready to
> go?  The ISO 639-3 folks have been updating their data files in
> response to the issues I raised, and apparently the standard is ready
> to be published, possibly by the end of this month, so I'd like to
> prepare a draft-03 that would be ready for WG Last Call.  Please send
> any comments.

OK I'll take a go (I couldn't find bis-02 only bis-01 so I'll talk about
that). My main point is that there are lots of suppress scripts missing.
Here are a few that spring out at me:

ko -> Hang

This is a biggy I would suspect. The following I'm not so sure about.

bm -> Latn
bo -> Tibt (?)
br -> Latn
ee -> Latn
fy -> Latn
gd -> Latn
ha -> Latn
ig -> Latn

Hmm I'll stop there. I wonder if it might be helpful to put some kind of
comment into the registry to say either that the decision has been made
that this language has no suppress script (because more than one is
used) or that no decision has been made as to whether this language has
a suppress script or not until they've all been decided on.

Yours,
Martin

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 21 Mar 2007 07:24:43 -0700

Martin Hosken <martin underscore hosken at sil dot org> wrote:

> OK I'll take a go (I couldn't find bis-02 only bis-01 so I'll talk 
> about that).

You're right, -01 is the version most recently submitted.

> My main point is that there are lots of suppress scripts missing.

There is a problem in general with Suppress-Script, but I contend it is 
a problem best discussed in the main process document (RFC 4646bis) and 
not in the document that delivers the Registry and outlines the rules 
for creating it (RFC 4645bis).

The problem, as you state and as Frank Ellermann has stated roughly 
4,646 times, is that by providing such a field, users will expect it to 
be correctly and authoritatively populated all of the time.  This is 
something ietf-languages has (IMHO) neither the time nor the expertise 
to do.  Instead, the field is present only for a sampling of languages 
for which an "overwhelmingly used" script could be determined with 
little or no controversy.  Proposals to add others are welcome at 
ietf-languages.

The gap between expectation and reality here is one of the reasons I 
opposed Suppress-Script in the first place.

> This is a biggy I would suspect.

I thought so too, for a long time, and studied this a year ago to try to 
prove it.  I read books, scanned newspapers, and talked to native Korean 
speakers.  What I found was that, although Hangul is by far the most 
common script for writing Korean (maybe even "overwhelmingly"), there is 
noticeable use of hanja is certain contexts: scientific works, personal 
names, newpaper headlines (to resolve ambiguities), and a few others. 
There is also an important tradition that hanja is part of the Korean 
cultural experience, so that even if Hangul is overwhelmingly used, the 
"controversy" factor applies here.  I went in firmly believing that this 
Suppress-Script should be added, and came away believing it should not, 
which I think is significant.

> The following I'm not so sure about.
>
> bm -> Latn
> ...

See above.  The correct place to propose these is ietf-languages.

> Hmm I'll stop there. I wonder if it might be helpful to put some kind 
> of comment into the registry to say either that the decision has been 
> made that this language has no suppress script (because more than one 
> is used) or that no decision has been made as to whether this language 
> has a suppress script or not until they've all been decided on.

Again, I believe the place for such a comment is in RFC 4646bis.  There 
is no provision in the syntax of the Registry to add file-level 
comments, though it was suggested during LTRU 1.0.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Mar 2007 17:50:44 +0100

Doug Ewell wrote:
 
> There is a problem in general with Suppress-Script, but I contend
> it is a problem best discussed in the main process document (RFC
> 4646bis) and not in the document that delivers the Registry and
> outlines the rules for creating it (RFC 4645bis).

Depends, if we decide to do some bulk update (again) 4645bis should
state how that was done.

> the field is present only for a sampling of languages for which an
> "overwhelmingly used" script could be determined with little or no
> controversy.

The "overhelmingly used" is its purpose for compatibility with older
or naive applications.
 
>> I wonder if it might be helpful to put some kind of comment into
>> the registry to say either that the decision has been made that
>> this language has no suppress script (because more than one is 
>> used) or that no decision has been made as to whether this language
 
> Again, I believe the place for such a comment is in RFC 4646bis.

In theory we could assign a meaning to empty Suppress-Script fields.

> There is no provision in the syntax of the Registry to add file-level

I think Martin's idea was in the direction of per record comments,
an "empty" Suppress-Script field could mean "intentionally void".

Frank

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 21 Mar 2007 11:20:39 -0700

Hi,

<broken record on>
The fundamental problem is NOT the "Suppress-Script" kludge.

The fundamental problem is that Script tags were unwisely
allowed into language tags at all - they will continue to
make for surprising results to real users for the indefinite
future at a thoroughly dubious gain in functionality.
<broken record off>

We've wrestled in the printing industry quite a bit with
how to cope with script subtags - and the clear concensus
is that we'll ban their use entirely in printing protocols.
We have a perfectly good pre-existing separate metadata
element for specifying script - print spoolers will simply
silently delete script subtags from received language tags.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Frank Ellermann [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 11:51 AM
To: [email-masked]
Subject: [Ltru] Suppress-Script (was: Re: Status of RFC 4645bis)

 

Frank

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.16/729 - Release Date: 3/21/2007 7:52 AM

---

From: John Cowan <[email-masked]>
Date: Wed, 21 Mar 2007 14:35:23 -0400

> comments, though it was suggested during LTRU 1.0.

The comment can be an ordinary one at the subtag level.  For example,
since we know that az is multi-script, we could add a Comment: field to
it saying "Comment:  Multi-script language, no Suppress-Script possible."
That makes it a matter for ietf-languages.

-- 
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            [email-masked]
    I'd use DTDs                        http://www.ccil.org/~cowan
    If they had local trees --
I think I best switch to RELAX NG.

---

From: Addison Phillips <[email-masked]>
Date: Wed, 21 Mar 2007 11:39:40 -0700

> That makes it a matter for ietf-languages.

Ugh.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Mar 2007 19:58:12 +0100

> silently delete script subtags from received language tags.

Probably that's what JohnK meant in the RFC 4646 "Last Call"
when he asked about "profiles".  Your application would be a
"profile" where script subtags (and in theory maybe also all
script related extensions or variants like "fonipa") are just
not used (or officially forbidden).

I've no problem with that approach, but I don't think that
we'll need prose in 4646bis how to formulate or even register
such profiles, "4646 tags without script subtags" is clear.

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Mar 2007 15:08:22 -0800

Hi -

> From: "McDonald, Ira" <[email-masked]>
> To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 21, 2007 10:20 AM
> Subject: RE: [Ltru] Suppress-Script (was: Re: Status of RFC 4645bis)
...
...

Printing wasn't ever one of the use cases for script subtags, as far
as I can recall.  Script subtags are much more relevant for searching / 
filtering.  I'm actually a bit surprised that a print spooler would even
need the script in metadata.  After all, the code points are distinct
anyway.

Randy

---

From: John Cowan <[email-masked]>
Date: Wed, 21 Mar 2007 18:53:28 -0400

> need the script in metadata.  After all, the code points are distinct

FWIU, it's a matter of making sure that the printer has the correct fonts
without having to read through the entire document.

-- 
Why are well-meaning Westerners so concerned that   John Cowan
the opening of a Colonel Sanders in Beijing means   [email-masked]
the end of Chinese culture? [...]  We have had      http://www.ccil.org/~cowan
Chinese restaurants in America for over a century,
and it hasn't made us Chinese.  On the contrary,
we obliged the Chinese to invent chop suey.            --Marshall Sahlins

---

From: Martin Hosken <[email-masked]>
Date: Thu, 22 Mar 2007 09:49:41 +0700

Dear Frank,

For some inexplicable reason, I didn't receive Doug's response that you
are responding to :(

> an "empty" Suppress-Script field could mean "intentionally void".

Yes, I was thinking of some per record information however it may be
encoded.

Yours,
Martin

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 22 Mar 2007 10:22:10 -0700

Hi,

John's got it just right - print spoolers and print
devices examine required resources for print jobs
at the time of job submission - NOT just at the time
of job execution, which may be minutes or hours later.

Jobs are rejected for resource conflicts (in this case
a font that doesn't cover the necessary characters)
at time of job submission, as a best practice.

Metadata about required scripts (note the plural please)
is important for user satisfaction when using shared
network printers - which are often considerably more
expensive than high-end UNIX workstations.  

Cheers,
- Ira

-----Original Message-----
From: John Cowan [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 5:53 PM
To: Randy Presuhn
Cc: [email-masked]
Subject: Re: [Ltru] Suppress-Script (was: Re: Status of RFC 4645bis)

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 3/22/2007 7:44 AM

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Mar 2007 21:24:14 +0100

Martin Hosken wrote:

> I didn't receive Doug's response that you are responding to :(

With all those weird spam filters you never know...  Some pages
with URLs of the two LTRU list archives I'm aware of:

<http://dir.gmane.org/gmane.ietf.ltru> (HTTP, NNTP, search, ...).
<http://tools.ietf.org/wg/ltru> (WG charter, drafts, list, ...)

Frank

P.S. to Stephane, maybe add GMaNe to <http://ltru.generic-nic.net/>