I respectfully submit that the Washington DC meeting spend
the time NOT on reviewing the proposal (as submitted), but
instead back off to the point of discussing reasonable
*scenarios* for requiring notifications.
All too many times we write up "requirements" documents
that virtually hide the underlying scenarios with respect
to firm, existing application environments. (By "application"
I mean "how the concept is to be used", and not a particular
piece of software or software category.)
I'd like to discuss the usage and requirements for notifications
at this kind of level:
"I need a car for commuting to work. What kind of car
would be appropriate?"
Rather than discussing requirements like this:
"The vehicle needs four tires, each rated at 40,000 miles/year."
Skip the details. Let's talk about real-world, pragmatic
environments and how notifications need to work in those
environments.
And during those discussions, if someone utters words to
the effect of:
"Perhaps someone someday somewhere needs to be able to..."
then that person gets the AXE. (Literally... ;-)
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@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 --
----------------------------------------------------------------------
don@lexmark.com wrote:
>
> I agree with Roger on this one. I refuse to waste my time reading this
> stuff.
> Perhaps we have not scoped the effort correctly?!?! I don't want to
> belittle
> the efforts that have gone into this but I think those efforts were clearly
> pointed in the wrong direction.
>
> We have clearly strayed from the IETF's design strategy to something else.
> There are very few full IETF standards this long. HTTP/1.0 is only 60
> pages. (I'll admit, HTTP/1.1 is a design-by-committee document from
> my perspective.) I still think IPP is GROSSLY over-designed. Fortunately
> we mandated only a small subset as a requirement. I predict that popular
> usage will be a minor subset of the total IPP definition. The rest will
> only
> be used by a very, very small number of the total printing devices that
> ship.
>
> Back to notification.....
>
> For example, I cannot imagine any reasonable scenario on notification that
> would
> require any use of printer resolution in notification. I notice in the
> document in the
> section on collections that printer resolutions are used. Even as an
> example,
> this is clearly not appropriate. If we can't do notifications in 10-20
> pages (max)
> then it is clearly too heavy.
>
> As a user, all I really want to know is:
>
> 1) The job has printed page n
> 2) The job ended and the return code/error message was x
> 3) The output was printed on printer z
>
> As an administrator, etc., all I really want to know is:
>
> 1) The printer is down
> 2) The printer needs supplies now or soon
>
> I want to be able to choose between e-mail and a more immediate
> notification. Beyond
> this, the user and administrator need to use the printer management
> utilities and tools
> for that device to determine what to do next. We can always contrive
> scenarios where
> Joe wants to know about Bob's job but that is well past 6 sigma. Let's
> toss all that
> garbage.
>
> We're not doing accounting here, let's keep it simple. TIPSI does more
> than we need (it includes much of the MIB traps concepts) except e-mail and
> all
> the alerts sections total maybe 25 pages. It seems to work, my customers
> are happy.
>
> Everything else is superfluous and overkill. For once can't we design
> something simple
> and not aim it at the DOCUTECH environment. If Xerox needs something much
> heavier
> then you should go do it for your products. I'm not putting all this junk
> in my printers.
>
> Don
>
> **********************************************
> * Don Wright don@lexmark.com *
> * Product Manager, Strategic Alliances *
> * Lexmark International *
> * 740 New Circle Rd *
> * Lexington, Ky 40550 *
> * 606-232-4808 (phone) 606-232-6740 (fax) *
> **********************************************
>
> To: ipp%pwg.org@interlock.lexmark.com
> cc: (bcc: Don Wright)
> bcc: Don Wright
> Subject: IPP> Notifications paper
>
> I have started to review the latest notification paper from Tom et al.
> This looks to be a fine example of design by committee, i.e. put
> everything in but the kitchen sink, so as to please everybody. Sorry,
> but I think it's rubbish -- if it takes 50 pages to describe it is way too
> complicated. If I can wade through the gory details, I'll make more
> substantive
> comments later.
> Roger K deBry
> Senior Technical Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry@us.ibm.com
> phone: 1-303-924-4080