[excuse me, but I'm getting up on the soap box for a minute]
The ongoing exchange over the per-job attributes concerns me. Not so
much because of the specifics, but because it fits a pattern that seems
to dominate much of the discussion on IPP -- something I'd call
steering by looking in the rear-view mirror.
I was hoping IPP offered an opportunity to do a better job of printing
than the currently prevalent printing systems, which, IMHO, are a pretty
idiosyncratic lot and have evident shortcomings as far as meeting the
needs of Internet printing. What I see instead is a standard being
crafted around those historical idiosyncracies and limitations --
arguments of the form "feature-x will be hard to implement in a gateway
to my-favorite-printing-system, so we should remove it from the standard
(or make it optional, much the same thing)" or "my-favorite-printing-
system doesn't provide feature-x, so it isn't important." Accomodating
the past and present seems much more compelling than trying to design
for the future.
Witness the discussion of Job-URL vs Job-Number. We ended up with an
extended discussion centered around backward-compatibility, and precious
little concerning whether the IPP model (with or without Job-URLs)
incorporated the flexibility desirable for Internet printing.
Now we have a discussion of "can System V UNIX handle print jobs with
multiple data types." In contrast, look at all the tweaks and twists
added to existing lpr/lpd implementations. Take a step back and look at
what printer vendors have been doing with document data types --
automatic type sensing, multiple virtual printers, and so forth. These
are all, in large part, market-driven, ad-hoc attempts to deal with
inadequacies of printing protocols in place today. If there's a
conclusion to be drawn from existing protocols, it's not "gotta have
multiple document data types," or "don't need 'em" -- it's "who can tell
from this mess."
It seems to me that, for Internet printing, if you want to look at
existing protocols for guidance, some of the less "popular" ones have
more to contribute, because they share characteristics of Internet
printing that are missing from the prevalent ones. The much-maligned
ISO 10175 still has the clearest model for the printing process, if you
can crack the impenetrable prose of the standards document. Many
"legacy" and production printing systems address issues with shared and
remote printing that are relevant to Internet printing.
To get back to the rear-view mirror analogy -- check out the road ahead.
How are these decisions going to look five years from now, when you're
trying to use software based on IPP for your printing? I realize we're
at a very late stage for IPP 1.0, but for remaining discussion, and for
follow-on work, I really think we'd benefit from placing more emphasis
on looking out the windshield.
[thanks; end tirade]
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662