From lemonade-bounces@ietf.org Mon Sep 03 04:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS7Im-0007Dt-5U; Mon, 03 Sep 2007 04:28:56 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IS7Il-0007CV-0e for lemonade-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 04:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS7Ih-0007Bl-5Q for lemonade@ietf.org; Mon, 03 Sep 2007 04:28:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IS7If-00048z-3k for lemonade@ietf.org; Mon, 03 Sep 2007 04:28:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l838SRsr005522; Mon, 3 Sep 2007 11:28:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 11:28:08 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 11:28:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Date: Mon, 3 Sep 2007 11:27:30 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Thread-Index: AcfrOzELbhMIyhMcTJiJREsFghD1WgCwYing References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com><4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> From: To: , X-OriginalArrivalTime: 03 Sep 2007 08:28:07.0769 (UTC) FILETIME=[5B051C90:01C7EE04] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: leiba@watson.ibm.com 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 Thank You Randall, I have further questions/comments. >> What is the execution order of the scripts (last modification=20 >> date/alphabetical/etc)? I am asking this because one script=20 >might move=20 >> an email while another might notify it - which one happens first... > >My suggested text included: > >> After all Sieve scripts have run, the implementation MAY=20 >then expunge=20 >> the original message > >This way, the message will remain in the folder while all=20 >scripts run, so multiple scripts may move it, resulting in the=20 >message effectively being copied. As for modifications,=20 >existing text in the document says modifications don't show up=20 >to the script, so in effect they likewise take effect after=20 >all scripts have run. But I see no text saying that the message MUST NOT be expunged until all scripts have finished. Perhaps it would contradict a MUST somewhere in the SIEVE specs? >> What if there are two scripts and: both want to send a=20 >notification,=20 >> and to the same/different addresses? Which will be sent? Both? > >Yes. Each scripts needs to operate independently. =20 >Separately, as an optimization, an implementation could=20 >coalesce multiple notifications to the same address into a=20 >single notification. Ok, so let' take this a step further. There is a new mail arriving, and we have scripts A, B and C from clients A, B and C respectively. The new mail triggers both A and B scripts. The result of script A is to delete the email. The result of script B is to move (copy+delete, right?) the email to a different mailbox. The result of script C is to notify about new mail. So, A copy of the email is placed into another mailbox and finally the mail is deleted and C is notified. The deposit of the new mail to the other mailbox (the copy action of script B) triggers at least script A (since it was script B making the change, I assume that it will not trigger itself to avoid loops) and C. The result of script C is to notify about new mail. The result of script A is to delete the email (same result as before). Script A triggers script B and C. B does nothing, C is notified again. Problems: - the email that B wanted to move somewhere else is deleted - C receives four notifications when "nothing" really happened (a new mail arrived, copied, but deleted both). This can be optimized though. - If C wanted a copy of the mail (justl like B), script A would have deleted it. - What if scripts A and B moved (copy+delete) the email between two different mailboxes continuously (infinite loop)? >> The original text refers to these problems as: " complexity and=20 >> possible ambiguity involved with coordinating the results of=20 >> multiple scripts". >> Should these problems be elaborated in more detail and - hopefully=20 >> - provide a standardized behavior? > >I have attempted to provide a standardized behavior. If you feel=20 >more detail is needed, or that there is still ambiguity, please point=20 >out where. There is nothing wrong with the text - I just got the feeling that something is missing. I can't tell what, but something does not feel right. Perhaps after we went through a few use cases, we can come up with a solid proposal. >> One more question if I may: >> How do You identify (uniquely) which script belongs to which=20 >> client? I mean if we can't do this and clients keep overwriting=20 >> each others' scripts (because they don't know which one belongs to=20 >> them), we did not achieve anything, did we? > >My suggested text included: > >At 3:40 PM -0700 8/13/07, Randall Gellens wrote: >> The entry name below ""/IMAPSieve/Script/client/" SHOULD be >> named .. For example, "Eudora.FC2302". > >Hence, each client is assigned a through an IANA=20 >registry, perhaps an existing one, or a new one can be created. Each=20 >client is free to choose a of its own creation. > I was=20 >thinking that any identifier for the device could be used, but even a=20 >random number with a reasonable range would suffice. I guess a client could figure out the allocated random IDs by doing a simple query to the server - so it could figure out a unique random ID for itself if needed. Could we add then (with a requirement saying that it must be unique within the scope of the client-id; could be any number of hexa digits, case insensitive? 0-9, a-f, A-F)? So the whole ID would look like: .. A requirement might be also needed to store the in a safe place. Some clients overwrite/delete user data when the OS/client/firmware is updated. If the random id is lost, there will be no way to identify which client owned the script and it wil be hanging there for an eternity. Could this ID be re-used? Well, at least the . part of it - for example, to store client-specific preferences on the server? > There was never=20 >any intention of allowing clients to "keep overwriting each others'=20 >scripts (because they don't know which one belongs to them)" --=20 >instead, the idea is to err on the side of possible extra scripts,=20 >perhaps because a client has forgotten its identifier. Those=20 >obsolete scripts would eventually be reaped by the server, as=20 >described in my suggested text. Yes, this is my goal as well. Just trying to make it fool-proof. >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- >The number of licorice gumballs you get out of a gumball machine >increases in direct proportion to how much you hate licorice. > > >_______________________________________________ >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 Sep 04 10:05:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZ03-00016L-HM; Tue, 04 Sep 2007 10:03:27 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ISZ02-00016F-Dn for lemonade-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 10:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZ02-000167-4F for lemonade@ietf.org; Tue, 04 Sep 2007 10:03:26 -0400 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISZ00-0002A4-R2 for lemonade@ietf.org; Tue, 04 Sep 2007 10:03:26 -0400 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 l84E3GHg025475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 10:03:19 -0400 Date: Tue, 04 Sep 2007 10:03:11 -0400 From: Cyrus Daboo To: Zoltan.Ordogh@nokia.com, randy@qualcomm.com, lemonade@ietf.org Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Message-ID: <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.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.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: leiba@watson.ibm.com 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, --On September 3, 2007 11:27:30 AM +0300 Zoltan.Ordogh@nokia.com wrote: >> Yes. Each scripts needs to operate independently. >> Separately, as an optimization, an implementation could >> coalesce multiple notifications to the same address into a >> single notification. I think as Zoltan's examples show this is getting way too complicated. Having multiple "competing" scripts being executed like this is a recipe for disaster. Lets drop this aspect of the spec and see whether the rest will actually get implemented and be interoperable first. Then, if there really is demand, we can consider per-client scripts as an extension. -- 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 Sep 04 10:31: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 1ISZPI-0008Og-R9; Tue, 04 Sep 2007 10:29:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ISZPH-0008Ob-Rl for lemonade-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 10:29:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZPH-0008OT-Hd for lemonade@ietf.org; Tue, 04 Sep 2007 10:29:31 -0400 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISZPH-0002bk-6j for lemonade@ietf.org; Tue, 04 Sep 2007 10:29:31 -0400 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 76926DE813A; Tue, 4 Sep 2007 07:29:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id DF9191D5572; Tue, 4 Sep 2007 07:26:15 -0700 (PDT) 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 FltmXKpkhXXB; Tue, 4 Sep 2007 07:26:13 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 20A331D5575; Tue, 4 Sep 2007 07:26:13 -0700 (PDT) Date: Tue, 4 Sep 2007 07:26:13 -0700 (PDT) From: Dan Karp To: Cyrus Daboo Message-ID: <1245869244.74581188915973031.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> Subject: Re: [lemonade] IMAP-SIEVE: Per-Client Sieve Script MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.249.241] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: randy@qualcomm.com, lemonade@ietf.org, leiba@watson.ibm.com, Zoltan Ordogh 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 think as Zoltan's examples show this is getting way too complicated. > Having multiple "competing" scripts being executed like this is a recipe > for disaster. Lets drop this aspect of the spec and see whether the rest > will actually get implemented and be interoperable first. Then, if there > really is demand, we can consider per-client scripts as an extension. Hear, hear. _______________________________________________ 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 Sep 05 03:25:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISpEo-0000yR-PE; Wed, 05 Sep 2007 03:23:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ISpEo-0000yJ-8L for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 03:23:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISpEn-0000yB-TD for lemonade@ietf.org; Wed, 05 Sep 2007 03:23:45 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISpEn-0003GH-AQ for lemonade@ietf.org; Wed, 05 Sep 2007 03:23:45 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l857N0k9027506; Wed, 5 Sep 2007 10:23:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 10:23:12 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 10:23:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Date: Wed, 5 Sep 2007 10:22:35 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> In-Reply-To: <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Thread-Index: Acfu/GKzVYdPcpWtRhu74pvagEu+xwAjk84Q References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> From: To: , , X-OriginalArrivalTime: 05 Sep 2007 07:23:12.0524 (UTC) FILETIME=[9E1964C0:01C7EF8D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: leiba@watson.ibm.com 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 Cyrus, Randall has a valid point and sooner or later we are going to tackle the = multi-client issue. I think it would be beneficial to address these issues - if possible, = before the Lemonade release. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Cyrus Daboo [mailto:cyrus@daboo.name]=20 >Sent: 04 September, 2007 17:03 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); randy@qualcomm.com;=20 >lemonade@ietf.org >Cc: leiba@watson.ibm.com >Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script > >Hi, > >--On September 3, 2007 11:27:30 AM +0300 Zoltan.Ordogh@nokia.com wrote: > >>> Yes. Each scripts needs to operate independently. >>> Separately, as an optimization, an implementation could coalesce=20 >>> multiple notifications to the same address into a single=20 >>> notification. > >I think as Zoltan's examples show this is getting way too complicated.=20 >Having multiple "competing" scripts being executed like this=20 >is a recipe for disaster. Lets drop this aspect of the spec=20 >and see whether the rest will actually get implemented and be=20 >interoperable first. Then, if there really is demand, we can=20 >consider per-client scripts as an extension. > >-- >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 Wed Sep 05 03:46: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 1ISpZL-0001Np-KS; Wed, 05 Sep 2007 03:44:59 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ISpZK-0001K9-Oe for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 03:44:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISpZK-0001K0-Dr for lemonade@ietf.org; Wed, 05 Sep 2007 03:44:58 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISpZJ-0003mi-UT for lemonade@ietf.org; Wed, 05 Sep 2007 03:44:58 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 46A5E4AC98; Wed, 5 Sep 2007 09:44:56 +0200 (CEST) Message-Id: Date: Wed, 5 Sep 2007 09:46:14 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] IMAP-SIEVE: Per-Client Sieve Script References: <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: randy@qualcomm.com, cyrus@daboo.name, leiba@watson.ibm.com, Zoltan.Ordogh@nokia.com 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 Zoltan.Ordogh@nokia.com writes: > Randall has a valid point and sooner or later we are going to tackle > the multi-client issue. > I think it would be beneficial to address these issues - if possible, > before the Lemonade release. Then let's drop them and discuss them separately, and if it's resolved before WGLC we can always put them back in. Personally I have absolutely no idea how to do this, but I see Randall's point, so I'm afraid I cannot contribute right now. I will if I think of something. 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 Sep 05 09:37: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 1ISv2r-0008QP-NZ; Wed, 05 Sep 2007 09:35:49 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ISv2q-0008QJ-2O for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 09:35:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISv2p-0008QB-MU for lemonade@ietf.org; Wed, 05 Sep 2007 09:35:47 -0400 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISv2p-0005v4-9j for lemonade@ietf.org; Wed, 05 Sep 2007 09:35:47 -0400 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 l85DZeDU004365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2007 09:35:43 -0400 Date: Wed, 05 Sep 2007 09:35:35 -0400 From: Cyrus Daboo To: Zoltan.Ordogh@nokia.com, randy@qualcomm.com, lemonade@ietf.org Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Message-ID: <301726258D35308A27110E08@caldav.corp.apple.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.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.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: leiba@watson.ibm.com 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 Zoltan, --On September 5, 2007 10:22:35 AM +0300 Zoltan.Ordogh@nokia.com wrote: > Randall has a valid point and sooner or later we are going to tackle the > multi-client issue. I think it would be beneficial to address these > issues - if possible, before the Lemonade release. I disagree - I question whether there is a need to do it this way at all. I think an adequate solution for most cases is to allow manual triggering of scripts by clients. That way clients can apply their own scripts when they actually interact with the server. The whole business of allowing clients to upload their own scripts which get automatically handled and considered "private" to each client is awkward. For example, what happens if a user stops using a client? How does the script for that client get disabled? Does there have to be some sort of script management UI in every client so users can manage other client's scripts use etc? I think we should remove this for now, finish the spec with the single script behavior, deploy it and then see what the practical needs of clients are rather than the current theoretical needs. -- 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 Wed Sep 05 14:59: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 1IT042-00077T-65; Wed, 05 Sep 2007 14:57:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT041-00077O-97 for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 14:57:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT040-000779-T7 for lemonade@ietf.org; Wed, 05 Sep 2007 14:57:20 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT040-0005d7-3u for lemonade@ietf.org; Wed, 05 Sep 2007 14:57:20 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l85IvJlY017357 for ; Wed, 5 Sep 2007 18:57:19 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JNW00601SAPFK00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 05 Sep 2007 12:57:19 -0600 (MDT) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNW00D3OSKGESTA@mail-amer.sun.com> for lemonade@ietf.org; Wed, 05 Sep 2007 12:57:19 -0600 (MDT) Date: Wed, 05 Sep 2007 11:55:13 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acfv7kpHX1aWVxlSQNanLtTOtc6G5A== X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Subject: [lemonade] IMAP URLS 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="===============0011814743==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============0011814743== Content-type: multipart/alternative; boundary="Boundary_(ID_vE+maYkQ7sx+fyU8EEvVbA)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_vE+maYkQ7sx+fyU8EEvVbA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT RFC 2192 (IMAP URLs) says in section 7: The [isection] field is optional. If not present, the URL refers to the entire Internet message as returned by the IMAP command "UID FETCH BODY.PEEK[]". If present, the URL refers to the object returned by a "UID FETCH BODY.PEEK[
]" command. The type of the object may be determined with a "UID FETCH BODYSTRUCTURE" command and locating the appropriate part in the resulting BODYSTRUCTURE. Note that unsafe characters in [isection] MUST be encoded as described in [BASIC-URL]. So for instance, I could have a relative IMAP URL "/inbox/;uid=59917/;section=header.fields (date from)". RFC3501 says in section 6.4.5 The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part specifiers refer to the [RFC-2822] header of the message or of an encapsulated [MIME-IMT] MESSAGE/RFC822 message. HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of field-name (as defined in [RFC-2822]) names, and return a subset of the header. The subset returned by HEADER.FIELDS contains only those header fields with a field-name that matches one of the names in the list; similarly, the subset returned by HEADER.FIELDS.NOT contains only the header fields with a non-matching field-name. The field-matching is case-insensitive but otherwise exact. Subsetting does not exclude the [RFC-2822] delimiting blank line between the header and the body; the blank line is included in all header fetches, except in the case of a message which has no body and no blank line. so presumably the result of the imap URL would include the extra CR/LF at the end except in the case mentioned. This is IMHO not as useful in CATENATE as it could be I can see some virtue in being able to say in an append 1 append drafts catenate (url "/inbox/;uid=59917/;section=header.fields.not (date from)" text {89+} Date: Tue, 28 Aug 2007 21:31:25 -0700 (PDT) From: aardvark@red.iplanet.com 12345678 ) With the interpretation of the RFC that I think is the strict reading this would not work as I would get an extra CR/LF back after the requested headers. Do other people read the RFC the same way, and if so what have they implemented? In the interest of full disclosure I should say that I do not return this CR/LF. Peter --Boundary_(ID_vE+maYkQ7sx+fyU8EEvVbA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

