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: 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,
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