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