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.
"Hastings, Tom N" <email@example.com> on 05-10-99 08:13:54
To: Henrik Holst/INT, firstname.lastname@example.org
Subject: RE: IPP> Filter on 'printer-state-changed' notification
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.
From: email@example.com [mailto:firstname.lastname@example.org]
Sent: Wednesday, September 29, 1999 06:02
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
notifications when a
printer wants toner, and another operator wants a notifications when the
needs paper. Today
both operators will get E-mails telling that the printer wants toner or
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
changes to one of the specified states in the 'notify-printer-state' and
attributes, send by the IPP client in the 'create-subscription' operation,
then will the IPP printer
send an 'printer-state-changed' notification event.
What do you think?