You state that the primary motivation for moving to CR/LF is to improve
MIB object display within general purpose NMS platforms. I question
the true value of this motivation.
Please recall that several informal "studies" by various people have
consistently indicated that those persons using general purpose NMS
platforms are *not* generally interested in managing printers with
those types of products. That is to say, "reasonable behavior" of
Printer MIB values displayed using a general purpose NMS should be
considered "gravy" (ie, value-add) and not a mainstream requirement.
Some quick comments:
- 'prtChannelInformation' was not expressly designed to be a human-
readable value, even though the syntax is "DisplayString".
- Ironically, 'prtGeneralCurrentOperator' and 'prtGeneralServicePerson'
were designed with more of a bent towards human-readability, yet
the syntax for those objects is "OCTET STRING". Strange...
Again, if the group desires a move towards CR/LF instead of LF, then
so be it. It should be well noted, though, that such a move will in
effect "break" existing RFC 1759 management applications, since those
apps expect to deal only with LF as the delimiter character.
...jay
PS: I have attached a version of the original document below, whereby
all page-break stuff (headers, footers, etc) have been removed to
improve readability.
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
----- Begin Included Message -----
Date: Wed, 16 Jul 1997 01:16:39 PDT
To: pmp@pwg.org
From: Tom Hastings <hastings@cp10.es.xerox.com>
Subject: PMP> ISSUE: CR/LF, not just LF, to mark lines in prtChannelInfo,
prtGeneralCurrentOperator, prtGeneralServicePerson
There are several places in the Printer MIB where a LF by itself
is indicated as the way to separate lines. But US-ASCII and NVT ASCII
both specify that lines are ended with the two character sequence
CR (carriage return = decimal 13) and LF (line feed = decimal 10).
If you send ONLY a LF to a display console (eg, an NMS), you will NOT
reposition to the first column for the next fragment and these strings
will be displayed incorrectly (as a cascade to the right).
This is because LF is only a vertical motion in US-ASCII and NVT ASCII.
It is UNIX and C that have the convention that LF by itself is a new-line.
The following objects are affected:
1. The 'prtChannelInformation' object specifies ONLY an LF (line feed)
as a delimiter and NOT a CR/LF pair (consistent with MIME mail and HTTP
header usage, US-ASCII and NVT ASCII usage).
2. The 'prtGeneralCurrentOperator' and 'prtGeneralServicePerson'
specify ONLY an LF (line feed) to delimit lines, NOT a CR/LF pair.
Suggested changes of text
Here is the current text for the three objects:
prtChannelInformation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Auxiliary information to allow a printing application
to use the channel for data submission to the printer.
An application capable of using a specific
PrtChannelType should be able to use the combined
information from the prtChannelInformation and other
channel and interface group objects to 'bootstrap' its
use of the channel. prtChannelInformation is not
intended to provide a general channel description, nor
to provide information that is available once the
channel is in use.
The encoding and interpretation of the
prtChannelInformation object is specific to channel
type. The description of each PrtChannelType enum value
for which prtChannelInformation is defined specifies the
appropriate encoding and interpretation, including
interaction with other objects. For channel types that
do not specify a prtChannelInformation value, its value
shall be null (0 length).
When a new PrtChannelType enumeration value is
registered, its accompanying description must specify
the encoding and interpretation of the
prtChannelInformation value for the channel type.
prtChannelInformation semantics for an existing
PrtChannelType may be added or amended in the same
manner as described in section 2.4.1 for type 2
enumeration values.
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.)
6. For each PrtChannelType for which
prtChannelInformation entries are defined, the
descriptive text associated with the PrtChannelType
enumeration value shall specify the following
information for each entry:
Title: Brief description phrase, e.g.: 'Port name',
'Service Name', etc.
Keyword: The keyword value, e.g.: 'Port' or 'Service'
Syntax: The encoding of the entry value, if it
cannot be directly represented by NVT ASCII.
Status: 'Mandatory', 'Optional', or 'Conditionally
Mandatory'
Multiplicity: 'Single' or 'Multiple' to indicate whether
the entry may be present multiple times.
Description: Description of the use of the entry, other
information required to complete the
definition (e.g.: ordering constraints,
interactions between entries).
Applications that interpret prtChannelInformation should
ignore unrecognized entries, so they are not affected if
new entry types are added."
::= { prtChannelEntry 9 }
prtGeneralCurrentOperator OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the person who is responsible for operating
this printer. It is suggested that this string include
information that would enable other humans to reach the
operator, such as a phone number. As a convention to
facilitate automatic notification of the operator by the
agent or the network management station, the phone
number, fax number or email address should be placed on
a separate line starting with ASCII LF (hex 0x0A) and
the ASCII text string (without the quotes): 'phone: ',
'fax: ', and 'email: ', respectively. Phone numbers may
contain digits, spaces and parentheses, which shall be
ignored. Phone numbers may also include ASCII comma
characters(hex 2C) that are used to indicate a two-
second pause during the dialing sequence. If either the
phone, fax, or email information is not available, then
a line should not be included for this information.
NOTE: For interoperability purposes, it is advisable to
use email addresses formatted according to RFC 822
requirements."
::= { prtGeneralEntry 4 }
prtGeneralServicePerson OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the person responsible for servicing this
printer. It is suggested that this string include
information that would enable other humans to reach the
service person, such as a phone number. As a convention
to facilitate automatic notification of the service
person by the agent or a network management station, the
phone number, fax number or email address should be
placed on a separate line starting with ASCII LF (hex
0x0A) and the ASCII text string (without the quotes):
'phone: ', 'fax: ', and 'email: ', respectively. Phone
numbers may contain digits, spaces and parentheses,
which shall be ignored. Phone numbers can also include
one or more ASCII comma characters(hex 2C) to indicate a
two-second pause during the dialing sequence. If either
the phone, fax, or email information is not available,
then a line should not included for this information.
NOTE: For interoperability purposes, it is advisable to
use email addresses formatted according to RFC 822
requirements."
::= { prtGeneralEntry 5 }
The suggested changes are indicated with | in line one:
prtChannelInformation OBJECT-TYPE
| SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Auxiliary information to allow a printing application
to use the channel for data submission to the printer.
An application capable of using a specific
PrtChannelType should be able to use the combined
information from the prtChannelInformation and other
channel and interface group objects to 'bootstrap' its
use of the channel. prtChannelInformation is not
intended to provide a general channel description, nor
to provide information that is available once the
channel is in use.
The encoding and interpretation of the
prtChannelInformation object is specific to channel
type. The description of each PrtChannelType enum value
for which prtChannelInformation is defined specifies the
appropriate encoding and interpretation, including
interaction with other objects. For channel types that
do not specify a prtChannelInformation value, its value
shall be null (0 length).
When a new PrtChannelType enumeration value is
registered, its accompanying description must specify
the encoding and interpretation of the
prtChannelInformation value for the channel type.
prtChannelInformation semantics for an existing
PrtChannelType may be added or amended in the same
manner as described in section 2.4.1 for type 2
enumeration values.
The prtChannelInformation specifies values for a
collection of channel attributes, represented as text
according to the following rules:
| 1. The prtChannelInformation SHALL NOT be 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 US-ASCII [US-ASCII] alphabetic
| characters (A-Z, a-z), that identifies a channel
attribute,
| b. a US-ASCII Equals Sign (=) to delimit the keyword,
| c. a data value, consisting of US-ASCII graphics
| characters (codes 32-126) and possibly graphic
| characters of another one or two byte set in codes
| 128 to 255 according to the structure of 8-bit codes
| in ISO 2022 as with any other OCTET STRING in this
| MIB not subject to localization. See section
2.2.1 entitled "General Printer".
| d. a Carriage Return (code 13) and 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 US-
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
[UTF-8] format.)
6. For each PrtChannelType for which
prtChannelInformation entries are defined, the
descriptive text associated with the PrtChannelType
enumeration value shall specify the following
information for each entry:
Title: Brief description phrase, e.g.: 'Port name',
'Service Name', etc.
Keyword: The keyword value, e.g.: 'Port' or 'Service'
Syntax: The encoding of the entry value, if it
| cannot be directly represented by US-ASCII.
Status: 'Mandatory', 'Optional', or 'Conditionally
Mandatory'
Multiplicity: 'Single' or 'Multiple' to indicate whether
the entry may be present multiple times.
Description: Description of the use of the entry, other
information required to complete the
definition (e.g.: ordering constraints,
interactions between entries).
Applications that interpret prtChannelInformation should
ignore unrecognized entries, so they are not affected if
new entry types are added."
::= { prtChannelEntry 9 }
prtGeneralCurrentOperator OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the person who is responsible for operating
this printer. It is suggested that this string include
information that would enable other humans to reach the
operator, such as a phone number. As a convention to
facilitate automatic notification of the operator by the
agent or the network management station, the phone
number, fax number or email address should be placed on
| a separate line starting with US-ASCII carriage return
| (CR = decimal 13) and line feed (LF = decimal 10) and
| the US-ASCII text string (without the quotes): 'phone: ',
'fax: ', and 'email: ', respectively. Phone numbers may
contain digits, spaces and parentheses, which shall be
| ignored. Phone numbers may also include US-ASCII comma
| characters (decimal 44) that are used to indicate a two-
second pause during the dialing sequence. If either the
phone, fax, or email information is not available, then
a line should not be included for this information.
NOTE: For interoperability purposes, it is advisable to
use email addresses formatted according to RFC 822
requirements."
::= { prtGeneralEntry 4 }
prtGeneralServicePerson OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the person responsible for servicing this
printer. It is suggested that this string include
information that would enable other humans to reach the
service person, such as a phone number. As a convention
to facilitate automatic notification of the service
person by the agent or a network management station, the
phone number, fax number or email address should be
| placed on a separate line starting with US-ASCII
| carriage return (CR = decimal 13) and line feed
| (LF = decimal 10) and the US-ASCIItext string
(without the quotes):
'phone: ', 'fax: ', and 'email: ', respectively. Phone
numbers may contain digits, spaces and parentheses,
which shall be ignored. Phone numbers can also include
one or more ASCII comma characters(hex 2C) to indicate a
two-second pause during the dialing sequence. If either
the phone, fax, or email information is not available,
then a line should not included for this information.
NOTE: For interoperability purposes, it is advisable to
use email addresses formatted according to RFC 822
requirements."
::= { prtGeneralEntry 5 }
----- End Included Message -----