way, of course I would prefer to change the filter, depending on the busy
status, but that may not always be possible if the busy status is detected
in another medium without a channel back to Sieve filter management.
Right, exactly.
Of course I could pass the priority as attribute of the notification
and let whatever receives notifications filter them.
Yes, that's one way to handle them; that's the argument for having "mailto"
set "X-Priority", and having "XMPP" set "Priority" consistent with RFC 1327.
And that's certainly a valid thing to do with it.
Which notification method is meant to make use of this feature and how
would it be implemented? Or are there implementations already?
We had an experimental notification mechanism here, which used user "context"
to determine how to notify the user. It used the :priority in addition to
information the "context server" knew about the user to decide whether or not
to notify, and to pick the ultimate notification channel.
That sort of thing can't really be done in the Sieve script, so it makes
sense to give the notification mechanism as much information as we can,
so that it can do it.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam