This implies something other than HTTP used as the basic protocol for c=
ommands
and jobs.
-Carl
owner-ipp@pwg.org on 05/20/98 04:07:12 PM
Please respond to owner-ipp@pwg.org
To: ipp@pwg.org
cc:
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 me=
ssage
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 rega=
rding
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 pro=
tocl
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 sam=
e
basic protocol as the commands and jobs. The content is defined. A clie=
nt
can request that they be generated for a specific job. In addition a cl=
ient
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 pri=
nter
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.
=