Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt

[Ned Freed <[e-mail]>]

> If you don't mind a stupid question on this..

Far from being stupid; it cuts to the heart of the purpose of this extension.

> The idea of a 'snooze' feature is something lot's of people are working
> on, and maybe it should be a higher level than in 'sieve'?

I guess future release in SMTP (RFC 4865) qualifies as a "higher level"
mechanism, and as the draft notes, it can be leveraged by the sieve
implementation to implement snooze.

> Maybe it would be helpful to set solicit feedback on other industry
> implementations of this feature.. possibly this should be in IMAP itself?

Possibly. But the how very much depends on the why.

The draft states that the purpose of this extension is to avoid having messages
appear in a mailbox until "a more convenient time for the user to act upon
them".

This begs the question (yes, I'm using the phrase in the sense it has recently
acquired) of why a user would be incapable of simply ignoring or otherwise
dealing with the message, without the need for any delay. After all, delaying
delivery has potentially serious consequences: Suppose a user sets up a delay,
some messages are then delayed, and then then for whatever reason the user
urgently needs to access these messages. Depending on the way this is
implemented, tney may have no means of determining whether or not there are
messages in this state, let alone accessing them. [1]

So why would someone be willing to accept these consequences? The draft doesn't
say, but I think answer is that some clients fail in the most fundamental way
imagineable: They make it difficult, if not impossible, for the user to
exercise proper control of how they handle their email. And there  are several
failure modes a delay can address: The lack of a, "Don't sound an alarm for
nonurgent messages delivered between 10PM and 6AM" setting, inadequate and/or
inconvenient filtering options for displaying recent arrivals, etc.

Add to this the fact that users often make use of multiple clients, which
invokes a variant of Einar Stefferud's three body problem: When multiple
clients are used you end up with the union of the bugs and the intersection of
their features.

So how does this relate to an IMAP based alternative? Such an alternative is it
requires client support to configure. And if clients are going to have to
change to support this wouldn't it be better to address the underlying client
issue that makes this extension necessary?

In contrast, it only takes support in one client to set up sieve filters. And
filter configuration is something you already need for other reasons. Finally,
if need be it can be an entirely separate client.

				Ned

{1] This is, at a minumum, a security consideration that needs to be
documented.