To PWG PMP,
Here are my comments on the prtChannelInformation object for the PWG PMP
telecon to discuss this specification for the Printer MIB Wed, Oct 30, 10-12.
I like what is specified here. It is simple, extensible, solves real needs
for people and programs that need additional information about how to submit
jobs to the printer, such as the port number, or Netware queue name. It is
writeable, so that an administrator can set it if the device agent can't.
My comments are:
1. Want DisplayString as data type, or at least specify in the DESCRIPTION,
so that the data must be the restricted form of ASCII (NVT ASCII? was is
the RFC for it?)
2. MIN-ACCESS should be read-only, correct?
3. It will be added to the channel group and the channel table, not to a
separate group and not to a separate table. So include the additions to the
conformance section that goes in the back.
4. Implementors may want to add their own keywords, but they run the risk of
a collision with an update to the channel registration. So implementors are
encouraged to come to the committee with new keywords before they ship. We
need some text like that to be added. How about something like:
Implementors may add their own keywords, but they run the risk of choosing
the same keyword as other implementors with the same or different semantics.
Therefore, it is strongly recommended that implementors submit additional
keyword proposals to the PWG for addition to existing registrations using
the normal procedures for type 2 enums.
5. Change "no extraneous characters should be present" to "no extraneous
characters shall be present".
The word "shall" in standards means required for conformance. The work
"should" means recommended.
6. Change should to shall in: "Otherwise, there should be at most
one entry for each attribute.
7. Clarify the "it" in not human readable. The value of this object must
always be human readable. It may represent a value that is not human
readable, such as decimal digits representing a binary port number.
Thanks,
Tom Hastings
>Return-Path: <pwg-owner at pwg.org>
>Date: Sun, 20 Oct 1996 00:11:54 PDT
>From: David_Kellerman at nls.com>To: pwg at pwg.org>Subject: revised prtChannelInformation MIB object (was prtChannelMagicCookie)
>Sender: owner-pwg at pwg.org>>Here is the revised prtChannelInformation object definition (previously
>prtChannelMagicCookie). I've tried to incorporated all the decisions
>reached at the October 18th conference call. Please let me know if
>anything is missing or mis-stated, or if you have suggestions on
>clarifying the language.
>>Following the object definition are the specific semantics for a
>handful of enum values. Again, please speak up if you think different
>information should be included, or if you can suggest improvements to
>the exposition.
>>There's one thing I'm confused about. Randy recommended changing the
>SYNTAX to DisplayString, and I thought I understood why this made sense.
>But RFC 1759 seems to use plain OCTET STRING throughout, not
>DisplayString. Explanation?
>>:: David Kellerman Northlake Software 503-228-3383
>::david_kellerman at nls.com Portland, Oregon fax 503-228-5662
>>>prtChannelInformation OBJECT-TYPE
> SYNTAX DisplayString (SIZE(0..255))
> MAX-ACCESS read-write
> MIN-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 may also be added
> to an existing PrtChannelType 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, encoded according to the following rules:
>> 1. The prtChannelInformation is a list of entries containing
> data values. Each entry begins with a name, composed of
> alphabetic characters (A-Z, a-z), that identifies a channel
> attribute. The name is followed by an equals sign (=), the
> data value, and a linefeed character. No other characters
> (such as extraneous space characters) should be present.
>> 2. If a channel attribute has multiple values, it is
> represented by multiple entries with the same name, each
> containing one value. Otherwise, there should be at most
> one entry for each attribute.
>> 3. Entries may appear in any order.
>> 4. The prtChannelInformation value may contain information that
> is not normally coded in human-readable form. In these
> cases, whatever symbolic representation is conventionally
> used for the information is used for encoding the
> prtChannelInformation. (For instance, a binary port value
> might be encoded as a decimal number.)
>> 5. For each PrtChannelType for which prtChannelInformation is
> defined, the descriptive text associated with the
> PrtChannelType enumeration value shall specify, at a
> minimum, the following:
> a. The attributes specified by the prtChannelInformation,
> their identifying names, and how their data value is
> encoded if it is not normally human-readable.
> b. For each attribute, whether it is mandatory or optional,
> and whether it may have multiple values.
>> Applications that interpret prtChannelInformation should ignore
> unrecognized entries, so they are not affected if new entry
> types are added.
> "
> ::= { prtChannelEntry 9 }
>>>Here are proposed prtChannelInformation definitions for selected
>PrtChannelType values:
>> chLPDServer(8), -- ...
> -- prtChannelInformation entries:
> -- printer queue name
> -- name: QUEUE, mandatory, single value
> -- value is the ASCII queue name as
> -- described in RFC 1179
> chDECLAT(32), -- ...
> -- prtChannelInformation entries:
> -- port name
> -- name: PORT, optional, single value
> -- service name
> -- name: SERVICE, optional, single value
> -- Exactly one of port and service must be
> -- specified.
> chPortTCP(37), -- ...
> -- prtChannelInformation entries:
> -- TCP port number
> -- name: PORT, mandatory, single value
> -- value is encoded as a decimal number
> chBidirPortTCP(38), -- ...
> -- prtChannelInformation is same as chPortTCP
>>>