Bob,
My proposal is only similar to Ira's proposal for the code set part.
My proposal does NOT address country or language, which is where
we found problems in Ira's proposal. By only addressing code char
sets, we don't need to divide the OCTET STRING objects up.
Please point out a problem with the SYNTHESIS proposal (which only
affects code sets). If there is one, your position (that this problem
can't be easily fixed in a short time) will gain support.
Thanks,
Tom
>
>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.
>
>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@cp10.es.xerox.com]
>Sent: Wednesday, July 23, 1997 4:40 AM
>To: pmp@pwg.org
>Cc: Harald.T.Alvestrand@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
>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 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.
>
>
>
>
>
>