PMP Mail Archive: Re: PMP> Defect report in Printer MIB v2 - Localization

PMP Mail Archive: Re: PMP> Defect report in Printer MIB v2 - Localization

Re: PMP> Defect report in Printer MIB v2 - Localization

JK Martin (jkm@underscore.com)
Thu, 17 Apr 1997 11:28:43 -0400 (EDT)

Ira,

Perhaps you've just opened Pandora's Box with this issue, hopefully not.

Regarding this section of your message:

> The client software team I work with here at Xerox has recently been
> meeting with some of our colleagues from Fuji Xerox (Japan). They noted
> that the following original Printer MIB v1 (RFC 1759) text is STILL
> present in 'draft-ietf-printmib-mib-info-01.txt' in section 2.2.1
> 'General Printer':
>
> "Localization is only performed on those strings in the MIB that
> are explicitly marked as being localized. All other character
> strings are returned in ASCII."
>
> Fortunately the Printer MIB specified the 'non-localized' strings as the
> base ASN.1 type 'OCTET STRING' and not the dubious IETF SMIv2 type
> 'DisplayString' (explicitly constrained to 'NVT ASCII'). Nonetheless,
> ASCII is a singularly useless character set in the Japanese domestic
> market and in most of FX's Asia/Pacific markets for descriptive
> information. Useful character sets include ISO 2022-JP and Unicode
> UCS-2.
>
> Our Xerox client team and our Fuji Xerox colleagues would like to
> request that this defect be repaired by changing the above text to say:
>
> "Localization is only performed on those strings in the MIB that
> are explicitly marked as being localized. All other character
> strings are returned in the fixed locale (established at 'device
> install' time) of this network printer or network print server
> (by means outside the scope of this Printer MIB)."

I personally don't have a problem with the general notion of allowing
for different locales in place of ASCII (as stated in the MIB), HOWEVER,
this should definitely require some sort of MIB object that states what
which locale has been defined for this situation.

If not, then how can a mgmt app handle such strings without risking the
chance of seriously breaking itself?

...jay

----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------