IPP Mail Archive: Re: IPP> Re: Additional IPP comments -Reply

Re: IPP> Re: Additional IPP comments -Reply

Harry Lewis (harryl@us.ibm.com)
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 ---

ipp-owner@pwg.org
04/05/97 03:39 PM

To: ipp@pwg.org@internet
cc:
Subject: Re: IPP> Re: Additional IPP comments -Reply

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