IPP>MOD - Print by reference

IPP>MOD - Print by reference

IPP>MOD - Print by reference

Harry Lewis harryl at us.ibm.com
Wed Jun 11 19:38:27 EDT 1997

Don, your question is crucial.

>Do we really need:
>1) An IPP Job Submission protocol
>2) An IPP Print by Reference standard
>3) An IPP Job Management protocol
>4) An IPP Print Capability Discovery protocol
>etc, etc, etc?

 I've tried to indicate similar feelings and been laughed out of the room
(figuratively) for suggesting 3 and 4 could be handled via the Job and Printer

I'm drawing a conclusion that much of the churn on these issues relates to the
separate worlds that Jay described so well in a previous note to the JMP (which
I am including here, out of context).

>Seriously, some of us firmly believe in the importance of "out of band"
>job monitors (ie, processes monitoring job progression without being
>intrinsically part of the printing process, a la Unix and VMS).  The
>only consistent way to indentify jobs is through jobOwner, and hence,
>this data must be available for as long as the job entry exists in the
>Those who will be using the Job MIB as an intrinsic part of the
>printing process are lucky (eg, Windows, OS/2, etc).  (We envy you,
>believe us!)  If someone can state a justifiable case for being able to
>monitor jobs with jobOwner, then great!  (And please do so soon!)
>Otherwise, we need that data for the duration of the job entry.

The point is, those who feel more comfortable with IPP as a "web based
submission protocol", by my observation, relate strongly with the intrinsic,
integrated print frameworks provided by Windows, OS/2 and similar operating
systems. In these environments, an end-to-end, all encompassing print protocol
is unnecessary because there is a query and status API (if you will) to
facilitate communication with the printer via some means other than the
submission protocol.

I think the desire for IPP to be all encompassing - query, submit, monitor,
control - stems from platforms which do not supply a "robust" print framework
as part of the native OS, today. Here, a robust replacement for LPR/LPD would,
appropriately,  include everything.

I don't want to ignore or prioritize any one platform (or family) but, if my
distinction is at all accurate, I think it would be a good idea to develop IPP
components that can work together in an end-to-end solution but also may
operate separately (at least the submission piece) in environments that do not
need or warrant a full solution.

>>> Harry Lewis <<<

More information about the Ipp mailing list