Subject: Re: IPP> Notifications paper

From: Harry Lewis <[email-masked]>
Date: Fri, 15 May 1998 11:40:04 -0400

I'm not defending the length or complexity of the Notifications document,
although I am co-author. My contributions are mainly in defining a limited set
of event types, some optimized, guaranteed content, and attempting to stem the
tide of desire for COMPLETE flexibility... wherein any recipient could request
any content for any type of event.

I am a bit surprised, however, at the focus of this argument ON the
notifications document. Maybe it's just like a dam breaking or something but,
I'll tell you, IPP certainly is no joy to try to read and understand! I think
we witnessed the numbing effects of deep and detailed cryptics best when the
PWG was simultaneously developing the Job MIB and IPP. Anyone who was not right
on top of either one had a very difficult time crossing over. I think Tom and
Scott (mainly) did an excellent job preserving compatibility of attributes
between the two, but I would wager most people don't really know this or
understand it's value.

Any detailed technical specification can be imposing when you crack the cover.
(TIPSI is a bit daunting to the uninitiated). The other side of the coin is a
sparse skeleton... yes... most of the IETF documents are un-illustrative...
then again... see how well some of them are understood, like LPR or DHCP...
oh...and cross platform, cross product e-mail really works fine, too.

I support this plea for improved documentation. I agree that we tend to jump in
too deep too fast, before many people have even grasped the concepts. My pet
peeve is all the mandated SHOULDs and SHALLs that only bog down the cognitive
process. And all these ipp-dash-linked-names... one at a time they're OK, but
try to read a paragraph! I'd rather someone speak to me in HEX!

In Virginia, I will be presenting our first attempt to establish a bona-fide
PWG standards development process. In our process, we are recommending distinct
periods for brainstorming, white papers, proposals, drafts, standards etc. with
established exit criteria.
I hope that, as a PWG - unfettered by the rules of another standards committee
- we will discipline ourselves to make sure we have appropriate documentation.
The process is open to your input and approval... so please give some thought
and contribute your ideas!

One thing I might suggest is that, whenever we find ourselves developing a
specification where the 80/20 rule favors OPTIONAL elements, such a project
should be accompanied (I know I said should but I guess I really mean shall ;-)
by a separate spec which distills and represents only the MANDATORY parts...
and THIS spec SHALL be called the STANDARD!

Harry Lewis - IBM Printing Systems

---

From: Jay Martin <[email-masked]>
Date: Fri, 15 May 1998 11:46:36 -0400

Harry,

You speak wisdom here, and I tend to agree with you entirely.
One statement in the first paragraph, though, deserves a brief
follow-up:

  "My contributions are mainly in ... attempting to stem the
   tide of desire for COMPLETE flexibility..."

Sorry, but characterizing this desire as "a tide" is
outright wrong.  There is NO tide here, just one person's
(continual) desire to throw in the kitchen sink at every
turn of the road and at every opportunity.

This kind of approach must be stopped NOW, or the PWG
will continue to sink into a sloth-like mode in which
specs take, say, 8 YEARS to complete.  And by then
the market will have changed so much as to make the
spec useless.

We should be learning more from DPA's mistakes,
rather than from its "successes".

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------