Re: [Imap-protocol] Suspend/Restore feature proposal

Quoting Brandon Long <[email protected]>:

> At the very least, I think you need to specify exactly what state is
> maintained.

Point taken: this isn't explicitly defined in the draft.  State as  
intended by the draft means that if a connection is RESUMEd, it would  
be impossible to tell the difference in the authenticated state from  
when the SUSPEND command was issued.  In other words, the server  
connection state would be identical to what it was at the time the  
SUSPEND command (that created the suspend token) was issued.

Maybe a better way to describe is that SUSPEND/RESUME is intended to  
allow a server to save the current IMAP configuration between sessions.

> I also think ideas like a server which supports suspend can't issue
> capability at login is non-starter.  Just because the server supports this
> suspend, doesn't mean all the clients will, and it makes no sense to punish
> the other clients for this.

One of the decisions I made when creating the draft was when to  
initiated resumption of the saved state.  For some reason, I was  
thinking that somehow being in the authenticated state, versus the not  
authenticated state, made a difference when it came to security  
concerns.  Looking at this decision now, that is obviously not the case.

If a client is going to use a non-secure authentication method, then  
it doesn't really matter *when* the server token is sent to the server  
- it's going to be insecure.  So requiring the RESUME command to be  
sent after authentication doesn't address that concern.

The RESUME command SHOULD be sent before authentication occurs, if  
possible.  (We can't restrict the command to only the  
not-authenticated state since PREAUTH connections are dumped directly  
into the authenticated state, where they should be able to RESUME if  
necessary.)  Allowing RESUME to be sent before authentication would  
have several advantages:

   - It addresses your concern.  If a client passes a valid suspend  
token before authentication, the server will know at the time of  
recreating the state that the CAPABILITY command, or any other  
untagged initialization response it wants to send, does not need to be  
sent.  Non-SUSPEND clients, and SUSPEND clients that have yet to  
receive a token, would continue to received these untagged responses.

   - From a server implementer's POV this may be a more efficient way  
to resume.  Not familiar with how any particular server works, but it  
seems that a server could leverage the fact that it is re-using  
session state instead of having to create a new session and then  
immediately toss this session out when a RESUME command is immediately  
issued after authentication.

> Also, wouldn't something like the RECONNECT proposal from lemonade make
> more sense, actually connecting to the exact state?

I assume you would be talking about this:

http://tools.ietf.org/html/draft-ietf-lemonade-reconnect-07

I don't claim to be an expert but I *think* this is what eventually  
became QRESYNC.  The reconnect draft was focused on reconnecting to a  
server with the intention of grabbing all changes to a particular  
mailbox from a previous connection.

Conversely, The SUSPEND draft doesn't care at all about the state of  
ANY mailbox.  It only seeks to restore the configuration so that the  
client doesn't unnecessarily spend time having to recreate these  
commands (which have no bearing on information eventually presented to  
the end-user) every time it connects.

The IMAP landscape has changed immensely since that draft was first  
proposed (2004).  Back then there was no need to affirmatively enable  
any IMAP features.  Since then, the following commands have been  
defined in extensions that require the client to proactively implement  
before they can be used:

COMPRESS=DEFLATE
ENABLE (CONDSTORE/QRESYNC)
LANGUAGE
COMPARATOR
CONVERSIONS
saved CONTEXTs
NOTIFY

Use of these advanced features become prohibitively expensive to a  
disconnected client if they have to be configured every time that  
client reconnects.

I tried to avoid listing the exact extensions that compromise server  
configuration state in an attempt to keep the draft short and to allow  
for future expandability.  But such a discussion/list might be  
necessary for clarity.

> Can't we just pipeline all of this?

You can't pipeline all necessary commands. For example, if the server  
doesn't send CAPABILITY on authentication, that needs to be grabbed  
before any other commands can be sent.

And other commands may rely on pre-existing commands.  LANGUAGE should  
be sent first since human-readable messages should be shown in that  
language immediately.  If you pipeline that command with other  
commands, there is no guarantee that the LANGAUGE command is handled  
first.

> And frankly, the amount of state needed to transfer on reconnect for actual
> folder state can be high (though, not as bad with CONDSTORE/QRESYNC).

I don't understand why folder (i.e. mailbox) state needs to be saved?   
As mentioned in the draft, the net result of a successful RESUME is  
that the client is left in the authenticated state.  A server does not  
need to keep state information for mailboxes when in this mode.

Thanks for the comments.  I will update the draft to, at a minimum,  
reflect the RESUME usage discussed above.

michael

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