1) A simple, limited flexibility, basically "hard-coded" set of information
(Job Complete, Job Cancelled, Job aborted, etc.) that is provided largely
tuned for human consumption that is requested in the IPP job submission
command.
2) A more complex, flexible solution for machine consumption that is
achieved through the addition of something like "Subscribe" and
"Unsubscribe" operations to IPP. A richer, more robust set of events and
attributes (groups?, collections?, individual attributes?, etc.) can be
requested with the information send in several different ways (i.e TCP
port, SNMP trap, etc.)
Too bad you could be here to join in!!
**********************************************
* Don Wright don@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@interlock.lexmark.com
cc: (bcc: Don Wright)
bcc: Don Wright
Subject: IPP> Notifications
I still suggest that we are mixing two different things under the same
title.
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.