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 at nls.com Portland, Oregon fax 503-228-5662