[Suppress-Script] Initial list of 300 languages

[Peter Constable]

> 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 definition
of
> the over-the-wire datatype 'naturalLanguage'.  And that definition
ONLY
> describes language tags (in the running text) as language codes
followed
> 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
codes.

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
NOT
> 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 publishing
a
> 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 management
> 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