Subject: SDP> more suggestions for SDP discussion

From: [email-masked]
Date: Sat, 16 May 1998 05:45:33 PST

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
::  [email-masked] Portland, Oregon        fax 503-228-5662