>Do we really need:
>
>1) An IPP Job Submission protocol
>-and-
>2) An IPP Print by Reference standard
>-and-
>3) An IPP Job Management protocol
>-and-
>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
MIBs.
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
>agent.
>
>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 <<<