Ira & Angelo,
Thanks for clearing up some of this for me. With your clarifications,
I've taken another look at the proposal and have some questions about
it (it seems that anytime someone looks closely at an area of the Printer
MIB, questions arise :-).
I'll start with Angelo's recent response and then go back to the original
proposal.
> ----------
>From: Caruso,Angelo[SMTP:Angelo_Caruso at wb.xerox.com]
> Sent: Wednesday, June 11, 1997 3:50 PM
> To: pmp at pwg.org> Subject: RE: PMP> Localization changes to Printer MIB
>> Bob,
>> > These are all new objects that don't change the functionality of the
> existing objects.
> > The change being proposed pulls out some of the current functionality of
> > prtGeneralCurrentLocalization and puts it in
> prtGeneralStaticLocalization. The
> > problem that I see this causing is what happens when a customer
> connects their new
> > printer and tries to manage it with their existing management
> software (we know that
> > customers tend to update their software much less frequently than
> they add printers).
> > If they try to set the new printer's localization, they will find
> that it is only partially
> > localized.
> >
> > This change breaks existing software; therefore, it needs more
> thought before it
> > goes into the Printer MIB.
>> I talked with Ira this afternoon and want to try and clarify this a
> little more. Ira's laptop just died so you won't see any mail from him
> for a few days. My understanding of Ira's proposal:
>> 1) All objects localized according to prtGeneralCurrentLocalization
> would continue to be localized according to that object (with their
> SYNTAX changed to PrtCurrentLocaleString for clarity).
> 2) All objects localized according to prtConsoleLocalization would
> continue to be localized according to that object (with their SYNTAX
> changed to PrtConsoleLocaleString for clarity).
> 3) Objects suitable for static localization (e.g. prtInputName) would
> be localized according to the new object prtGeneralStaticLocalization
> (with their SYNTAX changed to PrtStaticLocaleString for clarity).
> 4) Objects not suitable for localization (e.g. prtInputMediaName and
> prtLocalizationLanguage) would remain forever unlocalized (with their
> SYNTAX changed to PrtEnglishASCIIString for clarity).
We need a list of the objects that are going to have their SYNTAX
changed to PrtEnglishASCIIString.
>> Your statement above, "The change being proposed pulls out some of the
> current functionality of prtGeneralCurrentLocalization and puts it in
> prtGeneralStaticLocalization", is NOT what Ira is proposing. The new
> object prtGeneralStaticLocalization would apply ONLY to objects which
> are currently unlocalized. The prtGeneralCurrentLocalization object,
> which currently provides only a partial localization, would continue
> to provide exactly the same partial localization.
>> Thanks,
> Angelo
>>
And now, the original proposal.
> --------------------------------------------------
>> Add three new textual conventions:
> ----------------------------------
>> PrtCurrentLocaleDisplayString ::=3D TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "The type for human-readable (NOT binary) string objects:
> a) whose dynamic locale (language, country, code set) shall be
> indicated by the value of 'prtGeneralCurrentLocalization';
> b) whose value (when updated by an SNMP Set-Request) shall be
> interpreted in this locale by the management agent;
> c) whose value (when returned by an SNMP Get-Response) shall =
> be
> interpreted in this locale by the management station."
> REFERENCE
> "See: 'prtGeneralCurrentLocalization' in the General group
> of this Printer MIB."
> SYNTAX OCTET STRING
>> PrtConsoleLocaleDisplayString ::=3D TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "The type for human-readable (NOT binary) string objects:
> a) whose dynamic locale (language, country, code set) shall be
> indicated by the value of 'prtGeneralConsoleLocalization';
> b) whose value (when updated by an SNMP Set-Request) shall be
> interpreted in this locale by the management agent;
> c) whose value (when returned by an SNMP Get-Response) shall =
> be
> interpreted in this locale by the management station."
> REFERENCE
> "See: 'prtGeneralConsoleLocalization' in the General group
> of this Printer MIB."
> SYNTAX OCTET STRING
>> PrtStaticLocaleDisplayString ::=3D TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "The type for human-readable (NOT binary) string objects:
> a) whose static locale (language, country, code set) shall be
> indicated by the value of 'prtGeneralStaticLocalization';
> b) whose value (when updated by an SNMP Set-Request) shall be
> interpreted in this locale by the management agent;
> c) whose value (when returned by an SNMP Get-Response) shall =
> be
> interpreted in this locale by the management station."
> REFERENCE
> "See: 'prtGeneralStaticLocalization' in the General group
> of this Printer MIB."
> SYNTAX OCTET STRING
>> Update/Add to General group:
> ----------------------------
>> prtGeneralCurrentLocalization OBJECT-TYPE
> SYNTAX Integer32 (1..65535)
> MAX-ACCESS read-write -- write many, read many
> MIN-ACCESS read-only -- move to Conformance section
> STATUS current
> DESCIRPTION
> "The value of 'prtLocalizationIndex' corresponding to the
> language, country, and character set to be used when
> interpreting dynamically localized 'human-readable' string
> objects of type 'PrtCurrentLocaleDisplayString'. This object
> shall not apply to strings of 'PrtConsoleLocaleDisplayString'
> or 'PrtStaticLocaleDisplayString' type.
>> Usage: This object may be updated (repeatedly) during normal
> operation of this network printer or network print server."
> REFERENCE
> "See: 'prtGeneralConsoleLocalization' (console strings) and
> 'prtGeneralStaticLocalization' (static strings)
> objects in the General group of this Printer MIB."
> ::=3D { prtGeneralEntry 2 }
>> prtGeneralConsoleLocalization OBJECT-TYPE
> SYNTAX Integer32 (1..65535)
> MAX-ACCESS read-write -- write many, read many
> MIN-ACCESS read-only -- move to Conformance section
> STATUS current
> DESCIRPTION
> "The value of 'prtLocalizationIndex' corresponding to the
> language, country, and character set to be used when
> interpreting console localized 'human-readable' string
> objects of type 'PrtConsoleLocaleDisplayString'. This object
> shall not apply to strings of 'PrtCurrentLocaleDisplayString'
> or 'PrtStaticLocaleDisplayString' type.
>> Usage: This object may be updated (repeatedly) during normal
> operation of this network printer or network print server."
> REFERENCE
> "See: 'prtGeneralCurrentLocalization' (dynamic strings) and
> 'prtGeneralStaticLocalization' (static strings)
> objects in the General group of this Printer MIB."
> ::=3D { prtGeneralEntry 10 }
>> prtGeneralStaticLocalization OBJECT-TYPE
Is this object mandatory or optional?
> SYNTAX Integer32 (1..65535)
> MAX-ACCESS read-write -- write once, read many
> MIN-ACCESS read-only -- move to Conformance section
> STATUS current
> DESCIRPTION
> "The value of 'prtLocalizationIndex' corresponding to the
> language, country, and character set to be used when
> interpreting statically localized 'human-readable' string
> objects of type 'PrtStaticLocaleDisplayString'. This object
> shall not apply to strings of 'PrtCurrentLocaleDisplayString'
> or 'PrtStaticLocaleDisplayString' type.
>> Usage: This object may be updated (at most) once at 'device
> install' time for this network printer or network print =
> server."
I can't figure out if it is legal to update this object more than once ('may' and 'at most' are confusing). It seems to imply that it can be updated only once in the life of the printer.
It would also be good to specify that changing the value of this object will require the values of all the writable objects that are localized according to this one to be changed (or would they return to a default value?)
> REFERENCE
> "See: 'prtGeneralCurrentLocalization' (dynamic strings) and
> 'prtGeneralConsoleLocalization' (console strings)
> objects in the General group of this Printer MIB."
> ::=3D { prtGeneralEntry 20 }
>> Change the SYNTAX of these objects to 'PrtCurrentLocaleDisplayString':
> ----------------------------------------------------------------------
>> prtCoverDescription
> prtInputDescription
> prtOutputDescription
> prtMarkerSuppliesDescription
> prtMediaPathDescription
> prtInterpreterDescription
> prtAlertDescription
The above are all read-only objects, so this looks okay to me.
>> Change the SYNTAX of these objects to 'PrtConsoleLocaleDisplayString':
> ----------------------------------------------------------------------
>> prtConsoleDisplayBufferText
> prtConsoleDescription
If a management application writes a value to prtConsoleDisplayBufferText, it must be localized according to prtGeneralConsoleLocalization. If the value of prtGeneralConsoleLocalization is changed, the management application should rewrite the value according to the new localization. (Note: We must be willing to live with this since this isn't a new problem.)
>> Change the SYNTAX of these objects to 'PrtStaticLocaleDisplayString':
> ---------------------------------------------------------------------
>> prtGeneralCurrentOperator
> prtGeneralServicePerson
> prtGeneralAdminName
The above object is now prtGeneralPrinterName.
> prtGeneralSerialNumber
> prtLocalizationLanguage
> prtLocalizationCountry
> prtInputMediaName
> prtInputName
> prtInputVendorName
> prtInputModel
> prtInputVersion
> prtInputSerialNumber
> prtInputMediaType
> prtInputMediaColor
> prtOutputName
> prtOutputVendorName
> prtOutputModel
> prtOutputVersion
> prtOutputSerialNumber
> prtMarkerColorantValue
> prtChannelProtocolVersion
> prtInterpreterLangLevel
> prtInterpreterLangVersion
> prtInterpreterVersion
>
>From Ira's 6/11 message:
> At the 22 April PMP telecon, Randy mentioned that some
> strings are not suitable for re-localization. He is of
> course right - the mnemonics line 'US', 'EN', from ISO
> or IANA stds, the 'prtInputMediaName' (which needs to
> be a well-known set of strings, to be useful), the
> new 'prtChannelInformation' object (although NOT
> localizing it still gives a problem for a server name
> in a non-English environment or worse a non-8-bit
> environment).
>> So, how about FOUR textual conventions:
>> PrtCurrentLocaleString
> PrtConsoleLocaleString
> PrtStaticLocaleString
> PrtEnglishASCIILocaleString
By adding the fourth textual convention PrtEnglishASCIILocaleString, I assume some of the objects under the 'PrtStaticLocaleDisplayString' list above would be moved. prtLocalizationLanguage and prtInputMediaName have been mentioned explicitly, while prtLocalizationCountry has been implied. It's not immediately clear to me which objects should have their SYNTAX changed to PrtEnglishASCIILocaleString (prtInputSerialNumber and prtOutputSerialNumber seem to be candidates).
SUMMARY
The chronology of this proposal has been:
4/20 - Proposal posted by Ira.
4/22 - PMP phone conference; Randy was to review proposal and send recommendation.
6/6 - Lloyd re-posts the proposal asking for discussion (which, in PWG fashion, ensues).
6/10 - Ira adds a fourth textual convention to his original proposal.
I appreciate the problem that Ira is trying to fix. However, at this point in time the proposal is incomplete since the list of objects that would be changed for syntax type PrtEnglishASCIILocaleString is not available. This proposal causes many changes in the document which makes for many opportunities to break things unintentionally. We are trying to get the Printer MIB published and have already missed our deadlines. Let's quit trying to fix "one more thing" and get the document out.
Bob Pentecost
HP