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

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

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

Scott Isaacson SISAACSON at novell.com
Mon May 5 12:27:39 EDT 1997


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: scott_isaacson at novell.com
W: http://www.novell.com

>>> JK Martin <jkm at underscore.com> 05/03 9:54 PM >>>
>   Model A:  client ---> printer
>   Model B:  client ---> spooling server ---> 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.

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,

client --> IPP Printer (running in a specialized network node called 
          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.



More information about the Ipp mailing list