We got real close to agreement and people tried real hard.
Doing it all by e-mail has been difficult and time consuming.
David's proposal on Friday was something that I though we could
all get behind but we seem to have run out of time.
Your proposed text is an improvement and warns people of the dangers
of using 128 to 255 while clarifing what we mean by code sets.
A couple of comments on what you propose to edit:
1. The prtGeneralPrinterName change is backward (I made the same
mistake, so you may have copied it from me). It is already DisplayString
and you want to make it OCTET STRING, like all the other objects.
2. We need to add references to US-ASCII and NVT-ASCII and add a
Reference section at the end. The current IETF practice is to put the reference
inside [] with something mneumonic. So [US-ASCII] and [NVT-ASCII]
would be the tags embedded after the first references in the text
and the references would be:
References:
[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.
Tom
P.S. I've put these comments in the attached as well:
At 14:27 07/28/97 PDT, lpyoung at lexmark.com wrote:
>>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
Add the reference so the above line would become:
US-ASCII [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
Should be:
*from* DisplayString
*to* OCTET STRING
>(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
Add the reference, so that the above line would become:
a-z) represented by their NVT ASCII [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
>>>>