Subject: Re: IPP> MOD - Push back on simplifying Print operation resp

From: [email-masked] (Bill Wagner)
Date: Wed, 19 Feb 1997 09:32:02 -0500

I think Tom has made some valid points. I would request more 
     information on why "We need to keep each operation semantically simple 
     -no overloading of separate semantic operations onto one IPP operation." 
     
     Without indicating the operational requirements for this dictate, it 
     seems more like a religious statement than a clear requirement. On the 
     other hand, the returning of status information which would be 
     requested anyway seems quite reasonable.
     
     Bill Wagner, DPI

     ______________________________ Reply Separator 
     _________________________________
     Subject: IPP> MOD - Push back on simplifying Print operation response
Author:  Tom Hastings <[email-masked]> at Internet
Date:    2/18/97 11:24 PM

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.