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

From: [email-masked]
Date: Mon, 15 May 2006 15:50:02 -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-06.txt
	Pages		: 23
	Date		: 2006-5-15
	
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-06.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-06.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-06.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: <[email-masked]>
Date: Tue, 16 May 2006 11:35:57 +0300

Hi all,
I have a couple of questions on this draft.

There is nothing about expiration timeout in the draft, so I assume each client and server implementation is free to choose any setting.

1. Let's say the client setting is 5 minutes, the server setting is 3 minutes. How will the client know what is the current setting on the server (to be in sync)? Is there any way to query it?
2. This assumes that the client can query the server setting (1). So the client noticed that the server setting is 3 minutes. The client wants to make it longer because 5 minutes seems to be a better value. How can the client change the setting on the server?
3. This assumes that the client can request changing the server setting (2). The client requested changing the setting, but the server has a good reason to force a shorter expiration timeout (perhaps to save some resources). In any case, how can the server not to accept the new setting? (To tell the client that: "fine, I got Your message, but let's just keep my value for now").
4. This assumes that the whole thing is supported and working (1,2,3). Now, how would it work in a multi-client enviroment? We would like to to make sure that each client has its own expiration timeout - and that one client changing the setting does not have any impact on another client. The expiration timeout might very well be different for a fixed terminal and a mobile one. The mobile terminal evalutes its environment continouosly and needs to make adjustsments according to its estimation of network conditions.

Any thoughts on this?
Thank You.

Best regards: Zoltán Ördögh
E-mail: [email-masked]
Phone: +358 50 386 0566

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 15 May, 2006 22:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-06.txt 

	
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.

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-06.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

Send a message to:
	[email-masked].
In the body type:

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 May 2006 17:49:03 -0700

Excellent work on this draft.

I do have a number of comments, but all of them are minor:

Section 2.1:
    The above protocol sequence simply logged the user into the account,
    selected the INBOX mailbox and downloaded the updated flags for a
    subset of messages.

It is proper to say "subset" since the command used "1:*"?  Since it 
is only one mailbox, I guess it is technically correct, but it seems 
perhaps misleading.

Section 3.1:
    If the optional session identifier (SID) parameter is not defined,
    the server will generate a new session as described in Section 3.2.

For readability, it might be better to say "used" (or maybe "sent") 
rather than "defined", since this draft defines the parameter.

Section 3.1:
    Note, that this document doesn't define a minimal
    required expiration timeout, as members of the Lemonade WG have
    decided that any such limit would not be adequate for all
    deployments.

Since the document is nearing completion and has been around for a 
while, it might be good to replace this text with something along the 
lines of

    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.

Section 3.2:
    This
    forces the server to create a new session regardless if a previous,
    valid session is available.  If a valid session is already available
    and a new one can be create, the existing session becomes inactive
    and can be resumed at a later time.

For readability, I'd suggest replacing "forces" with "instructs" (or 
"requests").

Note there is a typo: "create" instead of "created".

It might be good to explain or reword the last sentence above ("If a 
valid...") to make it more clear what it is saying.  Does "valid 
session" include active sessions for this user as well as inactive 
ones?  It sounds like it is saying that if the client has an active 
resumable session on the current connection (that is, within the 
current IMAP session), that it becomes inactive and a new one is 
created, but this should be made explicit.

Section 3.1:
    In
    order to limit Deny of Service attacks a server implementation SHOULD
    have a per-user limit on maximum number of resumable sessions.  When
    this limit is reached the server SHOULD "expire" the oldest
    inactive(*) session associated with the same user.  If no inactive
    session associated with the same user is available, the server MUST
    return the tagged NO response to the SID command.

Note there is a typo: "Deny of Service" instead of "Denial of Service".

I'd suggest removing the quotes around 'expire'.

I'd suggest moving the asterisked text to be inside a parenthetical 
aside: "inactive(*) session" becomes "inactive (not associated with 
an active TCP connection) session".

Section 3.2:
    If the
    SID is not recognized (for example, this is the first time the client
    tries to connect, or the the SID is invalid because it is either not
    known to the server or has expired)

By "first time" you mean the first connection by this client to this 
server?  If so, why would the client use a SID?  Perhaps it is trying 
to use one from an older server, or is just confused?  Either way, 
I'd think it would fall into the "not known" category.  So, I'd 
suggest deleting the "first time" wording.

Note there is a typo later in this section: "user has no longer 
permissions" instead of "user no longer has permissions".

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:
    If the provided UIDVALIDITY matches the one provided by the currently
    selected mailbox

Wording suggestion: change "the one provided by the currently 
selected" to "that of the selected"

