IPP> Re: Additional IPP comments -Reply

IPP> Re: Additional IPP comments -Reply

IPP> Re: Additional IPP comments -Reply

Roger K Debry rdebry at us.ibm.com
Fri Apr 4 15:54:20 EST 1997

Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080

I'm not saying that I agree or disagree with having a separate manegement
standard.  However, I would note that management takes on many forms.  The
printer MIB and the Job Monitoring MIB DO NOT meet all of the needs for
managing a printing system.  I view them ONLY as providing monitoring functions.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 04/04/97 01:49
PM ---------------------------

        ipp-owner @ pwg.org
        04/04/97 12:42 PM

To: jkm @ underscore.com at internet, ipp @ pwg.org at internet, rsproull @
lady-alice.East.Sun.COM at internet, hastings @ cp10.es.xerox.com at internet
cc: fhanzel @ cp10.es.xerox.com at internet
Subject: IPP> Re: Additional IPP comments -Reply

I like this discussion about "mangagment facilities" and IPP v1 or v2.
I first summarize some of the comments that have been made and then
I add my own comments below:

Bob writes:
> 2. I strongly recommend *not* including in IPP a complete set of printer
>  management facilities.  I think this should be a totally separate standard
> (named IPMP or something).  The reasons are:
> ...

Tom writes:
> I think that the entire IPP group is in agreement here.  We keep talking
> about IPP V2.0 for management facilities, so IPP V1.0 will NOT have
> any management facilities.

Bob writes:
> Your comment about IPP V2.0 for management is *directly opposed* to
>  what I recommended above, which is to keep them separate for the
>  reasons given above.  It is likely to require that all print driver clients
>  who use 1.0 will have to upgrade, even if they don't need any
>  management features. My view is that these should be separate
>  protocols that share some common terminology (printer, print job, etc.)
>  but are allowed to evolve separately.

Jay writes:
> I completely agree with Bob Sproull.  Another advantage to keeping
> printing separate from management is that the printing specs should
> advance more rapidly.
> It is only natural to consider the ramifications of management while
> developing the printing standards, but the specs should be on entirely
> separate tracks.

My comments:

I WHOLEHEARTEDLY agree with Bob and Jay.  There should be different
tracks for Management Facilities vs End User Facilities.  This is such
a good idea, we are doing that right now!  There are at least THREE
tracks right now...

     1. IPP - end user job submission

     2. Job Monitoring MIB - job monitoring via SNMP (accounting)
     3. Printer MIB - printer management via SNMP

If we want to "add" Administrative or Management operations, they
should be defined separately since (as Bob says) not all client
implementations will want to take on this burden and support these
new operations.  In other words, IPP V2.0 should never have
Admin or Management operations.

However, we may want to add some "end user job control"
operations to IPP.  Right now IPP has no "move" or "modify my
job" or "pause/resume my job" or " hold/release my job".  I can
some of these as part of IPP past v1.0.  Sometimes we loosly call
these management functions, however they are end user job control

Scott Isaacson
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com

More information about the Ipp mailing list