Subject: IPP>MOD -Reply

From: "Scott A. Isaacson" <[email-masked]>
Date: Thu, 27 Feb 1997 11:31:18 -0700

>>> <[email-masked]> 02/25/97 03:03pm >>>
> If we intend the protocol to support Printers which cannot spool jobs,
> or which, have limited spool space, then I think we need an attribute
> which expresses this fact so that a client can use the protocol
>  appropriately for that client. I've spent some time reviewing the
>  proposal I made at the San Jose meeting with our control unit
>  developers. While depending upon the underlying wire protocol
> to handle the pacing of data works okay when there is infinite spool
>  space, we strongly believe that an application layer protocol, such as
>  that which I suggested, is required when the printer must print while
>  receiving data.  We have implemented a very similar scheme for TCP/IP
>   IPDS printers and it works quite well.

We discussed this at the Wednesday call.  The discussion wound up
being a requirements discussion.  Which are the following requirements
are part of IPP requirements:

1. Receive all errors and events over a separate channel
from the job submission channel

2.  Receive all errors and events over the job submission channel
synchronously (in every response to every request there might be
errors and events that have happened)

3. Receive all errors and events over the job submission channel
asynchronously (some async packet comming back indepented of the
job submission or query requests and responses)

If you realize that IPP allows for events and errors to be reported via our
simple notification attributes over some other channel using some other
mechanism, here is a solution to your scenario from the telecon:

A user submits a job and is in the process of transfering segments.  The
printer started printing the job since it had to (it doesn't spool) or it
choose to (for some performance reason).  There is a problem where
the printer can't print any more (jam lets say).  The buffers are filling up,
and so the client can't send any more data until the jam is cleared.  All the
user knows is that it can't write any more.  It doesn't know why, it just
knows that it can't.  The device could send an printer error out which is
then routed to any interested party.  The end user, if they were
interested would receive the event (via the method defined then the
supplied URL), or if it had not registered intereset it could always go poll
using a Get Attributes operation on the printer.  In either case, it sees the
device is stopped because of a jam.  Then the human can decide to
either clear the jam physically which would allow for more segments to
be sent, or the end user could just simply cancel the job since it is
waiting for the transport to clear and probably stopping other printing
from happening on the same channel.

This solution seems to solve the problems generated in the scenario, by
staying with requirements level 1 (not 2 or 3).

Scott