RFC 2192 (IMAP URLs) says in section 7:

     The [isection] field is optional.  If not present, the URL refers

     to the entire Internet message as returned by the IMAP command "UID

     FETCH <uid> BODY.PEEK[]".  If present, the URL refers to the object

     returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command.  The

     type of the object may be determined with a "UID FETCH <uid>

     BODYSTRUCTURE" command and locating the appropriate part in the

     resulting BODYSTRUCTURE.  Note that unsafe characters in [isection]

     MUST be encoded as described in [BASIC-URL].

 

So for instance, I could have a relative IMAP URL

"/inbox/;uid=59917/;section=header.fields (date from)".

 

RFC3501 says in section 6.4.5

 

         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part

         specifiers refer to the [RFC-2822] header of the message or of

         an encapsulated [MIME-IMT] MESSAGE/RFC822 message.

         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of

         field-name (as defined in [RFC-2822]) names, and return a

 

         subset of the header.  The subset returned by HEADER.FIELDS

         contains only those header fields with a field-name that

         matches one of the names in the list; similarly, the subset

         returned by HEADER.FIELDS.NOT contains only the header fields

         with a non-matching field-name.  The field-matching is

         case-insensitive but otherwise exact.  Subsetting does not

         exclude the [RFC-2822] delimiting blank line between the header

         and the body; the blank line is included in all header fetches,

         except in the case of a message which has no body and no blank

         line.

 

so presumably the result of the imap URL would include the extra CR/LF

at the end except in the case mentioned.  This is IMHO not as useful in

CATENATE as it could be

 

I can see some virtue in being able to say in an append

 

1 append drafts catenate (url "/inbox/;uid=59917/;section=header.fields.not (date from)" text {89+}

Date: Tue, 28 Aug 2007 21:31:25 -0700 (PDT)

From: aardvark@red.iplanet.com

 

12345678

)

 

With the interpretation of the RFC that I think is the strict reading this would not work as I would get an extra CR/LF back after the requested headers.  Do other people read the RFC the same way, and if so what have they implemented?

 

In the interest of full disclosure I should say that I do not return this CR/LF.

 

Peter

 

