At 15:57 05/14/1998 PDT, don at 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.
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.
>>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.
That "so-called garbage" is in the Notification Requirements document.
>>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.
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?
>>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.
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.
>>Don
>>**********************************************
>* Don Wright don at 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 at 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 at us.ibm.com>phone: 1-303-924-4080
>>>>>>>>>