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:harryl at us.ibm.com]
Sent: Monday, March 09, 1998 9:27 AM
To: ipp at pwg.org
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