1. I think it was (is) important to align IPP and the Printer MIB, Job MIB
w.r.t. migration and compatibility. I don't think it is necessary to enforce
complete division of labor, however, among the protocols. It seems natural, to
me, for one or more approaches to strengthen or "win out" while others "fade".
2. One of the pitfalls of SNMP was (is) that it's an IP protocol. We've had
several parties state several times that lack of SNMP over the parallel channel,
for example, limits total adoption of the Printer MIB for things like self
configuring drivers.
3. The extensions under discussion are operator based which is different from
infrastructure management (i.e. SNMP's arena).
4. Full extension, growth and utilization of the Printer and Job MIBs has been
relatively hindered by shyness related to IETF constraints or reaction (i.e. the
Job MIB is great... but they didn't "like" it.
5. I think a "total solution" will consist of a complimentary set of protocols
and technologies addressing service and capabilities discovery, print submission
and monitoring, notifications, asset awareness and administration. I would
characterize the pause/stop printer type operations as a pro-active forms of
monitoring... not system administration, so I think they are appropriate for
IPP.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
"Carl-Uno Manros" <carl@manros.com> on 06/24/99 05:41:49 PM
To: "Wagner,William" <bwagner@digprod.com>,
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, Carl
Kugler/Boulder/IBM@IBMUS
cc: (bcc: Harry Lewis/Boulder/IBM)
Subject: RE: IPP> Re:Goals behind IPP 1.1 printer mgmt
Bill,
There are always more then one side to view things. The debate about where
you put admin functions have been going on for decades and I am not sure
that everybody has declared SNMP the winner yet.
ISO, when they defined DPA, decided to put the same kind of functionality
that Carl has now proposed, into DPA even though ISO had its own management
protocol as well.
I believe that people that have implemented these features in DPA have found
them quite useful and would like to see them included in IPP as well. If
they want these features, and we tell them that they are out of scope for
IPP, they may well go ahead and implement them as their own proprietary
extensions instead, a much worse case in my view.
Another observation is that a number of companies have now started doing
device management using proprietary web access solutions. Isn't this an
indication that maybe the days of SNMP are counted anyway?
Carl-Uno
> -----Original Message-----
> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
> Wagner,William
> Sent: Thursday, June 24, 1999 2:42 PM
> 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.
>