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=
think
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=
tes
between the two, but I would wager most people don't really know this o=
r
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 coi=
n is a
sparse skeleton... yes... most of the IETF documents are un-illustrativ=
e...
then again... see how well some of them are understood, like LPR or DHC=
P...
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=
nitive
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=
-fide
PWG standards development process. In our process, we are recommending =
distinct
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=
mmittee
- we will discipline ourselves to make sure we have appropriate documen=
tation.
The process is open to your input and approval... so please give some t=
hought
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=
ject
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=
ts...
and THIS spec SHALL be called the STANDARD!
Harry Lewis - IBM Printing Systems
=