Chris and I have decided to close down the Printer MIB work
effective today, 7/28/97. We would like to thank everyone for
their contributions to the efforts of advancing the Printer MIB
to Draft Standard.
The last remaining issue that was been discussed for the past few
weeks is the issue of Localization. Chris and I stepped back and
took a honest look at this issue. We decided that attempting to
resolve this issue is not required in advancing the Printer MIB
to Draft Standard. This issue was not discovered during
interoperability testing, it was not discovered as a customer
field problem, it was discovered by a group of individuals who
felt (and rightly so) that the MIB could be improved if
localization were better addressed. The net is that the Printer
MIB can not be considered to be broken from an IETF perspective
if it is progressed forward and the area of localization is left
as initially defined in RFC 1759.
As a working group, we have had two goals. On the one hand our
mission to get to DRAFT standard was clear: prove that all objects,
mandatory and optional, are interoperable and only add changes
for clarity. This was accomplished. On the other hand, we were
also encouraged to take a little longer to address localization.
This we did as well. It is the responsibility of IETF Working Group
chairs to determine if convergence is possible within a reasonable
amount of time. While some progress was made on localization,
we did not converge on a clear implementable solution that meets
the requirements for DRAFT Standard.
The best path through the IETF in addressing localization now
appears to be through an Informational RFC. The efforts can
continue to clearly define localization for the Printer MIB and
the effort published as an Informational RFC. This will give all
implementors of the Printer MIB the opportunity to optionally
support the Informational RFC as an additional MIB in
their product.
There have been some good clarification changes proposed for the
Printer MIB in the discussions of the past two weeks. Chris and
I have reviewed the mail on this issue and have included the
changes that best reflect consensus from the working group. I have
included the major changes below. All changes (major and minor)
will be published on or before Wednesday July 30th.
Major Changes:
(1) Clarification of ASCII.
The last line of the third paragraph is section 2.2.1 will be
replaced, and the following text will be used instead.
The agent SHALL return all other character strings as coded
character sets in which code positions 0-127 (decimal) are
US-ASCII. Use of the remaining values, 128-255, is discouraged
because there is no method defined in the MIB to determine the
desired code position to character mapping and in the future,
these code positions may be used for a specific encoding which
would result in an agent utilizing these code positions being
incompatible with future implementations.
Control codes (code positions 0-31 and 127) SHALL NOT be used
unless specifically specified in the DESCRIPTION of the object.
(2) The syntax of prtGeneralPrinterName will change
*from* OCTET STRING
*to* DisplayString
(3) The syntax of prtLocalizationLanguage and prtLocalizationCountry
will change
*from* OCTET STRING
*to* DisplayString
(4) prtChannelInformation will change
*from* DisplayString
*to* OCTET STRING
and the text will be changed as follows:
prtChannelInformation OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
...
The prtChannelInformation specifies values for a collection of
channel attributes, represented according to the following
rules:
1. The prtChannelInformation is not affected by localization.
2. The prtChannelInformation is a list of entries representing
the attribute values. Each entry consists of a sequence of
octets containing the following items, in order:
a. a keyword, composed of alphabetic characters (A-Z,
a-z) represented by their NVT ASCII codes, that
identifies a channel attribute,
b. the NVT ASCII code for an Equals Sign (code 61),
to delimit the keyword,
c. a data value encoded using rules specific to the
PrtChannelType to which the prtChannelInformation applies,
which must in no case allow an octet with value 10 (the NVT
ASCII Line Feed code),
d. the NVT ASCII code for a Line Feed character (code 10),
to delimit the data value.
No other octets shall be present.
Keywords are case-sensitive. Conventionally, keywords are
capitalized (including each word of a multi-word keyword), and,
since they occupy space in the prtChannelInformation, they are
kept short.
3. If a channel attribute has multiple values, it is
represented by multiple entries with the same keyword,
each specifying one value. Otherwise, there shall be at
most one entry for each attribute.
4. By default, entries may appear in any order. If there are
ordering constraints for particular entries, these must be
specified in their definitions.
5. A prtChannelInformation value by default consists of text
represented by NVT ASCII graphics character codes. However,
other representations may be specified:
a. In cases where the prtChannelInformation value contains
information not normally coded in textual form, whatever
symbolic representation is conventionally used for the
information should be used for encoding the
prtChannelInformation value. (For instance, a binary port
value might be represented as a decimal number using NVT ASCII
codes.) Such encoding must be specified in the definition of
the value.
b. The value may contain textual information in a character set
other than NVT ASCII graphics characters. (For instance, an
identifier might consist of ISO 10646 text encoded using
the UTF-8 encoding scheme.) Such a character set and its
encoding must be specified in the definition of the value.
Regards,
Lloyd
------------------------------------------------------------
Lloyd Young Lexmark International, Inc.
Senior Program Manager Dept. C14L/Bldg. 035-3
Strategic Alliances 740 New Circle Road NW
internet: lpyoung at lexmark.com Lexington, KY 40550
Phone: (606) 232-5150 Fax: (606) 232-6740