Subject: IPP> Notifications paper

From: [email-masked]
Date: 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                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

To:   [email-masked]
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: [email-masked]
phone: 1-303-924-4080

---

From: Jay Martin <[email-masked]>
Date: Fri, 15 May 1998 11:26:23 -0400

Don has done a great job of hitting the nail on the head
with respect to the length and detail of the latest Notifications
proposal.

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

---

From: Tom Hastings <[email-masked]>
Date: Mon, 18 May 1998 14:53:44 PDT

>then it is clearly too heavy.

You are correct that printer resolutions have no business in notification.

The section you cited on printer resolution is in the 9-page Appendix.
That Appendix is about collections, not notification.  At the IPP telecon
the participants wanted the collection attribute syntax added as an 
Appendix, rather than a separate document.  On the other hand, the IETF
often breaks down their standards into separate documents.  You have to
retrieve 5 to 10 documents sometimes to understand one interface.

But we could put the collection attribute syntax into a separate document,
like the IETF.  Should we?

Also the authors wanted some examples (often not included in IETF documents),
so page 41-44 are two examples, totalling 4 pages.

Also the authors wanted to add the Job Monitoring MIB attributes that
are used for job progress monitoring.  This added 6 pages (28-33).

There is a one page summary as well.

So if you remove the 9-page Appendix, the 4-page example, and the 6
pages of Job Monitoring MIB attribute additions, and the one page
summary, we are down to 36 pages.  Scott has done some good work in
further simplifying the proposal and tightning up the text.

>Joe wants to know about Bob's job but that is well past 6 sigma.  Let's

That "so-called garbage" is in the Notification Requirements document.

>the alerts sections total maybe 25 pages.  It seems to work, my customers

Lets discuss whether we want to do accounting or not.  Currently, the
PWG Job Monitoring MIB has accounting as one of its usages.  There
are those who are concerned that SNMP is a fairly fragile way to
do reliable accounting.  Is there a need to also provide a more robust
way with IPP?  Or should implementors add private extensions for 
accounting with IPP?

>then you should go do it for your products.  I'm not putting all this junk

Please identify which "junk" you would like to get rid of.  Then we can
have a more constructive discussion.  The whole idea of the authors was
to see what stuff we wanted to keep and what wasn't necessary.  It is
far easier for a committee to delete from a spec, then it is to invent
on the fly.