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
At 02:25 PM 10/3/97 PDT, David_Kellerman at nls.com wrote:
>[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
>>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: manros at cp10.es.xerox.com