Harry,
I agree with your observations entirely. And these concerns
are *exactly* why SENSE was designed to _not_ support any kind
of filtering, so as to ease the burden on the SENSE server
(which is the "agent" in your text below).
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Harry Lewis wrote:
>> 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