For Current Operator and Service Person it can be argued that these could be
entered via the op panel, especially for larger printers. I suppose same is
true for media and just about anything else, given enough keys on your console
(i.e. like some of IBM's printers which have an entire keyboard and monitor as
the console). We chose not to belabor these issues in developing the printer
MIB and supported the MIB's original leaning toward facilitating lower cost
embedded machines with limited op panel capabilities as these were viewed as
the majority of the network printing market from a volume basis.
Come to think of it, since these may be entered via the OpPanel, I can see,
now, shy HP chose prtConsoleLocalization for their defaults.
The more I think about this whole localization issue the more I'm convinced
the major mistake made initially was in defining more than one localization
(general and console) to begin with!
Harry Lewis - IBM Printing Systems
----------- Forwarded by Harry Lewis/Boulder/IBM on 07/25/97 04:36 PM ---------
pmp-owner@pwg.org
07/25/97 04:31 PM
Please respond to pmp-owner@pwg.org @ internet
To: pmp@pwg.org @ internet
cc:
Subject: PMP> another look at alternatives 1-2, reasons less is bette
I'll apologize in advance, because I'm flip-flopping on localization.
But that's what results from trying to think on my feet.
There's a problem common to Tom's proposals and my UTF-8 proposal. The
MIB already has defined a particular structure for localization, based
on the localization table. If you look carefully at this structure and
the choices of which objects are localized and which are not, it makes a
lot of sense. I think all these new proposals launch off into new
territory, and fail to take into account the existing logic of the MIB.
What I'm going to suggest is that we make a few adjustments to objects
to bring them into line with the current localization strategy, and
nothing more.
To see why this might make sense, I think you need to distinguish
between "user interface" objects, and those that are "opaque" -- coded
values that are programmatic in nature and not intended for direct user
consumption. As a particular example of this, the MIB uses ASCII
strings this way in many cases; if it were an ISO standard, it would
probably use OIDs instead, and there would be a lot less confusion.
It's important that these opaque objects not be localized, so that the
coded values don't get lost. The choice of ASCII for their encoding
is relatively arbitrary.
As an example, consider the objects that describe an input sub-unit:
prtInputName
prtInputVendorName
prtInputModel
prtInputVersion
prtSerialNumber
prtInputDescription
The prtInputDescription object is localized, the others are not. In
fact, prtInputDescription is a nice fat string (0..255) big enough to
hold a localized description that summarizes all the other objects --
they need never see the light of day. This looks intentional to me, and
it seems like a reasonable approach.
Now, if you are inclined to go along with this general approach, there
are some loose ends to clean up -- objects that look like they really
should be localized to be consistent, but were overlooked. Here are the
ones I see:
prtGeneralCurrentOperator
prtGeneralServicePerson
Seems like these have to be localized; can't see any reason not.
prtInputMediaName
Right now there is no localized object that summarizes input
medium attributes. This seems like the obvious choice.
prtInputName
prtOutputName
I'm not sure about these. prtInputDescription and
prtOutputDescription already provide localized descriptions for
the sub-units. Jay says these fields are present to allow a
manager to assign locally meaningful names to units (e.g.
"Dave's input tray"), and if this is the case they should be
localized. (I guess HP already localizes prtOutputName.)
In preparing this list, I looked at each of the OCTET STRING objects,
and asked "is this user interface data?" In particular, if there was
already a localized object that could be used to present the same
information at the user interface, the answer was "no."
:: David Kellerman Northlake Software 503-228-3383
:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662