Le 12 sept. 2009 à 09:27, Charles Marcus a écrit :
On 9/11/2009, Axel Luttgens (*******) wrote:
Well, POP is rather well RFC-based too... ;-)
In fact, POP and IMAP are both well-defined protocols;
they just are optimized for each extreme of possible behaviors:
remove everything from the server as soon as a local copy has been
taken, or leave everything on the server without taking any local
copy.
He was talking about the 'leave messages on server' part of POP, which
you conveniently omitted above.
Hello Charles,
No, I don't think to have omitted anything: I already replied to the
OP wrt the 'leave messages on server' matter.
Here, I was replying to Leonardo (who's not the OP) who started a new
idea (a potentially misleading POP vs IMAP debate) within the original
thread.
Is this aspect of POP 'well-defined' in
the RFCs? This is not a rhetorical question, I really don't know.
No, of course not.
The POP protocol defines how a client and a server communicate, and
what the client may ask the server to do thru a limited set of well-
defined commands.
And so does the IMAP protocol too, no more no less.
The client configuration may allow to automate some command sequences
emitted by the client, so that the user doesn't have to perform those
commands manually; but this clearly is outside of the client/server
protocols.
The current base specifications of the POP and IMAP protocols are
available at, respectively:
http://www.rfc-editor.org/rfc/rfc1939.txt
http://www.rfc-editor.org/rfc/rfc3501.txt
What if user 1 at MUA1 decides to delete some message today? Will
user 2 on MUA2 still see that message when connecting 10 days later?
Of course, if user 1 and user 2 happen to be the same user, then that
user won't be surprised.
Since he obviously wasn't talking about different users, I'm really
not
sure why you asked your question.
Because email users often tend to be somewhat schizophrenic...
For example: hey! why are my messages marked as read by Thunderbird? I
just had a quick look at them thru webmail in a cybercafé?!?
But yes, agreed: to better convey my idea, I should have written
"souldn't be surprised" instead of "won't be surprised".
Multiple users accessing the same IMAP account/folders obviously
requires some thought and planning (and well-defined permissions) to
make work correctly.
But then neither would he have been surprised if using two distinct
POP clients.
I cannot count how many times I've had to explain to $user that the
fact
that the reason they just had to redownload 5000 messages (for the 3rd
time in a year?) is a good reason NOT to use this option, and that
they
should use IMAP.
Do you mean that those re-downloads occur frequently and
"spontaneously"?
This should normally not happen, and it may be worth to somewhat
investigate.
For example, perhaps are your users addicted to alt-ctrl-del
sequences? ;-)
More seriously: are the clients bug-free? may it happen that your
users sometimes work thru poor communication channels? is the server
consistent with the UIDLs? why do your POP users leave so many
messages on the server? etc.
So, yes, $POPuser can certainly be surprised when this 'feature' of
POP
doesn't work as expected.
Again, this has nothing to do with the POP protocol; this is just a
client setting, an often misunderstood one.
BTW, have you noticed those settings available on IMAP clients?
They usually begin with 'remove messages from the server when...',
instead of 'leave messages on the server...'
These opposite formulations just reflect those opposite behaviors I
mentioned above.
And because of that, IMAP clients often provide settings related to
local copies of messages as well.
All those (yet more complicated) settings are often misunderstood too...
Axel
