Recent SDP discussions have "drilled down" pretty deeply. To try to
gain some perspective, here's a general observation, and my list of
key technical requirements that are still at issue for a
driver-printer protocol.
The general observation is that everyone has already "solved" the
driver-printer communications (where "internet printing" was
relatively uncharted territory), so a new driver-printer protocol has
to have compelling advantages over existing solutions in order to
get implemented. In fact, most vendors have heavy investments in
their existing solutions. In contrast to IPP as an "internet
printing" solution, I doubt that vendors would give serious thought
to replacing their driver-printer connection with IPP -- they'd lose
too much functionality. The question we ought to keep revisiting
is, do we have a driver-printer protocol that is compelling enough to
get implemented?
Here's my list of technical requirements that are specific to the
driver-printer interface. Most are lifted from prior discussion.
1. Non-HTTP transport -- HTTP seems a poor choice of transport for
a driver-printer protocl, for a variety of reasons: it's
"heavy," it constrains the model of driver-printer interaction,
it potentially requires the driver to be integrated with the
host HTTP services.
2. Transport independence -- does the driver-printer protocol need
to be designed to run over different (possibly non-network)
transports; what is the practical (not just hypothetical) scope
of the protocol.
3. Handling the data stream -- it isn't just an issue of "chunking"
the data stream; there is a body of experience that suggests
separating data transfer from the control channel is a desirable
feature of a driver-printer protocol.
4. Notification, printer status and exception monitoring -- yes,
this has been beaten around a lot; a driver-printer protocol
needs a good answer, and IPP doesn't yet have one; sockets have
issues with scalability and persistence of connections.
5. Security -- it's shortsighted not to address security even in a
driver-printer protocol (or at least plan for it); it needs to
handle coordinated authentication of multiple connections if the
protocol allows that (for data stream, notification, etc.), as
is desirable for a driver-printer protocol.
6. Device management - it was out-of-scope for IPP 1.0, but a
driver talking to a printer typically has to deal with device
management issues; IPP plus "some other protocol for management"
gets ugly quickly (configuration, coordination, security), and
you at least need to spec the alignment between the multiple
protocols.
7. Resource management - it is valuable for a driver-printer
protocol to allow the printer to request resources (fonts,
forms, etc) as it needs them; it can simplify drivers, make
printer configuration and maintenance easier.
8. Localization - at my last reading, IPP placed a significant
localization load on the printer; the model for a driver-printer
protocol should be machine-to-machine, place localization at the
driver, and avoid localized data on the printer.
9. Who's in control - IPP assumes the client controls all
interaction (push the job across, poll for information); a
driver-printer protocol can benefit from a more balanced division
of control (printer gating of job processing, printer delivery
of event notifications, printer request of data and resources,
for instance).
10. Client contention - when multiple clients share a non-spooling
printer, do they just poll until they gain access;
alternatively, a notification-style approach ("I want to send a
job," "I'm ready to accept your job") might be more efficient
and "fair."
11. Low-level discovery - to allow driver (or directory service) to
be configured automatically with printer identity, features
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662