--Boundary_(ID_vE+maYkQ7sx+fyU8EEvVbA)-- --===============0011814743== 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 --===============0011814743==-- From lemonade-bounces@ietf.org Wed Sep 05 16:07: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 1IT18H-0004L7-8P; Wed, 05 Sep 2007 16:05:49 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT18F-0004KJ-7E for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:05:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT18E-0004KB-T9 for lemonade@ietf.org; Wed, 05 Sep 2007 16:05:46 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT18E-0000eC-FT for lemonade@ietf.org; Wed, 05 Sep 2007 16:05:46 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l85K5hCR023777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2007 13:05:43 -0700 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.03) with ESMTP id l85K5fxx013479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2007 13:05:43 -0700 Date: Wed, 5 Sep 2007 13:05:41 -0700 (PDT) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] IMAP URLS In-Reply-To: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> Message-ID: References: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> 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.9.5.124327 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_500_599 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Wed, 5 Sep 2007, Peter Coates wrote: > In the interest of full disclosure I should say that I do not return this > CR/LF. If your server implementation violates the specification in this way then it is non-compliant and broken. Please fix this problem as soon as possible and let me know when it is fixed (and preferably which version fixes it). Thank you. -- 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 Wed Sep 05 16:24: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 1IT1Ok-00079f-JF; Wed, 05 Sep 2007 16:22:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT1Oi-00079Z-Pw for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1Oi-00079R-GS for lemonade@ietf.org; Wed, 05 Sep 2007 16:22:48 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT1Og-0007NU-EU for lemonade@ietf.org; Wed, 05 Sep 2007 16:22:48 -0400 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, 5 Sep 2007 21:22:43 +0100 Message-ID: <46DF103E.4090106@isode.com> Date: Wed, 05 Sep 2007 21:23:26 +0100 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: Mark Crispin Subject: Re: [lemonade] IMAP URLS References: <0a0901c7efee$6acca580$4065f080$%coates@sun.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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Mark Crispin wrote: > On Wed, 5 Sep 2007, Peter Coates wrote: > >> In the interest of full disclosure I should say that I do not return >> this >> CR/LF. > > If your server implementation violates the specification in this way > then it is non-compliant and broken. *Which* specification? I think Peter was talking about Catenate and not RFC 3501 FETCH. > Please fix this problem as soon as possible and let me know when it is > fixed (and preferably which version fixes it). Thank you. _______________________________________________ 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 Sep 05 16:31:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1VE-0006lE-8f; Wed, 05 Sep 2007 16:29:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT1VD-0006ew-9y for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:29:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1VC-0006cD-UF for lemonade@ietf.org; Wed, 05 Sep 2007 16:29:30 -0400 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 1IT1VC-0001vf-G5 for lemonade@ietf.org; Wed, 05 Sep 2007 16:29:30 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML02AY8BIO004M2Q@mauve.mrochek.com> for lemonade@ietf.org; Wed, 5 Sep 2007 13:29:26 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MKYJIADNM800005F@mauve.mrochek.com> for lemonade@ietf.org; Wed, 05 Sep 2007 13:29:20 -0700 (PDT) Message-id: <01ML02AX0B3Y00005F@mauve.mrochek.com> Date: Wed, 05 Sep 2007 13:22:11 -0700 (PDT) From: Ned Freed Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script In-reply-to: "Your message dated Tue, 04 Sep 2007 10:03:11 -0400" <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> To: Cyrus Daboo DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189024166; h=Date: From:Subject:MIME-version:Content-type; b=uhNfSGUTol4t1Xh/yzuAWD94U +xW6HVU1sL6ykrtzKrZuGysCWSx+/ct+5agk+i+1MscRgfXRa9QEPDJ8C5mCA== X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: randy@qualcomm.com, lemonade@ietf.org, leiba@watson.ibm.com, Zoltan.Ordogh@nokia.com 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, > --On September 3, 2007 11:27:30 AM +0300 Zoltan.Ordogh@nokia.com wrote: > >> Yes. Each scripts needs to operate independently. > >> Separately, as an optimization, an implementation could > >> coalesce multiple notifications to the same address into a > >> single notification. > I think as Zoltan's examples show this is getting way too complicated. > Having multiple "competing" scripts being executed like this is a recipe > for disaster. Lets drop this aspect of the spec and see whether the rest > will actually get implemented and be interoperable first. Then, if there > really is demand, we can consider per-client scripts as an extension. +1 I have actually implemented handling of multiple script handling in the context of delivery processing. There are all sorts of ways to do it, but the goal has to be that things manage to work in the way users expect. I eventually arrived at a result that was remarkably close to the recommendations Jutta Degener did (she wrote a droaft some time back on how to handle multiple delivery time sieves). However, delivery time processing is a better defined problem (it is, after all, the place Sieve was deisned to operate) and there are some simplifying assumptions having to do with ranking of multiple sieves that I don't think are possible in the context of IMAP. I therefore support dropping this for now. 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 Wed Sep 05 16:36: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 1IT1a5-000235-Oh; Wed, 05 Sep 2007 16:34:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT1a4-00022u-Hr for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1a4-00022j-8D for lemonade@ietf.org; Wed, 05 Sep 2007 16:34:32 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT1a2-0007mu-S5 for lemonade@ietf.org; Wed, 05 Sep 2007 16:34:32 -0400 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.06) with ESMTP id l85KYTwK017734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2007 13:34:30 -0700 X-Auth-Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l85KYTcp024768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2007 13:34:29 -0700 Date: Wed, 5 Sep 2007 13:34:29 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] IMAP URLS In-Reply-To: <46DF103E.4090106@isode.com> Message-ID: References: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> <46DF103E.4090106@isode.com> 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.9.5.130724 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' X-Spam-Score: -1.0 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Wed, 5 Sep 2007, Alexey Melnikov wrote: > Mark Crispin wrote: >> On Wed, 5 Sep 2007, Peter Coates wrote: >>> In the interest of full disclosure I should say that I do not return this >>> CR/LF. >> If your server implementation violates the specification in this way then >> it is non-compliant and broken. > *Which* specification? I think Peter was talking about Catenate and not RFC > 3501 FETCH. If that was the case, then CATENATE would have to disregard trailing CRLFs at the end of a header piece being catenated, but somehow have to figure out when it's in a header and when it isn't. Also, Peter says "return this CR/LF", not "disregard this CR/LF." Or, perhaps, he's talking about URLFETCH (assuming that the CATENATE does a URLFETCH instead of resolving the URL internally...but I thought we agreed not to stipulate that in this version?). If that's the case, then there's nothing in URLFETCH that says to truncate trailing CRLFs from message header parts. The only way that I can interpret Peter's message that makes sense (at least to me) is if he's talking about FETCH. And in that case, the IMAP specification is clear and unambiguous. -- 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 Wed Sep 05 16:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1ds-0003LD-2k; Wed, 05 Sep 2007 16:38:28 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT1dq-0003Gy-Le for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1dq-0003Gn-C5 for lemonade@ietf.org; Wed, 05 Sep 2007 16:38:26 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT1do-0007rU-Iu for lemonade@ietf.org; Wed, 05 Sep 2007 16:38:26 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l85KcOMJ028859 for ; Wed, 5 Sep 2007 20:38:24 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JNW00D01X50PZ00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 05 Sep 2007 14:38:24 -0600 (MDT) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNW0050EXBGCDE0@mail-amer.sun.com>; Wed, 05 Sep 2007 14:38:24 -0600 (MDT) Date: Wed, 05 Sep 2007 13:37:56 -0700 From: Peter Coates Subject: RE: [lemonade] IMAP URLS In-reply-to: To: "'Mark Crispin'" , "'Alexey Melnikov'" Message-id: <0a1d01c7effc$af2fa200$0d8ee600$%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: Acfv/DQ0LGJeip/bQOGrT9k3kTJlQgAACYeg References: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> <46DF103E.4090106@isode.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 The specification for fetch is unambiguous and the CRLF has to be present and is present in all implementations I'm aware of. I am discussing IMAP URLS. I am suggesting that the CRLF at the end of an IMAP URL that requests header, or one that requests some headers NOT return the CRLF. That would affect URLFETCH and CATENATE. Peter -----Original Message----- From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] Sent: September 5, 2007 13:34 To: Alexey Melnikov Cc: Peter Coates; lemonade@ietf.org Subject: Re: [lemonade] IMAP URLS On Wed, 5 Sep 2007, Alexey Melnikov wrote: > Mark Crispin wrote: >> On Wed, 5 Sep 2007, Peter Coates wrote: >>> In the interest of full disclosure I should say that I do not return this >>> CR/LF. >> If your server implementation violates the specification in this way then >> it is non-compliant and broken. > *Which* specification? I think Peter was talking about Catenate and not RFC > 3501 FETCH. If that was the case, then CATENATE would have to disregard trailing CRLFs at the end of a header piece being catenated, but somehow have to figure out when it's in a header and when it isn't. Also, Peter says "return this CR/LF", not "disregard this CR/LF." Or, perhaps, he's talking about URLFETCH (assuming that the CATENATE does a URLFETCH instead of resolving the URL internally...but I thought we agreed not to stipulate that in this version?). If that's the case, then there's nothing in URLFETCH that says to truncate trailing CRLFs from message header parts. The only way that I can interpret Peter's message that makes sense (at least to me) is if he's talking about FETCH. And in that case, the IMAP specification is clear and unambiguous. -- 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 Wed Sep 05 16:47:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1l7-0003zw-1Q; Wed, 05 Sep 2007 16:45:57 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT1l5-0003zm-V4 for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:45:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1l5-0003ze-KJ for lemonade@ietf.org; Wed, 05 Sep 2007 16:45:55 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT1l5-0002Js-2m for lemonade@ietf.org; Wed, 05 Sep 2007 16:45:55 -0400 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.06) with ESMTP id l85Kjriv008203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2007 13:45:54 -0700 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.03) with ESMTP id l85KjpX1020576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2007 13:45:53 -0700 Date: Wed, 5 Sep 2007 13:45:50 -0700 (PDT) From: Mark Crispin To: Peter Coates Subject: RE: [lemonade] IMAP URLS In-Reply-To: <0a1d01c7effc$af2fa200$0d8ee600$%coates@sun.com> Message-ID: References: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> <46DF103E.4090106@isode.com> <0a1d01c7effc$af2fa200$0d8ee600$%coates@sun.com> 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.9.5.132123 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: lemonade@ietf.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 On Wed, 5 Sep 2007, Peter Coates wrote: > The specification for fetch is unambiguous and the CRLF has to be present > and is present in all implementations I'm aware of. Excellent, thank you. > I am discussing IMAP URLS. > I am suggesting that the CRLF at the end of an IMAP URL that requests > header, or one that requests some headers NOT return the CRLF. That would > affect URLFETCH and CATENATE. It does more than that. Either URLFETCH and CATENATE have to have explicit language that states "in the event of a fetch of header data, the trailing CRLF is omitted", or every implementation of IMAP URL has to be changed to do this. It also begs the question of what to do if you CATENATE BODY[HEADER] and BODY[TEXT]. Does this mean that you have to add a CRLF literal between the two? Note that you could accomplish what you want in your example by CATENATEing literal text with the added headers (but no trailing CRLF) first, then the rump header from partial fetching. That would have the effect of putting the added headers before any Received: lines (which is probably why you didn't do it that way) but IMHO it is dishonest to change the From: and preserve Received: lines so I'm not particularly worried about that problem. Your overall point is a good one, and it's something that should have been raised long ago when partial header fetching was discussed in the IMAP base specification. But I'm afraid that it's over a decade too late to close that barn door. -- 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 Wed Sep 05 17:21: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 1IT2II-0000sO-Qa; Wed, 05 Sep 2007 17:20:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IT2IH-0000sJ-Ra for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 17:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT2IH-0000sB-Hm for lemonade@ietf.org; Wed, 05 Sep 2007 17:20:13 -0400 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 1IT2IG-0000cn-Vc for lemonade@ietf.org; Wed, 05 Sep 2007 17:20:13 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Wed, 5 Sep 2007 22:20:08 +0100 Subject: RE: [lemonade] IMAP URLS References: <0a0901c7efee$6acca580$4065f080$%coates@sun.com> <46DF103E.4090106@isode.com> <0a1d01c7effc$af2fa200$0d8ee600$%coates@sun.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <14812.1189027207.355307@peirce.dave.cridland.net> Date: Wed, 05 Sep 2007 22:20:07 +0100 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: d6b246023072368de71562c0ab503126 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 Sep 5 21:45:50 2007, Mark Crispin wrote: > Note that you could accomplish what you want in your example by > CATENATEing literal text with the added headers (but no trailing > CRLF) first, then the rump header from partial fetching. That > would have the effect of putting the added headers before any > Received: lines (which is probably why you didn't do it that way) > but IMHO it is dishonest to change the From: and preserve Received: > lines so I'm not particularly worried about that problem. Indeed, it's not too difficult to do - the typical use-case for this is editing the subject line on a draft, rather than trying to mangle a message with Received headers already present. 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 Thu Sep 06 05:04:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDFm-0001LQ-L8; Thu, 06 Sep 2007 05:02:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ITDFl-0001Kk-OA for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 05:02:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDFl-0001Kc-1Z for lemonade@ietf.org; Thu, 06 Sep 2007 05:02:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITDFk-00032q-Ci for lemonade@ietf.org; Thu, 06 Sep 2007 05:02:20 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8691jHn030610; Thu, 6 Sep 2007 12:02:08 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:01:54 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:01:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Date: Thu, 6 Sep 2007 12:01:12 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157010A8B32@esebe199.NOE.Nokia.com> In-Reply-To: <01ML02AX0B3Y00005F@mauve.mrochek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Thread-Index: Acfv+3ybTJj98KqpQICSo0a4Ibno7QAZv9Xg References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <01ML02AX0B3Y00005F@mauve.mrochek.com> From: To: , X-OriginalArrivalTime: 06 Sep 2007 09:01:50.0581 (UTC) FILETIME=[8FF2FA50:01C7F064] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: randy@qualcomm.com, lemonade@ietf.org, leiba@watson.ibm.com 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, Cyrus, Arnt, I think we all agree Randall does have a valid point - what we disagree = about is the means to deal with the problem. Is this a valid assessment = so far? 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? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Ned Freed [mailto:ned.freed@mrochek.com]=20 >Sent: 05 September, 2007 23:22 >To: Cyrus Daboo >Cc: Ordogh Zoltan (Nokia-TP-MSW/Tampere); randy@qualcomm.com;=20 >lemonade@ietf.org; leiba@watson.ibm.com >Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script > >> Hi, > >> --On September 3, 2007 11:27:30 AM +0300=20 >Zoltan.Ordogh@nokia.com wrote: > >> >> Yes. Each scripts needs to operate independently. >> >> Separately, as an optimization, an implementation could coalesce=20 >> >> multiple notifications to the same address into a single=20 >> >> notification. > >> I think as Zoltan's examples show this is getting way too=20 >complicated. >> Having multiple "competing" scripts being executed like this is a=20 >> recipe for disaster. Lets drop this aspect of the spec and=20 >see whether=20 >> the rest will actually get implemented and be interoperable first.=20 >> Then, if there really is demand, we can consider per-client=20 >scripts as an extension. > >+1 > >I have actually implemented handling of multiple script=20 >handling in the context of delivery processing. There are all=20 >sorts of ways to do it, but the goal has to be that things=20 >manage to work in the way users expect. I eventually arrived=20 >at a result that was remarkably close to the recommendations=20 >Jutta Degener did (she wrote a droaft some time back on how to=20 >handle multiple delivery time sieves). > >However, delivery time processing is a better defined problem=20 >(it is, after all, the place Sieve was deisned to operate) and=20 >there are some simplifying assumptions having to do with=20 >ranking of multiple sieves that I don't think are possible in=20 >the context of IMAP. I therefore support dropping this for now. > > 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 Sep 06 12:00:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJkl-0001KB-D3; Thu, 06 Sep 2007 11:58:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1ITJki-0001Fv-0s for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 11:58:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJkh-0001Fj-Lz; Thu, 06 Sep 2007 11:58:43 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITJkh-0006tk-6M; Thu, 06 Sep 2007 11:58:43 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id B71BCE0FC0; Thu, 6 Sep 2007 08:56:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070906155619.B71BCE0FC0@bosco.isi.edu> Date: Thu, 6 Sep 2007 08:56:19 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] RFC 5032 on WITHIN Search Extension to the IMAP Protocol 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 Request for Comments is now available in online RFC libraries. RFC 5032 Title: WITHIN Search Extension to the IMAP Protocol Author: E. Burger, Ed. Status: Standards Track Date: September 2007 Mailbox: eric.burger@bea.com Pages: 5 Characters: 8921 Updates: RFC3501 See-Also: I-D Tag: draft-ietf-lemonade-search-within-05.txt URL: http://www.rfc-editor.org/rfc/rfc5032.txt This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS TRACK] This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ 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 Sep 17 06:20: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 1IXDig-0000S8-B7; Mon, 17 Sep 2007 06:20:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IXDif-0000Rw-G4 for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 06:20:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDif-0000Rm-4t for lemonade@ietf.org; Mon, 17 Sep 2007 06:20:45 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXDie-0001I6-K6 for lemonade@ietf.org; Mon, 17 Sep 2007 06:20:45 -0400 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, 17 Sep 2007 11:20:41 +0100 Message-ID: <46EE551F.1090103@isode.com> Date: Mon, 17 Sep 2007 11:21:19 +0100 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: Randall Gellens References: 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: b4a0a5f5992e2a4954405484e7717d8c Cc: lemonade@ietf.org Subject: [lemonade] Re: Comments on notify-06 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 Randy, Sorry I've missed this message earlier. Randall Gellens wrote: > ---- > Abstract: > > OLD: > unsolicited notifications > > NEW: > unsolicited notifications for specified mailboxes Ok, changed > ---- > Section 2: > > New sentence to be added to end of first paragraph: > > NEW: > Also, IDLE only applies to the selected mailbox, thus requiring an > additional TCP connection per mailbox. Added. > ---- > Section 3: > > OLD: > If the notification would be prohibitively expensive for the server > (e.g. "notify me of all flag changes in all mailboxes"), the server > MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] > response. > > What does it mean if the notification would be prohibitively expensive > but the server doesn't send a tagged NO with NOTIFICATIONOVERFLOW? > Presumably, if the server sends OK, it means the server will send the > notifications anyway? Yes > Or perhaps the server sends a tagged OK but then sends an untagged > NOTIFICATIONOVERFLOW when it decides it is overloaded? This can happen as well. > Also, I suppose the server could send a BAD or NO without > NOTIFICATIONOVERFLOW. This seems a bit fuzzy. Presumably the idea of > a tagged NO with NOTIFICATIONOVERFLOW is to inform the client that it > should send a simpler request. Something like that. > If so, this should be made more clear. Although, I'm personally not > sure how the client would do so, assuming the original request was > made by seeing which mailboxes the user had specified as interesting. > > ---- > Section 5.10. Notification Overflow > > Similar point as above: what does the client do? Wait a while and > resend the NOTIFY command? Send a simpler 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 Wed Sep 19 15:10: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 1IY4vf-00050z-Fb; Wed, 19 Sep 2007 15:09:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IY4ve-00050t-QL for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 15:09:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4ve-00050l-Du for lemonade@ietf.org; Wed, 19 Sep 2007 15:09:42 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY4vd-0002B5-OJ for lemonade@ietf.org; Wed, 19 Sep 2007 15:09:42 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8JJ9fgG024471 for ; Wed, 19 Sep 2007 19:09:41 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 <0JOM00J01QHT6700@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 19 Sep 2007 13:09:41 -0600 (MDT) Received: from Tundra ([129.150.34.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOM00DIWQK1JJH0@mail-amer.sun.com> for lemonade@ietf.org; Wed, 19 Sep 2007 13:09:38 -0600 (MDT) Date: Wed, 19 Sep 2007 12:09:20 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <009601c7faf0$95cccaf0$95229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf68JTYNWorbC+qRQW16jMyQj1NZQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [lemonade] imap convert (and IMAP URLS and CATENATE) 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 a number of issues with CONVERT. These are mostly to do with error reporting and preflighting. URLs and CATENATE come into play as either part of a solution or having similar issues. There is text in the CATENATE document at the end of section 7.3 that says "Servers MAY refuse to execute a conversion request that converts multiple messages at once, i.e. a conversion request that specifies multiple message numbers/UIDs". Let's look at WHY a server may want to do this. The reason that is presumably in the mind of the author is to do with preflighting, where a client asks for the size of a converted body part then asks for the body itself... the server should cache the result and having the constraint of one conversion at a time really helps there. Now lets look at the HOW. How does the server tell the client about this restriction? The syntax is good, so the response has to be a NO, but I see no obvious resp-text-code to explain the restriction. Suppose the server did not impose this restriction, and the client made the following request: C: e001 CONVERT 2,3 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] BODYPARTSTRUCTURE[2]) Suppose further that body[2] of message 2 was an image/jpeg, but body[2] of message 3 was text/plain, or not present. What is the server supposed to do? Is it supposed to reject the whole command (which required a lot of look ahead)? Is it supposed to return the converted body for message 2, and a CONVERTERROR for message 3? if body[2] does not exist in msgno 3 what should the CONVERTERROR contain? I do not see how this case is handled. Do we use a pseudo mime type of NIL as the from mime type? If at least one message part is successfully converted, i.e. at least one CONVERTED response is returned, then presumably the tagged response has to be OK regardless of any CONVERTERROR responses that may accompany it. Which begs the question as to why we say NO if the all fail. That is not the behaviour of fetch: 1 fetch 1:* body[8] * 1 FETCH (BODY[8] NIL) * 2 FETCH (BODY[8] NIL) * 3 FETCH (BODY[8] NIL) * 4 FETCH (BODY[8] NIL) * 5 FETCH (BODY[8] NIL) * 6 FETCH (BODY[8] NIL) * 7 FETCH (BODY[8] NIL) * 8 FETCH (BODY[8] NIL) * 9 FETCH (BODY[8] NIL) 1 OK Completed Now lets go back to the preflighting, where a client asks for the size then (maybe) the data. The problem here is that the server is expected to cache some results. this is a load on the server that is transparent to the client and an anomaly for the server. I suggest instead that we augment the IMAP URL syntax adding an optional /;convert= part to it and a ;encoding= parameter. Thus if a client wanted the server to perform a conversion but not yet down load the result it could say something along the lines of a append Drafts CATENATE (TEXT {nnn} From: "peter" To: "peter" Subject: Converted Body Date: Wed, 19 Sep 2007 01:01:53 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C7FA98.EC0768B0" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C7FA98.EC0768B0 Content-Type: image/jpeg; name="DSC00317.JPG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DSC00317.JPG" URL "/INBOX/;uid=42/;section=2/;convert=(%22IMAGE/JPG%22%20(%22PIX-X%22%20%22128%22% 20%22PIX-Y%22%20%2296%22))" TEXT {nn} ------=_NextPart_000_0087_01C7FAAA.231A29D0-- ) Then the client can ask for the size of the thing, forward it, etc, etc. If the conversion can not be carried out, then the append command would reply a NO [BADURL /INBOX/... conversion error] [CONVERTERROR ...] Except that a response can only carry one structured response field. We could put the converterror information in the BADURL response, but that has no structure after the URL. Shame it does not have some more structure, eg a NO [BADURL /INBOX/... BADURLSYNTAX ...] a NO [BADURL /INBOX/... BADUID ...] a NO [BADURL /INBOX/... BADSECTION ...] a NO [BADURL /INBOX/... CONVERTERROR ...] Too late to fix that, I suppose. ---------- Trivial point: the syntax of missing-parms in the CONVERTERROR response is as follows missing-params = "MISSINGPARAMETERS" 1*(SP mime type-and-params) mime type-and-params = from-concrete-mime-type SP to-mime-type SP "(" transcoding-params ")" transcoding-params = transcoding-param *(SP transcoding-param) transcoding-param = transcoding-param-name SP transcoding-param-value Presumably if the parameter is missing, then the transcoding-param-value reported in the error response is NIL? eg aa NO [CONVERTERROR MISSINGPARAMETERS text/plain text/plain (charset nil)] Peter _______________________________________________ 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 Sep 19 17:22: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 1IY6zI-0007Yl-Gv; Wed, 19 Sep 2007 17:21:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IY6zG-0007XI-Ph for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 17:21:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6zG-0007Wg-Cn for lemonade@ietf.org; Wed, 19 Sep 2007 17:21:34 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY6zF-0006dP-Ji for lemonade@ietf.org; Wed, 19 Sep 2007 17:21:34 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8JLLXWu017811 for ; Wed, 19 Sep 2007 21:21: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 <0JOM00L01W9WRW00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 19 Sep 2007 15:21:33 -0600 (MDT) Received: from Tundra ([129.150.34.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOM00GYOWNOWPA0@mail-amer.sun.com> for lemonade@ietf.org; Wed, 19 Sep 2007 15:21:26 -0600 (MDT) Date: Wed, 19 Sep 2007 14:21:07 -0700 From: Peter Coates In-reply-to: To: "'Peter Coates'" , lemonade@ietf.org Message-id: <00b301c7fb02$ff55fc00$95229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf68JTYNWorbC+qRQW16jMyQj1NZQAEhOCw References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Subject: [lemonade] RE: imap convert (and IMAP URLS and CATENATE) 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 One point I meant to make in this node, but failed to is that if the CONVERTED response has the form * msgno CONVERTED (tag zzz) ... Then the CONVERTERROR response should also. Peter -----Original Message----- From: Peter Coates [mailto:peter.coates@sun.com] Sent: September 19, 2007 12:09 To: 'lemonade@ietf.org' Subject: imap convert (and IMAP URLS and CATENATE) I have a number of issues with CONVERT. These are mostly to do with error reporting and preflighting. URLs and CATENATE come into play as either part of a solution or having similar issues. There is text in the CATENATE document at the end of section 7.3 that says "Servers MAY refuse to execute a conversion request that converts multiple messages at once, i.e. a conversion request that specifies multiple message numbers/UIDs". Let's look at WHY a server may want to do this. The reason that is presumably in the mind of the author is to do with preflighting, where a client asks for the size of a converted body part then asks for the body itself... the server should cache the result and having the constraint of one conversion at a time really helps there. Now lets look at the HOW. How does the server tell the client about this restriction? The syntax is good, so the response has to be a NO, but I see no obvious resp-text-code to explain the restriction. Suppose the server did not impose this restriction, and the client made the following request: C: e001 CONVERT 2,3 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] BODYPARTSTRUCTURE[2]) Suppose further that body[2] of message 2 was an image/jpeg, but body[2] of message 3 was text/plain, or not present. What is the server supposed to do? Is it supposed to reject the whole command (which required a lot of look ahead)? Is it supposed to return the converted body for message 2, and a CONVERTERROR for message 3? if body[2] does not exist in msgno 3 what should the CONVERTERROR contain? I do not see how this case is handled. Do we use a pseudo mime type of NIL as the from mime type? If at least one message part is successfully converted, i.e. at least one CONVERTED response is returned, then presumably the tagged response has to be OK regardless of any CONVERTERROR responses that may accompany it. Which begs the question as to why we say NO if the all fail. That is not the behaviour of fetch: 1 fetch 1:* body[8] * 1 FETCH (BODY[8] NIL) * 2 FETCH (BODY[8] NIL) * 3 FETCH (BODY[8] NIL) * 4 FETCH (BODY[8] NIL) * 5 FETCH (BODY[8] NIL) * 6 FETCH (BODY[8] NIL) * 7 FETCH (BODY[8] NIL) * 8 FETCH (BODY[8] NIL) * 9 FETCH (BODY[8] NIL) 1 OK Completed Now lets go back to the preflighting, where a client asks for the size then (maybe) the data. The problem here is that the server is expected to cache some results. this is a load on the server that is transparent to the client and an anomaly for the server. I suggest instead that we augment the IMAP URL syntax adding an optional /;convert= part to it and a ;encoding= parameter. Thus if a client wanted the server to perform a conversion but not yet down load the result it could say something along the lines of a append Drafts CATENATE (TEXT {nnn} From: "peter" To: "peter" Subject: Converted Body Date: Wed, 19 Sep 2007 01:01:53 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C7FA98.EC0768B0" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C7FA98.EC0768B0 Content-Type: image/jpeg; name="DSC00317.JPG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DSC00317.JPG" URL "/INBOX/;uid=42/;section=2/;convert=(%22IMAGE/JPG%22%20(%22PIX-X%22%20%22128%22% 20%22PIX-Y%22%20%2296%22))" TEXT {nn} ------=_NextPart_000_0087_01C7FAAA.231A29D0-- ) Then the client can ask for the size of the thing, forward it, etc, etc. If the conversion can not be carried out, then the append command would reply a NO [BADURL /INBOX/... conversion error] [CONVERTERROR ...] Except that a response can only carry one structured response field. We could put the converterror information in the BADURL response, but that has no structure after the URL. Shame it does not have some more structure, eg a NO [BADURL /INBOX/... BADURLSYNTAX ...] a NO [BADURL /INBOX/... BADUID ...] a NO [BADURL /INBOX/... BADSECTION ...] a NO [BADURL /INBOX/... CONVERTERROR ...] Too late to fix that, I suppose. ---------- Trivial point: the syntax of missing-parms in the CONVERTERROR response is as follows missing-params = "MISSINGPARAMETERS" 1*(SP mime type-and-params) mime type-and-params = from-concrete-mime-type SP to-mime-type SP "(" transcoding-params ")" transcoding-params = transcoding-param *(SP transcoding-param) transcoding-param = transcoding-param-name SP transcoding-param-value Presumably if the parameter is missing, then the transcoding-param-value reported in the error response is NIL? eg aa NO [CONVERTERROR MISSINGPARAMETERS text/plain text/plain (charset nil)] Peter _______________________________________________ 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 Sep 19 18:29:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY832-000398-L1; Wed, 19 Sep 2007 18:29:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IY831-00038y-2L for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 18:29:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY830-00038Z-Mj for lemonade@ietf.org; Wed, 19 Sep 2007 18:29:30 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY82z-0000Cz-KG for lemonade@ietf.org; Wed, 19 Sep 2007 18:29:30 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8JMTTCF010633 for ; Wed, 19 Sep 2007 22:29:29 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 <0JOM00I01ZQAOZ00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 19 Sep 2007 16:29:29 -0600 (MDT) Received: from Tundra ([129.150.34.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOM008IKZSW2MC0@mail-amer.sun.com> for lemonade@ietf.org; Wed, 19 Sep 2007 16:29:22 -0600 (MDT) Date: Wed, 19 Sep 2007 15:29:03 -0700 From: Peter Coates In-reply-to: <00b301c7fb02$ff55fc00$95229681@Tundra> To: "'Peter Coates'" , lemonade@ietf.org Message-id: <00d901c7fb0c$7caf48b0$95229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf68JTYNWorbC+qRQW16jMyQj1NZQAEhOCwAAImOYA= References: <00b301c7fb02$ff55fc00$95229681@Tundra> X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Subject: [lemonade] RE: imap convert (and IMAP URLS and CATENATE) 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 Another point about convert. The syntax allows for insane commands like e001 CONVERT 2:* (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] BODYPARTSTRUCTURE[1]) There are two insanities about this command. First the idea that I might want the same conversion on the nth body part in multiple messages is a joke. Secondly the idea that I might want the BINARY of a particular conversion of one part and the body structure from applying that conversion to another part is not even funny. Ignoring the multiple messages part of this, this tells me that there is something fishy about the syntax of the command. (1) it allows me to do something absurd (2) it wastes bandwidth having me specify the same thing twice. What the client really wants to specify is a body part in a message and what data it wants back. The command should perhaps look more like e001 CONVERT 2[1.1] (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY BODYPARTSTRUCTURE) While were at it, what do all these parentheses achieve for us? Why could the command not look like e001 CONVERT 2[1.1] (NIL "PIX-X" "128" "PIX-Y" "96") BINARY BODYPARTSTRUCTURE Peter -----Original Message----- From: Anthony.Coates@Sun.COM [mailto:Anthony.Coates@Sun.COM] On Behalf Of Peter Coates Sent: September 19, 2007 14:21 To: 'Peter Coates'; lemonade@ietf.org Subject: RE: imap convert (and IMAP URLS and CATENATE) One point I meant to make in this node, but failed to is that if the CONVERTED response has the form * msgno CONVERTED (tag zzz) ... Then the CONVERTERROR response should also. Peter -----Original Message----- From: Peter Coates [mailto:peter.coates@sun.com] Sent: September 19, 2007 12:09 To: 'lemonade@ietf.org' Subject: imap convert (and IMAP URLS and CATENATE) I have a number of issues with CONVERT. These are mostly to do with error reporting and preflighting. URLs and CATENATE come into play as either part of a solution or having similar issues. There is text in the CATENATE document at the end of section 7.3 that says "Servers MAY refuse to execute a conversion request that converts multiple messages at once, i.e. a conversion request that specifies multiple message numbers/UIDs". Let's look at WHY a server may want to do this. The reason that is presumably in the mind of the author is to do with preflighting, where a client asks for the size of a converted body part then asks for the body itself... the server should cache the result and having the constraint of one conversion at a time really helps there. Now lets look at the HOW. How does the server tell the client about this restriction? The syntax is good, so the response has to be a NO, but I see no obvious resp-text-code to explain the restriction. Suppose the server did not impose this restriction, and the client made the following request: C: e001 CONVERT 2,3 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] BODYPARTSTRUCTURE[2]) Suppose further that body[2] of message 2 was an image/jpeg, but body[2] of message 3 was text/plain, or not present. What is the server supposed to do? Is it supposed to reject the whole command (which required a lot of look ahead)? Is it supposed to return the converted body for message 2, and a CONVERTERROR for message 3? if body[2] does not exist in msgno 3 what should the CONVERTERROR contain? I do not see how this case is handled. Do we use a pseudo mime type of NIL as the from mime type? If at least one message part is successfully converted, i.e. at least one CONVERTED response is returned, then presumably the tagged response has to be OK regardless of any CONVERTERROR responses that may accompany it. Which begs the question as to why we say NO if the all fail. That is not the behaviour of fetch: 1 fetch 1:* body[8] * 1 FETCH (BODY[8] NIL) * 2 FETCH (BODY[8] NIL) * 3 FETCH (BODY[8] NIL) * 4 FETCH (BODY[8] NIL) * 5 FETCH (BODY[8] NIL) * 6 FETCH (BODY[8] NIL) * 7 FETCH (BODY[8] NIL) * 8 FETCH (BODY[8] NIL) * 9 FETCH (BODY[8] NIL) 1 OK Completed Now lets go back to the preflighting, where a client asks for the size then (maybe) the data. The problem here is that the server is expected to cache some results. this is a load on the server that is transparent to the client and an anomaly for the server. I suggest instead that we augment the IMAP URL syntax adding an optional /;convert= part to it and a ;encoding= parameter. Thus if a client wanted the server to perform a conversion but not yet down load the result it could say something along the lines of a append Drafts CATENATE (TEXT {nnn} From: "peter" To: "peter" Subject: Converted Body Date: Wed, 19 Sep 2007 01:01:53 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C7FA98.EC0768B0" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C7FA98.EC0768B0 Content-Type: image/jpeg; name="DSC00317.JPG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DSC00317.JPG" URL "/INBOX/;uid=42/;section=2/;convert=(%22IMAGE/JPG%22%20(%22PIX-X%22%20%22128%22% 20%22PIX-Y%22%20%2296%22))" TEXT {nn} ------=_NextPart_000_0087_01C7FAAA.231A29D0-- ) Then the client can ask for the size of the thing, forward it, etc, etc. If the conversion can not be carried out, then the append command would reply a NO [BADURL /INBOX/... conversion error] [CONVERTERROR ...] Except that a response can only carry one structured response field. We could put the converterror information in the BADURL response, but that has no structure after the URL. Shame it does not have some more structure, eg a NO [BADURL /INBOX/... BADURLSYNTAX ...] a NO [BADURL /INBOX/... BADUID ...] a NO [BADURL /INBOX/... BADSECTION ...] a NO [BADURL /INBOX/... CONVERTERROR ...] Too late to fix that, I suppose. ---------- Trivial point: the syntax of missing-parms in the CONVERTERROR response is as follows missing-params = "MISSINGPARAMETERS" 1*(SP mime type-and-params) mime type-and-params = from-concrete-mime-type SP to-mime-type SP "(" transcoding-params ")" transcoding-params = transcoding-param *(SP transcoding-param) transcoding-param = transcoding-param-name SP transcoding-param-value Presumably if the parameter is missing, then the transcoding-param-value reported in the error response is NIL? eg aa NO [CONVERTERROR MISSINGPARAMETERS text/plain text/plain (charset nil)] Peter _______________________________________________ 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 Sep 20 05:42:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIWx-0002s3-Uu; Thu, 20 Sep 2007 05:41:07 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IYIWw-0002qQ-7k for lemonade-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 05:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIWv-0002qH-RU for lemonade@ietf.org; Thu, 20 Sep 2007 05:41:05 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYIWn-0007h1-4I for lemonade@ietf.org; Thu, 20 Sep 2007 05:41:05 -0400 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, 20 Sep 2007 10:40:52 +0100 Message-ID: <46F19806.4080800@isode.com> Date: Wed, 19 Sep 2007 22:43:34 +0100 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] imap convert (and IMAP URLS and CATENATE) References: <009601c7faf0$95cccaf0$95229681@Tundra> In-Reply-To: <009601c7faf0$95cccaf0$95229681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 Peter Coates wrote: >I have a number of issues with CONVERT. These are mostly to do with error >reporting and preflighting. URLs and CATENATE come into play as either part of >a solution or having similar issues. > >There is text in the CATENATE document at the end of section 7.3 that says >"Servers MAY refuse to execute a conversion request that converts multiple >messages at once, i.e. a conversion request that specifies multiple message >numbers/UIDs". > >Let's look at WHY a server may want to do this. The reason that is presumably >in the mind of the author is to do with preflighting, where a client asks for >the size of a converted body part then asks for the body itself... the server >should cache the result and having the constraint of one conversion at a time >really helps there. > >Now lets look at the HOW. How does the server tell the client about this >restriction? The syntax is good, so the response has to be a NO, but I see no >obvious resp-text-code to explain the restriction. > > Right. In my [unpublished] revision 12 I've added a new subresponse of the CONVERTERROR response: TOOMANYCONVERSIONS - the request has specified conversion of multiple messages or body parts. This would result in a need to store multiple converted messages and the number of converted messages exceeds the maximum number supported by the server or allowed by its policy. Now, I wasn't sure that this is actually needed. The main reason is that I don't think that the server needs to cache more than one converted part at any given time. Even if the client has requested conversions of multiple bodyparts, the server can perform conversion 1, then immediately return it to the client, then perform conversion 2, then return it to the client, etc. >Suppose the server did not impose this restriction, and the client made the >following request: > > C: e001 CONVERT 2,3 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] > BODYPARTSTRUCTURE[2]) > >Suppose further that body[2] of message 2 was an image/jpeg, but body[2] of >message 3 was text/plain, or not present. What is the server supposed to do? >Is it supposed to reject the whole command (which required a lot of look ahead)? > > No, this wasn't the intent. >Is it supposed to return the converted body for message 2, and a CONVERTERROR >for message 3? > Yes. Now, CONVERTERROR doesn't contain any message number, but this can be easily added. >if body[2] does not exist in msgno 3 what should the >CONVERTERROR contain? > BADPARAMETERS, i.e. the source MIME type can't be converted to the destination MIME type. >I do not see how this case is handled. Do we use a pseudo mime type of NIL as the from mime type? > > Yes, this would work (I would need to extend syntax to allow for that) >If at least one message part is successfully converted, i.e. at least one >CONVERTED response is returned, then presumably the tagged response has to be OK >regardless of any CONVERTERROR responses that may accompany it. Which begs the >question as to why we say NO if the all fail. > I don't think this would make much practical difference for clients. They need to handle the tagged NO, as well as tagged OK + untagged CONVERTERROR. >That is not the behaviour of >fetch: >1 fetch 1:* body[8] >* 1 FETCH (BODY[8] NIL) >* 2 FETCH (BODY[8] NIL) >* 3 FETCH (BODY[8] NIL) >* 4 FETCH (BODY[8] NIL) >* 5 FETCH (BODY[8] NIL) >* 6 FETCH (BODY[8] NIL) >* 7 FETCH (BODY[8] NIL) >* 8 FETCH (BODY[8] NIL) >* 9 FETCH (BODY[8] NIL) >1 OK Completed > >Now lets go back to the preflighting, where a client asks for the size then >(maybe) the data. The problem here is that the server is expected to cache some >results. this is a load on the server that is transparent to the client and an >anomaly for the server. I suggest instead that we augment the IMAP URL syntax >adding an optional /;convert= part to it > I think you've missed section 9.1 in revision 11, it already contains something like this. >and a ;encoding= parameter. > This would convey Content-Transfer-Encoding, right? > Thus if a >client wanted the server to perform a conversion but not yet down load the >result it could say something along the lines of > >a append Drafts CATENATE (TEXT {nnn} >From: "peter" >To: "peter" >Subject: Converted Body >Date: Wed, 19 Sep 2007 01:01:53 -0700 >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_0033_01C7FA98.EC0768B0" > >This is a multi-part message in MIME format. > >------=_NextPart_000_0033_01C7FA98.EC0768B0 >Content-Type: image/jpeg; > name="DSC00317.JPG" >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; > filename="DSC00317.JPG" > >URL >"/INBOX/;uid=42/;section=2/;convert=(%22IMAGE/JPG%22%20(%22PIX-X%22%20%22128%22% >20%22PIX-Y%22%20%2296%22))" TEXT {nn} > >------=_NextPart_000_0087_01C7FAAA.231A29D0-- >) > >Then the client can ask for the size of the thing, forward it, etc, etc. >If the conversion can not be carried out, then the append command would reply >a NO [BADURL /INBOX/... conversion error] [CONVERTERROR ...] > >Except that a response can only carry one structured response field. We could >put the converterror information in the BADURL response, but that has no >structure after the URL. Shame it does not have some more structure, eg > >a NO [BADURL /INBOX/... BADURLSYNTAX ...] >a NO [BADURL /INBOX/... BADUID ...] >a NO [BADURL /INBOX/... BADSECTION ...] >a NO [BADURL /INBOX/... CONVERTERROR ...] > >Too late to fix that, I suppose. > > This would be doable, if we create a new response code or extend existing one. As long as the new response code is optional, it can be included in CATENATEbis. >---------- > >Trivial point: the syntax of missing-parms in the CONVERTERROR response is as >follows > > missing-params = "MISSINGPARAMETERS" > 1*(SP mimetype-and-params) > > mimetype-and-params = from-concrete-mime-type SP to-mime-type > SP "(" transcoding-params ")" > > transcoding-params = transcoding-param > *(SP transcoding-param) > > transcoding-param = transcoding-param-name SP > transcoding-param-value > >Presumably if the parameter is missing, then the transcoding-param-value >reported in the error response is NIL? > > Thanks for spotting this. >eg >aa NO [CONVERTERROR MISSINGPARAMETERS text/plain text/plain (charset nil)] > > No, the transcoding-params should be optional, the same way as it is optional in the request: mimetype-and-params = from-concrete-mime-type SP to-mime-type [SP "(" transcoding-params ")"] _______________________________________________ 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 Sep 20 12:53:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPGn-0004PR-Pn; Thu, 20 Sep 2007 12:52:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IYPGn-0004Ly-0d for lemonade-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 12:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPGm-0004Ld-MV for lemonade@ietf.org; Thu, 20 Sep 2007 12:52:52 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYPGg-00032G-4q for lemonade@ietf.org; Thu, 20 Sep 2007 12:52:52 -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 l8KGqZFF024932 for ; Thu, 20 Sep 2007 16:52:35 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 <0JOO00J01DGOVU00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Thu, 20 Sep 2007 10:52:35 -0600 (MDT) Received: from Tundra ([129.150.37.52]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOO00LDFEVCFM30@mail-amer.sun.com>; Thu, 20 Sep 2007 10:52:25 -0600 (MDT) Date: Thu, 20 Sep 2007 09:52:05 -0700 From: Peter Coates To: "'Alexey Melnikov'" , lemonade@ietf.org Message-id: <01a901c7fba6$940f92e0$95229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf7ppLoZloaVlkDSPKMMRnXH0rrMA== X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: Subject: [lemonade] More on CONVERT 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 _______________________________________________ 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 Sep 20 13:14: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 1IYPbR-00062g-Gm; Thu, 20 Sep 2007 13:14:13 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IYPbP-0005xN-Ps for lemonade-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 13:14:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPbP-0005xD-G7 for lemonade@ietf.org; Thu, 20 Sep 2007 13:14:11 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYPbI-0003cu-Td for lemonade@ietf.org; Thu, 20 Sep 2007 13:14:11 -0400 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 l8KHDt7f016204 for ; Thu, 20 Sep 2007 17:13:55 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 <0JOO00201FJXRY00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Thu, 20 Sep 2007 11:13:55 -0600 (MDT) Received: from Tundra ([129.150.37.52]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOO00H08FUT6600@mail-amer.sun.com>; Thu, 20 Sep 2007 11:13:43 -0600 (MDT) Date: Thu, 20 Sep 2007 10:13:21 -0700 From: Peter Coates In-reply-to: To: "'Peter Coates'" , "'Alexey Melnikov'" , lemonade@ietf.org Message-id: <000801c7fba9$8d5ee600$34259681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acf7ppLoZloaVlkDSPKMMRnXH0rrMAAAuuew References: X-Spam-Score: -1.0 (-) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [lemonade] RE: More on CONVERT 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="===============0150933840==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0150933840== Content-type: multipart/alternative; boundary="Boundary_(ID_/nRmnApjnERcY3rmegvP6A)" This is a multi-part message in MIME format. --Boundary_(ID_/nRmnApjnERcY3rmegvP6A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Twice outlook just ate my text. CONVERTERROR needs to carry descriptive text. there may be several failures and even some successes all in the same command. the tagged NO is not the place for the error text. The original message had examples and reasoning. but once is enough. Peter _____ From: Peter Coates [mailto:peter.coates@sun.com] Sent: September 20, 2007 09:52 To: 'Alexey Melnikov'; 'lemonade@ietf.org' Subject: More on CONVERT --Boundary_(ID_/nRmnApjnERcY3rmegvP6A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Twice outlook just ate my text.

