Subject: Re: IPP> Lost print Jobs

From: [email-masked]
Date: Tue, 7 Jan 1997 15:57:35 -0500

Classification:
Prologue:
Epilogue:

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/07/97 01:51
PM ---------------------------

        ipp-owner @ pwg.org
        01/07/97 01:28 PM

To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet
cc:
Subject: Re: IPP> Lost print Jobs

>This seems a reasonable question and a valid response. I am not
>pleased with the response and its implications. How large is a maximum
>size job? Do we provide some ipp mechanism to flag overflow errors?
>Does an IPP printer  need a hard  disk?  Or are we indeed goin to NT's
>being used as IPP servers (which I though was the opposite the desired
>direction?)

I guess that we all have our own view  -- I thought that NT's (or)
eqivalent systems) as IPP servers was the preferred direction. Printers
supporting IPP would have a server under the covers. I never viewed IPP
as a viable protocol for a low end printer, no matter what the transport!

______________________________ Reply Separator _________________________________
Subject: IPP> Lost print Jobs
Author:  [email-masked] at Internet
Date:    1/7/97 1:01 PM

Classification:
Prologue:
Epilogue:

I think it was Scott that asked the following question:

"In HTTP is it possible for the client to send a job, the printer
bogs down in printing it, it never responds, and the client
times out or the HTTP server stack times out  waiting for
the CGI script to finish, and then resends the job and the job
is printed twice?"

I believe that using HTTP (or any other simple request-response)
protocol will work as long as we  make sure that each action is
atomic, and that client-server operations are asynchronous to
server-device operations.  For example:

  If a print job is submitted, the server responds positively once
the message is parsed correctly and the job is safe-stored.  The
response contains the job-id assigned by the server for use in
subsequent operations.

Printing occurs asynchonous to the above request/response
flow.  If the printer jams, or for some other reason cannot
complete the print job, the orginal request is not hung up - it has
 already been responded to. A subsequent request can check
status of the job.

Assuming a reliable transport, responses should not get lost.

It seems to me that if a device implements the IPP model, it must
be capable of queuing at least one job so that this asynchonicity
can be maintained. If the printer cannot do this, i.e. it prints while
receiving the job then either we claim it is not an IPP printer, or
all bets are off on dealing with Scott's problem.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 7 Jan 1997 12:23:58 PST

If a printer cannot spool and prints while it is receiving the job,
then the HTTP responses might be different: if another job is already
printing, a print request (POST) might result in an immediate error
(503) with a Retry-After response.

The current Proposed Standard HTTP has no particular timeouts defined
for delays, but there are probably proxy implementations that timeout
if they can't transmit a POST in a reasonable amount of time
(Minutes).

The problem would go away with third-party-print (client pushes URL &
credentials to server which fetches document), since range retrieval
could be used for partial fetches of print job material.

Larry