IPP Mail Archive: Re: IPP> Notifications paper

IPP Mail Archive: Re: IPP> Notifications paper

Re: IPP> Notifications paper

Harry Lewis (harryl@us.ibm.com)
Fri, 15 May 1998 11:40:04 -0400

I'm not defending the length or complexity of the Notifications documen=
although I am co-author. My contributions are mainly in defining a limi=
ted set
of event types, some optimized, guaranteed content, and attempting to s=
tem the
tide of desire for COMPLETE flexibility... wherein any recipient could =
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 somethin=
g but,
I'll tell you, IPP certainly is no joy to try to read and understand! I=
we witnessed the numbing effects of deep and detailed cryptics best whe=
n the
PWG was simultaneously developing the Job MIB and IPP. Anyone who was n=
ot right
on top of either one had a very difficult time crossing over. I think T=
om and
Scott (mainly) did an excellent job preserving compatibility of attribu=
between the two, but I would wager most people don't really know this o=
understand it's value.

Any detailed technical specification can be imposing when you crack the=
(TIPSI is a bit daunting to the uninitiated). The other side of the coi=
n is a
sparse skeleton... yes... most of the IETF documents are un-illustrativ=
then again... see how well some of them are understood, like LPR or DHC=
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. M=
y pet
peeve is all the mandated SHOULDs and SHALLs that only bog down the cog=
process. And all these ipp-dash-linked-names... one at a time they're O=
K, 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=
PWG standards development process. In our process, we are recommending =
periods for brainstorming, white papers, proposals, drafts, standards e=
tc. with
established exit criteria.
I hope that, as a PWG - unfettered by the rules of another standards co=
- we will discipline ourselves to make sure we have appropriate documen=
The process is open to your input and approval... so please give some t=
and contribute your ideas!

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

Harry Lewis - IBM Printing Systems