______________________________ Reply Separator _________________________________
Subject: PMP> URGENT: SYNTHESIS proposal on definition of OCTET STRIN
Author: Tom Hastings <hastings@cp10.es.xerox.com> at Internet
Date: 7/23/97 3:39 AM
Please indicate your approval/disapproval of this SYNTHESIS proposal
by noon PDT today (Wednesday, 7/23).
I hope that this proposal continues to be acceptable to those that liked
yesterday's proposal and is intended to satisfy the Area Director and those
who disaproved of yesterday's proposal on the grounds that there wasn't
a way to determine the coded character set.
We've had a real good *technical* discussion on the e-mail list yesterday
about the proposal to relax the restriction on the MIB objects defined
as OCTET STRING from being only ASCII to being any char set that has
US-ASCII in code positions 32-126. Thanks everyone for the hard work.
The people in favor of the proposal are in favor of it because it
describes existing (and planned) implementations
(including the HP 5si and Lexmark printers)
and it allows implementors to follow the IAB recommendation that UTF-8
be the default character set (which has US-ASCII in code positions 32-126).
The people against the proposal have picked up the flaw that it does not
follow the Area Directors admonition that it must be possible to
determine the code set being used by objects in the MIB.
Fortunately, most of the data will be using code positions 32-126, so there
isn't any ambiguity for those code positions. It is for code positions
128-255 for which we have no means in the MIB to indicate what the code
set is. For example, the code set could be UTF-8, ISO 8859-1 (Latin1),
HP Roman8, JIS X0208 (Japanese Kanji two byte set), GB2312 (PRC Chinese
Kanji two byte set), since these code sets are all supersets of US-ASCII.
Rather than abandoning all hope, lets follow the Area Director's advice
and provide the means to specify the code set for those OCTET STRING objects
in question (those that are not already indicated as being subject to the
localization mechanism in the Printer MIB). I suggest as a SYNTHESIS proposal
which should make all the commentors happy and follows the Area Director's
advice (at the cost of a single object):
1. Add a simple object to the General table that specifies the static
code set for the OCTET STRING objects in question (those that are not
already indicated as being subject to the localization mechanism in the
Printer MIB)
2. The object has MAX-ACCESS of read-write
3. The object has MIN-ACCESS of read-only
4. Lets just add the object to the MANDATORY General Group, rather than
making the object OPTIONAL and putting it in a separate group and
specifying that US-ASCII SHALL be used when the object is omitted.
5. The default value for the object is specified as UTF-8 (enum 106)
to follow the IAB recommendation.
6. Lets call the new object: prtGeneralStaticCodeSet
The complete text of this SYNTHESIS proposal affects:
1. page 14 (as before) to broaden the restriction of OCTET STRING from
just ASCII to coded character sets that are a superset of US-ASCII,
but extended to mention the new prtGeneralStaticCodeSet object.
2. page 75, change prtGeneralPrinterName from DisplayString to
OCTET STRING (SIZE(0..63)) [or a different size if we agree to one]
3. page 68, add prtGeneralStaticCodeSet to the prtGeneralTable
4. page 76, to add the prtGeneralStaticCodeSet object DESCCRIPTION.
5. page 137 to add MIN-ACCESS read-only
6. page 143 to add the prtGeneralStaticCodeSet object to the prtGeneralGroup
7. page 172 to add a proper Bibliography section
The seven changes are:
1. Page 14, change the paragraph about OCTET STRING objects from:
Localization is only performed on those strings in the MIB that
are explicitly marked as being localized. All other character
strings are returned in ASCII.
to:
Localization is only performed on those strings in the MIB
represented by objects with syntax 'OCTET STRING' that
are explicitly marked as being localized. The agent SHALL return
all other OCTET STRING objects as coded character sets in which code
positions 0-127 (decimal) SHALL be US-ASCII [US-ASCII] and the remaining
code positions, 128-255, if used, SHALL be any other coded character
set structured according to ISO 2022 [ISO 2022] in 8-bit environments,
including multi-byte sets.. Examples of coded character sets which
meet this criteria are: US-ASCII, ISO 646:1991 IRV [ISO 646],
ISO 8859-1 (Latin-1) [ISO 8859], any ISO 8859-n, HP Roman8,
Windows Default 8-bit set, UTF-8 [UTF-8], US-ASCII plus
JIS X0208-1990 Japanese [JIS X0208], US-ASCII plus GB2312-1980
PRC Chinese [GB2312].
Examples of coded character sets which do not meet this criteria are:
national 7-bit sets (except US ASCII), EBCDIC, and ISO 10646 (Unicode)
[ISO 10646]. In order to represent Unicode characters, use UTF-8
[UTF-8].
Control codes (code positions 0-31 and 127) SHALL NOT be used unless
specifically specified in the DESCRIPTION of the object.
In order for an application to be able to determine the coded
character set returned by agents for objects of type OCTET STRING,
(in order to be able to interpret code positions 128 to 255, since
code positions 0 to 126 SHALL be US-ASCII), the
prtGeneralStaticCodeSet object identifies the coded character set
in use. This object is updated (infrequently) by system
administrators when they install, upgrade, or move the managed
system (to another physical and/or network location) or is
fixed by the implementation.
2. Page 75: Change the syntax of the MIB object: 'prtGeneralPrinterName'
from 'DisplayString' which is restricted to US-ASCII to
'OCTET STRING (SIZE(0..63))'
so that other sets may be used in code positions 128 to 255 and so that
no control codes will be used (and so a lower and upperbound length
are specified).
3. Page 68, add prtGeneralStaticCodeSet to the table by replacing:
prtAlertAllEvents Counter32 -- Alert
}
with:
prtAlertAllEvents Counter32, -- Alert
prtGeneralStaticCodeSet CodedCharSet
-- General
}
4. Page 76: Add prtGeneralStaticCodeSet object to the end of the
prtGeneralTable:
prtGeneralStaticCodeSet OBJECT-TYPE
SYNTAX CodedCharSet
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A code set from the IANA Character Set registry [IANA] to be used
when interpreting 'human-readable' string objects with syntax
'OCTET STRING' that are not explicitly marked as being subject
to localization. The specified code set SHALL have the
property that code positions 32 to 126 are US-ASCII [US-ASCII]
Code positions 0 to 31 and 127 SHALL NOT be used
unless the object DESCRIPTION explicitly permits such usage.
Code positions 128 to 255 SHALL represent single-byte or multi-byte
graphic characters structured according to ISO 2022 [ISO 2022].
Usage: This object is updated (infrequently) by system
administrators when they install, upgrade, or move the managed
system (to another physical and/or network location) or is
fixed by the implementation.
Usage: This object NEED NOT contain a value which is 'known'
to this network printer or network print server, and need NOT
contain a value found in some 'prtLocalizationCharacterSet'
object instance currently present in the 'prtLocalizationTable'
(ie, the static char set may be 'opaque' to the managed system)."
REFERENCE
"See: Section 2.2.1, 'General Printer',
'prtGeneralCurrentLocalization' (dynamic strings), and
'prtGeneralConsoleLocalization' (console strings)
objects in the General group of this Printer MIB."
DEFVAL {126} -- UTF-8 [UTF-8]
::= { prtGeneralEntry 20 }
5. Page 137, after prtGeneralSerialNumber, add MIN-ACCESS read-only:
OBJECT prtGeneralStaticCodeSet
MIN-ACCESS read-only
DESCRIPTION
"It is conformant to implement this object as read-only"
6. page 143 to add the prtGeneralStaticCodeSet object to the prtGeneralGroup
Change:
prtGeneralGroup OBJECT-GROUP
OBJECTS { prtGeneralConfigChanges,
prtGeneralCurrentLocalization,
prtGeneralReset, prtCoverDescription,
prtCoverStatus,
prtLocalizationLanguage, prtLocalizationCountry,
prtLocalizationCharacterSet, prtStorageRefIndex,
prtDeviceRefIndex, prtGeneralPrinterName,
prtGeneralSerialNumber }
to:
prtGeneralGroup OBJECT-GROUP
OBJECTS { prtGeneralConfigChanges,
prtGeneralCurrentLocalization,
prtGeneralReset, prtCoverDescription,
prtCoverStatus,
prtLocalizationLanguage, prtLocalizationCountry,
prtLocalizationCharacterSet, prtStorageRefIndex,
prtDeviceRefIndex, prtGeneralPrinterName,
prtGeneralSerialNumber, prtGeneralStaticCodeSet }
7. Page 172: Add a proper Bibliography section so that the above
references can be made. I found a proper reference to US-ASCII in
RFC 2044 (UTF-8) as:
[US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
So it is ok to refer to ANSI standards from IETF standards.
So I propose that the Bibligraphy section be:
[GB2312] GB 2312-1980, "Chinese People's Republic oF China (PRC)
mixed one byte and two byte coded character set"
[IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, ISI, October 1994.
[ISO 646] ISO/IEC 646:1991, "Information technology -- ISO 7-bit coded
character set for information interchange", JTC1/SC2.
[ISO 8859] ISO/IEC 8859-1:1987, "Information technology -- 8-bit single
byte coded graphic character sets -
Part 1: Latin alplhabet No. 1, JTC1/SC2."
[ISO 2022] ISO/IEC 2022:1994 - "Information technology -- Character code
structure and extension techniques", JTC1/SC2.
[ISO 10646] ISO/IEC 10646-1:1993, "Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane, JTC1/SC2.
[JIS X0208] JIS X0208-1990, "Japanese two byte coded character set."
[NVT ASCII] J. Postel, J. Reynolds, "TELENET PROTOCOL SPECIFICATION",
RFC 854, May 1983.
[US-ASCII] Coded Character Set - 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[UTF-7] Goldsmith, D., and M. Davis, "UTF-7", RFC1642, Taligent,
Inc., July 1994.
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646", RFC 2044, October 1996.
For reference:
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:
prtGeneralCurrentOperator OCTET STRING,
prtGeneralServicePerson OCTET STRING,
prtGeneralSerialNumber OCTET STRING,
localized prtCoverDescription OCTET STRING,
prtCoverDescription OCTET STRING,
prtLocalizationLanguage OCTET STRING,
prtLocalizationCountry OCTET STRING,
prtInputMediaName OCTET STRING,
prtInputName OCTET STRING,
prtInputVendorName OCTET STRING,
prtInputModel OCTET STRING,
prtInputVersion OCTET STRING,
prtInputSerialNumber OCTET STRING,
localized prtInputDescription OCTET STRING,
prtInputMediaType OCTET STRING,
prtInputMediaColor OCTET STRING,
prtOutputName OCTET STRING,
prtOutputVendorName OCTET STRING,
prtOutputModel OCTET STRING,
prtOutputVersion OCTET STRING,
prtOutputSerialNumber OCTET STRING,
localized prtOutputDescription OCTET STRING,
localized prtMarkerSuppliesDescription OCTET STRING,
prtMarkerColorantValue OCTET STRING,
localized prtMediaPathDescription OCTET STRING,
prtChannelProtocolVersion OCTET STRING,
prtInterpreterLangLevel OCTET STRING,
prtInterpreterLangVersion OCTET STRING,
localized prtInterpreterDescription OCTET STRING,
prtInterpreterVersion OCTET STRING,
console localization prtConsoleDisplayBufferText OCTET STRING
console localization prtConsoleDescription OCTET STRING
localized prtAlertDescription OCTET STRING,
This proposal would add to the above list:
prtGeneralPrinterName OCTET STRING
NOTE:
I have left out any attempts to fix the DESCRIPTION of
prtChannelInformation in this proposal, since previous attempts to
fix its descriptive contradictions has upset some members. I have
also not proposed that its SYNTAX be changed from DisplayString
to OCTET STRING for the same reason.