I would have been there If I could - I was there in spirit :-)
> -----Original Message-----
> From: don@lexmark.com [SMTP:don@lexmark.com]
> Sent: Wednesday, May 20, 1998 7:14 PM
> To: Paul Moore
> Cc: Ipp@pwg.org
> Subject: IPP> Notifications
>
>
> This is remarkedly similar to my description of what I wanted that I kept
> trying to get across in the meeting today.
>
> 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.
>
>
>
>
>
>
>