The minutes of the Model telecon, 2/14/97 say:
Item 3.
The Print Response will only have Job URL coming back, NO printer status or
job status. We need to keep each operation semantically simple - no
overloading of separate semantic operations onto one IPP operation. So we
will remove Job Status and Printer Status from the Print Response. Also, on
the Print Request, we will remove the "Requested Attributes". If a real
status operation is needed, it can be performed separately.
My concern is that either:
1. User friendly implmentations will make additional protocol calls
to get job and printer status. That means that each Print operation
will require three calls, not one. If we layer on HTTP that means
a new session startup/teardown for each of the three calls.
IPP will be another Internet burner (or at least perceived as one).
2. Client mplementors won't bother getting any status of the job or printer
either in the name of efficiency on the Internet or making their
implementation easier.
IPP will just be another "black hole" print protocol that doesn't
give any user feedback.
I've used a system (VMS) for 15 years that told you in its Print
operation whether your job was queued or started printing. With
so many desktop printers that have a low duty cycle, whether your
job started printing because the printer was idle or has to wait
is very useful.
If we elminate the status return on Print and client implementors
don't make the two additional protocol calls, the following
very unfriendly situatoin will happen:
If the printer to which you submitted your job was printing
another job and the printer needs attention, you will NOT get a
notification of this problem, even if you specify the
notification-events=printer-problem, because the printer problem
event happened BEFORE you submitted your job. So your job
will sit there until someone else fixes the problem and you
won't know about it even though you asked to be notified of
any printer problems!!!
Its so simple to have the Print operation return the job
and printer state and state-reasons in the response.
Lets reconsider this decision (and get others involved in this
discussion, especially the people who hate and those who love
HTTP).
Tom
P.S. I can probably live with elminiating the requested-attributes
on the grounds that such clients can make another call or probably
won't bother, since GUI clients will probably have shown the user the
interesting job attributes anyway.