RE: draft-gulbrandsen-imap-enable-03

[Peter Coates <[e-mail]>]

Let's consider ENABLE and QRESYNC.

Is the QRESYNC capability is in effect for a session, the responses sent by
the server are different from those that would otherwise be sent.  VANISHED
instead of EXPUNGED, for instance.  So, it is important that the server not
use QRESYNC features until told to by the client.

I am really against any extension that can change the protocol during the
life of the session.  I would like to see the protocol negotiated at the
start of the session.

Thus, the server does not advertise QRESYNC initially.  If the client issues
an ENABLE command, and then issues a CAPABILITY command it can try to turn
on the feature and see if the server supported it.

S: * OK [CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS
CHILDREN 
   BINARY UNSELECT SORT IDLE URLAUTH LANGUAGE ESEARCH THREAD=ORDEREDSUBJECT 
   THREAD=REFERENCES CONDSTORE ENABLE CONTEXT WITHIN XSENDER X-NETSCAPE
XSERVERINFO
   X-SUN-SORT ANNOTATE-EXPERIMENT-1 X-UNAUTHENTICATE X-SUN-IMAP
X-ANNOTATEMORE XUM1
   AUTH=PLAIN] sandman.red.iplanet.com IMAP4 service (Sun Java(tm) System
Messaging
   Server 7.0-0.01 32bit (built Oct 26 2007))
C: 1 login YYYYY XXXXX
S: 1 OK User logged in
C: 2 enable qresync foobar
S: 2 OK Completed
C: 3 capability
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS
CHILDREN 
   BINARY UNSELECT SORT CATENATE URLAUTH LANGUAGE ESEARCH
THREAD=ORDEREDSUBJECT
   THREAD=REFERENCES IDLE ENABLE CONTEXT WITHIN XSENDER X-NETSCAPE
XSERVERINFO
   X-SUN-SORT ANNOTATE-EXPERIMENT-1 X-UNAUTHENTICATE X-SUN-IMAP
X-ANNOTATEMORE XUM1
   CONDSTORE QRESYNC
S: 3 OK Completed

The new capability vector sent after the enable command reflect the new
negotiated protocol level.  I would have liked CONDSTORE to have to be
enabled, but it was too late to do that, and we are stuck with 42 different
ways that the CONDSTORE extension can be enabled. (note that turning on
QRESYNC implies turning on CONDSTORE)

I have argued that the enable command only be allowed near the start of a
session, only at the first command, or as the first command after
authentication, but I do not think I have achieved much traction on that
idea as it implies another state for the protocol engine.  I can see that
that is an attractive argument for some, but if feels a bit academic and
pedantic to me.


Peter

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Ken Murchison
Sent: November 2, 2007 04:08
To: [e-mail]; IMAP Extensions WG
Subject: draft-gulbrandsen-imap-enable-03


After looking at the current draft on my way towards implementing 
QRESYNC, I'm wondering why ENABLE is allowed to be used blindly.  I 
don't see any reason why ENABLE should be allowed before the client 
knows that a particular extension is supported (via CAPABILITY).

In particular, the second example in section 3 seems strange to me, and 
AFAICT, doing ENABLE before CAPABILITY doesn't gain anything in terms of 
round trips.  I also don't like the fact that we're documenting that 
ENABLE can be used to probe for extensions (as per paragraph 2 in 
section 5).  We already have a command to list extensions.

If we specify that a client MUST NOT try to enable an extension that 
isn't listed by CAPABILITY, then all the server has to worry about 
parsing are those extensions that it supports and are enable-able. 
Trying to ENABLE any other other extensions, whether unknown, 
unenable-able, or unsupported can all result in BAD.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University