IPP Mail Archive: IPP> Notifications paper

IPP Mail Archive: IPP> Notifications paper

IPP> Notifications paper

don@lexmark.com
Thu, 14 May 1998 18:57:46 -0400

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