Section 3.2:
    If the list of known UIDs was also provided, the server should only
    report flag changes and expunges for the provided messages.  If the
    client haven't provided the list of UIDs, the server acts as if the
    client has specified "1:*".  Thus, the client can just service these
    pending events and need not perform a full resynchronization.

Typo: "client haven't provided" instead of "client doesn't provide".

Suggest rewording "client can just service these", perhaps to "client 
can process just these".

Section 3.2:
    If these events could not be cached for some reason, the server MUST
    return the NEWSID response to signal that the client should perform a
    state-comparison based synchronization.

Maybe change "If these events could not be cached for some reason" to 
"if the server was unable to cache all events since the MODSEQ and 
hence is unable to send them to the client"?

Section 3.2:
    Note, that if, while the client was offline, the mailbox was deleted
    and another mailbox was renamed on top of the selected, the server
    may do one of the two things:

Typos: suggest changing to:

    If, while the client was offline, the selected mailbox was deleted
    and another mailbox was renamed to the same name, the server
    MAY do either:

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"?

Section 3.2:
    the current session on logout it SHOULD use "LOGOUT (PRESERVE)"
    instead of just dropping TCP connection.  The former helps to avoid
    unnecessary resource consumption on the server caused by a TCP
    disconnect.

Typo: add "the" between "dropping" and "TCP".

Maybe change "the former" to "this".

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
He who laughs last is probably your boss.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 May 2006 17:56:57 -0700

At 11:35 AM +0300 5/16/06, <[email-masked]> wrote:

>  There is nothing about expiration timeout in the draft, so I assume 
> each client and server implementation is free to choose any setting.

Each server implementation is free to choose any value it likes. 
Clients have no choice in the matter, aside from perhaps having a 
value beyond which not to even try and resume a session.

