Re: [Imap-protocol] IMAP SUBMIT Extension, take two

On Thu, Mar 20, 2014, at 10:06 PM, Arnt Gulbrandsen wrote:
> Is that atomicity really required? And if it is, I don't think the 
> three-step submit process gives you atomicity.
> 
> I like it in general, but I'd prefer a two- or even one-step process. 
> Two-step could be "upload to outbox; submit from outbox". You can do the 
> atomicity thing by saying that servers SHOULD lock a message in the outbox 
> while it's being submitted, and refuse to resubmit.

I think requiring the server to set a flag (system flag \Sent would be
ideal, but I'm not sure that we can ever create a new one without breaking
clients...)

I agree that two step is probably enough - one for upload, and one for
"send existing message".

> Personally I don't think it's worth it. It's better to have simplicity, 
> even at the cost of the occasional duplicated message.

I think there's a "simplicity vs clarity" issue here.  It's much more simple
for a client to be able to know that a message was sent without having to
set a flag itself.  We definitely need the interlock to err on the side of
sending twice than not at all, but having a flag that says "this message
has been sent" is valuable - and having the server set is is actually MORE
simple than having the client need to set it after getting send confirmation
from the server.

IMAP hasn't had anything which makes a change to the status of a message
silently before - because the only editable parts have been flags,
annotations and of course messages themselves, which can only follow one
real state transition series (now with a single branch)

NONEXISTENT => CREATED (with F/UVAD/U triplet) => EXPUNGED

And now that MOVE exists, there's a "MOVED" path between CREATED and EXPUNGED,
though you can still just model that as two separate messages having 
concatenated lifetimes.  Also between CREATED and EXPUNGED there is the
possibility of setting or clearing flags (including \Deleted) and also
in a modern enough server setting, altering or clearing message annotations.

That's it.

But now we're proposing a state transition from "UNSENT" to "SENT" - and I
strongly believe that rates a readable change on the server, either a flag
or a standard annotation name.  All I think it needs is a transition from
"no flag present" to "\Sent" flag present, or $Sent if \Sent is considered
too impossible to add at this stage of the game.

Bron.

-- 
  Bron Gondwana
  [email protected]
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol