Notifications: A user making known to the system their desire that a message
be sent when some action occurs on their job (ie.e 'email me when this job
finishes')
Events: an IPP Client asking an IPP Printer to send it information regarding
errors, jobs, .etc.
These may operate independantly, in tandem or in parallel.
I suggest that the behaviours need to be something like:
Notifications: Human readable, sent by a mechanism that is non-IPP (i.e
email, ftp,....). The content is user defined (or can be). The only protocl
addition we need is that there needs to be job attributes thats convey the
users request. There may well be a standard set of mechanisms by which a
notification can be sent. They are bound to jobs.
Events: Machine readable. Carried in an IPP specified way using the same
basic protocol as the commands and jobs. The content is defined. A client
can request that they be generated for a specific job. In addition a client
can subscribe to events.
Usage scenario. A user asks for email when a job has finished printing. The
IPP request to the server has the attribute set saying 'notify when
printed'. The server queues the job up. When the job is sent to the printer
it sets the attribute saying 'send me an event when this job completes'. (In
fact a server may well be subscribed full-time to job completion events).
When the server receives the event is goes into its job end process and
recalls that the user requested email - so it sends a message.