IPP>MOD Concern about Event Notification Content

IPP>MOD Concern about Event Notification Content

IPP>MOD Concern about Event Notification Content

Carl-Uno Manros cmanros at cp10.es.xerox.com
Fri Oct 17 16:01:44 EDT 1997

At 11:20 AM 10/17/97 PDT, you wrote:
>You're correct in that it probably won't take much time to hack
>up the existing text to nail down some kind of encoding that would
>be palatable to the IESG or whomever.
>That is not what concerns me about IPP notification, however.
>What does concern me is that no one has offered up any REAL
>scenarios illustrating how IPP notification would actually work.
>Sure, people have made comments to the effect of "just send an email
>message".  But I think we really need to walk thru multiple (not
>just one) method of using IPP notification data to ensure that the
>resulting facility is indeed useful as designed.
>Do I have any suggestions?  Not at this time...which is one reason
>I suggested we defer this entire capability until the next version
>of IPP.
>Event notification is NOT something we want to take lightly, nor
>do a half-baked job.  Believe me, after spending the last 2 years
>on SENSE development, it's pretty easy to hack together a "solution"
>that appears to be useful, but ultimately falls short in the long
>run.  (That's not to say our SENSE implementation falls short,
>mind you...  ;-)
>	...jay


I am not looking for anything very sophisticated here, just the ability for
the end user to find out if a job completed correctly, or if not what
problems it ran into. You can get that with many of the existing printing
protocols already. And I claim that we already have the semantics for this
in place in our current draft document.

You can get very sophisticated and spend a long time on making the complete
and perfect notification service for operators administrators etc., the
messaging people in the IETF spent several years defining notifications,
and now they spend another few years on doing receipts. But, as I said
before I think that we have the semantics that we need for Version 1.0 of

What we need to improve is the format and to allow flexibility for
extensions in the next version of IPP. If we model that on what we alreay
have in the application/ipp, I cannot see this being a monumental task.

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com

More information about the Ipp mailing list