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

From: Tom Hastings <[email-masked]>
Date: Tue, 18 Feb 1997 23:24:21 PST

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.

---

From: [email-masked] (Robert Herriot)
Date: Thu, 20 Feb 1997 15:26:57 -0800

> a new session startup/teardown for each of the three calls.

My assumption is that the GUI from which the Print submission is made is
a different process from the one showing status in most cases.  In such an
environment, the Print submission GUI would probably not inform the
job status GUI about the changes. The primary issue is whether a print 
submission GUI (or command) would inform the user of the special case 
you site below where the printer is stopped and needs attention before it
will resume printing. 

You suggest that there would 3 calls, but I have optimized the Get Jobs
operation so that it can request printer status and jobs lists in the
same response.

>   won't know about it even though you asked to be notified of

There seem to be two possible solutions to the above problem:

    1) If a Printer receives a job with notification-events=printer-problem
    and the printer is currently stopped, it sends the most recent critical 
    event to the job's notification-address.  This actually raises the issue
    of whether a user's Print Status GUI should be able to indicate interest
    in the Printer Status, even when the user has no job's in the queue.
    In such a case, the GUI is up to date and doesn't need this new
    mechanism.

    2) The print request returns a special status, though for HTTP there
    is no reasonable special status value, so there would have to be some 
    other way, such as via a printer-state value, as you suggest.

We should probably discuss this at tomorrow's meeting.

---

From: Babak Jahromi <[email-masked]>
Date: Thu, 20 Feb 1997 15:36:48 -0800

Isn't what you call "print submission GUI" the everyday applications
people use? like Word, Excel, Corel, Quicken. etc. etc.?

So I wouldn't plan on changing any of it!

Babak

>-----Original Message-----
>From:	[email-masked] [SMTP:[email-masked]]
>Sent:	Thursday, February 20, 1997 3:27 PM
>To:	[email-masked]; [email-masked]
>Subject:	Re: IPP> MOD - Push back on simplifying Print operation response
>
>
>>

---

From: [email-masked] (Robert Herriot)
Date: Fri, 21 Feb 1997 13:01:23 -0800

> From [email-masked] Thu Feb 20 15:39:00 1997
> 
> 

I hadn't planned on changing the print submission GUI in Windows, but
the design is intended to allow Unix and possibly Java clients to submit
jobs with IPP attributes which a receiving Printer (i.e. Print Server)
can process.

We are unfortunately caught in a world where Windows client do attribute
processing and Unix servers sometimes need to do attribute processing
because Unix clients don't.

Bob Herriot