Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt

From: [email-masked]
Date: Tue, 06 Jun 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: IMAP4 Extensions for Quick Reconnect
	Author(s)	: C. Wilson, A. Melnikov
	Filename	: draft-ietf-lemonade-reconnect-07.txt
	Pages		: 24
	Date		: 2006-6-6
	
This document defines a quick reconnect IMAP4 extension, which gives
a mobile client the ability to resume a previously abandoned session,
without the need to perform a full synchronization sequence.  The
goal is to minimize the amount of data transfered at login after a
dropped connection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-reconnect-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-reconnect-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Jun 2006 12:05:30 +0100

>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt
I believe this revision addresses all editorial comments from Dave and 
Arnt. It also addresses most of the editorial comments from Randy.
The too remaining non editorial issues (ABNF for LOGOUT parameters and 
minimum number of per user sessions) were addressed as well.

Alexey

P.S. I've discovered some obsolete text in -07, which I removed from my 
copy. I will do another revision if the document is to be sent to IESG.

---

From: <[email-masked]>
Date: Thu, 8 Jun 2006 12:52:19 +0300

Thank You for the update Alexey,
I have a few comments:
 - "   state is deleted.  While there is no required minimum expiration
   timeout, server implementations are encouraged to support as long a
   time as possible, subject to denial-of-service and related concerns." This is something I have commented before. I do not know if the idea has been discussed. It would be very beneficial for the client to know how long the server keeps the sessions, even better if the client could negotiate this setting. Has this been discussed during the interim? Was there any conclusion?
 - "   previous, active resumable session is available.  If an active
   session is already available and a new one can be created, the" What happens when a new session cannot be created? Who says it cannot be created and why? What is the server/client behaviour if it could not be created?
 - "   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?
 - "   server then checks the last known modification sequence." MODSEQ?
 - "   [[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.
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

-----Original Message-----
From: ext Alexey Melnikov [mailto:[email-masked]] 
Sent: 07 June, 2006 14:06
To: [email-masked]
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt

[email-masked] wrote:

>This document defines a quick reconnect IMAP4 extension, which gives a 
>mobile client the ability to resume a previously abandoned session, 
>without the need to perform a full synchronization sequence.  The goal 
>is to minimize the amount of data transfered at login after a dropped 
>connection.
>
I believe this revision addresses all editorial comments from Dave and Arnt. It also addresses most of the editorial comments from Randy.
The too remaining non editorial issues (ABNF for LOGOUT parameters and minimum number of per user sessions) were addressed as well.

Alexey

P.S. I've discovered some obsolete text in -07, which I removed from my copy. I will do another revision if the document is to be sent to IESG.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2006 17:46:59 -0700

At 12:05 PM +0100 6/7/06, Alexey Melnikov wrote:

>  I believe this revision addresses all editorial comments from Dave 
> and Arnt. It also addresses most of the editorial comments from 
> Randy.

Which editorial comments remain?  (I was going to do a diff against 
-06 and check against my email, but if you have a list that is much 
easier)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Implementation is the sincerest form of flattery.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 Jun 2006 15:23:27 +0100

Randall Gellens wrote:

>> and Arnt. It also addresses most of the editorial comments from Randy.
>

I have not addressed the following issues (I am still thinking if they 
should be addressed and how):

Randall Gellens wrote:

> Section 3.2:
>    If the provided UIDVALIDITY doesn't match the UIDVALIDITY
>    for the currently selected mailbox, the server MUST send the NEWSID
>    response containing the SID of the resumed session.
>
> Maybe add clarifying text to say that the NEWSID response contains the 
> same SID, that is, that the server doesn't abandon the resumed SID and 
> generate a new one?

> Section 3.2:
>    Example: Resuming an old session in selected state with the INBOX
>    selected, but where the server could not cache all the events since
>    the specified modification sequence.  The server sends the NEWSID
>    response, which means that the client should perform full
>    resynchronization.
>
> Might be good to note that in this example the server elected to 
> generate a new SID (since as I understand the text the server can also 
> keep the same SID).
>
> Section 3.2:
>    Example: Resuming an old session in selected state with the mailbox
>    Drafts selected, but the mailbox was deleted and another one was
>    renamed to become Drafts, while the client was offline.  The server
>    chooses to keep the Drafts mailbox open, however it sends the NEWSID
>    response, which means that the client should perform full
>    resynchronization.
>
>    C: A02 SID Frt-egf-779 6896834 11 20:35
>    S: * NEWSID Frt-egf-779
>    S: * FOLDER Drafts
>    S: * OK [UIDVALIDITY 1098183472] Current UIDValidity
>    S: * OK [UIDNEXT 12] Next available UID
>    S: * OK [HIGHESTMODSEQ 54] S: * 7 EXISTS
>    S: * 0 RECENT
>    S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
>    S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
>    \Deleted \Seen \*)] Permanent flags
>    S: A02 OK [READ-WRITE] session created
>
> Nit: Since the server elected to reuse the same SID, maybe the server 
> should say "session resumed" instead of "session created"?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 Jun 2006 20:44:33 +0100

[email-masked] wrote:

>   time as possible, subject to denial-of-service and related concerns." This is something I have commented before. I do not know if the idea has been discussed. It would be very beneficial for the client to know how long the server keeps the sessions, even better if the client could negotiate this setting. Has this been discussed during the interim?
>
No it hasn't.
I've read both your message and Randy's reply to it. I think Randy 
argued against the need for the server to advertise/be able to change 
any limit. If you disagree, can you please reply to Randy's message and 
we will continue the discussion.

>Was there any conclusion?
>   session is already available and a new one can be created, the" What happens when a new session cannot be created?
>
The server would reply NO and the current active session remains active. 
I guess this can be spelled out in the document.

>Who says it cannot be created and why?
>
Server can have a policy limiting number 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.

>   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 sim…
Yes, this will be deleted.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 12 Jun 2006 14:56:16 -0700

At 8:44 PM +0100 6/11/06, Alexey Melnikov wrote:

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

Why would a client want to have more than one saved or active session 
to the same server?  To have multiple mailboxes selected (one per 
session)?  Is this still needed with condstore?

If so, maybe we do need to provide guidance to client authors as to 
what to expect and to server authors as to a minimum per-user to 
support.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Artificial intelligence is no match for natural stupidity.

---

From: <[email-masked]>
Date: Tue, 20 Jun 2006 13:00:49 +0300

>Why would a client want to have more than one saved or active session to the same server?  To have multiple mailboxes selected (one per session)?  Is this still needed with condstore?

Not one particluar client, but different clients.
The usual corporate case (which I think might get more complicated in the real life, however not very often):
1. boss having a laptop
2. boss having a mobile
3. secretary having a laptop
4. secretary having a mobile
accessing the very same mailbox.

-----Original Message-----
From: ext Randall Gellens [mailto:[email-masked]] 
Sent: 13 June, 2006 00:56
To: Alexey Melnikov; Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt

At 8:44 PM +0100 6/11/06, Alexey Melnikov wrote:

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

Why would a client want to have more than one saved or active session to the same server?  To have multiple mailboxes selected (one per session)?  Is this still needed with condstore?

If so, maybe we do need to provide guidance to client authors as to what to expect and to server authors as to a minimum per-user to support.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- Artificial intelligence is no match for natural stupidity.