I've been scratching my head over this one. It isn't that the capability isn't
useful - it is - and that the proposal won't work - it will. Rather, it's the
implied coupling between presence checks and notify that has me concerned with
the basic approach that's been chosen.
Yes, in a way it does seem odd, but the coupling is in the base
enotify spec, RFC 5435, where the notify_method_capability is defined,
and the "online" notification-capability is specified.
So far, that's the only bit of presence information that's testable,
so this spec adds three more items. If folks think we should use a
different (new) mechanism for these tests, I'm happy to work on
designing that (with input). But enotify introduced this mechanism.
But maybe I'm worrying about nothing. AFAIK all of the currently defined
presence checks have an associated notification mechanism. And even if such a
mechanism exists, there's nothing to say an implementation couldn't implement
only the presence check part of enotify.
Right... supporting enotify doesn't do anything _per se_, unless
specific notification methods are also supported. So it seems a "mix
and match" kind of thing.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve