Subject: Re: IPP> MOD - Suggestion: add RequiredResources call...

From: JK Martin <[email-masked]>
Date: Sat, 3 May 1997 23:54:41 -0400 (EDT)

Tom,

You've done a great job in describing your position in your response
to Harald on this topic.  It wasn't until I read your fine posting
that it finally dawned on me where I was having some problems with
the directions the IPP was taking.

It is possible to describe any one of the vast majority of today's
printing systems as having one of the two following models:

  Model A:  client ---> printer

  Model B:  client ---> spooling server ---> printer

Where I think IPP gets into real trouble is that it tries to achieve
these goals simultaneously:

  1.  Provide all printing features required by 99% of the world's
      population;

  2.  Assure that all such defined features can be implemented in
      a desktop printer costing $150 ($119.99 at Wall-Mart);

  3.  Make all of this happen by mid-1997.

How many times have we heard statements like:

  "We can't go that route, it's not possible in a desktop printer."

Seems like we had better come to grips with the possibility where IPP
should only attempt to address "Model B" above; then, as hardware
technology decreases in price, allow desktop printers to catch up.

That is, let IPP address the "client ---> spooling server" portion of
the model, and develop a cheap, simple, and fast protocol to deal with
the "spooling server ---> printer" side of the model.

Sure, one could take sufficient time and resources and ultimately
define a printing approach that scales from my mother's direct-attached
ink-jet printer all the way up to the 200+ page-per-minute laser screamers
in Fortune 10 companies, but the age-old question arises:

	"Why?"

Just because you CAN do something doesn't mean you necessarily SHOULD.

My company has plenty of experience with large Enterprises using LPD
on every type of client in the Enterprise--including Windows 3.1--that
feed large spooling servers.  These servers then use a plethora of
protocols to effect the print jobs on a wide variety of both network
and direct-attached (serial/parallel) printers.

And you know what?  Those companies are crying for a standard protocol
to talk to the printers.  Lack of features on the client side is not
even on the horizon for them.

One last thing:

>>KISS.....
>
>We agree.  The hard part is deciding for which party to make it simple:
>the client or the server/printer.

It's starting to look like NEITHER side is going to be simple.  And I
really believe that at least one side CAN be simple...if we step back
and re-evaluate some of the directions we've been taking.

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

---

From: Scott Isaacson <[email-masked]>
Date: Mon, 05 May 1997 10:27:39 -0600

Jay,

You wrote:

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

>>> JK Martin <[email-masked]> 05/03 9:54 PM >>>
> 
>  ...
>  ...

I was under the assumption that most everyone was focused on model B with a
desire to not do anything explicit to preclude model A.  I hope that this
assumption is still valid.    We need to define a job submission and control
protocol that works for model B.  If someday, someone happens to implement
IPP directly within the output device (printer) which has a network
interface card, then so much the better, but we do not force that in order
for IPP to be successful.    At that time, the model really becomes a single
logical/architectural model:

client --> IPP Printer

which can be realized in many physical network configurations

client --> IPP Printer (running on a general purpose network node which is 
         probably a "computer" such as a typical file server, app server,
etc.)

client --> IPP Printer (running in a specialized network node called 
printer, 
          multi-function device, output device, or whatever).

As to "Why?" do we need to even address model A at all in our thoughts and
decisions:  There are implementations today (in the Novell environments
specifically)  where the "server" is embedded in the "printer".  In this
case the "server" is not a "spooling server" but a "print server".  The
embedded print server uses a file server for actual disk space, but all
status, control, queries, and events are realized through the embedded
"server" (or model A).  Therefore, since model A does exist in today's
market, we must address it.

Having said that, I agree with you that I do not want IPP (v1.0) to become
"all things to all peole with all devices by mid 1997".  We should continue
to focus on Model B and allow for hardware and other issues to help realize
model B in within the output device (what you call model A).

Also, I am interested in how you would apply real quantitative requirements
to   "cheap, simple, and fast" when you suggest a protocol to deal with the
"spooling server ---> printer" side of the model?  I am assuming that you
are refering to the fact that as IPP is currently shaping up, IPP would not
satisfy "cheap, simple, and fast"?  I am also assuming that you are refering
to an earlier email you osted about IPP protocol issues and suggestions to
which I have not responded nor have I seen any other responses.

Scott