From lemonade-bounces@ietf.org Fri Nov 02 07:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InuNa-0006Nh-3a; Fri, 02 Nov 2007 07:07:58 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1InuNY-0006Lh-Lq for lemonade-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 07:07:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InuNY-0006Fe-Bc for lemonade@ietf.org; Fri, 02 Nov 2007 07:07:56 -0400 Received: from smtp.andrew.cmu.edu ([128.2.10.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InuNS-000373-V8 for lemonade@ietf.org; Fri, 02 Nov 2007 07:07:51 -0400 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lA2B7nGV005776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Nov 2007 07:07:50 -0400 Message-ID: <472B04FD.9020100@andrew.cmu.edu> Date: Fri, 02 Nov 2007 07:07:41 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lemonade@ietf.org, IMAP Extensions WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.212 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [lemonade] 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org 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 From lemonade-bounces@ietf.org Fri Nov 02 07:26:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inuec-0000Cf-Bf; Fri, 02 Nov 2007 07:25:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Inuea-0000Bh-E7 for lemonade-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 07:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inuea-0000BZ-4f for lemonade@ietf.org; Fri, 02 Nov 2007 07:25:32 -0400 Received: from smtp.andrew.cmu.edu ([128.2.10.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InueT-0001vB-Tv for lemonade@ietf.org; Fri, 02 Nov 2007 07:25:32 -0400 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lA2BPADE006622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Nov 2007 07:25:10 -0400 Message-ID: <472B090D.1060303@andrew.cmu.edu> Date: Fri, 02 Nov 2007 07:25:01 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lemonade@ietf.org, IMAP Extensions WG Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> In-Reply-To: <472B04FD.9020100@andrew.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.212 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ken Murchison wrote: > 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. One more thing: What is supposed to happen if a client does 'ENABLE CONDSTORE THREAD' on a server that supports both extensions? Should we use untagged OK responses to tell the client which extensions were enabled? What is the final result of the command? -- 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 From lemonade-bounces@ietf.org Fri Nov 02 11:18:13 2007 Return-path: 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 ; 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 In-reply-to: <472B04FD.9020100@andrew.cmu.edu> To: "'Ken Murchison'" , lemonade@ietf.org, "'IMAP Extensions WG'" 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 List-Unsubscribe: , List-Post: List-Help: List-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 From lemonade-bounces@ietf.org Sun Nov 04 05:44:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IocyI-0004mw-Dm; Sun, 04 Nov 2007 05:44:50 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IocyG-0004lx-IG for lemonade-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 05:44:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IocyG-0004ie-6y for lemonade@ietf.org; Sun, 04 Nov 2007 05:44:48 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IocyD-0006rX-G0 for lemonade@ietf.org; Sun, 04 Nov 2007 05:44:46 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 7B8744AC9A; Sun, 4 Nov 2007 11:45:00 +0100 (CET) Message-Id: Date: Sun, 4 Nov 2007 11:45:06 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> In-Reply-To: <472B04FD.9020100@andrew.cmu.edu> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ken Murchison writes: > 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). Two reasons. 1. It allows the client to use a single invariant enable command. The client doesn't have to do any string concatenation, it can just do "if ( server supports enable ) send its enable command". 2. It allows the client to send a single enable command early, even though the server it's talking to (before authentication) may not even know the complete list of capabilities that will be available after authentication. People asked for both of these properties. > 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. That's right. > 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. I'm perfectly happy taking that out, if that would be appropriate. I thought this sort of thing was supposed to be listed in security considerations. > 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. Please discuss that with Peter Coates. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Nov 04 05:50:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iod3W-00014H-Dj; Sun, 04 Nov 2007 05:50:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iod3U-00013j-T1 for lemonade-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 05:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iod3U-00012y-JA for lemonade@ietf.org; Sun, 04 Nov 2007 05:50:12 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iod3S-0004bD-VO for lemonade@ietf.org; Sun, 04 Nov 2007 05:50:12 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B10FB4AC9A; Sun, 4 Nov 2007 11:50:26 +0100 (CET) Message-Id: Date: Sun, 4 Nov 2007 11:50:33 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> <472B090D.1060303@andrew.cmu.edu> In-Reply-To: <472B090D.1060303@andrew.cmu.edu> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ken Murchison writes: > One more thing: > > What is supposed to happen if a client does 'ENABLE CONDSTORE THREAD' > on a server that supports both extensions? BAD if the server is careful, because THREAD isn't ENABLE-ish. > Should we use untagged OK responses to tell the client which > extensions were enabled? If so, then a server handling unauthenticated connections would have to know what capabilities will be available to that user after authentication. > What is the final result of the command? 'ENABLE CONDSTORE' before authentication has no immediate effect. It takes effect only after authentication, at which point it has acted as a 'condstore enabling command'. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 06 21:23:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpaZJ-0008MI-Vp; Tue, 06 Nov 2007 21:23:01 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IpaZI-0008MC-JU for lemonade-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 21:23:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpaZI-0008M4-8m for lemonade@ietf.org; Tue, 06 Nov 2007 21:23:00 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpaZH-00079P-PX for lemonade@ietf.org; Tue, 06 Nov 2007 21:23:00 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA72MwrQ019958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2007 18:22:58 -0800 Received: from [192.168.1.13] (vpn-10-50-16-40.qualcomm.com [10.50.16.40]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA72MuPp032004; Tue, 6 Nov 2007 18:22:57 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <472B04FD.9020100@andrew.cmu.edu> <472B090D.1060303@andrew.cmu.edu> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 6 Nov 2007 18:20:52 -0800 To: Arnt Gulbrandsen , lemonade@ietf.org, ietf-imapext@imc.org From: Randall Gellens Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:50 AM +0100 11/4/07, Arnt Gulbrandsen wrote: > If so, then a server handling unauthenticated connections would > have to know what capabilities will be available to that user after > authentication. I think it is worth mentioning this in the draft, as a clarification for the response not indicating which capabilities were/will be enabled. It'll save readers wondering about it. > >> What is the final result of the command? > > 'ENABLE CONDSTORE' before authentication has no immediate effect. > It takes effect only after authentication, at which point it has > acted as a 'condstore enabling command'. This also is worth mentioning in the draft. In the case of CONDSTORE, the server could internally enable it right away; it just won't have any effect until after a mailbox is selected, which can't be until after authentication. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Good night to spend with family, but avoid arguments with your mate's new lover. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 07 16:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsEy-0000iD-CR; Wed, 07 Nov 2007 16:15:12 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IpsEp-0000Zi-N6 for lemonade-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 16:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsEp-0000ZV-9K; Wed, 07 Nov 2007 16:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpsEo-0001YF-LJ; Wed, 07 Nov 2007 16:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 430FA175C8; Wed, 7 Nov 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IpsEn-0002qI-OM; Wed, 07 Nov 2007 16:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Nov 2007 16:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : The Lemonade Profile Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-profile-bis-06.txt Pages : 35 Date : 2007-11-7 This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-profile-bis-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-profile-bis-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-7152902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-7152902.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Nov 09 11:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWXQ-0002Y1-SY; Fri, 09 Nov 2007 11:16:56 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqWXP-0002Xv-2w for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 11:16:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWXO-0002W5-NM for lemonade@ietf.org; Fri, 09 Nov 2007 11:16:54 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqWXO-00006p-3w for lemonade@ietf.org; Fri, 09 Nov 2007 11:16:54 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 9 Nov 2007 16:16:52 +0000 Message-ID: <473487D3.4020002@isode.com> Date: Fri, 09 Nov 2007 16:16:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: >> 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. > > I'm perfectly happy taking that out, if that would be appropriate. I > thought this sort of thing was supposed to be listed in security > considerations. Based on various off-list discussions I got impression that several people really disliked that. So I am suggesting the following change: Replace: The server MUST NOT change the CAPABILITY list as a result of executing ENABLE. With: The server MUST NOT change the CAPABILITY list as a result of executing ENABLE, i.e. a CAPABILITY command issued right after an ENABLE command MUST list the same capabilities as a CAPABILITY command issued before the ENABLE command. The following example demonstrates that: C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t1 OK foo C: t2 ENABLE CONDSTORE X-GOOD-IDEA S: t2 OK foo C: t3 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t3 OK foo again and also add: Note that according to [RFC3501] the list of advertised capabilities MAY change after a STARTTLS and/or AUTHENTICATE/LOGIN command. The ENABLE command doesn't change that. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 09 12:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXcd-0002EK-EA; Fri, 09 Nov 2007 12:26:23 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqXcc-0002ED-8H for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 12:26:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXcb-0002Dl-Up for lemonade@ietf.org; Fri, 09 Nov 2007 12:26:21 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqXcY-0006Yn-6K for lemonade@ietf.org; Fri, 09 Nov 2007 12:26:21 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA9HQHM3020135 for ; Fri, 9 Nov 2007 17:26:17 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 <0JR90060119K1Z00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 09 Nov 2007 10:26:17 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR9009D11QLJL50@mail-amer.sun.com>; Fri, 09 Nov 2007 10:26:06 -0700 (MST) Date: Fri, 09 Nov 2007 09:24:40 -0800 From: Peter Coates Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: <473487D3.4020002@isode.com> To: "'Alexey Melnikov'" , "'Arnt Gulbrandsen'" Message-id: <01a601c822f5$7c13bf60$743b3e20$%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: Acgi7mapDZxScV0TRK6OP6mgBJ9ZmQAAWyYQ References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org What? If Enabling an extension does not affect the CAPABILITY vector, and if the ENABLE command silenty ignores extensions the server does not wan to allow or which it doe not know, then after the sequence C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t1 OK foo C: t2 ENABLE CONDSTORE X-GOOD-IDEA S: t2 OK foo the client does not know whether CONDSTORE is enabled or not. I assert that either the enable command has to tell the client which things worked (or which things didn't), or the capability vector has to change Thus the sequence should be either C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t1 OK foo C: t2 ENABLE CONDSTORE X-GOOD-IDEA S: t2 OK foo C: t3 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE CONDSTORE S: t3 OK foo again Or C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t1 OK foo C: t2 ENABLE CONDSTORE X-GOOD-IDEA S: * OK [ENABLED CONDSTORE] or some variant of this S: t2 OK foo C: t3 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t3 OK foo again Peter -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Alexey Melnikov Sent: November 9, 2007 08:16 To: Arnt Gulbrandsen Cc: lemonade@ietf.org; ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 Arnt Gulbrandsen wrote: >> 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. > > I'm perfectly happy taking that out, if that would be appropriate. I > thought this sort of thing was supposed to be listed in security > considerations. Based on various off-list discussions I got impression that several people really disliked that. So I am suggesting the following change: Replace: The server MUST NOT change the CAPABILITY list as a result of executing ENABLE. With: The server MUST NOT change the CAPABILITY list as a result of executing ENABLE, i.e. a CAPABILITY command issued right after an ENABLE command MUST list the same capabilities as a CAPABILITY command issued before the ENABLE command. The following example demonstrates that: C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t1 OK foo C: t2 ENABLE CONDSTORE X-GOOD-IDEA S: t2 OK foo C: t3 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE S: t3 OK foo again and also add: Note that according to [RFC3501] the list of advertised capabilities MAY change after a STARTTLS and/or AUTHENTICATE/LOGIN command. The ENABLE command doesn't change that. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 09 12:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXtR-0000zY-Go; Fri, 09 Nov 2007 12:43:45 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqXtQ-0000xb-9U for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 12:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXtP-0000xT-Vm for lemonade@ietf.org; Fri, 09 Nov 2007 12:43:43 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqXtM-0007JP-Ln for lemonade@ietf.org; Fri, 09 Nov 2007 12:43:43 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 17C7CDE9324; Fri, 9 Nov 2007 09:43:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id B39601D5571; Fri, 9 Nov 2007 09:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYO08Jbmgy7z; Fri, 9 Nov 2007 09:43:33 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 70E861D5572; Fri, 9 Nov 2007 09:43:33 -0800 (PST) Date: Fri, 9 Nov 2007 09:43:33 -0800 (PST) From: Dan Karp To: Peter Coates Message-ID: <90089910.86811194630213289.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1680368567.86531194630050060.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.132.81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: lemonade@ietf.org, ietf-imapext@imc.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I assert that either the enable command has to tell the client which > things worked (or which things didn't), or the capability vector has > to change. I think that we're unnecessarily complicating a fundamentally simple idea. Why not just have ENABLE fail unless all the requested capabilities are implemented and enable-able? This would generally require waiting until after authentication to call ENABLE, but I'm not even sure why it's ever useful in the NOT AUTHENTICATED state... I'm told that the "ignore unknown capabilities" behavior was added so one client author could use a static ENABLE request, but simpler is probably better here. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 09 14:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ9F-0005KH-G7; Fri, 09 Nov 2007 14:04:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqZ9E-0005JK-LL for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ9E-0005J2-BU for lemonade@ietf.org; Fri, 09 Nov 2007 14:04:08 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZ9A-000268-V3 for lemonade@ietf.org; Fri, 09 Nov 2007 14:04:08 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 9 Nov 2007 19:04:03 +0000 Message-ID: <4734AEF8.4090201@isode.com> Date: Fri, 09 Nov 2007 19:03:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Coates Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> In-Reply-To: <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Peter Coates wrote: >What? If Enabling an extension does not affect the CAPABILITY vector, and >if the ENABLE command silenty ignores extensions the server does not want to >allow or which it does not know, then after the sequence > > C: t1 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > S: t1 OK foo > C: t2 ENABLE CONDSTORE X-GOOD-IDEA > S: t2 OK foo > >the client does not know whether CONDSTORE is enabled or not. > >I assert that either the enable command has to tell the client which things worked (or >which things didn't), or the capability vector has to change > > Agreed, but this can (and I think should) be done in a way which doesn't contradict text I've suggested. See below. >Thus the sequence should be either > C: t1 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > S: t1 OK foo > C: t2 ENABLE CONDSTORE X-GOOD-IDEA > S: t2 OK foo > C: t3 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE >CONDSTORE > S: t3 OK foo again > > I dislike that, because you now implicitly saying that there are magic extensions which don't work unless the client knows how to enable them. Really, the server should have advertised the CONDSTORE extension to begin with. >Or > C: t1 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > S: t1 OK foo > C: t2 ENABLE CONDSTORE X-GOOD-IDEA > S: * OK [ENABLED CONDSTORE] or some variant of this > > (Or just use the CAPABILITY response code: it serves the same purpose + can save a round trip in this case.) So if you insist on being able to change the capability list, it is much better to return the updated list using the CAPABILITY response code. Clients should already be able to handle unsolicited updates, in particular because the CAPABILITY response code payload frequently changes after LOGIN/AUTHENTICATE. This allows the client to figure out if an extension can be enabled after all. > S: t2 OK foo > C: t3 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > S: t3 OK foo again > > >Peter > > >-----Original Message----- >From: owner-ietf-imapext@mail.imc.org >[mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Alexey Melnikov >Sent: November 9, 2007 08:16 >To: Arnt Gulbrandsen >Cc: lemonade@ietf.org; ietf-imapext@imc.org >Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 > > >Arnt Gulbrandsen wrote: > > >>>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. >>> >>> >>I'm perfectly happy taking that out, if that would be appropriate. I >>thought this sort of thing was supposed to be listed in security >>considerations. >> >> >Based on various off-list discussions I got impression that several >people really disliked that. >So I am suggesting the following change: > >Replace: > The server MUST NOT change the CAPABILITY list as a result of > executing ENABLE. > >With: > The server MUST NOT change the CAPABILITY list as a result of > executing ENABLE, i.e. a CAPABILITY command issued right after > an ENABLE command MUST list the same capabilities as a CAPABILITY > command issued before the ENABLE command. The following example > demonstrates that: > > C: t1 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > S: t1 OK foo > C: t2 ENABLE CONDSTORE X-GOOD-IDEA > S: t2 OK foo > C: t3 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > S: t3 OK foo again > >and also add: > > Note that according to [RFC3501] the list of advertised capabilities MAY > change after a STARTTLS and/or AUTHENTICATE/LOGIN command. The ENABLE > command doesn't change that. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 09 17:47:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqcdf-0003E4-OC; Fri, 09 Nov 2007 17:47:47 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iqcdf-0003Dy-0V for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 17:47:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqcde-0003Dq-M5 for lemonade@ietf.org; Fri, 09 Nov 2007 17:47:46 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iqcde-0000Bp-51 for lemonade@ietf.org; Fri, 09 Nov 2007 17:47:46 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNIXYGPV7400GR1B@mauve.mrochek.com> for lemonade@ietf.org; Fri, 9 Nov 2007 14:47:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNH2LGCDDS00BDC1@mauve.mrochek.com>; Fri, 09 Nov 2007 14:47:35 -0800 (PST) Message-id: <01MNIXYDTMIU00BDC1@mauve.mrochek.com> Date: Fri, 09 Nov 2007 14:42:08 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: "Your message dated Fri, 09 Nov 2007 09:43:33 -0800 (PST)" <90089910.86811194630213289.JavaMail.root@dogfood.zimbra.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 References: <1680368567.86531194630050060.JavaMail.root@dogfood.zimbra.com> <90089910.86811194630213289.JavaMail.root@dogfood.zimbra.com> To: Dan Karp DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1194648459; h=Date: From:Subject:MIME-version:Content-type; b=qTe9qPMuQt/Rg7aCv32g+1Tcr HqI4eJhT7uFCz948EM5EkyPchsO/oKutLLdW6bk+XHUQqnCBCVeWbPC/rHeVA== X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > I assert that either the enable command has to tell the client which > > things worked (or which things didn't), or the capability vector has > > to change. > I think that we're unnecessarily complicating a fundamentally simple idea. > Why not just have ENABLE fail unless all the requested capabilities are > implemented and enable-able? This would generally require waiting until after > authentication to call ENABLE, but I'm not even sure why it's ever useful in > the NOT AUTHENTICATED state... Because clients can have have both features they require and features they can use if available. If things work this way a client would have to issue one ENABLE for the required stuff and then a separate ENABLE for each optional thing they can use. Some clients may be able to get away with requiring certain extensions be present. Others have to work in more heterogenous environments. > I'm told that the "ignore unknown capabilities" behavior was added so one > client author could use a static ENABLE request, but simpler is probably better > here. Your proposal is at least a complex IMO. My personal preference is to have the initial capability list not list things that can be enabled, have enable turn on whatit can and ignore the rest, and have any enabled changes show up in subsequent capability lists. This leverages existing protocol features and doesn't invent new syntax or require multiple commands. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 09 18:33:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqdM8-0007ab-Dn; Fri, 09 Nov 2007 18:33:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqdM7-0007aV-Em for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 18:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqdM7-0007a1-4Y for lemonade@ietf.org; Fri, 09 Nov 2007 18:33:43 -0500 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqdM6-0003v0-Hr for lemonade@ietf.org; Fri, 09 Nov 2007 18:33:43 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Fri, 9 Nov 2007 23:33:38 +0000 MIME-Version: 1.0 Message-Id: <24023.1194651216.952135@peirce.dave.cridland.net> Date: Fri, 09 Nov 2007 23:33:36 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] TLS reauth hack X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I finally got around to publishing draft-cridland-sasl-tls-sessions-00.txt This describes a potential hack using TLS session resumption and SASL EXTERNAL to essentially give single RTT reauthentication to any SASL mechanism supporting channel binding. I don't know we actually *have* any SASL mechanisms supporting channel binding yet, but nevertheless, hypothetical comments would be welcome, in theory. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 09 22:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqh8H-0005OB-8p; Fri, 09 Nov 2007 22:35:41 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iqh8G-0005O5-Qt for lemonade-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 22:35:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqh8G-0005N6-GY for lemonade@ietf.org; Fri, 09 Nov 2007 22:35:40 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqh8D-0001cn-4r for lemonade@ietf.org; Fri, 09 Nov 2007 22:35:40 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id 861B4DE8E4C; Fri, 9 Nov 2007 19:35:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 53EC21D5571; Fri, 9 Nov 2007 19:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWev1XetcJeF; Fri, 9 Nov 2007 19:35:28 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 7E6891D5574; Fri, 9 Nov 2007 19:35:28 -0800 (PST) Date: Fri, 9 Nov 2007 19:35:28 -0800 (PST) From: Dan Karp To: Ned Freed Message-ID: <260231135.117501194665728404.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1679890550.110521194650065847.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.132.81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > Why not just have ENABLE fail unless all the requested capabilities > > are implemented and enable-able? This would generally require waiting > > until after authentication to call ENABLE, but I'm not even sure why > > it's ever useful in the NOT AUTHENTICATED state... > > Because clients can have have both features they require and features > they can use if available. If things work this way a client would have > to issue one ENABLE for the required stuff and then a separate ENABLE > for each optional thing they can use. Why? Authenticate, issue CAPABILITY (or get an unsolicited one from the authentication step), check to see if it includes all the required capabilities, and issue a single ENABLE containing all the capabilities (required and desired) that you want to enable. That's about as simple as you can make it if some servers won't return a full capability list until after authentication. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Nov 10 07:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqppL-000203-NX; Sat, 10 Nov 2007 07:52:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqppK-0001zu-ML for lemonade-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 07:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqppK-0001zm-Bd for lemonade@ietf.org; Sat, 10 Nov 2007 07:52:42 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqppH-0006rf-Sc for lemonade@ietf.org; Sat, 10 Nov 2007 07:52:42 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:36956) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1IqppG-0003XI-8C (Exim 4.63) (return-path ); Sat, 10 Nov 2007 12:52:38 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IqppG-0003EU-Gp (Exim 4.67) (return-path ); Sat, 10 Nov 2007 12:52:38 +0000 Date: Sat, 10 Nov 2007 12:52:38 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] TLS reauth hack In-Reply-To: <24023.1194651216.952135@peirce.dave.cridland.net> Message-ID: References: <24023.1194651216.952135@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 9 Nov 2007, Dave Cridland wrote: > I finally got around to publishing draft-cridland-sasl-tls-sessions-00.txt Can you resolve the ambiguity problem by requiring that the client observe that the server does not advertise EXTERNAL for a full TLS negotiation but does when the client re-uses a TLS session ID that was set up by a connection that used channel-bound SASL? The client then knows that the EXTERNAL is related to the TLS session, and therefore knows that it'll get the same authzid as previously. Tony. -- f.a.n.finch http://dotat.at/ NORTHEAST SOLE LUNDY FASTNET: NORTHWESTERLY 5 OR 6. MODERATE. MAINLY FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Nov 10 08:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqqnJ-0004qO-44; Sat, 10 Nov 2007 08:54:41 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqqnH-0004oT-1Y for lemonade-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 08:54:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqqnG-0004oI-O4 for lemonade@ietf.org; Sat, 10 Nov 2007 08:54:38 -0500 Received: from dovecot.org ([82.118.211.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqqnD-0000Rl-66 for lemonade@ietf.org; Sat, 10 Nov 2007 08:54:38 -0500 Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 4BC99FA8A68; Sat, 10 Nov 2007 15:54:03 +0200 (EET) Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 From: Timo Sirainen To: Dan Karp In-Reply-To: <90089910.86811194630213289.JavaMail.root@dogfood.zimbra.com> References: <90089910.86811194630213289.JavaMail.root@dogfood.zimbra.com> Date: Sat, 10 Nov 2007 15:54:02 +0200 Message-Id: <1194702842.25921.939.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0796089389==" Errors-To: lemonade-bounces@ietf.org --===============0796089389== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7On8w524wMwiKs5SaFt3" --=-7On8w524wMwiKs5SaFt3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-11-09 at 09:43 -0800, Dan Karp wrote: > I think that we're unnecessarily complicating a fundamentally simple > idea. Why not just have ENABLE fail unless all the requested > capabilities are implemented and enable-able? This would generally > require waiting until after authentication to call ENABLE, but I'm not > even sure why it's ever useful in the NOT AUTHENTICATED state... I'd really like if it worked only after authentication. I think NOT AUTHENTICATED state should be as simple as possible. The user is still untrusted at that point, so the less features server needs to worry about at that point, the less chances there are for bugs/security holes. --=-7On8w524wMwiKs5SaFt3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHNbf6yUhSUUBViskRApg6AKCBIxzVS4mJmhmEfMxCoMizI1qn6gCgiZVH sJdkuJg+zHMg7cqt62gxa/I= =HLxP -----END PGP SIGNATURE----- --=-7On8w524wMwiKs5SaFt3-- --===============0796089389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0796089389==-- From lemonade-bounces@ietf.org Sat Nov 10 11:09:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqsuC-0000H7-BN; Sat, 10 Nov 2007 11:09:56 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqsuB-0000Ec-IJ for lemonade-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 11:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqsuB-0000ET-8h for lemonade@ietf.org; Sat, 10 Nov 2007 11:09:55 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqsu7-0004du-Fs for lemonade@ietf.org; Sat, 10 Nov 2007 11:09:55 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNJYDF84UO00G9QK@mauve.mrochek.com> for lemonade@ietf.org; Sat, 10 Nov 2007 08:09:44 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNH2LGCDDS00BDC1@mauve.mrochek.com>; Sat, 10 Nov 2007 08:09:39 -0800 (PST) Message-id: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> Date: Sat, 10 Nov 2007 07:59:30 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: "Your message dated Fri, 09 Nov 2007 19:35:28 -0800 (PST)" <260231135.117501194665728404.JavaMail.root@dogfood.zimbra.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 References: <1679890550.110521194650065847.JavaMail.root@dogfood.zimbra.com> <260231135.117501194665728404.JavaMail.root@dogfood.zimbra.com> To: Dan Karp DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1194710983; h=Date: From:Subject:MIME-version:Content-type; b=uU2NaHSPx2QxJv4Zif6AsOhBq wc9Lc4OR0GWvjbbi+4kOI3KiVTujbsc6JRMRj28Nx4+CaILGsKDrWAN+0zZQg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Ned Freed , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > > Why not just have ENABLE fail unless all the requested capabilities > > > are implemented and enable-able? This would generally require waiting > > > until after authentication to call ENABLE, but I'm not even sure why > > > it's ever useful in the NOT AUTHENTICATED state... > > > > Because clients can have have both features they require and features > > they can use if available. If things work this way a client would have > > to issue one ENABLE for the required stuff and then a separate ENABLE > > for each optional thing they can use. > Why? Authenticate, issue CAPABILITY (or get an unsolicited one from the > authentication step), check to see if it includes all the required > capabilities, and issue a single ENABLE containing all the capabilities > (required and desired) that you want to enable. One problem is that this presumes that enable will always succeed for anything that was previousliy listed as a capability. This strikes me as risky - there could be things where the server cannot tell there's a problem enabling it until it actually goes through the steps of doing so. I strongly prefer a model where it is possible to check to see what's turned on and what is not. > That's about as simple as you can make it if some servers won't return a full > capability list until after authentication. Well, let's see. In your approach the client authenticates, sends a capability command, checks the result to make sure the stuff that's required is there, and then constructs a enable command depending on that response. In my approach the client authenticates and then sends the enable command followed by a capability command to see the results of the enable. I think the latter is safer, allows more flexibility for server implementations, and is actually simpler on the client side ot implement. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Nov 10 11:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqteu-0002EX-Qz; Sat, 10 Nov 2007 11:58:12 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iqteu-0002ES-EQ for lemonade-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 11:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqteu-0002Dt-4O for lemonade@ietf.org; Sat, 10 Nov 2007 11:58:12 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqter-0006FN-QG for lemonade@ietf.org; Sat, 10 Nov 2007 11:58:12 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 65D03DE842F; Sat, 10 Nov 2007 08:58:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 36A5F1D5585; Sat, 10 Nov 2007 08:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCbUtdsC3C7E; Sat, 10 Nov 2007 08:58:02 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 6EF2E1D5581; Sat, 10 Nov 2007 08:58:02 -0800 (PST) Date: Sat, 10 Nov 2007 08:58:02 -0800 (PST) From: Dan Karp To: Ned Freed Message-ID: <1441926969.141961194713882140.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.132.81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Ned Freed , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > That's about as simple as you can make it if some servers won't > > return a full capability list until after authentication. > > Well, let's see. In your approach the client authenticates, sends a > capability command, checks the result to make sure the stuff that's > required is there, and then constructs a enable command depending > on that response. > > In my approach the client authenticates and then sends the enable > command followed by a capability command to see the results of the > enable. Yeah, but that's not how IMAP or CONDSTORE work. If a server supports a capability, it must come back in a post-authentication CAPABILITY response. Not every client will support ENABLE. When you have extensions like CONDSTORE that can be enabled either explicitly via ENABLE or implicitly via certain command arguments, a non-ENABLE-savvy client will have no idea that it can use CONDSTORE. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Nov 10 13:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqv4f-0005hs-1b; Sat, 10 Nov 2007 13:28:53 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iqv4e-0005hk-9f for lemonade-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 13:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqv4e-0005hY-0C for lemonade@ietf.org; Sat, 10 Nov 2007 13:28:52 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqv4b-0000qY-FQ for lemonade@ietf.org; Sat, 10 Nov 2007 13:28:51 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNK37QASKW00FRG8@mauve.mrochek.com> for lemonade@ietf.org; Sat, 10 Nov 2007 10:28:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNH2LGCDDS00BDC1@mauve.mrochek.com>; Sat, 10 Nov 2007 10:28:37 -0800 (PST) Message-id: <01MNK37NMXWY00BDC1@mauve.mrochek.com> Date: Sat, 10 Nov 2007 10:25:51 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: "Your message dated Sat, 10 Nov 2007 08:58:02 -0800 (PST)" <1441926969.141961194713882140.JavaMail.root@dogfood.zimbra.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 References: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> <1441926969.141961194713882140.JavaMail.root@dogfood.zimbra.com> To: Dan Karp DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1194719321; h=Date: From:Subject:MIME-version:Content-type; b=esbw0peJZRTMj5vkzlCXpdPt0 TBRpDFFVqryTCiIOdt158DQX4q4e2A9GWj6DZe645PUIN6DFLikZP69FIEUMA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Ned Freed , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > > That's about as simple as you can make it if some servers won't > > > return a full capability list until after authentication. > > > > Well, let's see. In your approach the client authenticates, sends a > > capability command, checks the result to make sure the stuff that's > > required is there, and then constructs a enable command depending > > on that response. > > > > In my approach the client authenticates and then sends the enable > > command followed by a capability command to see the results of the > > enable. > Yeah, but that's not how IMAP or CONDSTORE work. We get to define how IMAP and CONDSTORE work. > If a server supports a capability, it must come back in a > post-authentication CAPABILITY response. I quite simply disagree. This may be how things have been done in the past but it isn't necessarily how things need to work in the future. > Not every client will support ENABLE. When you have extensions like CONDSTORE > that can be enabled either explicitly via ENABLE or implicitly via certain > command arguments, a non-ENABLE-savvy client will have no idea that it can use > CONDSTORE. Nothing prevents us from requiring ENABLE in order to use extensions that change command response syntax. In fact I think such a requirement would be a very good idea. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Nov 10 13:56:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqvVe-0006tB-Nf; Sat, 10 Nov 2007 13:56:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IqvVd-0006r8-HO for lemonade-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 13:56:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqvVd-0006r0-6j for lemonade@ietf.org; Sat, 10 Nov 2007 13:56:45 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqvVc-0003Ci-Kg for lemonade@ietf.org; Sat, 10 Nov 2007 13:56:45 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAAIuh21002149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Nov 2007 10:56:43 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAAIufdg013399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Nov 2007 10:56:42 -0800 Date: Sat, 10 Nov 2007 10:56:40 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-Reply-To: <01MNK37NMXWY00BDC1@mauve.mrochek.com> Message-ID: References: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> <1441926969.141961194713882140.JavaMail.root@dogfood.zimbra.com> <01MNK37NMXWY00BDC1@mauve.mrochek.com> User-Agent: Alpine 0.99999 (OSX 810 2007-11-10) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.10.102925 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat, 10 Nov 2007, Ned Freed wrote: > We get to define how IMAP and CONDSTORE work. Slight note of unpleasant reality: IMAP is a very large and complex protocol, even at its base level. It is difficult to implement correctly; and fewer people are trying. The IMAP client world is dominated by programs such as Outlook and Thunderbird, which use only a tiny fraction of the base specification facilities and (with the possible exception of UIDPLUS) none of the extensions. The IMAP server world is being taken over by Exchange and GMail, neither of which implement more than a fraction (as in one or two) of the current set of extensions. What's more, Exchange's implementation of the base specification is buggy, and GMail's implementation of the base specification is incomplete. There are numerous other servers which have incomplete and/or incorrect implementations of the base specification, and it gets worse when you get to extensions. Pine/Alpine is rapidly becoming less viable in the world, not because it is text based but because it depends upon servers that offer full and correct implementation of the base specification and of any extensions. I am currently fighting a losing battle on deployment of [censored] server which does not correctly implement IMAP (and thus breaks Pine/Alpine) with the counter-argument being "it works fine for Outlook and Thunderbird." That's right, boys and girls, you (meaning the IETF) are no longer defining IMAP. Microsoft, Mozilla, Google, etc. are who defines IMAP today. They may pay lip service to your definition, but they ignore it in real life. It bewilders me that you are still talking about making IMAP large and more complex. Do you really think that the tide is going to be turned back? I now return you back to your fascinating discussion. -- 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. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 00:50:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSC3-0003MD-Ns; Mon, 12 Nov 2007 00:50:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrSC1-0003Gp-SU for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 00:50:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSC1-0003El-FN for lemonade@ietf.org; Mon, 12 Nov 2007 00:50:41 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrSC1-0001o3-0r for lemonade@ietf.org; Mon, 12 Nov 2007 00:50:41 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id E0EE426E72; Mon, 12 Nov 2007 05:50:40 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IrSC0-0008NG-PO; Mon, 12 Nov 2007 00:50:40 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: gparsons@nortel.com From: IETF I-D Submission Tool Message-Id: Date: Mon, 12 Nov 2007 00:50:40 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org Subject: [lemonade] New Version Notification for draft-ietf-lemonade-architecture-00 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A new version of I-D, draft-ietf-lemonade-architecture-00.txt has been successfuly submitted by Glenn Parsons and posted to the IETF repository. Filename: draft-ietf-lemonade-architecture Revision: 00 Title: LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet Mail Creation_date: 2007-11-12 WG ID: lemonade Number_of_pages: 24 Abstract: This document specifies the architecture for mobile email, as described by the OMA, using Internet Mail protocols. This architecture is the basis of the work of the LEMONADE WG and is a guidleine for the LEMONADE Profile.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. The IETF Secretariat. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 01:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSLj-0007T5-Qr; Mon, 12 Nov 2007 01:00:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrSLb-00078w-8s for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 01:00:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSLa-00078c-QS; Mon, 12 Nov 2007 01:00:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrSLa-0003xy-Cf; Mon, 12 Nov 2007 01:00:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F2C7A175B3; Mon, 12 Nov 2007 06:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IrSL3-0006kG-Jb; Mon, 12 Nov 2007 01:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Nov 2007 01:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-architecture-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet Mail Author(s) : E. Burger, G. Parsons Filename : draft-ietf-lemonade-architecture-00.txt Pages : 24 Date : 2007-11-12 This document specifies the architecture for mobile email, as described by the OMA, using Internet Mail protocols. This architecture is the basis of the work of the LEMONADE WG and is a guidleine for the LEMONADE Profile.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-architecture-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-architecture-00.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-architecture-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-12005037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-12005037.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Nov 12 05:20:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWOh-00012l-BV; Mon, 12 Nov 2007 05:20:03 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrWOg-00012X-A5 for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 05:20:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWOe-00011N-RP for lemonade@ietf.org; Mon, 12 Nov 2007 05:20:01 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrWOe-0007O0-1T for lemonade@ietf.org; Mon, 12 Nov 2007 05:20:00 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 12 Nov 2007 10:19:55 +0000 X-SMTP-Protocol-Errors: PIPELINING Subject: Re: [lemonade] TLS reauth hack References: <24023.1194651216.952135@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <24023.1194862781.083519@peirce.dave.cridland.net> Date: Mon, 12 Nov 2007 10:19:41 +0000 From: Dave Cridland To: Tony Finch Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8Bit for 7bit transmission X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Nov 10 12:52:38 2007, Tony Finch wrote: > On Fri, 9 Nov 2007, Dave Cridland wrote: > = > > I finally got around to publishing = > draft-cridland-sasl-tls-sessions-00.txt > = > Can you resolve the ambiguity problem by requiring that the client = > observe > that the server does not advertise EXTERNAL for a full TLS = > negotiation but > does when the client re-uses a TLS session ID that was set up by a > connection that used channel-bound SASL? The client then knows that = > the > EXTERNAL is related to the TLS session, and therefore knows that = > it'll get > the same authzid as previously. This is probably a conversation for the SASL mailing list rather than = here - I mentioned the draft here because it has applicability here. If a na=EFve client is trying to setup two connections, say = imap://support@imap.example.net/ and imap://user@imap.example.net/, = and reuses the TLS session for both connections, it could quite = easily accidentally use EXTERNAL mistakenly on whichever IMAP = connection was second to be brought up, causing all sorts of fun and = games. Clients do tend to use EXTERNAL blindly if advertised. I suspect this will end up being PREAUTH-TLS-SESSION, and we'll end = up with a whole family of PREAUTH-*. Dave. -- = Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 07:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYMj-0001fL-6I; Mon, 12 Nov 2007 07:26:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrYMi-0001fE-LW for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:26:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYMi-0001f5-Br for lemonade@ietf.org; Mon, 12 Nov 2007 07:26:08 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrYMf-0000SA-2z for lemonade@ietf.org; Mon, 12 Nov 2007 07:26:08 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47082) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1IrYMc-0007fR-9X (Exim 4.63) (return-path ); Mon, 12 Nov 2007 12:26:02 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IrYMc-0004U2-U0 (Exim 4.67) (return-path ); Mon, 12 Nov 2007 12:26:02 +0000 Date: Mon, 12 Nov 2007 12:26:02 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] TLS reauth hack In-Reply-To: <24023.1194862781.083519@peirce.dave.cridland.net> Message-ID: References: <24023.1194651216.952135@peirce.dave.cridland.net> <24023.1194862781.083519@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-1681738283-1194869543=:8220" Content-ID: X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870869256-1681738283-1194869543=:8220 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Mon, 12 Nov 2007, Dave Cridland wrote: > > This is probably a conversation for the SASL mailing list rather than > here - I mentioned the draft here because it has applicability here. I assumed that discussions should follow up to your original message, since you didn't say otherwise. I'll leave the thread here since the sasl list lacks the context. > If a na=EFve client is trying to setup two connections, say > imap://support@imap.example.net/ and imap://user@imap.example.net/, and r= euses > the TLS session for both connections, it could quite easily accidentally = use > EXTERNAL mistakenly on whichever IMAP connection was second to be brought= up, > causing all sorts of fun and games. In that case the client would be buggy, since it got its TLS sessions mixed up. Perhaps that implies another requirement for the draft. > Clients do tend to use EXTERNAL blindly if advertised. I suspect this > will end up being PREAUTH-TLS-SESSION, and we'll end up with a whole > family of PREAUTH-*. That seems rather lame to me. Clients should know what authentication mechanism they are using even if it spans multiple layers, so I don't think it makes sense to use EXTERNAL blindly, and I don't think they need extra help from the protocol to tell them which code path they are in the middle of. Perhaps I'm failing to think of some circumstances in which this is not possible. Tony. --=20 f.a.n.finch http://dotat.at/ SHANNON: VARIABLE 3 BECOMING NORTHWEST 4 OR 5. MODERATE OR ROUGH. RAIN LATE= R. MODERATE OR GOOD. --1870869256-1681738283-1194869543=:8220 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --1870869256-1681738283-1194869543=:8220-- From lemonade-bounces@ietf.org Mon Nov 12 07:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYeH-0000HS-Bd; Mon, 12 Nov 2007 07:44:17 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrYeF-0000HB-TC for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:44:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYeF-0000Fp-JR for lemonade@ietf.org; Mon, 12 Nov 2007 07:44:15 -0500 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrYeD-0001DG-Gx for lemonade@ietf.org; Mon, 12 Nov 2007 07:44:15 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 12 Nov 2007 12:44:09 +0000 Subject: Re: [lemonade] TLS reauth hack References: <24023.1194651216.952135@peirce.dave.cridland.net> <24023.1194862781.083519@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <30641.1194871448.775240@peirce.dave.cridland.net> Date: Mon, 12 Nov 2007 12:44:08 +0000 From: Dave Cridland To: Tony Finch Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8Bit for 7bit transmission X-Spam-Score: -1.4 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Nov 12 12:26:02 2007, Tony Finch wrote: > On Mon, 12 Nov 2007, Dave Cridland wrote: > > > > This is probably a conversation for the SASL mailing list rather = > than > > here - I mentioned the draft here because it has applicability = > here. > = > I assumed that discussions should follow up to your original = > message, > since you didn't say otherwise. I'll leave the thread here since = > the sasl > list lacks the context. > = > = Yes. I've not even mentioned the draft there, yet. > > If a na=EFve client is trying to setup two connections, say > > imap://support@imap.example.net/ and = > imap://user@imap.example.net/, and reuses > > the TLS session for both connections, it could quite easily = > accidentally use > > EXTERNAL mistakenly on whichever IMAP connection was second to be = > brought up, > > causing all sorts of fun and games. > = > In that case the client would be buggy, since it got its TLS = > sessions > mixed up. Perhaps that implies another requirement for the draft. > = > = Yes, it probably does. > > Clients do tend to use EXTERNAL blindly if advertised. I suspect = > this > > will end up being PREAUTH-TLS-SESSION, and we'll end up with a = > whole > > family of PREAUTH-*. > = > That seems rather lame to me. Clients should know what = > authentication > mechanism they are using even if it spans multiple layers, so I = > don't > think it makes sense to use EXTERNAL blindly, and I don't think = > they need > extra help from the protocol to tell them which code path they are = > in the > middle of. Perhaps I'm failing to think of some circumstances in = > which > this is not possible. I certainly think that using EXTERNAL blindly is a bad idea, but = equally, it's how clients are behaving in the field, so it's quite = possibly too late to do anything about. Dave. -- = Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 07:53:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYnA-0007MY-4p; Mon, 12 Nov 2007 07:53:28 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrYn8-0007K6-Ge for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYn8-0007Ja-6z for lemonade@ietf.org; Mon, 12 Nov 2007 07:53:26 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrYn5-0001aa-FG for lemonade@ietf.org; Mon, 12 Nov 2007 07:53:26 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 844E14ACC1; Mon, 12 Nov 2007 13:53:35 +0100 (CET) Message-Id: Date: Mon, 12 Nov 2007 13:54:02 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> In-Reply-To: <473487D3.4020002@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Arnt Gulbrandsen wrote: > >>> 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. >> >> I'm perfectly happy taking that out, if that would be appropriate. I >> thought this sort of thing was supposed to be listed in security >> considerations. > > Based on various off-list discussions I got impression that several > people really disliked that. Are we talking about the same thing? I thought Peter referred to the security considerations, but now you suggest changing something else. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 07:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYr3-0000Vt-7o; Mon, 12 Nov 2007 07:57:29 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrYr1-0000UB-L1 for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:57:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYr1-0000TP-7b for lemonade@ietf.org; Mon, 12 Nov 2007 07:57:27 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYr0-0005Jf-Mu for lemonade@ietf.org; Mon, 12 Nov 2007 07:57:27 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 12:57:24 +0000 Message-ID: <47384D95.4050800@isode.com> Date: Mon, 12 Nov 2007 12:56:53 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> Arnt Gulbrandsen wrote: >> >>>> 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. >>> >>> I'm perfectly happy taking that out, if that would be appropriate. I >>> thought this sort of thing was supposed to be listed in security >>> considerations. >> >> Based on various off-list discussions I got impression that several >> people really disliked that. > > Are we talking about the same thing? As it turned out we weren't. I though Peter disliked probing for available extensions using ENABLE, but he didn't. After reading this thread it looks like Ken and myself dislike probing, but I am not sure who else dislikes it. > I thought Peter referred to the security considerations, but now you > suggest changing something else. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 08:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZ5H-00007d-OW; Mon, 12 Nov 2007 08:12:11 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrZ5G-00007N-Lx for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:12:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZ5G-00005r-BR for lemonade@ietf.org; Mon, 12 Nov 2007 08:12:10 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrZ5F-0006Hw-RU for lemonade@ietf.org; Mon, 12 Nov 2007 08:12:10 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 82C854AC2B; Mon, 12 Nov 2007 14:12:21 +0100 (CET) Message-Id: Date: Mon, 12 Nov 2007 14:12:48 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <47384D95.4050800@isode.com> In-Reply-To: <47384D95.4050800@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > As it turned out we weren't. I though Peter disliked probing for > available extensions using ENABLE, but he didn't. After reading this > thread it looks like Ken and myself dislike probing, but I am not > sure who else dislikes it. I dislike probing. My _personal_ preferences would be for an ENABLE which is usable only after login, which can be used any time, but where all the examples show it being used as part of connection startup. I'm neutral on whether ENABLE CONDSTORE should fail on a CONDSTORE-ignorant server. (I'm happy with the text there now, but it's not exactly what I would have put in if it were only up to me.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 08:18:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZAy-0003OM-DJ; Mon, 12 Nov 2007 08:18:04 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrZAw-0003OG-Q6 for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:18:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZAw-0003O8-Fv for lemonade@ietf.org; Mon, 12 Nov 2007 08:18:02 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrZAv-0006V7-Vn for lemonade@ietf.org; Mon, 12 Nov 2007 08:18:02 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 13:18:00 +0000 Message-ID: <4738526A.4030707@isode.com> Date: Mon, 12 Nov 2007 13:17:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <47384D95.4050800@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> As it turned out we weren't. I though Peter disliked probing for >> available extensions using ENABLE, but he didn't. After reading this >> thread it looks like Ken and myself dislike probing, but I am not >> sure who else dislikes it. > > I dislike probing. > > My _personal_ preferences would be for an ENABLE which is usable only > after login, which can be used any time, but where all the examples > show it being used as part of connection startup. I'm neutral on > whether ENABLE CONDSTORE should fail on a CONDSTORE-ignorant server. I prefer that the server just ignores extensions that it doesn't recognize or which can't be enabled. There are ways for the client to figure out which extensions were enabled and which were not. > (I'm happy with the text there now, but it's not exactly what I would > have put in if it were only up to me.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 08:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZDm-00067h-OS; Mon, 12 Nov 2007 08:20:58 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrZDk-000640-Vp for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:20:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZDk-00062V-2X for lemonade@ietf.org; Mon, 12 Nov 2007 08:20:56 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrZDj-0006eM-Fi for lemonade@ietf.org; Mon, 12 Nov 2007 08:20:55 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 13:20:54 +0000 Message-ID: <47385317.501@isode.com> Date: Mon, 12 Nov 2007 13:20:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG , IMAP Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [lemonade] Request to discuss draft-ietf-imapext-i18n at the Lemonade WG meeting in Vancouver X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi everybody, The IMAPEXT WG is not going to meet in Vancouver. Lemonade Profile Bis currently depends on draft-ietf-imapext-i18n (via LISTEXT and METADATA). Any objections to quickly discussing open issue with draft-ietf-imapext-i18n at the Lemonade WG meeting in Vancouver? Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 08:37:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZUF-0005qr-AW; Mon, 12 Nov 2007 08:37:59 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrZUE-0005pg-9t for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:37:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZUD-0005p4-VN for lemonade@ietf.org; Mon, 12 Nov 2007 08:37:58 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrZUD-0007Ox-8o for lemonade@ietf.org; Mon, 12 Nov 2007 08:37:57 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 13:37:55 +0000 Message-ID: <47385714.6030506@isode.com> Date: Mon, 12 Nov 2007 13:37:24 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> <1441926969.141961194713882140.JavaMail.root@dogfood.zimbra.com> <01MNK37NMXWY00BDC1@mauve.mrochek.com> In-Reply-To: <01MNK37NMXWY00BDC1@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ned Freed wrote: >>>>That's about as simple as you can make it if some servers won't >>>>return a full capability list until after authentication. >>>> >>>Well, let's see. In your approach the client authenticates, sends a >>>capability command, checks the result to make sure the stuff that's >>>required is there, and then constructs a enable command depending >>>on that response. >>> >>>In my approach the client authenticates and then sends the enable >>>command followed by a capability command to see the results of the >>>enable. >>> Ned, while I agree that your proposal is simpler (when I saw your message I was about to reply to Dan saying that he moved complexity from the server end to the client end), I have to agree with Dan that what you propose is not what existing mail clients do. >>Yeah, but that's not how IMAP or CONDSTORE work. >> > >We get to define how IMAP and CONDSTORE work. > We can redefine how IMAP works with new extensions, but I don't think we can change CONDSTORE now, as it is an RFC for more than a year now. (But we still can change QRESYNC, if needed) >>If a server supports a capability, it must come back in a >>post-authentication CAPABILITY response. >> I agree with Dan. Note that this actually doesn't contradict what you've suggested. >I quite simply disagree. This may be how things have been done in the past but >it isn't necessarily how things need to work in the future. > Yes, we can change how this works, but I frankly don't think that the client should ask for the list of available capabilities yet again after issuing the ENABLE command. Many years ago, when I was still an IMAP client developer, I thought that the CAPABILITY response is immutable for the duration of an IMAP connection (e.g. before and after AUTHENTICATE/LOGIN). This doesn't seem to be the case in real world now. Many servers advertise different capabilities upon connection (in the CAPABILITY response code) and after authentication. However this is not explicitly defined in RFC 3501. It only says that the list of capabilities can change after STARTTLS or AUTHENTICATE/LOGIN. RFC 3501 is silent if the list of capabilities can change at any other moment. The document is also silent on whether CAPABILITY responses/response codes are additive or not (i.e. if * "CAPABILITY FOO" followed by "* CAPABILITY BAR" is the same as "* CAPABILITY FOO BAR"). I think these things should be clarified for the sake of existing and future client developers. >>Not every client will support ENABLE. When you have extensions like CONDSTORE >>that can be enabled either explicitly via ENABLE or implicitly via certain >>command arguments, a non-ENABLE-savvy client will have no idea that it can use >>CONDSTORE. >> >> > >Nothing prevents us from requiring ENABLE in order to use extensions that >change command response syntax. In fact I think such a requirement would be a >very good idea. > I agree with this statement. But I think this is an orthogonal issue to whether something needs to be advertised in the CAPABILITY response or not. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 08:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZb4-0005U7-UC; Mon, 12 Nov 2007 08:45:02 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrZb2-0005P8-Rh for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:45:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZb2-0005On-Ca for lemonade@ietf.org; Mon, 12 Nov 2007 08:45:00 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrZb1-0007kJ-Ns for lemonade@ietf.org; Mon, 12 Nov 2007 08:45:00 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 13:44:58 +0000 Message-ID: <473858BA.7030609@isode.com> Date: Mon, 12 Nov 2007 13:44:26 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] List of open issues with 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I will try to summarize the list of open issues so far (some of them are related): 1). In which states the ENABLE command should be allowed: all, only after authentication, ... 2). Handling of ENABLE for unrecognized extensions: send error or ignore 3). Handling of ENABLE for extensions that should not be enablable (e.g. IDLE): send error or ignore 4). How the client can learn if a particular extension was enabled or not? Does it need to know? 5). Does ENABLE affect CAPABILITY response/response code? Does this look like a full list of issues? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 08:47:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZdl-0008FX-Nn; Mon, 12 Nov 2007 08:47:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IrZdb-00088d-CU for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:47:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZda-00087V-85 for lemonade@ietf.org; Mon, 12 Nov 2007 08:47:38 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrZdW-00043F-Sr for lemonade@ietf.org; Mon, 12 Nov 2007 08:47:38 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 13:47:32 +0000 Message-ID: <47385952.9020009@isode.com> Date: Mon, 12 Nov 2007 13:46:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG References: <473858BA.7030609@isode.com> In-Reply-To: <473858BA.7030609@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [lemonade] Re: List of open issues with 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov wrote: > I will try to summarize the list of open issues so far (some of them > are related): And I would state my preferences: > 1). In which states the ENABLE command should be allowed: all, only > after authentication, ... All states. > 2). Handling of ENABLE for unrecognized extensions: send error or ignore Ignore. > 3). Handling of ENABLE for extensions that should not be enablable > (e.g. IDLE): send error or ignore Ignore. > 4). How the client can learn if a particular extension was enabled or > not? Does it need to know? Clients should only rely on CAPABILITY responses/response codes. > 5). Does ENABLE affect CAPABILITY response/response code? It shouldn't affect the CAPABILITY command issued in the same state, but it might change after authentication. > Does this look like a full list of issues? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 12:29:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ird60-0006HF-Ge; Mon, 12 Nov 2007 12:29:12 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ird5z-0006Gp-NN for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 12:29:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ird5z-0006Gd-DX for lemonade@ietf.org; Mon, 12 Nov 2007 12:29:11 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ird5v-0005I2-MO for lemonade@ietf.org; Mon, 12 Nov 2007 12:29:11 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lACHT6gK031184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2007 09:29:06 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lACHT5fF004184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Nov 2007 09:29:06 -0800 Date: Mon, 12 Nov 2007 09:29:04 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-Reply-To: <47385714.6030506@isode.com> Message-ID: References: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> <1441926969.141961194713882140.JavaMail.root@dogfood.zimbra.com> <01MNK37NMXWY00BDC1@mauve.mrochek.com> <47385714.6030506@isode.com> User-Agent: Alpine 0.99999 (OSX 810 2007-11-10) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.12.91042 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 12 Nov 2007, Alexey Melnikov wrote: > Many years ago, when I was still an IMAP client developer, I thought that the > CAPABILITY response is immutable for the duration of an IMAP connection (e.g. > before and after AUTHENTICATE/LOGIN). This doesn't seem to be the case in > real world now. Nor was it ever the case. > Many servers advertise different capabilities upon connection > (in the CAPABILITY response code) and after authentication. Yes. > However this is not explicitly defined in RFC 3501. It only says that the > list of capabilities can change after STARTTLS or AUTHENTICATE/LOGIN. RFC > 3501 is silent if the list of capabilities can change at any other moment. I certainly hope not. If it does, someone badly misdesigned something. > The document is also silent on whether CAPABILITY responses/response codes > are additive or not (i.e. if * "CAPABILITY FOO" followed by "* CAPABILITY > BAR" is the same as "* CAPABILITY FOO BAR"). I think these things should be > clarified for the sake of existing and future client developers. I hope that this question never comes up in real life; but I don't think that capabilities should be additive. -- 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. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 12 14:35:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irf44-0004ag-KI; Mon, 12 Nov 2007 14:35:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Irf42-0004XK-UB for lemonade-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 14:35:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irf41-0004Vx-ML for lemonade@ietf.org; Mon, 12 Nov 2007 14:35:18 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irf3y-0001b0-2D for lemonade@ietf.org; Mon, 12 Nov 2007 14:35:17 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 19:35:12 +0000 Message-ID: <4738AABA.5080401@isode.com> Date: Mon, 12 Nov 2007 19:34:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <1679890550.110521194650065847.JavaMail.root@dogfood.zimbra.com> <260231135.117501194665728404.JavaMail.root@dogfood.zimbra.com> <01MNJYDCJNVE00BDC1@mauve.mrochek.com> In-Reply-To: <01MNJYDCJNVE00BDC1@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ned Freed wrote: >>>>Why not just have ENABLE fail unless all the requested capabilities >>>>are implemented and enable-able? This would generally require waiting >>>>until after authentication to call ENABLE, but I'm not even sure why >>>>it's ever useful in the NOT AUTHENTICATED state... >>>> >>>> >>>Because clients can have have both features they require and features >>>they can use if available. If things work this way a client would have >>>to issue one ENABLE for the required stuff and then a separate ENABLE >>>for each optional thing they can use. >>> >>Why? Authenticate, issue CAPABILITY (or get an unsolicited one from the >>authentication step), check to see if it includes all the required >>capabilities, and issue a single ENABLE containing all the capabilities >>(required and desired) that you want to enable. >> >One problem is that this presumes that enable will always succeed for anything >that was previousliy listed as a capability. This strikes me as risky - there >could be things where the server cannot tell there's a problem enabling it >until it actually goes through the steps of doing so. > > Can you think of an example when enabling would fail for any reason other than the feature not being supported? >I strongly prefer a model where it is possible to check to see what's turned >on and what is not. > Agreed. (The CAPABILITY response code works for that). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 13 09:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx3Z-00050Y-Tl; Tue, 13 Nov 2007 09:48:01 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Irx3Y-00050N-Tn for lemonade-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 09:48:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx3Y-00050B-J1 for lemonade@ietf.org; Tue, 13 Nov 2007 09:48:00 -0500 Received: from mail.freax.org ([86.39.154.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irx3X-0006Zu-Ho for lemonade@ietf.org; Tue, 13 Nov 2007 09:48:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 83A1715D2DD for ; Tue, 13 Nov 2007 15:41:46 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiv3cIRXkVbR for ; Tue, 13 Nov 2007 15:41:46 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 5595A15D2B7 for ; Tue, 13 Nov 2007 15:41:46 +0100 (CET) From: Philip Van Hoof To: lemonade mailing list Content-Type: text/plain Date: Tue, 13 Nov 2007 15:48:16 +0100 Message-Id: <1194965296.7501.28.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi there, I don't know whether or not I'm the first to try, but I tried to implement 'using NOTIFY' in my client (Tinymail, Modest, TMut). I had some difficulties and, given that there are few servers supporting it and I couldn't find any to use, some questions too. This probably means that the proposal can use some more clarification here and there. Or maybe some more examples. * The unsolicited LIST response must be accompanied by a STATUS. Else I have a new folder but I don't know about its counts. For example: if the user of another E-mail client that is connected to the same account copies a folder A to B, I'd get a LIST response, but not guaranteed a STATUS? I think the standard should guarantee both to take place in order (first the LIST, then the STATUS). * STATUS's unsolicited response does not mention the UNSEEN parameter. Neither (however) would that be a useful one as some E-mail clients see "unread" as the amount of items that never got read AND that never got marked as deleted (while perhaps still being unread). The problem here is that a lot of spam softwares mark spam as deleted too. Some people "hide" deleted E-mails too (they want to remove unread items, which is not uncommon in these days of spam spam and spam). They don't want those hidden (marked as deleted) items to be counted as unread. STATUS's UNSEEN doesn't take that into account. With ESEARCH it's possible to merge the \Deleted and \Seen correctly to a meaningful number. NOTIFY doesn't seem to support that calculation, putting us back at where we are with STATUS (for NOTIFY): at a non useful number. This limits NOTIFY, other than the folder created/deleted/renamed events, to the exact same functionality than what IDLE already offers (most mobile E-mail clients don't show the total count of the folders, for screen space reasons): only the unread count of the currently selected folder can be known in real time. Putting us back at IDLE :) * Is it possible for a folder to be created with a bunch of childs instantly? And will I get unsolicited LIST responses in order about that? I haven't found something in the proposal that talks about the order of LIST responses. For the client developer, it's important that this happens in order (or a lot more complex to handle, if not). * Unsolicited VANISHED vs. EXPUNGE: clarify exactly and very clearly "when what" is going to be used. For the client it's highly important that the IMAP server doesn't use both (the index number of the EXPUNGE response would be wrong if the client already handled a VANISHED for the removal, causing loss of data for the user). * Unsolicited multi-line responses are not easy for my situation to handle. At least not if they don't start with a " * ". Although this is a problem of my software (not of the standard itself). This makes it difficult to deal with nicer MessageNew responses (I fear I'll have to limit what the server will offer me to just the UID, and use my current IDLE code: to stop the IDLE mode, get the information that I need and then restart IDLE mode, rather than letting the server instantly give me all the info that I'll need). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 13 11:04:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryFc-0004Et-Bv; Tue, 13 Nov 2007 11:04:32 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IryFa-0004EP-VU for lemonade-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 11:04:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryFa-0004Dv-KG for lemonade@ietf.org; Tue, 13 Nov 2007 11:04:30 -0500 Received: from mail.freax.org ([86.39.154.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IryFa-0002p3-7U for lemonade@ietf.org; Tue, 13 Nov 2007 11:04:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 3338215D2E9 for ; Tue, 13 Nov 2007 16:58:21 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJvEsOnuNDJV for ; Tue, 13 Nov 2007 16:58:21 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 05E4515D2E8 for ; Tue, 13 Nov 2007 16:58:20 +0100 (CET) Subject: Re: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client From: Philip Van Hoof To: lemonade mailing list In-Reply-To: <1194965296.7501.28.camel@schtrumpf> References: <1194965296.7501.28.camel@schtrumpf> Content-Type: text/plain Date: Tue, 13 Nov 2007 17:04:51 +0100 Message-Id: <1194969891.7501.37.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 2007-11-13 at 15:48 +0100, Philip Van Hoof wrote: > Hi there, > > I don't know whether or not I'm the first to try, but I tried to > implement 'using NOTIFY' in my client (Tinymail, Modest, TMut). I had > some difficulties and, given that there are few servers supporting it > and I couldn't find any to use, some questions too. ... Another question: What is the difference between a deleted mailbox, and a created mailbox's unsolicited STATUS response? From the examples: Example of a newly created mailbox: S: * LIST () "/" "NewMailbox" And a deleted mailbox: S: * LIST (\NoSelect) "/" "INBOX.DeletedMailbox" So ... the "\NoSelect" flag? Can't a not-removed folder have that flag too? The description doesn't seem to talk about this \NoSelect flag either (just the example shows this as difference). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 13 11:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryj0-0004VD-Qu; Tue, 13 Nov 2007 11:34:54 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iryiz-0004Ur-Er for lemonade-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 11:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryiy-0004Ui-W0 for lemonade@ietf.org; Tue, 13 Nov 2007 11:34:52 -0500 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iryiy-0002tf-4U for lemonade@ietf.org; Tue, 13 Nov 2007 11:34:52 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Tue, 13 Nov 2007 16:34:46 +0000 Subject: Re: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client References: <1194965296.7501.28.camel@schtrumpf> <1194969891.7501.37.camel@schtrumpf> In-Reply-To: <1194969891.7501.37.camel@schtrumpf> MIME-Version: 1.0 Message-Id: <31210.1194971686.365210@peirce.dave.cridland.net> Date: Tue, 13 Nov 2007 16:34:46 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Nov 13 16:04:51 2007, Philip Van Hoof wrote: > So ... the "\NoSelect" flag? Can't a not-removed folder have that > flag too? Kind of. But the distinction between a mailbox that exists, but has the \NoSelect attribute, and a mailbox that doesn't exist at all, is pretty minor for a client. Nevertheless, you're right that a "folder" - a hierarchy point which can potentially have inferior mailboxes - can indeed have an existence and this flag. > The description doesn't seem to talk about this \NoSelect flag > either (just the example shows this as difference). \NoSelect is itself defined in RFC3501. I think in this case, we possibly want to say \NonExistent instead (From LIST-EXTENDED). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 14 07:05:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGzd-0002rA-7X; Wed, 14 Nov 2007 07:05:17 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IsGzc-0002qw-4Z for lemonade-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 07:05:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGzb-0002qI-QN for lemonade@ietf.org; Wed, 14 Nov 2007 07:05:15 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsGzb-0007DH-Bx for lemonade@ietf.org; Wed, 14 Nov 2007 07:05:15 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 14 Nov 2007 12:05:13 +0000 Message-ID: <473AE478.5040106@isode.com> Date: Wed, 14 Nov 2007 12:05:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client References: <1194965296.7501.28.camel@schtrumpf> <1194969891.7501.37.camel@schtrumpf> <31210.1194971686.365210@peirce.dave.cridland.net> In-Reply-To: <31210.1194971686.365210@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Tue Nov 13 16:04:51 2007, Philip Van Hoof wrote: > >> The description doesn't seem to talk about this \NoSelect flag >> either (just the example shows this as difference). > > \NoSelect is itself defined in RFC3501. > > I think in this case, we possibly want to say \NonExistent instead > (From LIST-EXTENDED). Indeed. This is a bug in the example that Philip quoted, as the text above was talking about \Nonexistent. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 14 11:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLJ1-0006L3-1M; Wed, 14 Nov 2007 11:41:35 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IsLIz-0006Jj-2E for lemonade-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:41:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLIy-0006JZ-OI for lemonade@ietf.org; Wed, 14 Nov 2007 11:41:32 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLIv-0005qH-Gq for lemonade@ietf.org; Wed, 14 Nov 2007 11:41:32 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 7AD1A32987; Wed, 14 Nov 2007 16:40:59 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IsLIR-00044T-DO; Wed, 14 Nov 2007 11:40:59 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: alexey.melnikov@isode.com From: IETF I-D Submission Tool Message-Id: Date: Wed, 14 Nov 2007 11:40:59 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org, Alexey.Melnikov@isode.com, stephane.maes@oracle.com, dave.cridland@isode.com Subject: [lemonade] New Version Notification for draft-ietf-lemonade-profile-bis-07 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A new version of I-D, draft-ietf-lemonade-profile-bis-07.txt has been successfuly submitted by Alexey Melnikov and posted to the IETF repository. Filename: draft-ietf-lemonade-profile-bis Revision: 07 Title: The Lemonade Profile Creation_date: 2007-11-14 WG ID: lemonade Number_of_pages: 35 Abstract: This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. The IETF Secretariat. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 14 11:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLLp-0001bi-Uj; Wed, 14 Nov 2007 11:44:29 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IsLLn-0001XW-VW for lemonade-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:44:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLLn-0001Wu-LZ for lemonade@ietf.org; Wed, 14 Nov 2007 11:44:27 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLLk-0006CY-7l for lemonade@ietf.org; Wed, 14 Nov 2007 11:44:27 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 14 Nov 2007 16:44:22 +0000 Message-ID: <473B25D9.10301@isode.com> Date: Wed, 14 Nov 2007 16:44:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: lemonade@ietf.org Subject: Re: [lemonade] New Version Notification for draft-ietf-lemonade-profile-bis-07 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org IETF I-D Submission Tool wrote: >A new version of I-D, draft-ietf-lemonade-profile-bis-07.txt has been successfuly submitted by Alexey Melnikov and posted to the IETF repository. > >Filename: draft-ietf-lemonade-profile-bis >Revision: 07 >Title: The Lemonade Profile >Creation_date: 2007-11-14 >WG ID: lemonade >Number_of_pages: 35 > > I've only updated dates in this version. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 14 11:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLRF-0004KP-35; Wed, 14 Nov 2007 11:50:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IsLRD-0004IU-ID for lemonade-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:50:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLRC-0004He-Vg; Wed, 14 Nov 2007 11:50:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsLRC-0008KT-JG; Wed, 14 Nov 2007 11:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6FDF32AC6D; Wed, 14 Nov 2007 16:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsLRC-00019o-7O; Wed, 14 Nov 2007 11:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Nov 2007 11:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-07.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : The Lemonade Profile Author(s) : D. Cridland, et al. Filename : draft-ietf-lemonade-profile-bis-07.txt Pages : 35 Date : 2007-11-14 This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-profile-bis-07.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-profile-bis-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-14114057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-14114057.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Nov 14 12:53:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMR0-0007or-O4; Wed, 14 Nov 2007 12:53:54 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IsMQz-0007mg-Rv for lemonade-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 12:53:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMQz-0007lD-Fh for lemonade@ietf.org; Wed, 14 Nov 2007 12:53:53 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMQy-00078e-TA for lemonade@ietf.org; Wed, 14 Nov 2007 12:53:53 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 14 Nov 2007 17:53:51 +0000 Message-ID: <473B361D.4060002@isode.com> Date: Wed, 14 Nov 2007 17:53:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Philip Van Hoof Subject: Re: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client References: <1194965296.7501.28.camel@schtrumpf> In-Reply-To: <1194965296.7501.28.camel@schtrumpf> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lemonade mailing list X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Philip, Philip Van Hoof wrote: >Putting us back at IDLE :) > >* Is it possible for a folder to be created with a bunch of childs >instantly? And will I get unsolicited LIST responses in order about >that? I haven't found something in the proposal that talks about the >order of LIST responses. For the client developer, it's important that >this happens in order (or a lot more complex to handle, if not). > > You can't expect any particular order of unsolicited LIST responses and your client already has to handle this for the regular LIST command. When your client sees a response like this: * LIST () "/" "A/B/C" it has to also create [UI] objects for mailboxes A and A/B, if it hasn't created them already. >* Unsolicited VANISHED vs. EXPUNGE: clarify exactly and very clearly >"when what" is going to be used. For the client it's highly important >that the IMAP server doesn't use both > The server is either always sending EXPUNGE or always sending VANISHED. Mixing them is indeed not a good idea. But this is really a QRESYNC issue, if it is an issue at all. >(the index number of the EXPUNGE >response would be wrong if the client already handled a VANISHED for the >removal, causing loss of data for the user). > > As a side note: I think a client that has the full mailbox msgno-to-uid map should be able to cope anyway. The server should send correct message numbers at all times. >* Unsolicited multi-line responses are not easy for my situation to >handle. At least not if they don't start with a " * ". > I am not sure I understand what the issue is. Can you elaborate? >Although this is a problem of my software (not of the standard itself). This makes it >difficult to deal with nicer MessageNew responses (I fear I'll have to >limit what the server will offer me to just the UID, and use my current >IDLE code: to stop the IDLE mode, get the information that I need and >then restart IDLE mode, rather than letting the server instantly give me >all the info that I'll need). > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 14 18:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRP5-0003U4-1F; Wed, 14 Nov 2007 18:12:15 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IsRP3-0003SJ-QX for lemonade-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 18:12:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRP3-0003QP-E3 for lemonade@ietf.org; Wed, 14 Nov 2007 18:12:13 -0500 Received: from mail.freax.org ([86.39.154.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsRP3-0007PO-10 for lemonade@ietf.org; Wed, 14 Nov 2007 18:12:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 7EF5515D203; Thu, 15 Nov 2007 00:05:59 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLAnL+7fMHeH; Thu, 15 Nov 2007 00:05:58 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 9383115D18B; Thu, 15 Nov 2007 00:05:58 +0100 (CET) Subject: Re: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client From: Philip Van Hoof To: Alexey Melnikov In-Reply-To: <473B361D.4060002@isode.com> References: <1194965296.7501.28.camel@schtrumpf> <473B361D.4060002@isode.com> Content-Type: text/plain Date: Thu, 15 Nov 2007 00:12:35 +0100 Message-Id: <1195081955.7702.7.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade mailing list X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 2007-11-14 at 17:53 +0000, Alexey Melnikov wrote: > You can't expect any particular order of unsolicited LIST responses and > your client already has to handle this for the regular LIST command. > When your client sees a response like this: > * LIST () "/" "A/B/C" > it has to also create [UI] objects for mailboxes A and A/B, if it hasn't > created them already. Okay. That makes it quit a bit more difficult though. > >* Unsolicited VANISHED vs. EXPUNGE: clarify exactly and very clearly > >"when what" is going to be used. For the client it's highly important > >that the IMAP server doesn't use both > The server is either always sending EXPUNGE or always sending VANISHED. > Mixing them is indeed not a good idea. But this is really a QRESYNC > issue, if it is an issue at all. Indeed > >* Unsolicited multi-line responses are not easy for my situation to > >handle. At least not if they don't start with a " * ". > > > I am not sure I understand what the issue is. Can you elaborate? Well, it's a problem in how I'm handling things that happen while in IDLE mode. I should fix this in my code rather than claim it's making certain things more difficult :) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Nov 15 11:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishp0-00084d-8n; Thu, 15 Nov 2007 11:44:06 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ishox-000803-4h for lemonade-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:44:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishot-0007yn-Tz; Thu, 15 Nov 2007 11:44:02 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ishot-0005Lp-Hm; Thu, 15 Nov 2007 11:43:59 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3DFC8175D0; Thu, 15 Nov 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IshMr-0004tx-Ng; Thu, 15 Nov 2007 11:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 11:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-notify-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : The IMAP NOTIFY Extension Author(s) : C. King, et al. Filename : draft-ietf-lemonade-imap-notify-01.txt Pages : 18 Date : 2007-11-15 This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-notify-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-imap-notify-01.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-notify-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15104835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-notify-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-notify-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15104835.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sun Nov 18 01:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itdg2-0001EY-AN; Sun, 18 Nov 2007 01:30:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Itdfx-00016B-Vn for lemonade-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 01:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itdfu-0000yv-Pv; Sun, 18 Nov 2007 01:30:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itdfs-0002UG-C7; Sun, 18 Nov 2007 01:30:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 420BC328D6; Sun, 18 Nov 2007 06:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItdfO-0006uz-3u; Sun, 18 Nov 2007 01:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 01:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-notifications-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : Lemonade Notifications and Filters Author(s) : R. Gellens, et al. Filename : draft-ietf-lemonade-notifications-05.txt Pages : 18 Date : 2007-11-18 This document discusses how to provide notification and filtering mechanisms to IMAP as part the Lemonade profile. This document also discusses the use of Lemonade notifications to implement server to server notifications. Gellens [page 1] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-notifications-05.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-notifications-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18012105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notifications-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notifications-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18012105.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Nov 19 09:10:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7KC-0004Jr-29; Mon, 19 Nov 2007 09:10:08 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iu7K7-0004G3-EO for lemonade-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 09:10:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7K6-0004Fh-VW; Mon, 19 Nov 2007 09:10:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu7K6-0002QN-I9; Mon, 19 Nov 2007 09:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7558B2AC4F; Mon, 19 Nov 2007 14:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu7K6-0007K4-8A; Mon, 19 Nov 2007 09:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 09:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-imap-sieve-04.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : Support for Sieve in Internet Message Access Protocol (IMAP4) Author(s) : B. Leiba Filename : draft-ietf-lemonade-imap-sieve-04.txt Pages : 24 Date : 2007-11-19 Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).Note While this document defines extensions to IMAP and Sieve, it is the work of the Lemonade Working Group (Enhancements to Internet email to support diverse service environments), and discussion of it is on the lemonade mailing list at mailto:lemonade@ietf.org. Subscription requests can be sent to mailto:lemonade-request@ietf.org?body=subscribe (send an email message with the word "subscribe" in the body). A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/lemonade/index.html A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-imap-sieve-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19090546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-sieve-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19090546.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue Nov 20 13:35:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXwA-0006f0-RQ; Tue, 20 Nov 2007 13:35:06 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IuXw8-0006Zu-QO for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:35:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXw8-0006Zm-GP for lemonade@ietf.org; Tue, 20 Nov 2007 13:35:04 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXw1-0003p3-Vs for lemonade@ietf.org; Tue, 20 Nov 2007 13:35:04 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAKIYkSO018200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2007 10:34:46 -0800 Received: from [192.168.1.13] (vpn-10-50-16-37.qualcomm.com [10.50.16.37]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAKIYhvA024559; Tue, 20 Nov 2007 10:34:44 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <4734AEF8.4090201@isode.com> References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> <4734AEF8.4090201@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 20 Nov 2007 10:33:16 -0800 To: Alexey Melnikov , Peter Coates , Ned Freed From: Randall Gellens Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 7:03 PM +0000 11/9/07, Alexey Melnikov wrote: >> Thus the sequence should be either >> C: t1 CAPABILITY >> S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE >> S: t1 OK foo >> C: t2 ENABLE CONDSTORE X-GOOD-IDEA >> S: t2 OK foo >> C: t3 CAPABILITY >> S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE >> CONDSTORE >> S: t3 OK foo again >> > I dislike that, because you now implicitly saying that there are > magic extensions which don't work unless the client knows how to > enable them. Really, the server should have advertised the > CONDSTORE extension to begin with. I agree. The client shouldn't have to parse both the CAPABILITY response and the ENABLE response to learn if an extension has been negotiated. If we put all ENABLEable extensions in the CAPABILITY response, then the response to ENABLE can be OK even if it contains unknown extensions. At 2:42 PM -0800 11/9/07, Ned Freed wrote: > My personal preference is to have the initial capability list not list things > that can be enabled, have enable turn on whatit can and ignore the rest, and > have any enabled changes show up in subsequent capability lists. This > leverages existing protocol features and doesn't invent new syntax or > require multiple commands. Why do you prefer not having ENABLEable extensions in the initial CAPABILITY response? At 7:59 AM -0800 11/10/07, Ned Freed wrote: > One problem is that this presumes that enable will always succeed > for anything > that was previousliy listed as a capability. This strikes me as risky - there > could be things where the server cannot tell there's a problem enabling it > until it actually goes through the steps of doing so. > > I strongly prefer a model where it is possible to check to see what's turned > on and what is not. > In my approach the client authenticates and then sends the enable command > followed by a capability command to see the results of the enable. So ENABLE returns OK even if some extensions are not known or couldn't be turned on for whatever reason (temporary failure of a resource perhaps). The post-authentication post-ENABLE CAPABILITY response omits anything that failed during ENABLE. So a post-authentication pre-ENABLE CAPABILITY response may be different from a post-authentication post-ENABLE CAPABILITY response. That seems a little odd, but it may be easier on the client, since the client only has to parse the CAPABILITY response, not the ENABLE response. But it does effectively force the sequence CAPABILITY-authentication-ENABLE-CAPABILITY. At 10:25 AM -0800 11/10/07, Ned Freed wrote: > Nothing prevents us from requiring ENABLE in order to use extensions that > change command response syntax. In fact I think such a requirement would be a > very good idea. I agree, but this requires a revision to CONDSTORE that deprecates the current extension and defines a new one, doesn't it? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- No one would choose a friendless existence even if they had all other good things in the world. --Aristotle _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 20 13:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYGl-0004Yp-BX; Tue, 20 Nov 2007 13:56:23 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IuYGk-0004Yk-Sl for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYGk-0004Yc-J9 for lemonade@ietf.org; Tue, 20 Nov 2007 13:56:22 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYGg-0004as-5K for lemonade@ietf.org; Tue, 20 Nov 2007 13:56:22 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNY338117400G9Q4@mauve.mrochek.com> for lemonade@ietf.org; Tue, 20 Nov 2007 10:56:09 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNWVHAV96800GULE@mauve.mrochek.com>; Tue, 20 Nov 2007 10:56:06 -0800 (PST) Message-id: <01MNY336A8QY00GULE@mauve.mrochek.com> Date: Tue, 20 Nov 2007 10:40:42 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: "Your message dated Tue, 20 Nov 2007 10:33:16 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> <4734AEF8.4090201@isode.com> To: Randall Gellens DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1195584968; h=Date: From:Subject:MIME-version:Content-type; b=bLYLEYvnNLRepR9YiOJgYfKPX 80KMA+Z7CvwWJxNcuU5nYoqVPz1hKAxTBHIlzUw+deodHeIATCETYXfOoU1/w== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: lemonade@ietf.org, Alexey Melnikov , Peter Coates , Ned Freed , ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > At 7:03 PM +0000 11/9/07, Alexey Melnikov wrote: > >> Thus the sequence should be either > >> C: t1 CAPABILITY > >> S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > >> S: t1 OK foo > >> C: t2 ENABLE CONDSTORE X-GOOD-IDEA > >> S: t2 OK foo > >> C: t3 CAPABILITY > >> S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE > >> CONDSTORE > >> S: t3 OK foo again > >> > > I dislike that, because you now implicitly saying that there are > > magic extensions which don't work unless the client knows how to > > enable them. Really, the server should have advertised the > > CONDSTORE extension to begin with. > I agree. > The client shouldn't have to parse both the CAPABILITY response and > the ENABLE response to learn if an extension has been negotiated. If > we put all ENABLEable extensions in the CAPABILITY response, then the > response to ENABLE can be OK even if it contains unknown extensions. > At 2:42 PM -0800 11/9/07, Ned Freed wrote: > > My personal preference is to have the initial capability list not list things > > that can be enabled, have enable turn on whatit can and ignore the rest, and > > have any enabled changes show up in subsequent capability lists. This > > leverages existing protocol features and doesn't invent new syntax or > > require multiple commands. > Why do you prefer not having ENABLEable extensions in the initial > CAPABILITY response? Because it removes the ability to use the response to determine what is or is not enabled. > At 7:59 AM -0800 11/10/07, Ned Freed wrote: > > One problem is that this presumes that enable will always succeed > > for anything > > that was previousliy listed as a capability. This strikes me as risky - there > > could be things where the server cannot tell there's a problem enabling it > > until it actually goes through the steps of doing so. > > > > I strongly prefer a model where it is possible to check to see what's turned > > on and what is not. > > In my approach the client authenticates and then sends the enable command > > followed by a capability command to see the results of the enable. > So ENABLE returns OK even if some extensions are not known or > couldn't be turned on for whatever reason (temporary failure of a > resource perhaps). The post-authentication post-ENABLE CAPABILITY > response omits anything that failed during ENABLE. So a > post-authentication pre-ENABLE CAPABILITY response may be different > from a post-authentication post-ENABLE CAPABILITY response. That > seems a little odd, but it may be easier on the client, since the > client only has to parse the CAPABILITY response, not the ENABLE > response. But it does effectively force the sequence > CAPABILITY-authentication-ENABLE-CAPABILITY. Correct, but clients already have to look at capabilitiez after authentication so this adds no overhead. No matter how you slice it the client has to be able to determine what's enabled - the present situation as I understand is unacceptable since situations can arise where the client doesn't know what's on and what's off. The three options as I seee it are: (1) Have enable return this information as some sort of extended response. (2) have the client send multiple enables and use the response status to determine success or failure. (3) Piggyback this on the existing capabilities mechanism. I believe (3) is the simplest by far from a client perspective. An existing, compliant client need only add code to send a single enable command (which can even have a fixed set of arguments). The client then uses the capability response it already has to find out what extensions it can use, and more importantly what changes those extenaions have made to the syntax and semantics of server responses. If we don't do (3) I think the only viable alternative is (1). (2) looks an awful lot like telnet option negiation to me, which hasn't worked all that well. > At 10:25 AM -0800 11/10/07, Ned Freed wrote: > > Nothing prevents us from requiring ENABLE in order to use extensions that > > change command response syntax. In fact I think such a requirement would be a > > very good idea. > I agree, but this requires a revision to CONDSTORE that deprecates > the current extension and defines a new one, doesn't it? Yes, but IMO that's a good thing. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 20 14:26:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYkE-0003qJ-V1; Tue, 20 Nov 2007 14:26:50 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IuYkD-0003q9-Go for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYkD-0003q1-6v for lemonade@ietf.org; Tue, 20 Nov 2007 14:26:49 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYkA-00063U-GG for lemonade@ietf.org; Tue, 20 Nov 2007 14:26:49 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAKJQiQP025833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2007 11:26:45 -0800 Received: from [192.168.1.13] (vpn-10-50-16-37.qualcomm.com [10.50.16.37]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAKJQgO5026382; Tue, 20 Nov 2007 11:26:43 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <01MNY336A8QY00GULE@mauve.mrochek.com> References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> <4734AEF8.4090201@isode.com> <01MNY336A8QY00GULE@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 20 Nov 2007 11:22:56 -0800 To: Ned Freed From: Randall Gellens Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: lemonade@ietf.org, Alexey Melnikov , Peter Coates , Ned Freed , ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:40 AM -0800 11/20/07, Ned Freed wrote: >> Why do you prefer not having ENABLEable extensions in the initial >> CAPABILITY response? > > Because it removes the ability to use the response to determine what is or is > not enabled. I don't understand your reply. I parse it as: you prefer prohibiting any extension that can be ENABLEd from appearing in the initial (pre-authentication) CAPABILITY response because this way clients can't use the initial CAPABILITY response to determine what is or is not ENABLEd? Do you mean that you want to keep all non-TLS non-authentication extensions out of the initial CAPABILITY response to avoid revealing information to an unauthenticated client? Or do you mean that you want to prevent clients from assuming that any ENABLEable extension listed in the initial CAPABILITY response and included in the ENABLE command was successfully ENABLEd, without looking at the post-ENABLE CAPABILITY response? >> At 7:59 AM -0800 11/10/07, Ned Freed wrote: >>> One problem is that this presumes that enable will always succeed >>> for anything >>> that was previousliy listed as a capability. This strikes me as >>> risky - there >>> could be things where the server cannot tell there's a problem >>> enabling it >>> until it actually goes through the steps of doing so. >>> >>> I strongly prefer a model where it is possible to check to see >>> what's turned >>> on and what is not. > >> > In my approach the client authenticates and then sends the >> enable command >>> followed by a capability command to see the results of the enable. > >> So ENABLE returns OK even if some extensions are not known or >> couldn't be turned on for whatever reason (temporary failure of a >> resource perhaps). The post-authentication post-ENABLE CAPABILITY >> response omits anything that failed during ENABLE. So a >> post-authentication pre-ENABLE CAPABILITY response may be different >> from a post-authentication post-ENABLE CAPABILITY response. That >> seems a little odd, but it may be easier on the client, since the >> client only has to parse the CAPABILITY response, not the ENABLE >> response. But it does effectively force the sequence >> CAPABILITY-authentication-ENABLE-CAPABILITY. > > Correct, but clients already have to look at capabilitiez after > authentication > so this adds no overhead. True, but it does force any client that uses ENABLE to issue it after authenticating and before issuing the post-authentication CAPABILITY command (unless the client wants to issue a third CAPABILITY command, which seems pointless). So the required command sequence becomes: 1: CAPABILITY (only to determine if TLS and which authentication mechanisms are supported) 2: TLS (if being used) and authentication 3: ENABLE (with all desired ENABLEable extensions) 4: CAPABILITY (to see which ENABLEable extensions were turned on, and which other extensions are supported) >> At 10:25 AM -0800 11/10/07, Ned Freed wrote: >>> Nothing prevents us from requiring ENABLE in order to use extensions that >>> change command response syntax. In fact I think such a >>> requirement would be a >>> very good idea. > >> I agree, but this requires a revision to CONDSTORE that deprecates >> the current extension and defines a new one, doesn't it? > > Yes, but IMO that's a good thing. It would make things much cleaner, so long-term would be helpful. Is there support in the group for doing this? Are there deployments of CONDSTORE? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Note that although IBM 'invented' virtual memory in 1972 it had been available in a multi-processor multi-tasking environment on the Burroughs B5000 line since 1963 and the B6000 line since 1968. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 20 14:49:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZ6C-0005Ik-Nh; Tue, 20 Nov 2007 14:49:32 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IuZ6A-0005I2-JC for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:49:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZ6A-0005GB-7Y for lemonade@ietf.org; Tue, 20 Nov 2007 14:49:30 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuZ66-0006qw-WB for lemonade@ietf.org; Tue, 20 Nov 2007 14:49:30 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 50CDBDE92BB; Tue, 20 Nov 2007 11:49:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 442C31D5576; Tue, 20 Nov 2007 11:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9AFLOV2dPcV; Tue, 20 Nov 2007 11:49:19 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 45DF41D53EF; Tue, 20 Nov 2007 11:49:19 -0800 (PST) Date: Tue, 20 Nov 2007 11:49:19 -0800 (PST) From: Dan Karp To: Ned Freed Message-ID: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <01MNY336A8QY00GULE@mauve.mrochek.com> Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.205.227] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Randall Gellens , Ned Freed , lemonade@ietf.org, Peter Coates , ietf-imapext@imc.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > Why do you prefer not having ENABLEable extensions in the initial > > CAPABILITY response? > > Because it removes the ability to use the response to determine what > is or is not enabled. If that is the point of this, we should stop trying to be tricky and just add an untagged ENABLED response: A001 ENABLE X-UNKNOWN-EXTENSION QRESYNC CONDSTORE * ENABLED QRESYNC CONDSTORE A001 OK ENABLE completed I don't like changing the semantics of CAPABILITY just to avoid having a new untagged response. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 20 14:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZ96-0005h9-VA; Tue, 20 Nov 2007 14:52:32 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IuZ95-0005V0-Kv for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:52:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZ95-0005Nu-1e for lemonade@ietf.org; Tue, 20 Nov 2007 14:52:31 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuZ91-00070Z-OL for lemonade@ietf.org; Tue, 20 Nov 2007 14:52:31 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAKJqQAd019734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2007 11:52:26 -0800 X-Auth-Received: from D-128-208-197-44.dhcp4.washington.edu (D-128-208-197-44.dhcp4.washington.edu [128.208.197.44]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAKJqQA2023243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Nov 2007 11:52:26 -0800 Date: Tue, 20 Nov 2007 11:52:42 -0800 (PST) From: Mark Crispin To: Dan Karp Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-Reply-To: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> Message-ID: References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> User-Agent: Alpine 0.99999 (LN8 824 2007-11-19) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.20.113138 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_900_999 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Randall Gellens , Ned Freed , lemonade@ietf.org, Peter Coates , ietf-imapext@imc.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org +1 On Tue, 20 Nov 2007, Dan Karp wrote: >>> Why do you prefer not having ENABLEable extensions in the initial >>> CAPABILITY response? >> >> Because it removes the ability to use the response to determine what >> is or is not enabled. > > If that is the point of this, we should stop trying to be tricky and > just add an untagged ENABLED response: > > A001 ENABLE X-UNKNOWN-EXTENSION QRESYNC CONDSTORE > * ENABLED QRESYNC CONDSTORE > A001 OK ENABLE completed > > I don't like changing the semantics of CAPABILITY just to avoid having > a new untagged response. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade > -- 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. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 20 18:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IucDO-0001EP-8r; Tue, 20 Nov 2007 18:09:10 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IucDN-0001EK-OU for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 18:09:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IucDN-0001EB-Cj for lemonade@ietf.org; Tue, 20 Nov 2007 18:09:09 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IucDM-0000Og-IH for lemonade@ietf.org; Tue, 20 Nov 2007 18:09:09 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNYBWNRZAO00GAM4@mauve.mrochek.com> for lemonade@ietf.org; Tue, 20 Nov 2007 15:08:57 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNWVHAV96800GULE@mauve.mrochek.com>; Tue, 20 Nov 2007 15:05:44 -0800 (PST) Message-id: <01MNYBSP7BY600GULE@mauve.mrochek.com> Date: Tue, 20 Nov 2007 14:52:28 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: "Your message dated Tue, 20 Nov 2007 11:22:56 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> <4734AEF8.4090201@isode.com> <01MNY336A8QY00GULE@mauve.mrochek.com> To: Randall Gellens DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1195600136; h=Date: From:Subject:MIME-version:Content-type; b=GB+NE+nauuRz523i4tB4Yuda+ h7XXLD4nSgx9lZ5oqlXzTUZ7rlFbYUGtiOU8WBmT8XV0GBXKuBp05u+hxtEqA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: lemonade@ietf.org, Alexey Melnikov , Peter Coates , Ned Freed , ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > At 10:40 AM -0800 11/20/07, Ned Freed wrote: > >> Why do you prefer not having ENABLEable extensions in the initial > >> CAPABILITY response? > > > > Because it removes the ability to use the response to determine what is or is > > not enabled. > I don't understand your reply. I parse it as: you prefer prohibiting > any extension that can be ENABLEd from appearing in the initial > (pre-authentication) CAPABILITY response because this way clients > can't use the initial CAPABILITY response to determine what is or is > not ENABLEd? It's extremely simple: If the availabity of an extension is sufficient for it to appear in the CAPABILITY response then that response cannot be used as an indication of whether or not the extension is enabled. I suppose you could change the response in some way, but I have to wonder why a client would care about the existance of an extension that it didn't bother trying to enable. > Do you mean that you want to keep all non-TLS non-authentication > extensions out of the initial CAPABILITY response to avoid revealing > information to an unauthenticated client? No, the pre-authentication response is completely irrelevant. > Or do you mean that you want to prevent clients from assuming that > any ENABLEable extension listed in the initial CAPABILITY response > and included in the ENABLE command was successfully ENABLEd, without > looking at the post-ENABLE CAPABILITY response? Again, the initial capability response isn't relevant to any of this. The only thing I can think of that would make it relevant is to misdesign enable so that it's all or nothing. In that case you'd need to look at that response to find out what you could put in your enable command. But in that case you still shouldn't be paying attention to the pre-authentication response. Rather, you'd need to CAPA-TLS-CAPA-AUTH-CAPA-ENABLE sequence. Blech. > >> At 7:59 AM -0800 11/10/07, Ned Freed wrote: > >>> One problem is that this presumes that enable will always succeed > >>> for anything > >>> that was previousliy listed as a capability. This strikes me as > >>> risky - there > >>> could be things where the server cannot tell there's a problem > >>> enabling it > >>> until it actually goes through the steps of doing so. > >>> > >>> I strongly prefer a model where it is possible to check to see > >>> what's turned > >>> on and what is not. > > > >> > In my approach the client authenticates and then sends the > >> enable command > >>> followed by a capability command to see the results of the enable. > > > >> So ENABLE returns OK even if some extensions are not known or > >> couldn't be turned on for whatever reason (temporary failure of a > >> resource perhaps). The post-authentication post-ENABLE CAPABILITY > >> response omits anything that failed during ENABLE. So a > >> post-authentication pre-ENABLE CAPABILITY response may be different > >> from a post-authentication post-ENABLE CAPABILITY response. That > >> seems a little odd, but it may be easier on the client, since the > >> client only has to parse the CAPABILITY response, not the ENABLE > >> response. But it does effectively force the sequence > >> CAPABILITY-authentication-ENABLE-CAPABILITY. > > > > Correct, but clients already have to look at capabilitiez after > > authentication > > so this adds no overhead. > True, but it does force any client that uses ENABLE to issue it after > authenticating and before issuing the post-authentication CAPABILITY > command (unless the client wants to issue a third CAPABILITY command, > which seems pointless). Correct, but IMO this is a very good thing. Limiting the places where enable can be used results in a tremendous reduction in the number of places where a state transition can occur. (Unfortunately it doesn't reduce the number of actual protocol states, but nothing short of a redesign of the way responses are structured so they can be extended at any time can accomplish that.) > So the required command sequence becomes: > 1: CAPABILITY (only to determine if TLS and which authentication > mechanisms are supported) > 2: TLS (if being used) and authentication > 3: ENABLE (with all desired ENABLEable extensions) > 4: CAPABILITY (to see which ENABLEable extensions were turned > on, and which other extensions are supported) Yep, that's it. > >> At 10:25 AM -0800 11/10/07, Ned Freed wrote: > >>> Nothing prevents us from requiring ENABLE in order to use extensions that > >>> change command response syntax. In fact I think such a > >>> requirement would be a > >>> very good idea. > > > >> I agree, but this requires a revision to CONDSTORE that deprecates > >> the current extension and defines a new one, doesn't it? > > > > Yes, but IMO that's a good thing. > It would make things much cleaner, so long-term would be helpful. Is > there support in the group for doing this? Are there deployments of > CONDSTORE? That's the real question. If there's significant deployment we pretty much have no choice but to do this by adding additional response inforation to enable, which adds client complexity. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 20 19:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iud96-0006Oj-SV; Tue, 20 Nov 2007 19:08:48 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iud96-0006Od-5p for lemonade-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:08:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iud95-0006OU-Q2 for lemonade@ietf.org; Tue, 20 Nov 2007 19:08:47 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iud95-0003Cs-4u for lemonade@ietf.org; Tue, 20 Nov 2007 19:08:47 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAL08j6C028959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2007 16:08:46 -0800 Received: from [192.168.1.13] (vpn-10-50-16-37.qualcomm.com [10.50.16.37]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAL08hls019611; Tue, 20 Nov 2007 16:08:43 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <01MNYBSP7BY600GULE@mauve.mrochek.com> References: <472B04FD.9020100@andrew.cmu.edu> <473487D3.4020002@isode.com> <01a601c822f5$7c13bf60$743b3e20$%coates@sun.com> <4734AEF8.4090201@isode.com> <01MNY336A8QY00GULE@mauve.mrochek.com> <01MNYBSP7BY600GULE@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 20 Nov 2007 16:05:48 -0800 To: Ned Freed From: Randall Gellens Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: lemonade@ietf.org, Alexey Melnikov , Peter Coates , Ned Freed , ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:52 PM -0800 11/20/07, Ned Freed wrote: >> At 10:40 AM -0800 11/20/07, Ned Freed wrote: > >> >> Why do you prefer not having ENABLEable extensions in the initial >>>> CAPABILITY response? >>> >>> Because it removes the ability to use the response to determine >>> what is or is >>> not enabled. > >> I don't understand your reply. I parse it as: you prefer prohibiting >> any extension that can be ENABLEd from appearing in the initial >> (pre-authentication) CAPABILITY response because this way clients >> can't use the initial CAPABILITY response to determine what is or is >> not ENABLEd? > > It's extremely simple: If the availabity of an extension is sufficient for it > to appear in the CAPABILITY response then that response cannot be used as an > indication of whether or not the extension is enabled. > > I suppose you could change the response in some way, but I have to > wonder why a > client would care about the existance of an extension that it didn't bother > trying to enable. Thanks, I see the source of my confusion now: the term "initial CAPABILITY response". I took it to mean the pre-authentication CAPABILITY response, but I see now you only talking about post-authentication. >> True, but it does force any client that uses ENABLE to issue it after >> authenticating and before issuing the post-authentication CAPABILITY >> command (unless the client wants to issue a third CAPABILITY command, >> which seems pointless). > > Correct, but IMO this is a very good thing. Limiting the places where enable > can be used results in a tremendous reduction in the number of places where a > state transition can occur. (Unfortunately it doesn't reduce the number of > actual protocol states, but nothing short of a redesign of the way responses > are structured so they can be extended at any time can accomplish that.) > >> So the required command sequence becomes: > >> 1: CAPABILITY (only to determine if TLS and which authentication >> mechanisms are supported) >> 2: TLS (if being used) and authentication >> 3: ENABLE (with all desired ENABLEable extensions) >> 4: CAPABILITY (to see which ENABLEable extensions were turned >> on, and which other extensions are supported) > > Yep, that's it. This makes sense. If an extension that is normally ENABLE-able is sent by the client in ENABLE, but for some reason fails, the server omits it from the CAPABILITY response in step 4. This is reasonable because in reality it isn't actually available just at the moment for whatever reason, even though the server does support it. This might change the next time the client connects, but that's always the case. This is different from how I am used to thinking of the CAPABILITY response, but is simpler for the client, I think. >> >> At 10:25 AM -0800 11/10/07, Ned Freed wrote: >>>>> Nothing prevents us from requiring ENABLE in order to use >>>>> extensions that >>>>> change command response syntax. In fact I think such a >>>>> requirement would be a >>>>> very good idea. >>> >>>> I agree, but this requires a revision to CONDSTORE that deprecates >>>> the current extension and defines a new one, doesn't it? >>> >>> Yes, but IMO that's a good thing. > >> It would make things much cleaner, so long-term would be helpful. Is >> there support in the group for doing this? Are there deployments of >> CONDSTORE? > > That's the real question. If there's significant deployment we pretty much > have no choice but to do this by adding additional response inforation to > enable, which adds client complexity. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You think it's a conspiracy by the networks to put bad shows on TV. But the shows are bad because that's what people want. It's not like Windows users don't have any power. I think they are happy with Windows, and that's an incredibly depressing thought. --Steve Jobs _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 21 04:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulVF-0004Ly-HU; Wed, 21 Nov 2007 04:04:13 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IulVD-0004Lc-TB for lemonade-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulV8-0004Kr-6Z for lemonade@ietf.org; Wed, 21 Nov 2007 04:04:06 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IulV4-0005Yx-Hz for lemonade@ietf.org; Wed, 21 Nov 2007 04:04:05 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 886734ACC2; Wed, 21 Nov 2007 10:04:06 +0100 (CET) Message-Id: <7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com> Date: Wed, 21 Nov 2007 10:03:55 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Randall Gellens , Alexey Melnikov , Peter Coates , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp writes: > If that is the point of this, we should stop trying to be tricky and > just add an untagged ENABLED response: Absolutely. Not sure I agree with the need for ENABLED, but it certainly is THE straightforward and sensible solution to the perceived problem. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 21 06:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iunlk-0000J4-0v; Wed, 21 Nov 2007 06:29:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iunlj-0000Iy-6c for lemonade-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 06:29:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iunli-0000Ik-RH for lemonade@ietf.org; Wed, 21 Nov 2007 06:29:22 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iunli-0004yh-D8 for lemonade@ietf.org; Wed, 21 Nov 2007 06:29:22 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Nov 2007 11:29:20 +0000 Message-ID: <4744168D.10304@isode.com> Date: Wed, 21 Nov 2007 11:29:17 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> <7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com> In-Reply-To: <7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org, ietf-imapext@imc.org, Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Dan Karp writes: > >> If that is the point of this, we should stop trying to be tricky and >> just add an untagged ENABLED response: > > Absolutely. > > Not sure I agree with the need for ENABLED, but it certainly is THE > straightforward and sensible solution to the perceived problem. Agreed. But can somebody please give me a useful use case of why a client would need to know if something is enabled or not. The client still needs to cope with a server that doesn't support an extension. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 21 06:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iunzg-0006PG-1U; Wed, 21 Nov 2007 06:43:48 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iunzd-0006PB-MX for lemonade-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 06:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iunzd-0006P3-BB for lemonade@ietf.org; Wed, 21 Nov 2007 06:43:45 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IunzU-0001ml-F6 for lemonade@ietf.org; Wed, 21 Nov 2007 06:43:45 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 996D84ACDE; Wed, 21 Nov 2007 12:43:34 +0100 (CET) Message-Id: Date: Wed, 21 Nov 2007 12:43:22 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> <7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com> <4744168D.10304@isode.com> In-Reply-To: <4744168D.10304@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Alexey Melnikov , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > But can somebody please give me a useful use case of why a client > would need to know if something is enabled or not. The client still > needs to cope with a server that doesn't support an extension. I believe there won't be any such useful case with regular clients. There could be three other kinds of cases: 1. A test suite client., which wants to test at the start that it has the same idea of state as the server. 2. A client which can tell the user about the server it's using in a little dialog box: Server host: Protocol: IMAP Server name: Using TLS: Logged in as: Extensions used: That last list would be the ones the server offers and client uses that aren't ENABLE fodder, plus the ones from ENABLED. 3. Really badly written extensions. For example, if Peter makes a complete mess of his FAT NIL proposal, a client might need to know. IMO, 1 is a weak reason (we do this in a nonstandard way and that's perfect for testing), 2 is even weaker and 3 is laughable. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 21 12:08:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iut3T-0002lW-5W; Wed, 21 Nov 2007 12:08:03 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iut3R-0002W9-V9 for lemonade-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:08:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iut3R-0002L1-16 for lemonade@ietf.org; Wed, 21 Nov 2007 12:08:01 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iut3P-0003v8-EK for lemonade@ietf.org; Wed, 21 Nov 2007 12:08:01 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNZDLDL63400C5KY@mauve.mrochek.com> for lemonade@ietf.org; Wed, 21 Nov 2007 09:07:55 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNWVHAV96800GULE@mauve.mrochek.com>; Wed, 21 Nov 2007 09:07:11 -0800 (PST) Message-id: <01MNZDKI4K8200GULE@mauve.mrochek.com> Date: Wed, 21 Nov 2007 08:50:58 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 In-reply-to: "Your message dated Wed, 21 Nov 2007 12:43:22 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com> <7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com> <4744168D.10304@isode.com> To: Arnt Gulbrandsen DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1195664874; h=Date: From:Subject:MIME-version:Content-type; b=PUDBhq7P5Qgy5NjOn6lA2nVqz O6fLB6XOEKiei/Nzcl4YfRQkwaUFpPjTENUxHCYk9+dqdyP0tl5G3JCXWO1xg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: lemonade@ietf.org, ietf-imapext@imc.org, Ned Freed , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Alexey Melnikov writes: > > But can somebody please give me a useful use case of why a client > > would need to know if something is enabled or not. The client still > > needs to cope with a server that doesn't support an extension. > I believe there won't be any such useful case with regular clients. Not true. The obvious one is any extension which, once enabled, changes response syntax in some way and for which an attempt to enable it can fail due to some local condition on the server. So suppose a client tries to enable the extension. The enable succeeds or fails but the client cannot tell from the response which one it was. Now what? Does the client have to try some command that should have an altered response in order to see if the enable worked? And do this for each of several extensions? This is terrible protocol design, nothing more and nothing less. Even worse, the likely behavior of client writers will be to simply assume that all enable actions succeed. Then when an enable doesn't work the client and server get desynchronized. > There could be three other kinds of cases: > 1. A test suite client., which wants to test at the start that it has > the same idea of state as the server. This is getting close to another important case: Various sorts of proxies and stateful firewalls. I'm not particularly fond of these sorts of things, but my dislike doesn't change the fact that they are commonly used. And any time you have a protocol that has lots of possible state changes that can occur at various different times and for which it is even slightly difficult to determine current state, you are pretty much guaranteed to have problems. > 2. A client which can tell the user about the server it's using in a > little dialog box: > Server host: > Protocol: IMAP > Server name: > Using TLS: > Logged in as: > Extensions used: > That last list would be the ones the server offers and client uses that > aren't ENABLE fodder, plus the ones from ENABLED. > 3. Really badly written extensions. For example, if Peter makes a > complete mess of his FAT NIL proposal, a client might need to know. Mind you, the best way to solve these problems would be to devise a response format whose syntax doesn't need to change in order to return more stuff. But I don't think there's any desire to engage in such a major redesign of IMAP at this point. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Nov 22 13:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvH7V-0002bO-1D; Thu, 22 Nov 2007 13:49:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IvH7T-0002b8-OD for lemonade-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 13:49:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvH7T-0002av-1j for lemonade@ietf.org; Thu, 22 Nov 2007 13:49:47 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvH7S-0000xE-JD for lemonade@ietf.org; Thu, 22 Nov 2007 13:49:46 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Nov 2007 18:49:44 +0000 Message-ID: <4745CF17.3000405@isode.com> Date: Thu, 22 Nov 2007 18:48:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [lemonade] Proposed agenda for the Lemonade WG meeting in Vancouver X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi folks, Monday is the final day for submitting agendas, so here is my proposal. (Disclaimer: my personal opinion only): ================================== Lemonade IETF 70, Vancouver, December 2007 Agenda Document status review ( 5 mins) Results from the Second Lemonade Interop Event (10 mins) IMAP CONVERT (draft-ietf-lemonade-convert-12.txt) (15 mins) IMAP NOTIFY (draft-ietf-lemonade-imap-notify-01.txt) (20 mins) Lemonade notifications (draft-ietf-lemonade-notifications-05.txt) (20 mins) IMAP Internationalization (draft-ietf-imapext-i18n-13.txt) (20 mins) IMAP Sieve (draft-ietf-lemonade-imap-sieve-04.txt) (15 mins) Lemonade Profile Bis (draft-ietf-lemonade-profile-bis-07.txt) (15 mins) Total: 120 mins ================================== Comments? Any other topic/draft people would like to discuss? Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Nov 24 06:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtWO-0007NC-Jx; Sat, 24 Nov 2007 06:50:04 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IvtWN-0007N3-HA for lemonade-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtWN-0007Mq-6w; Sat, 24 Nov 2007 06:50:03 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtWI-0007Qv-N7; Sat, 24 Nov 2007 06:50:03 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm9547483640; Sat, 24 Nov 2007 20:02:55 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm914741b2c1; Mon, 19 Nov 2007 22:38:49 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 22:38:49 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7KE-0004K8-7q; Mon, 19 Nov 2007 09:10:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7K6-0004Fh-VW; Mon, 19 Nov 2007 09:10:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu7K6-0002QN-I9; Mon, 19 Nov 2007 09:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7558B2AC4F; Mon, 19 Nov 2007 14:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu7K6-0007K4-8A; Mon, 19 Nov 2007 09:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 09:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-imap-sieve-04.txt X-BeenThere: lemonade@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart 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 : Support for Sieve in Internet Message Access Protocol (IMAP4) Author(s) : B. Leiba Filename : draft-ietf-lemonade-imap-sieve-04.txt Pages : 24 Date : 2007-11-19 Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).Note While this document defines extensions to IMAP and Sieve, it is the work of the Lemonade Working Group (Enhancements to Internet email to support diverse service environments), and discussion of it is on the lemonade mailing list at mailto:lemonade@ietf.org. Subscription requests can be sent to mailto:lemonade-request@ietf.org?body=subscribe (send an email message with the word "subscribe" in the body). A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/lemonade/index.html A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-imap-sieve-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19090546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-sieve-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19090546.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sun Nov 25 21:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTw7-0003c3-Au; Sun, 25 Nov 2007 21:43:03 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwTw5-0003bw-FQ for lemonade-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 21:43:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTw5-0003bk-2i for lemonade@ietf.org; Sun, 25 Nov 2007 21:43:01 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwTw4-0001tg-Gv for lemonade@ietf.org; Sun, 25 Nov 2007 21:43:00 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lAQ2gu9d012658 for ; Sun, 25 Nov 2007 18:42:56 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lAQ2gtJr004517 for ; Sun, 25 Nov 2007 18:42:55 -0800 Received: from 172.24.28.192 ([172.24.28.192]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Nov 2007 02:42:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 25 Nov 2007 14:50:41 -0800 Subject: Re: [lemonade] Multiple Scripts for IMAP-Sieve From: Eric Burger To: Message-ID: Thread-Topic: [lemonade] Multiple Scripts for IMAP-Sieve Thread-Index: AcgPKoOKwe+CT3sdEdykBwAWy4mm/wgixcZ7 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.4 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org So here it is, November, and I have not heard boo on this subject. Any thoughts? Does Zoltan's client identifier draft help or is it orthogonal to this problem? On 10/15/07 7:54 AM, "Eric Burger" wrote: > While on the subject of "Don't Add Anything," we seemed to have had rough > consensus on Randy's text for supporting multiple scripts for IMAP Sieve. > However, it appears that consensus is eroding. > > Normally, the Chairs would offer to drop the text supporting per-client > sieve scripts. However, we would like to visit Zoltan's request: > > My worry here is that we might release a genie from the bottle. > I mean if Lemonade bis was released/deployed as is (with a single > script setup), we might not be able to change that in the future - > well, at least not easily and quickly because we are going to have > to provide backwards compatibility until the old services are > phase out. > Would it be possible to build in some sort of safeguard so that we > can change this later on without making it incompatible with > existing Lemonade deployment? Some sort of future-proof-ish > solution? > > We would like to hear people's observations on this ASAP, preferably before > 19 October. > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and have > received this message in error, please immediately return this by email and > then delete it. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 02:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwY0F-00062b-6p; Mon, 26 Nov 2007 02:03:35 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwY0E-00062U-4t for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 02:03:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwY0D-00062M-PM for lemonade@ietf.org; Mon, 26 Nov 2007 02:03:33 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwY06-0004kp-TX for lemonade@ietf.org; Mon, 26 Nov 2007 02:03:33 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 5EC57DE8CFC; Sun, 25 Nov 2007 23:03:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 46EC31D5576; Sun, 25 Nov 2007 23:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRqJQ+Q3O3rw; Sun, 25 Nov 2007 23:03:16 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 3A7CA1D5575; Sun, 25 Nov 2007 23:03:16 -0800 (PST) Date: Sun, 25 Nov 2007 23:03:16 -0800 (PST) From: Dan Karp To: Eric Burger Message-ID: <1420995591.206991196060596068.JavaMail.root@dogfood.zimbra.com> In-Reply-To: Subject: Re: [lemonade] Multiple Scripts for IMAP-Sieve MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.153.167] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > So here it is, November, and I have not heard boo on this subject. > > Any thoughts? Does Zoltan's client identifier draft help or is it > orthogonal to this problem? Personal opinion? No way should Sieve scripts for anything but SMTP message receipt be a mandatory part of Lemonade. And definitely no multiple script support -- "future proofing" is almost always code for "this adds significant complexity and I have no idea how it could be useful"... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 04:54:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwafD-0002HW-Jf; Mon, 26 Nov 2007 04:54:03 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwafC-0002HR-NU for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 04:54:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwafC-0002HJ-E3 for lemonade@ietf.org; Mon, 26 Nov 2007 04:54:02 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwaf3-0000sG-Nj for lemonade@ietf.org; Mon, 26 Nov 2007 04:54:02 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id AC0B54AC8F for ; Mon, 26 Nov 2007 10:53:57 +0100 (CET) Message-Id: Date: Mon, 26 Nov 2007 10:53:03 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Multiple Scripts for IMAP-Sieve References: <1420995591.206991196060596068.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1420995591.206991196060596068.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp writes: >> So here it is, November, and I have not heard boo on this subject. >> >> Any thoughts? Does Zoltan's client identifier draft help or is it >> orthogonal to this problem? > > Personal opinion? No way should Sieve scripts for anything but SMTP > message receipt be a mandatory part of Lemonade. And definitely no > multiple script support -- "future proofing" is almost always code > for "this adds significant complexity and I have no idea how it could > be useful"... +1 and a boldfaced, 80-point +1. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 05:37:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbKm-0001vq-UH; Mon, 26 Nov 2007 05:37:00 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwbKj-0001vX-3D for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 05:36:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbKi-0001vP-PE for lemonade@ietf.org; Mon, 26 Nov 2007 05:36:56 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwbKi-0004vk-9w for lemonade@ietf.org; Mon, 26 Nov 2007 05:36:56 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Nov 2007 10:36:54 +0000 Message-ID: <474AA1A1.3070004@isode.com> Date: Mon, 26 Nov 2007 10:36:17 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: lemonade@ietf.org Subject: Re: [lemonade] Multiple Scripts for IMAP-Sieve References: <1420995591.206991196060596068.JavaMail.root@dogfood.zimbra.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Dan Karp writes: > >>> So here it is, November, and I have not heard boo on this subject. >>> >>> Any thoughts? Does Zoltan's client identifier draft help or is it >>> orthogonal to this problem? >> >> Personal opinion? No way should Sieve scripts for anything but SMTP >> message receipt be a mandatory part of Lemonade. And definitely no >> multiple script support -- "future proofing" is almost always code >> for "this adds significant complexity and I have no idea how it could >> be useful"... > > +1 and a boldfaced, 80-point +1. I have to agree with this. I want IMAP Sieve work to be finished, but I don't think it should be included into Lemonade Profile Bis. I think this is something we should discuss in Vancouver. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 06:11:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbsV-0003W3-Nm; Mon, 26 Nov 2007 06:11:51 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwbsT-0003Qk-Jp for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 06:11:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbsT-0003Qc-9d for lemonade@ietf.org; Mon, 26 Nov 2007 06:11:49 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwbsS-0005kP-Qi for lemonade@ietf.org; Mon, 26 Nov 2007 06:11:49 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Nov 2007 11:11:47 +0000 Message-ID: <474AA9CC.7060309@isode.com> Date: Mon, 26 Nov 2007 11:11:08 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [lemonade] Proposal to include draft-cridland-urlfetch-binary-00.txt into Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org draft-cridland-urlfetch-binary-00.txt extends IMAP URLAUTH extension to allow requesting binary or converted version of a message/message part referenced by an URLAUTH URL. This extension was suggested during the Lemonade interim in spring 2007 and Dave finally got around to writing it. As discussed several months ago, there was a WG consensus that draft-ietf-lemonade-streaming-03.txt should be updated to reference it. In my capacity of an individual contributor: Based on some discussions during the last Lemonade interop, I would like to suggest that this document should be included into the Lemonade Profile Bis. I've reviewed the document and I believe it is ready for immediate Working Group Last Call. Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 06:12:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwbsw-0004jo-Js; Mon, 26 Nov 2007 06:12:18 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iwbsv-0004jj-Pu for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 06:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwbsv-0004jb-G1 for lemonade@ietf.org; Mon, 26 Nov 2007 06:12:17 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwbsm-0002j2-N7 for lemonade@ietf.org; Mon, 26 Nov 2007 06:12:17 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 344A14AC9A for ; Mon, 26 Nov 2007 12:12:15 +0100 (CET) Message-Id: Date: Mon, 26 Nov 2007 12:11:20 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [lemonade] Interop, a few words X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, Alexey will produce a proper report. But I want to say a few words: The interop went well. We tested what we should, found some bugs but they were few, showed that things interoperated quite nicely overall, and after finishing a few hours ahead of schedule we went to lunch and a sort of cross between an interim and a bar-bof ensued. One of the topics was notify. Separate message follows. The other topics were partly relevant to Lemonade. Peter and I will write new drafts about error reporting. Either or both may be included into Lemonade profile-ter, we'll see about that when there's concrete text. I have started on mine. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 06:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbtN-0005AS-CA; Mon, 26 Nov 2007 06:12:45 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwbtL-00058b-N5 for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 06:12:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbtL-00058T-Ct for lemonade@ietf.org; Mon, 26 Nov 2007 06:12:43 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwbtK-0005lk-Pt for lemonade@ietf.org; Mon, 26 Nov 2007 06:12:43 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E1FD64AC6C for ; Mon, 26 Nov 2007 12:12:48 +0100 (CET) Message-Id: Date: Mon, 26 Nov 2007 12:11:54 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [lemonade] NOTIFY simplification X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, since every Notify implementer was in the same room as I last week I asked: what can and should we simplify here?. 1. The mailbox* events. We decided to merge this. It seemed unlikely to us that a mailbox would want to know about some but not all of mailboxcreated, mailboxrenamed and mailboxdeleted. If you disagree, speak now or hold your peace. (And if you speak, mention some use cases.) 2. The search expression for message events. Server implementers wanted to drop it. Client implementers said "but it might be useful". Two use cases were presented: "I want to be notified of mail from my boss, but not from anyone else since push is expensive" and "I want to be notified of incoming mail, but I get a lot of mailing-list mail which I don't want to read on my mobile client". I personally find the first use case extremely weak. It's trotted out all the time, but I've never seen anyone do it (it could be done using sieve and fileinto+keep). Some people let their esteemed manager pay the phone bill and do not economise on usage, others pay it themselves and treat their boss like everyone else. The second is much better. IMO it's not strong enough to justify keeping the search program since most people who get much mailing-list mail divert it into separate mailboxes, but opinions may vary on that. Opinions? 3. The fetch program for the selected mailbox. Peter wanted it out, various other people wanted it in, myself included. As I interpreted it, we have rough consensus for keeping it in. 4. Other ideas for simplification? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 08:12:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdlI-00069u-DY; Mon, 26 Nov 2007 08:12:32 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwdlF-00068O-U0 for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 08:12:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdlF-000686-Hy for lemonade@ietf.org; Mon, 26 Nov 2007 08:12:29 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwdlD-0008L1-Ku for lemonade@ietf.org; Mon, 26 Nov 2007 08:12:29 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQDCQPP004834 for ; Mon, 26 Nov 2007 13:12:26 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 <0JS40070178B6D00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 26 Nov 2007 06:12:26 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS400BZS7COA770@mail-amer.sun.com> for lemonade@ietf.org; Mon, 26 Nov 2007 06:12:26 -0700 (MST) Date: Mon, 26 Nov 2007 05:12:08 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_0WFM1vJmCoxd6Yj2L3mrPA)" Content-language: en-ca Thread-index: AcgwLfK42JgPxM8OTjKdnFO4SlET1w== X-Spam-Score: 0.0 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Subject: [lemonade] extended error reporting X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --Boundary_(ID_0WFM1vJmCoxd6Yj2L3mrPA) Content-type: multipart/alternative; boundary="Boundary_(ID_z0ts7SOOBlkxjlF9P2itWQ)" --Boundary_(ID_z0ts7SOOBlkxjlF9P2itWQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Attached is a suggestion that I believe addresses a problem in error reporting in particular in URLFETCH, but which also applies to FETCH. Peter Coates --Boundary_(ID_z0ts7SOOBlkxjlF9P2itWQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Attached is a suggestion that I believe addresses a problem in error reporting in particular in URLFETCH, but which also applies to FETCH.

 

Peter Coates

--Boundary_(ID_z0ts7SOOBlkxjlF9P2itWQ)-- --Boundary_(ID_0WFM1vJmCoxd6Yj2L3mrPA) Content-type: text/plain; name=errext.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=errext.txt Internet Draft: ERREXT Peter Coates (Ed.) Document: draft-ERREXT-00 Sun Microsystems Intended status: ???? Expires: November 26, 2007 IMAP ERREXT extension Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract ERREXT defines extensions to IMAP allowing servers to provide error information explaining why a request is returning no data. Table of Contents Status of this Memo ....................................... 1 Copyright Notice........................................... 1 Abstract................................................... 1 Conventions used in this document.......................... 1 Table of Contents.......................................... 2 1. Introduction............................................ 2. Relation with other E-mail specifications............... 3. NEGOTIATION WITH enable AND capability.................. 4. Changes to the FETCH response........................... 5. Changes to the URLFETCH response........................ 6. Changes to the CONVERTED response....................... 7. ERROR phrases........................................... 8. Formal Syntax........................................... 9. Security Considerations................................. 10. References............................................. 10.1. Normative References............................... 10.2. Informative References............................. 11. Acknowledgments........................................ 12. Author's Addresses..................................... Version History............................................ Intellectual Property Statement............................ Disclaimer of Validity..................................... Copyright Statement ....................................... 1. Introduction and Conventions used in this document This document defines the ERREXT extension to IMAP4 [RFC3501]. ERREXT provides a machanism for a server to explain to a client why no data is being returned in various context. Currently, the server has no option but to return NIL to various requests with no opportunity to explain. This is true in the FETCH untagged response, and also in the URLFETCH untagged response. [CONVERT] has a mechanism for passing error information to the client when the server is unable or unwilling to perform a conversion. This machanism is generalised here. In general, this extension permits the server to send a structured error phrase in place of a NIL in the FETCH and URLFETCH responses The client must enable this extension. Unless the client issues the apropriate ENABLE command, the server MUST NOT advertise or use the error phrases described in this document. This extension is designed in part ot enable SMTP servers using BURL to return reasonable error messages if a URLFETCH fails, but has wider applicability than that. The syntax of the error phrase is left open to extension as needs become apparent. 1.2 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. In particular, the term "session" is used in this document as defined in Section 1.2 of [RFC3501]. Editorial comments are surrounded with <<>>. [Note to RFC Editor: please remove this sentence before publication.] 2. Relation with other IMAP specifications ERREXT depends on the ENABLE extension [ENABLE]. This is because once enabled the extension affect the server responses but not the client commands. 3. Negotiation with ENABLE and CAPABILITY The server MUST NOT advertize the ERREXT capability nor use the modified responses described in this document unless the client has explicitly enabled this feature using the ENABLE command. Clients which want to use this extension SHOULD enable this feature early in the session, preferably immediately upon establishing the session, or immediately after authenticating. Once the feature has been enabled the server SHOULD replace any NIL in FETCH and URLFETCH responses with the ERROR phrase described below. 4. Changes to FETCH response The FETCH response currently may return NIL in a number of circumstances, most of which indicate a poor choice of cmmand by the client (asking for a body part that does not exist). However NIL is also used by servers to indicate an that something is not available for other reasons. This leaves the client in a quandry, not able to indicate to the user what the issue is. The ERREXT entension allows ERROR to be used in place of NIL so the server can explain why the request failed. For instance: C: a001 FETCH 42 BODY[73] S: * 42 FETCH (BODY[73] (ERROR "No such part" NONEXISTANT)) S: a001 OK Completed C: a002 FETCH 17,18 (UID BODYSTRUCTURE) S: * 42 FETCH (UID 1132 BODYSTRUCTURE (ERROR "SYSTEM ERROR 52" TEMPFAIL 0:30)) S: * 42 FETCH (UID 1136 BODYSTRUCTURE ("TEXT" "PLAIN" ("CHARSET" "UTF-8") NIL NIL "8BIT" 3174 1 NIL NIL NIL NIL)) S: a002 OK Completed The server is under no obligation to send an error-phrase and MAY send a NIL where permitted before if it has nothing to add to the converstions. However, servers SHOULD endevor to explain why no data is returned in cases where is might not be obvious to the client. Note that any FETCH data type might result in a NIL response even those which currenly can not return NIL. This means that ENVELOPE, INTERNALDATE, BODY, and BODYSTRUCTURE MAY be followed by an error-phrase. 5. Changes to the URLFETCH response The URLFETCH response curretly returns NIL if a URL provided is invalid in any way, or if the object requested does not exist. This makes life dificult for SMTP server implementing BURL as they can not construct a helpful bounce message. As the URLFETCH command can contain multiple URLs, putting explanitory text in the tagged response is inadequate. Again, this extension allows the server to replace the NIL with a structured ERROR phrase. C: a003 URLFETCH imap:/ginny@sirroe.com/INBOX;uidvalidity=1189012121 /;uid=131;urlauth=submituser+ginny:internal:184d1f82... S: * URLFETCH "imap:/ginny@sirroe.com/INBOX;uidvalidity=1189012121 /;uid=131;urlauth=submituser+ginny:internal:184d1f82..." (ERROR "Bad uidvalidity" UIDVALIDITY 1273119973) S: a003 OK Completed 6. Changes to the CONVERTED response The CONVERTED response currently uses CONVERTERROR or TEMPFAIL to indicate an error. These MAY be replaced by ERROR and ERROR TEMPFAIL responses. The syntax of the error phrase differs from the syntax of the converterror-phrase only in that it uses ERROR instead of CONVERTERROR. C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii")) (BINARY[3] BODYPARTSTRUCTURE[3]) S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] (CONVERTERROR "Source text has non us-ascii" BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii"))) S: b002 NO All conversions failed The ERROR TEMPFAIL phrase is richer than the TEMPFAIL keyword it replaces in that it carries explanitory text and a suggested try interval. C: b003 CONVERT 17 ("image/tiff" ("pic-x" "128")) (BINARY[3] BODYPARTSTRUCTURE[3]) S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] (ERROR "Image convertions disabled beacuse of load" TEMPFAIL 0:30)) S: b002 NO All conversions failed 7. ERROR phrases The ERROR phrase has the general structure (ERROR user-readable-string errortype balanced-sub-phrase) The string immediately following the kwyword ERROR is intended to be text that might usefully be presented to a user. This is followed by a section that is intended for the client code to use. This consists of one of a defined set of errortypes followed by information pertaining to that errortype. The exact syntax for each errortype varies, but alway forms a balanced string. That is to say it may contain a number of strings and open and close parentheses, but the parentheses are always balanced. The defined errortypes are: BADPARAMETERS and MISSINGPARAMETERS as defined in [CONVERT] BADURL part - The URL is correct in syntax (or the command would have been rejeced with a BAD tagged response. This ERROR phrase tells the client which part of the URL failed semanticly. part can be one of URLTYPE - not an apropriate IMAP url URLUID - UID does not exist URLsection - section does not exist URLEXPIRE - URL has EXPIRED URLACCESs - bad or inapropriate credentials TEMPFAIL - The request can not be executed at the moment for operational reasons. The descriptive text provides some additional information and a suggested retry interval is given. For instance: (ERROR "Image convertions disabled beacuse of load" TEMPFAIL 0:30)) 8. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document. This syntax augments the grammar specified in [RFC3501] and [RFC3516]. Non-terminals not defined in this document can be found in [RFC3501], [RFC3516], [IMAPABNF]. in [CONVERT] we add: converterror-phrase =/ error-phrase in [IMAP] we add: msg-att-static =/ ENVELOPE SP error-phrase / INTERNALDATE SP error-phrase / "RFC822" [".HEADER" / ".TEXT"] SP error-phase / RFC822.SIZE SP error-phrase / "BODY" ("STRUCTURE") SP error-phase / "BODY" section ["<" number ">"] SP error-phrase in [URLAUTH] we redifine urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP [ nstring / error-phrase]) note that this encompases the existing definition of urlfetch-data error-phrase = "(" "ERROR" SP err-descript SP error-code ")" error-code = tempfail / bad-params / missing-params / bad-url / other-error ; bad-params and missing-params are defined in ; [CONVERT] ; other-error is there for future error-codes err-descript = string ; Human readable text explaining the conversion error bad-url = "BADURL" SP [ "URLTYPE" / "URLUID" / "URLSECTION" / "URLEXPIRE" / "URLACCESs" ] other-error = 1*ASTRING-CHAR SP (balanced-list *(SP balanced-list)) balanced-list = astring *(astring) / "(" balanced-list ")" 9. Security Considerations It is to be noted that returning the reason for not returning data might reveal that which orght not to be revealed. servers need to be careful what they say in these error-phrases 10. References 10.1. Normative References [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. http://www.ietf.org/rfc/rfc4234 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 [URLAUTH] Crispin, M. "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006 [IMAPURL] Melnikov, A. and C. Newman, "IMAP URL Scheme", work in progress, draft-ietf-lemonade-rfc2192bis-XX.txt [CONVERT] Melnikov, A. and P. Coates, "IMAP CONVERT extension", work in progress, draft-ietf-lemonade-convert-XX.txt 11. Acknowledgments 12. Authors' Addresses Peter Coates (Editor) Sun Microsystems 185 Falcon Drive Whitehorse, YT Y1A 6T2, Canada Email: peter.coates@Sun.COM 13. Version History Note to RFC-editor: Please delete this section before publication Release 00 Initial release Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. --Boundary_(ID_0WFM1vJmCoxd6Yj2L3mrPA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --Boundary_(ID_0WFM1vJmCoxd6Yj2L3mrPA)-- From lemonade-bounces@ietf.org Mon Nov 26 10:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfV6-0003Up-Dx; Mon, 26 Nov 2007 10:03:56 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwfV5-0003QV-6R for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:03:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfV4-0003QM-Rk for lemonade@ietf.org; Mon, 26 Nov 2007 10:03:54 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfV4-0002Xo-23 for lemonade@ietf.org; Mon, 26 Nov 2007 10:03:54 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 26 Nov 2007 15:03:34 +0000 Subject: Re: [lemonade] NOTIFY simplification References: In-Reply-To: MIME-Version: 1.0 Message-Id: <8213.1196089413.619593@peirce.dave.cridland.net> Date: Mon, 26 Nov 2007 15:03:33 +0000 From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8Bit for 7bit transmission X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'll answer all these points, since noisy consensus is better than = silence. On Mon Nov 26 11:11:54 2007, Arnt Gulbrandsen wrote: > 1. The mailbox* events. We decided to merge this. It seemed = > unlikely to us that a mailbox would want to know about some but not = > all of mailboxcreated, mailboxrenamed and mailboxdeleted. If you = > disagree, speak now or hold your peace. (And if you speak, mention = > some use cases.) > = > = I'm very much in favour of this. Any way to keep the costs down. > 2. The search expression for message events. Server implementers = > wanted to drop it. Client implementers said "but it might be = > useful". Two use cases were presented: "I want to be notified of = > mail from my boss, but not from anyone else since push is = > expensive" and "I want to be notified of incoming mail, but I get a = > lot of mailing-list mail which I don't want to read on my mobile = > client". > = > I personally find the first use case extremely weak. It's trotted = > out all the time, but I've never seen anyone do it (it could be = > done using sieve and fileinto+keep). Some people let their esteemed = > manager pay the phone bill and do not economise on usage, others = > pay it themselves and treat their boss like everyone else. > = > The second is much better. IMO it's not strong enough to justify = > keeping the search program since most people who get much = > mailing-list mail divert it into separate mailboxes, but opinions = > may vary on that. > = > Opinions? > = > = Basically, my impression was that client implementors essentially = want a degree of inbound filtering, but for the selected mailbox, = filtering the output of "the fetch program" makes more sense than = filtering "the notifications". More interesting is the related problem Philip Van Hoof outlined, = whereby we want to be able to remove spurious SELECT/synch cycles by = ensuring that NOTIFY is emitting only relevant data for non-SELECTed = mailboxes, by allowing the client to specify what counts as "unread". > 3. The fetch program for the selected mailbox. Peter wanted it out, = > various other people wanted it in, myself included. As I = > interpreted it, we have rough consensus for keeping it in. > = > = Peter wants this moved to CONTEXT. My gut feeling is that this is = wrong, but Peter's arguments are persuasive - namely, that if you're = going to the effort of maintaining an active filter, then keeping all = filtering in the same place is easier to implement. My opinion is yoyoing on this at the moment. I appreciate that my = primary argument against this is a gut feeling combined with an = =E6sthetic argument. One thing that nags at me is that the complexity shifts from managing = multiple SEARCH programs to managing multiple FETCH programs, and I'm = not sure that's a trade-off that's universally going to be a simple = thing to handle. Moreover, I suspect - possibly incorrectly - that in many cases, a = single CONTEXT for viewing will be used, so it may make no difference = at all. I think I need to implement all this to get a better understanding of = how it can be used, and how it might fit together at either end. Dave. -- = Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 10:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfyW-0003ms-VZ; Mon, 26 Nov 2007 10:34:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwfyV-0003mH-3L for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfyU-0003m6-PE for lemonade@ietf.org; Mon, 26 Nov 2007 10:34:18 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwfyO-0000dA-45 for lemonade@ietf.org; Mon, 26 Nov 2007 10:34:18 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6D1864AC80; Mon, 26 Nov 2007 16:34:18 +0100 (CET) Message-Id: Date: Mon, 26 Nov 2007 16:34:30 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] NOTIFY simplification References: <8213.1196089413.619593@peirce.dave.cridland.net> In-Reply-To: <8213.1196089413.619593@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes, answering me: >> 3. The fetch program for the selected mailbox. Peter wanted it out, >> various other people wanted it in, myself included. As I >> interpreted it, we have rough consensus for keeping it in. > > Peter wants this moved to CONTEXT. My gut feeling is that this is > wrong, but Peter's arguments are persuasive - namely, that if you're > going to the effort of maintaining an active filter, then keeping all > filtering in the same place is easier to implement. Putting it in context would double it for me, since I already run a fetch program in the session: A mailbox change triggers a fetch of some combination of uid, flags, annotations and modseq, with changedsince to select the right messages. I'd hate to have both session and search run that kind of thing. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 12:41:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhxv-00050D-Tr; Mon, 26 Nov 2007 12:41:51 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iwhxu-000506-T5 for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:41:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhxu-0004zx-Jd for lemonade@ietf.org; Mon, 26 Nov 2007 12:41:50 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwhxq-0005rl-0e for lemonade@ietf.org; Mon, 26 Nov 2007 12:41:50 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAQHfiZW017076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2007 09:41:45 -0800 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAQHfhUJ002826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Nov 2007 09:41:44 -0800 Date: Mon, 26 Nov 2007 09:41:40 -0800 From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] extended error reporting In-Reply-To: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> User-Agent: Alpine 0.99999 (WNT 825 2007-11-21) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.26.91431 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 26 Nov 2007, Peter Coates wrote: > Attached is a suggestion that I believe addresses a problem in error > reporting in particular in URLFETCH, but which also applies to FETCH. My reaction to this proposal is one of horror, even as I recognize that it is quite well-intentioned. I prefer to abolish the error cases rather than adding additional complexity to IMAP to report errors. (1) There is no excuse for a FETCH error. Ever. A client should NEVER attempt to FETCH something that does not exist. It knows, from the untagged EXISTS response, exactly what sequence numbers are valid; and it knows, from the BODYSTRUCTURE, exactly what message parts exist. An invalid sequence number is a BAD, and I should have made an invalid body part specifier a BAD as well. Similarly, a server should NEVER return an error to a FETCH of a valid sequence number and message part; notwithstanding RFC 2180 4.1.2 and 4.1.3 which are cases of poorly-designed (and IMHO non-compliant) server implementations. (2) That leaves UID FETCH and URLFETCH. The ONLY error condition that should exist for these commands is "this item no longer exists"; and thus there is one, and only one, meaning for a NIL return. Complexity is not our friend, boys and girls. IMAP is already far more complex than it needs to be, and the result is that it is nearly unimplementable. There are major servers out there, from major players in the industry, which spit in the face of the current specification due to its excessive complexity. It would be better to publish an informational RFC saying "RFC 2180 4.1.2 and 4.1.3 are bad ideas and should never be done", thus simplifying(!) IMAP, than to add more complexity to IMAP that nobody will implement. There are certainly aspects of IMAP in which better error reporting would be highly desirable. FETCH is not one of them. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 13:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiLt-0002Xn-4c; Mon, 26 Nov 2007 13:06:37 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwiLr-0002Xh-9O for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:06:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiLq-0002XX-UE for lemonade@ietf.org; Mon, 26 Nov 2007 13:06:34 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwiLq-0000rg-15 for lemonade@ietf.org; Mon, 26 Nov 2007 13:06:34 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQI6X6l015926 for ; Mon, 26 Nov 2007 18:06:33 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 <0JS400101K9DVR00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 26 Nov 2007 11:06:33 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS4007DUKYPCND0@mail-amer.sun.com>; Mon, 26 Nov 2007 11:06:27 -0700 (MST) Date: Mon, 26 Nov 2007 10:06:08 -0800 From: Peter Coates Subject: RE: [lemonade] extended error reporting In-reply-to: To: "'Mark Crispin'" Message-id: <023001c83057$0630d250$129276f0$%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: AcgwU6UTgD1n//tgTYel7bcrRKufvAAAsENg References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I beg to disagree with your assertion that the only possible interpretation of a NIL in a response to a URLFETCH is "this item no longer exists". The URL specified could have become invalid between the time it was returned from a GENURLAUTH and the time it was presented in a URLFETCH. It could have expired. The UIDVALIDITY could have changed. Access could have been denied (or never granted). The server has information that it could choose to return to the client, information that could help diagnose the problem. That URLFETCH does not have a way to return the information currently seem to me to be a problem. Peter -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] On Behalf Of Mark Crispin Sent: November 26, 2007 09:42 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] extended error reporting On Mon, 26 Nov 2007, Peter Coates wrote: > Attached is a suggestion that I believe addresses a problem in error > reporting in particular in URLFETCH, but which also applies to FETCH. My reaction to this proposal is one of horror, even as I recognize that it is quite well-intentioned. I prefer to abolish the error cases rather than adding additional complexity to IMAP to report errors. (1) There is no excuse for a FETCH error. Ever. A client should NEVER attempt to FETCH something that does not exist. It knows, from the untagged EXISTS response, exactly what sequence numbers are valid; and it knows, from the BODYSTRUCTURE, exactly what message parts exist. An invalid sequence number is a BAD, and I should have made an invalid body part specifier a BAD as well. Similarly, a server should NEVER return an error to a FETCH of a valid sequence number and message part; notwithstanding RFC 2180 4.1.2 and 4.1.3 which are cases of poorly-designed (and IMHO non-compliant) server implementations. (2) That leaves UID FETCH and URLFETCH. The ONLY error condition that should exist for these commands is "this item no longer exists"; and thus there is one, and only one, meaning for a NIL return. Complexity is not our friend, boys and girls. IMAP is already far more complex than it needs to be, and the result is that it is nearly unimplementable. There are major servers out there, from major players in the industry, which spit in the face of the current specification due to its excessive complexity. It would be better to publish an informational RFC saying "RFC 2180 4.1.2 and 4.1.3 are bad ideas and should never be done", thus simplifying(!) IMAP, than to add more complexity to IMAP that nobody will implement. There are certainly aspects of IMAP in which better error reporting would be highly desirable. FETCH is not one of them. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 13:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiSV-00045P-8I; Mon, 26 Nov 2007 13:13:27 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwiSU-00045J-MN for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:13:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiSU-00045B-CG for lemonade@ietf.org; Mon, 26 Nov 2007 13:13:26 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwiST-00013r-Vi for lemonade@ietf.org; Mon, 26 Nov 2007 13:13:26 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MO6FC9866800H0VX@mauve.mrochek.com> for lemonade@ietf.org; Mon, 26 Nov 2007 10:13:22 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MO03MUUIFK00GULE@mauve.mrochek.com>; Mon, 26 Nov 2007 10:13:17 -0800 (PST) Message-id: <01MO6FC6ONKS00GULE@mauve.mrochek.com> Date: Mon, 26 Nov 2007 10:07:43 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] extended error reporting In-reply-to: "Your message dated Mon, 26 Nov 2007 10:06:08 -0800" <023001c83057$0630d250$129276f0$%coates@sun.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> To: Peter Coates DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196100801; h=Date: From:Subject:MIME-version:Content-type; b=tND2hf/mL4T7ed5RTTgWuk9rE FeOJmOjUSP3cSv93MY2KHlnTOt5HtmAOXwDmYrPkCL/P05IDYUzCjbLw0RZzw== X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: lemonade@ietf.org, 'Mark Crispin' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I beg to disagree with your assertion that the only possible interpretation > of a NIL in a response to a URLFETCH is "this item no longer exists". The > URL specified could have become invalid between the time it was returned > from a GENURLAUTH and the time it was presented in a URLFETCH. It could > have expired. The UIDVALIDITY could have changed. Access could have been > denied (or never granted). Or the URL could have gotten corrupted in some way. Or the server could be misconfigured, e.g., no submit user defined. I ran into several of these working on our BURL implementation. Figuring out what was going on in some cases was a major, major pain. > The server has information that it could choose > to return to the client, information that could help diagnose the problem. > That URLFETCH does not have a way to return the information currently seem > to me to be a problem. A big one IMO. Although this hasn't been an issue for me, I'm also not convinced by the assertion that FETCH should never return an error. Just as one example, what about systems that move inactive message content to some type of secondary storage? Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 14:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjS5-0001Sh-VH; Mon, 26 Nov 2007 14:17:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwjS4-0001SQ-LO for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjS4-0001SI-Bw for lemonade@ietf.org; Mon, 26 Nov 2007 14:17:04 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwjS0-0000fw-0F for lemonade@ietf.org; Mon, 26 Nov 2007 14:17:04 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAQJGwlY027610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2007 11:16:59 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAQJGvZt026199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Nov 2007 11:16:58 -0800 Date: Mon, 26 Nov 2007 11:16:57 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] extended error reporting In-Reply-To: <01MO6FC6ONKS00GULE@mauve.mrochek.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.26.104311 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 26 Nov 2007, Ned Freed wrote: >> I beg to disagree with your assertion that the only possible interpretation >> of a NIL in a response to a URLFETCH is "this item no longer exists". The >> URL specified could have become invalid between the time it was returned >> from a GENURLAUTH and the time it was presented in a URLFETCH. It could >> have expired. The UIDVALIDITY could have changed. Access could have been >> denied (or never granted). > Or the URL could have gotten corrupted in some way. Or the server could be > misconfigured, e.g., no submit user defined. These sound like things that a server should NOT disclose to a client due to security considerations (as opposed to something in its server log). An attacker may find that level of detail to be quite useful. Remember the lesson of Tenex password validation! > I ran into several of these working on our BURL implementation. Figuring out > what was going on in some cases was a major, major pain. I'm sure; and I don't dispute that these conditions should be in a server's error log. I don't think that they should be disclosed to a client. >> The server has information that it could choose >> to return to the client, information that could help diagnose the problem. >> That URLFETCH does not have a way to return the information currently seem >> to me to be a problem. > A big one IMO. A mechanism exists via status codes and untagged OK/NO/BAD. It is not necessary to add a new syntax element. > Although this hasn't been an issue for me, I'm also not convinced by the > assertion that FETCH should never return an error. Just as one example, what > about systems that move inactive message content to some type of secondary > storage? Back in 1987 we thought that such a thing may be necessary while waiting for the operator to mount the CD-ROM with the archived file. It didn't happen then. I doubt very much that it ever will in this day and age of petabyte primary stores. IMAP has a perfectly mechanism -- multiple mailboxes -- to separate active from inactive content. A mixture of active and inactive content within a mailbox did not happen, and IMHO never will. -- 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. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 14:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjkD-0001xs-9E; Mon, 26 Nov 2007 14:35:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwjkC-0001xm-DU for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:35:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjkC-0001xe-3J for lemonade@ietf.org; Mon, 26 Nov 2007 14:35:48 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwjkB-00038Q-Ly for lemonade@ietf.org; Mon, 26 Nov 2007 14:35:48 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id AFAF34AC6D; Mon, 26 Nov 2007 20:35:53 +0100 (CET) Message-Id: Date: Mon, 26 Nov 2007 20:36:04 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] extended error reporting References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Mark Crispin , Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > (2) That leaves UID FETCH and URLFETCH. And URLFETCH. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 14:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk1t-0006UB-5V; Mon, 26 Nov 2007 14:54:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iwk1s-0006U6-Is for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:54:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk1r-0006Tx-0d for lemonade@ietf.org; Mon, 26 Nov 2007 14:54:04 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwk1q-0003Wv-54 for lemonade@ietf.org; Mon, 26 Nov 2007 14:54:02 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQJs1Ne009333 for ; Mon, 26 Nov 2007 19:54:01 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 <0JS400C01PK5TM00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 26 Nov 2007 12:54:00 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS4002N3PXZAN50@mail-amer.sun.com>; Mon, 26 Nov 2007 12:54:00 -0700 (MST) Date: Mon, 26 Nov 2007 11:53:41 -0800 From: Peter Coates Subject: RE: [lemonade] extended error reporting In-reply-to: To: "'Mark Crispin'" , "'Ned Freed'" Message-id: <025d01c83066$0cb62440$26226cc0$%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: AcgwYP//WvHWXek8TlqsbqvhSPq4ywAA8Apg References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org It reveals nothing that they can't find out to tell a client that a URL has expired or that they do not have access of a mailbox. I do not see that as a valid argument. What revealing such information does is reduce service calls. As for other mechanisms, I grant that an untagged NO could be sent after each URLFETCH response carrying the reason for the NIL. But if that is to be done, then that too needs specifying do different servers do not use different conventions to correlate the error with the NIL. And that reeks of a contrapted solution, rather than the rather modest suggestion I put forward in the first place. The alternative solution for URLFETCH would be to limit it to a single URL per command so the error reason can be carried in a NO response. But URLFETCH is already an RFC. Contrary to your assertion, we do see NIL responses sent in FETCH responses for transient operational reasons, and I see the demand for two tier storage, and the like increasing rather than decreasing. I grant that multiple mailboxes offer a better solution for separating active from inactive content, but that does not help the folks running the server. Peter -----Original Message----- From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of Mark Crispin Sent: November 26, 2007 11:17 To: Ned Freed Cc: Peter Coates; lemonade@ietf.org Subject: RE: [lemonade] extended error reporting On Mon, 26 Nov 2007, Ned Freed wrote: >> I beg to disagree with your assertion that the only possible interpretation >> of a NIL in a response to a URLFETCH is "this item no longer exists". The >> URL specified could have become invalid between the time it was returned >> from a GENURLAUTH and the time it was presented in a URLFETCH. It could >> have expired. The UIDVALIDITY could have changed. Access could have been >> denied (or never granted). > Or the URL could have gotten corrupted in some way. Or the server could be > misconfigured, e.g., no submit user defined. These sound like things that a server should NOT disclose to a client due to security considerations (as opposed to something in its server log). An attacker may find that level of detail to be quite useful. Remember the lesson of Tenex password validation! > I ran into several of these working on our BURL implementation. Figuring out > what was going on in some cases was a major, major pain. I'm sure; and I don't dispute that these conditions should be in a server's error log. I don't think that they should be disclosed to a client. >> The server has information that it could choose >> to return to the client, information that could help diagnose the problem. >> That URLFETCH does not have a way to return the information currently seem >> to me to be a problem. > A big one IMO. A mechanism exists via status codes and untagged OK/NO/BAD. It is not necessary to add a new syntax element. > Although this hasn't been an issue for me, I'm also not convinced by the > assertion that FETCH should never return an error. Just as one example, what > about systems that move inactive message content to some type of secondary > storage? Back in 1987 we thought that such a thing may be necessary while waiting for the operator to mount the CD-ROM with the archived file. It didn't happen then. I doubt very much that it ever will in this day and age of petabyte primary stores. IMAP has a perfectly mechanism -- multiple mailboxes -- to separate active from inactive content. A mixture of active and inactive content within a mailbox did not happen, and IMHO never will. -- 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. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 17:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmWw-0002wi-L2; Mon, 26 Nov 2007 17:34:18 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwmWu-0002qf-Sw for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmWu-0002mi-9D for lemonade@ietf.org; Mon, 26 Nov 2007 17:34:16 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwmWr-00086G-3t for lemonade@ietf.org; Mon, 26 Nov 2007 17:34:16 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAQMYBpr009122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2007 14:34:11 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAQMY9iP028637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Nov 2007 14:34:11 -0800 Date: Mon, 26 Nov 2007 14:33:49 -0800 (Pacific Standard Time) From: Mark Crispin To: Peter Coates Subject: RE: [lemonade] extended error reporting In-Reply-To: <025d01c83066$0cb62440$26226cc0$%coates@sun.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> User-Agent: Alpine 0.99999 (WNT 825 2007-11-21) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.26.140240 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_419_BADTHINGS 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: lemonade@ietf.org, 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 26 Nov 2007, Peter Coates wrote: > It reveals nothing that they can't find out to tell a client that a URL has > expired If you are talking about URLAUTH URLs, the expiration is in plaintext in the URL and the client is perfectly capable of figuring that out for itself without server messages. I'm not convinced that it is safe to say that the URLAUTH has been revoked or other details of how it is invalid. I won't be without a thorough review by the security experts. > or that they do not have access of a mailbox. What are we talking about, [UID] FETCH or URLFETCH? In the case of [UID] FETCH, the argument is silly. Access is by mailbox, not by message; and the proper time for any such error message is at SELECT time. In the case of URLFETCH, what does it mean to have a URLAUTH URL but not access? If you are talking about non-URLAUTH URLs, that should be a NO. > I do not see that as > a valid argument. What revealing such information does is reduce service > calls. Saying "it will reduce service calls" is like saying "it's for the children". Such statements are nothing more than strawmen to stifle debate ("you want there to be more service calls, you evil person you"). The only situation in which error messages to the end user are useful are when the end user can do something about the condition. Neither "URL has expired" nor "access not permitted" have any obvious remedial action for J. Random User other than placing a service call (or giving up). Once again, what is put in the server log for support personnel is another matter entirely. I don't consider it to be a valid tradeoff to reduce service calls but opening a potential security hole. Security holes are not necessarily obvious either. I call your attention, once again, to the Tenex password validation security bug. It is necessary to think these things through carefully and cautiously, and not say "it isn't going to be a problem", or "it will reduce service calls." Instead of strawmen arguments, give some concrete examples in which an error message would lead to remedial user action without the need for a service call. Then!! we can talk about a means by which this is best conveyed. I sympathize with your need to debug your code, but that's a special case that is best off done in a closed environment. That is not a typical user use case. > As for other mechanisms, I grant that an untagged NO could be sent after > each URLFETCH response carrying the reason for the NIL. But if that is to > be done, then that too needs specifying do different servers do not use > different conventions to correlate the error with the NIL. And that reeks > of a contrapted solution, rather than the rather modest suggestion I put > forward in the first place. Bah. "Yes, we could use an existing framework for this purpose, but it won't create as elegant a solution as creating an entirely new framework. Our new framework will be so obviously wonderful that everybody will implement it." Excess complexity is a disease, and the worst form of that disease is excessive complexity to create elegant solutions. > The alternative solution for URLFETCH would be to limit it to a single URL > per command so the error reason can be carried in a NO response. But > URLFETCH is already an RFC. Please offer a use case in which a multiple-URL URLFETCH does something useful with discrete error messages. I suspect that in most real use circumstances, the interesting cases are "it worked (everything was fetched)" or "it didn't work". > Contrary to your assertion, we do see NIL responses sent in FETCH responses > for transient operational reasons Only broken IMAP servers do that. If a broken implementation isn't going to be fixed, what makes anyone think that it's going to adopt this new error framework that you are proposaing? > and I see the demand for two tier > storage, and the like increasing rather than decreasing. Who? Where? > I grant that > multiple mailboxes offer a better solution for separating active from > inactive content, but that does not help the folks running the server. If this is a bug in a local server implementation, it would be better to fix that server rather than expect everything else to change to accomodate that server. IMAP is about making things work, not explaining why it can only do a half-assed job of working. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 19:00:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwns5-0001hP-JD; Mon, 26 Nov 2007 19:00:13 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iwns4-0001hH-Kc for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:00:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwns4-0001h8-8p for lemonade@ietf.org; Mon, 26 Nov 2007 19:00:12 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwns3-0000J3-AQ for lemonade@ietf.org; Mon, 26 Nov 2007 19:00:12 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MO6RG54Z4000J2ZK@mauve.mrochek.com> for lemonade@ietf.org; Mon, 26 Nov 2007 16:00:06 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MO6M9IUXWG00BDC1@mauve.mrochek.com>; Mon, 26 Nov 2007 16:00:02 -0800 (PST) Message-id: <01MO6RG3EYXU00BDC1@mauve.mrochek.com> Date: Mon, 26 Nov 2007 15:01:32 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] extended error reporting In-reply-to: "Your message dated Mon, 26 Nov 2007 14:33:49 -0800 (Pacific Standard Time)" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> To: Mark Crispin DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196121605; h=Date: From:Subject:MIME-version:Content-type; b=IjAcry72KLeMc3H42PwUqc5MR 3dlr1VmtDxCdV3Tih2X7JA13FK4CRHZUMXuawPbwYqCftqDQiRwz4ZLDlQCHg== X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: lemonade@ietf.org, Peter Coates , 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Mon, 26 Nov 2007, Peter Coates wrote: > > It reveals nothing that they can't find out to tell a client that a URL has > > expired > If you are talking about URLAUTH URLs, the expiration is in plaintext in > the URL and the client is perfectly capable of figuring that out for > itself without server messages. Not necessarily. A client may opt to slam a URL together and pass it on to URLAUTH without having any real understanding of the format. > I'm not convinced that it is safe to say that the URLAUTH has been revoked > or other details of how it is invalid. I won't be without a thorough > review by the security experts. That's just not how these things work. There are no magic security oracles we can ask such questions of. Completed proposals in the IETF get some measure of review as part of our standards process but that's about it. We're expected to work out our security issues for ourselves, performing such analysis ourselves. In fact these days the security area seems to even have given up on the notion of assigning advisors to working groups. (Not that this would benefit us in this case - advisors advise, they don't do our work for us.) Now, if you have a specific security exposure in mind or better still an analysis of why certain information would be a bad thing to reveal, that's one thing, but absent vague concerns about security are not justification for hiding useful information. > ... > > I do not see that as > > a valid argument. What revealing such information does is reduce service > > calls. > Saying "it will reduce service calls" is like saying "it's for the > children". Such statements are nothing more than strawmen to stifle > debate ("you want there to be more service calls, you evil person you"). > The only situation in which error messages to the end user are useful are > when the end user can do something about the condition. First, this isn't true. The user may not be in a position to fix some problems but a site administrator may - as long as they have the necessary information. And the most straightfoward way for them to get that information is from the user. The alternative if the information isn't presented to the user is for them to dig through server logs - which in the case of large scale systems handling millions of users can be a very challenging task indeed, assuming the error was even logged. Second, it is not the case that none of the errors can be dealt with by the user. The obvious one is that the message no longer exists. If the user knows that's what went wrong they can address it (by referring to a different message, giving up or whatever). The problem is right now when an error occurs the user has no way of knowing what the underlying problem is and whether or not they are in a position to address it. In fact the main point of having a useful error is to tell the user whether or not it is something they can address themselves. > Neither "URL has > expired" nor "access not permitted" have any obvious remedial action for > J. Random User other than placing a service call (or giving up). Once > again, what is put in the server log for support personnel is another > matter entirely. We deal with this sort of thing all the time at quite a few very large sites. We never hear that improved error messages significantly reduce frontline calls (most of which are probably of the "what's this cord with the two rectangular things and one round thing for" sort anyhow), but we hear all the time that they are hugely helpful in getting those calls resolved without having to push issues "up the chain". Our customers therefore hammer on us constantly to provide better, more consistent, and more detailed errors _without_ having to fall back to logs. (They would also very much like having those errors in the user's native language and not technical English, but that's a different discussion for a different day.) > I don't consider it to be a valid tradeoff to reduce service calls but > opening a potential security hole. Security holes are not necessarily > obvious either. I call your attention, once again, to the Tenex password > validation security bug. I'm afraid I no longer recall what this one was and google turns up nothing useful. > It is necessary to think these things through carefully and cautiously, > and not say "it isn't going to be a problem", or "it will reduce service > calls." Now this, OTOH, is a true strawman. Nobody here is saying, "let's go off half cocked and define something that spews out user passwords". Rather, several of us have identified a problem during development that we believe will persist in actual operation and we're discussing ways to address it without causing additional trouble. > Instead of strawmen arguments, give some concrete examples in which an > error message would lead to remedial user action without the need for a > service call. Then!! we can talk about a means by which this is best > conveyed. I have given several already. In conclusion, I will add that I have absolutely no religion as to how this gets addressed. I'm therefore staying out of the mechanism selection part of this. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 19:22:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoDy-0005Fu-1R; Mon, 26 Nov 2007 19:22:50 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwoDx-0005Fo-GN for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:22:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoDx-0005Fg-54 for lemonade@ietf.org; Mon, 26 Nov 2007 19:22:49 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwoDv-00012F-L9 for lemonade@ietf.org; Mon, 26 Nov 2007 19:22:49 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAR0MiY2014858 for ; Tue, 27 Nov 2007 00:22:44 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 <0JS500M01249O100@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 26 Nov 2007 17:22:44 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS5002PS2DQUV00@mail-amer.sun.com> for lemonade@ietf.org; Mon, 26 Nov 2007 17:22:39 -0700 (MST) Date: Mon, 26 Nov 2007 16:22:20 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <033901c8308b$93d81b20$bb885160$%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: AcgwZmlj/9ijqJPET06WiG7AgiHfYAAJSFBg X-Spam-Score: -1.0 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [lemonade] FW: notify and context X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I have looked into implementing the notify draft as it stands, and am impressed by the complexity implied by the little bit of syntax: message-event = ( "MessageNew" SP "(" fetch-att *(SP fetch-att) ")" SP message-match-criteria ) I am also not convinced by the usefulness of the complexity, although I have to accept the value of the service being offered to clients. I am unconvinced that the requirements are met in a useful way with this command. The intent is that a client can register its interests, and sit back being fed the information it wants as it arrives. Thus if it is only interested in messages meeting a specific set of criteria in particular mailboxes, it says so and gets headers or whatnot for just those messages. What actually happens is that the search program specified and the fetch program specified are only used if the mail box in question is selected. Otherwise, if a new message arrives, the client is told about it, end of story. The implication of this is that if a client is interested in messages from multiple folders, it will have to select those folders from time to time to see it the new mail is "interesting". With the way notify is currently drafted, this switch will cause any search and fetch programs specified in previous notify commands to come into play, which is all very nice for the client, if rather nasty to implement in the server. But all that pain in the server is not actually adequate for the client. If a message or two have arrived since the mailbox was last selected, the client needs to know whether they match the search criteria. This requires it either to fetch the necessary bits of the message and evaluate the search itself (and lemonade assumes we are dealing with devices that are a bit limited in their ability to do that) or they need to issue a search command (or a few search commands) to catch up with these messages that arrived in the mailbox before it was selected. That is to say, even with these search commands being in the notify command the client still has to issue the equivalent search command as part of its synchronizing with a newly selected mailbox. Now we already have another mechanism for specifying persistent searches (and sorts!) in the selected mailbox, and that is EASEARCH. If a persistent search were in effect as well as a notify, then all the various searches and sorts would have to be evaluated, so the client would expect both ESEARCH and FETCH responses when interesting new messages arrive in the selected mailbox. So NOTIFY (a) is not adequate to allow a stored search to "synch up" a "view" for a client as a mail box is selected, (b) overlaps somewhat in functionality with CONTEXT, and (c) is difficult to implement. It also fails the "keep separate functions separate" guidelines as it is mixing notifications of events, searching, and fetching. (other than that I like it) I propose that the search and fetch programs be removed from NOTIFY. This leaves an even bigger gap in the functionality that mobile clients want. This gan can be closed by adding an optional fetch program to the UPDATE phrase in ESEARCH, changing the definition of modifier-update from modifier-update = "UPDATE" to modifier-update = "UPDATE" [ SP "(" fetch-att *(SP fetch-att) ")"] This allows a client, when selecting a mailbox to issue the command View1 uid search (update (body.peek[header.fields (from to subject)]) all) from "myboss" modseq 11374 This allows a client to fetch the uids of any interesting messages that arrived or were changed after the last known modseq so they can be fetched if needed, and sets up the automatic search/fetch for any new messages. We even have the technology to do this in a sort, possibly even more important for mobile clients, although in that case the modseq option in the search program becomes a bit less useful. An argument that can be put against this proposal is that it muddies the search command with fetch things. That is true. But it enables us to disentangle both search and fetch from notify, and (at no real cost to the client) significantly reduces the complexity of the context that the server is expected to carry as a result of the notify command. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 19:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoKU-00068t-BF; Mon, 26 Nov 2007 19:29:34 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwoKT-00068e-3d for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:29:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoKS-00068V-QL for lemonade@ietf.org; Mon, 26 Nov 2007 19:29:32 -0500 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwoKQ-0007Wq-Pi for lemonade@ietf.org; Mon, 26 Nov 2007 19:29:32 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Tue, 27 Nov 2007 00:29:06 +0000 Subject: RE: [lemonade] extended error reporting References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <12639.1196123345.809039@peirce.dave.cridland.net> Date: Tue, 27 Nov 2007 00:29:05 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Nov 26 22:33:49 2007, Mark Crispin wrote: > On Mon, 26 Nov 2007, Peter Coates wrote: >> It reveals nothing that they can't find out to tell a client that >> a URL has >> expired > > If you are talking about URLAUTH URLs, the expiration is in > plaintext in the URL and the client is perfectly capable of > figuring that out for itself without server messages. > > I'm not convinced that it is safe to say that the URLAUTH has been > revoked or other details of how it is invalid. I won't be without > a thorough review by the security experts. In my experience, the BURL/URLAUTH situation is very weak in error reporting, and the client doesn't always know what the failure reason is. Taking this specific example, mobile devices aren't always aware of the correct time, and a client trying to generate, then use (via BURL) an IMAP URL which has a tight expiration is perfectly capable of finding a largely opaque error coming back from the submission server, purely because the clock is wrong. (And sometimes, it's wrong because the GSM network is helpfully broadcasting the wrong time). FWIW, I use a ten minute expiry in my client precisely to lessen the chances of this happening, but that's not always going to be enough - it's one of those shrugging-off implementation choices. It's also possible for another client to expunge the message prior to the URLAUTH ticket being used, and quite possibly other error cases which are not clear-cut cases of developer error, but cases of user misconfiguration or misuse. I suspect that extending URLAUTH to handle conversion would elicit several more use cases. I'm perfectly in agreement that if an apparently bogus URLAUTH URL gets passed in, that's an error I don't mind not reporting, but in some cases, the error requires specific user action to resolve - it's those errors I'd welcome better error reporting for. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 20:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwpOs-0001EW-UQ; Mon, 26 Nov 2007 20:38:10 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwpOr-0001BL-Pe for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 20:38:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwpOr-0001BD-Dl for lemonade@ietf.org; Mon, 26 Nov 2007 20:38:09 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwpOq-0007Xn-5c for lemonade@ietf.org; Mon, 26 Nov 2007 20:38:09 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAR1c647002688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2007 17:38:06 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAR1c6iA023184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Nov 2007 17:38:06 -0800 Date: Mon, 26 Nov 2007 17:37:45 -0800 (Pacific Standard Time) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] extended error reporting In-Reply-To: <01MO6RG3EYXU00BDC1@mauve.mrochek.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MO6RG3EYXU00BDC1@mauve.mrochek.com> User-Agent: Alpine 0.99999 (WNT 825 2007-11-21) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.26.171444 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 26 Nov 2007, Ned Freed wrote: >> If you are talking about URLAUTH URLs, the expiration is in plaintext in >> the URL and the client is perfectly capable of figuring that out for >> itself without server messages. > Not necessarily. A client may opt to slam a URL together and pass it on to > URLAUTH without having any real understanding of the format. A URLAUTH signed URL can't be "slammed together". Once signed with a URLAUTH, it is immutable. Whatever assemble the original URL has to know the semantics of expiration. >> I'm not convinced that it is safe to say that the URLAUTH has been revoked >> or other details of how it is invalid. I won't be without a thorough >> review by the security experts. > That's just not how these things work. There are no magic security > oracles we can ask such questions of. Completed proposals in the IETF > get some measure of review as part of our standards process but that's > about it. We're expected to work out our security issues for ourselves, > performing such analysis ourselves. In that case, then this group is remiss if it does not perform such analysis. > Now, if you have a specific security exposure in mind or better still an > analysis of why certain information would be a bad thing to reveal, > that's one thing, but absent vague concerns about security are not > justification for hiding useful information. For each of the possible error messages, what information does this give the attacker that he would not have been able to discover easily otherwise? Does it inform the attacker whether a URLAUTH signing key exists? Does it inform the attacker that the data contents exist (or do not exist) even if he does not know the correct URLAUTH? Does it, with a specially-tailored URL, give the attacker information that reduces the problem scope to determine the URLAUTH signing key? Vague claims that "this isn't a problem" are not a way to address security considerations! >> The only situation in which error messages to the end user are useful are >> when the end user can do something about the condition. > First, this isn't true. The user may not be in a position to fix some > problems but a site administrator may - as long as they have the > necessary information. And the most straightfoward way for them to get > that information is from the user. The alternative if the information > isn't presented to the user is for them to dig through server logs - > which in the case of large scale systems handling millions of users can > be a very challenging task indeed, assuming the error was even logged. So, because the server has a poor log implementation, we have to give this information to the user trusting that he will convey it accurately to the site administrator. We also have to trust that this user isn't a hacker who has been collecting all this information to break in, using some vector that he knows about but we don't (yet). I remain skeptical. > Second, it is not the case that none of the errors can be dealt with by > the user. The obvious one is that the message no longer exists. If the > user knows that's what went wrong they can address it (by referring to a > different message, giving up or whatever). The problem is right now when > an error occurs the user has no way of knowing what the underlying > problem is and whether or not they are in a position to address it. This scenario makes sense only with URLAUTH; and in that case a separate entity from the user generated the URLAUTH. > In fact the main point of having a useful error is to tell the user > whether or not it is something they can address themselves. And I contend that the use cases discussed so far are primarily for software developers debugging their implementations and NOT for end users. Most usage of URLAUTH is via automated mechanisms, and the interesting thing to the end user is if it worked or not. If it doesn't work, the end user isn't going to debug the URLAUTH. >> Neither "URL has >> expired" nor "access not permitted" have any obvious remedial action for >> J. Random User other than placing a service call (or giving up). Once >> again, what is put in the server log for support personnel is another >> matter entirely. > > We deal with this sort of thing all the time at quite a few very large > sites. We never hear that improved error messages significantly reduce > frontline calls (most of which are probably of the "what's this cord > with the two rectangular things and one round thing for" sort anyhow), > but we hear all the time that they are hugely helpful in getting those > calls resolved without having to push issues "up the chain". Our > customers therefore hammer on us constantly to provide better, more > consistent, and more detailed errors _without_ having to fall back to > logs. (They would also very much like having those errors in the user's > native language and not technical English, but that's a different > discussion for a different day.) Who are your customers on this point? The end users? Or the site administrators? If the latter, shouldn't you be addressing site administrator needs, rather than dump technical jargon on an end user? You need a way for the site administrator to know better what is going on, without sharing that information with the Russian Mafia. >> I don't consider it to be a valid tradeoff to reduce service calls but >> opening a potential security hole. Security holes are not necessarily >> obvious either. I call your attention, once again, to the Tenex password >> validation security bug. > I'm afraid I no longer recall what this one was and google turns up nothing > useful. Tenex very helpfully told you if the userid was invalid, if the password was invalid, if there was some error in an argument, etc. Passwords were validated, character-at-a-time, between the stored password and the user's argument string. Once determining a valid userid (admittedly not generally difficult in Tenex), you would then pass it a one-character password, where the next character was on a no-access page. "Invalid password" meant that character was not the first character of the password. "Page fault" meant that it was the first character of the password. Repeat with progressively longer strings until you got the entire password. The first attempt at a fix was to fetch the entire password argument from the user before validating, so page fault would always happen. But that wasn't good enough. The more difficult, but equally effective, attack is left as an exercise for the reader; but the fix was a rewrite of the password validation logic so that the validity test was a single machine instruction. >> It is necessary to think these things through carefully and cautiously, >> and not say "it isn't going to be a problem", or "it will reduce service >> calls." > Now this, OTOH, is a true strawman. Nobody here is saying, "let's go off > half cocked and define something that spews out user passwords". Rather, > several of us have identified a problem during development that we > believe will persist in actual operation and we're discussing ways to > address it without causing additional trouble. Better error reporting is a good thing; but let's have a listing of the errors that we want to report instead of adding an open-ended framework with just a handwave that "there are no problems." >> Instead of strawmen arguments, give some concrete examples in which an >> error message would lead to remedial user action without the need for a >> service call. Then!! we can talk about a means by which this is best >> conveyed. > I have given several already. You listed: . "slamming together a URLAUTH". The end user can't do this at all. . "it no longer exists". The end user has to get a new one from whomever gave him the URLAUTH. In fact, for URLAUTH, there really are only the following small set of conditions for the end user: . You won. Yay! . Foo, you are a hacker. . This URLAUTH is no longer valid. Contact whomever gave it to you to get a new one. For FETCH, there are only the following conditions: . You won. Yay! . Your buggy client gave an invalid message sequence number. . Your buggy client gave an invalid part part specifier. I tell you NIL. For URL FETCH, there are the following conditions: . You won. Yay! . This UID is no longer valid. I'm saying nothing about that message. . Your buggy client gave an invalid part part specifier. I tell you NIL. Since you claim that there are more conditions than these, are they really unique conditions? Are they brought about by the implementation, and would not exist if the implementation was any better? If it is "foo, you are a hacker", do you really want to tell the hacker how he goofed? Even if it is "no longer valid", do you necessarily want to tell the user (as opposed to the issuer) why? If you have to tell the end user anything, I would be more comfortable with a mechanism that issued an incident token, which would then allow authorized personnel to get what really happpened. > In conclusion, I will add that I have absolutely no religion as to how this > gets addressed. I'm therefore staying out of the mechanism selection part of > this. Interestingly, I have no religion on that point either. IMAP is so incredibly complex and baroque that its doom is sealed whether or not one more gargoyle is added to the tower. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Nov 26 21:23:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwq6Z-0003vg-Ji; Mon, 26 Nov 2007 21:23:19 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iwq6Y-0003r5-Ld for lemonade-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 21:23:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwq6Y-0003pq-BB for lemonade@ietf.org; Mon, 26 Nov 2007 21:23:18 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwq6U-0006vx-GM for lemonade@ietf.org; Mon, 26 Nov 2007 21:23:18 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAR2NCrQ009039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2007 18:23:12 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lAR2NB1Q028976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Nov 2007 18:23:11 -0800 Date: Mon, 26 Nov 2007 18:22:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Dave Cridland Subject: RE: [lemonade] extended error reporting In-Reply-To: <12639.1196123345.809039@peirce.dave.cridland.net> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> User-Agent: Alpine 0.99999 (WNT 825 2007-11-21) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.26.175525 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 27 Nov 2007, Dave Cridland wrote: > In my experience, the BURL/URLAUTH situation is very weak in error reporting, > and the client doesn't always know what the failure reason is. I agree. But what is the target audience for the error reports? End user? Site administrator? Software developer/debugger? I submit that this is not a "one shoe fits all" type of situation. > Taking this specific example, mobile devices aren't always aware of the > correct time, and a client trying to generate, then use (via BURL) an IMAP > URL which has a tight expiration is perfectly capable of finding a largely > opaque error coming back from the submission server, purely because the clock > is wrong. (And sometimes, it's wrong because the GSM network is helpfully > broadcasting the wrong time). That scenario suggests that the correct protocol fix is to have a relative expiration date/time for the client doing the GENURLAUTH, and have the returned URLAUTH replace that relative expiration date/time with an absolute value. For example, authimapurlrump = authimapurl [expire-relative] iurlauth-rump expire-relative = ";EXPIRESIN=" 1*DIGIT ; number of seconds That way, we don't have relative expirations in authimapurlfull; the returned authimapurlfull would have to include an absolute expiration. An alternative is to encode a relative expiration in the mechanism field. > It's also possible for another client to expunge the message prior to the > URLAUTH ticket being used, and quite possibly other error cases which are not > clear-cut cases of developer error, but cases of user misconfiguration or > misuse. Yes, but those are cases of "this URLAUTH is no longer valid, contact the entity that gave you the URLAUTH for a new one." > I'm perfectly in agreement that if an apparently bogus URLAUTH URL gets > passed in, that's an error I don't mind not reporting, but in some cases, the > error requires specific user action to resolve - it's those errors I'd > welcome better error reporting for. Yes -- but once again, for whom?!? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 05:23:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxbM-0007xG-Q3; Tue, 27 Nov 2007 05:23:36 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IwxbK-0007x6-Pa for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 05:23:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxbK-0007wv-Ep for lemonade@ietf.org; Tue, 27 Nov 2007 05:23:34 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwxbH-0007Y3-BR for lemonade@ietf.org; Tue, 27 Nov 2007 05:23:34 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 27 Nov 2007 10:23:12 +0000 Subject: RE: [lemonade] extended error reporting References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <13695.1196158990.303583@peirce.dave.cridland.net> Date: Tue, 27 Nov 2007 10:23:10 +0000 From: Dave Cridland To: Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Nov 27 02:22:50 2007, Mark Crispin wrote: > On Tue, 27 Nov 2007, Dave Cridland wrote: >> In my experience, the BURL/URLAUTH situation is very weak in error >> reporting, and the client doesn't always know what the failure >> reason is. > > I agree. But what is the target audience for the error reports? > > End user? > > Site administrator? > > Software developer/debugger? > > I submit that this is not a "one shoe fits all" type of situation. > > And I absolutely agree, but I also submit that some errors do require user intervention to correct, and therefore should be presented clearly to the user for resolution. >> Taking this specific example, mobile devices aren't always aware >> of the correct time, and a client trying to generate, then use >> (via BURL) an IMAP URL which has a tight expiration is perfectly >> capable of finding a largely opaque error coming back from the >> submission server, purely because the clock is wrong. (And >> sometimes, it's wrong because the GSM network is helpfully >> broadcasting the wrong time). > > That scenario suggests that the correct protocol fix is to have a > relative expiration date/time for the client doing the GENURLAUTH, > and have the returned URLAUTH replace that relative expiration > date/time with an absolute value. For example, Well, I'm not sure that helps, and more importantly I suspect that this would be a more radical change than Peter's proposal anyway. BURL/URLAUTH are deployed technologies [ie, not just Polymer], and the simplest way of handling this deficiency without breaking existing implementations would be to have the BURL command produce more useful diagnostics. Besides which, there are other cases, including any case which involves server-side manipulation of a body part during the URLFETCH. My proposal of BINARY-mode is one such (consider bogus base64), and any similar proposal involving CONVERT-in-URLFETCH. >> It's also possible for another client to expunge the message prior >> to the URLAUTH ticket being used, and quite possibly other error >> cases which are not clear-cut cases of developer error, but cases >> of user misconfiguration or misuse. > > Yes, but those are cases of "this URLAUTH is no longer valid, > contact the entity that gave you the URLAUTH for a new one." > > Yes, but often they're not cases where there is a security leak in explaining what the problem actually is. Bear in mind that the most common scenario for BURL/URLAUTH is the case where a client gets a URLAUTH for a message and then uses it quite rapidly in a BURL command within an authenticated SUBMIT session. The authorizing authority for the URL is the user, here, and moreover, if a hacker has got to the stage of being able to use a submit+ authorized URL, then he can almost certainly gain access to the IMAP store itself. This is not always the case, of course, and I'm certainly not advocating producing details error responses for all cases. Just those that make sense. >> I'm perfectly in agreement that if an apparently bogus URLAUTH URL >> gets passed in, that's an error I don't mind not reporting, but in >> some cases, the error requires specific user action to resolve - >> it's those errors I'd welcome better error reporting for. > > Yes -- but once again, for whom?!? Sorry, I thought this was clear - "[...] the error requires specific user action to resolve" - hence the user. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 10:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2hn-0007KV-SO; Tue, 27 Nov 2007 10:50:35 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix2hm-000735-0b for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:50:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2hl-0006si-BH for lemonade@ietf.org; Tue, 27 Nov 2007 10:50:33 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix2hk-0004P1-9d for lemonade@ietf.org; Tue, 27 Nov 2007 10:50:33 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARFoT3n004184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2007 07:50:30 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARFoSq7020435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Nov 2007 07:50:29 -0800 Date: Tue, 27 Nov 2007 07:50:28 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: RE: [lemonade] extended error reporting In-Reply-To: <13695.1196158990.303583@peirce.dave.cridland.net> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> User-Agent: Alpine 0.99999 (OSX 830 2007-11-26) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.27.72141 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 27 Nov 2007, Dave Cridland wrote: >> That scenario suggests that the correct protocol fix is to have a relative >> expiration date/time for the client doing the GENURLAUTH, and have the >> returned URLAUTH replace that relative expiration date/time with an >> absolute value. For example, > > Well, I'm not sure that helps, and more importantly I suspect that this would > be a more radical change than Peter's proposal anyway. BURL/URLAUTH are > deployed technologies [ie, not just Polymer], and the simplest way of > handling this deficiency without breaking existing implementations would be > to have the BURL command produce more useful diagnostics. Given your scenario of the GSM network broadcasting the wrong time, and hence the URLAUTH generating entity is making meaningless URLAUTHs, I don't see how an error message is going to help the end user at all. It's the fool software that set up an expiration 10 minutes into the future based upon an incorrection notion of absolute time. The user probably knows quite well that the time shown by his phone is hours off from the real time, and can't do a damn thing about it. Even if the phone permits a manual reset, the network time update will just set it back. And it's not just GSM. I've seen this with CDMA networks. So much for the myth that CDMA network time is guaranteed to be in synchronization with GPS time. [Details on request. I had someone argue with me that this was "impossible" at length on another forum before he finally understood.] It seems to me that if you really want to generate expirations based upon a relative interval, we should extend the URLAUTH mechanism to allow this. Obvious we can't break the existing implementations, hence the word "extend". > Besides which, there are other cases, including any case which involves > server-side manipulation of a body part during the URLFETCH. My proposal of > BINARY-mode is one such (consider bogus base64), and any similar proposal > involving CONVERT-in-URLFETCH. In that case, the error report should be part of the conversion mechanism framework and not the fetching framework. >>> It's also possible for another client to expunge the message prior to the >>> URLAUTH ticket being used, and quite possibly other error cases which are >>> not clear-cut cases of developer error, but cases of user misconfiguration >>> or misuse. >> Yes, but those are cases of "this URLAUTH is no longer valid, contact the >> entity that gave you the URLAUTH for a new one." > Yes, but often they're not cases where there is a security leak in explaining > what the problem actually is. But the problem is "this URLAUTH is no longer valid, contact the entity that gave you the URLAUTH for a new one." > Bear in mind that the most common scenario for > BURL/URLAUTH is the case where a client gets a URLAUTH for a message and then > uses it quite rapidly in a BURL command within an authenticated SUBMIT > session. The authorizing authority for the URL is the user, here, and > moreover, if a hacker has got to the stage of being able to use a submit+ > authorized URL, then he can almost certainly gain access to the IMAP store > itself. Let's assume that the hacker, one way or another, has got to the state of knowing a submit+ authorized URL. That doesn't help him much, since he can't use it, but he has an example of a URLAUTH generated by the correct key. URLAUTH resists known-plaintext attacks, but perhaps he can try something else. He now launches a brute force attack to see if he can create other URLAUTHs. Perhaps he uses carefully-crafted URLs that are more likely to exploit a weakness in the encryption algorithm or key. What do more detailed error messages tell him? For example: Do they make his task of ultimately finding the key any easier? Short of finding the key, do they disclose details about the mailbox (such as the number of messages, or the structure of certain messages)? > This is not always the case, of course, and I'm certainly not advocating > producing details error responses for all cases. Just those that make sense. The next thing is: a new framework for error responses is proposed, instead of using the existing frameworks. What value does this new framework gain that justifies the creation of Yet Another Framework to an already extremely overburdened protocol? The chief benefit to the new framework is in associating the message precisely with the URL that triggered it in a multi-URL request; thus the desire not to use tagged response. How is this useful to the end user? Gee, the 23rd URL in my URLFETCH message got a URL expired error message. I don't think so, especially given (by your own agreement) the most common case is "the case where a client gets a URLAUTH for a message and then uses it quite rapidly in a BURL command within an authenticated SUBMIT session." How is this useful to an application? The user's request failed. In the most common case, the application is the submit server; and it's just going to bounce the entire thing back. It's not going to do anything intelligent knowing that the 23rd URL was bad. The unresolved security question here is how much goes in the bounce, and how much goes in the log with perhaps an incident tag in the bounce. Even if you give the end user all the information, you can give it just as well in the existing framework using tagged response or a series of untagged NOs. The proposed new framework doesn't gain anything for the bounce message. Similarly, in the common case, the proposed new framework doesn't help site administrators either. The important thing for a site administrator is how the submit server puts together its bounce for the end user. The site administrator doesn't care if its where it is in some URLFETCH request. Once again, the tagged response or a series of untagged NOs is completely adequate. I submit that the main value for the new framework is software developers debugging their URLAUTH/BURL implementations, and NOT end users, applications, or site administrators. Software developer convenience is NOT a good reason for adding something that is otherwise of limited or no use. What's more, you are NOT going to get this new framework generally accepted with such a paltry value. We have major IMAP servers that don't even implement all of the base specification (and whose vendors question the need to implement all of the base specification), much less any extensions. -- 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. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 11:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3NV-00026K-Of; Tue, 27 Nov 2007 11:33:41 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix3NU-000260-7F for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:33:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3NT-00025r-U0 for lemonade@ietf.org; Tue, 27 Nov 2007 11:33:39 -0500 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3NS-0002sE-N3 for lemonade@ietf.org; Tue, 27 Nov 2007 11:33:39 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 27 Nov 2007 16:33:18 +0000 Subject: RE: [lemonade] extended error reporting References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <17749.1196181195.681762@peirce.dave.cridland.net> Date: Tue, 27 Nov 2007 16:33:15 +0000 From: Dave Cridland To: Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Nov 27 15:50:28 2007, Mark Crispin wrote: >> Besides which, there are other cases, including any case which >> involves server-side manipulation of a body part during the >> URLFETCH. My proposal of BINARY-mode is one such (consider bogus >> base64), and any similar proposal involving CONVERT-in-URLFETCH. > > In that case, the error report should be part of the conversion > mechanism framework and not the fetching framework. > > Well, indeed, but at a protocol level there is no such distinction - both may, and probably will, use URLFETCH. >> Bear in mind that the most common scenario for BURL/URLAUTH is the >> case where a client gets a URLAUTH for a message and then uses it >> quite rapidly in a BURL command within an authenticated SUBMIT >> session. The authorizing authority for the URL is the user, here, >> and moreover, if a hacker has got to the stage of being able to >> use a submit+ authorized URL, then he can almost certainly gain >> access to the IMAP store itself. > > Let's assume that the hacker, one way or another, has got to the > state of knowing a submit+ authorized URL. That doesn't help him > much, since he can't use it, but he has an example of a URLAUTH > generated by the correct key. URLAUTH resists known-plaintext > attacks, but perhaps he can try something else. > > He now launches a brute force attack to see if he can create other > URLAUTHs. Perhaps he uses carefully-crafted URLs that are more > likely to exploit a weakness in the encryption algorithm or key. > What do more detailed error messages tell him? For example: > > Do they make his task of ultimately finding the key any easier? > > Short of finding the key, do they disclose details about the > mailbox (such as the number of messages, or the structure of > certain messages)? > > Well, let's assume that the attacker has an expired URL. He can detirmine it is expired by checking the timestamp in the URL. Getting an error message telling him so is hardly a breach of security - we're allowed to tell people the time. RESETKEY or similar issues are different - here, the URL has been forcefully invalidated, and there's no need to distinguish between this and mailbox deletion. Doing so most certainly leaks information. We can, in addition, reject anything that should have been caught at GENURLAUTH time, which includes non-existent body parts. But there's a wealth of cases - including the message being expunged - for which the URL can be validated fully. In these case, you have a demonstrably valid URL that remains authorized, but which points to missing or unusable data. It can be argued that this grants your brute force attacker a greater chance of being able to identify an existent message and valid section to use in their URL, but equally, they have such an example already, so I'd dispute the strength of that argument. FWIW, it'd be perfectly reasonable to encode within the INTERNAL gunk the modseq the message was generated at, so that if you had sufficient state (and Cyrus IMAP, for example, does) you could distinguish between "The message did not exist at the time of the GENURLAUTH" - reject out of hand - and "The message no longer exists" - provide an error. > What's more, you are NOT going to get this new framework generally > accepted with such a paltry value. We have major IMAP servers that > don't even implement all of the base specification (and whose > vendors question the need to implement all of the base > specification), much less any extensions. Given that this is being proposed by implementors of BURL capable submission servers, and you're arguing that it has most value to them, I feel that you're arguing that the value is higher to the implementor than to the end user, so I think you may be self-defeating here - it seems somewhat likely that, amongst URLAUTH implementors, and especially those also working on BURL, it would have a reasonably high uptake. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 11:39:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3TE-00078E-TO; Tue, 27 Nov 2007 11:39:36 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix3TD-00077b-JP for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:39:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3TC-000775-HC for lemonade@ietf.org; Tue, 27 Nov 2007 11:39:35 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix3TB-0006rQ-Uv for lemonade@ietf.org; Tue, 27 Nov 2007 11:39:34 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 27 Nov 2007 16:39:14 +0000 Subject: RE: [lemonade] extended error reporting References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <17749.1196181553.757037@peirce.dave.cridland.net> Date: Tue, 27 Nov 2007 16:39:13 +0000 From: Dave Cridland To: Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Nov 27 15:50:28 2007, Mark Crispin wrote: > The chief benefit to the new framework is in associating the > message precisely with the URL that triggered it in a multi-URL > request; thus the desire not to use tagged response. > > How is this useful to the end user? Just to pick up on this point in particular, this allows the Submission server to associate the URLAUTH error with the BURL command which produced it, in case it happens to have batched up a series of BURL requests from different sessions while it's authenticating to the IMAP server, for example. Whilst it may, or may not, be useful to the end user to know which particular BURL command caused the failure, it's certainly handy for the submission server to know. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 13:08:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4rg-0001Ma-8n; Tue, 27 Nov 2007 13:08:56 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix4re-0001ML-Rk for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:08:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4re-0001MB-H4 for lemonade@ietf.org; Tue, 27 Nov 2007 13:08:54 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix4rd-0001GO-4Y for lemonade@ietf.org; Tue, 27 Nov 2007 13:08:54 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Nov 2007 18:08:50 +0000 Message-ID: <474C5CF1.3030702@isode.com> Date: Tue, 27 Nov 2007 18:07:45 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Based on various discussions during the Lemonade interop in Munich, I would like to propose the following changes to the Lemonade Profile Bis document: After reviewing existing server and client implementations, there was support for removing RFC 5032 (WITHIN) from the Lemonade Profile Bis. The reason for this is because server implementors found interaction between WITHIN and CONTEXT to be too complex to implement, while client implementors didn't find the extension to be useful. If somebody would like to argue that RFC 3052 should be in Lemonade Profile Bis, please speak up now. The group also discussed possible removal of the following extensions, however no agreement was reached among the group members: 1). METADATA is currently a dependency for the CONVERT extension. There is also a proposal to use METADATA for storing search criteria on the server. This is complicated extension for servers to implement. 2). LIST-EXTENDED (currently a dependency for the METADATA extension). The group fell that this extension by itself doesn't buy much Lemonade clients. However if further extensions to LIST are added to Lemonade Profile Bis (see below for an example), then it might be more valuable. As a side note, all but 1 server implementations participating in the interop have implemented LIST-EXTENDED. 3). COMPARATOR (currently a dependency of both LIST-EXTENDED and METADATA). This extension allows searching (and sorting) for pieces of email messages or annotations, using different comparators, for example language Unicode case-insensitive comparator or a language specific comparator. While there was no doubt that this is a useful extension to IMAP in general, only 1 client developer thought that this should be included into Lemonade Profile Bis. There was also some interest in adding the following 2 extensions to the Lemonade Profile Bis: 1). Peter Coates' URLAUTH extended error reporting (being discussed on the mailing list now) 2). Dave Cridland's Extended URLFETCH for binary and converted parts(draft-cridland-urlfetch-binary-00.txt) 3). There was also some interest in adding STATUS data to LIST. There is no draft describing this yet. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 13:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5NQ-0005Nl-5L; Tue, 27 Nov 2007 13:41:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix5NP-0005Nf-Eu for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:41:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5NP-0005NN-3u for lemonade@ietf.org; Tue, 27 Nov 2007 13:41:43 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix5NO-0005bd-Hd for lemonade@ietf.org; Tue, 27 Nov 2007 13:41:42 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id DFD3EDE8A06; Tue, 27 Nov 2007 10:41:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 51A481D5572; Tue, 27 Nov 2007 10:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwvQ05xumn8g; Tue, 27 Nov 2007 10:41:33 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id E528F1D5574; Tue, 27 Nov 2007 10:41:32 -0800 (PST) Date: Tue, 27 Nov 2007 10:41:32 -0800 (PST) From: Dan Karp To: Alexey Melnikov Message-ID: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1946667865.330821196188655452.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.153.167] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > 1). METADATA is currently a dependency for the CONVERT extension. > There is also a proposal to use METADATA for storing search criteria > on the server. This is complicated extension for servers to implement. Well, if there's any chance of avoiding METADATA, I'm for it. If you're seriously considering switching to a CONVERT-specific command to get the server's conversion capabilities, the cleanest I can come up with is: CONVERSIONS where and are partially or completely wildcardable. For instance, for conversion info from GIF to JPEG (no untagged CONVERT would be returned if no conversion was possible): C: a CONVERSIONS "image/gif" "image/jpeg" S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced") S: a OK CONVERSIONS completed For conversion info from GIF to anything: C: b CONVERSIONS "image/gif" * S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced") S: * CONVERT "image/gif" "image/png" (...) S: ... S: b OK CONVERSIONS completed For conversion of anything to JPEG: C: c CONVERSIONS * "image/jpeg" S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced") S: * CONVERT "image/png" "image/jpeg" (...) S: ... S: c OK CONVERSIONS completed For conversions from all image formats to all text formats (maybe via OCR?): C: d CONVERSIONS "image/*" "text/*" S: d OK CONVERSIONS completed > 3). COMPARATOR (currently a dependency of both LIST-EXTENDED and > METADATA). COMPARATOR is only a METADATA dependency, right? METADATA adds sorting to LIST-EXTENDED, but it's not a standard part of that extension. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 13:54:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5ZN-00059q-UO; Tue, 27 Nov 2007 13:54:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix5ZN-00059W-3T for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:54:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5ZM-00059N-Og for lemonade@ietf.org; Tue, 27 Nov 2007 13:54:04 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix5ZM-00079z-6t for lemonade@ietf.org; Tue, 27 Nov 2007 13:54:04 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARIs2H9002840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2007 10:54:02 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARIs0qP014227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Nov 2007 10:54:02 -0800 Date: Tue, 27 Nov 2007 10:53:35 -0800 (Pacific Standard Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis In-Reply-To: <474C5CF1.3030702@isode.com> Message-ID: References: <474C5CF1.3030702@isode.com> User-Agent: Alpine 0.99999 (WNT 825 2007-11-21) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.27.102259 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 27 Nov 2007, Alexey Melnikov wrote: > After reviewing existing server and client implementations, there was support > for removing RFC 5032 (WITHIN) from the Lemonade Profile Bis. The reason for > this is because server implementors found interaction between WITHIN and > CONTEXT to be too complex to implement, while client implementors didn't find > the extension to be useful. +1 for removal. > The group also discussed possible removal of the following extensions > [snip: METADATA, LIST-EXTENDED, COMPARATOR] +1 for removal of all of these. They can always be added back in the third revision of the profile. > There was also some interest in adding the following 2 extensions to the > Lemonade Profile Bis: > 1). Peter Coates' URLAUTH extended error reporting (being discussed on the > mailing list now) > 2). Dave Cridland's Extended URLFETCH for binary and converted > parts(draft-cridland-urlfetch-binary-00.txt) > 3). There was also some interest in adding STATUS data to LIST. There is no > draft describing this yet. Oppose all three for addition to bis. +1 on listing as "to be considered for addition in the third revision". Side note: LEMONADE is currently a very tough sell due to complexity and "nobody is asking for it." Any measures that reduce complexity and increase demand are good things IMHO. It's good news that SUN apparently takes LEMONADE seriously; but certain other big players that I talk to do not. That worries me. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 14:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5gu-00074m-Ll; Tue, 27 Nov 2007 14:01:52 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix5gt-000744-Hq for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:01:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5gt-00073r-4I for lemonade@ietf.org; Tue, 27 Nov 2007 14:01:51 -0500 Received: from outmail129159.authsmtp.net ([62.13.129.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix5gn-0005I0-4H for lemonade@ietf.org; Tue, 27 Nov 2007 14:01:51 -0500 Received: from outmail128181.authsmtp.net (outmail128181.authsmtp.net [62.13.128.181]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id lARJ1fCk098771; Tue, 27 Nov 2007 19:01:41 GMT Received: from DGCSonyFS (c-75-67-229-125.hsd1.nh.comcast.net [75.67.229.125]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id lARJ1d4p032114; Tue, 27 Nov 2007 19:01:40 GMT From: "Darryl Champagne" To: "'Arnt Gulbrandsen'" , , References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com><7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com><4744168D.10304@isode.com> Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03 Date: Tue, 27 Nov 2007 14:01:38 -0500 Message-ID: <027201c83127$f13cfa50$6e02a8c0@DGCSonyFS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: thread-index: AcgsM8kqNBeot6p8SzOiffHeK1cQagE8PpiQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Server-Quench: 2feb17d4-9d1b-11dc-814e-001185d377ca X-AuthRoute: OCdyYgEXBlZZQw9C UXtZVgdJRQghPh1N CFkFIBdMJUcNSQVJ NksacxtFagJbY1ZH HGQLW1NEUVR7WWJ/ bwofagBDZE1QXQdj TklLR01QEQdtHhxP Wm98KBgmc0VGe3xx ZEIsXXJcVQp4IxMv Q0kAEXAPMWYydWEe BBNFfwJQJR5Kfh5E YlUrV3QKMjRJBA9q Vzw3MjU2OzxTJREd ThsEI05XTlsPFCQ1 QRwZEDNqHEgMX2A+ KRUsLlNZRB15 X-Authentic-SMTP: 61633132393235.squirrel.dmpriest.net.uk:752/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Alexey Melnikov' , 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, I'm a bit confused about where this has ended up. Is this the current status? - Enable gets registered with IANA. - Extensions do not get registered (although they might be described in specific RFCs). - One can enable arbitrary extensions. - There is no indication if an extension is not supported (other than potentially some change to other data returned). - There is no way to disable an extension once it has been enabled. I'm not advocating anything here - solely asking if this is the current way consensus thinks it should work. Is this where it stands at the moment? Also, isn't there another case where a client would care about what extensions work - where there is some interaction between extensions? For example, don't bother with X, Y, and Z unless all 3 work? Thanks, Dgc Darryl G. Champagne -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@oryx.com] Sent: Wednesday, November 21, 2007 6:43 AM To: lemonade@ietf.org; ietf-imapext@imc.org Cc: Alexey Melnikov; Ned Freed Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 Alexey Melnikov writes: > But can somebody please give me a useful use case of why a client > would need to know if something is enabled or not. The client still > needs to cope with a server that doesn't support an extension. I believe there won't be any such useful case with regular clients. There could be three other kinds of cases: 1. A test suite client., which wants to test at the start that it has the same idea of state as the server. 2. A client which can tell the user about the server it's using in a little dialog box: Server host: Protocol: IMAP Server name: Using TLS: Logged in as: Extensions used: That last list would be the ones the server offers and client uses that aren't ENABLE fodder, plus the ones from ENABLED. 3. Really badly written extensions. For example, if Peter makes a complete mess of his FAT NIL proposal, a client might need to know. IMO, 1 is a weak reason (we do this in a nonstandard way and that's perfect for testing), 2 is even weaker and 3 is laughable. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 14:04:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5jj-00047K-Pn; Tue, 27 Nov 2007 14:04:47 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix5ji-00046x-HV for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:04:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5ji-00046o-7J for lemonade@ietf.org; Tue, 27 Nov 2007 14:04:46 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix5jh-0008Sq-TD for lemonade@ietf.org; Tue, 27 Nov 2007 14:04:46 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Nov 2007 19:04:44 +0000 Message-ID: <474C6A09.3020407@isode.com> Date: Tue, 27 Nov 2007 19:03:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dan Karp Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis References: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >>3). COMPARATOR (currently a dependency of both LIST-EXTENDED and >>METADATA). >> >> >COMPARATOR is only a METADATA dependency, right? > It is also a weak dependency for the LIST-EXTENDED document, but it is not required to implement LIST-EXTENDED. >METADATA adds sorting to LIST-EXTENDED, but it's not a standard part of that extension. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 14:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix624-00025Q-6j; Tue, 27 Nov 2007 14:23:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix622-00022P-W9 for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:23:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix622-00021C-LH for lemonade@ietf.org; Tue, 27 Nov 2007 14:23:42 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix622-0002VW-7J for lemonade@ietf.org; Tue, 27 Nov 2007 14:23:42 -0500 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lARJNa0V024045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Nov 2007 14:23:39 -0500 Date: Tue, 27 Nov 2007 14:23:31 -0500 From: Cyrus Daboo cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis Message-ID: <5D6766D5A5510B166B025AC4@caldav.corp.apple.com> In-Reply-To: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> References: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.2 required=5.0 tests=MISSING_HEADERS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 1.6 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dan, --On November 27, 2007 10:41:32 AM -0800 Dan Karp wrote: >> 1). METADATA is currently a dependency for the CONVERT extension. >> There is also a proposal to use METADATA for storing search criteria >> on the server. This is complicated extension for servers to implement. > > Well, if there's any chance of avoiding METADATA, I'm for it. If you're > seriously considering switching to a CONVERT-specific command to get the > server's conversion capabilities, the cleanest I can come up with is: Irrespective of the current METADATA spec, if there is any need to store meta-data-like information on the server then we should have one way to do that, rather than having each extension do its own thing. If there is a need for that, and there is a problem with complexity in the current METADATA spec, then lets address that. I certainly think revising the data model (e.g. doing away with .priv and .shared, fixing the content-type model etc) would one approach, as well as removing the dependency on LISTEXT (i.e. no searching for metadata values). -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 14:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6R7-0005qt-E5; Tue, 27 Nov 2007 14:49:37 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix6R6-0005q1-QH for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:49:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6R6-0005pU-Fn for lemonade@ietf.org; Tue, 27 Nov 2007 14:49:36 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix6R5-0005RX-W9 for lemonade@ietf.org; Tue, 27 Nov 2007 14:49:36 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5C1364AC7C; Tue, 27 Nov 2007 20:49:41 +0100 (CET) Message-Id: Date: Tue, 27 Nov 2007 20:49:44 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis References: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <690403813.331461196188892530.JavaMail.root@dogfood.zimbra.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp writes: > Well, if there's any chance of avoiding METADATA, I'm for it. If > you're seriously considering switching to a CONVERT-specific command > to get the server's conversion capabilities, the cleanest I can come > up with is: =2E.. Personally I was thinking about something like "to which formats could you convert uid 42, bodypart 4.2?". (Bodypart 4.2 has content-type application/octet-stream.) But myself, I'd always just send off "convert 4.2 to jpg, size 69*105" and deal with both success and failure. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 15:11:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6m5-0006Ox-DV; Tue, 27 Nov 2007 15:11:17 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix6m4-0006On-6t for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:11:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6m3-0006Od-SA for lemonade@ietf.org; Tue, 27 Nov 2007 15:11:15 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix6m3-0000hk-BE for lemonade@ietf.org; Tue, 27 Nov 2007 15:11:15 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARKBDFs007274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2007 12:11:13 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARKBDnf008455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Nov 2007 12:11:13 -0800 Date: Tue, 27 Nov 2007 12:10:47 -0800 (Pacific Standard Time) From: Mark Crispin To: Dave Cridland Subject: RE: [lemonade] extended error reporting In-Reply-To: <17749.1196181553.757037@peirce.dave.cridland.net> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> <17749.1196181553.757037@peirce.dave.cridland.net> User-Agent: Alpine 0.99999 (WNT 832 2007-11-27) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.27.113828 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 27 Nov 2007, Dave Cridland wrote: > Just to pick up on this point in particular, this allows the Submission > server to associate the URLAUTH error with the BURL command which produced > it, in case it happens to have batched up a series of BURL requests from > different sessions while it's authenticating to the IMAP server, for example. OK, this is a scenario worth exploring. It postulates that a submission server is going to batch multiple BURL requests into a single URLFETCH (presuamably to save RTTs); and that this sort of thing is going to be common enough that it is worth adding an additional framework for errors. How likely is this scenario? Is it likely to encompass all the BURL requests for a single message? For multiple messages? What about the theory that claims that it is better NOT to batch multiple requests, but instead to have multiple sessions working on parts of the problem? For example, the SMTP strategy advocated by the qmail church? The point here is a sanity check. It isn't enough that it can be done; the point is will it be done, or are we creating an elaborate kludge tower that in the long term won't be used because everybody (at least, everybody who matter...and we neither define nor control that) does something else. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 15:23:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6yJ-00060u-L8; Tue, 27 Nov 2007 15:23:55 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix6yI-0005ze-Fy for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:23:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6yI-0005z6-4r for lemonade@ietf.org; Tue, 27 Nov 2007 15:23:54 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix6yH-0003jf-Hf for lemonade@ietf.org; Tue, 27 Nov 2007 15:23:54 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARKNpCu011310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2007 12:23:51 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lARKNplc010709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Nov 2007 12:23:51 -0800 Date: Tue, 27 Nov 2007 12:23:26 -0800 (Pacific Standard Time) From: Mark Crispin To: Dave Cridland Subject: RE: [lemonade] extended error reporting In-Reply-To: <17749.1196181195.681762@peirce.dave.cridland.net> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> <17749.1196181195.681762@peirce.dave.cridland.net> User-Agent: Alpine 0.99999 (WNT 832 2007-11-27) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.27.115725 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 27 Nov 2007, Dave Cridland wrote: > Well, indeed, but at a protocol level there is no such distinction - both > may, and probably will, use URLFETCH. That presumes that the conversion is encoded into the URL, thus denying the client that choice. Doesn't seem like a good idea to me. > Well, let's assume that the attacker has an expired URL. He can detirmine it > is expired by checking the timestamp in the URL. Getting an error message > telling him so is hardly a breach of security - we're allowed to tell people > the time. Correct. On the other hand, since he can determine that fact himself even in the absence of an error message, that is not an interesting case for the error message. > RESETKEY or similar issues are different - here, the URL has been > forcefully invalidated, and there's no need to distinguish between this and > mailbox deletion. Doing so most certainly leaks information. Correct again, and if this proposal is to move forward I believe that these sorts of issues must be ferreted out and discussed in security considerations. I don't think that it is my responsibility to do so; the proponents should do this. > But there's a wealth of cases - including the message being expunged - for > which the URL can be validated fully. In these case, you have a demonstrably > valid URL that remains authorized, but which points to missing or unusable > data. Here we diverge in opinion. I believe that the case of a message being expunged MAY be an equivalent case to RESETKEY. For example, I want to revoke just one particular URLAUTH that I issued, and not any others. Hence, I want a finer tool than RESETKEY. I copy the affected message back to the same mailbox (people do this all the time!) then expunge the original copy. I may not want > Given that this is being proposed by implementors of BURL capable submission > servers, and you're arguing that it has most value to them, I feel that > you're arguing that the value is higher to the implementor than to the end > user, so I think you may be self-defeating here - it seems somewhat likely > that, amongst URLAUTH implementors, and especially those also working on > BURL, it would have a reasonably high uptake. Maybe. But I don't foresee large multi-URLAUTH URLFETCHes being widely used. It strikes me as a good sounding idea that isn't so good in practice. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 15:27:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix725-0004R7-Fe; Tue, 27 Nov 2007 15:27:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix724-0004Qq-C4 for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix724-0004Qe-2a for lemonade@ietf.org; Tue, 27 Nov 2007 15:27:48 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix722-0001iZ-Bd for lemonade@ietf.org; Tue, 27 Nov 2007 15:27:48 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ED19D4AC7C for ; Tue, 27 Nov 2007 21:27:51 +0100 (CET) Message-Id: Date: Tue, 27 Nov 2007 21:27:54 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] extended error reporting References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> <17749.1196181195.681762@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I haven't said anything. So I will: I like the basic idea (+1 on it) and will contribute once the discussion moves on to productive detail. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 15:46:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7KQ-0000Rw-C8; Tue, 27 Nov 2007 15:46:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix7KP-0000Rl-RW for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:46:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7KP-0000RZ-Hn for lemonade@ietf.org; Tue, 27 Nov 2007 15:46:45 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7KO-0006hR-3u for lemonade@ietf.org; Tue, 27 Nov 2007 15:46:45 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Nov 2007 20:46:42 +0000 Message-ID: <474C81E9.8050204@isode.com> Date: Tue, 27 Nov 2007 20:45:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: IMAP Extensions WG , Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [lemonade] "Friends of IMAP" dinner on Monday, December 3rd X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There seem to be some interest in having [now traditional] "friends of IMAP" dinner in Vancouver on Monday, December 3rd. People who didn't tell me before and who would like to come should email me directly, so that I can estimate how big the reservation should be. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Nov 27 15:50:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7OL-00086O-Oo; Tue, 27 Nov 2007 15:50:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ix7OL-00086G-Bg for lemonade-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:50:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7OL-000866-1c for lemonade@ietf.org; Tue, 27 Nov 2007 15:50:49 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix7OK-0002L1-H3 for lemonade@ietf.org; Tue, 27 Nov 2007 15:50:48 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Nov 2007 20:50:46 +0000 Message-ID: <474C82DE.5070305@isode.com> Date: Tue, 27 Nov 2007 20:49:34 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Darryl Champagne Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03 References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com><7YuRD8XC5q7UzHD2142Juw.md5@libertango.oryx.com><4744168D.10304@isode.com> <027201c83127$f13cfa50$6e02a8c0@DGCSonyFS> In-Reply-To: <027201c83127$f13cfa50$6e02a8c0@DGCSonyFS> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: lemonade@ietf.org, ietf-imapext@imc.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Darryl Champagne wrote: >Hi, > > Hi Darryl, >I'm a bit confused about where this has ended up. > I am not sure that the dust has settled yet. But here are my guesses where things are going: >Is this the current status? > >- Enable gets registered with IANA. > > Not sure why this is important. >- Extensions do not get registered (although they might be described in >specific RFCs). > > Not sure what do you mean here. Registered where? >- One can enable arbitrary extensions. > > Yes. >- There is no indication if an extension is not supported (other than >potentially some change to other data returned). > > The current CAPABILITY mechanism is still going to be used to find out if an extension is supported or not. I think there is some form of consensus that a new response should be added to signal which extensions were successfully enabled. >- There is no way to disable an extension once it has been enabled. > > Correct. The ability to disable extensions was discarded long time ago. >I'm not advocating anything here - solely asking if this is the current way >consensus thinks it should work. Is this where it stands at the moment? > >Also, isn't there another case where a client would care about what >extensions work - where there is some interaction between extensions? > >For example, don't bother with X, Y, and Z unless all 3 work? > > This should be possible: a client can construct an ENABLE command after checking CAPABILITY. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Nov 28 15:41:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTiy-0006Ha-FL; Wed, 28 Nov 2007 15:41:36 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IxTix-0006GL-Bi for lemonade-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 15:41:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTix-0006G8-0S for lemonade@ietf.org; Wed, 28 Nov 2007 15:41:35 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxTiw-0006wG-KL for lemonade@ietf.org; Wed, 28 Nov 2007 15:41:34 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lASKfWcq031490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Nov 2007 12:41:33 -0800 Received: from [192.168.1.13] (vpn-10-50-16-148.qualcomm.com [10.50.16.148]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lASKfVUK005966 for ; Wed, 28 Nov 2007 12:41:32 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 28 Nov 2007 12:35:14 -0800 To: lemonade@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] draft-ietf-lemonade-notifications-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This document has been significantly cleaned up and cut down, per . The Security Considerations has also been reworded. Other minor editing as well. I am not aware of any open issues with the document, therefore I propose that no meeting time be spent on it. I'd appreciate people reviewing it and sending editorial comments to me, and technical comments to the list. If you believe this document does need agenda time in Vancouver, please speak up now. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Some days you feel like Schrodinger's cat. --M. S. Hutchenreuther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Nov 29 08:34:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjXd-0000ph-Bx; Thu, 29 Nov 2007 08:34:57 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IxjXb-0000ek-Iq for lemonade-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 08:34:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjXb-0000bt-5N for lemonade@ietf.org; Thu, 29 Nov 2007 08:34:55 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxjXa-0006D4-2y for lemonade@ietf.org; Thu, 29 Nov 2007 08:34:54 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 7DE57DE8E6F; Thu, 29 Nov 2007 05:34:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 5D7321D5576; Thu, 29 Nov 2007 05:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAJ6aI+wqXnl; Thu, 29 Nov 2007 05:34:45 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 5D02E1D5574; Thu, 29 Nov 2007 05:34:45 -0800 (PST) Date: Thu, 29 Nov 2007 05:34:45 -0800 (PST) From: Dan Karp To: Cyrus Daboo Message-ID: <310490041.110291196343285181.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <591982580.110271196343221445.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.153.167] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Irrespective of the current METADATA spec, if there is any need to > store meta-data-like information on the server then we should have > one way to do that, rather than having each extension do its own > thing. There's a very specific, limited way that a client needs to query the server to discover the server's CONVERT capabilities. Ideally, you want something as clear and as simple as possible to allow this. Yes, you could shoehorn this into a general-purpose "metadata" framework that returns a non-syntax-constrained octet stream to each request, but that sounds a lot like a hydraulic jackhammer in search of nails. (And many of us don't own the jackhammer.) If you want to argue for going down the latter route, we should first look at 2 or 3 other serious proposed extensions that have a need for similar client discovery behavior so that we can try to draw out the commonalities. If there aren't any such extensions or there aren't major common needs, then we're looking at a CONVERT-specific issue that should be dealt with within CONVERT rather than generalized. (And I'm not completely sure that a server's CONVERT implementation capabilities are "metadata" in the same way that, say, the MOTD is.) > If there is a need for that, and there is a problem with complexity in > the current METADATA spec, then lets address that. I certainly think > revising the data model (e.g. doing away with .priv and .shared, fixing > the content-type model etc) would one approach, as well as removing the > dependency on LISTEXT (i.e. no searching for metadata values). METADATA, as it stands now, is way too complicated. It attempts to be a read-write mailbox-level metadata store, a read-write server- level metadata store, and a read-only extension capability discovery mechanism. The third of those seems to have been an afterthought, but it's why METADATA is even in the Lemonade discussion. I'm not convinced that METADATA -- or anything like it -- is a good solution for the third problem. And, as I mentioned above, I'm not sure that the third problem isn't just a CONVERT problem that needs to be dealt with within CONVERT. (If you want to talk about revamping METADATA as a mailbox-level metadata repository, I'm happy to participate. I'm of the opinion that we could shed .priv/.shared, .value/.size, LIST-EXTENDED, vendor space, and multi-level key hierarchy without losing the core METADATA functionality.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Nov 29 08:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjaf-0005Lq-QJ; Thu, 29 Nov 2007 08:38:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ixjae-0005Cj-LI for lemonade-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 08:38:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjae-00059E-7L for lemonade@ietf.org; Thu, 29 Nov 2007 08:38:04 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixjac-0008Hk-F1 for lemonade@ietf.org; Thu, 29 Nov 2007 08:38:04 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5A3EF4AC7C; Thu, 29 Nov 2007 14:38:05 +0100 (CET) Message-Id: Date: Thu, 29 Nov 2007 14:37:54 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis References: <310490041.110291196343285181.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <310490041.110291196343285181.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cyrus Daboo X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp writes: > METADATA, as it stands now, is way too complicated. It attempts to be > a read-write mailbox-level metadata store, a read-write server- level > metadata store, and a read-only extension capability discovery > mechanism. > > The third of those seems to have been an afterthought, but it's why > METADATA is even in the Lemonade discussion. I'm not convinced that > METADATA -- or anything like it -- is a good solution for the third > problem. +1 Btw, this combination makes METADATA difficult for me to implement. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Nov 29 13:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnjc-0007BB-Rw; Thu, 29 Nov 2007 13:03:36 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ixnjb-0007AU-PK for lemonade-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 13:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnjb-0007AC-FT for lemonade@ietf.org; Thu, 29 Nov 2007 13:03:35 -0500 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxnjZ-0001ij-FY for lemonade@ietf.org; Thu, 29 Nov 2007 13:03:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 2E2AD15D2FF for ; Thu, 29 Nov 2007 18:56:41 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLPP-990cdcp for ; Thu, 29 Nov 2007 18:56:41 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 00A3F15D2F8 for ; Thu, 29 Nov 2007 18:56:40 +0100 (CET) From: Philip Van Hoof To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain Date: Thu, 29 Nov 2007 19:03:23 +0100 Message-Id: <1196359403.8325.41.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [lemonade] CONVERT's BODYPARTSTRUCTURE doesn't cut it for the client X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Summary: A client needs to know before launching the CONVERT how the result will look or what the result can look like. It also needs to know what it can convert to. Story: Consider that the client needs to prepare its part viewers before the part's contents are fetched. I'll give an example: progressive loading of JPEGs. I'll go into hypothetical-mode. Warn me if I never go out of it (I know it becomes a dangerous world when going hypothetical, but how else do we specify things for a future?) I'm mr. client and I got this bodystructure piece: ("APPLICATION" "OCTET-STREAM" NIL NIL NIL NIL 11111111111161 0) I can't do a lot with that. I can't instantiate a JPEG viewer because I don't know yet what I'll receive. I can't tell the server "please convert this to something more sensible" because I don't know to what I should convert it to: I don't know what it "is" ... it's a bunch of bytes for as far as I am, as client developer, concerned. BODYPARTSTRUCTURE comes to late too. It will only tell me DURING the conversion phase. At that time I had to make a decision already: it's me who has to specify this to the CONVERT command, right? But what must I specify if I don't know what I can do with this part? So .. a BODYPARTSTRUCTURE-like that I can request BEFORE I convert? For example: 1 UID FETCH 10 BODYSTRUCTURE And I receive a * 1 FETCH (UID 10 BODYSTRUCTURE (((("TEXT" "PLAIN" NIL NIL NIL "7BIT" 83 4 NIL NIL NIL)("TEXT" "HTML" ("CHARSET" "utf-8") NIL NIL "7BIT" 690 13 NIL NIL NIL) "ALTERNATIVE" ("BOUNDARY" "---") NIL NIL)("APPLICATION" "WORD-DOCUMENT-whatever" ("NAME" "test.doc") "" NIL "BASE64" 113000 NIL ("ATTACHMENT" ("FILENAME" "test.doc")) NIL) "RELATED" ("TYPE" "multipart/alternative" "BOUNDARY" "---") NIL NIL) "MIXED" ("BOUNDARY" "---") NIL NIL)) ... Or perhaps I just receive a ... ... ("APPLICATION" "OCTET-STREAM" NIL NIL NIL NIL 11111111111161 0) ... What I propose to add to CONVERT is: 2 UID FETCH 10 BODYCONVERTIBLESTRUCTURE[2] * BODYCONVERTIBLESTRUCTURE[2] ("IMAGE" "JPG" "CONVERTIBLE-TO" ( ("IMAGE" "JPEG" ("X-WIDTH" "VARIABLE" "Y-WIDTH" "VARIABLE")) ("IMAGE" "GIF" ("X-WIDTH" "VARIABLE" "Y-WIDTH" "VARIABLE")) ("APPLICATION" "PDF" NIL) ("TEXT" "HTML" NIL) ("TEXT" "PLAIN" NIL) )) And then I can do: 3 UID CONVERT 10 ("APPLICATION/PDF") (BINARY[2] BODYPARTSTRUCTURE[2]) This BODYCONVERTIBLESTRUCTURE must not be a fast one, I would only need this at the moment when the user wants to view a particular message. I don't need it to build my summary screen (for which I might want to fetch BODYSTRUCTURE and ENVELOPE, for example). The chance for my case will be extremely high that I will do a CONVERT soon after the BODYCONVERTIBLESTRUCTURE. However, I don't want it immediately (like with the BODYPARTSTRUCTURE, this doesn't help me). Based on that response, I will make a decision for my CONVERT command. Hoping this makes sense :) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 30 15:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCL4-0000Yf-L4; Fri, 30 Nov 2007 15:19:54 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyCL3-0000YE-46 for lemonade-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 15:19:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCL2-0000VL-4J for lemonade@ietf.org; Fri, 30 Nov 2007 15:19:52 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyCL1-0006PU-GY for lemonade@ietf.org; Fri, 30 Nov 2007 15:19:52 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAUKJkxl009262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Nov 2007 12:19:46 -0800 Received: from [192.168.1.13] (vpn-10-50-16-88.qualcomm.com [10.50.16.88]) by hamtaro.qualcomm.com (8.14.2/8.13.6/1.0) with ESMTP id lAUKJdOl025599; Fri, 30 Nov 2007 12:19:41 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <027201c83127$f13cfa50$6e02a8c0@DGCSonyFS> References: <1700927456.65461195588159131.JavaMail.root@dogfood.zimbra.com><7YuRD8 XC5q7UzHD2142Juw.md5@libertango.oryx.com><4744168D.10304@isode.com> <027201c83127$f13cfa50$6e02a8c0@DGCSonyFS> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 30 Nov 2007 12:17:22 -0800 To: "Darryl Champagne" , "'Arnt Gulbrandsen'" , , From: Randall Gellens Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'Alexey Melnikov' , 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:01 PM -0500 11/27/07, Darryl Champagne wrote: > Hi, > I'm a bit confused about where this has ended up. Is this the current > status? > > - Enable gets registered with IANA. > - Extensions do not get registered (although they might be described in > specific RFCs). ENABLE, as an extension, gets registered with IANA at . So do new extensions. ENABLE doesn't change this at all. ENABLE is merely a clean way to flip a switch during an IMAP session that otherwise requires magic. That is, ENABLE just makes state changes explicit (and maybe at a more constrained time) rather than having them occur at arbitrary points as a result of the client's use of certain command forms. > - One can enable arbitrary extensions. Any ENABLE-able extension can be used with ENABLE, but that's a tautology. > - There is no indication if an extension is not supported (other than > potentially some change to other data returned). Extensions still are listed in the CAPABILITY response -- ENABLE doesn't change that. But the client needs to know which of them can be used with ENABLE. > - There is no way to disable an extension once it has been enabled. Correct. > I'm not advocating anything here - solely asking if this is the current way > consensus thinks it should work. Is this where it stands at the moment? > > Also, isn't there another case where a client would care about what > extensions work - where there is some interaction between extensions? > > For example, don't bother with X, Y, and Z unless all 3 work? The client can examine the CAPABILITY response. But I think there is still an open issue as to inclusion or exclusion of an extension which the client included in ENABLE but whose ENABLE-ment failed. So, the standard/recommended command sequence might be: a1 CAPABILITY (to see if TLS is and which authentication mechanisms are supported) a2 STARTTLS (if supported) a3 AUTHENTICATE b1 ENABLE (to try and enable all desired mechanisms) b2 CAPABILITY (to see which extensions are supported, and which extensions included in the NOTIFY command were in fact ENABLEd) Or, a1 CAPABILITY (to see if TLS is and which authentication mechanisms are supported) a2 STARTTLS (if supported) a3 AUTHENTICATE b1 CAPABILITY (to see which extensions are supported) b1 ENABLE (to try and enable all desired and supported mechanisms) In the first case, the client learns from the post-authentication CAPABILITY response which extensions were successfully ENABLEd. The second case, the ENABLE response needs to indicate this. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. --Maurice Wilkes discovers debugging, 1949 (courtesy of Paul Robinson) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Nov 30 15:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCP0-0002PI-JF; Fri, 30 Nov 2007 15:23:58 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyCOz-0002Om-Na for lemonade-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 15:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCOz-0002OX-E1 for lemonade@ietf.org; Fri, 30 Nov 2007 15:23:57 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyCOy-00019R-Tt for lemonade@ietf.org; Fri, 30 Nov 2007 15:23:57 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAUKNteL009726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Nov 2007 12:23:55 -0800 Received: from [192.168.1.13] (vpn-10-50-16-88.qualcomm.com [10.50.16.88]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAUKNpj7021176; Fri, 30 Nov 2007 12:23:54 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <4745CF17.3000405@isode.com> References: <4745CF17.3000405@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 30 Nov 2007 12:23:11 -0800 To: Alexey Melnikov , Lemonade WG From: Randall Gellens Subject: Re: [lemonade] Proposed agenda for the Lemonade WG meeting in Vancouver Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 6:48 PM +0000 11/22/07, Alexey Melnikov wrote: > Lemonade notifications (draft-ietf-lemonade-notifications-05.txt) (20 mins) I don't think this draft needs an agenda slot, especially not a 20-minute one. But if desired we could have a slot to review and verify what we are doing about notifications, including this draft, text in profile-bis, and the changes that were made per . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Good breeding consists in concealing how much we think of ourselves and how little we think of the other person. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade