Subject: Re: [sieve] New Version Notification for draft-george-sieve-notify-presence-00

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2010 14:04:34 -0500

I've just posted an update to this, here:
   http://www.ietf.org/id/draft-george-sieve-notify-presence-01.txt

Barry

---

From: [email-masked]
Date: Sun, 07 Feb 2010 09:15:55 -0800 (PST)

>    http://www.ietf.org/id/draft-george-sieve-notify-presence-01.txt

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.

This issue shows up in the third example in section 3. This example has a
presence check being used to determine whether or not to send a vacation
notice. There's no actual use of a notify action. Further, the example hard
codes the recipient's presence information.

The latter issue could, I suppose, be addressed by looking up the recipients
presence information with an externai list operation - assuming we make it
possible for external list operations to return additional properties.

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.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Feb 2010 13:17:56 -0500

> 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.

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Feb 2010 11:42:58 +0100

Barry Leiba wrote:
 [...]

>>only the presence check part of enotify.
Exactly.
One use case I have in mind is IMAP presence (== "is this user currently 
connected to the IMAP server"). So I am planning to implement "IMAP 
presence check", but there would be no "IMAP notification" - it is 
already covered by IMAP IDLE.