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

JK Martin <jkm@underscore.com> Thu, 17 April 1997 15:37 UTC

Received: from cnri by ietf.org id aa10926; 17 Apr 97 11:37 EDT
Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa13179; 17 Apr 97 11:37 EDT
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21733 for <ietf-archive@cnri.reston.va.us>; Thu, 17 Apr 1997 11:33:07 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 17 Apr 1997 11:32:13 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21604 for pmp-outgoing; Thu, 17 Apr 1997 11:31:57 -0400 (EDT)
Date: Thu, 17 Apr 1997 11:28:43 -0400
From: JK Martin <jkm@underscore.com>
Message-Id: <199704171528.LAA17106@uscore.underscore.com>
To: imcdonal@eso.mc.xerox.com
Subject: Re: PMP> Defect report in Printer MIB v2 - Localization
Cc: pmp@pwg.org
X-Sun-Charset: US-ASCII
Sender: pmp-owner@pwg.org

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   --
----------------------------------------------------------------------