From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 May 2007 12:22:23 +0100

X-Accept-LanguaFrom [email-masked] Wed May 23 09:34:41 2007
Date: Wed, 23 May 2007 11:37:32 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [lemonade] concerns with
	draft-ietf-lemonade-reconnect-client-04.txt
Cc: Chris Newman <[email-masked]>

Chris Newman wrote:

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

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.

> 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 therFrom [email-masked] Wed May 23 09:34:41 2007
Date: Wed, 23 May 2007 11:37:32 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [lemonade] concerns with
	draft-ietf-lemonade-reconnect-client-04.txt
Cc: Chris Newman <[email-masked]>

Chris Newman wrote:

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

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.

> 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 therge: en-us, en
To: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Cc: Cyrus Daboo <[email-masked]>,
	to Internet email to support diverse service enivronments
	<[email-masked]>, IMAP Extensions WG <[email-masked]>,
	Enhancements

Hi Randy,

Randall Gellens wrote:

> I hope this isn't too late to be useful.
>
> At 9:31 PM -0700 4/2/07, Dan Karp wrote:
>
>>     A user can only set and retrieve private or shared annotations on a
>>     mailbox which exists and is returned to them via a LIST or LSUB
>>     command, irrespective of whether they have read or write access to
>>     the actual message content of the mailbox.  If the client 
>> attempts to
>>     set or retrieve annotations on other mailboxes, the server MUST
>>     respond with a NO response.
>>
>>  I can understand the logic behind requiring LIST/LSUB access for 
>> reading
>>  public mailbox annotations and for setting private annotations.  But
>>  that seems to be a very low bar for setting public mailbox annotations.
>>  Adding a new ACL permission for setting annotations would make this
>>  extension more complex and would also introduce a dependency on the ACL
>>  extension, but perhaps requiring [READ-WRITE] access to the mailbox
>>  might be reasonable?
>
> Seems reasonable.  It's interesting that any user can set a shared 
> server annotation.

I was also advocating a new ACL right, but Cyrus didn't think it was needed.

> Note that, separate from Dan's comments, the description of the 
> SETMETADATA command should explicitly mention that an empty string is 
> used to set server annotations, and should include some examples of 
> doing so.
>
> Perhaps servers should be permitted to reject an attempt to set shared 
> server annotations if, based on internal configuration (that is, not 
> standardized) the user isn't allowed to do so?  That would allow 
> servers to, for example, have some users that can set any shared 
> server annotations, others that can set none, and some that can set some.

Well yes, but implementations can already do that no matter what the 
spec says.

> I think trying to standardize this would require ACL extensions and 
> introduce an ACL dependency, which we don't want to do.  This could 
> always be done in the future, based on operational experience.

 [...]

>>     Each annotation is an entry that has a hierarchical name, with each
>>     component of the name separated by a slash ("/").  An entry name 
>> MUST
>>     NOT contain two consecutive "/" characters and MUST NOT end with a
>>     "/" character.
>>
>>     Each entry is made up of a set of attributes.  Each attribute has a
>>     hierarchical name, with each component of the name separated by a
>>     period (".").  An attribute name MUST NOT contain two consecutive 
>> "."
>>     characters and MUST NOT end with a "." character.
>>
>>  My last comment is personal preference: I fear that this may be a 
>> bit of
>>  overkill for folder annotation.  I understand the need for this type of
>>  flexible syntax for ACAP's purposes, but the use cases for IMAP appear
>>  significantly more limited in scope.  In ace 
> 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?

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.

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

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.

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