CONVERTERROR needs to carry descriptive text.  there may be several failures and even some successes all in the same command.  the tagged NO is not the place for the error text.

The original message had examples and reasoning.  but once is enough.

Peter


From: Peter Coates [mailto:peter.coates@sun.com]
Sent: September 20, 2007 09:52
To: 'Alexey Melnikov'; 'lemonade@ietf.org'
Subject: More on CONVERT

--Boundary_(ID_/nRmnApjnERcY3rmegvP6A)-- --===============0150933840== 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 --===============0150933840==-- From lemonade-bounces@ietf.org Fri Sep 21 01:59:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYbXP-0003PA-0r; Fri, 21 Sep 2007 01:58:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IYbXN-0003Ok-Id for lemonade-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 01:58:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYbXM-0002yF-PB for lemonade@ietf.org; Fri, 21 Sep 2007 01:58:48 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYbWg-0000ZV-On for lemonade@ietf.org; Fri, 21 Sep 2007 01:58:07 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8L5w5cZ017372 for ; Fri, 21 Sep 2007 05:58:05 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 <0JOP00A01F354Y00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Thu, 20 Sep 2007 23:58:05 -0600 (MDT) Received: from Tundra ([129.150.37.52]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOP00ANKF8OJZA0@mail-amer.sun.com> for lemonade@ietf.org; Thu, 20 Sep 2007 23:58:05 -0600 (MDT) Date: Thu, 20 Sep 2007 22:57:39 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <010c01c7fc14$54a148b0$34259681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acf8FFD+djE2boU3RRyWn/2vUWWKPA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [lemonade] convert URLs 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="===============1409732028==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1409732028== Content-type: multipart/alternative; boundary="Boundary_(ID_0v2fT+ndjPkHK+cUu56I+g)" This is a multi-part message in MIME format. --Boundary_(ID_0v2fT+ndjPkHK+cUu56I+g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I'm feeling a bit more confident I understand this CONVERT stuff now that I have implemented the CONVERT command at least for charset conversions of text/xxx parts. Moving on the section 9.1 of the document, tucked away after the formal syntax. These URLs are used in a couple of places. URLFETCH and CATENATE. In both places we have to consider what the encoding of the converted parts should be. I'd be perfectly happy to assert that if a client is capable of issuing a URLFETCH with a CONVERT in it, then it is perfectly capable of handling binary data coming down the pike at it. But CATENATE is a different story. CATENATE is used to construct messages that may be intended for transmission to another user with a potentially less capable client. just marking the bodies as encoding=8bit may not be the answer. it could be asserted that the server has the best idea what sort of encoding is suitable for the converted bodypart, but that doesn't help as the poor client has to construct the headers to go round it. SO, it has to be up to the client to specify the encoding. So the syntax in section 9.1 has to be extended so it can specify the encoding. At least that is my reasoning. And I could be quite wrong. Peter --Boundary_(ID_0v2fT+ndjPkHK+cUu56I+g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
I'm feeling a bit more confident I understand this CONVERT stuff now that I have implemented the CONVERT command at least for charset conversions of text/xxx parts.
 
Moving on the section 9.1 of the document, tucked away after the formal syntax.
 
These URLs are used in a couple of places.  URLFETCH and CATENATE.  In both places we have to consider what the encoding of the converted parts should be. 
I'd be perfectly happy to assert that if a client is capable of issuing a URLFETCH with a CONVERT in it, then it is perfectly capable of handling binary data coming down the pike at it. 
But CATENATE is a different story.  CATENATE is used to construct messages that may be intended for transmission to another user with a potentially less capable client.  just marking the bodies as encoding=8bit may not be the answer.  it could be asserted that the server has the best idea what sort of encoding is suitable for the converted bodypart, but that doesn't help as the poor client has to construct the headers to go round it.  SO, it has to be up to the client to specify the encoding.  So the syntax in section 9.1 has to be extended so it can specify the encoding.
 
At least that is my reasoning.  And I could be quite wrong.
 
Peter
--Boundary_(ID_0v2fT+ndjPkHK+cUu56I+g)-- --===============1409732028== 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 --===============1409732028==-- From lemonade-bounces@ietf.org Fri Sep 21 08:14: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 1IYhOb-0002mk-5Z; Fri, 21 Sep 2007 08:14:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IYhOZ-0002jf-LG for lemonade-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 08:14:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhOZ-0002hX-4j for lemonade@ietf.org; Fri, 21 Sep 2007 08:14:07 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYhOY-00015N-6T for lemonade@ietf.org; Fri, 21 Sep 2007 08:14:06 -0400 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 l8LCE5Y8000962 for ; Fri, 21 Sep 2007 12:14:05 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 <0JOP00C01WMFW300@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 21 Sep 2007 06:14:05 -0600 (MDT) Received: from Tundra ([129.150.32.193]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOP005G8WNCVC20@mail-amer.sun.com>; Fri, 21 Sep 2007 06:14:02 -0600 (MDT) Date: Fri, 21 Sep 2007 05:13:39 -0700 From: Peter Coates To: lemonade@ietf.org, "'Alexey Melnikov'" Message-id: <012e01c7fc48$d94e9840$34259681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acf8SNfIh2WXeVdyTuSS0JkvttduJA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [lemonade] more on CONVERTERROR response 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="===============0444132488==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0444132488== Content-type: multipart/alternative; boundary="Boundary_(ID_89dy7g7Aob/RF5mfwI6qsg)" This is a multi-part message in MIME format. --Boundary_(ID_89dy7g7Aob/RF5mfwI6qsg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT IF we agree that the CONVERTERROR untagged response is the place to put the descriptive text that in -11 of the CONVERT draft goes on the tagged NO, the the syntax of the CONVERTERROR response has to be better defined. At the moment it I have it always start * msgno CONVERTERROR (tag "tag") This is followed either by MISSINGPARAMETER from-type to-type ("missingparameter") descriptive text or BADPARAMETER from-type to-type descriptive text or BADPARAMETER from-type to-type ("parameter" "badvalue") descriptive text This is going to be hard to parse. Can I suggest that the structured part of the response goes inside [...] thus: * msgno CONVERTERROR (tag "tag") [MISSINGPARAMETER from-type to-type ("missingparameter")] descriptive text * msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type] descriptive text * msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type ("parameter" "badvalue")] descriptive text Also, note that I'm assuming that no parameters should be passed back in the BADPARAMETER part unless that parameter was in error. And I'm ignoring PARAMETERS I don't need/recognise. I suspect that is wrong... Peter --Boundary_(ID_89dy7g7Aob/RF5mfwI6qsg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
IF we agree that the CONVERTERROR untagged response is the place to put the descriptive text that in -11 of the CONVERT draft goes on the tagged NO, the the syntax of the CONVERTERROR response has to be better defined.
 
At the moment it I have it always start
* msgno CONVERTERROR (tag "tag")
This is followed either by
MISSINGPARAMETER from-type to-type ("missingparameter") descriptive text
or
BADPARAMETER from-type to-type descriptive text
or
BADPARAMETER from-type to-type ("parameter" "badvalue") descriptive text
 
This is going to be hard to parse.  Can I suggest that the structured part of the response goes inside [...] thus:
 
* msgno CONVERTERROR (tag "tag") [MISSINGPARAMETER from-type to-type ("missingparameter")] descriptive text
* msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type] descriptive text
* msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type ("parameter" "badvalue")] descriptive text
 
