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 at hp-roseville-om3.om.hp.com
[mailto:PETER_E_MELLQUIST at hp-roseville-om3.om.hp.com]
Sent: Thursday, June 24, 1999 3:30 PM
To: hastings at cp10.es.xerox.com; HPARRA at novell.com; ipp at pwg.org;
kjo at ess.mc.xerox.com; kugler at us.ibm.com;
PETER_E_MELLQUIST at 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.