Subject: RE: IPP> Notification content

From: "Turner, Randy" <[email-masked]>
Date: Mon, 9 Mar 1998 09:34:30 -0800

I seem to remember there was some concensus towards the end of the
discussion that two items needed to be defined:

1.	What events cause a notification to be generated, and
2.	What parameters get transmitted along with the event
notification.

I emphasized at the meeting that the parameters that are transmitted
along with a particular event are "standardized" (fixed) in a
standards-track document. If a client needs to know more about the
particular event, the client can subsequently issue an IPP request or
possibly an SNMP request depending upon the original event.

Randy

	-----Original Message-----
	From:	Harry Lewis [SMTP:[email-masked]]
	Sent:	Monday, March 09, 1998 9:27 AM
	To:	[email-masked]
	Cc:	Roger K Debry
	Subject:	IPP> Notification content

	In Austin, I think we discussed the IPP notification requirement
that any
	attribute may be requested during registration for a given
event. I think the
	requirement stems from the notion that notification content
should just "mimic"
	the response to a query. But this is probably unrealistic. A
query/response is
	synchronous - during which, the "agent's" job is to gather the
requested
	information and package the response. With notifications, you
pre-register for
	asynchronous events. It would be a much greater burden on the
agent, whether it
	be IPP, SNMP or whatever, to maintain, not only of who wants
which
	notifications, but also what information they requested with
each type of event!

	Harry Lewis - IBM Printing Systems

---

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Mar 1998 13:55:02 -0500

Jay, with a generic event broker, like SENSE, I can understand how filtering
could get out of hand. For the specific case of Job events, however, I am
actually advocating an EVENT TYPE filter. In my note, I was trying to point out
that allowing arbitrary CONTENT per event type is probably out of scope