Ever since the IETF MIB-II (RFC 1213, March 1991), there have been
command objects (eg, 'ifAdminStatus') and companion status objects (eg,
'ifOperStatus') used for active management in IETF SNMP MIBs. SNMPv3
(RFC 257x) has strong user-based authentication and view-based access
control, so the argument that this is foolish (as opposed to using TLS
and IPP for active management) doesn't wash anymore.
Recent examples are: a) IETF Schedule MIB (RFC 2591, May 1999), which
provides scheduling for delayed management operations, by setting an
integer command object in ANY public or private MIB (by instance OID)
at a periodic or specific time; and b) IETF Script MIB (RFC 2592, May
1999), which controls remote loading and execution of management scripts
via SNMP, using 'smScriptAdminStatus' and 'smScriptOperStatus'.
Several years ago, Xerox defined a private MIB for Job Management which
uses a simple integer command and a companion parameters object. It's
based on ISO 10175 DPA and IEEE 1387.4 POSIX System Admin - Part 4:
Printing Interfaces, so it should look familiar (see excerpts below).
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
----------
XcmSimpleJobMgmtOperation ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The simple job management operation associated with
this conceptual row in the 'xcmSimpleJobMgmtTable'
and the 'xcmJobGenBasicTable' (XCMI Job Monitoring MIB), OR
this conceptual row in the 'xcmSimpleJobInterceptTable'
and the 'xcmJobClientId' object (XCMI Job Monitoring MIB)."
REFERENCE
"See: Section 4 'Print Utilities' (pages 71 to 212) of
POSIX Sys Admin (IEEE 1387.4 / Draft 8, October 1994).
See: OBJECT clauses in MODULE-COMPLIANCE macro of
XCMI Simple Job Mgmt MIB, for compliance info."
SYNTAX INTEGER {
none(0), -- No operation
other(1), -- Other operation
unknown(2), -- Unknown operation
-- POSIX - Job level operations (on/off-system jobs)
jobCreate(1401), -- 'pdpr' (submit job)
jobDelete(1402), -- 'pddelete' (destroy job)
jobList(1403), -- 'pdls' (list job attributes)
jobSet(1404), -- 'pdset' (set job attributes)
jobPause(1408), -- 'pdpause' (hold job)
jobResume(1409), -- 'pdresume' (release job)
jobInterrupt(1411), -- 'pdinterrupt' (interrupt job)
jobModify(1412), -- 'pdmod' (set job attributes)
jobPromote(1413), -- 'pdpromote' (set to next job)
jobRemove(1414), -- 'pdrm' (cancel job)
jobResubmit(1415), -- 'pdresubmit' (resubmit job)
jobManage(2401), -- for future extensions
-- POSIX - Document level operations (on/off-system jobs)
docDelete(1502), -- 'pddelete' (destroy document)
docList(1503), -- 'pdls' (list doc attributes)
docSet(1504), -- 'pdset' (set doc attributes)
docModify(1512), -- 'pdmod' (set doc attributes)
docRemove(1514), -- 'pdrm' (cancel document)
docManage(2501) -- for future extensions
}
----------
XcmSimpleJobMgmtEntry ::= SEQUENCE {
-- Simple Job Mgmt Info
xcmSimpleJobMgmtOperation XcmSimpleJobMgmtOperation,
xcmSimpleJobMgmtData XcmSimpleJobMgmtData,
xcmSimpleJobMgmtStatus XcmGenSNMPv2ErrorStatus,
xcmSimpleJobMgmtInProgress TruthValue
}
xcmSimpleJobMgmtOperation OBJECT-TYPE
SYNTAX XcmSimpleJobMgmtOperation
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The simple job management operation specified for
this conceptual row in the 'xcmSimpleJobMgmtTable'
and the 'xcmJobGenBasicTable' (XCMI Job Monitoring MIB).
Usage: Performing 'delete' (system operator) shall ALWAYS force
'xcmJobCurrentState' to 'completed(17)' immediately,
and MAY affect 'xcmJobAccountingBasicRowStatus'.
Usage: Performing 'remove' (user cancel) shall ALWAYS force
'xcmJobCurrentState' to 'completed(17)' in a timely fashion,
but shall NOT affect 'xcmJobAccountingBasicRowStatus'."
REFERENCE
"See: Section 4 'Print Utilities' (pages 71 to 212) of
POSIX Sys Admin (IEEE 1387.4 / Draft 8, October 1994).
See: OBJECT clauses in MODULE-COMPLIANCE macro of
XCMI Simple Job Mgmt MIB, for compliance info."
DEFVAL { none } -- no job mgmt operation
::= { xcmSimpleJobMgmtEntry 1 }
xcmSimpleJobMgmtData OBJECT-TYPE
SYNTAX XcmSimpleJobMgmtData (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The simple job management data specified for
this conceptual row in the 'xcmSimpleJobMgmtTable'
and the 'xcmJobGenBasicTable' (XCMI Job Monitoring MIB)."
REFERENCE
"See: Security Config, Account, and User groups in
XCMI Security MIB.
See: Section 6.6 'Security in DPA' (pages 38 to 39) of
DPA (ISO 10175-1 / Final Text, March 1996).
See: Section 4 'Print Utilities' (pages 71 to 212) of
POSIX Sys Admin (IEEE 1387.4 / Draft 8, October 1994).
See: OBJECT clauses in MODULE-COMPLIANCE macro of
XCMI Simple Job Mgmt MIB, for compliance info."
DEFVAL { ''H } -- no job mgmt data
::= { xcmSimpleJobMgmtEntry 2 }
> ----------------------------------------------------------------------
> From: kugler@us.ibm.com
> Date: Thu, 24 Jun 1999 14:18:48 -0600
> Subject: IPP> Re:Goals behind IPP 1.1 printer mgmt
>
> Peter wrote:
> >
> >Thanks for the reference to the "design goals" behind the effort. This
> >helps to
> >clarify to what degree printer mgmt should be included. If the intent is to
> >include a full mgmt protocol within IPP, then perhaps it might be good to
> >point this out since it remains somewhat ambiguous.
>
> Another way to look at it is that we're not inventing a new protocol at all,
> only extending the IPP Model with some new operations and attributes.
>
> >If the intent is to provide a
> >distinct subset then, what is the criteria for selecting that sub-set?
> >Certainly job related mgmt is desired, but as for printer management its
> >not
> >clear what the intent is.
> >
> >Assuming the intent is for IPP to be an IETF blessed protocol....Protocols
> >developed within the IETF address mgmt in the form of SNMP MIBS.
>
> I'm genuinely interested in how you propose to do these operations
> (Pause-Printer, Resume-Printer, Purge-Jobs, Shutdown-Printer, Enable-Printer,
> Disable-Printer, Space-Printer, etc.) with SNMP. I imagine we'd have to add
> some kind of new "Controls" group to the Printer MIB and do things like SET
> "ctrlShutdown" to TRUE in order to shutdown the Printer?
>
> >...
>
> -Carl
>