Also, note that I'm assuming that no parameters should be passed back in the BADPARAMETER part unless that parameter was in error.
 
And I'm ignoring PARAMETERS I don't need/recognise.  I suspect that is wrong...
 
Peter
--Boundary_(ID_89dy7g7Aob/RF5mfwI6qsg)-- --===============0444132488== 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 --===============0444132488==-- From lemonade-bounces@ietf.org Fri Sep 21 13:16: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 1IYm6V-0000Nr-4I; Fri, 21 Sep 2007 13:15:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IYm6I-00006y-8C for lemonade-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 13:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm6H-0008Vj-OG; Fri, 21 Sep 2007 13:15:33 -0400 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYm6G-0007nQ-Hk; Fri, 21 Sep 2007 13:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3AA1026E7E; Fri, 21 Sep 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IYm5m-0006pu-30; Fri, 21 Sep 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Sep 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-streaming-03.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 : Streaming Internet Messaging Attachments Author(s) : N. Cook Filename : draft-ietf-lemonade-streaming-03.txt Pages : 31 Date : 2007-9-21 This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 4722). The document also defines a new IMAP METADATA entry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-03.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-streaming-03.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-streaming-03.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-9-21123534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-streaming-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-streaming-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-21123534.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 Sep 23 09:45: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 1IZRkZ-0001hx-2E; Sun, 23 Sep 2007 09:43:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkX-0001hr-Cw for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkX-0001gg-1K for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:53 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRkW-00079W-Dg for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:52 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:50 +0100 Message-ID: <46F64238.3090509@isode.com> Date: Sun, 23 Sep 2007 11:38:48 +0100 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] RE: imap convert (and IMAP URLS and CATENATE) References: <00b301c7fb02$ff55fc00$95229681@Tundra> <00d901c7fb0c$7caf48b0$95229681@Tundra> In-Reply-To: <00d901c7fb0c$7caf48b0$95229681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Peter Coates wrote: >Another point about convert. The syntax allows for insane commands like > >e001 CONVERT 2:* (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] >BODYPARTSTRUCTURE[1]) > >There are two insanities about this command. First the idea that I might want >the same conversion on the nth body part in multiple messages is a joke. >Secondly the idea that I might want the BINARY of a particular conversion of one >part and the body structure from applying that conversion to another part is not >even funny. > >Ignoring the multiple messages part of this, this tells me that there is >something fishy about the syntax of the command. >(1) it allows me to do something absurd >(2) it wastes bandwidth having me specify the same thing twice. > >What the client really wants to specify is a body part in a message and what >data it wants back. The command should perhaps look more like > >e001 CONVERT 2[1.1] (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY >BODYPARTSTRUCTURE) > > This would make the CONVERT command syntax unnecessarily different from the FETCH command syntax. (They are already slightly different, but this would make it even more different). So before changing the document I would need to hear at least one more voice in favor of this change. >While were at it, what do all these parentheses achieve for us? > Possible extensibility of the CONVERT command in the future. >Why could the command not look like > >e001 CONVERT 2[1.1] (NIL "PIX-X" "128" "PIX-Y" "96") BINARY BODYPARTSTRUCTURE > > _______________________________________________ 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 Sep 23 09:45: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 1IZRkZ-0001hx-2E; Sun, 23 Sep 2007 09:43:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkX-0001hr-Cw for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkX-0001gg-1K for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:53 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRkW-00079W-Dg for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:52 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:50 +0100 Message-ID: <46F64238.3090509@isode.com> Date: Sun, 23 Sep 2007 11:38:48 +0100 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] RE: imap convert (and IMAP URLS and CATENATE) References: <00b301c7fb02$ff55fc00$95229681@Tundra> <00d901c7fb0c$7caf48b0$95229681@Tundra> In-Reply-To: <00d901c7fb0c$7caf48b0$95229681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Peter Coates wrote: >Another point about convert. The syntax allows for insane commands like > >e001 CONVERT 2:* (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] >BODYPARTSTRUCTURE[1]) > >There are two insanities about this command. First the idea that I might want >the same conversion on the nth body part in multiple messages is a joke. >Secondly the idea that I might want the BINARY of a particular conversion of one >part and the body structure from applying that conversion to another part is not >even funny. > >Ignoring the multiple messages part of this, this tells me that there is >something fishy about the syntax of the command. >(1) it allows me to do something absurd >(2) it wastes bandwidth having me specify the same thing twice. > >What the client really wants to specify is a body part in a message and what >data it wants back. The command should perhaps look more like > >e001 CONVERT 2[1.1] (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY >BODYPARTSTRUCTURE) > > This would make the CONVERT command syntax unnecessarily different from the FETCH command syntax. (They are already slightly different, but this would make it even more different). So before changing the document I would need to hear at least one more voice in favor of this change. >While were at it, what do all these parentheses achieve for us? > Possible extensibility of the CONVERT command in the future. >Why could the command not look like > >e001 CONVERT 2[1.1] (NIL "PIX-X" "128" "PIX-Y" "96") BINARY BODYPARTSTRUCTURE > > _______________________________________________ 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 Sep 23 09:45: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 1IZRkP-0001ez-IT; Sun, 23 Sep 2007 09:43:45 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkO-0001eo-PV for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkO-0001eW-Bz for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:44 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRkN-00079K-SH for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:44 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:37 +0100 Message-ID: <46F59663.8020805@isode.com> Date: Sat, 22 Sep 2007 23:25:39 +0100 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 References: <012e01c7fc48$d94e9840$34259681@Tundra> In-Reply-To: <012e01c7fc48$d94e9840$34259681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org Subject: [lemonade] Re: more on CONVERTERROR response 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: > Also, note that I'm assuming that no parameters should be passed back > in the BADPARAMETER part unless that parameter was in error. Yes, this needs to be clarified in the draft. > And I'm ignoring PARAMETERS I don't need/recognise. I suspect that is > wrong... Yes, it is. You should be returning BADPARAMETER instead. _______________________________________________ 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 Sep 23 09:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=sti edprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkP-0001ez-IT; Sun, 23 Sep 2007 09:43:45 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkO-0001eo-PV for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkO-0001eW-Bz for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:44 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRkN-00079K-SH for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:44 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:37 +0100 Message-ID: <46F59663.8020805@isode.com> Date: Sat, 22 Sep 2007 23:25:39 +0100 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 References: <012e01c7fc48$d94e9840$34259681@Tundra> In-Reply-To: <012e01c7fc48$d94e9840$34259681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org Subject: [lemonade] Re: more on CONVERTERROR response 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: > Also, note that I'm assuming that no parameters should be passed back > in the BADPARAMETER part unless that parameter was in error. Yes, this needs to be clarified in the draft. > And I'm ignoring PARAMETERS I don't need/recognise. I suspect that is > wrong... Yes, it is. You should be returning BADPARAMETER instead. _______________________________________________ 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 Sep 23 09:45: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 1IZRkU-0001fr-NE; Sun, 23 Sep 2007 09:43:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkT-0001fl-Uf for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkT-0001fd-LC for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:49 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZRkS-0007bX-D4 for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:49 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:46 +0100 Message-ID: <46F59CA1.4000809@isode.com> Date: Sat, 22 Sep 2007 23:52:17 +0100 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] RE: imap convert (and IMAP URLS and CATENATE) References: <00b301c7fb02$ff55fc00$95229681@Tundra> In-Reply-To: <00b301c7fb02$ff55fc00$95229681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Peter Coates wrote: >One point I meant to make in this node, but failed to is that if the CONVERTED >response has the form >* msgno CONVERTED (tag zzz) ... >Then the CONVERTERROR response should also. > > I like this. _______________________________________________ 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 Sep 23 09:45: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 1IZRkW-0001gB-Rg; Sun, 23 Sep 2007 09:43:52 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkV-0001g5-Fc for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkV-0001fw-3y for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRkU-00079R-Gd for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:50 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:48 +0100 Message-ID: <46F63F88.1080801@isode.com> Date: Sun, 23 Sep 2007 11:27:20 +0100 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 References: <012e01c7fc48$d94e9840$34259681@Tundra> In-Reply-To: <012e01c7fc48$d94e9840$34259681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lemonade@ietf.org Subject: [lemonade] Re: more on CONVERTERROR response 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: > IF we agree that the CONVERTERROR untagged response is the place to > put the descriptive text I think so. > that in -11 of the CONVERT draft goes on the tagged NO, CONVERTERROR is an untagged response, not a response code anymore. So it is not returned in the tagged NO. > the the syntax of the CONVERTERROR response has to be better defined. > > At the moment it I have it always start > * msgno CONVERTERROR (tag "tag") > This is followed either by > MISSINGPARAMETER from-type to-type ("missingparameter") descriptive text > or > BADPARAMETER from-type to-type descriptive text > or > BADPARAMETER from-type to-type ("parameter" "badvalue") descriptive text > > This is going to be hard to parse. Can I suggest that the structured > part of the response goes inside [...] thus: > > * msgno CONVERTERROR (tag "tag") [MISSINGPARAMETER from-type to-type > ("missingparameter")] descriptive text > * msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type] > descriptive text > * msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type > ("parameter" "badvalue")] descriptive text IMAP usually uses () for grouping, so I've used () instead of []. Note that I've also changed syntax of from-type and to-type to be quoted strings, for consistency with the CONVERT request itself. Example: C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3] S: * 2 CONVERTERROR (TAG "b001") (BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii")) "Source text has non us-ascii" S: b001 NO Conversion request failed _______________________________________________ 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 Sep 23 09:45: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 1IZRkU-0001fr-NE; Sun, 23 Sep 2007 09:43:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkT-0001fl-Uf for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkT-0001fd-LC for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:49 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZRkS-0007bX-D4 for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:49 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:46 +0100 Message-ID: <46F59CA1.4000809@isode.com> Date: Sat, 22 Sep 2007 23:52:17 +0100 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] RE: imap convert (and IMAP URLS and CATENATE) References: <00b301c7fb02$ff55fc00$95229681@Tundra> In-Reply-To: <00b301c7fb02$ff55fc00$95229681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Peter Coates wrote: >One point I meant to make in this node, but failed to is that if the CONVERTED >response has the form >* msgno CONVERTED (tag zzz) ... >Then the CONVERTERROR response should also. > > I like this. _______________________________________________ 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 Sep 23 09:45: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 1IZRkW-0001gB-Rg; Sun, 23 Sep 2007 09:43:52 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZRkV-0001g5-Fc for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 09:43:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRkV-0001fw-3y for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRkU-00079R-Gd for lemonade@ietf.org; Sun, 23 Sep 2007 09:43:50 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:48 +0100 Message-ID: <46F63F88.1080801@isode.com> Date: Sun, 23 Sep 2007 11:27:20 +0100 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 References: <012e01c7fc48$d94e9840$34259681@Tundra> In-Reply-To: <012e01c7fc48$d94e9840$34259681@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lemonade@ietf.org Subject: [lemonade] Re: more on CONVERTERROR response 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: > IF we agree that the CONVERTERROR untagged response is the place to > put the descriptive text I think so. > that in -11 of the CONVERT draft goes on the tagged NO, CONVERTERROR is an untagged response, not a response code anymore. So it is not returned in the tagged NO. > the the syntax of the CONVERTERROR response has to be better defined. > > At the moment it I have it always start > * msgno CONVERTERROR (tag "tag") > This is followed either by > MISSINGPARAMETER from-type to-type ("missingparameter") descriptive text > or > BADPARAMETER from-type to-type descriptive text > or > BADPARAMETER from-type to-type ("parameter" "badvalue") descriptive text > > This is going to be hard to parse. Can I suggest that the structured > part of the response goes inside [...] thus: > > * msgno CONVERTERROR (tag "tag") [MISSINGPARAMETER from-type to-type > ("missingparameter")] descriptive text > * msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type] > descriptive text > * msgno CONVERTERROR (tag "tag") [BADPARAMETER from-type to-type > ("parameter" "badvalue")] descriptive text IMAP usually uses () for grouping, so I've used () instead of []. Note that I've also changed syntax of from-type and to-type to be quoted strings, for consistency with the CONVERT request itself. Example: C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3] S: * 2 CONVERTERROR (TAG "b001") (BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii")) "Source text has non us-ascii" S: b001 NO Conversion request failed _______________________________________________ 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 Sep 24 07:35:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZmCP-0007Ft-4M; Mon, 24 Sep 2007 07:34:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZmCO-0007ES-MB for lemonade-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 07:34:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZmCO-0007EE-AD for lemonade@ietf.org; Mon, 24 Sep 2007 07:34:00 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZmCN-0006AV-Nl for lemonade@ietf.org; Mon, 24 Sep 2007 07:34:00 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5DE3E4ACB2; Mon, 24 Sep 2007 13:33:58 +0200 (CEST) Message-Id: Date: Mon, 24 Sep 2007 13:35:55 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <20070921222103.F334EE3E83@bosco.isi.edu> In-Reply-To: <20070921222103.F334EE3E83@bosco.isi.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response 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 rfc-editor@rfc-editor.org writes: > A new Request for Comments is now available in online RFC libraries. > > RFC 4959 Lemonade blocks on this, right? Well, it's published. 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 Sep 24 11:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpwQ-0008Ok-Rs; Mon, 24 Sep 2007 11:33:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZpwP-0008Of-Ry for lemonade-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 11:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpwP-0008NJ-IT for lemonade@ietf.org; Mon, 24 Sep 2007 11:33:45 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZpwG-0002Yd-Av for lemonade@ietf.org; Mon, 24 Sep 2007 11:33:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l8OFXG5i001117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Sep 2007 08:33:16 -0700 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 l8OFX53c018886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Sep 2007 08:33:15 -0700 Date: Mon, 24 Sep 2007 08:33:04 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> 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.9.24.80030 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_500_599 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' X-Spam-Score: -1.0 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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, 24 Sep 2007, Arnt Gulbrandsen wrote: > rfc-editor@rfc-editor.org writes: >> A new Request for Comments is now available in online RFC libraries. >> RFC 4959 > Lemonade blocks on this, right? Well, it's published. Why on earth would Lemonade block on this? Sheesh. There's a difference between must-have and nice-to-have. SASL-IR is, at best, nice-to-have. -- 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 Sep 24 11:45: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 1IZq75-0004y7-EA; Mon, 24 Sep 2007 11:44:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZq74-0004y0-2P for lemonade-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 11:44:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZq73-0004xs-Mz for lemonade@ietf.org; Mon, 24 Sep 2007 11:44:45 -0400 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 1IZq72-0004ti-VD for lemonade@ietf.org; Mon, 24 Sep 2007 11:44:45 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 24 Sep 2007 16:44:30 +0100 Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> In-Reply-To: MIME-Version: 1.0 Message-Id: <7206.1190648667.717856@peirce.dave.cridland.net> Date: Mon, 24 Sep 2007 16:44:27 +0100 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 Mon Sep 24 16:33:04 2007, Mark Crispin wrote: > On Mon, 24 Sep 2007, Arnt Gulbrandsen wrote: >> rfc-editor@rfc-editor.org writes: >>> A new Request for Comments is now available in online RFC >>> libraries. >>> RFC 4959 >> Lemonade blocks on this, right? Well, it's published. > > Why on earth would Lemonade block on this? > > Sheesh. There's a difference between must-have and nice-to-have. > SASL-IR is, at best, nice-to-have. "Blocks" is also relative. It is a normatively required reference. But we could have ditched it if it looked like it would have seriously delayed us. 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 Sep 24 11:49: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 1IZqBh-00014q-9O; Mon, 24 Sep 2007 11:49:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZqBf-00013t-Nr for lemonade-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 11:49:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqBf-00013l-A0 for lemonade@ietf.org; Mon, 24 Sep 2007 11:49:31 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZqBe-00054a-Lh for lemonade@ietf.org; Mon, 24 Sep 2007 11:49:31 -0400 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 l8OFnRCh022088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Sep 2007 08:49:27 -0700 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 l8OFnPRS028954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Sep 2007 08:49:26 -0700 Date: Mon, 24 Sep 2007 08:49:24 -0700 (PDT) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: <7206.1190648667.717856@peirce.dave.cridland.net> Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> 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.9.24.80030 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, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) 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 Mon, 24 Sep 2007, Dave Cridland wrote: > On Mon Sep 24 16:33:04 2007, Mark Crispin wrote: >> On Mon, 24 Sep 2007, Arnt Gulbrandsen wrote: >>> rfc-editor@rfc-editor.org writes: >>>> A new Request for Comments is now available in online RFC libraries. >>>> RFC 4959 >>> Lemonade blocks on this, right? Well, it's published. >> Why on earth would Lemonade block on this? >> Sheesh. There's a difference between must-have and nice-to-have. SASL-IR >> is, at best, nice-to-have. > "Blocks" is also relative. It is a normatively required reference. But we > could have ditched it if it looked like it would have seriously delayed us. How is it normatively required? At most, it should be a recommendation to save an RTT. But there are many other RTT savings that are far more critical than this one. -- 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 Sep 24 14:22:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsZM-0006No-93; Mon, 24 Sep 2007 14:22:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IZsZK-0006Kn-RP for lemonade-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 14:22:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsZK-0006IM-Dd for lemonade@ietf.org; Mon, 24 Sep 2007 14:22:06 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZsZJ-0002Ns-Dw for lemonade@ietf.org; Mon, 24 Sep 2007 14:22:06 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8OIM1n7025303 for ; Mon, 24 Sep 2007 18:22: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 <0JOV00F01XKHQ000@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 24 Sep 2007 12:22:01 -0600 (MDT) Received: from Tundra ([129.150.35.235]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOV0046SXOEZN50@mail-amer.sun.com>; Mon, 24 Sep 2007 12:21:52 -0600 (MDT) Date: Mon, 24 Sep 2007 11:21:22 -0700 From: Peter Coates To: alexey.melnikov@isode.com Message-id: <01da01c7fed7$b7227160$6501a8c0@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf+17Uq8z7HG4AQSG26IEYydzkJXg== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org Subject: [lemonade] imap convert URL syntax 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 *think* that this is a formal description of my proposal for imap urls requiring conversion. The intent of this (probably mashed up) ABNF is that the SECTION section look something like: /;section=CONVERT.1.1?to-type=text%2fplain&charset=us-ascii&unknown-character-re placement=%2e This works because "?" Is not included in bchar. enc-section = 1*bchar convert-parameters ; %-encoded version of [RFC3501 ] "extended-section-spec" followed by the convert parameters encoded as necessary ; is defined in [IMAPURL ]. convert-parameters = "?" "to-type" "=" 1*uchar *[ "&" 1*uchar "=" 1*uchar ] ; %-encoded as necessary, the destination type/subtype followed by the convert parameters extended-section-spec = section-spec / "CONVERT" ; for the whole message / "CONVERT." section-part ; for a body part I am not convinced by the first form of extended-section-spec. The CONVERT command does not allow for the conversion of the whole message. Why should IMAP URLs? Peter _______________________________________________ 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 Sep 25 05:20: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 1Ia6aE-00025k-Tq; Tue, 25 Sep 2007 05:19:58 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ia6aE-00021W-4b for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 05:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6aD-00020U-Qz for lemonade@ietf.org; Tue, 25 Sep 2007 05:19:57 -0400 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 1Ia6aC-0007S8-5e for lemonade@ietf.org; Tue, 25 Sep 2007 05:19:57 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 25 Sep 2007 10:19:44 +0100 Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <7206.1190711981.498021@peirce.dave.cridland.net> Date: Tue, 25 Sep 2007 10:19:41 +0100 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: 3e15cc4fdc61d7bce84032741d11c8e5 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 Sep 24 16:49:24 2007, Mark Crispin wrote: > On Mon, 24 Sep 2007, Dave Cridland wrote: >> On Mon Sep 24 16:33:04 2007, Mark Crispin wrote: >>> On Mon, 24 Sep 2007, Arnt Gulbrandsen wrote: >>>> rfc-editor@rfc-editor.org writes: >>>>> A new Request for Comments is now available in online RFC >>>>> libraries. >>>>> RFC 4959 >>>> Lemonade blocks on this, right? Well, it's published. >>> Why on earth would Lemonade block on this? >>> Sheesh. There's a difference between must-have and nice-to-have. >>> SASL-IR is, at best, nice-to-have. >> "Blocks" is also relative. It is a normatively required reference. >> But we could have ditched it if it looked like it would have >> seriously delayed us. > > How is it normatively required? > > It's a MUST for servers to implement in Profile Bis. There are no SHOULDs in Profile Bis for servers. Clients don't have to - I think, without looking, that it's a SHOULD, like many of these things, although given that the only case where it's useful is with PLAIN (and we have LOGIN which does the same thing for the common case), EXTERNAL (a nice idea, but unlikely to occur in the real world), and DIGEST-MD5 (moving to Historic), then few clients are likely to use it in practise. But should a new mechanism arise that's useful here (YAP-* springs to mind), then it's there, deployed and ready. It's also not terribly hard to implement, so it's not a burden - in my opinion, having implemented it in client and server. > At most, it should be a recommendation to save an RTT. But there > are many other RTT savings that are far more critical than this one. Sure. It's a single round-trip at session-startup. Savings of round-trips for the more repetitive actions (such as SELECT time, or FETCHes) are way more important, of course. So I'm agreeing with you in entirety - it's a nice-to-have, and we can have it without delay, so we'll have it. If it were likely to delay Profile Bis, it should have been dropped. Whether Profile Bis ought to have SHOULDs for servers is a whole debate in and of itself. 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 Sep 25 06:38: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 1Ia7md-0004Zx-QT; Tue, 25 Sep 2007 06:36:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ia7mc-0004Zq-7d for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 06:36:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7mb-0004Zi-Tj for lemonade@ietf.org; Tue, 25 Sep 2007 06:36:49 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia7mb-0003Z3-6x for lemonade@ietf.org; Tue, 25 Sep 2007 06:36:49 -0400 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, 25 Sep 2007 11:36:46 +0100 Message-ID: <46F83B3A.7090606@isode.com> Date: Mon, 24 Sep 2007 23:33:30 +0100 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 References: <01da01c7fed7$b7227160$6501a8c0@Tundra> In-Reply-To: <01da01c7fed7$b7227160$6501a8c0@Tundra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: lemonade@ietf.org Subject: [lemonade] Re: imap convert URL syntax 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: >I *think* that this is a formal description of my proposal for imap urls >requiring conversion. The intent of this (probably mashed up) ABNF is that the >SECTION section look something like: > >/;section=CONVERT.1.1?to-type=text%2fplain&charset=us-ascii&unknown-character-re >placement=%2e > >This works because "?" Is not included in bchar. > >enc-section = 1*bchar convert-parameters > ; %-encoded version of [RFC3501 >] "extended-section-spec" followed by the convert parameters encoded as >necessary >; is defined in [IMAPURL > ]. >convert-parameters = "?" "to-type" "=" 1*uchar *[ "&" 1*uchar "=" 1*uchar ] > ; %-encoded as necessary, the destination type/subtype followed by >the convert parameters > >extended-section-spec = section-spec > / "CONVERT" > ; for the whole message > / "CONVERT." section-part > ; for a body part > >I am not convinced by the first form of extended-section-spec. > Sure it does: BINARY[] >The CONVERT >command does not allow for the conversion of the whole message. Why should IMAP >URLs? > > _______________________________________________ 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 Sep 25 09:45: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 1IaAj0-0004x9-EX; Tue, 25 Sep 2007 09:45:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaAiy-0004w6-O8 for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 09:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAix-0004u6-2B for lemonade@ietf.org; Tue, 25 Sep 2007 09:45:16 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaAiq-0005mN-HA for lemonade@ietf.org; Tue, 25 Sep 2007 09:45:15 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 33ABC4ACD2 for ; Tue, 25 Sep 2007 15:44:57 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 15:46:56 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 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 Mark Crispin writes: > Why on earth would Lemonade block on this? There was talk of that happening a few months ago. At the December interim? Prague meeting? Sometime around then. Someone said something like "the document is done already and widely implemented, so it's a one-RTT improvement at practically no cost". If. I. Remember. Correctly. I didn't care much at the time, since there was nothing for me to do in either case. > Sheesh. There's a difference between must-have and nice-to-have. > SASL-IR is, at best, nice-to-have. I rather agreed with that when I read the -00 draft. But since so many widely used servers have implemented the extension I think a published specification is now more than just "nice to have". (I wish I knew why so many people implemented this particular extension.) 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 Sep 25 10:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAxc-0006ak-EO; Tue, 25 Sep 2007 10:00:24 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaAxb-0006aR-Pm for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 10:00:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAxb-0006aC-FX for lemonade@ietf.org; Tue, 25 Sep 2007 10:00:23 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaAxY-0000LK-TK for lemonade@ietf.org; Tue, 25 Sep 2007 10:00:21 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9FDA54ACE6; Tue, 25 Sep 2007 16:00:19 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 16:02:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: profile-bis and ipv6 References: <18269.1188373437.581860@peirce.dave.cridland.net> <18269.1188377299.947528@peirce.dave.cridland.net> In-Reply-To: <18269.1188377299.947528@peirce.dave.cridland.net> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: > Speaking as an editor, I'd feel more comfortable adding this if there > were visible consensus. Noone has replied so far, either in the positive or negative. Zolt=E1n replied with a followup question, to which I seemed to have the right answer: "mandate only implementation, not deployment". I interpret this as mildish agreement, not strong enough to be called support. Perhaps Eric or Glenn could ask for a hum in the room at the next meeting. 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 Sep 25 11:27: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 1IaCJb-0002E5-Vv; Tue, 25 Sep 2007 11:27:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaCJa-0002Ch-T6 for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCJa-00025e-Ja for lemonade@ietf.org; Tue, 25 Sep 2007 11:27:10 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaCJP-0008Mz-BD for lemonade@ietf.org; Tue, 25 Sep 2007 11:27:05 -0400 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 l8PFQggq015626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2007 08:26:42 -0700 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 l8PFQebQ003761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 08:26:41 -0700 Date: Tue, 25 Sep 2007 08:26:39 -0700 (PDT) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: <7206.1190711981.498021@peirce.dave.cridland.net> Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> <7206.1190711981.498021@peirce.dave.cridland.net> 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.9.25.80853 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' X-Spam-Score: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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, 25 Sep 2007, Dave Cridland wrote: > It's a MUST for servers to implement in Profile Bis. There are no SHOULDs in > Profile Bis for servers. This is a mistake. It should be removed. Lemonade does NOT need this. On the other hand, Lemonade is rapidly moving to irrelevance. So it may not matter. > It's also not terribly hard to implement, so it's not a burden - in my > opinion, having implemented it in client and server. It all depends. It is arguably a layering violation; the obvious way to implement it is to hold it in a buffer until the SASL layer is started. But I agree that there are more horrible things in the world. > So I'm agreeing with you in entirety - it's a nice-to-have, and we can have > it without delay, so we'll have it. If it were likely to delay Profile Bis, > it should have been dropped. It should be dropped because it is unnecessary and adds complexity to something that is already unnecessarily complex. -- 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 Sep 25 11:29: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 1IaCM7-0001TL-V1; Tue, 25 Sep 2007 11:29:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaCM6-0001Mt-Pc for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCM4-0001Km-FP for lemonade@ietf.org; Tue, 25 Sep 2007 11:29:46 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaCM3-0008Q9-4o for lemonade@ietf.org; Tue, 25 Sep 2007 11:29:44 -0400 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 l8PFTgwe016672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2007 08:29:42 -0700 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 l8PFTd6X013678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 08:29:41 -0700 Date: Tue, 25 Sep 2007 08:29:39 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> 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.9.25.81314 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_600_699 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' X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Tue, 25 Sep 2007, Arnt Gulbrandsen wrote: > (I wish I knew why so many people implemented this particular extension.) It's low-hanging fruit for open source servers. However, don't delude yourself; as it is not necessary (other than this silly statement by Lemonade), it won't be implemented by a server which is trying to minimize its bloat by NOT implementing unnecessary extensions. I know of servers which are in that situation. -- 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 Sep 25 12:24: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 1IaDD0-0002uF-HX; Tue, 25 Sep 2007 12:24:26 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaDCz-0002u9-8Q for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 12:24:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDCy-0002u0-UL for lemonade@ietf.org; Tue, 25 Sep 2007 12:24:24 -0400 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 1IaDCy-0004gM-B5 for lemonade@ietf.org; Tue, 25 Sep 2007 12:24:24 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 25 Sep 2007 17:24:13 +0100 Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> <7206.1190711981.498021@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <21239.1190737452.593944@peirce.dave.cridland.net> Date: Tue, 25 Sep 2007 17:24:12 +0100 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: 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 Sep 25 16:26:39 2007, Mark Crispin wrote: > On Tue, 25 Sep 2007, Dave Cridland wrote: >> It's a MUST for servers to implement in Profile Bis. There are no >> SHOULDs in Profile Bis for servers. > > This is a mistake. It should be removed. Lemonade does NOT need > this. > > *sigh* Can you make a compelling argument why it should be removed? > On the other hand, Lemonade is rapidly moving to irrelevance. So > it may not matter. > > This really doesn't match what I'm seeing, both in my professional and personal capacities. For a start, I'm seeing clients being developed for consumer-grade devices which use Lemonade. Whether they're actually advertising the fact in their glossy manuals is another matter. I'm really not sure why you're arguing so heavily against something so simple, especially if you've apparently decided it's all irrelevant anyway. 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 Sep 25 12:34: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 1IaDM6-0006LD-5S; Tue, 25 Sep 2007 12:33:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaDM4-0006IW-UH for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 12:33:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDM4-0006IO-Jp for lemonade@ietf.org; Tue, 25 Sep 2007 12:33:48 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaDM4-0004r1-3N for lemonade@ietf.org; Tue, 25 Sep 2007 12:33:48 -0400 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, 25 Sep 2007 17:33:44 +0100 Message-ID: <46F93875.9070302@isode.com> Date: Tue, 25 Sep 2007 17:33:57 +0100 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: Mark Crispin Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> <7206.1190711981.498021@peirce.dave.cridland.net> <21239.1190737452.593944@peirce.dave.cridland.net> In-Reply-To: <21239.1190737452.593944@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: d6b246023072368de71562c0ab503126 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 the other hand, Lemonade is rapidly moving to irrelevance. So it >> may not matter. > > This really doesn't match what I'm seeing, both in my professional > and personal capacities. For a start, I'm seeing clients being > developed for consumer-grade devices which use Lemonade. Whether > they're actually advertising the fact in their glossy manuals is > another matter. > > I'm really not sure why you're arguing so heavily against something > so simple, especially if you've apparently decided it's all > irrelevant anyway. I also don't understand why you are arguing against inclusion of something you've implemented into something you have no plans to implement. _______________________________________________ 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 Sep 25 12:38: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 1IaDQp-0003nM-UW; Tue, 25 Sep 2007 12:38:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaDQl-0003m2-Qu for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 12:38:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDQl-0003le-EG for lemonade@ietf.org; Tue, 25 Sep 2007 12:38:39 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaDQk-0004yw-VI for lemonade@ietf.org; Tue, 25 Sep 2007 12:38:39 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l8PGca2Y018298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2007 09:38:36 -0700 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 l8PGcY7b018581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 09:38:35 -0700 Date: Tue, 25 Sep 2007 09:38:33 -0700 (PDT) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: <21239.1190737452.593944@peirce.dave.cridland.net> Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> <7206.1190711981.498021@peirce.dave.cridland.net> <21239.1190737452.593944@peirce.dave.cridland.net> 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.9.25.91730 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_800_899 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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, 25 Sep 2007, Dave Cridland wrote: >> This is a mistake. It should be removed. Lemonade does NOT need this. > *sigh* Can you make a compelling argument why it should be removed? It is a basic principle that any requirement that is not needed should be removed. > I'm really not sure why you're arguing so heavily against something so > simple, especially if you've apparently decided it's all irrelevant anyway. I don't want to be blamed when Lemonade turns out to be a miserable failure. I don't see the mobile device world moving towards Lemonade; just see lots of talk, reminiscent of the OSI fiasco in the 1980s. -- 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 Sep 25 12:41:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDTd-00061F-FF; Tue, 25 Sep 2007 12:41:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaDTc-0005zh-Lz for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 12:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDTc-0005zZ-CH for lemonade@ietf.org; Tue, 25 Sep 2007 12:41:36 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaDTV-0002JM-QR for lemonade@ietf.org; Tue, 25 Sep 2007 12:41:36 -0400 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 l8PGfGko027448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2007 09:41:17 -0700 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 l8PGfEMD027169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 09:41:16 -0700 Date: Tue, 25 Sep 2007 09:41:14 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: <46F93875.9070302@isode.com> Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> <7206.1190711981.498021@peirce.dave.cridland.net> <21239.1190737452.593944@peirce.dave.cridland.net> <46F93875.9070302@isode.com> 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.9.25.91730 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_600_699 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' X-Spam-Score: -1.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 Tue, 25 Sep 2007, Alexey Melnikov wrote: > I also don't understand why you are arguing against inclusion of something > you've implemented into something you have no plans to implement. It is the difference between fluff in an open-source server implementation, and fluff in a mandatory-to-implement function set. Is Lemonade serious about having a viable solution to non-IETF (and generally proprietary) standards for mobile device email? Or do you want to repeat the OSI fiasco of the 1980s? -- 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 Sep 25 16:55: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 1IaHR8-0000vK-NQ; Tue, 25 Sep 2007 16:55:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaHR4-0000ky-VE for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 16:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHR3-0000fC-QL for lemonade@ietf.org; Tue, 25 Sep 2007 16:55:13 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaHQt-0001cg-Vj for lemonade@ietf.org; Tue, 25 Sep 2007 16:55:10 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D14E34AC44; Tue, 25 Sep 2007 22:54:52 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 22:56:52 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 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 Mark Crispin writes: > On Tue, 25 Sep 2007, Arnt Gulbrandsen wrote: >> (I wish I knew why so many people implemented this particular extension.) > > It's low-hanging fruit for open source servers. Hm... the document shepherd asked me whether I had a list of implementations, so I wrote to various maintainers asking whether they'd implemented it. Two authors of closed-source servers responded to the question by implementing it. That shocked me. > However, don't delude yourself; as it is not necessary (other than > this silly statement by Lemonade), it won't be implemented by a > server which is trying to minimize its bloat by NOT implementing > unnecessary extensions. I know of servers which are in that > situation. I don't disagree with that. 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 Sep 25 17:06: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 1IaHbf-00074l-PM; Tue, 25 Sep 2007 17:06:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaHbe-0006za-4T for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 17:06:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHbd-0006vv-Nn for lemonade@ietf.org; Tue, 25 Sep 2007 17:06:09 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaHbb-0005WZ-4x for lemonade@ietf.org; Tue, 25 Sep 2007 17:06:07 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l8PL65mR011636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2007 14:06:06 -0700 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 l8PL65h1015625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2007 14:06:05 -0700 Date: Tue, 25 Sep 2007 14:06:05 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> 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.9.25.135029 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Tue, 25 Sep 2007, Arnt Gulbrandsen wrote: > Hm... the document shepherd asked me whether I had a list of implementations, > so I wrote to various maintainers asking whether they'd implemented it. Two > authors of closed-source servers responded to the question by implementing > it. That shocked me. I'm thinking of one major closed-source server which doesn't. On the other hand, that server's vendor is aggressively working to kill IMAP by deprecating it as being "legacy" and "obsolete", so I doubt it will ever support Lemonade. That non-IMAP component of that server will do mobile devices via its proprietary protocol though. >> However, don't delude yourself; as it is not necessary (other than this >> silly statement by Lemonade), it won't be implemented by a server which is >> trying to minimize its bloat by NOT implementing unnecessary extensions. I >> know of servers which are in that situation. > I don't disagree with that. Hence my argument that Lemonade should aggressively trim fat from all requirements. The SASL-IR requirement is an example of such fat that should be trimmed. Every little bit of fat hurts, not helps, the long-term chances of Lemonade's viability. I personally fear that it is already too late (we missed our window), but that won't stop me from trying to see the right thing happen. -- 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 Sep 25 17:34: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 1IaI2h-0006Oi-J5; Tue, 25 Sep 2007 17:34:07 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaI2f-0006Od-K0 for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 17:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaI2f-0006Jn-54 for lemonade@ietf.org; Tue, 25 Sep 2007 17:34:05 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaI2d-0002e4-Ic for lemonade@ietf.org; Tue, 25 Sep 2007 17:34:05 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 7BF644AC64 for ; Tue, 25 Sep 2007 23:34:02 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 23:36:02 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: 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 Mark Crispin writes: > Hence my argument that Lemonade should aggressively trim fat from all > requirements. Amen to that. Can you suggest a list, e.g. "five biggest pieces of bloat"? 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 Sep 25 21:03: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 1IaLIj-0001J2-Br; Tue, 25 Sep 2007 21:02:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaLIi-0001Iw-TQ for lemonade-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 21:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaLIi-00010v-JH for lemonade@ietf.org; Tue, 25 Sep 2007 21:02:52 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaLIW-0008Uc-K3 for lemonade@ietf.org; Tue, 25 Sep 2007 21:02:47 -0400 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 l8Q12Xr9002580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2007 18:02:33 -0700 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 l8Q12Xlr031488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2007 18:02:33 -0700 Date: Tue, 25 Sep 2007 18:02:31 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> 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.9.25.173929 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' X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Tue, 25 Sep 2007, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> Hence my argument that Lemonade should aggressively trim fat from all >> requirements. > Amen to that. Can you suggest a list, e.g. "five biggest pieces of bloat"? I haven't been paying close enough attention; just noting overall tone of the discussions. SASL-IR was so obvious that it stood out. I suggest that each and every requirement in the profile be subject to a "how bad would it be if this is omitted?" consideration, paying particular example to things that are currently optional today (and thus have a reasonable chance of being there even if not mandatory). It isn't good enough to be "nice to have". If it isn't critical, it should go. For example, the trio stands out as being critical, as it is our solution to forward without download. So the trio make the cut. -- 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 Wed Sep 26 04:58: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 1IaSic-0000IC-2Y; Wed, 26 Sep 2007 04:58:06 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaSia-00008U-1r for lemonade-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 04:58:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaSiZ-0008Td-Ky for lemonade@ietf.org; Wed, 26 Sep 2007 04:58:03 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaSiW-0008Bf-VY for lemonade@ietf.org; Wed, 26 Sep 2007 04:58:01 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 779214ACB1; Wed, 26 Sep 2007 10:57:59 +0200 (CEST) Message-Id: <49Q5KDhQ507kFGCiFgWApw.md5@libertango.oryx.com> Date: Wed, 26 Sep 2007 11:00:00 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response References: <20070921222103.F334EE3E83@bosco.isi.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 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 Mark Crispin writes: > I suggest that each and every requirement in the profile be subject to > a "how bad would it be if this is omitted?" consideration, paying > particular example to things that are currently optional today (and > thus have a reasonable chance of being there even if not mandatory). > It isn't good enough to be "nice to have". If it isn't critical, it > should go. People have seemed to place great emphasis on saving roundtrips at startup, and SASL-IR saves one in the very common case of STARTTLS+PLAIN. If roundtrips are that important, I don't see how SASL-IR can be faulted. > For example, the trio stands out as being critical, as it is our > solution to forward without download. So the trio make the cut. Strictly speaking it's two solutions, each of which requires three extensions. Servers must implement four extensions, clients can choose which three to use. Seems mildly bloated 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 Wed Sep 26 06:30: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 1IaU9o-0005MD-K7; Wed, 26 Sep 2007 06:30:16 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaU9n-0005Lx-Pc for lemonade-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 06:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaU9m-0005Lp-VX for lemonade@ietf.org; Wed, 26 Sep 2007 06:30:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaU9g-000671-NO for lemonade@ietf.org; Wed, 26 Sep 2007 06:30:14 -0400 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, 26 Sep 2007 11:29:59 +0100 Message-ID: <46FA25B0.4040306@isode.com> Date: Wed, 26 Sep 2007 10:26:08 +0100 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 References: <01da01c7fed7$b7227160$6501a8c0@Tundra> In-Reply-To: <01da01c7fed7$b7227160$6501a8c0@Tundra> 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [lemonade] Re: imap convert URL syntax 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: >I *think* that this is a formal description of my proposal for imap urls >requiring conversion. The intent of this (probably mashed up) ABNF is that the >SECTION section look something like: > I've argued with Peter that IMAP URLs should just %-encode the whole CONVERT request. While the syntax is ugly, an IMAP server processing an URL containing such request can just remove %-encoding and pass the result to the function that parses the conversion specification as used in the CONVERT command. So, unless new arguments in favor of changing the URL syntax are given, the document would stay the way it currently is. _______________________________________________ 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 Sep 26 11:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZBD-0004pa-FT; Wed, 26 Sep 2007 11:52:03 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaZBC-0004pM-1a for lemonade-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 11:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZBB-0004ol-Mu for lemonade@ietf.org; Wed, 26 Sep 2007 11:52:01 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaZB5-0005qj-EX for lemonade@ietf.org; Wed, 26 Sep 2007 11:52:01 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8QFpXDq011184 for ; Wed, 26 Sep 2007 15:51: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 <0JOZ00M01FMQA500@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 26 Sep 2007 09:51:33 -0600 (MDT) Received: from Tundra ([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 <0JOZ00BDAG196K70@mail-amer.sun.com> for lemonade@ietf.org; Wed, 26 Sep 2007 09:51:11 -0600 (MDT) Date: Wed, 26 Sep 2007 08:50:36 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <011101c80054$fc2a1b90$eb239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgAVPrtm1aXFo21Tki/Fgrzwp/UmQ== X-Spam-Score: -1.0 (-) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [lemonade] CONVERT, CONVERTED, and CONVERTERROR 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 the current IMAP CONVERT DRAFT has some inconsistencies which become very clear when you try to implement it. The draft states: A successful CONVERT/UID CONVERT command results in one or more untagged CONVERTED responses (one per message). They are similar to the untagged FETCH responses. So far so good. when things work, the draft is just fine. It is when things go wrong that problems start to emerge. An example given in the draft is Example: The client requests for conversion of a text/html body part to text/plain and asks for a charset of us-ascii. The server cannot respect the charset conversion request because there are non-us-ascii characters in the text/html body part, so it fails the request with tagged NO response, preceded by the CONVERTERROR BADPARAMETERS response (see section 8 ). C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3] S: * CONVERTERROR BADPARAMETERS text/html text/plain ("charset" "us-ascii") S: b001 NO Source text has non us-ascii But what if the command had been C: b002 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BINARY[3] or C: b003 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BODYPARTSTUCTURE[2] BINARY[2] BODYPARTSTUCTURE[3] BINARY[3] and some conversions succeed and some fail? my first thought on this was to move the error text from the tagged response and put the message number (and UID?) into the CONVERTERROR like so: C: b004 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BINARY[3] S: * 4 CONVERTED (TAG "b004") (BINARY[3] {2135} ) S: * 5 CONVERTERROR (TAG "b004") (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii S: b004 OK Curates egg But this does not work well for the more complicated case where there are several bodyparts to convert, and some succeed and some fail for a given message. The convert error is not specific to the command, nor to a particular message, but a particular body part. My next action was to consider the FETCH command, and what it does when information is unavailable: it returns NIL. Perhaps we should consider the CONVERTERROR a "fat NIL". This gets a little verbose, but is at least consistent: C: b005 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BINARY[2] BINARY[3] S: * 4 CONVERTED (TAG "b005") ( BINARY[2] {2135} BINARY[3] (CONVERTERROR (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii)) S: * 5 CONVERTED (TAG "b005") ( BINARY[3] (CONVERTERROR (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii) BINARY[2] {2135} ) S: b005 OK Curates egg (msgno 4 part 2 and msgno 5 part 3 are successfully converted, msgno 4 part 3 and msgno 3 part 2 errored). This looks promising, but we are not done yet. Supposing the command had requested BODYPARTSTRUTURE as well as BINARY for each conversion. What does this new scheme return? C: b003 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BODYPARTSTUCTURE[2] BINARY[2] BODYPARTSTUCTURE[3] BINARY[3] S: * 4 CONVERTED (TAG "b005") ( BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII") NIL NIL "8bit" 2135 NIL NIL NIL) BINARY[2] {2135} BODYPARTSTRUCTURE[3] (CONVERTERROR (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii) BINARY[3] (CONVERTERROR (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii)) S: * 5 CONVERTED (TAG "b005") ( BODYPARTSTRUCTURE[2] (CONVERTERROR (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii) BINARY[2] (CONVERTERROR (BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii) BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII") NIL NIL "8bit" 2135 NIL NIL NIL) BINARY[3] {2135} )) S: b005 OK Curates egg The command sends an untagged CONVERTED response for each message, and either the requested data or an error response to each item requested. But this does end up with duplicated error messages going back to the client. Perhaps we can do better. Suppose instead of sending back the specific data items with the CONVERTERROR objects, we send back just the CONVERTERROR: C: b003 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BODYPARTSTUCTURE[2] BINARY[2] BODYPARTSTUCTURE[3] BINARY[3] S: * 4 CONVERTED (TAG "b005") ( BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII") NIL NIL "8bit" 2135 NIL NIL NIL) BINARY[2] {2135} CONVERTERROR[3] ((BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii)) S: * 5 CONVERTED (TAG "b005") ( CONVERTERROR[2] ((BADPARAMETERS text/html text/plain ("charset" "us-ascii")) Source text has non us-ascii) BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII") NIL NIL "8bit" 2135 NIL NIL NIL) BINARY[3] {2135} )) S: b005 OK Curates egg This feels better, but it may pose problems for clients to parse, and I am a server person rather than a client person. I think I have identified a problem and put forward two candidate solutions. I favour the second, but others my feel otherwise or have a quite different take on the whole problem. Peter _______________________________________________ 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 Sep 26 12:12: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 1IaZUf-0004IP-0U; Wed, 26 Sep 2007 12:12:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IaZUe-0004Fx-3l for lemonade-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 12:12:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZUd-0004Ay-P3 for lemonade@ietf.org; Wed, 26 Sep 2007 12:12:07 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaZUb-0003u0-9E for lemonade@ietf.org; Wed, 26 Sep 2007 12:12:05 -0400 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 l8QGC4Mn003454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Sep 2007 09:12:04 -0700 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 l8QGC150016289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2007 09:12:03 -0700 Date: Wed, 26 Sep 2007 09:12:01 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: <49Q5KDhQ507kFGCiFgWApw.md5@libertango.oryx.com> Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> <49Q5KDhQ507kFGCiFgWApw.md5@libertango.oryx.com> 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.9.26.85624 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_800_899 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Wed, 26 Sep 2007, Arnt Gulbrandsen wrote: > People have seemed to place great emphasis on saving roundtrips at startup, > and SASL-IR saves one in the very common case of STARTTLS+PLAIN. If > roundtrips are that important, I don't see how SASL-IR can be faulted. Does it require automatic capability announcement in the startup banner and in the authentication response? That is far more important than SASL-IR, since that saves two RTTs every time. Does it add a new, two-stage, STARTTLS that can announce automatic capabilities after TLS is in effect? That saves another one, every time. If not, it seems that Lemonade is failing to see the forest for the trees. -- 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 Thu Sep 27 12:45: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 1IawUB-0000Cx-U4; Thu, 27 Sep 2007 12:45:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IawUB-0000Cs-7a for lemonade-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 12:45:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawUA-00004u-Sn for lemonade@ietf.org; Thu, 27 Sep 2007 12:45:10 -0400 Received: from ppsw-5.csi.cam.ac.uk ([131.111.8.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IawU6-0007UW-E6 for lemonade@ietf.org; Thu, 27 Sep 2007 12:45:06 -0400 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-2.csi.cam.ac.uk ([131.111.8.54]:57413) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1IawU2-0002n2-Hf (Exim 4.67) (return-path ); Thu, 27 Sep 2007 17:45:02 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IawU2-0000fb-Ef (Exim 4.67) (return-path ); Thu, 27 Sep 2007 17:45:02 +0100 Date: Thu, 27 Sep 2007 17:45:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] Re: RFC 4959 on IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response In-Reply-To: <7206.1190711981.498021@peirce.dave.cridland.net> Message-ID: References: <20070921222103.F334EE3E83@bosco.isi.edu> <7206.1190648667.717856@peirce.dave.cridland.net> <7206.1190711981.498021@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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, 25 Sep 2007, Dave Cridland wrote: > > EXTERNAL (a nice idea, but unlikely to occur in the real world) One of my friends set up the infrastructure in his company to do single-sign-on with X.509. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. _______________________________________________ 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 Sep 28 18:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbO6W-0003aD-65; Fri, 28 Sep 2007 18:14:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IbO6V-0003Ye-BF for lemonade-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:14:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbO6U-0003XI-UQ for lemonade@ietf.org; Fri, 28 Sep 2007 18:14:35 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbO6U-0000wa-A2 for lemonade@ietf.org; Fri, 28 Sep 2007 18:14:34 -0400 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, 28 Sep 2007 23:14:32 +0100 Message-ID: <46FD7CA6.3090909@isode.com> Date: Fri, 28 Sep 2007 23:13:58 +0100 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 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] Re: New Version Notification for draft-ietf-lemonade-reconnect-client-06 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: >Changes since draft-ietf-lemonade-reconnect-client-05.txt > > [...] >o Require that any client issues ENABLE QRESYNC first. Servers now >reject SELECT QRESYNC/FETCH VANISHED not preceeded by ENABLE >QRESYNC with BAD. > > If anybody has a problem with this change, speak up now. _______________________________________________ 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 Sep 28 18:20: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 1IbOBy-0001jb-Oj; Fri, 28 Sep 2007 18:20:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IbOBx-0001ia-G4 for lemonade-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOBx-0001iS-6Z; Fri, 28 Sep 2007 18:20:13 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbOBw-0007en-3c; Fri, 28 Sep 2007 18:20:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EC63D26E9F; Fri, 28 Sep 2007 22:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbOBl-0005ja-Ru; Fri, 28 Sep 2007 18:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Sep 2007 18:20:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-reconnect-client-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 : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-reconnect-client-06.txt Pages : 25 Date : 2007-09-28 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages (and always includes the UIDs expunged).Changes since draft-ietf-lemonade-reconnect-client-05.txt o Many editorial improvements from Randy Gellens. o Remove RECENT response from the list of responses that doesn't need to be returned when VANISHED is also returned. o Clarified that VANISHED (EARLIER) must be returned before any FETCH. o Fixed some typos in examples. o Require that any client issues ENABLE QRESYNC first. Servers now reject SELECT QRESYNC/FETCH VANISHED not preceeded by ENABLE QRESYNC with BAD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-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-reconnect-client-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-reconnect-client-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-09-28181124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-28181124.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 Sat Sep 29 09:42: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 1IbcZe-0002LO-Go; Sat, 29 Sep 2007 09:41:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IbO48-0000bZ-9V for lemonade-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:12:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbO47-0000bR-Uj for lemonade@ietf.org; Fri, 28 Sep 2007 18:12:07 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbO47-0000sd-M2 for lemonade@ietf.org; Fri, 28 Sep 2007 18:12:07 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 5AC05175AA; Fri, 28 Sep 2007 22:11:27 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IbO3S-0004tB-So; Fri, 28 Sep 2007 18:11:26 -0400 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: Fri, 28 Sep 2007 18:11:26 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Sat, 29 Sep 2007 09:41:36 -0400 Cc: lemonade@ietf.org, Alexey.Melnikov@isode.com, dave.cridland@isode.com Subject: [lemonade] New Version Notification for draft-ietf-lemonade-reconnect-client-06 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-reconnect-client-06.txt has been successfuly submitted by Alexey Melnikov and posted to the IETF repository. Filename: draft-ietf-lemonade-reconnect-client Revision: 06 Title: IMAP4 Extensions for Quick Mailbox Resynchronization Creation_date: 2007-09-28 WG ID: lemonade Number_of_pages: 25 Abstract: This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages (and always includes the UIDs expunged).Changes since draft-ietf-lemonade-reconnect-client-05.txt o Many editorial improvements from Randy Gellens. o Remove RECENT response from the list of responses that doesn't need to be returned when VANISHED is also returned. o Clarified that VANISHED (EARLIER) must be returned before any FETCH. o Fixed some typos in examples. o Require that any client issues ENABLE QRESYNC first. Servers now reject SELECT QRESYNC/FETCH VANISHED not preceeded by ENABLE QRESYNC with BAD. 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