Yes, that's basically it. And my hope is that these "changes" actually
overlap with existing practice.
> 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?
Tom, are you trying to pull a fast one here? ;-) The MIB doesn't
contain this information now, localized or not. Aren't you supposed to
go get it from one of the other MIBs?
> 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.
Yes, the application should treat these as "coded" values and may choose
to present corresponding localized "user interface" values to the user.
> 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'm trying to keep from changing things! And I did notice that previous
localized objects were (with the one exception) read-only. I don't see
any reason to introduce a new localization category. Instead, adopt the
same approach as is already used for prtConsoleDisplayBufferText -- the
management application had better write a value consistent with the
setting of prtGeneralCurrentLocalization.
What do current implementations do with prtConsoleDisplayBufferText when
the management application changes prtConsoleLocalization? Leave it to
the application to correct any inconsistency, revert to a default value,
or what?
> 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.
How about just ASCIIString for the name?
> 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?
If you're going to switch to TCs for the localized objects, I liked
Ira's proposal more:
o PrtCurrentLocaleDisplayString for objects controlled by
prtGeneralCurrentLocalization,
o PrtConsoleLocaleDisplayString for objects controlled by
prtConsoleLocalization.
I don't see why you need to distinguish between the read-only and the
read-write strings with different TCs.
Also, if you do incorporate the TCs into the MIB (which Lloyd and Chris
have done once already), go ahead and remove the descriptive text that
serves the same purpose -- one way or the other, not both.
> 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.
My question for anyone who's made it this far in this message is: what
practical effect will this have on your existing agent or application
implementation? (I do respect Bob Pentacost's remarks that answering
this sort of question accurately is pretty costly.) For starters, maybe
just: is anything obviously going to break, and how serious is the
problem?
> 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 3166 standards 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.
>
> From the bake-off, how many of the newly proposed localized read-write
> 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
:: David Kellerman Northlake Software 503-228-3383
:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662