Tom,
I agreed with your first proposal because it seemed to be loosening the =
specification a bit to accommodate some existing implementations as well =
as allowing some flexibility for future implementations. Objections have =
been raised that your proposal didn't fix all the problems that exist, =
so you have created this "SYNTHESIS proposal" which looks quite similar =
to Ira's proposal which was rejected.
As I objected to Ira's proposal, I must object to this proposal as well. =
I feel that loosening the specification is one thing, but providing an =
incomplete fix is another.=20
We recognize that there are localization problems with the Printer MIB =
that Lloyd and Chris are trying to publish. I'd rather publish with the =
existing known problems than to put in a partial fix or delay for a =
complete fix.
Bob Pentecost
HP
----------
From: Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
Sent: Wednesday, July 23, 1997 4:40 AM
To: pmp at pwg.org
Cc: Harald.T.Alvestrand at uninett.no; Keith Moore
Subject: PMP> URGENT: SYNTHESIS proposal on definition of OCTET STRING =
toallow superset of ASCII
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=20
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=20
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),=20
HP Roman8, JIS X0208 (Japanese Kanji two byte set), GB2312 (PRC Chinese=20
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=20
localization mechanism in the Printer MIB). I suggest as a SYNTHESIS =
proposal=20
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=20
already indicated as being subject to the localization mechanism in the=20
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=20
making the object OPTIONAL and putting it in a separate group and=20
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=20
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=20
represented by objects with syntax 'OCTET STRING' that
are explicitly marked as being localized. The agent SHALL return=20
all other OCTET STRING objects as coded character sets in which =
code=20
positions 0-127 (decimal) SHALL be US-ASCII [US-ASCII] and the =
remaining=20
code positions, 128-255, if used, SHALL be any other coded =
character=20
set structured according to ISO 2022 [ISO 2022] in 8-bit =
environments,=20
including multi-byte sets.. Examples of coded character sets =
which=20
meet this criteria are: US-ASCII, ISO 646:1991 IRV [ISO 646],=20
ISO 8859-1 (Latin-1) [ISO 8859], any ISO 8859-n, HP Roman8,=20
Windows Default 8-bit set, UTF-8 [UTF-8], US-ASCII plus=20
JIS X0208-1990 Japanese [JIS X0208], US-ASCII plus GB2312-1980=20
PRC Chinese [GB2312].
=20
Examples of coded character sets which do not meet this criteria =
are: =20
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=20
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=20
'OCTET STRING (SIZE(0..63))'=20
so that other sets may be used in code positions 128 to 255 and so =
that=20
no control codes will be used (and so a lower and upperbound length=20
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=20
when interpreting 'human-readable' string objects with syntax
'OCTET STRING' that are not explicitly marked as being subject=20
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]
::=3D { 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=20
references can be made. I found a proper reference to US-ASCII in=20
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=20
character set for information interchange", JTC1/SC2.
[ISO 8859] ISO/IEC 8859-1:1987, "Information technology -- 8-bit =
single=20
byte coded graphic character sets -=20
Part 1: Latin alplhabet No. 1, JTC1/SC2."
[ISO 2022] ISO/IEC 2022:1994 - "Information technology -- =
Character code=20
structure and extension techniques", JTC1/SC2.
[ISO 10646] ISO/IEC 10646-1:1993, "Information technology -- =
Universal=20
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 =
OCTET STRING,
prtOutputSerialNumber OCTET STRING,=20
localized prtOutputDescription OCTET STRING,=20
localized prtMarkerSuppliesDescription OCTET STRING,
prtMarkerColorantValue OCTET STRING,=20
localized prtMediaPathDescription OCTET STRING,
prtChannelProtocolVersion OCTET STRING,
prtInterpreterLangLevel OCTET STRING,
prtInterpreterLangVersion OCTET STRING,=20
localized prtInterpreterDescription OCTET STRING,
prtInterpreterVersion OCTET STRING,=20
console localization prtConsoleDisplayBufferText OCTET STRING=20
console localization prtConsoleDescription OCTET STRING=20
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=20
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.