Subject: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt

From: Chris Newman <[email-masked]>
Date: Wed, 16 May 2007 00:28:06 -0700

I'm concerned there are architectural issues with 
draft-ietf-lemonade-reconnect-client-04.txt that may create problems with IETF 
consensus on the document.  I wanted to verify that the WG has consensus on 
these specific architectural issues in addition to the document as a whole 
before I start IETF last call, as it may be more difficult to resolve these 
issues in an IETF-wide or IESG scope than in a more narrow WG scope.  My 
intention is not to force any specific changes, but rather to encourage making 
changes prior to IETF last call that might be helpful to speed IETF consensus.

1. Implicit server behavior changes

This extension has several cases where client commands trigger a server 
behavior change as a side-effect of a client command.  There has been 
significant discussion in other IETF contexts (EAI design team, IMAPEXT, ENABLE 
extension) that such behavior is undesirable and that if a server behavior 
change is to occur it should be explicit and early in the protocol exchange.  I 
would like to confirm the WG has consensus on this specific issue as I suspect 
it is likely be problematic during IETF last call.

2. Change in IMAP untagged response model

For better or worse, IMAP is a cache update protocol model rather than a 
request/response protocol model.  That means an untagged response is not bound 
to a particular command, but rather the portion of the client's cache state 
that is updated can be determined solely from the untagged response itself (the 
SEARCH response being a notable exception).  This extension changes that model 
by binding the VANISHED response to a specific command with the TAG correlator. 
Are there servers which execute client commands out-of-order so that such 
binding would be necessary?  Does the WG believe changing the fundamental IMAP 
model in this case is the best way to accomplish this specific task?

3.  VANISHED response sometimes but not always implying EXISTS change

The VANISHED response is used in two different ways: one to replace the EXPUNGE 
response to indicate a change in mailbox state at that moment (including an 
implicit EXISTS update), and one to indicate that messages were removed before 
the mailbox was selected in response to a QRESYNC select modifier or VANISHED 
UID FETCH modifier.  I suspect the logic the client must use to distinguish 
these cases is a bit subtle.  Perhaps a simplification to VANISHED to address 
issue 2 & 3 should be considered?

4. Complex interaction with CONDSTORE and UIDPLUS

This extension requires CONDSTORE and requires the server to advertise 
CONDSTORE.  That means there's a silly state where the server advertises 
QRESYNC but not CONDSTORE.  Perhaps there's a simple way to eliminate the silly 
state?  Furthermore, there is a great deal of variation in server behaviors and 
client codepaths between un-extended IMAP, IMAP + CONDSTORE, IMAP + CONDSTORE + 
QRESYNC and IMAP + CONDSTORE + QRESYNC + UIDPLUS.  Is the WG really comfortable 
with this complexity?  Perhaps QRESYNC should require UIDPLUS in addition to 
CONDSTORE?  Perhaps QRESYNC is really a refinement of CONDSTORE rather than an 
extension to it, so perhaps QRESYNC should subsume CONDSTORE and obsolete it?

                - Chris Newman
                Applications Area Director

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 May 2007 10:19:53 +0200

VERY well put. Your message describes almost everything that makes me 
uneasy about QRESYNC.

Just one comment:

Chris Newman writes:
> For better or worse, IMAP is a cache update protocol model rather than 
> a request/response protocol model.  That means an untagged response 
> is not bound to a particular command, but rather the portion of the 
> client's cache state that is updated can be determined solely from 
> the untagged response itself (the SEARCH response being a notable 
> exception).  This extension changes that model by binding the 
> VANISHED response to a specific command with the TAG correlator. Are 
> there servers which execute client commands out-of-order so that such 
> binding would be necessary?

There are servers which execute client commands concurrently. My day job 
is one, and I think there is another now. I do not know whether this 
necessitates the TAG correlator.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 16 May 2007 07:54:05 -0700 (Pacific Daylight Time)

+1

I very much oppose any change to IMAP's core principles.

On Wed, 16 May 2007, Arnt Gulbrandsen wrote:

