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: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Harry Lewis wrote:
>> 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