Subject: IPP> steering by the rear-view mirror

From: [email-masked]
Date: Fri, 03 Oct 1997 13:25:11 PST

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

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 7 Oct 1997 16:12:09 PDT

David,

Generally speaking I tend to agree with you that we should attempt to
design for the future rather than for the past. However, these kind of
things do not happen in a vacuum. Are we trying to be revolutionaries or
evolutionaries?  I guess the right approach is somewhere in between.  My
take on this is that we should design for the future, but we should not
make future solutions different from current ones just for the heck of it.
If we can make things backwards compatible in areas where it it does not
compromise our design, I think it as a good approach to stay with what
people are already familiar with (be they implementors or end users).
I admit that some of the discussions that you refer to have taken more time
than I would have liked, but this is fully in line with one of the
Parkinson's Laws (remember Parkingson, or am I the only one old enough?),
which states that the time spent on discussing a subject is in revers
proportion to its importance :-)

All in all, I do not think we have been doing too badly (compared to many
other DL discussions I have seen in other IETF WGs). Compromise is the name
of the game in all standardization groups.

Carl-Uno

>::  [email-masked] Portland, Oregon        fax 503-228-5662
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]