Tom
It is right that the reciever of the notification event sometimes could filter
the events as well as the notification source,
but if the method is SMTP I think the filter must be on the notification source.
Henrik
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 05-10-99 08:13:54
To: Henrik Holst/INT, ipp at pwg.org
cc:
Subject: RE: IPP> Filter on 'printer-state-changed' notification
Henrik,
While we could add simple filtering to the Notification Source as you
suggest, the alterntative is for the Notification Recipient to do some
filtering for the cases where the Ultimate Notification Recipient only wants
to be told about a subset of the events.
We need to discuss.
Tom
-----Original Message-----
From: henrik.holst at i-data.com [mailto:henrik.holst at i-data.com]
Sent: Wednesday, September 29, 1999 06:02
To: ipp at pwg.org
Subject: IPP> Filter on 'printer-state-changed' notification
Today we don't have the possibility to set a filter on the
'printer-state-changed' event. It would be nice
to have such a feature. Thinking of the scenario where one operator wants
E-mail
notifications when a
printer wants toner, and another operator wants a notifications when the
printer
needs paper. Today
both operators will get E-mails telling that the printer wants toner or
paper.
It could be done by two new subscription attributes 'notify-printer-state'
(1setOf type1 enum) and
'notify-printer-state-reasons' (1setOf typ2 keyword). So if the
'printer-state'
or 'printer-state-reasons'
changes to one of the specified states in the 'notify-printer-state' and
'notify-printer-state-reasons'
attributes, send by the IPP client in the 'create-subscription' operation,
only
then will the IPP printer
send an 'printer-state-changed' notification event.
What do you think?
Henrik Holst