> VERY well put. Your message describes almost everything that makes me uneasy 
> about QRESYNC.
>
> Just one comment:
>
> Chris Newman writes:
>> request/response protocol model.  That means an untagged response is not 
>> bound to a particular command, but rather the portion of the client's cache 
>> state that is updated can be determined solely from the untagged response 
>> itself (the SEARCH response being a notable exception).  This extension 
>> changes that model by binding the VANISHED response to a specific command 
>> with the TAG correlator. Are there servers which execute client commands 
>> out-of-order so that such binding would be necessary?
>
> There are servers which execute client commands concurrently. My day job is 
> one, and I think there is another now. I do not know whether this 

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 May 2007 11:37:32 +0100

Chris Newman wrote:

> draft-ietf-lemonade-reconnect-client-04.txt that may create problems 
> with IETF consensus on the document.  I wanted to verify that the WG 
> has consensus on these specific architectural issues in addition to 
> the document as a whole before I start IETF last call, as it may be 
> more difficult to resolve these issues in an IETF-wide or IESG scope 
> than in a more narrow WG scope.  My intention is not to force any 
> specific changes, but rather to encourage making changes prior to IETF 
> last call that might be helpful to speed IETF consensus.
>
> This extension has several cases where client commands trigger a 
> server behavior change as a side-effect of a client command.  There 
> has been significant discussion in other IETF contexts (EAI design 
> team, IMAPEXT, ENABLE extension) that such behavior is undesirable and 
> that if a server behavior change is to occur it should be explicit and 
> early in the protocol exchange.  I would like to confirm the WG has 
> consensus on this specific issue as I suspect it is likely be 
> problematic during IETF last call.

As per discussion during the Lemonade interim, Dave and I will change 
QRESYNC to depend on Arnt's ENABLE extension. The change will address 
this issue.

> a request/response protocol model.  That means an untagged response is 
> not bound to a particular command, but rather the portion of the 
> client's cache state that is updated can be determined solely from the 
> untagged response itself (the SEARCH response being a notable 
> exception).  This extension changes that model by binding the VANISHED 
> response to a specific command with the TAG correlator. Are there 
> servers which execute client commands out-of-order so that such 
> binding would be necessary?  Does the WG believe changing the 
> fundamental IMAP model in this case is the best way to accomplish this 
> specific task?
>
> The VANISHED response is used in two different ways: one to replace 
> the EXPUNGE response to indicate a change in mailbox state at that 
> moment (including an implicit EXISTS update), and one to indicate that 
> messages were removed before the mailbox was selected in response to a 
> QRESYNC select modifier or VANISHED UID FETCH modifier.  I suspect the 
> logic the client must use to distinguish these cases is a bit subtle.  
> Perhaps a simplification to VANISHED to address issue 2 & 3 should be 
> considered?

Based on subsequent discussion with Chris: QRESYNC will be updated to 
rename the TAG parameter to EARLIER and remove the associated command 
tag, as it was not used. Text describing that the VANISHED response with 
the EARLIER parameter doesn't decrement EXISTS would be also clarified.

Note, that the VANISHED response never changed the IMAP model. The TAG 
parameter was only used to distinguish two cases: earlier expunged 
messages and currently expunged messages.

> CONDSTORE.  That means there's a silly state where the server 
> advertises QRESYNC but not CONDSTORE.  Perhaps there's a simple way to 
> eliminate the silly state?  Furthermore, there is a great deal of 
> variation in server behaviors and client codepaths between un-extended 
> IMAP, IMAP + CONDSTORE, IMAP + CONDSTORE + QRESYNC and IMAP + 
> CONDSTORE + QRESYNC + UIDPLUS.  Is the WG really comfortable with this 
> complexity?  Perhaps QRESYNC should require UIDPLUS in addition to 
> CONDSTORE?  Perhaps QRESYNC is really a refinement of CONDSTORE rather 
> than an extension to it, so perhaps QRESYNC should subsume CONDSTORE 
> and obsolete it?

Thinking more about this: clients that would like to use the VANISHED 
responses would also likely want to use UID EXPUNGE (i.e. the UIDPLUS 
extension).
So personally I am slightly in preference of making the UIDPLUS a 
requirement for all QRESYNC-compliant servers.

However, if we do this change, it would make no difference as far as 
Lemonade Profile Bis is concerned, because servers are required to 
implement both extensions anyway.
And existing IMAP clients already have to deal with absence of UIDPLUS 
extension.

Having said that I would like to poll the WG regarding making QRESYNC 
require UIDPLUS.