Re: [lemonade] draft-ietf-lemonade-imap-sieve-00

[Dave Cridland <dave at cridland.net>]

On Mon Dec 19 05:13:53 2005, Barry Leiba wrote:
> I have just sent the attached draft to be published as an I-D.  
> It's a
> first pass at describing an extension to IMAP and Sieve that could 
> be
> used to drive server-to-client notifications with a Sieve script.
>
> Please review and comment here, and especially note the "open 
> issues"
> section.

There's quite a few mentions of atomic moves - these can be quite 
slow for some mailstores, and in general they're tricky, and they 
almost invariably involve maintaining locking on multiple mailboxes.

Moreover, I really do fear what a naïve client - or indeed any client 
- will do when it casually flips a flag, and discovers the message 
has just been expunged. Even if it's not naïve, but is the most 
intelligent and aware client in the world, I don't see how it's going 
to detect the difference between "this flag change caused the message 
to be atomically moved" and "this flag change didn't happen because 
the message was already expunged".

I also have a nasty feeling that some clients will take it upon 
themselves to make setting the \Deleted flag instantly expunge the 
message.

I also think it's likely to break UIDPLUS - a client will lose track 
of apparently witnessed moves, because it has no idea of what the new 
UID is, as well as not knowing if the message still exists somewhere 
else on the server. If even one message is moved in a MULTIAPPEND, 
then the APPENDUID response cannot be sent.

Section 3.8 suggests that even if the message isn't shifted about 
atomically behind the client's back, and UIDPLUS actually works, then 
because the headers may be edited, a client will potentially have the 
wrong data in the cache.

Oddly enough, I do think we could use reject, though. Reject could 
generate a protocol level error, hence an APPEND or COPY to a mailbox 
could be forced to fail for a fairly arbitrary reason, for instance. 
Of course, with APPEND and LITERAL+, that's going to make client 
implementors a little upset.

Really, I think this ought to limit itself to two actions:

1) Notifications, so that message appends, copies, and flag changes 
can be sent to disconnected devices.

2) Flag changes, primarily for interoperability between clients using 
locally defined keywords.

Otherwise, I'm really not sure how we're going to get all those worms 
back into the can.

Dave.
--
          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade