Care to elaborate?
I guess I should have been more specific and said "HTTP/1.1".
-Carl
paulmo at microsoft.com on 05/21/98 07:01:54 PM
Please respond to paulmo at microsoft.com
To: ipp at pwg.org, Carl Kugler/Boulder/IBM at ibmus
cc:
Subject: RE: IPP> Notifications
not necessarily
> -----Original Message-----
> From: Carl Kugler [SMTP:kugler at us.ibm.com]
> Sent: Thursday, May 21, 1998 11:14 AM
> To: ipp at 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 at pwg.org on 05/20/98 04:07:12 PM
> Please respond to owner-ipp at pwg.org> To: ipp at 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.
>>>>>
=