[Suppress-Script] Initial list of 300 languages

McDonald, Ira imcdonald at sharplabs.com
Thu Mar 16 06:48:39 CET 2006


I agree with Jon Hanna that IPP/1.0 (RFC 2566) and IPP/1.1 (RFC 2911)
were wrong not to mention tags of the form 'i-xxx' and others that could
legally be registered under RFC 1766 and later RFC 3066.  But there's
some history to be explained here that still haunts the printing

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.

Here's why.

All printing protocols talk to a logical print spooler or a physical
print device.  And every network print device shipped in the last decade
supports the single standard IETF Printer MIB v1 (RFC 1759) or its
backward-compatible successor Printer MIB v2 (RFC 3805).  When the
Printer MIB v1 was developed by the PWG (then a chartered IETF working
group), on the advice of our IETF appointed expert advisor, rows in the
'prtLocalizationTable' were defined as follows:

    PrtLocalizationEntry ::= SEQUENCE {
        prtLocalizationIndex                Integer32 (1..65535),
        prtLocalizationLanguage             OCTET STRING (SIZE(0..2)),
        prtLocalizationCountry              OCTET STRING (SIZE(0..2)),
        prtLocalizationCharacterSet         CodedCharSet

Note that maximum size of TWO characters for language and country codes.

The IETF Printer MIB v2 (RFC 3805) was finally published SEVEN YEARS
(and three IETF Applications Area Directors) after the technical content
was complete (thanks to the intervention of Bert Wijnen and Juergen
Schoenwalder).  I argued strongly that we should extend the length of
the two language and country code objects and ADD a new object called
'prtLocalizationLanguageTag' that would support 63 characters like the
IPP datatype, but no printer vendor supported me and no IETF community
reviewer seemed concerned to fix this problem.

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.

After the bitter experience of the Printer MIB v2 delay in the IETF
standards-track process, the PWG subsequently incorporated, became a
program of the IEEE-ISTO, and abandoned forever developing any IETF

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.

We now return you to your semantic web everywhere future...

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

More information about the Ietf-languages mailing list