Subject: Submit Direction (was RE: [lemonade] COMPRESS Thoughts)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:00:55 -0400

Mea Culpa: I used poor language when attempting to describe the
asymmetrical nature of compression.  Re-reading what I wrote, and the
subsequent thread, it is apparent that what I wrote made it sound like
we were ONLY going to have compression in the Server->Client direction,
and we would NOT have compression in the Client->Server direction.

Thing 1: That was not the consensus.  The consensus was there could be
situations where you would want compression all the time in both
directions (the typical case); there could be situations where you would
want compression only Server->Client but not Client->Server; for that
matter, there theoretically could be situations where you would want
compression only Client->Server (although I cannot think of any).  The
point I was trying to make is that we needed to handle compression in
one direction, AS WELL AS compression in both directions.

Thing 2: The entire discussion revolved around IMAP.  As has been
pointed out on the list, compression would be an incredibly useful
feature for SUBMIT.

Thing 3: Compression on SUBMIT does not depend on compression for IMAP.

Thing 4: Lemonade does not strictly depend on compression to get
published.

Thing 5: I don't want to expand our work before we finish our committed
work.

Given these Things, I would offer we work out Compression for IMAP
first.  We need data collection (what resources get saved, what
resources get spent, is CPU really that much more expensive than Radio
[I thougber of available sessions per user,

per IP or other factors. This can be done in order to limit DoS attacks.
Server can have a global limit on number of sessions it can serve.

At the end this is dictated by available resources.

>What is the server/client behaviour if it could not be created?
>  
>
Client needs to fallback to using regular IMAP, as if the quick 
reconnect extension is not available.

In theory the client can do something differently if it expects, say, 3 
resumable sessions and only got 2.

> - "   In order to limit Denial of Service attacks a server
implementation
>   SHOULD have a per-user limit on maximum number of resumable
sessions." If the server imposes such limit, what is the way to
communicate the number of current sessions and the limit to the client?
There is currently no way to communicate the number of sessions 
available to a user.
This was discussed during the recent interim and Eric convinced me that
a). specifying any limit in the document wouldn't help, as multiple 
clients acting on behalf of a single user would be able to exceed any
limit.
b). advertising any limit (or remaining number of sessions) would not 
help, as there is a race condition between the moment when the server 
advertises the remaining number and the moment when the client can 
create a new session. So the client would have to be able to deal with 
server saying "I can't create any more sessions" anyway.

> - "   server then checks the last known modification sequence."
MODSEQ?
Yes.

> - "   [[anchor8: This section clearly assumes voluntarily
disconnect]]" should it be described instead having it as an anchor? It
is already described  - except the voluntary part - so it could simply
be removed.
Yes, this will be deleted.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade