Subject: IPP> Re: MOD - RE: Base printer implementation requirements

From: Scott Isaacson <[email-masked]>
Date: Tue, 06 May 1997 14:47:37 -0600

Jay writes:

>>> JK Martin <[email-masked]> 05/05 3:26 PM >>>
> As far as deriving base constraints goes, to me the real question is:
>
>    Must an "IPP Printer" must be able spool print jobs?
>
> I would like to see an answer of "Yes", but clearly this is where desktop
> printers (and many, if not most, network printers) fail to perform.  And I
> believe this is usually the reasons behind most case of "we can't do that
> due to printer limitations."

I fail to see why a "yes" answer matters?  If someone decides to implement
IPP in a printer that can not spool, what changes?  If it is too busy
processing one job and another comes in from another client, it returns a
"busy" or a "out of spool space"  just as in the case where a server
implementation supports 2000 spooled jobs and the 2001st job comes in.  When
it is asked how many "queued jobs" it answers "0" or "1" depending if it is
processing a job or not.  If it is too busy to even establish a client
connection (it only supports one at a time) then the second one times out,
just as if it supported 500 client connection and the 501st comes in and
fails and experiences a time out.  

Will anybody implement IPP in a printer like this?  Probably not.  Does the
model preclude them from doing so?  No.   Will this type of printer ever be
used as as a shared network printer?  Probaly not, but if it is, and it does
not embed IPP then it can be front ended by a "server" that does.

> And I
> believe this is usually the reasons behind most case of "we can't do that
> due to printer limitations."

I believe the only time we should change the model or make decisions based
on info like "we can't do that"  is when we are talking about what exists in
reality today and the near future - like "many printers that support a PDL
like PostScript can't support overriding PDL instrcutions with exteranal
attributes"  In view of that statement, we must "work" in the exising world
and not just some future fantasy world.   I don't want to succumb to the
argument that since the printing spectrum is soooo wide, we can not do one
thing or the other since it fails at the exteme ends.  IPP should fall
comfortably in the middle of the spectrum and all for niche extensions to
support the fringes of the spectrum.

Scott

Scott

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 06 May 1997 15:07:57 -0600

Dave,

>>> <[email-masked]> 05/05 7:09 PM >>>
>  3. Assuming your printer is capable of spooling is no panacea.  For
>     .....
>    when too many jobs queued up.  I'd say if you're careful to consider
>    problematic scenarios in your protocol design, not just the happy
>    case, the spooled printer isn't that much better off than the
>    non-spooled one. 

Good explaination of why spooling maxing out is a common problem wether the
spool size is 1 job or 5 million jobs.  Once it maxes out, then there is a
common error handling problem.   The "no spooling" case is just on the very
low end of the specturm of the "spooling" case.

Scott

---

From: Peter Zehler <[email-masked]>
Date: Wed, 7 May 1997 08:15:42 PDT

All,
>From Jay's and Scott's conversation.
____________
<snip>
JKM> As far as deriving base constraints goes, to me the real question is:
JKM>
JKM>    Must an "IPP Printer" must be able spool print jobs?
JKM> I would like to see an answer of "Yes", but clearly this is where desktop
JKM> printers (and many, if not most, network printers) fail to perform.  And I
JKM> believe this is usually the reasons behind most case of "we can't do that
JKM> due to printer limitations."

SAI>I fail to see why a "yes" answer matters?  If someone decides to implement
SAI>IPP in a printer that can not spool, what changes?  If it is too busy
SAI>processing one job and another comes in from another client, it returns a
SAI>"busy" or a "out of spool space"  just as in the case where a server
SAI>implementation supports 2000 spooled jobs and the 2001st job comes in.  
<snip>
SAI>Will anybody implement IPP in a printer like this?  Probably not.  Does the
SAI>model preclude them from doing so?  No.   Will this type of printer ever be
SAI>used as as a shared network printer?  Probaly not, but if it is, and it does
SAI>not embed IPP then it can be front ended by a "server" that does.
__________
PJZ:
I have been listening.  I am prototyping IPP on a printer that can only accept and process a job at a time.  I chose this printer specifically to check the lower bounds of an IPP implementation.  I have to agree with Scott.   Spooling is not the printer feature that determines if a printer is capable of supporting IPP.  IPP will be sitting (somewhere) on top of TCP.  The flow control capabilities of this layer of the protocol should allow me to gate the inflow of PDL data while the printer "catches up" with the PDL stream.  I also have the job-k-octets to limit the job size for a low-end printer.  
This class of printer will not be IPP feature rich.  The printer itself will not be feature rich.  It is true some clients will be denied service while the printer is busy. All services must handle the "capacity + 1" problem.  IPP seems to handle this problem.  There is still the issue for the application to determine when it should time out.  IPP level print job submission operations should help accomodate application level timeout detection.  We will have to see where the print operation semantics discussion ends up.
Will this type of printer be used as as a shared network printer?  Yes it can, if the workload is low enough.  If IPP service is not available often enough for the site's needs, an IPP spooler can be put between the client and the printer.  A bigger printer could also be used.
The factor that will determine if a printer can be IPP compliant will be the complexity of IPP, IPP conformance specification, and the available printer resources that are available for IPP.
_________________________________
<snip>
Pete

---

From: JK Martin <[email-masked]>
Date: Wed, 7 May 1997 15:39:10 -0400 (EDT)

Peter,

> I am prototyping IPP on a printer that can only accept and process a
> job at a time.  I chose this printer specifically to check the lower
> bounds of an IPP implementation.
>
> [...]
>
> It is true some clients will be denied service while the printer is
> busy. All services must handle the "capacity + 1" problem.  IPP seems
> to handle this problem.

How does IPP handle the problem where a printer implementation only
accepts a single connection at a time, where all other connection
requests are denied (or ignored) until the current job has completed?

In the marketplace today, there are *lots* of printers with network
interfaces that accept only a single LPD connection at any one time;
if a job (or any other LPD service request) is being handled, any
connection attempt simply fails with a TCP-level "time-out" indication.

As client software developers, this situation gives us tremendous grief,
as we are unable to discern between "the printer is too busy to answer
you right now" and "the printer is not responding on the network".

It is my ardent hope that printer vendors strive to develop network
printers capable of saying "I'm too busy right now, try later", rather
than simply ignoring the connection attempt.

> There is still the issue for the application to determine when it
> should time out.  IPP level print job submission operations should help
> accomodate application level timeout detection.

Thanks for raising the issue of application time-out, Peter.

To me, this aspect of the IPP protocol could be the kiss of death,
whereby submission of a print job is handled in multiple, independent
transactions.

Lest we forget, one of the *biggest* problems facing the average user
is controlling time-out values for printers when those printers do not
have a decent protocol with which to determine when a job is done (or
has aborted, or whatever).  Our experience has been that users absolutely
despise such required "fine tuning" of a printer's operational parameters.

How will this problem scenario be handled by the typical IPP implementation
within a network printer with no spooling capability (ie, can process only
a single job at a time):

  1.  Client executes a "CreateJob" operation on the printer

  2.  Client sends the first of three documents to the printer.

  3.  Client crashes...never to return.

If the answer is something like:

  "The printer will have to use an internal time-out parameter to know
   when to abort an in-process job submission, and that parameter will
   have to be exposed to the system manager for potential modification."

then I'd suggest we haven't really come very far in advancing network
printing.

This is probably my biggest concerns with using HTTP as the basis for
a network printing protocol, at least when an operation spans multiple
independent transactions between the client and the server.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------