You ask an important question: Why weren't admin operations, like
Shutdown-Printer, Pause-Printer, Resume-Printer, Purge-Jobs,
Disable-Printer, Enable-Printer, put into the Printer MIB?
While I agree that we could have added such operations to the Printer MIB,
why didn't we? After all the proposed Printer MIB was published as RFC 1759
in March of 1994. Here are my thoughts as to why these operations haven't
been added:
1. The security with SNMPv1 is not standardized, so that a vendor would be
exposing the printer (on the LAN):
a. To test this supposition, how many vendors implement the only management
control function in the Printer MIB: reset, which is OPTIONAL?
Of course SNMPv3 security changes the picture, but only recently.
2. The difficulty of adding anything to the Printer MIB is awesome, both
within the IETF printmib WG and the IESG:
a. The IETF printmib WG hasn't even been able to agree to clarify the
localization that different implementations have done (even though the
proposal added no new objects, but just clarified the current spec to
reflect what was actual practice). This is in spite of the participants
agreeing that the proposal agreed with current implementations.
b. The IETF printmib WG chair's view is that the Printer MIB is done and is
to move to a draft standard where it cannot have any extensions added. This
is in spite of there being a number of members who have voiced the opposite
opinion that we should just keep updating the Printer MIB as we need
extensions as new proposed IETF standards. I know of no participant beside
the chair that insists that the Printer MIB progress to draft status.
c. The IETF printmib WG chair has indicated that he doesn't want to add
anything to the draft Printer MIB that hasn't been thoroughly reviewed by
people who indicate positive approval on the pmp DL. We've proposed adding
the registration information for the job submission channel to the draft
Printer MIB to reference IPP/1.0 [RFC 2565, 2566]. So far the silence on
the pmp DL has been deafening. How could you possibly add a bunch of
administrative operations to the Printer MIB?
Tom
-----Original Message-----
From: Wagner,William [mailto:bwagner@digprod.com]
Sent: Thursday, June 24, 1999 14:42
To: 'PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com';
hastings@cp10.es.xerox.com; HPARRA@novell.com; ipp@pwg.org;
kjo@ess.mc.xerox.com; kugler@us.ibm.com
Subject: RE: IPP> Re:Goals behind IPP 1.1 printer mgmt
The "design goals" indicated that management aspects were excluded in
Version 1.0; this does not mean that there was ever any decision to include
them in a later version. Indeed, one of the reasons management was "put
aside" was that there was no consensus about what level of management was
appropriate to IPP. There was substantial concern on the part of those
familiar with the printer MIB that yet another device management path was
not a good idea.
Indeed, the types of management functions identified in the "goals" are not
device management but deal more with the logical printer, jobs, and who has
authority to do what. These are quite different from capabilities like
"shut-down printer".
To agree with adding such inappropriate capabilities for the sake of keeping
things going merely sanctifies the idea that IPP should be a management as
well as submission protocol, which is just not reasonable. The idea of
providing the capability for someone to shut down my printer over the
internet does not strike me as a desirable feature.
The Printer MIB has been updated. If, based on several years of SNMP based
printer management experience, additional device control features were
necessary, why were they not introduced as Printer MIB capabilities?
William A. Wagner (Bill Wagner)
Director, OEM Technology
> DPI Imaging Division
> NETsilicon Inc.
> 411 Waverley Oaks Road, #227
> Waltham, MA 02452
> Telephone 781-398-4588
> FAX 781-647-4460
>
-----Original Message-----
From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com
[mailto:PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com]
Sent: Thursday, June 24, 1999 3:30 PM
To: hastings@cp10.es.xerox.com; HPARRA@novell.com; ipp@pwg.org;
kjo@ess.mc.xerox.com; kugler@us.ibm.com;
PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com
Subject: IPP> Re:Goals behind IPP 1.1 printer mgmt
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. 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. If the use
cases behind the protocol require mgmt within the protocol which cannot be
addressed by SNMP then so be it. If the intent is develop a brand new mgmt
infrastructure just for some type of device, then historically the IETF has
frowned on this. Instead the philosophy has been to encourage a single mgmt
framework enabling interoperable mgmt applications. Having every protocol do
there own thing would clearly not be in the interest of the IETF. I would
not
like to see the IESG/IETF hold up IPP due to this type of issue.
In the interest of moving IPP ahead now, this does not seem to be a major
issue
at this point. The number of mgmt attributes seem minimal. It would be
interesting to consult with the area director to get his perspective and
guidance.
Peter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
RFC 2567, "Design Goals for IPP," states that version 1.0 does not
address printer management; the role of the Administrator. However, it
does not say that printer management is deprecated for all time. As a
matter of fact, someone reading RFC 2567 is defintely left with the
sense that printer management is in the domain of IPP, but was set
aside in order to get the first versin done (which is sensible).
So while there may be arguments on the merits of including printer
management in IPP, saying that it violates the initial premises of
what the protocol is, is incorrect. Either that or the PWG allowed
an inaccurate RFC to be published.
specifically, RFC 2567 says:
Section 4 Objective of the Protocol
The protocol to be defined by an Internet printing working group will
address the wants and needs of the end-user (V1.0). It will not, at
least initially, address the operator or administrator wants and
needs (V2.0).
Section 3.3. ADMINISTRATOR (NOT REQUIRED FOR V1.0)
...
The wants and needs of the administrator include all those of the
end-user and, in some environments, some or all of those of the
operator. Minimally, the administrator must also have the tools,
programs, utilities and supporting protocols available to be able to:
- create an instance of a printer
- create, edit and maintain the list of authorized end-users
- create, edit and maintain the list of authorized operators
- create, edit and maintain the list of authorized
administrators
- create, customize, change or otherwise alter the manner in
which the status capabilities and other information about printers
and jobs are presented
- create, customize, or change other printer or job features
- administrate billing or other charge-back mechanisms
- create sets of defaults
- create sets of capabilities
<< File: RE_ RE_ IPP_ MOD - comments on Carl's Set and Admin operations
registration pr.TXT >>
.......................................................................
Item Subject: WINMAIL.DAT
Couldn't convert Microsoft Mail Message Data item to text at a gateway.