PMP Mail Archive: PMP> Revisions to latest Internet Draft

PMP Mail Archive: PMP> Revisions to latest Internet Draft

PMP> Revisions to latest Internet Draft

Lloyd Young (
22 Mar 97 7:02:31 EST

A conference call was conducted on Friday March 21st to
discuss changes that are required to be included in the
Printer MIB Internet Draft before it is submitted to
the IETF prior to the Memphis IETF meeting.

1. prtStorageRefSeqNumber, prtDeviceRefSeqNumber and prtConsoleLightIndex which
are indexes to begin at 1
instead of 0. (Paul Gloger's e-mail dated 3/19/97)
2. The description for chAppSocket(12)changed back
to description contained in RFC1759:

-- a bi-directional, LPD-like
-- protocol using 9101 for
-- control and 9100 for data.
-- Adobe Systems, Inc.
(Ron Bergman's e-mail dated 3/290/97)
3. The end of the description of prtConsoleDisplayBufferIndex and
prtConsoleLightIndex changed to read:
"...values are normally expected to remain stable across
successive power cycles."
(Ron Bergman's e-mail dated 3/20/97)
4. (Ron Bergman's e-mail dated 20-Mar)
Order of objects in the specification
a. We agreed that the OBJECT-TYPE descriptions of the objects in the General
table should be changed from being sprinkled throughout the document in the
appropriate group, to appearing in table order immediately after the General
Table. Randy had started this reorganization from the RFC 1759 order. No
OIDs are changed in this re-ordering, only the order of appearance of the
OBJECT-TYPE descriptions of the objects.
b. We agreed that the OBJECT-TYPE descriptions in the General table should
have a block comment that indicates something about the following objects,
such as that they are default indexes in various groups or are objects in a
particular group for which there is only one instance per Printer.
c. Each line in the PrtGeneralEntry SEQUENCE would have an added column as a
comment, indicating the group in which the object belongs. Perhaps the
current lead sentence: "Note that not al of the objects in this sequence are
in the general printer group." could have the additional sentence: "The
group in which each object is a member is indicated as a comment below."

PrtGeneralEntry ::= SEQUENCE {
-- Note that not all of the objects in this sequence are in the
-- general printer group. The group in which each
-- object is a member is indicated as a comment below.
prtGeneralConfigChanges Counter32, -- General
prtGeneralCurrentLocalization Integer32, -- General
prtGeneralReset PrtGeneralResetTC, -- General
prtGeneralCurrentOperator OCTET STRING, -- ResponsibleParty
prtGeneralServicePerson OCTET STRING, -- ResponsibleParty
prtInputDefaultIndex Integer32, -- Input
prtOutputDefaultIndex Integer32, -- Output
prtMarkerDefaultIndex Integer32, -- Marker
prtMediaPathDefaultIndex Integer32, -- MediaPath
prtConsoleLocalization Integer32, -- Console
prtConsoleNumberOfDisplayLines Integer32, -- Console
prtConsoleNumberOfDisplayChars Integer32, -- Console
prtConsoleDisable INTEGER, -- Console
prtGeneralStartupPage PresentOnOff, -- AuxiliarySheet
prtGeneralBannerPage PresentOnOff, -- AuxiliarySheet
prtGeneralPrinterName OCTET STRING, -- General
prtGeneralSerialNumber OCTET STRING, -- General
prtAlertCriticalEvents Counter32, -- Alert
prtAlertAllEvents Counter32 -- Alert

5. The new objects should be assigned without gaps from RFC 1759, so that
prtGeneralStartupPage should be re-numbered at 14, not 16,
prtGeneralBannerPage 15, not 17, PresentOnOff at 16, not 18,
prtGeneralPrinterName at 17, not 19, prtGeneralSerialNumber at 18, not 20,
prtAlertCriticalEvents 19, not 21, prtAlertAllEvents at 20, not 22.

6. Delete the prtAutoSwitching object as per Bob's 3/18 e-mail, but remove
the OID gap, changing inputNextIndex from 26 to 25:

4) (pages 76-77) Input Switching Group: These objects have been worked over
on the mailing list quite a bit, mainly by Angelo Caruso (Xerox) and
myself. The agreed upon changes can be found at which is repeated
below (without revision marks [but changing the OID from 26 to 25 - TNH]).

-- The Input Switching Group

-- The input switching group allows the administrator to set the
-- input subunit timeout for the printer and to control the automatic
-- input subunit switching by the printer when an input subunit becomes
-- empty.
-- This group is optional. However, to claim conformance to this group,
-- it is required to implement every object in the group.

prtInputMediaLoadTimeout OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write MIN-ACCESS read-only STATUS current DESCRIPTION "When the printer is not able to print due to a subunit being empty or the requested media must be manually loaded, the printer will wait for the duration (in seconds) specified by this object. Upon expiration of the timeout, the printer will take the action specified by prtInputNextIndex.

The event which causes the printer to enter the waiting state is product specific. If the printer is not waiting for manually fed media, it may switch from an empty subunit to a different subunit without waiting for the timeout to expire.

A value of (-1) implies 'other' or 'infinite' which translates to 'wait forever'. The action which causes printing to continue is product specific. A value of (-2) implies 'unknown'." ::= { prtInputEntry 24 }

prtInputNextIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write MIN-ACCESS read-only STATUS current DESCRIPTION "The value of prtInputIndex corresponding to the input subunit which will be used when this input subunit is emptied and the timeout specified by prtInputMediaLoadTimeout expires. A value of zero(0) indicates that auto input switching will not occur when this input subunit is emptied. If the timeout specified by prtInputLoadMediaTimeout expires and this value is zero(0), the job will be aborted. A value of (-1) means other. The value (-2) means 'unknown' and specifically indicates that an implementation specific method will determine the next input subunit to use at the time this subunit is emptied and the timeout expires. The value(-3) means input switching is not supported for this subunit." ::= { prtInputEntry 25 }

7. Joe Fillion's e-mail of 3/21: Pg. 28. Number 2 - "... i.e., not a "PostIt". ..." I believe PostIt is a registered trademark. Elsewhere in the document you use (tm). I don't know what is appropriate here but this doesn't look right.

We agreed to use a more generic description, such as "sticky note".

8. Joe Fillion's e-mail of 3/21: Pg. 98. The description for prtMarkerSuppliesIndex is not a complete sentence. It was in rfc1759.

The text from RFC 1759 is:

prtMarkerSuppliesIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this marker supply. Although these values may change due to a major reconfiguration of the device (e.g. the addition of new marker supplies to the printer), values are expected to remain stable across successive printer power cycles." ::= { prtMarkerSuppliesEntry 1 }

The rest of Joe's editorial comments will be considered by the editor after the Internet-Draft is submitted.

Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C14L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW internet: Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740