Mark Crispin <[EMAIL PROTECTED]> wrote:
> The message shouldn't go away until that EXPUNGE [response] has
> happened.

So does this mean the EXPUNGE response should also be withheld from
the client that sent the EXPUNGE command, since the message has not
yet really been removed?

> If you read RFC 2180, you are immediately struck by something (or should be):
> all the listed strategies but one require substantial client complexity to
> work around what should be a server-internal issue.  That should indicate to
> you that that one strategy is the right one, and the others listed there are
> bogus.

Why is client complexity more important than server complexity?
Exactly what client complexity is incurred by this NO response?

>> This seems to be a weakness in the protocol, since there is no way for
>> the server to explicitly say exactly what has happened.
>
> Wrong -- it is a tremendous strength in the protocol!  It forces server
> implementors to make sure that it never happens, otherwise their server is
> non-compliant.

Why is that preferable to a more expressive protocol that lets servers
be specific about what has happened, and lets client handle that case
smoothly (similar to how you would have them handle NIL)?

>> If the server doesn't allow that, then I can DOS it by holding a
>> connection open without sending any commands that allow EXPUNGE, so no
>> messages can ever be deleted, and the message store grows
>> monotonically.
>
> There is a simple -- and quite compliant -- defense:
>       * BYE Connection holding too many expunged messages

This incurs comlpexity on the client too - it has to reconnect.  Why
is this preferable to sending NO, and letting the client update itself
with NOOP?

>> I'd prefer my server not to be DOS'able in this way,
>> and fortunately, RFC3501 gives me the latitude I need for that.
>
> If you are talking about sending a NO to a FETCH then you are quite mistaken.

Are you saying that RFC3501 does not allow NO for FETCH?  It seems
quite clear to me that it is allowed.

> It CAN be done.  It is not easy.

What confuses me is that you seem to like it this way.


paul

Reply via email to