You are assuming that there is only ONE management application using
the Printer MIB! What if there are several, one writing values, and
the others reading values. (I don't want to even think about more than
one writing values). Wouldn't it help if the management app that is
writing values was doing so in the localization specified in the MIB?
I suggest that that localization would be prtGeneralLocaliztion,
not prtConsoleLocalization. prtConsoleLocalization is for the
localization of what a human sees at the console which could be different
from what management apps "see". That is why we made two localization objects
originally in the MIB: prgGeneralLocalization and prtConsoleLocalization.
prtConsoleLocalization OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of the prtLocalizationIndex corresponding to
the language, country, and character set to be used for the
console. This localization applies both to the actual display
on the console as well as the encoding of these console
objects in management operations."
::= { prtGeneralEntry 10 }
Another objective of the Printer MIB was to allow a Printer to not have
any real OpPanel, and a management app could perform the duty of a console.
There is an example when there could be more than one management app,
one being the equivalent of the console, and the other managing the printer.
>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.
If the values are entered by the OpPanel, then I would think that the
values should still be localized by prtGeneralCurrentLocalization, rather
than prtConsoleLocalization, but that the values of both localization
objects would likely be the same.
>
>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!
No, see above. The two localization objects are for distinct purposes.
Also prtGeneralCurrentLocalization is read-only, while the
prtConsoleLocalization is read-write, so the some implementations
the app can actually change it (probably for those implementations
that have little or not OpPanel and so depend on a management app
to effectively be the console.
But for implementations that don't need a management app as a console
(the ones that implement prtConsoleLocalization as read-only), the
values of the two can be the same (and when changed locally by the OpPanel
would be automatically changed at the same time by the implementation).
>
>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
>
>
>
>