[lemonade] RE: draft-gulbrandsen-imap-enable-03
Peter Coates <peter.coates@sun.com> Fri, 02 November 2007 15:17 UTC
Return-path: <lemonade-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InyGf-0004Dv-5J; Fri, 02 Nov 2007 11:17:05 -0400
Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1InyGe-0004DY-65 for lemonade-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 11:17:04 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InyGd-0004DE-Qy for lemonade@ietf.org; Fri, 02 Nov 2007 11:17:03 -0400
Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InyGZ-0001xc-FB for lemonade@ietf.org; Fri, 02 Nov 2007 11:17:03 -0400
Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA2FGwwt001632 for <lemonade@ietf.org>; Fri, 2 Nov 2007 15:16:58 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQV00G01WCM9G00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 02 Nov 2007 09:16:58 -0600 (MDT)
Received: from kluane ([129.150.37.23]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQV00I7SX3XEM90@mail-amer.sun.com>; Fri, 02 Nov 2007 09:16:46 -0600 (MDT)
Date: Fri, 02 Nov 2007 08:16:20 -0700
From: Peter Coates <peter.coates@sun.com>
In-reply-to: <472B04FD.9020100@andrew.cmu.edu>
To: 'Ken Murchison' <murch@andrew.cmu.edu>, lemonade@ietf.org, 'IMAP Extensions WG' <ietf-imapext@imc.org>
Message-id: <013f01c81d63$53778a10$fa669e30$%coates@sun.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-ca
Content-transfer-encoding: 7bit
Thread-index: AcgdQ4Yb1/MCvpl2Sh6JSH6CxQYciQAHJ3Gw
References: <472B04FD.9020100@andrew.cmu.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc:
Subject: [lemonade] RE: draft-gulbrandsen-imap-enable-03
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org
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: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Ken Murchison Sent: November 2, 2007 04:08 To: lemonade@ietf.org; 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Randall Gellens
- [lemonade] draft-gulbrandsen-imap-enable-03 Ken Murchison
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ken Murchison
- [lemonade] RE: draft-gulbrandsen-imap-enable-03 Peter Coates
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- RE: [lemonade] draft-gulbrandsen-imap-enable-03 Peter Coates
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Dan Karp
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ned Freed
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Dan Karp
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Timo Sirainen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ned Freed
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Dan Karp
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ned Freed
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mark Crispin
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mark Crispin
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Randall Gellens
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ned Freed
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Randall Gellens
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Dan Karp
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mark Crispin
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ned Freed
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Randall Gellens
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Ned Freed
- RE: [lemonade] draft-gulbrandsen-imap-enable-03 Darryl Champagne
- Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov
- RE: [lemonade] draft-gulbrandsen-imap-enable-03 Randall Gellens