I guess I should have been more specific and said "HTTP/1.1".
-Carl
paulmo@microsoft.com on 05/21/98 07:01:54 PM
Please respond to paulmo@microsoft.com
To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus
cc:
Subject: RE: IPP> Notifications
not necessarily
> -----Original Message-----
> From: Carl Kugler [SMTP:kugler@us.ibm.com]
> Sent: Thursday, May 21, 1998 11:14 AM
> To: ipp@pwg.org
> Subject: Re: IPP> Notifications
>
> > Events: Machine readable. Carried in an IPP specified way using the=
same
> > basic protocol as the commands and jobs.
>
> This implies something other than HTTP used as the basic protocol for=
> commands
> 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 sam=
e
> 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 thi=
s 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 conv=
ey
> the
> users request. There may well be a standard set of mechanisms by whic=
h a
> notification can be sent. They are bound to jobs.
>
> Events: Machine readable. Carried in an IPP specified way using the s=
ame
> basic protocol as the commands and jobs. The content is defined. A cl=
ient
> 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 printin=
g.
> 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 complete=
s'.
> (In
> fact a server may well be subscribed full-time to job completion even=
ts).
> When the server receives the event is goes into its job end process a=
nd
> recalls that the user requested email - so it sends a message.
>
>
>
>
>
=