Harry and Scott,
Well said, indeed. (Normally I would not append original messages
in their entirety in a response, but since the words are so compelling,
I have done so in this case so that others may immediately reference
those opinions.)
Since DPA wants to cover the entire known universe, then fine.
Let it do so...and let the market react accordingly.
However, why can't IPP be *initially* developed to be very, very
simple, thereby garnering rapid acceptance across the board in the
marketplace? (In much the same manner as HTTP, SMTP, etc, as Scott has
pointed out.)
It really appears (to me, anyway) that the very same people who
developed DPA over an EIGHT YEAR PERIOD are now trying to simply use
IPP as a front-end to DPA back-end engines and related technologies.
Interfacing DPA to IPP should be done in the same manner (and same
attitude, for that matter) as is being done for LPR/LPD. It's really
that simple.
One other thing is worthy of mention here, along the lines of
complexity vs. simplicity. The PMP group has been wrestling with the
issues surrounding implementation of the Printer MIB now for quite some
time; same goes for the never-seems-to-complete Job Monitoring MIB by
the JMP group. You would think the IPP participants could learn
something from the issues the PMP and JMP groups have encountered when
trying to deal with a "too fat" specification.
However, if you notice, almost all of the major contributors of the IPP
effort are new to the PWG organization, and have no real working
experience whatsoever in the history of the PMP group, in particular.
It would be more than instructive if those participants could take some
time to understand the ramifications of the work done by the PMP group
(and that of the ongoing JMP effort), particularly with respect to
time-to-market issues surrounding implementation.
I, for one, am really afraid we are destined to repeat the mistakes
of the PMP and JMP groups for the IPP initiative if we continue down
the path of "cover the world" complexities. It might be useful to
recall the famous quote:
"Those who ignore the past are bound to repeat it."
Harry and Scott have voiced their opinions regarding the need to
keep IPP simple. Roger also voiced an opinion; however, with all
due respect, his comments made it sound as if the IPP was in some
way *required* to satisfy all known requirements, based on apparent
market demand.
Any other opinions out there? Now would be a great time to hear from
everyone on this issue...before it's too late.
...jay
----- Begin Included Message -----
From: Harry Lewis <harryl at us.ibm.com>
To: <ipp at pwg.org>
Subject: IPP> "IPP" == "DPA"
Date: Thu, 20 Mar 1997 11:31:29 -0500
Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Jay said...
>After reviewing Tom Hasting's most recent issues document, it is
>really starting to appear that "IPP" is simply the 1990's name
>for "DPA" in terms of scope and complexity.
>Does anyone else out there share this view?
Yes, I have express this sentiment when reviewing other IPP documents.
I can't "complain" because I've been unable to participate as heavily
as I'd like in the extremely rapid pace of IPP development, therefore,
I haven't been able to contribute any meaningful alternatives. I'm
still trying to pare back the Job MIB to something that will work in a
printer! It's where I'm currently focused. (I guess someone has to
bring up the rear ;-).
Just as an observation - and I'll admit to being parochial toward lower
cost embedded controllers, not necessarily representing the "total" IBM
or industry world of printing - it seems like not only DPA, but
specifically the constant bringing of SERVER function into the picture
is what makes it so complex. I'm not saying this is not valid or
necessary, but I feel like there are already products developed or
being developed on DPA (Tom even referenced these as existing
applications that can't be "broken" when I recommended changing
JobState to one object rather than 2). It's fine for DPA to cover all
the complexities of job sets, job ordering, print pooling, holding
'till midnight, documents that make up jobs etc. etc. etc..., but why
do we have to push ALL this into IPP? Why can't IPP facilitate web
submission and web feedback, freeing network print from the LOCAL area
network, and still let DPA applications manage the complex enterprise
where and when appropriate.
Don't get me wrong - I feel DPA and DPA applications have a definite
place and a great value in many large enterprises. I want IPP and DPA
apps to interoperate. I just don't want IPP to *become* DPA (same goes
for the Job MIB).
Harry Lewis - IBM Printing Systems
----- End Included Message -----
----- Begin Included Message -----
Date: Thu, 20 Mar 1997 10:23:59 -0700
From: Scott Isaacson <Scott_Isaacson at novell.com>
To: ipp at pwg.org, jkm at underscore.com
Subject: IPP> "IPP" == "DPA" -Reply
DPA seems like an "everthing in it from the beginning" type of standard
with implementations that are "NOT everything in it"
I was hoping that IPP would follow the IETF approach: keep it simple
and make it a reality. In other words, IPP should be "just the basics
from the beginning" with implmentations that are also "just the
basics" Then there is some sort of growth path with new versions with
more attributes etc...
Look at HTML, HTTP, SMTP, FTP...
THE REASON WHY THEY WIN IS BECAUSE THEY ARE STUPIDLY SIMPLE. THEN THEY
GET ACCEPTED AND THEN THEY GROW rather than coming in with EVERYTHING
in the spec, NOTHING gets implemented, and there is NO SUCCESS
Some days I am tempted to rip the whole model document right in half
and just leave jobs status and printer status attributes. We all know
that is too simple, but since we all lean (myself included) to be too
complex maybe we just need some balance.
Scott
>>> JK Martin <jkm at underscore.com> 03/20/97 03:27am >>>
After reviewing Tom Hasting's most recent issues document, it is
really starting to appear that "IPP" is simply the 1990's name
for "DPA" in terms of scope and complexity.
Does anyone else out there share this view?
...jay
----- End Included Message -----