Subject: IPP> "IPP" == "DPA"

From: Harry Lewis <[email-masked]>
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

---

From: JK Martin <[email-masked]>
Date: Thu, 20 Mar 1997 15:23:17 -0500 (EST)

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 [email-masked] Thu Mar 20 11:36 EST 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Subject: IPP> "IPP" == "DPA"
Date: Thu, 20 Mar 1997 11:31:29 -0500

Classification:
Prologue:

Jay said...

>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).

----- End Included Message -----

----- Begin Included Message -----

>From [email-masked] Thu Mar 20 12:25 EST 1997
Date: Thu, 20 Mar 1997 10:23:59 -0700
From: Scott Isaacson <[email-masked]>
To: [email-masked], [email-masked]
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 <[email-masked]> 03/20/97 03:27am >>>

	...jay

----- End Included Message -----

---

From: Roger K Debry <[email-masked]>
Date: Thu, 20 Mar 1997 16:23:19 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

Jay wrote:

RKD> Ultimately, I'd like to be sure that IPP covers 80% of the needs of the
marketplace.
RKD> However, I am all for cutting V1.0 down to a manageable and quickly agreed
upon
RKD> and implementable size.  I believe we are at the point where we need to
cut and
RKD run with a model document for V1.0 or we won't be on the standards track
this year!
RKD> Simplifying will greatly help.

---

From: Tom Hastings <[email-masked]>
Date: Thu, 20 Mar 1997 14:03:20 PST

Gee, Jay, why do you say that IPP is just the 90s name of DPA?  
I haven't proposed any new attributes.
What is the additional complexity that you are concerned about?
I'm just clarifying what is already there, I thought.

By the way, a standard which is vague is not really a standard, since
different implementors will read it differently and then wonder why
the interoperability testing didn't succeed.

By the way, are there attributes that you think we could get rid of?
We intend to make a pruing pass and either remove some or make a base
level that is required for conformance.  You ought to participate in
that to make certain that the base level is not too complex.

Tom

---

From: Tom Hastings <[email-masked]>
Date: Thu, 20 Mar 1997 14:08:44 PST

Harry and Jay,

It would be real helpful if you both could take a couple of minutes and
list what complexity in the current Model document you are most concerned 
about.

Then we could consider doing something about it.  However, just a general
concern about complexity is hard to respond to (and easy to ignore).

Thanks,
Tom