>
>  1. Let's say the client setting is 5 minutes, the server setting is 
> 3 minutes. How will the client know what is the current setting on 
> the server (to be in sync)? Is there any way to query it?
>  2. This assumes that the client can query the server setting (1). 
> So the client noticed that the server setting is 3 minutes. The 
> client wants to make it longer because 5 minutes seems to be a 
> better value. How can the client change the setting on the server?
>  3. This assumes that the client can request changing the server 
> setting (2). The client requested changing the setting, but the 
> server has a good reason to force a shorter expiration timeout 
> (perhaps to save some resources). In any case, how can the server 
> not to accept the new setting? (To tell the client that: "fine, I 
> got Your message, but let's just keep my value for now").
>  4. This assumes that the whole thing is supported and working 
> (1,2,3). Now, how would it work in a multi-client enviroment? We 
> would like to to make sure that each client has its own expiration 
> timeout - and that one client changing the setting does not have 
> any impact on another client. The expiration timeout might very 
> well be different for a fixed terminal and a mobile one. The mobile 
> terminal evalutes its environment continouosly and needs to make 
> adjustsments according to its estimation of network conditions.

Most often we pick minimum values for such things, and include a 
CAPABILITY so the server can announce the value it supports.  (For 
example, see the POP "EXPIRE" capability in RFC 2449.)

However, doing so only makes sense if the client should change its 
behavior based on what the server supports.  In the case of session 
expiration, it probably makes the most sense for clients to always 
try and resume sessions, and for servers to retain sessions for as 
long as possible, subject to resource constraints.  Likely the 
session retention period will be a configurable value that an 
administrator can adjust to constrain the use of resources.

Since clients can reasonably always try and resume a session, why 
have a way to announce values?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
A logician saves the life of a space alien and is rewarded with
an offer to answer any question.  After a thought he asks: What
is the best question to ask and the correct answer to it?  After
a brief panic the alien consults her computer and says: The best
question to ask is the one you just did and the correct answer
to it is the one I gave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 23 May 2006 10:38:58 +0200

I noticed one thing.

When resuming a session, the server has to tell the mailbox then name of 
the selected mailbox (which RFC 3501 calls mailbox and this draft 
sometimes mailbox, sometimes folder). Fine.

But some mailboxes have multiple names, or are case insensitive. INBOX 
is a case in point. So some decisions must be made. Three 
possibilities:

1. The server MUST report the name the client used in SELECT verbatim. 
(Example: If the client used "select inbox", the the server MUST report 
"* FOLDER inbox", not *FOLDER INBOX".)

2. The server sends a FOLDER response to SELECT if the name used in the 
FOLDER response differs (in case or otherwise) from the name used by 
the client. (Example: If the client used "select users.alexey" and the 
server would say "* FOLDER INBOX" during SID processing, then it must 
send such a response during SELECT processing too.)

3. Add 3-4 pages of mailbox name comparison instructions, so the client 
can compare the name it used in SELECT and the name the server used in 
FOLDER.

I prefer 2, would live happily with 1, and mention 3 only because that 
would add yet another dependency on draft-newman-i18n-comparator ;)

Hm. Now I noticed one more thing. The draft says mailbox most of the 
time, but sometimes it says folder. Maybe best to stick to mailbox, as 
the base IMAP RFC does.

And another! There's an underscore in the formal grammar, I'd change 
that to a hyphen.

And a third! No, fourth! The format of international phone numbers are 
mentioned, but not defined. What's the prefix to use? 00? 8? I suggest 
adding a few words, such as "e.g.  P0044... for a number in the UK". Or 
better yet, dropping the P thing. Two independent clients running on a 
dualboot GPRS-connected laptop shouldn't use conflicting P* SIDs.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 23 May 2006 06:51:45 -0700 (PDT)

On Tue, 23 May 2006, Arnt Gulbrandsen wrote:
> (Example: If the client used "select inbox", the the server MUST report "* 
> FOLDER inbox", not *FOLDER INBOX".)

What?  This specification uses "FOLDER" as a token?!?

I strongly object to this.  "Folder" is not a word in the IMAP vocabulary, 
for a reason.

Please change this.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 May 2006 11:18:27 +0100

Mark Crispin wrote:

>> 1. The server MUST report the name the client used in SELECT 
>> verbatim. (Example: If the client used "select inbox", the the server 
>> MUST report "* FOLDER inbox", not *FOLDER INBOX".)
>
>
> I strongly object to this.  "Folder" is not a word in the IMAP 
> vocabulary, for a reason.

I am fine with replacing FOLDER with something else.

> Please change this.

If I remember MAILBOX was used in IMAPv2 or similar.
Suggestions?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 May 2006 15:15:03 +0200

Alexey Melnikov writes:
> If I remember MAILBOX was used in IMAPv2 or similar. Suggestions?

Could use "* OK [MAILBOX nstring]". But the conflict with IMAPv2 is not 
serious - it just means that IMAPv2 servers cannot implement this 
extension.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 24 May 2006 06:56:44 -0700 (PDT)

On Wed, 24 May 2006, Arnt Gulbrandsen wrote:
> Could use "* OK [MAILBOX nstring]".

Works for me.

> But the conflict with IMAPv2 is not 
> serious - it just means that IMAPv2 servers cannot implement this extension.

IMAP2 uses untagged MAILBOX and not MAILBOX inside an untagged OK.  So 
there is no conflict with IMAP2.

I doubt that any IMAP2 server will implement this.  The issue is if a 
client which implements IMAP2 can implement this; and as noted above there 
is no conflict.

-- Mark --

http://panda.com/mrc

---

From: Randall Gellens <[email-masked]>
Date: Wed, 24 May 2006 18:53:39 -0700

At 10:38 AM +0200 5/23/06, Arnt Gulbrandsen wrote:

>  And a third! No, fourth! The format of international phone numbers 
> are mentioned, but not defined. What's the prefix to use? 00? 8? I 
> suggest adding a few words, such as "e.g.  P0044... for a number in 
> the UK". Or better yet, dropping the P thing. Two independent 
> clients running on a dualboot GPRS-connected laptop shouldn't use 
> conflicting P* SIDs.

I missed this, but now that I see it, I wonder if perhaps this is 
left over from an early draft where the client chose the session ID 
(or did I just imagine that)?

The draft says:

    session-id       = string ;; a unique session identifier,
                       ;; implementation specific.  If starts from "P"
                       ;; it must be followed by an international
                       ;; phone number.

What is the purpose of this text?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"SF Public Defender: Reasonable Doubt at a Reasonable Price" --Seen on
back of jacket worn by P-D staffer, as reported by Herb Cain in Chronicle

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 May 2006 14:06:56 +0100

Randall Gellens wrote:

>> the UK". Or better yet, dropping the P thing. Two independent clients 
>> running on a dualboot GPRS-connected laptop shouldn't use conflicting 
>> P* SIDs.
>
> I missed this, but now that I see it, I wonder if perhaps this is left 
> over from an early draft where the client chose the session ID (or did 
> I just imagine that)?
>
> The draft says:
>

I think SIDs were client generated some time ago (I frankly don't 
remember now).

As SIDs are now server generated this is irrelevant. Any objections to 
removing the comment?

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 May 2006 10:35:25 -0700

At 2:06 PM +0100 5/25/06, Alexey Melnikov wrote:

>> left over from an early draft where the client chose the session 
>> ID (or did I just imagine that)?
>>
>>  The draft says:
>>

That's what I thought as well, so I think this was just left over 
from those days.

>  As SIDs are now server generated this is irrelevant. Any objections 
> to removing the comment?

Please do.

-------------- Randomly-selected tag: ---------------
Good night to spend with family, but avoid arguments with your
mate's new lover.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 May 2006 10:35:25 -0700

Please do.

---

From: <[email-masked]>
Date: Fri, 26 May 2006 11:32:56 +0300

The client is not necessariliy aware of its own MSISDN/MDN (there are proprietary means to find it out but in common practice it is intentionally not available for the client for security reasons), so including it as a MUST would be a bad decision anyway because it requires the client to have direct access to the mobile network plus some proprietary implementation (per each operator) to retreive the MSISDN/MDN. Desktops/laptops will not able to do this - what would those put there? A random phone number? What if that random phone number actually exists?
So, I support removing the phone number.
Thank You.

-----Original Message-----
From: ext Alexey Melnikov [mailto:[email-masked]] 
Sent: 25 May, 2006 16:07
To: Randall Gellens
Cc: [email-masked]
Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt

> What is the purpose of this text?

I think SIDs were client generated some time ago (I frankly don't remember now).

As SIDs are now server generated this is irrelevant. Any objections to removing the comment?

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 May 2006 18:43:28 +0100

Arnt Gulbrandsen wrote:

> I noticed one thing.
>
> When resuming a session, the server has to tell the mailbox then name 
> of the selected mailbox (which RFC 3501 calls mailbox and this draft 
> sometimes mailbox, sometimes folder

Changed to "mailbox" everywhere.

> ). Fine.
> is a case in point. So some decisions must be made.

I see your point, we don't want to make clients confused.

> Three possibilities: *
> *
> (Example: If the client used "select inbox", the the server MUST 
> report "* FOLDER inbox", not *FOLDER INBOX".)
>
> 2. The server sends a FOLDER response to SELECT if the name used in 
> the FOLDER response differs (in case or otherwise) from the name used 
> by the client. (Example: If the client used "select users.alexey" and 
> the server would say "* FOLDER INBOX" during SID processing, then it 
> must send such a response during SELECT processing too.)
>
> 3. Add 3-4 pages of mailbox name comparison instructions, so the 
> client can compare the name it used in SELECT and the name the server 
> used in FOLDER.
>
> I prefer 2, would live happily with 1,

I would prefer 1 and can live with 2, there are similar requirements for 
IMAP ACL already.
For now I've added the following text which reflects # 1:
    Note that the mailbox name MUST be reported verbatim
    as originally specified by the client in SELECT/EXAMINE. I.e. before 
server
    applies any mailbox name canonicalization (like converting "Inbox" 
or "users.andrew"
    to "INBOX").

> and mention 3 only because that would add yet another dependency on 
> draft-newman-i18n-comparator ;)

:-)

> that to a hyphen. *
> *

Fixed. Thanks.

> adding a few words, such as "e.g.  P0044... for a number in the UK". 
> Or better yet, dropping the P thing. Two independent clients running 
> on a dualboot GPRS-connected laptop shouldn't use conflicting P* SIDs.

Removed.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 May 2006 19:08:09 +0100

[I've applied most of the changes, leaving some till later, as I need to 
think about them.]

Randall Gellens wrote:

> It is proper to say "subset" since the command used "1:*"?

I've changed the UID FETCH to use 1:500, as it better reflects how 
disconnected clients resynchronize.

>   Since it is only one mailbox, I guess it is technically correct, but 
> it seems perhaps misleading.
>
>
> Section 3.1:

I've changed that to "is not provided".

> subject to denial-of-service and related concerns.

Sounds good, changed.

> For readability, I'd suggest replacing "forces" with "instructs" (or 

Done.

> Note there is a typo: "create" instead of "created".

Fixed.
[...]

> Note there is a typo: "Deny of Service" instead of "Denial of Service".

Fixed.

> I'd suggest removing the quotes around 'expire'.

Done.

> aside: "inactive(*) session" becomes "inactive (not associated with an 
> active TCP connection) session".

Changed.

> to use one from an older server, or is just confused?  Either way, I'd 
> think it would fall into the "not known" category.  So, I'd suggest 
> deleting the "first time" wording.

Deleted.

> permissions" instead of "user no longer has permissions".

Fixed.

[...]

> selected" to "that of the selected"

Changed.

Fixed. Thanks.

> Suggest rewording "client can just service these", perhaps to "client 

Changed.

[...]

> *   *If, while the client was offline, the selected mailbox was deleted

Changed.**

[...]

> Typo: add "the" between "dropping" and "TCP".

Fixed.

> Maybe change "the former" to "this".

Done.