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

On Wednesday, 19 March 2014 20:46:49 CEST, Andris Reinman wrote:
> The proposal seems a bit too complicated, especially the need 
> to track $ flags.

Which gives you the required atomicity in case of network troubles. It's an 
effective way of ensuring that if the client drops right after UID SUBMIT, 
upon next reconnect it will know how the operation ended up, and therefore 
whether you need to resend or not. In my book, this is important -- not 
every user uses a dedicated "sent" mailbox, some clients might even share 
the same one for INBOX/drafts/sent, so these flags really make sense, IMHO.

Perhaps the draft could be improved to make it easier to read? Patches 
welcome, source lives at [1].

The rest of the complications is a result of criticism that this cannot 
ever possibly compete with submission over ESMTP because it cannot do $FOO. 
I wanted to show that there's no problem replicating each and every ESMTP 
extension which actually (to my understanding of ESMTP, anyway) makes sense 
in the context of submission, and IIRC this claim was not contested last 
time I brought this.

If there's a consensus to make this impler, sure thing -- but I'm afraid 
the proposal would be facing pushbacks from both sides :(.

> I understand that sometimes it might be better 
> to be able to send an existing message (for example a draft 
> message already stored on the server) but wouldn’t it be good 
> enough for most cases to allow uploading the message with SUBMIT 
> (so the command would behave more like APPEND and less like UID 
> STORE) and the response for this command would indicate if the 
> message was accepted for delivery or not (like currently SMTP 
> MDA servers do)?

I definitely want CATENATE (critical for drafts & 
forward-without-download), so this immediately translates to supporting all 
the options which APPEND already has. Also, MULTIAPPEND enters the mix. It 
seems to me that it's easier to just have an extra command which does 
exactly one thing instead two of them. I also suspect that it would make 
server implementations easier at no cost to the clients.

I see that your proposal brings one less roundtrip to the table, though. 
I'm not convinced it is worth the effort, though.

Cheers,
Jan

[1] 
http://quickgit.kde.org/?p=trojita.git&a=blob&f=docs%2Fproposed-extensions%2Fdraft-kundrat-imap-submit.xml

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol