[Suppress-Script] Initial list of 300 languages
imcdonald at sharplabs.com
Thu Mar 16 07:11:55 CET 2006
You kind of glossed the fact the PWG editors DID want a proper
language tag in Printer MIB v1 (RFC 1759), but were prevented
specifically by the miserable advice/guidance of the IETF
appointed WG expert advisor (who shall remain unnamed, but I'm
sick of printer vendors getting this bad rap).
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
email: imcdonald at sharplabs.com
> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Peter
> Sent: Thursday, March 16, 2006 1:07 AM
> To: ietf-languages at iana.org
> Subject: RE: [Suppress-Script] Initial list of 300 languages
> > From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> > bounces at alvestrand.no] On Behalf Of McDonald, Ira
> > Note that the passage I quoted from IPP/1.1 was the formal
> > the over-the-wire datatype 'naturalLanguage'. And that definition
> > describes language tags (in the running text) as language codes
> > by optional country codes. Period.
> It says
> "The 'naturalLanguage' attribute syntax is a standard identifier for a
> natural language and optionally a country. The values for this syntax
> type are defined by RFC 1766 [RFC1766]."
> Let's consider that a bit: either
> - the first clause is only a partial statement of the syntax and the
> second clause is the complete reference statement, or
> - the first clause is the complete reference statement of the
> syntax and
> the second clause is badly-stated clarification on how to interpret
> them, or
> - the two clauses are contradictory statements of the syntax.
> What you seem to be saying is that the second alternative applies.
> > Here's why...
> > Note that maximum size of TWO characters for language and country
> Ouch. Clearly not an implementation of RFC1766 but rather of something
> *like unto* RFC1766.
> > So, to this day, a physical print device can ONLY display localized
> > objects (i.e., the names of each physical subunit like
> Input Tray) via
> > two-character language codes and two-character country codes. It is
> > possible to describe or use a three-character language code
> in Printer
> > MIB v1/v2.
> So, there will simply be scenarios in which content will not
> print with
> appropriate font choices. There is nothing we can do about the reality
> that there will be content tagged "fil" or "az-Arab".
> > Therefore, there are nearly insurmountable barriers to ever
> > Printer MIB v3 and fixing this problem.
> > And that is the reason that I was distressed to see the addition of
> > infixed script subtags in RFC3066bis. Because all printer
> > applications (both from print vendors and NMS vendors)
> depend entirely
> > on the Printer MIB v1/v2.
> Their back-compat story was broken even without infixed script subtags
> simply because of their choice to implement 0*2alpha "-"
> 0*2alpha rather
> than RFC1766 and the unavoidable reality of the need for alpha-3
> language IDs from 639-2. And they've been broken for around
> seven years
> ever since RFC3066 was published; 3066bis didn't really change that.
> All we can do wrt Suppress-Script is some damage control for
> high-importance cases such as en-US and fr-FR.
> Peter Constable
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
More information about the Ietf-languages