I guess I should have been more specific and said "HTTP/1.1".
email@example.com on 05/21/98 07:01:54 PM
Please respond to firstname.lastname@example.org
To: email@example.com, Carl Kugler/Boulder/IBM@ibmus
Subject: RE: IPP> Notifications
> -----Original Message-----
> From: Carl Kugler [SMTP:firstname.lastname@example.org]
> Sent: Thursday, May 21, 1998 11:14 AM
> To: email@example.com
> Subject: Re: IPP> Notifications
> > Events: Machine readable. Carried in an IPP specified way using the=
> > basic protocol as the commands and jobs.
> This implies something other than HTTP used as the basic protocol for=
> and jobs.
> firstname.lastname@example.org on 05/20/98 04:07:12 PM
> Please respond to email@example.com
> To: firstname.lastname@example.org
> Subject: IPP> Notifications
> I still suggest that we are mixing two different things under the sam=
> Notifications: A user making known to the system their desire that a
> be sent when some action occurs on their job (ie.e 'email me when thi=
> Events: an IPP Client asking an IPP Printer to send it information
> 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=
> email, ftp,....). The content is user defined (or can be). The only
> addition we need is that there needs to be job attributes thats conv=
> users request. There may well be a standard set of mechanisms by whic=
> notification can be sent. They are bound to jobs.
> Events: Machine readable. Carried in an IPP specified way using the s=
> basic protocol as the commands and jobs. The content is defined. A cl=
> can request that they be generated for a specific job. In addition a
> can subscribe to events.
> Usage scenario. A user asks for email when a job has finished printin=
> 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
> it sets the attribute saying 'send me an event when this job complete=
> fact a server may well be subscribed full-time to job completion even=
> When the server receives the event is goes into its job end process a=
> recalls that the user requested email - so it sends a message.