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
>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
>Joe wants to know about Bob's job but that is well past 6 sigma. Let's
>toss all that
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
>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?
>Everything else is superfluous and overkill. For once can't we design
>and not aim it at the DOCUTECH environment. If Xerox needs something much
>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 Wright email@example.com *
>* Product Manager, Strategic Alliances *
>* Lexmark International *
>* 740 New Circle Rd *
>* Lexington, Ky 40550 *
>* 606-232-4808 (phone) 606-232-6740 (fax) *
>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
>Roger K deBry
>Senior Technical Staff Member
>Architecture and Technology
>IBM Printing Systems