I think that we have agreed to change prtLocalizationLanguage and
prtLocalizationCountry from OCTET STRING to DisplayString. Are there
others that we should constrain to be US-ASCII by making the same change?
Such changes are not changes in the actual ASN.1 protocol and do not
change what goes on the wire; such a change only constrains the code positions
and character set to be US-ASCII in code positions 32 to 126.
I'd like to suggest that we include:
RW prtGeneralSerialNumber OCTET STRING,
R prtInputSerialNumber OCTET STRING,
R prtOutputSerialNumber OCTET STRING,
in the list of objects to change from OCTET STRING to DisplayString.
That would constrain serial numbers to decimal digits and other
Latin characters and symbols, such as '-'. Ok?
Serial numbers are something that an application program might be comparing
with a list of, so constraing them would help applications to not have
to worry about characters outside US-ASCII.
Are there any others that we should change?
Tom
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
localization' in front of the ones whose DESCRIPTIONs say are localized by
prtConsoleLocalization:
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 prtGeneralCurrentOperator OCTET STRING,
RW prtGeneralServicePerson OCTET STRING,
RW prtGeneralSerialNumber OCTET STRING,
R localized prtCoverDescription OCTET STRING,
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 OCTET STRING,
R prtLocalizationCountry OCTET STRING,
RW prtInputMediaName OCTET STRING,
RW prtInputName OCTET STRING,
R prtInputVendorName OCTET STRING,
R prtInputModel OCTET STRING,
R prtInputVersion OCTET STRING,
R prtInputSerialNumber OCTET STRING,
R localized prtInputDescription OCTET STRING,
RW prtInputMediaType OCTET STRING,
RW prtInputMediaColor OCTET STRING,
RW prtOutputName OCTET STRING,
R prtOutputVendorName OCTET STRING,
R prtOutputModel OCTET STRING,
R prtOutputVersion OCTET STRING,
R prtOutputSerialNumber OCTET STRING,
R localized prtOutputDescription OCTET STRING,
R localized prtMarkerSuppliesDescription OCTET STRING,
R prtMarkerColorantValue OCTET STRING,
R localized prtMediaPathDescription OCTET STRING,
R prtChannelProtocolVersion OCTET STRING,
R prtInterpreterLangLevel OCTET STRING,
R prtInterpreterLangVersion OCTET STRING,
R localized prtInterpreterDescription OCTET STRING,
R prtInterpreterVersion OCTET STRING,
RW console localization prtConsoleDisplayBufferText OCTET STRING
R console localization prtConsoleDescription OCTET STRING
R localized prtAlertDescription OCTET STRING,
This proposal would add to the above list:
RW prtGeneralPrinterName OCTET STRING
NOTE: David Kellerman's revised prtChannelInformation changes the
syntax of prtChannelInformation from DisplayString to OCTET STRING, but
his revised DESCRIPTION states that the coded character set after the
"=" sign is determined by the value of the enum. Therefore,
prtChannelInformation is NOT affected by the code set specified
with alternative 4 or 5 and should NOT be in the list of objects
affected.:
R prtChannelInformation OCTET STRING