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

[Barry Leiba <leiba at watson.ibm.com>]

Dave says...

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

I don't see that what I'm describing as an "atomic move" is any more of
a burden for servers than
   COPY 5 Newmailbox
   STORE 5 +Flags.Silent (\Deleted)
   EXPUNGE

What the spec means is that one of these "moves" must implement that
sequence as one operation, and what that mostly means is that if
something fails, none of it is done... and that the clients just see
the EXPUNGE responses, and not the intermediate FETCH FLAGS(\Deleted)
updates.

Do we prefer to just let servers implement these moves as those three
separate operations, and allow us to have intermediate states?  Or do
some agree with what Dave says later, that the moves aren't appropriate
at all (see my comments below)?

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

The same thing it does when it sees any message expunged.  I remind you
that every client, nowever naÃve or worldly, MUST deal with EXPUNGE
responses, and the underlying expungement (is that a word?) of the
messages.  Why should you think this should be a problem?  This can
happen in other situations, such as this:

Client 1                          Client 2
                                  C: X1 STORE 5 +Flags (\Deleted)
                                  S: * FETCH 5 Flags (\Deleted)
C: T1 STORE 5 +Flags (\Answered)
                                  S: X1 OK done
                                  C: X2 EXPUNGE
                                  S: * 5 EXPUNGE
S: T1 NO failed                   S: X2 OK done
C: T2 NOOP
S: * 5 EXPUNGE
S: T2 OK done

> 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 don't see why it has to detect the difference.  Can you explain?

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

This certainly doesn't give them license to do that.  If someone wants
to have a Sieve script do that, they certainly can, of course:

  if allof (${IMAPSieve.cause} :is "FLAG", hasflag "\\Deleted") {
      discard;
  }

Whether this is a good idea or not is something the implementer of the
script has to decide.

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

Huh?  This makes no sense.  Even if the server responds with a UID, the
message can disappear before the client can do anything with it anyway.
This automates things, perhaps making such situations more apt to
happen, but it doesn't change the fact that they can happen.

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

That IS a good point, and I'd originally started to write it to ban
EditHeader, but then changed my mind.  What do other client-writers
think about this?

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

I hadn't thought about that.  Yes, we could allow/define the reject
action.  Other comments?

> Of course, with APPEND and LITERAL+, that's going to make client
> implementors a little upset.

Using APPEND with LITERAL+ is a bad idea anyway, since the server can
always say NO to APPEND, without the client's being able to determine
that in advance.  Again, this doesn't change that.

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

Noted.  Do others agree?

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam


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