Subject: IPP> Re: Additional IPP comments -Reply

From: Roger K Debry <[email-masked]>
Date: Fri, 4 Apr 1997 15:54:20 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
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@internet, ipp @ pwg.org@internet, rsproull @
lady-alice.East.Sun.COM@internet, hastings @ cp10.es.xerox.com@internet
cc: fhanzel @ cp10.es.xerox.com@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...

END USER
     1. IPP - end user job submission

MANAGEMENT
     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
functions.

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: [email-masked]
W: http://www.novell.com
************************************************************

---

From: [email-masked] (Bill Wagner)
Date: Sat, 5 Apr 1997 14:47:47 -0500

I believe that there is implicit agreement from most quarters with 
     Scott's contention that " There should be different tracks for 
     Management Facilities vs. End User Facilities". However, it is 
     something that must be specifically stated  and perhaps oft repeated 
     to counter the tendency toward "functionality creep".
     
     I contend that IPP is, first and foremost, a job submission mechanism. 
     The functions of printer discovery, feature identification, job 
     progress monitoring and limited job control are to be provided only to 
     the extent necessary to support the end user in job submission. 
     
     The IPP should not be intended or structured to replace the Printer or 
     Job Monitoring MIB's. Conceptions to the contrary tend only to suggest 
     the fickleness of the standards process and discredit all of our 
     activities.
     
     The Printer MIB, however, does not deal with jobs. And the Job  
     Monitoring MIB does not provide job control (which was considered part 
     of job submission). Therefore, some specific limited end-user oriented 
     specific job management functions do fit in IPP. It is not clear that 
     these should include the type of administrator-oriented jobs 
     maintenance provisions Scott suggests. This should be clarified.

     If the need is felt for a matching printer management capability, one 
     not linked to SNMP, this is a different activity. Perhaps it is one 
     which will use the already defined and largely implemented MIB's with 
     some different form of transport.
     
     Bill Wagner, DPI

---

From: Harry Lewis <[email-masked]>
Date: Mon, 7 Apr 1997 12:01:06 -0400

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

Bravo - Bill! Your comments regarding IPP, the Printer MIB and the Job MIB are
very well stated. I agree with you, especially your final paragraph. Transports
will change. And the platform independence of the WEB and IPP are opportunities
not to be missed. I'm not opposed to enhancing solutions and functionality,
either, but we deserve to keep an eye on compatibility with the printer and job
MIB efforts and to be careful about "functionality creep".

It is curious that we have seen a lot of push from IETF members to map IPP to
LPD but no discussion of mapping to the printer MIB. This supports your
observation of IPP as foremost a submission protocol. I believe IPP can (and
should) go beyond submission, but, anyone involved in embedded implementations
knows there MUST be compatibility and a migration path.

---- Forwarded by Harry Lewis/Boulder/IBM on 04/07/97 09:32 AM ---

        [email-masked]
        04/05/97 03:39 PM

To: [email-masked]@internet
cc:
Subject: Re: IPP> Re: Additional IPP comments -Reply

     Bill Wagner, DPI