David,
Good job! I agree to these clarifications to prtChannelInformation.
I have two small tweaks:
1. IF we also accept the new prtGeneralStaticCodeSet object proposal,
the code set for prtChannelInformation is specified by the enum value,
not by the value of prtGeneralStaticCodeSet, so then change your point 1
from:
| 1. The prtChannelInformation is not affected by localization.
to:
| 1. The prtChannelInformation is not affected by localization
| or the value of the prtGeneralStaticCodeSet object.
2. We could align point b a little more with the IETF terminology in
RFC 2130, "The Report of the IAB Character Set Workshop held 29 Febuary
- 1 March 1997" and reference that important clarifying work.
Change:
| 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
| UTF-8.) Such a character set and its encoding must be
| specified in the definition of the value.
to:
| 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 [UTF8].) Such a character set and its
| encoding scheme [RFC 2130] must be specified in the definition
| of the value.
and then add the following to the References section:
[RFC 2130] C. Weider, C. Preston, K. Simonsen, H. Alvestrand,
R. Atkinson, M. Crispin, P. Svanberg, "The Report of the IAB Character
Set Workshop held 29 Febuary - 1 March 1997", April 1997.
Thanks for this effort,
Tom
At 19:39 07/22/97 PDT, David_Kellerman at nls.com wrote:
>Ah, Scott, another Pigeon come home to roost. The prtChannelInformation
>encoding. (What can I say -- I didn't have a clue what I was doing
>writing the prtChannelInformation stuff?)
>>I hate making these on-the-fly last minute changes. But your changes
>seem like the "right" thing to do, and here I am in the embarrasing
>position of suggesting that if they are non-controversial, we go ahead
>and incorporate them. But if this is a bigger issue than I think it is,
>please someone stop me.
>>I appreciate you laying out so clearly the changes you propose.
>However, I would propose slightly different wording. The problem is
>that once you abandon the NVT ASCII only convention, the change ripples
>through the text.
>>To summarize, the intent here is ONLY to (1) free up the rules for the
>prtChannelInformation values to make it easier for them to encode
>character sets other than NVT ASCII (ISO 10646, in particular, where the
>UTF-8 is much preferrable to the UTF-7 encoding imposed by the existing
>wording), (2) clarify some of the language concerning character sets.
>>What follows is: (1) text with my suggested changes indicated by
>changebars, (2) the existing text, for reference, (3) Scott's message
>containing his proposed changes.
>>:: David Kellerman Northlake Software 503-228-3383
>::david_kellerman at nls.com Portland, Oregon fax 503-228-5662
>>------------------------------------------------------------------------
>DK's modified text:
>> 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 encodings 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
>| UTF-8.) Such a character set and its encoding must be
>| specified in the definition of the value.
>>------------------------------------------------------------------------
>Existing text:
> prtChannelInformation OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..255))
> MAX-ACCESS read-only
> STATUS current
>> ...
>> The prtChannelInformation specifies values for a collection of
> channel attributes, represented as text according to the
> following rules:
>> 1. The prtChannelInformation is coded in the NVT ASCII character
> set. It is not affected by localization.
>> 2. The prtChannelInformation is a list of entries representing
> the attribute values. Each entry consists of the following
> items, in order:
>> a. a keyword, composed of alphabetic characters (A-Z,
> a-z), that identifies a channel attribute,
>> b. an Equals Sign (=) to delimit the keyword,
>> c. a data value, consisting of NVT ASCII graphics characters
> (codes 32-126),
>> d. a Line Feed character (code 10) to delimit the data value.
>> No other characters 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. The prtChannelInformation value may represent information that
> is not normally coded in textual form, or that is coded in a
> character set other than NVT ASCII. In these cases, whatever
> symbolic representation is conventionally used for the
> information should be used for encoding the
> prtChannelInformation. (For instance, a binary port value might
> be represented as a decimal number, Unicode would be represented
> in UTF-8 format.)
>>>>> I believe that the following changes should be made to the
>> section on prtChannelInformation:
>>>> From:
>> SYNTAX DisplayString (SIZE (0..255))
>> To:
>> SYNTAX OCTET STRING (SIZE (0..255)) -- with special rules
>>Agreed, DisplayString is just causing confusion here.
>>> From:
>> The prtChannelInformation specifies values for a
>> collection of channel attributes, represented as text
>> according to the following rules:
>> To:
>> The prtChannelInformation specifies values for a
>> collection of channel attributes, represented
>> according to the following rules:
>>> From:
>> 1. The prtChannelInformation is coded in the NVT ASCII
>> character set. It is not affected by localization.
>> To:
>> 1. The prtChannelInformation keywords are coded in the
NVT ASCII
>> character set. They are not affected by localization.
>>DK's to:
> 1. The prtChannelInformation is not affected by localization.
>>From:
> a. a keyword, composed of alphabetic characters (A-Z,
> a-z), that identifies a channel attribute,
>> b. an Equals Sign (=) to delimit the keyword,
>>DK's to:
> a. a keyword, composed of alphabetic characters (A-Z,
> a-z) represented by their NVT ASCII codes, that
> identifies a channel attribute,
>> b. an Equals Sign (=) represented by its NVT ASCII
> code (code 61), to delimit the keyword,
>>>> From:
>> c. a data value (encoded using the encoding rules specific
>> to that keyword)
>> To:
>>I think your cut-and-paste slipped here.
>>Corrected From:
> c. a data value, consisting of NVT ASCII graphics characters
> (codes 32-126),
>DK's To:
> c. a data value encoded using rules specific to the
> PrtChannelType to which the prtChannelInformation applies,
> which must not allow an octet with value 10 (the NVT ASCII
> Line Feed code),
>>> From:
>> No other characters shall be present.
>> To:
>> <remove>
>>When prtChannelInformation was discussed, questions such as "can there
>be white-space around the equals-sign" were raised. This sentence was
>intended to clarify that issue. (Whether it does or not is a separate
>question.) I would tend to leave it in place.
>>> Keep:
>> 5. The prtChannelInformation value may represent
>> information that is not normally coded in textual form,
>> or that is coded in a character set other than NVT
>> ASCII. In these cases, whatever symbolic representation
>> is conventionally used for the information should be
>> used for encoding the prtChannelInformation. (For
>> instance, a binary port value might be represented as a
>> decimal number, Unicode would be represented in UTF-8
>> format.)
>>>> <Don't make it UTF-7>
>>DK's To:
> 5. A prtChannelInformation value by default consists of text
> represented by NVT ASCII graphics character codes. 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.) Any such encoding must
> be specified in the definition of the value. Similarly, where
> the value contains textual information in a character set
> other than NVT ASCII graphics characters, the character set
> and its encoding must be specified in the definition of the
> value. (For instance, ISO 10646 text might be encoded using
> UTF-8.)
>> 5. The prtChannelInformation value may represent
> information that is not normally coded in textual form,
> or that is coded in a character set other than NVT
> ASCII. In these cases, whatever symbolic representation
> is conventionally used for the information should be
> used for encoding the prtChannelInformation. (For
> instance, a binary port value might be represented as a
> decimal number, Unicode would be represented in UTF-8
> format.)
>>------------------------------------------------------------------------
>>Date: Tue, 22 Jul 1997 15:02:22 -0600
>From: Scott Isaacson <SISAACSON at novell.com>
>Subject: Re: PMP> URGENT: Need consensus by noon PDT today on definition
> ofOCTET STRING to allow superset of ASCII
>>All,
>>It looks like noon has come and gone at the OK Printer Mib Corral.....
>Sorry for the late post.
>>However, my suggestions
>>Long ago,
>I proposed several sets of attributes for Novell channel types. I
>recommended that values be UTF-8 encoded Unicode characters.
>>Please note that use of Unicode in Novell has been in place
>(existing practice) for over 3 years. Printer, Print Server, and Queue
>names are Unicode in NetWare 4.x and IntranetWare, not just
>NDPS.
>>Therefore,
>I believe that the following changes should be made to the
>section on prtChannelInformation:
>>From:
> SYNTAX DisplayString (SIZE (0..255))
>To:
> SYNTAX OCTET STRING (SIZE (0..255)) -- with special rules
>>>From:
> The prtChannelInformation specifies values for a
> collection of channel attributes, represented as text
> according to the following rules:
>To:
> The prtChannelInformation specifies values for a
> collection of channel attributes, represented
> according to the following rules:
>>From:
> 1. The prtChannelInformation is coded in the NVT ASCII
> character set. It is not affected by localization.
>To:
> 1. The prtChannelInformation keywords are coded in the
>NVT ASCII
> character set. They are not affected by localization.
>>From:
> c. a data value (encoded using the encoding rules
>specific
> to that keyword)
>To:
>>From:
> No other characters shall be present.
>To:
> <remove>
>>>Keep:
> 5. The prtChannelInformation value may represent
> information that is not normally coded in textual form,
> or that is coded in a character set other than NVT
> ASCII. In these cases, whatever symbolic representation
> is conventionally used for the information should be
> used for encoding the prtChannelInformation. (For
> instance, a binary port value might be represented as a
> decimal number, Unicode would be represented in UTF-8
> format.)
>><Don't make it UTF-7>
>>Scott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>