I think your on to something here. Your idea basically is:
Lets use the existing XxxDescription objects to hold any localized
information about the other objects in the group, including
language changes, not just code set.
Lets keep most of the other objects as US-ASCII.
Lets change a few objects to being localized.
ISSUE 1: Add a prtGeneralPrinterDescription object?
We don't have a PrinterDescription object that could be localized
with information about the Printer, Vendor, Model, etc, like we do for
each sub-unit. Should we add such an object to the General group?
So we need to agree for each object that was OCTET STRING whether it
is subject to localization or not. If not, then it is fixed as US-ASCII.
Some of the objects even list standardized text values (like OIDs).
For these the application is presumed to do the localization,
if any localization is done:
R/W prtInputMediaType "stationery", "transparency", ...
R/W prtInputMediaColor "other", "unknown", "white", "pink"
R prtMarkerColorantValue "other", "unknown", "white", "red", ...
Correct? We might even add a 'Usage' statement along those lines.
ISSUE 2: Add an object to hold the written code set or not?
The current localized strings are all read-only (except for the
prtConsoleDisplayBufferText object).
ALL of the new ones are read-write, so some implementations
may let a management app write them.
In Nashua, Ang Caruso and Ira updated their proposal to having
a separate object that specified the coded character set for
objects that were writeable. Should we do that here too?
Or do we want to require that the management app write in
the same character set as the current localiztion specified
in the MIB so that we would NOT need another object for the
application to write the CodeSet enum into.
I suggest that we use TCs to distinguish between localized and
non-localized objects.
So how about TC's like:
PrtEnglishASCIIStringTC - for objects that are US-ASCII always
(like OIDs). The application does
any localization if it wants to.
PrtAgentLocalizedStringTC - the current localized objects
according to prtGeneralCurrentLocalization
and prtConsoleCurrentLocalization
PrtApplicationLocalizedStringTC - the new potentially read-write
objects.
ISSUE 3: Should we have a separate TC for console localization?
I've extracted all objects of type OCTET STRING from the MIB draft 02.
I've put 'localized' in front of the ones whose DESCRIPTIONs say are
localized according to prtGeneralCurrentLocalization and 'console loc.' in
front of the ones whose DESCRIPTIONs say are localized by
prtConsoleLocalization.
I've added "new loc." for the objects that are being proposed as
newly localizable.
NOTE: All of the "new loc." are read-write.
I've put RW for read-write objects and R for read-only objects.
NOTE that an implementation is NOT required to make any of the
RW objects writeable.
RW new loc. prtGeneralCurrentOperator PrtApplicationLocalizedStringTC
RW new loc. prtGeneralServicePerson PrtApplicationLocalizedStringTC
RW prtGeneralSerialNumber PrtEnglishASCIIStringTC
R localized prtCoverDescription PrtAgentLocalizedStringTC
The following two objects are proposed to be changed to DisplayString
since the ISO 639 and 3166standards specify what the values shall be using
Latin letters only:
R prtLocalizationLanguage PrtEnglishASCIIStringTC
R prtLocalizationCountry PrtEnglishASCIIStringTC
RW new loc. prtInputMediaName PrtApplicationLocalizedStringTC
RW new loc. prtInputName PrtApplicationLocalizedStringTC
R prtInputVendorName PrtEnglishASCIIStringTC
R prtInputModel PrtEnglishASCIIStringTC
R prtInputVersion PrtEnglishASCIIStringTC
R prtInputSerialNumber PrtEnglishASCIIStringTC
R localized prtInputDescription PrtAgentLocalizedStringTC
RW prtInputMediaType PrtEnglishASCIIStringTC
RW prtInputMediaColor PrtEnglishASCIIStringTC
RW new loc. prtOutputName PrtApplicationLocalizedStringTC
R prtOutputVendorName PrtEnglishASCIIStringTC
R prtOutputModel PrtEnglishASCIIStringTC
R prtOutputVersion PrtEnglishASCIIStringTC
R prtOutputSerialNumber PrtEnglishASCIIStringTC
R localized prtOutputDescription PrtAgentLocalizedStringTC
R localized prtMarkerSuppliesDescription PrtAgentLocalizedStringTC
R prtMarkerColorantValue PrtEnglishASCIIStringTC
R localized prtMediaPathDescription PrtAgentLocalizedStringTC
R prtChannelProtocolVersion PrtEnglishASCIIStringTC
R prtInterpreterLangLevel PrtEnglishASCIIStringTC
R prtInterpreterLangVersion PrtEnglishASCIIStringTC
R localized prtInterpreterDescription PrtAgentLocalizedStringTC
R prtInterpreterVersion PrtEnglishASCIIStringTC
RW console loc. prtConsoleDisplayBufferText PrtAgentLocalizedStringTC??
R console loc. prtConsoleDescription PrtAgentLocalizedStringTC?
R localized prtAlertDescription PrtAgentLocalizedStringTC
This proposal would add to the above list:
RW new loc. prtGeneralPrinterName PrtApplicationLocalizedStringTC
David Kellerman's revised prtChannelInformation also adds
but we should keep it as OCTET STRING, since its code
set varies depending on the enum value:
R prtChannelInformation OCTET STRING
A couple of comments below:
At 14:47 07/25/97 PDT, David_Kellerman@nls.com wrote:
>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.)
Though the localization is dropped when the object is written. So this
needs some more discussion about writing these objects.
objects are actually implmeented as read-write:
RW new loc. prtGeneralCurrentOperator PrtApplicationLocalizedStringTC
RW new loc. prtGeneralServicePerson PrtApplicationLocalizedStringTC
RW new loc. prtInputMediaName PrtApplicationLocalizedStringTC
RW new loc. prtInputName PrtApplicationLocalizedStringTC
RW new loc. prtOutputName PrtApplicationLocalizedStringTC
RW new loc. prtGeneralPrinterName (new) PrtApplicationLocalizedStringTC
>
>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
>
>