I think our model document stands as a way to do printing, over
internets and intranets. We have taken a lot of strides to make sure
that the model document was transport-independent.
What I would like to avoid is producing yet another printing protocol
(YAPP).
Considering that the number of mandatory stuff in IPP is pretty light,
it seems like taking this minimal IPP capability and using just TCP/IP
as a transport would be a good first strike against this
"host-to-device" protocol.
Also, concerning the notification problem, my earlier proposal (using
lightweight, acknowledged datagrams) would be
mapping-document-independent and would be "the" way to do notifications
regardless of mapping document. Of course this assumes that all
potential mapping documents would share a common TCP/IP transport
somewhere in their design.
Just my $0.02
Randy
-----Original Message-----
From: Jay Martin [SMTP:jkm@underscore.com]
Sent: Wednesday, February 11, 1998 8:01 AM
To: Turner, Randy
Cc: 'ipp@pwg.org'
Subject: Re: IPP> Does the world need a robust
host-to-device network printing protocol?
Randy,
> I'm curious how this host-to-device protocol for printing
would differ
> from IPP 1.0?
Excellent question. Right off the top of my head...
For one thing, such a protocol would be one heck of a lot more
efficient than IPP-over-HTTP. Anytime you frame bulk data
within
a transaction protocol, you lose bigtime in terms of
performance.
The CPAP designers learned this many years ago; the
implementation
of an FTP-like side-band "data channel" is one of the big
features
of CPAP v2. Also note that IEEE 1284.1 (aka "TIPSI", aka
"NPAP")
added similar support for a separate data-only channel near the
end of that protocol's development.
In addition to the significant increase in performance, we found
that implementing such a protocol was a lot easier in terms of
structure and complexity. Always a nice win, to be sure.
Another way the protocol would differ from IPP is in the area
of async messages during the transaction. As the client submits
a job, the server can inform the client of any number of events
that occur during the transaction, such as device alerts and
other things the client may (or may not, granted) be interested
in.
Using CPAP as an example of this kind of protocol, CPAP has the
ability for the server to convey to the client that the client's
job was terminated (either via the front panel, or by a remote
management app communicating with the server). Furthermore,
the "job kill" message to the client can include exactly WHO
killed the job, thereby allowing the client to provide an
excellent level of detail to the job submitter as to why the
job failed.
There's more I can say here, but this is at least a start.
I anxiously await comments from others, particularly from you,
Randy! I'd really like to get this kind of thread rolling.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com
-- -- Underscore, Inc. | Voice: (603) 889-7000-- -- 41C Sagamore Park Road | Fax: (603) 889-2699-- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com ------------------------------------------------------------------------