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

From: JK Martin <[email-masked]>
Date: Mon, 5 May 1997 17:26:09 -0400 (EDT)

Carl-Uno wrote:

> CBM> The first set of IPP implementations will most certainly be of type
> CBM> print server that can front for any type of printer, including a $150
> CBM> printer which is hooked up directly to the print server machine.
> CBM> The next stage is more likely to include IPP servers embedded in
> CBM> print devices connected to the network, and whether that networked 
> CBM> printer fits on a desktop or not seems really irrelevant.

Ok, this sounds better to me.  (Does everyone else agree with this??)

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."

> CBM> I do not think that anybody is neglecting the intranet type scenarios.

The phrase "neglecting the intranet" may not be the best choice of words
here.  With all due respect, the IPP may be "neglecting to provide a
reasonably simple and efficient network printing protocol for the intranet."

I'm hoping the Model team can start working more closely with Netscape
(as briefly discussed during today's telecon), whereby we investigate the
approach of adding a new standard protocol to web browsers.  This approach
could end up making all parties happy in the end.

	...jay

---

From: [email-masked] (Robert Herriot)
Date: Mon, 5 May 1997 14:40:29 -0700

> From [email-masked] Mon May  5 14:31:42 1997
> 
> Carl-Uno wrote:
> 

I agree. I have always made the same assumptions as Carl-Uno.

---

From: [email-masked]
Date: Mon, 05 May 1997 17:09:28 PST

Jay Martin wrote, in part:

> Our experience has indicated that within the Enterprise, all network
> printers must be front-ended by a spooling server; direct printing from
> a client system to a network is highly discouraged, or even forbidden.
> 
> Does this experience match others' in the Enterprise?  I'd really like
> to hear from other people on this question, either publicly or privately.

As background, so you'll know where my comments are coming from,
Northlake makes printer interface software for the Digital OpenVMS
environment.  It may seem we're a little off the beaten path, but
these systems (and our software) see service on both client and server
side of our customers' printing strategies, on heterogeneous networks,
departmental to enterprise scales, low-end to production printing, so we
cover a fair amount of ground. 

A couple comments: 

 1. No, I see no such consistency in our customers.  Many have chosen
    server architectures, but many prefer less centralized approaches.
    In support of this, I would point out all the multi-protocol network
    printer interfaces out there -- they're there because customers
    insisted on them, and what they do is make the printer accessible to
    multiple systems on some good-sized networks. 

 2. When you talk about a preference for server-based as opposed to
    decentralized configurations, you ought to ask why.  A big part
    of the answer is that today's clients and printers often behave
    unreliably; also, they have problems with sharing.  Interposing a
    server system helps with these problems, but at considerable cost. 
    Thing is, better printing protocols would help a lot, too.  I'd hate
    to give up on this as a goal for IPP. 

 3. Assuming your printer is capable of spooling is no panacea.  For
    example, just recently we spent a lot of time with one of our
    customer tracking down an intermittent failure (happened only at
    night with the lights out, you know) sending print jobs to a UNIX
    system acting as a print server -- it was running out of disk space
    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. 

Jay, what I'm reading into your comments is the notion that assuming a
spooled server simplifies that protocol requirements.  I question how
true this is.  The example of storage constraints (client or server
side) may be typical -- a robust protocol has to deal with similar issues
either way.

In our environment, we've been very successful with decentralized
printing configurations.  Admittedly, we have the advantage of a relatively
robust, capable client system, and we tend to gloss over the issue of
fair sharing of the printer.   When they can be made to work reliably,
these configurations offer advantages in flexibility and cost.  I'd like
to see IPP make them work better, not bypass them. 

::  David Kellerman         Northlake Software      503-228-3383
::  [email-masked] Portland, Oregon        fax 503-228-5662