From lemonade-bounces@ietf.org Thu Dec 01 04:14:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhkVw-000354-6I; Thu, 01 Dec 2005 04:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhkVr-00034e-5s for lemonade@megatron.ietf.org; Thu, 01 Dec 2005 04:13:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10252 for ; Thu, 1 Dec 2005 04:13:12 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhkqH-0005xm-KD for lemonade@ietf.org; Thu, 01 Dec 2005 04:35:07 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1EhkVm-00039i-KO; Thu, 01 Dec 2005 09:13:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 63350498003; Thu, 1 Dec 2005 09:16:11 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02433-01; Thu, 1 Dec 2005 09:16:06 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id E2486498002; Thu, 1 Dec 2005 09:16:05 +0000 (GMT) Date: Thu, 01 Dec 2005 09:13:47 +0000 Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH References: <25368.1133392897.320506@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <25368.1133428428.606401@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu Dec 1 01:16:14 2005, Mark Crispin wrote: > On Wed, 30 Nov 2005, Dave Cridland wrote: >> 1) I ran into an almost immediate problem with URLAUTH in that the >> server didn't recognise the hostname in the URL as being its own. >> I used 'mail' rather than the server's canonical hostname. > > For better or worse, I think that a server needs to recognize its > name(s) and not assume a canonicalization. Canonicalization > implies chasing CNAME and possibly a PTR lookup. > > Effectively, you're saying that a server should take the hostname as provided by the client, perform a getaddrinfo() on it, and see whether any of the entries matches the getsockname() of the connection? >> It occurs to me that if GENURLAUTH accepted a relative URL (either >> to the server URL, or to the currently selected mailbox as with >> CATENATE), this problem would vanish. The server is always in a >> better position than the client to construct the URL to the server. > > I question whether this is really so, given virtual hosts and other > such complications. > > I'll certainly concede that this might not be as easy as I thought - I've not personally tried implementing something like this. >> 2) There's no way to know whether a submission server you're >> talking to: >> a) Is authorized by the IMAP server to access "submit+" URLAUTH >> URLs. >> b) Will understand and use "anonymous" URLAUTH URLs, or simply >> anonymous URLs. > > I always thought that this was something that this would be > knowledge that is configured into the client, either by the human > user or by some system configuration tool. > > Yes, it has to be. For a Lemonade-environment client - that is, one that simply requires Lemonade servers - that's not a problem, since the client can assume that whatever submission server it has not only supports URLAUTH, but has a "submit+" level trust relationship with the IMAP server. In principle, a Lemonade client has no need to examine capabilities of servers at all. For a generic client, I'm a little concerned that a typical user would start to encounter problems comprehending what the client is asking them about. It's difficult to know how to phrase it in such a way that both, for instance, you and my mother would understand what question was being asked. >> 4) I found it unclear whether URLFETCH should accept relative URLs >> or not. I have no opinion on whether it should or not, either, >> given that the only purposes I can think of would be stateless >> access to message bodies, and I'm not sure that's within the >> spirit of things. > > I thought that in LEMONADE we require absolute. > > For Lemonade, URLFETCH is, essentially, an implementation detail, and would only be used by the submission server, with URLAUTH URLs. So from a Lemonade standpoint, there is no issue. > Stateless access to message bodies is certainly a possibility, > considered from the inception of URLAUTH. I'm not sure if I > consider it to be "good" or "bad" (I tend towards the latter) but > it certainly was considered. > > :-) > > I've actually yet to find a practical use for it, although annoying purists almost counts. :-) Realistically, the only circumstances I can think of where you'd want to access message bodies in multiple mailboxes would be in message assembly, where we'd use CATENATE/BURL/GENURLAUTH commands instead. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 01 15:50:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNz-0000Oy-OV; Thu, 01 Dec 2005 15:50:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNV-00008J-As; Thu, 01 Dec 2005 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25896; Thu, 1 Dec 2005 15:49:16 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehvi1-00084h-IX; Thu, 01 Dec 2005 16:11:18 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNS-0006d9-B7; Thu, 01 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Lemonade Profile Author(s) : S. Maes, A. Melnikov Filename : draft-ietf-lemonade-profile-06.txt Pages : 18 Date : 2005-12-1 This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol [RFC3501] extensions and BURL extension to the SUBMIT protocol [RFC2476]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-profile-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-profile-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: <2005-12-1123547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1123547.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 --NextPart-- From lemonade-bounces@ietf.org Fri Dec 02 01:08:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei45r-0007Ed-Rd; Fri, 02 Dec 2005 01:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei45q-0007Dn-Gl for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 01:08:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11374 for ; Fri, 2 Dec 2005 01:07:39 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei4QT-0000y4-EX for lemonade@ietf.org; Fri, 02 Dec 2005 01:29:45 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB268Kr3011751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2005 22:08:20 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB268HN2003552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Dec 2005 22:08:19 -0800 Date: Thu, 1 Dec 2005 22:08:17 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH In-Reply-To: <25368.1133428428.606401@peirce.dave.cridland.net> Message-ID: References: <25368.1133392897.320506@peirce.dave.cridland.net> <25368.1133428428.606401@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu, 1 Dec 2005, Dave Cridland wrote: >>> 1) I ran into an almost immediate problem with URLAUTH in that the server >>> didn't recognise the hostname in the URL as being its own. I used 'mail' >>> rather than the server's canonical hostname. >> For better or worse, I think that a server needs to recognize its name(s) >> and not assume a canonicalization. Canonicalization implies chasing CNAME >> and possibly a PTR lookup. > Effectively, you're saying that a server should take the hostname as provided > by the client, perform a getaddrinfo() on it, and see whether any of the > entries matches the getsockname() of the connection? I'm saying that neither client nor server should canonicalize a name that is used in a security context. This means that the server needs to know, its name(s), and probably should not trust the DNS in this regard. In the case of URLAUTH, I'm not certain that it should be validating any associated IP addresses against the getsockname() of the connection (what about proxies?). > For a generic client, I'm a little concerned that a typical user would start > to encounter problems comprehending what the client is asking them about. > It's difficult to know how to phrase it in such a way that both, for > instance, you and my mother would understand what question was being asked. I suspect that it'll be the same as always; you configure your IMAP server and your submission server at the direction of your ISP. >> Stateless access to message bodies is certainly a possibility, considered >> from the inception of URLAUTH. I'm not sure if I consider it to be "good" >> or "bad" (I tend towards the latter) but it certainly was considered. > I've actually yet to find a practical use for it, although annoying purists > almost counts. :-) I suspect (fear) that some webmail programs would get the idea that it will be more "efficient" to use URLFETCH rather than SELECT/FETCH/etc. -- 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 From lemonade-bounces@ietf.org Fri Dec 02 01:57:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4qt-0003YB-L5; Fri, 02 Dec 2005 01:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4qs-0003X9-3o for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 01:57:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15429 for ; Fri, 2 Dec 2005 01:56:14 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei5BS-0002QQ-3F for lemonade@ietf.org; Fri, 02 Dec 2005 02:18:21 -0500 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB26uvD7013991 for ; Thu, 1 Dec 2005 23:56:57 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQU00901Z1Z4400@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Thu, 01 Dec 2005 23:56:57 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQU0044AZAUN300@mail-amer.sun.com>; Thu, 01 Dec 2005 23:56:57 -0700 (MST) Date: Thu, 01 Dec 2005 22:57:36 -0800 From: Chris Newman Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH In-reply-to: <25368.1133392897.320506@peirce.dave.cridland.net> To: Dave Cridland , lemonade@ietf.org Message-id: <0DC081E5BD6ADB7DBC762E45@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <25368.1133392897.320506@peirce.dave.cridland.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7BIT 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote on 11/30/05 23:21 +0000: > 3) I found it unclear what response BURL generates when used with CHUNKING. > It seems natural that, given that RFC3030 clearly shows a 250 response for > non-LAST chunks with BDAT, that BURL should also, but in section 6, a "354" > response code is listed. I have chosen to expect, and emit, 250 response > codes, in line with BDAT. This is a bug in the BURL spec. It should be "250 2.5.0" (with the same status text and discussion) rather than "354". Will fix during RFC editor process and sort down one slot for correct ordering. This also involves removing the "Most of" modifier in the final sentence of the first paragraph of section 6. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 02:07:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei50b-0005A1-NK; Fri, 02 Dec 2005 02:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei50a-00059w-FZ for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 02:07:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16282 for ; Fri, 2 Dec 2005 02:06:16 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei5LD-0002hW-L4 for lemonade@ietf.org; Fri, 02 Dec 2005 02:28:24 -0500 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB2772D7019729 for ; Fri, 2 Dec 2005 00:07:02 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQU00F01ZRQN500@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Fri, 02 Dec 2005 00:07:02 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQU00451ZRON300@mail-amer.sun.com>; Fri, 02 Dec 2005 00:07:02 -0700 (MST) Date: Thu, 01 Dec 2005 23:07:42 -0800 From: Chris Newman Subject: Re: [lemonade] LEMONADE interim poll In-reply-to: <085091CB2CA14E4B8B163FFC37C84E9D0753BD8A@zcarhxm0.corp.nortel.com> To: Glenn Parsons , lemonade@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <085091CB2CA14E4B8B163FFC37C84E9D0753BD8A@zcarhxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I would attend LA or San Diego. Boston would be a maybe. Beijing I would probably not be able to attend. - Chris Glenn Parsons wrote on 11/28/05 17:51 -0500: > > Folks, > > The interest in LEMONADE is growing -- at least that's what you would think > from the fact that we have four offers for locations for our next interim > meeting. We only had two offers for the last interim :-) > > We propose that the date of the next LEMONADE interim meeting is Feb 1-2. > > The offered locations are: > > 1. Beijing, China > 2. San Diego, CA > 3. Los Angeles, CA > 4. Boston, MA > > As a result, the chairs are compelled to poll the WG on the turnout based on > meeting location. > > Please respond to me by the end of the week (i.e., Dec 2) indicating if you > would attend a LEMONADE interim in each of the offered locations. You may > also indicate your preference if you would be able to attend more than one > location. > > Cheers, > Glenn & Eric _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 03:47:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei6ZT-0003cm-SF; Fri, 02 Dec 2005 03:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei6ZS-0003ch-8s for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 03:47:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24078 for ; Fri, 2 Dec 2005 03:46:22 -0500 (EST) From: fanxiaohui@chinamobile.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei6u6-00063v-02 for lemonade@ietf.org; Fri, 02 Dec 2005 04:08:31 -0500 Received: from mail.chinamobile.com ([211.136.27.4] helo=cmccmta) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ei6ZN-00072H-6r for lemonade@ietf.org; Fri, 02 Dec 2005 03:47:05 -0500 To: gparsons@nortel.com, lemonade@ietf.org MIME-Version: 1.0 Subject: Re: Re: [lemonade] LEMONADE interim poll Date: Fri, 2 Dec 2005 16:32:52 +0800 Message-ID: X-MIMETrack: Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2005-12-02 04:40:46 PM MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi, folks I prefer Beijing, China. It would be much easier for Asian participants to join the meeting if it is= held in Asia. Cheers Fan China Mobile =3D=3D=3D=3D=3D=3D=3D=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D= =3D=3D=3D=3D=3D hi all, =A1=A1 I would perfer Beijing, China, too. But I agree that the revised proposed = date is Jan 24-25 because our Spring Festival in China=A1=A1from 28,Jan=A1= =A1to 7,Feb. =A1=A1 Best Regards, Liang Gang Huawei Technologies Co.,Ltd ---------------------------------------------------- Lianggang Huawei Technologies Tel:+86 25 84565646 Mob:+86 13813998674 Fax:+86 25 84565028 Email:lianggang79@huawei.com ---------------------------------------------------- =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 09:24:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiBpX-0002dw-RO; Fri, 02 Dec 2005 09:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiBpW-0002dF-3A for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 09:24:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28560 for ; Fri, 2 Dec 2005 09:23:18 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiCAC-0000j5-Cd for lemonade@ietf.org; Fri, 02 Dec 2005 09:45:29 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1EiBpD-00005r-SO; Fri, 02 Dec 2005 14:23:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D65D8498003; Fri, 2 Dec 2005 14:26:17 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08646-07; Fri, 2 Dec 2005 14:26:08 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id E4ABD498002; Fri, 2 Dec 2005 14:26:07 +0000 (GMT) Date: Fri, 02 Dec 2005 14:23:36 +0000 Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH References: <25368.1133392897.320506@peirce.dave.cridland.net> <25368.1133428428.606401@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <10120.1133533417.710152@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Dec 2 06:08:17 2005, Mark Crispin wrote: > On Thu, 1 Dec 2005, Dave Cridland wrote: >>>> 1) I ran into an almost immediate problem with URLAUTH in that >>>> the server didn't recognise the hostname in the URL as being its >>>> own. I used 'mail' rather than the server's canonical hostname. >>> For better or worse, I think that a server needs to recognize its >>> name(s) and not assume a canonicalization. Canonicalization >>> implies chasing CNAME and possibly a PTR lookup. >> Effectively, you're saying that a server should take the hostname >> as provided by the client, perform a getaddrinfo() on it, and see >> whether any of the entries matches the getsockname() of the >> connection? > > I'm saying that neither client nor server should canonicalize a > name that is used in a security context. This means that the > server needs to know, its name(s), and probably should not trust > the DNS in this regard. > > In the case of URLAUTH, I'm not certain that it should be > validating any associated IP addresses against the getsockname() of > the connection (what about proxies?). > > Right, so effectively, any hostname configured in the client must be the (or a) canonical, known name of the server. TLS encourages this too, of course. >> For a generic client, I'm a little concerned that a typical user >> would start to encounter problems comprehending what the client is >> asking them about. It's difficult to know how to phrase it in such >> a way that both, for instance, you and my mother would understand >> what question was being asked. > > I suspect that it'll be the same as always; you configure your IMAP > server and your submission server at the direction of your ISP. > > That's not actually what happens now, in a lot of cases. What happens now is that the user receives some cryptic instructions, and pays a consultant (like, say, me) to configure things for them, generally as part of the "get my computer on the web" request. Or asks a friend who knows these things. From a business standpoint, therefore, I should really be encouraging as many cryptic options as I possibly can, seeing as this represents a not insignificant portion of my company's income. But from a technical perspective, however, I'm trying to reduce all these options to a minimum. Ideally, I'd like an EHLO keyword, in this case, which indicated those IMAP servers for which the submission server had access. I say again, this isn't needed for a pure Lemonade environment. >>> Stateless access to message bodies is certainly a possibility, >>> considered from the inception of URLAUTH. I'm not sure if I >>> consider it to be "good" or "bad" (I tend towards the latter) but >>> it certainly was considered. >> I've actually yet to find a practical use for it, although >> annoying purists almost counts. :-) > > I suspect (fear) that some webmail programs would get the idea that > it will be more "efficient" to use URLFETCH rather than > SELECT/FETCH/etc. It'd be more efficient for a webmail client, but only under some circumstances (such as when the object referenced by the URL were 7 or 8 bit, and there was no need to rebuild the summary display). A webmail which handled that distinction is likely to be designed well enough to avoid the need entirely. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 09:35:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiC0u-0001qO-NB; Fri, 02 Dec 2005 09:35:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiC0t-0001qJ-AW for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 09:35:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29739 for ; Fri, 2 Dec 2005 09:35:03 -0500 (EST) Received: from fugue.toroid.org ([85.10.196.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiCLX-00018C-RL for lemonade@ietf.org; Fri, 02 Dec 2005 09:57:15 -0500 Received: from penne.toroid.org (localhost [127.0.0.1]) by fugue.toroid.org (Postfix) with ESMTP id DAD43E9B4; Fri, 2 Dec 2005 15:35:30 +0100 (CET) Received: from [10.0.0.123] (unknown [10.0.0.123]) by penne.toroid.org (Postfix) with ESMTP id 7D9D13E227A; Fri, 2 Dec 2005 20:05:29 +0530 (IST) Message-Id: Date: Fri, 2 Dec 2005 15:31:48 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Fri Dec 2 06:08:17 2005, Mark Crispin wrote: >> I suspect (fear) that some webmail programs would get the idea that >> it will be more "efficient" to use URLFETCH rather than >> SELECT/FETCH/etc. > > It'd be more efficient for a webmail client, but only under some > circumstances (such as when the object referenced by the URL were 7 > or 8 bit, and there was no need to rebuild the summary display). A > webmail which handled that distinction is likely to be designed well > enough to avoid the need entirely. How about a webmail client written by someone who thinks URLFETCH is always more "efficient" (substitute any positive-sounding adjective)? Is that likely to be well designed? I share Mark's fear. Too many web bozos like to fit the entire world into some sort of "stateless" URL scheme. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 11:11:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDVT-0006dF-Cp; Fri, 02 Dec 2005 11:11:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDVS-0006ar-Dh for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 11:11:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11691 for ; Fri, 2 Dec 2005 11:10:41 -0500 (EST) Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiDq9-0004Vv-Im for lemonade@ietf.org; Fri, 02 Dec 2005 11:32:54 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1EiDVG-0006Xd-Nb; Fri, 02 Dec 2005 16:11:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 79596498003; Fri, 2 Dec 2005 16:13:49 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09032-07; Fri, 2 Dec 2005 16:13:44 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 733ED498002; Fri, 2 Dec 2005 16:13:44 +0000 (GMT) Date: Fri, 02 Dec 2005 16:11:12 +0000 Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH References: In-Reply-To: MIME-Version: 1.0 Message-Id: <10120.1133539873.424224@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org, Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Dec 2 14:31:48 2005, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> On Fri Dec 2 06:08:17 2005, Mark Crispin wrote: >>> I suspect (fear) that some webmail programs would get the idea >>> that it will be more "efficient" to use URLFETCH rather than >>> SELECT/FETCH/etc. >> >> It'd be more efficient for a webmail client, but only under some >> circumstances (such as when the object referenced by the URL were >> 7 or 8 bit, and there was no need to rebuild the summary display). >> A webmail which handled that distinction is likely to be designed >> well enough to avoid the need entirely. > > How about a webmail client written by someone who thinks URLFETCH > is always more "efficient" (substitute any positive-sounding > adjective)? Is that likely to be well designed? > > Well, no. :-) They'd be missing the advantage of using BINARY, for a start. > I share Mark's fear. Too many web bozos like to fit the entire > world into some sort of "stateless" URL scheme. While I sympathise with your sentiments, having thought quite a bit about how a web-based IMAP client could and should work, it is very difficult to reconcile the distinct models. If you're writing for the web, you have no alternative but to conform to the stateless model. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 11:41:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDyV-00015j-Tp; Fri, 02 Dec 2005 11:41:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDyU-00014G-2r for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 11:41:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14986 for ; Fri, 2 Dec 2005 11:40:41 -0500 (EST) Received: from fugue.toroid.org ([85.10.196.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEJC-0005UF-U8 for lemonade@ietf.org; Fri, 02 Dec 2005 12:02:55 -0500 Received: from penne.toroid.org (localhost [127.0.0.1]) by fugue.toroid.org (Postfix) with ESMTP id C82E5F614; Fri, 2 Dec 2005 17:41:21 +0100 (CET) Received: from [10.0.0.123] (unknown [10.0.0.123]) by penne.toroid.org (Postfix) with ESMTP id 844EF3E22AA; Fri, 2 Dec 2005 22:11:20 +0530 (IST) Message-Id: Date: Fri, 2 Dec 2005 17:37:41 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH References: <10120.1133539873.424224@peirce.dave.cridland.net> In-Reply-To: <10120.1133539873.424224@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > While I sympathise with your sentiments, having thought quite a bit > about how a web-based IMAP client could and should work, it is very > difficult to reconcile the distinct models. Right. Much more pleasant if the webmail programmer if the the IMAP server author has to reconcile the two models. Personally, I think I'd be happy with the URLFETCH if the document were to say that IMAP servers are not expected to provide similar levels of performance as with SELECT/FETCH, and that clients needing performance should consider using SELECT/FETCH instead of URLFETCH. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 02 12:50:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF2y-0001Yr-U5; Fri, 02 Dec 2005 12:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF2w-0001Xz-LL for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 12:50:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23813 for ; Fri, 2 Dec 2005 12:49:23 -0500 (EST) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiFNc-0008Pv-Hq for lemonade@ietf.org; Fri, 02 Dec 2005 13:11:35 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB2Ho2Qn019112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2005 09:50:03 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB2Hnneb020693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Dec 2005 09:50:02 -0800 Date: Fri, 2 Dec 2005 09:49:48 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH In-Reply-To: <10120.1133533417.710152@peirce.dave.cridland.net> Message-ID: References: <25368.1133392897.320506@peirce.dave.cridland.net> <25368.1133428428.606401@peirce.dave.cridland.net> <10120.1133533417.710152@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 2409bba43e9c8d580670fda8b695204a 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 2 Dec 2005, Dave Cridland wrote: > Right, so effectively, any hostname configured in the client must be the (or > a) canonical, known name of the server. TLS encourages this too, of course. Don't use the word "canonical". It implies a "canonicalization" step to transform a name into the canonical name. DNS spoofing makes doing so dangerous. Rather, say that "any hostname used by the the client must be a name that the server recognizes as being its (the server's) name. TLS requires this too, of course." >> I suspect (fear) that some webmail programs would get the idea that it will >> be more "efficient" to use URLFETCH rather than SELECT/FETCH/etc. > It'd be more efficient for a webmail client, but only under some > circumstances (such as when the object referenced by the URL were 7 or 8 bit, > and there was no need to rebuild the summary display). Wrong definition of "efficient". The definition is "efficient" as in "lazy programmer doesn't want to bother to think about how to do it right." -- 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 From lemonade-bounces@ietf.org Fri Dec 02 12:53:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF5l-00024u-62; Fri, 02 Dec 2005 12:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF5k-00024o-95 for lemonade@megatron.ietf.org; Fri, 02 Dec 2005 12:53:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24184 for ; Fri, 2 Dec 2005 12:52:17 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiFQQ-0008VU-Bz for lemonade@ietf.org; Fri, 02 Dec 2005 13:14:30 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB2Hqq32006851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2005 09:52:52 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB2HqonJ023776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Dec 2005 09:52:51 -0800 Date: Fri, 2 Dec 2005 09:52:49 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH In-Reply-To: <10120.1133539873.424224@peirce.dave.cridland.net> Message-ID: References: <10120.1133539873.424224@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 2409bba43e9c8d580670fda8b695204a Cc: lemonade@ietf.org, Arnt Gulbrandsen 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 2 Dec 2005, Dave Cridland wrote: >> How about a webmail client written by someone who thinks URLFETCH is always >> more "efficient" (substitute any positive-sounding adjective)? Is that >> likely to be well designed? > Well, no. :-) They'd be missing the advantage of using BINARY, for a start. So? I doubt that any webmail client uses BINARY now. >> I share Mark's fear. Too many web bozos like to fit the entire world into >> some sort of "stateless" URL scheme. > While I sympathise with your sentiments, having thought quite a bit about how > a web-based IMAP client could and should work, it is very difficult to > reconcile the distinct models. If you're writing for the web, you have no > alternative but to conform to the stateless model. Nonsense. It is perfectly possible to build a webmail client that maintains state and keeps a stateful IMAP session open. WebPine is an example of such a client. It does require the programmer to do some work. But "need to do some work" is quite a bit different than "no alternative". -- 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 From lemonade-bounces@ietf.org Sat Dec 03 17:27:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eifqg-0005SA-Q8; Sat, 03 Dec 2005 17:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eifqg-0005S5-9x for lemonade@megatron.ietf.org; Sat, 03 Dec 2005 17:27:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09631 for ; Sat, 3 Dec 2005 17:26:28 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EigBd-0005fj-CJ for lemonade@ietf.org; Sat, 03 Dec 2005 17:48:58 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1EifqU-0007ix-Ui for lemonade@ietf.org; Sat, 03 Dec 2005 22:27:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DC149498003 for ; Sat, 3 Dec 2005 22:29:50 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14544-09 for ; Sat, 3 Dec 2005 22:29:46 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 1DD1F498002 for ; Sat, 3 Dec 2005 22:29:46 +0000 (GMT) Date: Sat, 03 Dec 2005 22:27:01 +0000 MIME-Version: 1.0 Message-Id: <21488.1133648821.728291@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] RFC2192bis, quick comments 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org 1) The ABNF for partial appears to be incorrect - I think the first=20 nz-number should be number. 2) In answer to the open questions / comments in the specification: Sec 3.1: I'm not sure what Chris's comment means here - if by "the=20 shared folders name", Chris means, for instance, translating "INBOX"=20 to, perhaps, "user.myusername", that would be reasonable if there=20 were defined semantics for doing so - I didn't think NAMESPACE=20 provided this, does it? Sec 3.2: I think we should deprecate the LOGIN-as-anonymous method.=20 Leave it in, but only as a fallback where the ANONYMOUS SASL mech is=20 not advertised, but LOGIN is still available. 3) It occured to me that an uglier syntax for partials would encode=20 the partial on the end of the section. This would change ABNF=20 something like: isection =3D enc-section [ "P" partial-range ] This is fairly ugly, but it has the advantage that a na=EFve processor=20 which is unaware of partials will most likely generate an error (or=20 have the IMAP server generate one). If partial is seperate, it's possible (and likely) that a na=EFve=20 implementation would receive the URL, and resolve it to the full=20 message part, which could be somewhat confusing to track down. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 06 07:02:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjbWr-00051m-G3; Tue, 06 Dec 2005 07:02:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjbWq-00051b-23 for lemonade@megatron.ietf.org; Tue, 06 Dec 2005 07:02:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17630 for ; Tue, 6 Dec 2005 07:01:49 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjbsI-00076F-JZ for lemonade@ietf.org; Tue, 06 Dec 2005 07:24:53 -0500 Received: from [192.168.0.7] ([62.3.217.253]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 6 Dec 2005 12:02:25 +0000 Message-ID: <43957DCF.50408@isode.com> Date: Tue, 06 Dec 2005 12:02:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] RFC2192bis, quick comments References: <21488.1133648821.728291@peirce.dave.cridland.net> In-Reply-To: <21488.1133648821.728291@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > 1) The ABNF for partial appears to be incorrect - I think the first = > nz-number should be number. Good catch, fixed. > 2) In answer to the open questions / comments in the specification: > > Sec 3.1: I'm not sure what Chris's comment means here - if by "the = > shared folders name", Chris means, for instance, translating "INBOX" = > to, perhaps, "user.myusername", that would be reasonable if there were = > defined semantics for doing so Yes, this is what he meant > - I didn't think NAMESPACE provided this, does it? No, it does not. > Sec 3.2: I think we should deprecate the LOGIN-as-anonymous method. = > Leave it in, but only as a fallback where the ANONYMOUS SASL mech is = > not advertised, but LOGIN is still available. Yes, the editorial copy already says that. > 3) It occured to me that an uglier syntax for partials would encode = > the partial on the end of the section. This would change ABNF = > something like: > > isection =3D enc-section [ "P" partial-range ] > > This is fairly ugly, but it has the advantage that a na=EFve processor = > which is unaware of partials will most likely generate an error (or = > have the IMAP server generate one). > > If partial is seperate, it's possible (and likely) that a na=EFve = > implementation would receive the URL, and resolve it to the full = > message part, which could be somewhat confusing to track down. I think I understand the motivation. However I would rather not do the hack you suggest, but I want to hear what other people think? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 06 10:04:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjeMK-0001LO-Ij; Tue, 06 Dec 2005 10:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjO7H-0002og-Pq; Mon, 05 Dec 2005 16:43:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15192; Mon, 5 Dec 2005 16:42:34 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjOSf-0002L8-3s; Mon, 05 Dec 2005 17:05:29 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EjO7A-0000yG-Mp; Mon, 05 Dec 2005 16:43:16 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 05 Dec 2005 16:43:16 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Tue, 06 Dec 2005 10:03:59 -0500 Cc: lemonade mailing list , lemonade chair , Internet Architecture Board , lemonade chair , RFC Editor Subject: [lemonade] Protocol Action: 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail' to Proposed Standard 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The IESG has approved the following document: - 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail ' as a Proposed Standard This document is the product of the Enhancements to Internet email to support diverse service environments Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-06.txt Technical Summary The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in ESMTP and Internet message headers. Working Group Summary The LEMONADE working group came to consensus on the publication of this document. No issues were raised during IETF Last Call. This work was coordinated with 3GPP and 3GPP2 by the author and working group chairs. The document was approved, but the approval appealed by John Klensin. After considering the appeal, the IESG asked the working group to consider the issues raised. This document contains the changes made by the working group post-appeal and after a second IETF Last Call. Protocol Quality This work was reviewed for the IESG by Ted Hardie. Eric Burger and Glenn Parsons are the PROTO shepherds. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 07 18:50:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek93J-0006fQ-PQ; Wed, 07 Dec 2005 18:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek92y-0006VL-TH; Wed, 07 Dec 2005 18:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18568; Wed, 7 Dec 2005 18:49:12 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek9Ok-0006C7-2h; Wed, 07 Dec 2005 19:12:34 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ek92v-00046z-RE; Wed, 07 Dec 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Dec 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-oma-mem-realization-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 : Realization of OMA Mobile Email (MEM) Architecture using Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-7165707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-oma-mem-realization-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-7165707.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 --NextPart-- From lemonade-bounces@ietf.org Thu Dec 08 10:53:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO5B-0004uk-CR; Thu, 08 Dec 2005 10:53:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO59-0004th-Bf; Thu, 08 Dec 2005 10:53:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02070; Thu, 8 Dec 2005 10:52:18 -0500 (EST) Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkO51-0005aB-WE; Thu, 08 Dec 2005 10:53:12 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 16:53:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Thu, 8 Dec 2005 16:54:18 +0100 Message-ID: Thread-Topic: [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tug From: "SEGOND Hubert RD-BIZZ-CAE" To: , X-OriginalArrivalTime: 08 Dec 2005 15:53:08.0690 (UTC) FILETIME=[7C1CD320:01C5FC0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 08 21:22:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXtu-0001bx-0q; Thu, 08 Dec 2005 21:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkNx4-0002bH-OL; Thu, 08 Dec 2005 10:44:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00845; Thu, 8 Dec 2005 10:44:01 -0500 (EST) Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkNwz-0005EB-Qc; Thu, 08 Dec 2005 10:44:55 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 16:44:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Thu, 8 Dec 2005 16:45:55 +0100 Message-ID: Thread-Topic: [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAfshFQ X-Priority: 1 Priority: Urgent Importance: high From: "SEGOND Hubert RD-BIZZ-CAE" To: , X-OriginalArrivalTime: 08 Dec 2005 15:44:46.0223 (UTC) FILETIME=[509E71F0:01C5FC0E] X-Spam-Score: 1.3 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 08 Dec 2005 21:22:20 -0500 Cc: lemonade@ietf.org, OMA-MEM@MAIL.OPENMOBILEALLIANCE.ORG, PICHELIN Aude OCORP-FR , ANZA Diego OCORP-FR 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 Copy: OMA-MEM Wg and Orange OMA Manager =20 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 08 22:06:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkYam-0000EI-LL; Thu, 08 Dec 2005 22:06:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkYaj-0000D5-Tt for lemonade@megatron.ietf.org; Thu, 08 Dec 2005 22:06:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26518 for ; Thu, 8 Dec 2005 22:05:34 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkYad-0008Km-F8 for lemonade@ietf.org; Thu, 08 Dec 2005 22:06:34 -0500 X-IronPort-AV: i="3.99,232,1131339600"; d="scan'208"; a="23863807:sNHT41569848" 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]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Thu, 8 Dec 2005 22:06:17 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701C2AE29@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TA= From: "Burger, Eric" To: "SEGOND Hubert RD-BIZZ-CAE" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 09 00:16:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekac0-0005wN-7Y; Fri, 09 Dec 2005 00:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekabq-0005ut-UH for lemonade@megatron.ietf.org; Fri, 09 Dec 2005 00:16:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08524 for ; Fri, 9 Dec 2005 00:14:52 -0500 (EST) Received: from rgminet01.oracle.com ([148.87.122.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekabo-0003pQ-RA for lemonade@ietf.org; Fri, 09 Dec 2005 00:15:54 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jB95FWYo025569; Thu, 8 Dec 2005 22:15:32 -0700 Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB95FWgr001808; Thu, 8 Dec 2005 22:15:32 -0700 Received: from us.oracle.com (dhcp-emea-uk-csvpn-gw8-141-144-136-16.vpn.oracle.com [141.144.136.16]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB95FTru001792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Dec 2005 22:15:30 -0700 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Thu, 8 Dec 2005 21:15:27 -0800 In-Reply-To: X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20051208211528094.00000005908@smaes-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: quoted-printable Cc: PICHELIN Aude OCORP-FR , ANZA Diego OCORP-FR X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hubert, as this was discussed on OMA MEM mailing list and addressed but all= are not on that mailing list, I am repeating the exchange that took place.= Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: Stephane H. Maes [mailto:stephane.maes@ORACLE.COM] = Sent: Wednesday, December 07, 2005 4:00 PM To: OMA-MEM Subject: Re: [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-0= 0.txt That statement is an actually correct characterization of the draft. Nothing prevent parallel work nor limit work to evolve ad at oma. However I= believe that ad work is stabilizing. Liaisons made ad available to ietf and its public doc anyway. Oma does not = control ietf work and this in fact a model of efficient cooperation. Also p= er oma process it is ok to start TS work in parallel to ad work. There should not be any concerns on any of these aspects. I hope it helps addressing ant unfortunate confusion on this. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: "SEGOND Hubert RD-BIZZ-CAE" Date: Thu, 8 Dec 2005 18:58:58 = To: Cc:OMA-MEM Subject: RE: [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-0= 0.txt St=E9phane, The principal raison that I disagree is that = The Abstract of the draft is: "This document specifies a realization of the architecture for the mobile e= mail enabler (MEM) as specified by the OMA, using Internet mail protocols".= You know that RD was approved in TP R&A (OMA-RD-MobileEmail-V1_0-20051018-C= ). AD is in progress and informal AD review under consideration maybe in Athen= s or Paris (or another meeting if necessary /depending exchange and feedbac= k with OMA-ARC, OMA-DS and OMA-MEM decision). I know that we have LS to exchange with Lemonade-IETF like another WG. The = question is : Can Lemonade WG provide a draft using OMA Ad features or references that ar= e not valid and agreed inside OMA first ? Hope you agree this point of view and the group continue too analyse the Ar= chitecture Document getting feedback from ARC, DS and Lemonade. = Thanks = = Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 = -----Message d'origine----- De : Stephane H. Maes [mailto:stephane.maes@ORACLE.COM] = Envoy=E9 : jeudi 8 d=E9cembre 2005 01:00 =C0 : OMA-MEM@MAIL.OPENMOBILEALLIANCE.ORG Objet : Re: [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00= .txt Hubert, I must be missing the concern. The draft clearly states that the AD as refe= renced is work in progress. AD provides a draft architecture specification.= On the other hand the AD, even if draft work in progress, it provides a log= ical architecture and list of technical features to support that reflects t= he current agreement of SWG and as communicated at joined workshop to IETF.= The draft provides Lemonade's view and status on how this current draft arc= hitecture (AD) is realizable via lemonade and ietf email stack. So what aspect do you disagree with? Is there an AD feature that lemonade d= oes not appropriately discuss in the draft? Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 7:46 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org; OMA-MEM@MAIL.OPENMOBILEALLIANCE.ORG; PICHELIN Aude O= CORP-FR; ANZA Diego OCORP-FR Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00= .txt Importance: High Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? = I 'm working an OMA MEM Working Group (like Orange SA delegate) and I can a= ssure that any OMA MEM architecture document is ready, we just are studying= the architecture in the OMA group and the architecture is not specified or= finalized today. I disagree with this draft. Best Regards, = Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 Copy: OMA-MEM Wg and Orange OMA Manager = -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De la p= art de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.t= xt = A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Enhancements to Internet email to support = diverse service environments Working Group of the IETF. Title : Realization of OMA Mobile Email (MEM) Architecture using Internet= Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 = This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realization= -00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of the = message. = You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce = to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html = or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt". = NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. = = Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 13 16:36:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmHpF-00087z-Rj; Tue, 13 Dec 2005 16:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmHpE-00087Y-A4 for lemonade@megatron.ietf.org; Tue, 13 Dec 2005 16:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02285 for ; Tue, 13 Dec 2005 16:35:46 -0500 (EST) From: Zoltan.Ordogh@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmHqI-0003f5-MB for lemonade@ietf.org; Tue, 13 Dec 2005 16:37:51 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBDLa0Ni003095; Tue, 13 Dec 2005 23:36:02 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Dec 2005 23:36:34 +0200 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Dec 2005 23:36:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Tue, 13 Dec 2005 23:36:33 +0200 Message-ID: <084CB2DF0B7F5E47BC056ABBDF423700C4A645@trebe101.NOE.Nokia.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701C2AE29@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TAA8ZBAwA== To: , X-OriginalArrivalTime: 13 Dec 2005 21:36:33.0353 (UTC) FILETIME=[4983A390:01C6002D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The document in question has been reviewed in OMA MEM group. OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions. You should receive the liaison statement sometimes during next week = hopefully. Stephane and Glenn was present during the discussions - they know the = details. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of ext Burger, Eric Sent: 09 December, 2005 05:06 To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 14 04:05:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmSZk-0004PO-6G; Wed, 14 Dec 2005 04:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmSZf-0004ND-H4 for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 04:05:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23205 for ; Wed, 14 Dec 2005 04:04:23 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmSan-00059f-Rk for lemonade@ietf.org; Wed, 14 Dec 2005 04:06:34 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 10:05:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Wed, 14 Dec 2005 10:05:43 +0100 Message-ID: Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TAA8ZBAwAAW9SnA From: "SEGOND Hubert RD-BIZZ-CAE" To: , X-OriginalArrivalTime: 14 Dec 2005 09:05:15.0840 (UTC) FILETIME=[7FA2C400:01C6008D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi all, I'm not participating to OMA meeting in Athens and I agree with the = OMA-MEM response. Eric Burger, to response to your question I disagree with the abstract/ = resume of the draft because The Lemonade WG draft introduction presents the work of OMA MEM as a = finished work, which in fact it is not. In the draft, it is stated that = the "realization of the architecture for the mobile email enabler (MEM) = [is specified] by the OMA"; however, this is inexact. In fact, this = realization is a work in progress, and has not been finalized. = Secondly, the draft statement indicates that the architecture uses = Internet mail protocols, which may appear slightly misleading. In fact, = this realization can use a variety of protocols (for example, OMA = Standard), and not only Internet mail protocols. Best Regards, Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 =20 -----Message d'origine----- De=A0: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Envoy=E9=A0: mardi 13 d=E9cembre 2005 22:37 =C0=A0: eburger@brooktrout.com; SEGOND Hubert RD-BIZZ-CAE Cc=A0: lemonade@ietf.org Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt The document in question has been reviewed in OMA MEM group. OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions. You should receive the liaison statement sometimes during next week = hopefully. Stephane and Glenn was present during the discussions - they know the = details. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of ext Burger, Eric Sent: 09 December, 2005 05:06 To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 14 10:28:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYXw-0005jp-7J; Wed, 14 Dec 2005 10:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYXu-0005h3-DH for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 10:27:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10090 for ; Wed, 14 Dec 2005 10:26:55 -0500 (EST) Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmYZ0-00037z-9k for lemonade@ietf.org; Wed, 14 Dec 2005 10:29:09 -0500 Received: from [70.214.88.182] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d14); Wed, 14 Dec 2005 09:27:28 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 7.0a12] Date: Wed, 14 Dec 2005 09:27:23 -0600 To: "SEGOND Hubert RD-BIZZ-CAE" From: Pete Resnick Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lemonade@ietf.org, eburger@brooktrout.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 12/14/05 at 10:05 AM +0100, SEGOND Hubert RD-BIZZ-CAE wrote: >The Lemonade WG draft introduction presents the work of OMA MEM as a >finished work, which in fact it is not. In the draft, it is stated >that the "realization of the architecture for the mobile email >enabler (MEM) [is specified] by the OMA"; however, this is inexact. >In fact, this realization is a work in progress, and has not been >finalized. That's exactly what the draft says in section 1: This document contains the current view of the work. It refers to stable specifications and work in progress. As the work progress, it is expected that this document will evolve and be updated accordingly. And in the references section: [2] "Mobile Email Architecture Document", OMA (Work in Progress), http://www.openmobilealliance.org/, October 2005. This objection is clearly just mistaken. The document is quite clear that the work is not completed. >Secondly, the draft statement indicates that the architecture uses >Internet mail protocols, which may appear slightly misleading. In >fact, this realization can use a variety of protocols (for example, >OMA Standard), and not only Internet mail protocols. Again from the introduction (the same words appear in the abstract): This document describes a realization of OMA mobile email enabler (MEM) using Internet Mail protocols defined by the IETF. Notice where it says "a realization". Not "the one realization". Not "the only realization". The document specifies *one single* realization. And the realization given is based on Internet protocols. There is no misleading here. Other standards bodies which develop different protocols can write a realization of the OMA architecture using their own protocols, but the IETF is writing a realization using IETF protocols. Again, this objection is simply mistaken. The document is quite clear that this is one realization (perhaps among others) that happens to use Internet protocols. pr -- Pete Resnick QUALCOMM Incorporated _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 14 11:09:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZCQ-0001pU-Vm; Wed, 14 Dec 2005 11:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZCO-0001oy-8b for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 11:09:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16350 for ; Wed, 14 Dec 2005 11:08:36 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmZDO-0005BK-1i for lemonade@ietf.org; Wed, 14 Dec 2005 11:10:50 -0500 X-IronPort-AV: i="3.99,252,1131339600"; d="scan'208"; a="24183477:sNHT105165168" 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]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Wed, 14 Dec 2005 11:09:34 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701CD3574@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TAA8ZBAwAAW9SnAAA+fRVA= From: "Burger, Eric" To: "SEGOND Hubert RD-BIZZ-CAE" X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Now I understand. The abstract is probably poorly worded, which is something that can be = fixed. In fact, the comment highlights some important points. In particular: o The draft is a work group draft. This means the draft represents the view of the work group, and not of any particular individual's view. o The draft is an IETF work in progress similar to, as pointed out, the OMA work in progress. o The draft records the IETF's current view of a realization of the currently published MEM architecture, as sent by the OMA liaison to the IETF, using the lemonade suite. o In addition, the draft contains a pedagogical summary of the MEM Requirements and Architecture Documents for IETF readers' benefit. The lemonade work group needed a vehicle for communicating our thoughts = and plans to the OMA. The only vehicle we have for writing, debating, = and gaining consensus on documents is the Internet Draft, so that is = what the work group produced. It is important to note there has been no = decision as to whether this particular draft will ever be an RFC. I hope this clarifies the purpose and rationale for the draft. Your = comment is, in fact, part of the process and we welcome your further = participation in the work group. -----Original Message----- From: SEGOND Hubert RD-BIZZ-CAE [mailto:hubert.segond@francetelecom.com] = Sent: Wednesday, December 14, 2005 4:06 AM To: Zoltan.Ordogh@nokia.com; Burger, Eric Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Hi all, I'm not participating to OMA meeting in Athens and I agree with the = OMA-MEM response. Eric Burger, to response to your question I disagree with the abstract/ = resume of the draft because The Lemonade WG draft introduction presents the work of OMA MEM as a = finished work, which in fact it is not. In the draft, it is stated that = the "realization of the architecture for the mobile email enabler (MEM) = [is specified] by the OMA"; however, this is inexact. In fact, this = realization is a work in progress, and has not been finalized. = Secondly, the draft statement indicates that the architecture uses = Internet mail protocols, which may appear slightly misleading. In fact, = this realization can use a variety of protocols (for example, OMA = Standard), and not only Internet mail protocols. Best Regards, Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 =20 -----Message d'origine----- De=A0: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Envoy=E9=A0: mardi 13 d=E9cembre 2005 22:37 =C0=A0: eburger@brooktrout.com; SEGOND Hubert RD-BIZZ-CAE Cc=A0: lemonade@ietf.org Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt The document in question has been reviewed in OMA MEM group. OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions. You should receive the liaison statement sometimes during next week = hopefully. Stephane and Glenn was present during the discussions - they know the = details. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of ext Burger, Eric Sent: 09 December, 2005 05:06 To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 14 11:11:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZEI-0002kH-Eh; Wed, 14 Dec 2005 11:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZEG-0002dN-Ac for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 11:11:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16715 for ; Wed, 14 Dec 2005 11:10:39 -0500 (EST) Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmZFF-0005GQ-BN for lemonade@ietf.org; Wed, 14 Dec 2005 11:12:53 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1EmZDp-0002e7-Fk; Wed, 14 Dec 2005 16:11:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 2F5D3498003; Wed, 14 Dec 2005 16:15:55 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04849-09; Wed, 14 Dec 2005 16:15:45 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 41FCA498002; Wed, 14 Dec 2005 16:15:45 +0000 (GMT) Date: Wed, 14 Dec 2005 16:11:06 +0000 Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt References: In-Reply-To: MIME-Version: 1.0 Message-Id: <32527.1134576667.121321@peirce.dave.cridland.net> From: Dave Cridland To: SEGOND Hubert RD-BIZZ-CAE Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Dec 14 09:05:43 2005, SEGOND Hubert RD-BIZZ-CAE wrote: > The Lemonade WG draft introduction presents the work of OMA MEM as > a finished work, which in fact it is not. In the draft, it is > stated that the "realization of the architecture for the mobile > email enabler (MEM) [is specified] by the OMA"; however, this is > inexact. In fact, this realization is a work in progress, and has > not been finalized. Neither, of course, is the draft - it itself is a work in progress. I'd assume that it wouldn't be published before the OMA MEM work is completed, and possibly not at all. It's not an official statement of the WG in the slightest, and wouldn't hold that until publication as an RFC. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 14 11:17:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZKD-0005fu-Tc; Wed, 14 Dec 2005 11:17:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZKC-0005dV-Fs for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 11:17:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17433 for ; Wed, 14 Dec 2005 11:16:54 -0500 (EST) From: Corby.Wilson@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmZLP-0005UV-TX for lemonade@ietf.org; Wed, 14 Dec 2005 11:19:08 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBEGHeSc019637; Wed, 14 Dec 2005 18:17:44 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Dec 2005 18:17:42 +0200 Received: from bsebe101.NOE.Nokia.com ([172.19.160.235]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Dec 2005 10:17:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Wed, 14 Dec 2005 11:17:34 -0500 Message-ID: <4422475A1E8D0248B00251C20D968F88AAECE4@bsebe101.NOE.Nokia.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701CD3574@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TAA8ZBAwAAW9SnAAA+fRVAAAJRKcA== To: , X-OriginalArrivalTime: 14 Dec 2005 16:17:38.0528 (UTC) FILETIME=[E6AECE00:01C600C9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org If this is a realization of the OMA MEM architecture, shouldn't the OMA = define this instead of the IETF. The document seems severly out of place. Since this document ties us to = the OMA MEM arch, we must spend allot of time making sure the doc is = synched with the OMA MEM specs. I'm not sure having this document in the IETF is such a good idea since = it could bog us down and slow down progress even more. I would rather see us focusing on getting current drafts and technolgies = completed rather than worry about the OMA MEM architecutre.=20 Corby Wilson Security & Mobile Connectivity -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of ext Burger, Eric Sent: Wednesday, December 14, 2005 11:10 AM To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org; Ordogh Zoltan (Nokia-TP-MSW/Tampere) Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Now I understand. The abstract is probably poorly worded, which is something that can be = fixed. In fact, the comment highlights some important points. In particular: o The draft is a work group draft. This means the draft represents the view of the work group, and not of any particular individual's view. o The draft is an IETF work in progress similar to, as pointed out, the OMA work in progress. o The draft records the IETF's current view of a realization of the currently published MEM architecture, as sent by the OMA liaison to the IETF, using the lemonade suite. o In addition, the draft contains a pedagogical summary of the MEM Requirements and Architecture Documents for IETF readers' benefit. The lemonade work group needed a vehicle for communicating our thoughts = and plans to the OMA. The only vehicle we have for writing, debating, = and gaining consensus on documents is the Internet Draft, so that is = what the work group produced. It is important to note there has been no = decision as to whether this particular draft will ever be an RFC. I hope this clarifies the purpose and rationale for the draft. Your = comment is, in fact, part of the process and we welcome your further = participation in the work group. -----Original Message----- From: SEGOND Hubert RD-BIZZ-CAE [mailto:hubert.segond@francetelecom.com] Sent: Wednesday, December 14, 2005 4:06 AM To: Zoltan.Ordogh@nokia.com; Burger, Eric Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Hi all, I'm not participating to OMA meeting in Athens and I agree with the = OMA-MEM response. Eric Burger, to response to your question I disagree with the abstract/ = resume of the draft because The Lemonade WG draft introduction presents the work of OMA MEM as a = finished work, which in fact it is not. In the draft, it is stated that = the "realization of the architecture for the mobile email enabler (MEM) = [is specified] by the OMA"; however, this is inexact. In fact, this = realization is a work in progress, and has not been finalized. = Secondly, the draft statement indicates that the architecture uses = Internet mail protocols, which may appear slightly misleading. In fact, = this realization can use a variety of protocols (for example, OMA = Standard), and not only Internet mail protocols. Best Regards, Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 =20 -----Message d'origine----- De=A0: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] = Envoy=E9=A0: mardi 13 d=E9cembre 2005 22:37 =C0=A0: = eburger@brooktrout.com; SEGOND Hubert RD-BIZZ-CAE Cc=A0: = lemonade@ietf.org Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt The document in question has been reviewed in OMA MEM group. OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions. You should receive the liaison statement sometimes during next week = hopefully. Stephane and Glenn was present during the discussions - they know the = details. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of ext Burger, Eric Sent: 09 December, 2005 05:06 To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 = 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: = [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 14 12:23:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaLp-0000D0-Uc; Wed, 14 Dec 2005 12:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaLl-00009t-GA for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 12:23:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26640 for ; Wed, 14 Dec 2005 12:22:25 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmaMp-0008Nq-LN for lemonade@ietf.org; Wed, 14 Dec 2005 12:24:40 -0500 X-IronPort-AV: i="3.99,252,1131339600"; d="scan'208,217"; a="24188258:sNHT54917640" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Wed, 14 Dec 2005 12:23:18 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701A58A6D@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TAA8ZBAwAAW9SnAAA+fRVAAAJRKcAACY0vK From: "Burger, Eric" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Cc: lemonade@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0822429256==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0822429256== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C600D3.12CDF3FB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C600D3.12CDF3FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is where I would expect the information in the document to end up. = However, we needed to get the lemonade message out, and this was the = vehicle for it. Your comment highlights why we will most likely not invest the resources = to progress the document to RFC status. -----Original Message----- From: Corby.Wilson@nokia.com [mailto:Corby.Wilson@nokia.com] Sent: Wed Dec 14 12:05:24 2005 To: Burger, Eric; hubert.segond@francetelecom.com Cc: lemonade@ietf.org; Zoltan.Ordogh@nokia.com Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt If this is a realization of the OMA MEM architecture, shouldn't the OMA = define this instead of the IETF. The document seems severly out of place. Since this document ties us to = the OMA MEM arch, we must spend allot of time making sure the doc is = synched with the OMA MEM specs. I'm not sure having this document in the IETF is such a good idea since = it could bog us down and slow down progress even more. I would rather see us focusing on getting current drafts and technolgies = completed rather than worry about the OMA MEM architecutre.=20 Corby Wilson Security & Mobile Connectivity -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of ext Burger, Eric Sent: Wednesday, December 14, 2005 11:10 AM To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org; Ordogh Zoltan (Nokia-TP-MSW/Tampere) Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Now I understand. The abstract is probably poorly worded, which is something that can be = fixed. In fact, the comment highlights some important points. In particular: o The draft is a work group draft. This means the draft represents the view of the work group, and not of any particular individual's view. o The draft is an IETF work in progress similar to, as pointed out, the OMA work in progress. o The draft records the IETF's current view of a realization of the currently published MEM architecture, as sent by the OMA liaison to the IETF, using the lemonade suite. o In addition, the draft contains a pedagogical summary of the MEM Requirements and Architecture Documents for IETF readers' benefit. The lemonade work group needed a vehicle for communicating our thoughts = and plans to the OMA. The only vehicle we have for writing, debating, = and gaining consensus on documents is the Internet Draft, so that is = what the work group produced. It is important to note there has been no = decision as to whether this particular draft will ever be an RFC. I hope this clarifies the purpose and rationale for the draft. Your = comment is, in fact, part of the process and we welcome your further = participation in the work group. -----Original Message----- From: SEGOND Hubert RD-BIZZ-CAE [mailto:hubert.segond@francetelecom.com] Sent: Wednesday, December 14, 2005 4:06 AM To: Zoltan.Ordogh@nokia.com; Burger, Eric Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Hi all, I'm not participating to OMA meeting in Athens and I agree with the = OMA-MEM response. Eric Burger, to response to your question I disagree with the abstract/ = resume of the draft because The Lemonade WG draft introduction presents the work of OMA MEM as a = finished work, which in fact it is not. In the draft, it is stated that = the "realization of the architecture for the mobile email enabler (MEM) = [is specified] by the OMA"; however, this is inexact. In fact, this = realization is a work in progress, and has not been finalized. = Secondly, the draft statement indicates that the architecture uses = Internet mail protocols, which may appear slightly misleading. In fact, = this realization can use a variety of protocols (for example, OMA = Standard), and not only Internet mail protocols. Best Regards, Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 =20 -----Message d'origine----- De=A0: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] = Envoy=E9=A0: mardi 13 d=E9cembre 2005 22:37 =C0=A0: = eburger@brooktrout.com; SEGOND Hubert RD-BIZZ-CAE Cc=A0: = lemonade@ietf.org Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt The document in question has been reviewed in OMA MEM group. OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions. You should receive the liaison statement sometimes during next week = hopefully. Stephane and Glenn was present during the discussions - they know the = details. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of ext Burger, Eric Sent: 09 December, 2005 05:06 To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 = 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: = [lemonade] I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade ------_=_NextPart_001_01C600D3.12CDF3FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt</TITLE= > </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>That is where I would expect the information in the = document to end up.  However, we needed to get the lemonade message = out, and this was the vehicle for it.<BR> <BR> Your comment highlights why we will most likely not invest the resources = to progress the document to RFC status.<BR> <BR>  -----Original Message-----<BR> From:   Corby.Wilson@nokia.com [<A = HREF=3D"mailto:Corby.Wilson@nokia.com">mailto:Corby.Wilson@nokia.com</A>]= <BR> Sent:   Wed Dec 14 12:05:24 2005<BR> To:     Burger, Eric; = hubert.segond@francetelecom.com<BR> Cc:     lemonade@ietf.org; = Zoltan.Ordogh@nokia.com<BR> Subject:        RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> If this is a realization of the OMA MEM architecture, shouldn't the OMA = define this instead of the IETF.<BR> The document seems severly out of place.  Since this document ties = us to the OMA MEM arch, we must spend allot of time making sure the doc = is synched with the OMA MEM specs.<BR> I'm not sure having this document in the IETF is such a good idea since = it could bog us down and slow down progress even more.<BR> <BR> I would rather see us focusing on getting current drafts and technolgies = completed rather than worry about the OMA MEM architecutre.<BR> <BR> <BR> Corby Wilson<BR> Security & Mobile Connectivity<BR> <BR> <BR> -----Original Message-----<BR> From: lemonade-bounces@ietf.org [<A = HREF=3D"mailto:lemonade-bounces@ietf.org">mailto:lemonade-bounces@ietf.or= g</A>] On Behalf Of ext Burger, Eric<BR> Sent: Wednesday, December 14, 2005 11:10 AM<BR> To: SEGOND Hubert RD-BIZZ-CAE<BR> Cc: lemonade@ietf.org; Ordogh Zoltan (Nokia-TP-MSW/Tampere)<BR> Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> Now I understand.<BR> <BR> The abstract is probably poorly worded, which is something that can be = fixed.  In fact, the comment highlights some important points.<BR> <BR> In particular:<BR> o  The draft is a work group draft.  This means the draft = represents<BR>    the view of the work group, and not of any particular = individual's<BR>    view.<BR> <BR> o  The draft is an IETF work in progress similar to, as pointed = out,<BR>    the OMA work in progress.<BR> <BR> o  The draft records the IETF's current view of a realization of = the<BR>    currently published MEM architecture, as sent by the OMA = liaison<BR>    to the IETF, using the lemonade suite.<BR> <BR> o  In addition, the draft contains a pedagogical summary of the = MEM<BR>    Requirements and Architecture Documents for IETF readers' = benefit.<BR> <BR> <BR> The lemonade work group needed a vehicle for communicating our thoughts = and plans to the OMA.  The only vehicle we have for writing, = debating, and gaining consensus on documents is the Internet Draft, so = that is what the work group produced.  It is important to note = there has been no decision as to whether this particular draft will ever = be an RFC.<BR> <BR> I hope this clarifies the purpose and rationale for the draft.  = Your comment is, in fact, part of the process and we welcome your = further participation in the work group.<BR> <BR> <BR> -----Original Message-----<BR> From: SEGOND Hubert RD-BIZZ-CAE [<A = HREF=3D"mailto:hubert.segond@francetelecom.com">mailto:hubert.segond@fran= cetelecom.com</A>]<BR> Sent: Wednesday, December 14, 2005 4:06 AM<BR> To: Zoltan.Ordogh@nokia.com; Burger, Eric<BR> Cc: lemonade@ietf.org<BR> Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> Hi all,<BR> <BR> I'm not participating to OMA meeting in Athens and I agree with the = OMA-MEM response.<BR> <BR> Eric Burger, to response to your question I disagree with the abstract/ = resume of the draft because<BR> <BR> The Lemonade WG draft introduction presents the work of OMA MEM as a = finished work, which in fact it is not.  In the draft, it is stated = that the "realization of the architecture for the mobile email = enabler (MEM) [is specified] by the OMA"; however, this is = inexact.  In fact, this realization is a work in progress, and has = not been finalized.  Secondly, the draft statement indicates that = the architecture uses Internet mail protocols, which may appear slightly = misleading.  In fact, this realization can use a variety of = protocols (for example, OMA Standard), and not only Internet mail = protocols.<BR> <BR> Best Regards,<BR> <BR> Hubert Segond<BR> France T=E9l=E9com - Division R&D<BR> 42, rue des Coutures BP 6243 CAEN Cedex 4<BR> Tel: +33 (0)2 31 75 90 98<BR> <BR> <BR> -----Message d'origine-----<BR> De=A0: Zoltan.Ordogh@nokia.com [<A = HREF=3D"mailto:Zoltan.Ordogh@nokia.com">mailto:Zoltan.Ordogh@nokia.com</A= >] Envoy=E9=A0: mardi 13 d=E9cembre 2005 22:37 =C0=A0: = eburger@brooktrout.com; SEGOND Hubert RD-BIZZ-CAE Cc=A0: = lemonade@ietf.org Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> The document in question has been reviewed in OMA MEM group.<BR> OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions.<BR> You should receive the liaison statement sometimes during next week = hopefully.<BR> Stephane and Glenn was present during the discussions - they know the = details.<BR> <BR> Best regards: Zolt=E1n =D6rd=F6gh<BR> E-mail: zoltan.ordogh@nokia.com<BR> Phone: +358 50 386 0566<BR> <BR> <BR> -----Original Message-----<BR> From: lemonade-bounces@ietf.org [<A = HREF=3D"mailto:lemonade-bounces@ietf.org">mailto:lemonade-bounces@ietf.or= g</A>]On<BR> Behalf Of ext Burger, Eric<BR> Sent: 09 December, 2005 05:06<BR> To: SEGOND Hubert RD-BIZZ-CAE<BR> Cc: lemonade@ietf.org<BR> Subject: RE:<BR> [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> <BR> What specifically do you disagree with in the draft?<BR> <BR> -----Original Message-----<BR> From: lemonade-bounces@ietf.org [<A = HREF=3D"mailto:lemonade-bounces@ietf.org">mailto:lemonade-bounces@ietf.or= g</A>] On Behalf Of SEGOND Hubert RD-BIZZ-CAE<BR> Sent: Thursday, December 08, 2005 10:54 AM<BR> To: Internet-Drafts@ietf.org; i-d-announce@ietf.org<BR> Cc: lemonade@ietf.org<BR> Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> <BR> Hi All,<BR> <BR> "Realization of the architecture as specified by the OMA, using = Internet<BR>    Mail protocols Internet"  ???<BR>   <BR> I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today.<BR> <BR> I disagree with this draft.<BR> <BR> Best Regards,<BR> <BR> Hubert Segond<BR> France T=E9l=E9com - Division R&D<BR> 42, rue des Coutures BP 6243 CAEN Cedex 4<BR> Tel: +33 (0)2 31 75 90 98<BR> <BR> <BR> <BR> -----Message d'origine-----<BR> De=A0: lemonade-bounces@ietf.org [<A = HREF=3D"mailto:lemonade-bounces@ietf.org">mailto:lemonade-bounces@ietf.or= g</A>] De la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 = d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: = lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt<BR> <BR> A New Internet-Draft is available from the on-line Internet-Drafts = directories.<BR> This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF.<BR> <BR>         Title   =         : Realization of OMA Mobile = Email (MEM) Architecture using Internet Mail<BR>         = Author(s)       : S. Maes, G. Parsons<BR>         = Filename        : = draft-ietf-lemonade-oma-mem-realization-00.txt<BR>         Pages   =         : 33<BR>         Date    =         : 2005-12-7<BR>        <BR>    This document specifies a realization of the architecture = for the<BR>    mobile email enabler (MEM) as specified by the OMA, using = Internet<BR>    Mail protocols.<BR> <BR> A URL for this Internet-Draft is:<BR> <A = HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-r= ealization-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-lemonad= e-oma-mem-realization-00.txt</A><BR> <BR> 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. <BR> You can also visit <A = HREF=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1= .ietf.org/mailman/listinfo/I-D-announce</A><BR> to change your subscription settings.<BR> <BR> <BR> 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<BR>         "get = draft-ietf-lemonade-oma-mem-realization-00.txt".<BR> <BR> A list of Internet-Drafts directories can be found in <A = HREF=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<= /A> or <A = HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet= f/1shadow-sites.txt</A><BR> <BR> <BR> Internet-Drafts can also be obtained by e-mail.<BR> <BR> Send a message to:<BR>         mailserv@ietf.org.<BR> In the body type:<BR>         "FILE = /internet-drafts/draft-ietf-lemonade-oma-mem-realization-00.txt".<BR= >        <BR> NOTE:   The mail server at ietf.org can return the document = in<BR>         MIME-encoded form by using = the "mpack" utility.  To use this<BR>         feature, insert the command = "ENCODING mime" before the "FILE"<BR>         command.  To decode the = response(s), you will need "munpack" or<BR>         a MIME-compliant mail = reader.  Different MIME-compliant mail readers<BR>         exhibit different behavior, = especially when dealing with<BR>         "multipart" MIME = messages (i.e. documents which have been split<BR>         up into multiple messages), = so check your local documentation on<BR>         how to manipulate these = messages.<BR>         =        <BR>         =        <BR> Below is the data which will enable a MIME compliant mail reader<BR> implementation to automatically retrieve the ASCII version of the<BR> Internet-Draft.<BR> <BR> _______________________________________________<BR> lemonade mailing list<BR> lemonade@ietf.org<BR> <A = HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade">https://www1.iet= f.org/mailman/listinfo/lemonade</A><BR> <BR> _______________________________________________<BR> lemonade mailing list<BR> lemonade@ietf.org<BR> <A = HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade">https://www1.iet= f.org/mailman/listinfo/lemonade</A><BR> <BR> _______________________________________________<BR> lemonade mailing list<BR> lemonade@ietf.org<BR> <A = HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade">https://www1.iet= f.org/mailman/listinfo/lemonade</A><BR> <BR> _______________________________________________<BR> lemonade mailing list<BR> lemonade@ietf.org<BR> <A = HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade">https://www1.iet= f.org/mailman/listinfo/lemonade</A><BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C600D3.12CDF3FB-- --===============0822429256== 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 --===============0822429256==-- From lemonade-bounces@ietf.org Wed Dec 14 13:22:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbGW-0003lY-M7; Wed, 14 Dec 2005 13:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbGP-0003k5-90 for lemonade@megatron.ietf.org; Wed, 14 Dec 2005 13:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05196 for <lemonade@ietf.org>; Wed, 14 Dec 2005 13:20:58 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmbHW-0002e5-Mv for lemonade@ietf.org; Wed, 14 Dec 2005 13:23:15 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 19:21:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Date: Wed, 14 Dec 2005 19:22:42 +0100 Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD101CE7FF1@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Thread-Index: AcX7i6hHXv9l37U3SD2ZgApN/lHHuAAg5tugABXW2TAA8ZBAwAAW9SnAAA+fRVAABQJZUA== From: "SEGOND Hubert RD-BIZZ-CAE" <hubert.segond@francetelecom.com> To: "Burger, Eric" <eburger@brooktrout.com> X-OriginalArrivalTime: 14 Dec 2005 18:21:55.0066 (UTC) FILETIME=[432035A0:01C600DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, 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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Thanks Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 =20 -----Message d'origine----- De=A0: Burger, Eric [mailto:eburger@brooktrout.com]=20 Envoy=E9=A0: mercredi 14 d=E9cembre 2005 17:10 =C0=A0: SEGOND Hubert RD-BIZZ-CAE Cc=A0: lemonade@ietf.org; Zoltan.Ordogh@nokia.com Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Now I understand. The abstract is probably poorly worded, which is something that can be = fixed. In fact, the comment highlights some important points. In particular: o The draft is a work group draft. This means the draft represents the view of the work group, and not of any particular individual's view. o The draft is an IETF work in progress similar to, as pointed out, the OMA work in progress. o The draft records the IETF's current view of a realization of the currently published MEM architecture, as sent by the OMA liaison to the IETF, using the lemonade suite. o In addition, the draft contains a pedagogical summary of the MEM Requirements and Architecture Documents for IETF readers' benefit. The lemonade work group needed a vehicle for communicating our thoughts = and plans to the OMA. The only vehicle we have for writing, debating, = and gaining consensus on documents is the Internet Draft, so that is = what the work group produced. It is important to note there has been no = decision as to whether this particular draft will ever be an RFC. I hope this clarifies the purpose and rationale for the draft. Your = comment is, in fact, part of the process and we welcome your further = participation in the work group. -----Original Message----- From: SEGOND Hubert RD-BIZZ-CAE [mailto:hubert.segond@francetelecom.com] = Sent: Wednesday, December 14, 2005 4:06 AM To: Zoltan.Ordogh@nokia.com; Burger, Eric Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Hi all, I'm not participating to OMA meeting in Athens and I agree with the = OMA-MEM response. Eric Burger, to response to your question I disagree with the abstract/ = resume of the draft because The Lemonade WG draft introduction presents the work of OMA MEM as a = finished work, which in fact it is not. In the draft, it is stated that = the "realization of the architecture for the mobile email enabler (MEM) = [is specified] by the OMA"; however, this is inexact. In fact, this = realization is a work in progress, and has not been finalized. = Secondly, the draft statement indicates that the architecture uses = Internet mail protocols, which may appear slightly misleading. In fact, = this realization can use a variety of protocols (for example, OMA = Standard), and not only Internet mail protocols. Best Regards, Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 =20 -----Message d'origine----- De=A0: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Envoy=E9=A0: mardi 13 d=E9cembre 2005 22:37 =C0=A0: eburger@brooktrout.com; SEGOND Hubert RD-BIZZ-CAE Cc=A0: lemonade@ietf.org Objet=A0: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt The document in question has been reviewed in OMA MEM group. OMA MEM has drafed a liaison statement which includes the OMA MEM = comments/questions. You should receive the liaison statement sometimes during next week = hopefully. Stephane and Glenn was present during the discussions - they know the = details. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of ext Burger, Eric Sent: 09 December, 2005 05:06 To: SEGOND Hubert RD-BIZZ-CAE Cc: lemonade@ietf.org Subject: RE: [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt What specifically do you disagree with in the draft? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of SEGOND Hubert RD-BIZZ-CAE Sent: Thursday, December 08, 2005 10:54 AM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: RE: = [lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 Hi All, "Realization of the architecture as specified by the OMA, using Internet Mail protocols Internet" ??? =20 I 'm working an OMA MEM Working Group (like Orange SA delegate) and I = can assure that any OMA MEM architecture document is ready, we just are = studying the architecture in the OMA group and the architecture is not = specified or finalized today. I disagree with this draft. Best Regards,=20 Hubert Segond France T=E9l=E9com - Division R&D 42, rue des Coutures BP 6243 CAEN Cedex 4 Tel: +33 (0)2 31 75 90 98 -----Message d'origine----- De=A0: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9=A0: jeudi 8 d=E9cembre 2005 00:50 =C0=A0: i-d-announce@ietf.org Cc=A0: lemonade@ietf.org Objet=A0: [lemonade] = I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt=20 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 : Realization of OMA Mobile Email (MEM) Architecture using = Internet Mail Author(s) : S. Maes, G. Parsons Filename : draft-ietf-lemonade-oma-mem-realization-00.txt Pages : 33 Date : 2005-12-7 =09 This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-oma-mem-realizati= on-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-oma-mem-realization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-oma-mem-realization-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 15 22:19:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En686-0003pc-2u; Thu, 15 Dec 2005 22:19:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En67t-0003ko-OO; Thu, 15 Dec 2005 22:19:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23492; Thu, 15 Dec 2005 22:18:21 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En69Q-0003F9-LH; Thu, 15 Dec 2005 22:20:56 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1En67t-0002Ok-0E; Thu, 15 Dec 2005 22:19:21 -0500 X-test-idtracker: no To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Message-Id: <E1En67t-0002Ok-0E@newodin.ietf.org> Date: Thu, 15 Dec 2005 22:19:21 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org Subject: [lemonade] Last Call: 'Lemonade Profile' to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The IESG has received a request from the Enhancements to Internet email to support diverse service environments WG to consider the following document: - 'Lemonade Profile ' <draft-ietf-lemonade-profile-06.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-06.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 16 14:33:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLKI-0001ia-5R; Fri, 16 Dec 2005 14:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emm5p-0004Lf-3V for lemonade@megatron.ietf.org; Thu, 15 Dec 2005 00:55:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17816 for <lemonade@ietf.org>; Thu, 15 Dec 2005 00:54:53 -0500 (EST) Received: from webmail.chinamobile.com ([211.136.27.4] helo=cmccmta) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emm79-0002R1-I3 for lemonade@ietf.org; Thu, 15 Dec 2005 00:57:16 -0500 Received: from fanxiaohui ([10.1.5.34]) by mail.chinamobile.com (Lotus Domino Release 5.0.12HF438) with SMTP id 2005121513581191:4208 ; Thu, 15 Dec 2005 13:58:11 +0800 Date: Thu, 15 Dec 2005 13:51:35 +0800 From: "Xiaohui Fan" <fanxiaohui@chinamobile.com> To: "Corby.Wilson@nokia.com" <Corby.Wilson@nokia.com>, "eburger@brooktrout.com" <eburger@brooktrout.com>, "hubert.segond@francetelecom.com" <hubert.segond@francetelecom.com> Subject: Re: RE:[lemonade]I-DACTION:draft-ietf-lemonade-oma-mem-realization-00.txt Organization: cmcc X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 5.0.12HF438 | October 15, 2003) at 2005-12-15 01:58:12 PM, Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2005-12-15 01:49:25 PM, Serialize complete at 2005-12-15 01:49:25 PM Message-ID: <OFB4542E4B.B07600BC-ONC82570D8.0020CB53@LocalDomain> X-Spam-Score: 1.1 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d X-Mailman-Approved-At: Fri, 16 Dec 2005 14:33:07 -0500 Cc: "lemonade@ietf.org" <lemonade@ietf.org>, "Zoltan.Ordogh@nokia.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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0486875620==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0486875620== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q29vcGVhcmlvbiBhbW9uZyBzdGFuZGFyZCBvcmdhbml6YXRpb25zIGlzIHZlcnkgY29tbW9uLiBU aGUgYWN0aW9uIGlzIHN1aXRhYmxlLiANCg0KQWx0aG91Z2ggdGhlIG1lbSBBRCBpcyBkZWZpbmVk IGJ5IE9NQSwgaXQgc2hhbGwgbm90IHNpbXBseSB0aGluayB0aGF0IHRoZSB3b3JrIG9mIGRlZmlu aW5nIHNwZWNzIGFuZCANCnRlY2hub2xpZ2llcyBiZSBkb25lIG9ubHkgaW4gT01BIGVzcGVjaWFs bHkgZm9yIG1vYmlsZSBlbWFpbC4gIA0KDQpJRVRGIGVtYWlsIHByb3RvY29scyBhcmUgdmVyeSBw b3B1bGFyIGFyb3VuZCB0aGUgd29ybGQuIFRoZSByZWFsaXphdGlvbiBvZiBtb2JpbGUgZW1haWwg dXNpbmcgSUVURiANCnByb3RvY29scyB3aGljaCBtYXkgaGF2ZSBoaWdoZXIgY29tcGF0aWJpbGl0 eSBhbmQgcGVyZm9ybWFuY2UgaXMgZXh0cmVtZWx5IG5lY2Vzc2FyeS4NCg0KSSBhZ3JlZSB0aGF0 IHdlIHNob3VsZCBhbHNvIGZvY3VzIG9uIGdldHRpbmcgY3VycmVudCBBRCBkcmFmdCBjb21wbGF0 ZWQuIEJ1dCBpdCBpcyBhIHBpdHkgdGhlIGZvcm1hbA0KcmV2aWV3IHN0aWxsIG5vdCBiZWdpbiBl dmVuIGFmdGVyIG9tYSBtZWV0aW5nIGluIEF0aGVucy4NCg0KPT09PT09PSAyMDA1LTEyLTE1IDAw OjE3OjM0IFlvdSB3cm90ZaO6PT09PT09PQ0KDQo+SWYgdGhpcyBpcyBhIHJlYWxpemF0aW9uIG9m IHRoZSBPTUEgTUVNIGFyY2hpdGVjdHVyZSwgc2hvdWxkbid0IHRoZSBPTUEgZGVmaW5lIHRoaXMg aW5zdGVhZCBvZiB0aGUgSUVURi4NCj5UaGUgZG9jdW1lbnQgc2VlbXMgc2V2ZXJseSBvdXQgb2Yg cGxhY2UuICBTaW5jZSB0aGlzIGRvY3VtZW50IHRpZXMgdXMgdG8gdGhlIE9NQSBNRU0gYXJjaCwg d2UgbXVzdCBzcGVuZCBhbGxvdCBvZiB0aW1lIG1ha2luZyBzdXJlIHRoZSBkb2MgaXMgc3luY2hl ZCB3aXRoIHRoZSBPTUEgTUVNIHNwZWNzLg0KPkknbSBub3Qgc3VyZSBoYXZpbmcgdGhpcyBkb2N1 bWVudCBpbiB0aGUgSUVURiBpcyBzdWNoIGEgZ29vZCBpZGVhIHNpbmNlIGl0IGNvdWxkIGJvZyB1 cyBkb3duIGFuZCBzbG93IGRvd24gcHJvZ3Jlc3MgZXZlbiBtb3JlLg0KPg0KPkkgd291bGQgcmF0 aGVyIHNlZSB1cyBmb2N1c2luZyBvbiBnZXR0aW5nIGN1cnJlbnQgZHJhZnRzIGFuZCB0ZWNobm9s Z2llcyBjb21wbGV0ZWQgcmF0aGVyIHRoYW4gd29ycnkgYWJvdXQgdGhlIE9NQSBNRU0gYXJjaGl0 ZWN1dHJlLiANCj4NCj4NCj5Db3JieSBXaWxzb24NCj5TZWN1cml0eSAmIE1vYmlsZSBDb25uZWN0 aXZpdHkNCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGxlbW9uYWRl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsZW1vbmFkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgZXh0IEJ1cmdlciwgRXJpYw0KPlNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTQs IDIwMDUgMTE6MTAgQU0NCj5UbzogU0VHT05EIEh1YmVydCBSRC1CSVpaLUNBRQ0KPkNjOiBsZW1v bmFkZUBpZXRmLm9yZzsgT3Jkb2doIFpvbHRhbiAoTm9raWEtVFAtTVNXL1RhbXBlcmUpDQo+U3Vi amVjdDogUkU6IFtsZW1vbmFkZV1JLURBQ1RJT046ZHJhZnQtaWV0Zi1sZW1vbmFkZS1vbWEtbWVt LXJlYWxpemF0aW9uLTAwLnR4dA0KPg0KPk5vdyBJIHVuZGVyc3RhbmQuDQo+DQo+VGhlIGFic3Ry YWN0IGlzIHByb2JhYmx5IHBvb3JseSB3b3JkZWQsIHdoaWNoIGlzIHNvbWV0aGluZyB0aGF0IGNh biBiZSBmaXhlZC4gIEluIGZhY3QsIHRoZSBjb21tZW50IGhpZ2hsaWdodHMgc29tZSBpbXBvcnRh bnQgcG9pbnRzLg0KPg0KPkluIHBhcnRpY3VsYXI6DQo+byAgVGhlIGRyYWZ0IGlzIGEgd29yayBn cm91cCBkcmFmdC4gIFRoaXMgbWVhbnMgdGhlIGRyYWZ0IHJlcHJlc2VudHMNCj4gICB0aGUgdmll dyBvZiB0aGUgd29yayBncm91cCwgYW5kIG5vdCBvZiBhbnkgcGFydGljdWxhciBpbmRpdmlkdWFs J3MNCj4gICB2aWV3Lg0KPg0KPm8gIFRoZSBkcmFmdCBpcyBhbiBJRVRGIHdvcmsgaW4gcHJvZ3Jl c3Mgc2ltaWxhciB0bywgYXMgcG9pbnRlZCBvdXQsDQo+ICAgdGhlIE9NQSB3b3JrIGluIHByb2dy ZXNzLg0KPg0KPm8gIFRoZSBkcmFmdCByZWNvcmRzIHRoZSBJRVRGJ3MgY3VycmVudCB2aWV3IG9m IGEgcmVhbGl6YXRpb24gb2YgdGhlDQo+ICAgY3VycmVudGx5IHB1Ymxpc2hlZCBNRU0gYXJjaGl0 ZWN0dXJlLCBhcyBzZW50IGJ5IHRoZSBPTUEgbGlhaXNvbg0KPiAgIHRvIHRoZSBJRVRGLCB1c2lu ZyB0aGUgbGVtb25hZGUgc3VpdGUuDQo+DQo+byAgSW4gYWRkaXRpb24sIHRoZSBkcmFmdCBjb250 YWlucyBhIHBlZGFnb2dpY2FsIHN1bW1hcnkgb2YgdGhlIE1FTQ0KPiAgIFJlcXVpcmVtZW50cyBh bmQgQXJjaGl0ZWN0dXJlIERvY3VtZW50cyBmb3IgSUVURiByZWFkZXJzJyBiZW5lZml0Lg0KPg0K Pg0KPlRoZSBsZW1vbmFkZSB3b3JrIGdyb3VwIG5lZWRlZCBhIHZlaGljbGUgZm9yIGNvbW11bmlj YXRpbmcgb3VyIHRob3VnaHRzIGFuZCBwbGFucyB0byB0aGUgT01BLiAgVGhlIG9ubHkgdmVoaWNs ZSB3ZSBoYXZlIGZvciB3cml0aW5nLCBkZWJhdGluZywgYW5kIGdhaW5pbmcgY29uc2Vuc3VzIG9u IGRvY3VtZW50cyBpcyB0aGUgSW50ZXJuZXQgRHJhZnQsIHNvIHRoYXQgaXMgd2hhdCB0aGUgd29y ayBncm91cCBwcm9kdWNlZC4gIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoZXJlIGhhcyBiZWVu IG5vIGRlY2lzaW9uIGFzIHRvIHdoZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0IHdpbGwgZXZl ciBiZSBhbiBSRkMuDQo+DQo+SSBob3BlIHRoaXMgY2xhcmlmaWVzIHRoZSBwdXJwb3NlIGFuZCBy YXRpb25hbGUgZm9yIHRoZSBkcmFmdC4gIFlvdXIgY29tbWVudCBpcywgaW4gZmFjdCwgcGFydCBv ZiB0aGUgcHJvY2VzcyBhbmQgd2Ugd2VsY29tZSB5b3VyIGZ1cnRoZXIgcGFydGljaXBhdGlvbiBp biB0aGUgd29yayBncm91cC4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZy b206IFNFR09ORCBIdWJlcnQgUkQtQklaWi1DQUUgW21haWx0bzpodWJlcnQuc2Vnb25kQGZyYW5j ZXRlbGVjb20uY29tXQ0KPlNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTQsIDIwMDUgNDowNiBB TQ0KPlRvOiBab2x0YW4uT3Jkb2doQG5va2lhLmNvbTsgQnVyZ2VyLCBFcmljDQo+Q2M6IGxlbW9u YWRlQGlldGYub3JnDQo+U3ViamVjdDogUkU6IFtsZW1vbmFkZV1JLURBQ1RJT046ZHJhZnQtaWV0 Zi1sZW1vbmFkZS1vbWEtbWVtLXJlYWxpemF0aW9uLTAwLnR4dA0KPg0KPkhpIGFsbCwNCj4NCj5J J20gbm90IHBhcnRpY2lwYXRpbmcgdG8gT01BIG1lZXRpbmcgaW4gQXRoZW5zIGFuZCBJIGFncmVl IHdpdGggdGhlIE9NQS1NRU0gcmVzcG9uc2UuDQo+DQo+RXJpYyBCdXJnZXIsIHRvIHJlc3BvbnNl IHRvIHlvdXIgcXVlc3Rpb24gSSBkaXNhZ3JlZSB3aXRoIHRoZSBhYnN0cmFjdC8gcmVzdW1lIG9m IHRoZSBkcmFmdCBiZWNhdXNlDQo+DQo+VGhlIExlbW9uYWRlIFdHIGRyYWZ0IGludHJvZHVjdGlv biBwcmVzZW50cyB0aGUgd29yayBvZiBPTUEgTUVNIGFzIGEgZmluaXNoZWQgd29yaywgd2hpY2gg aW4gZmFjdCBpdCBpcyBub3QuICBJbiB0aGUgZHJhZnQsIGl0IGlzIHN0YXRlZCB0aGF0IHRoZSAi cmVhbGl6YXRpb24gb2YgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIG1vYmlsZSBlbWFpbCBlbmFi bGVyIChNRU0pIFtpcyBzcGVjaWZpZWRdIGJ5IHRoZSBPTUEiOyBob3dldmVyLCB0aGlzIGlzIGlu ZXhhY3QuICBJbiBmYWN0LCB0aGlzIHJlYWxpemF0aW9uIGlzIGEgd29yayBpbiBwcm9ncmVzcywg YW5kIGhhcyBub3QgYmVlbiBmaW5hbGl6ZWQuICBTZWNvbmRseSwgdGhlIGRyYWZ0IHN0YXRlbWVu dCBpbmRpY2F0ZXMgdGhhdCB0aGUgYXJjaGl0ZWN0dXJlIHVzZXMgSW50ZXJuZXQgbWFpbCBwcm90 b2NvbHMsIHdoaWNoIG1heSBhcHBlYXIgc2xpZ2h0bHkgbWlzbGVhZGluZy4gIEluIGZhY3QsIHRo aXMgcmVhbGl6YXRpb24gY2FuIHVzZSBhIHZhcmlldHkgb2YgcHJvdG9jb2xzIChmb3IgZXhhbXBs ZSwgT01BIFN0YW5kYXJkKSwgYW5kIG5vdCBvbmx5IEludGVybmV0IG1haWwgcHJvdG9jb2xzLg0K Pg0KPkJlc3QgUmVnYXJkcywNCj4NCj5IdWJlcnQgU2Vnb25kDQo+RnJhbmNlIFTpbOljb20gLSBE aXZpc2lvbiBSJkQNCj40MiwgcnVlIGRlcyBDb3V0dXJlcyBCUCA2MjQzIENBRU4gQ2VkZXggNA0K PlRlbDogKzMzICgwKTIgMzEgNzUgOTAgOTgNCj4gDQo+DQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+RGU/IFpvbHRhbi5PcmRvZ2hAbm9raWEuY29tIFttYWlsdG86Wm9sdGFuLk9yZG9n aEBub2tpYS5jb21dIEVudm956aA6IG1hcmRpIDEzIGTpY2VtYnJlIDIwMDUgMjI6MzcgwKA6IGVi dXJnZXJAYnJvb2t0cm91dC5jb207IFNFR09ORCBIdWJlcnQgUkQtQklaWi1DQUUgQ2M/IGxlbW9u YWRlQGlldGYub3JnIE9iamV0PyBSRTogW2xlbW9uYWRlXUktREFDVElPTjpkcmFmdC1pZXRmLWxl bW9uYWRlLW9tYS1tZW0tcmVhbGl6YXRpb24tMDAudHh0DQo+DQo+VGhlIGRvY3VtZW50IGluIHF1 ZXN0aW9uIGhhcyBiZWVuIHJldmlld2VkIGluIE9NQSBNRU0gZ3JvdXAuDQo+T01BIE1FTSBoYXMg ZHJhZmVkIGEgbGlhaXNvbiBzdGF0ZW1lbnQgd2hpY2ggaW5jbHVkZXMgdGhlIE9NQSBNRU0gY29t bWVudHMvcXVlc3Rpb25zLg0KPllvdSBzaG91bGQgcmVjZWl2ZSB0aGUgbGlhaXNvbiBzdGF0ZW1l bnQgc29tZXRpbWVzIGR1cmluZyBuZXh0IHdlZWsgaG9wZWZ1bGx5Lg0KPlN0ZXBoYW5lIGFuZCBH bGVubiB3YXMgcHJlc2VudCBkdXJpbmcgdGhlIGRpc2N1c3Npb25zIC0gdGhleSBrbm93IHRoZSBk ZXRhaWxzLg0KPg0KPkJlc3QgcmVnYXJkczogWm9sdOFuINZyZPZnaA0KPkUtbWFpbDogem9sdGFu Lm9yZG9naEBub2tpYS5jb20NCj5QaG9uZTogKzM1OCA1MCAzODYgMDU2Ng0KPg0KPg0KPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbGVtb25hZGUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmxlbW9uYWRlLWJvdW5jZXNAaWV0Zi5vcmddT24NCj5CZWhhbGYgT2YgZXh0IEJ1cmdl ciwgRXJpYw0KPlNlbnQ6IDA5IERlY2VtYmVyLCAyMDA1IDA1OjA2DQo+VG86IFNFR09ORCBIdWJl cnQgUkQtQklaWi1DQUUNCj5DYzogbGVtb25hZGVAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRToNCj5b bGVtb25hZGVdSS1EQUNUSU9OOmRyYWZ0LWlldGYtbGVtb25hZGUtb21hLW1lbS1yZWFsaXphdGlv bi0wMC50eHQNCj4NCj4NCj5XaGF0IHNwZWNpZmljYWxseSBkbyB5b3UgZGlzYWdyZWUgd2l0aCBp biB0aGUgZHJhZnQ/DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBsZW1v bmFkZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bGVtb25hZGUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFNFR09ORCBIdWJlcnQgUkQtQklaWi1DQUUNCj5TZW50OiBUaHVyc2RheSwg RGVjZW1iZXIgMDgsIDIwMDUgMTA6NTQgQU0NCj5UbzogSW50ZXJuZXQtRHJhZnRzQGlldGYub3Jn OyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj5DYzogbGVtb25hZGVAaWV0Zi5vcmcNCj5TdWJqZWN0 OiBSRTogW2xlbW9uYWRlXUktREFDVElPTjpkcmFmdC1pZXRmLWxlbW9uYWRlLW9tYS1tZW0tcmVh bGl6YXRpb24tMDAudHh0IA0KPg0KPg0KPkhpIEFsbCwNCj4NCj4iUmVhbGl6YXRpb24gb2YgdGhl IGFyY2hpdGVjdHVyZSBhcyBzcGVjaWZpZWQgYnkgdGhlIE9NQSwgdXNpbmcgSW50ZXJuZXQNCj4g ICBNYWlsIHByb3RvY29scyBJbnRlcm5ldCIgID8/Pw0KPiAgIA0KPkkgJ20gd29ya2luZyBhbiBP TUEgTUVNIFdvcmtpbmcgR3JvdXAgKGxpa2UgT3JhbmdlIFNBIGRlbGVnYXRlKSBhbmQgSSBjYW4g YXNzdXJlIHRoYXQgYW55IE9NQSBNRU0gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGlzIHJlYWR5LCB3 ZSBqdXN0IGFyZSBzdHVkeWluZyB0aGUgYXJjaGl0ZWN0dXJlIGluIHRoZSBPTUEgZ3JvdXAgYW5k IHRoZSBhcmNoaXRlY3R1cmUgaXMgbm90IHNwZWNpZmllZCBvciBmaW5hbGl6ZWQgdG9kYXkuDQo+ DQo+SSBkaXNhZ3JlZSB3aXRoIHRoaXMgZHJhZnQuDQo+DQo+QmVzdCBSZWdhcmRzLCANCj4NCj5I dWJlcnQgU2Vnb25kDQo+RnJhbmNlIFTpbOljb20gLSBEaXZpc2lvbiBSJkQNCj40MiwgcnVlIGRl cyBDb3V0dXJlcyBCUCA2MjQzIENBRU4gQ2VkZXggNA0KPlRlbDogKzMzICgwKTIgMzEgNzUgOTAg OTgNCj4NCj4NCj4NCj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj5EZT8gbGVtb25hZGUt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxlbW9uYWRlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnIEVudm956aA6IGpldWRpIDggZOljZW1i cmUgMjAwNSAwMDo1MCDAoDogaS1kLWFubm91bmNlQGlldGYub3JnIENjPyBsZW1vbmFkZUBpZXRm Lm9yZyBPYmpldD8gW2xlbW9uYWRlXSBJLURBQ1RJT046ZHJhZnQtaWV0Zi1sZW1vbmFkZS1vbWEt bWVtLXJlYWxpemF0aW9uLTAwLnR4dCANCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+VGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRW5oYW5jZW1lbnRzIHRvIEludGVybmV0IGVt YWlsIHRvIHN1cHBvcnQgZGl2ZXJzZSBzZXJ2aWNlIGVudmlyb25tZW50cyBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLg0KPg0KPglUaXRsZQkJOiBSZWFsaXphdGlvbiBvZiBPTUEgTW9iaWxlIEVt YWlsIChNRU0pIEFyY2hpdGVjdHVyZSB1c2luZyBJbnRlcm5ldCBNYWlsDQo+CUF1dGhvcihzKQk6 IFMuIE1hZXMsIEcuIFBhcnNvbnMNCj4JRmlsZW5hbWUJOiBkcmFmdC1pZXRmLWxlbW9uYWRlLW9t YS1tZW0tcmVhbGl6YXRpb24tMDAudHh0DQo+CVBhZ2VzCQk6IDMzDQo+CURhdGUJCTogMjAwNS0x Mi03DQo+CQ0KPiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgcmVhbGl6YXRpb24gb2YgdGhl IGFyY2hpdGVjdHVyZSBmb3IgdGhlDQo+ICAgbW9iaWxlIGVtYWlsIGVuYWJsZXIgKE1FTSkgYXMg c3BlY2lmaWVkIGJ5IHRoZSBPTUEsIHVzaW5nIEludGVybmV0DQo+ICAgTWFpbCBwcm90b2NvbHMu DQo+DQo+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sZW1vbmFkZS1vbWEtbWVtLXJlYWxpemF0 aW9uLTAwLnR4dA0KPg0KPlRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9tIHRoZSBJLUQgQW5ub3VuY2Vt ZW50IGxpc3QsIHNlbmQgYSBtZXNzYWdlIHRvIGktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3Jn IHdpdGggdGhlIHdvcmQgdW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UuICAN Cj5Zb3UgY2FuIGFsc28gdmlzaXQgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vSS1ELWFubm91bmNlDQo+dG8gY2hhbmdlIHlvdXIgc3Vic2NyaXB0aW9uIHNldHRpbmdzLg0K Pg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UC4gTG9naW4gd2l0aCB0aGUgdXNlcm5hbWUgImFub255bW91cyIgYW5kIGEgcGFzc3dvcmQgb2Yg eW91ciBlLW1haWwgYWRkcmVzcy4gQWZ0ZXIgbG9nZ2luZyBpbiwgdHlwZSAiY2QgaW50ZXJuZXQt ZHJhZnRzIiBhbmQgdGhlbg0KPgkiZ2V0IGRyYWZ0LWlldGYtbGVtb25hZGUtb21hLW1lbS1yZWFs aXphdGlvbi0wMC50eHQiLg0KPg0KPkEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMgY2FuIGJlIGZvdW5kIGluIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4NCj4NCj5JbnRlcm5ldC1E cmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLg0KPg0KPlNlbmQgYSBtZXNzYWdl IHRvOg0KPgltYWlsc2VydkBpZXRmLm9yZy4NCj5JbiB0aGUgYm9keSB0eXBlOg0KPgkiRklMRSAv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbGVtb25hZGUtb21hLW1lbS1yZWFsaXphdGlvbi0w MC50eHQiLg0KPgkNCj5OT1RFOglUaGUgbWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVy biB0aGUgZG9jdW1lbnQgaW4NCj4JTUlNRS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFj ayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlzDQo+CWZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAi RU5DT0RJTkcgbWltZSIgYmVmb3JlIHRoZSAiRklMRSINCj4JY29tbWFuZC4gIFRvIGRlY29kZSB0 aGUgcmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBhY2siIG9yDQo+CWEgTUlNRS1jb21w bGlhbnQgbWFpbCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXJz DQo+CWV4aGliaXQgZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3 aXRoDQo+CSJtdWx0aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhh dmUgYmVlbiBzcGxpdA0KPgl1cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91 ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uDQo+CWhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3Nh Z2VzLg0KPgkJDQo+CQkNCj5CZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1J TUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQo+aW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxs eSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj5JbnRlcm5ldC1EcmFmdC4NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmxlbW9u YWRlIG1haWxpbmcgbGlzdA0KPmxlbW9uYWRlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGVtb25hZGUNCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPmxlbW9uYWRlIG1haWxpbmcgbGlzdA0KPmxlbW9u YWRlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGVt b25hZGUNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPmxlbW9uYWRlIG1haWxpbmcgbGlzdA0KPmxlbW9uYWRlQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGVtb25hZGUNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmxlbW9uYWRlIG1haWxpbmcgbGlz dA0KPmxlbW9uYWRlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbGVtb25hZGUNCg0KPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9 DQoNCg0KQmVzdCBSZWdhcmRzIAkJCQkNCg0KRmFuIFhpYW9odWkNCg0KUHJvZHVjdCBEZXZlbG9w bWVudCBEaXZpc2lvbiANClImRCBDRU5URVINCkNISU5BIE1PQklMRSBDT01NVU5JQ0FUSU9OUyBD T1JQT1JBVElPTiAoQ01DQykNCkFERDogNTNBLCBYaWJpYW5tZW5uZWkgQXZlLixYdWFud3UgRGlz dHJpY3QsQmVpamluZywxMDAwNTMgQ2hpbmENClRFTDorODYgMTAgNjYwMDY2ODggRVhUIDMxMzcN CkZBWDorODYgMTAgNjM2MDAzNDANCkUtbWFpbDogZmFueGlhb2h1aUBjaGluYW1vYmlsZS5jb20N Cg== --===============0486875620== 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 --===============0486875620==-- From lemonade-bounces@ietf.org Mon Dec 19 08:51:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoLQP-0002Sd-V5; Mon, 19 Dec 2005 08:51:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoDM4-0003qF-Sc for lemonade@megatron.ietf.org; Mon, 19 Dec 2005 00:14:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13614 for <lemonade@ietf.org>; Mon, 19 Dec 2005 00:13:34 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoDOD-0004Yd-E3 for lemonade@ietf.org; Mon, 19 Dec 2005 00:16:50 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBJ5GXQ4023096 for <lemonade@ietf.org>; Mon, 19 Dec 2005 00:16:33 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBJ5EKu218470 for <lemonade@ietf.org>; Mon, 19 Dec 2005 00:14:26 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBJ5EEK156446 for <lemonade@ietf.org>; Mon, 19 Dec 2005 00:14:15 -0500 Received: from SATURN ([9.12.245.86]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1134969249.101; Mon, 19 Dec 2005 00:14:09 -0400 Date: Mon, 19 Dec 2005 00:13:53 -0500 From: Barry Leiba <leiba@watson.ibm.com> To: lemonade@ietf.org Message-ID: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========5BFE8C124B7C6739492D==========" X-Spam-Score: 2.0 (++) X-Scan-Signature: 27ba11eb5e600a059070a14bd841d36d X-Mailman-Approved-At: Mon, 19 Dec 2005 08:51:36 -0500 Subject: [lemonade] draft-ietf-lemonade-imap-sieve-00 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --==========5BFE8C124B7C6739492D========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit I have just sent the attached draft to be published as an I-D. It's a first pass at describing an extension to IMAP and Sieve that could be used to drive server-to-client notifications with a Sieve script. Please review and comment here, and especially note the "open issues" section. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam --==========5BFE8C124B7C6739492D========== Content-Type: text/plain; charset=utf-8; name="draft-ietf-lemonade-imap-sieve-00.txt" Content-Disposition: attachment; filename="draft-ietf-lemonade-imap-sieve-00.txt"; size=32656 Content-Transfer-Encoding: quoted-printable Lemonade Working Group B. = Leiba Internet-Draft IBM T.J. Watson Research = Center Expires: June 21, 2006 December 18, = 2005 Support for Sieve in Internet Message Access Protocol (IMAP4) draft-ietf-lemonade-imap-sieve-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. = This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve = extensions, features such as notifications). Note Leiba Expires June 21, 2006 [Page = 1] =0C Internet-Draft Lemonade-Sieve December = 2005 While this document defines extensions to IMAP and Sieve, it is the work of the Lemonade Working Group (Enhancements to Internet email = to support diverse service environments), and discussion of it is on = the lemonade mailing list at mailto:lemonade@ietf.org. Subscription requests can be sent to mailto:lemonade-request@ietf.org?body=3Dsubscribe (send an email message with the word "subscribe" in the body). A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/lemonade/index.html Leiba Expires June 21, 2006 [Page = 2] =0C Internet-Draft Lemonade-Sieve December = 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . = 5 1.2 Conventions used in this document . . . . . . . . . . . . . = 5 2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . . = 6 2.1 The "IMAPSieve" Capability String . . . . . . . . . . . . . = 6 2.2 Existing IMAP Functions Affected by IMAPSieve . . . . . . . = 6 2.2.1 The IMAP APPEND Command . . . . . . . . . . . . . . . . . . = 6 2.2.2 The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . . = 6 2.2.3 The IMAP COPY Command . . . . . . . . . . . . . . . . . . . = 6 2.2.4 Changes to IMAP Message Flags . . . . . . . . . . . . . . . = 6 2.2.5 New or Changed IMAP Message Annotations . . . . . . . . . . = 7 2.3 New IMAP Functions Defined by IMAPSieve . . . . . . . . . . = 7 2.3.1 The IMAP SIEVEFILTER Command . . . . . . . . . . . . . . . . = 7 3. Applicable Sieve Actions and Interactions . . . . . . . . . = 9 3.1 The Implicit Keep . . . . . . . . . . . . . . . . . . . . . = 9 3.2 The Keep Action . . . . . . . . . . . . . . . . . . . . . . = 9 3.3 The Fileinto Action . . . . . . . . . . . . . . . . . . . . = 9 3.4 The Redirect Action . . . . . . . . . . . . . . . . . . . . = 10 3.5 The Reject Action . . . . . . . . . . . . . . . . . . . . . = 10 3.6 The Discard Action . . . . . . . . . . . . . . . . . . . . . = 10 3.7 The Notify Action . . . . . . . . . . . . . . . . . . . . . = 10 3.8 The Addheader and Deleteheader Actions . . . . . . . . . . . = 10 3.9 The Setflag, Deleteflag, and Removeflag Actions . . . . . . = 11 3.10 The Vacation Action . . . . . . . . . . . . . . . . . . . . = 11 3.11 New Sieve Variable: IMAPSieve.cause . . . . . . . . . . . . = 11 3.12 New Sieve Variable: IMAPSieve.mailbox . . . . . . . . . . . = 12 3.13 New Sieve Variable: IMAPSieve.changed.flags . . . . . . . . = 12 3.14 New Sieve Variable: IMAPSieve.changed.annotations . . . . . = 12 3.15 Interaction With Sieve Tests (Comparisons) . . . . . . . . . = 12 4. Open Issues With This Document . . . . . . . . . . . . . . . = 13 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . = 14 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . = 15 7. Security Considerations . . . . . . . . . . . . . . . . . . = 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . = 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . = 18 9.1 Normative References . . . . . . . . . . . . . . . . . . . . = 18 9.2 Non-Normative References . . . . . . . . . . . . . . . . . . = 18 Leiba Expires June 21, 2006 [Page = 3] =0C Internet-Draft Lemonade-Sieve December = 2005 Author's Address . . . . . . . . . . . . . . . . . . . . . . = 19 Intellectual Property and Copyright Statements . . . . . . . = 20 Leiba Expires June 21, 2006 [Page = 4] =0C Internet-Draft Lemonade-Sieve December = 2005 1. Introduction 1.1 Overview Some applications have a need to apply [Sieve] filters in situations other than initial mail delivery. This is especially true in = diverse service environments, such as when the client is sporadically connected, is connected through a high-latency or high-cost channel, or is on a limited-function device. For such clients, it may be = very important, for higher performance and reliability, to take advantage of server capabilities, including those provided by Sieve filtering (and Sieve extensions, such as [Notify]). This specification defines extensions to [IMAP] to support the invocation of Sieve scripts at times when the IMAP server creates = new messages, or modifies existing ones. It also defines how Sieve scripts will process these invocations. 1.2 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are = to be interpreted as described in [Keywds]. Leiba Expires June 21, 2006 [Page = 5] =0C Internet-Draft Lemonade-Sieve December = 2005 2. The IMAP "IMAPSieve" Extension 2.1 The "IMAPSieve" Capability String An IMAP server advertises support for this extension through the capability string "IMAPSieve" (the string is not case-sensitive, and is shown here with this capitalization for readability). A server that advertises IMAPSieve is claiming to be in compliance with this specification in all aspects. 2.2 Existing IMAP Functions Affected by IMAPSieve The subsections below describe in detail the IMAP commands and situations on which IMAPSieve has an effect. Not all Sieve actions make sense in the case of messages affected by IMAP commands. See Section 3 for details. If more than one message is affected at the same time, each message triggers the execution of a Sieve script separately. The scripts = MAY be run in parallel. 2.2.1 The IMAP APPEND Command A message may be added to a mailbox through the IMAP APPEND command. In a server that advertises IMAPSieve, new messages added in this = way MUST trigger the execution of a Sieve script, subject to the = settings specified with the SIEVEFILTER command (see Section 2.3.1). 2.2.2 The IMAP MULTIAPPEND Command If the IMAP server supports the IMAP [MultiAppend] extension, messages may be added to a mailbox through the IMAP MULTIAPPEND command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, as with = the APPEND command, also subject to the settings specified with the SIEVEFILTER command. 2.2.3 The IMAP COPY Command One or more messages may be added to a mailbox through the IMAP COPY command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, subject to the settings specified with the SIEVEFILTER command. 2.2.4 Changes to IMAP Message Flags One or more existing messages can have their flags changed in a number of ways, including: Leiba Expires June 21, 2006 [Page = 6] =0C Internet-Draft Lemonade-Sieve December = 2005 o The FETCH command (may cause the \Seen flag to be set). o The STORE command (may cause the \Answered, \Deleted, \Draft, \Flagged, and \Seen flags to be set or reset, and may cause keywords to be set or reset). o The invocation of a Sieve script on an existing message, where = the Sieve implementation supports the [IMAP4Flags] extension and the script uses one of the actions defined in that extension. o [[Flags-Others?: Are there other ways?]] In a server that advertises IMAPSieve, messages whose flags are changed in any way (except as explained in the next sentence) MUST trigger the execution of a Sieve script, subject to the settings specified with the SIEVEFILTER command. The exception is that in order to avoid script loops, flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. 2.2.5 New or Changed IMAP Message Annotations [[Annotate?: Do we want this to apply to annotate too? If so, does that make annotate a normative reference?]] If the IMAP server supports the [Annotate] extension, one or more existing messages can have annotations added or changed through the ANNOTATE command. In a server that advertises IMAPSieve, messages getting new or changed annotations MUST trigger the execution of a Sieve script, subject to the settings specified with the SIEVEFILTER command. 2.3 New IMAP Functions Defined by IMAPSieve 2.3.1 The IMAP SIEVEFILTER Command [[Do we need this?: I'm not sure whether we need this command, but I've put it here as a placeholder, and to start discussion. It may be that it's OK for all modifications to result in calls to the a Sieve filter, to have the filter designated elsewhere, and to have the filter decide what to handle and what to ignore.]] The SIEVEFILTER command is a command that we might need in order to tell the IMAP server which script to use for which mailbox(es). If we decide we need this, the idea would be that no Sieve script is invoked unless this command sets it up, and the command would "turn on" filtering for a particular mailbox, or set of mailboxes. Leiba Expires June 21, 2006 [Page = 7] =0C Internet-Draft Lemonade-Sieve December = 2005 SIEVEFILTER Command Arguments: to be defined Responses: to be defined Result: OK - command completed, filtering controls updated. NO - failure: the server was unable to complete the command and update the filtering controls. BAD - command unknown (not supported, or invalid in this state), or arguments invalid. Leiba Expires June 21, 2006 [Page = 8] =0C Internet-Draft Lemonade-Sieve December = 2005 3. Applicable Sieve Actions and Interactions Since some Sieve actions relate specifically to the delivery of = mail, not all actions make sense when the messages are created by other means, or when changes are made to data associated with existing messages. This section describes how actions in the base Sieve specification, and those in extensions known at this writing, relate to this specification. In addition to what is specified here, interactions specified in the individual specifications apply, and must be considered. 3.1 The Implicit Keep For all cases that fall under IMAPSieve, the implicit keep means = that the message is treated as it would have been if no Sieve script were run. For APPEND, MULTIAPPEND and COPY, the message is stored into the target mailbox normally. For flag or annotation changes, the message is left in the mailbox. 3.2 The Keep Action The keep action is applicable in all cases that fall under = IMAPSieve. Its behaviour is as described for implicit keep, in Section 3.1. 3.3 The Fileinto Action If the Sieve implementation supports the fileinto action, that = action is applicable in all cases that fall under IMAPSieve. If the [Copy] extension is available and the :copy option is specified, the implicit keep is retained; otherwise, fileinto cancels the implicit keep, as specified in the base Sieve specification. If a keep action, implicit or explicit, is also in effect, for APPEND, MULTIAPPEND, and COPY, the message is stored into the fileinto mailbox IN ADDITION TO the original target mailbox. For flag or annotation changes, the message is COPIED into the fileinto mailbox, without removing the original. If a keep action is NOT also in effect, for APPEND, MULTIAPPEND, and COPY, the message is stored into the fileinto mailbox INSTEAD OF in the original target mailbox. For flag or annotation changes, the message is MOVED, as an atomic operation, into the fileinto mailbox. This MUST happen as an atomic operation, and MUST NOT be done by copying the message and setting the \Deleted flag for the original. Leiba Expires June 21, 2006 [Page = 9] =0C Internet-Draft Lemonade-Sieve December = 2005 3.4 The Redirect Action The redirect action is applicable in all cases that fall under IMAPSieve. It causes the message to be sent, as specified in the base Sieve specification, to the designated address. If the [Copy] extension is available and the :copy option is specified, the implicit keep is retained; otherwise, redirect cancels the implicit keep, as specified in the base Sieve specification. If a keep action, implicit or explicit, is also in effect, for APPEND, MULTIAPPEND, and COPY, the message is stored into the target mailbox in addition to being redirected. For flag or annotation changes, the message remains in its original mailbox. If a keep action is NOT also in effect, for APPEND, MULTIAPPEND, and COPY, the message is NOT stored into the target mailbox. For flag = or annotation changes, the message is REMOVED, as an atomic operation, from the mailbox. This MUST happen as an atomic operation, and MUST NOT be done by setting the \Deleted flag for the message. 3.5 The Reject Action The reject action is NOT applicable to any case that falls under IMAPSieve. Its use MUST result in an error condition that will terminate the Sieve script. 3.6 The Discard Action The discard action is applicable in all cases that fall under IMAPSieve. If a keep action, implicit or explicit, is also in effect, the discard action does nothing. Otherwise, for APPEND, MULTIAPPEND, and COPY, the message is NOT stored into the target mailbox. For flag or annotation changes, the message is REMOVED, as an atomic operation, from the mailbox. This MUST happen as an = atomic operation, and MUST NOT be done by setting the \Deleted flag for the message. 3.7 The Notify Action If the [Notify] extension is available, the notify action is applicable in all cases that fall under IMAPSieve. The result is that the requested notification is sent, and that the message is otherwise handled as it would normally have been. 3.8 The Addheader and Deleteheader Actions If the [EditHeader] extension is available, the addheader and deleteheader actions are applicable for NEW MESSAGES ONLY (messages Leiba Expires June 21, 2006 [Page = 10] =0C Internet-Draft Lemonade-Sieve December = 2005 created by APPEND, MULTIAPPEND, and COPY). The requested header changes are made to the new message before it is stored into the target mailbox. Since messages in IMAP mailboxes are immutable, these actions are = NOT applicable in the case of flag or annotation changes to existing messages. If a script uses addheader or deleteheader in these = cases, the action MUST have no effect (and MUST NOT generate an error condition). [[editheader No Effect?: Is this what we want, or should it be an error?]] 3.9 The Setflag, Deleteflag, and Removeflag Actions If the [IMAP4Flags] extension is available, the actions associated with it are all applicable to any case that falls under IMAPSieve. It is worth noting also that the "hasflag" test that is defined in the IMAP4Flags extension might be particularly useful in scripts triggered by flag changes. As explained above, in order to avoid script loops flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. 3.10 The Vacation Action Even if the [Vacation] extension is available, the vacation action = is NOT applicable to any case that falls under IMAPSieve. Its use MUST result in an error condition that will terminate the Sieve script. 3.11 New Sieve Variable: IMAPSieve.cause Implementations MAY invoke different Sieve scripts for the different conditions described in this document (append, copy, flag changes, annotation changes). If the actions to be taken are common, and the implementation supports the [Include] extension, the common script code can be included as specified there. It may be preferable, though, to use a single script for all these conditions. To support that, if the [Variables] extension is available, the implementation MUST set the reserved variable "${IMAPSieve.cause}", which contains the name of the action that caused the script to be invoked. Its value is one of the following: o APPEND (for invocations resulting from APPEND or MULTIAPPEND) Leiba Expires June 21, 2006 [Page = 11] =0C Internet-Draft Lemonade-Sieve December = 2005 o COPY (for invocations resulting from COPY) o FLAG (for invocations resulting from flag changes) o ANNOTATE (for invocations resulting from new or changed annotations) 3.12 New Sieve Variable: IMAPSieve.mailbox If the [Variables] extension is available, the implementation MUST set the reserved variable "${IMAPSieve.mailbox}" to the name of the mailbox that the affected message is in, in the case of existing messages, or is targeted to be stored into, in the case of new messages. The value of this variable is fixed when the script begins, and, in particular, MUST NOT change as a result of any action, such as "fileinto". 3.13 New Sieve Variable: IMAPSieve.changed.flags If the [Variables] extension is available, the [IMAP4Flags] = extension is available, AND the script was invoked because of flag changes to an existing message, the implementation MUST set the reserved variable "${IMAPSieve.changed.flags}" to the name(s) of the flag(s) that have changed. If the script was not invoked because of flag changes, this variable MUST be unknown (and, thus, its value MUST be the empty string). The script will not know from this variable whether the flags have been set or reset, but it can use the "hasflag" test to determine the current value. See example 2 in Section 5 for an example of how this might be used. 3.14 New Sieve Variable: IMAPSieve.changed.annotations If the [Variables] extension is available, the [Annotate] extension is available, AND the script was invoked because of annotation changes to an existing message, the implementation MUST set the reserved variable "${IMAPSieve.changed.annotations}" to the name(s) of the annotation(s) that have changed. If the script was not invoked because of annotation changes, this variable MUST be unknown (and, thus, its value MUST be the empty string). 3.15 Interaction With Sieve Tests (Comparisons) This extension does not affect the operation of any tests or comparisons. Leiba Expires June 21, 2006 [Page = 12] =0C Internet-Draft Lemonade-Sieve December = 2005 4. Open Issues With This Document When this section is empty, I guess we're done.... 1. Do we need the SIEVEFILTER command? If so, exactly what should it do? 2. If EditHeader stuff is used with FLAG or ANNOTATE, should it be ignored or should it be an error? 3. If the reject action is used at all, should it be ignored or should it be an error? Same question for other inappropriate actions. 4. Requirement to Variables extension: We should probably = generalize the "cause" variable, and require it for all Sieve invocations. Normal delivery situations can have the value "DELIVERY". Otherwise, it's awkward to write a script that has to assume something about the ABSENCE of a "cause" variable. 5. Requirement to Variables document: There should be an example of a variable with a namespace attribute. 6. Do we need any more reserved Sieve variables for this? Do we have too many? 7. All of the extensions that we describe how to work with: are = they normative, or non-normative references? 8. Can anyone come up with some examples that use only features = from the base Sieve spec? Leiba Expires June 21, 2006 [Page = 13] =0C Internet-Draft Lemonade-Sieve December = 2005 5. Examples Example 1: If a new message is added to the "ActionItems" mailbox, a copy is sent to the address "actionitems@example.com". require ["copy", "variables"]; if anyof (${IMAPSieve.cause} :is "APPEND", ${IMAPSieve.cause} :is "COPY") { if ${IMAPSieve.mailbox} :is "ActionItems" { redirect :copy "actionitems@example.com"; } } Example 2: If the script is called for any message with the \Flagged flag set (tested through the [IMAP4Flags] extension), a notification is sent using the [Notify] extension. No notification will be sent, though, if we're called with an existing message that already had that flag set. require ["nofity", "imap4flags", "variables"]; if allof (hasflag "\\Flagged", not ${IMAPSieve.changed.flags} :contains "\\Flagged") { notify :message "Important message in ${IMAPSieve.mailbox}"; } Example 3: [[More examples?: Can anyone come up with some examples that use = only features from the base Sieve spec?]] Leiba Expires June 21, 2006 [Page = 14] =0C Internet-Draft Lemonade-Sieve December = 2005 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF]. Non-terminals = referenced but not defined below are as defined by [IMAP]. [[Maybe...: If we decide we need this command, the syntax goes here.]] command_auth =3D/ sievefilter ; Valid only in Authenticated or Selected state sievefilter =3D "SIEVEFILTER" to be defined Leiba Expires June 21, 2006 [Page = 15] =0C Internet-Draft Lemonade-Sieve December = 2005 7. Security Considerations It is possible to introduce script processing loops by having a = Sieve script that is triggered by flag changes use the actions defined in the [IMAP4Flags] extension. Implementations MUST take steps to prevent such loops. One way to avoid this problem is that if a script is invoked by flag changes, and that script further changes the flags, those flag changes SHOULD NOT trigger a Sieve script invocation. Other security considerations are discussed in [IMAP], and [Sieve], as well as in some of the other extension documents. Leiba Expires June 21, 2006 [Page = 16] =0C Internet-Draft Lemonade-Sieve December = 2005 8. IANA Considerations [[IANA?: Do we need this, since there's not actually a Sieve capability defined here?]] The following template specifies the IANA registration of the Sieve extension specified in this document: To: iana@iana.org Subject: Registration of new Sieve extension Capability name: imapsieve Capability keyword: imapsieve Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: this RFC Person and email address to contact for further information: Barry Leiba <leiba@watson.ibm.com> This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions. Leiba Expires June 21, 2006 [Page = 17] =0C Internet-Draft Lemonade-Sieve December = 2005 9. References 9.1 Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [Keywds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", work in progress, draft-ietf-sieve-3028bis, November 2005. 9.2 Non-Normative References [Annotate] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", work in progress, draft-ietf-imapext-annotate, November 2005. [Copy] Degener, J., "Sieve Extension: Copying Without Side Effects", RFC 3894, October 2004. [EditHeader] Degener, J. and P. Guenther, "Sieve Email Filtering: Editheader Extension", work in progress, draft-ietf-sieve-editheader, October 2005. [IMAP4Flags] Melnikov, A., "Sieve Mail Filtering Language: IMAP flag Extension", work in progress, draft-ietf-sieve-imapflags, October 2005. [Include] Daboo, C., "SIEVE Email Filtering: Include Extension", work in progress, draft-daboo-sieve-include, August 2005. [MultiAppend] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003. [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Extension: Notifications", work in progress, draft-ietf-sieve-notify, December 2005. [Vacation] Leiba Expires June 21, 2006 [Page = 18] =0C Internet-Draft Lemonade-Sieve December = 2005 Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Vacation Extension", work in progress, draft-ietf-sieve-vacation, October 2005. [Variables] Homme, K., "Sieve Extension: Variables", work in progress, draft-ietf-sieve-variables, October 2005. Author's Address Barry Leiba IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US Phone: +1 914 784 7941 Email: leiba@watson.ibm.com Leiba Expires June 21, 2006 [Page = 19] =0C Internet-Draft Lemonade-Sieve December = 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed = to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. = Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use = of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository = at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on = an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Leiba Expires June 21, 2006 [Page = 20] =0C --==========5BFE8C124B7C6739492D========== 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 --==========5BFE8C124B7C6739492D==========-- From lemonade-bounces@ietf.org Mon Dec 19 09:50:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMLG-0007WR-UH; Mon, 19 Dec 2005 09:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMLF-0007Vy-Pi for lemonade@megatron.ietf.org; Mon, 19 Dec 2005 09:50:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25018 for <lemonade@ietf.org>; Mon, 19 Dec 2005 09:49:19 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoMNT-00089g-13 for lemonade@ietf.org; Mon, 19 Dec 2005 09:52:40 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jBJEoEME013524; Mon, 19 Dec 2005 08:50:14 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <XN5B72PX>; Mon, 19 Dec 2005 08:50:14 -0600 Message-ID: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com> To: Barry Leiba <leiba@watson.ibm.com>, lemonade@ietf.org Subject: RE: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Mon, 19 Dec 2005 08:50:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I don't understand the big picture here. In earlier discussions, we determined there were four cases where filtering occures: AF: Administrative filtering upstream of user processing DF: Traditional deposit time filtering NF: Filtering of notification events (maybe including notification actions resulting from deposit events?) VF: View filters of messages in a mailbox. This draft appears to me to address DF filters where "deposit" comes from the IMAP client. Is that a correct reading? My alternate guess is that this specifies a means of performing a view filter by automatically (re)foldering messages into an alternate mailbox, in which case you want to capture all trigger events to apply the view filter to. Can you map this document to the above filtering model or suggest changes to the model? This draft also does not discuss the management of the scripts. Are you assuming MANAGE SIEVE? I would prefer to see a fuller script management interface included in IMAP that subsumes basic management capabilities of the SIEVEFILTER command. Greg V. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Barry Leiba Sent: Monday, December 19, 2005 12:14 AM To: lemonade@ietf.org Subject: [lemonade] draft-ietf-lemonade-imap-sieve-00 I have just sent the attached draft to be published as an I-D. It's a first pass at describing an extension to IMAP and Sieve that could be used to drive server-to-client notifications with a Sieve script. Please review and comment here, and especially note the "open issues" section. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Dec 19 09:59:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMTo-0001B7-BE; Mon, 19 Dec 2005 09:59:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMTm-0001Ah-Ck; Mon, 19 Dec 2005 09:59:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26509; Mon, 19 Dec 2005 09:58:06 -0500 (EST) Received: from bda035.bis.na.blackberry.com ([216.9.249.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoMVw-00007X-IZ; Mon, 19 Dec 2005 10:01:26 -0500 Received: from bda035-cell00.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda035.bis.na.blackberry.com (8.13.4 TEAMON/8.13.4) with ESMTP id jBJEwsQG003479; Mon, 19 Dec 2005 14:58:54 GMT Message-ID: <18152043.1135004334850.JavaMail.teamon@bda035-cell00.bisx.prod.on.blackberry> References: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> Sensitivity: Normal Importance: Normal To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade-bounces@ietf.org, "Barry Leiba" <leiba@watson.ibm.com>, lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 From: "Stephane H. Maes" <stephane.maes@oracle.com> Date: Mon, 19 Dec 2005 14:59:56 +0000 GMT MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephane.maes@oracle.com List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1522119499==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1522119499== Content-Transfer-Encoding: base64 Content-type: text/plain Content-Transfer-Encoding: base64 SSBhbSB3b3JraW5nIG9uIHRoZSBtYXBwaW5nIGFuZCBleGFtcGxlcy4gR2l2ZSBtZSBhIGZldyBk YXlzIHRvIHNlZSBpZiBpdCB3b3Jrcy4gSSB3aWxsIHRyeSB0byBhbGxpZ24gd2l0aCB0aGlzIG5l dyBkcmFmdCBhbmQgZXh0ZW5kIHRvIE5GLg0KDQpJIHRoaW5rIHRoaXMgaXMgaG93IHdlIGFncmVl ZCB0byBwcm9jZWVkIGluIFZhbmNvdXZlcg0KDQpTdGVwaGFuZQ0KX19fX18KU3RlcGhhbmUgSC4g TWFlcywgUGhELApEaXJlY3RvciBvZiBBcmNoaXRlY3R1cmUsIE1vYmlsZSwgVm9pY2UsIGFuZCBD b21tdW5pY2F0aW9ucyBQbGF0Zm9ybXMsIE9yYWNsZQpQaDogKzEtMjAzLTMwMC03Nzg2IChtb2Jp bGUvU01TL3NreXBlKTsgRmF4IC8gT2ZmaWNlIFVNOiArMS02NTAtNjA3LTYyOTYuCmUtbWFpbDog c3RlcGhhbmUubWFlc0BvcmFjbGUuY29tCklNOiBzaG1hZXMgKEFJTS9ZISkgb3Igc3RlcGhhbmVf bWFlc0Bob3RtYWlsLmNvbSAoTVNOIE1lc3NlbmdlcikNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206ICJWYXVkcmV1aWwsIEdyZWcgTSAoR3JlZykiIDxncmVndkBsdWNlbnQuY29t Pg0KRGF0ZTogTW9uLCAxOSBEZWMgMjAwNSAwODo1MDoxMSANClRvOkJhcnJ5IExlaWJhIDxsZWli YUB3YXRzb24uaWJtLmNvbT4sIGxlbW9uYWRlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2xlbW9u YWRlXSBkcmFmdC1pZXRmLWxlbW9uYWRlLWltYXAtc2lldmUtMDANCg0KDQpJIGRvbid0IHVuZGVy c3RhbmQgdGhlIGJpZyBwaWN0dXJlIGhlcmUuDQoNCkluIGVhcmxpZXIgZGlzY3Vzc2lvbnMsIHdl IGRldGVybWluZWQgdGhlcmUgd2VyZSBmb3VyIGNhc2VzIHdoZXJlIGZpbHRlcmluZyBvY2N1cmVz Og0KCUFGOiBBZG1pbmlzdHJhdGl2ZSBmaWx0ZXJpbmcgdXBzdHJlYW0gb2YgdXNlciBwcm9jZXNz aW5nDQoJREY6IFRyYWRpdGlvbmFsIGRlcG9zaXQgdGltZSBmaWx0ZXJpbmcNCglORjogRmlsdGVy aW5nIG9mIG5vdGlmaWNhdGlvbiBldmVudHMgKG1heWJlIGluY2x1ZGluZyBub3RpZmljYXRpb24g YWN0aW9ucyByZXN1bHRpbmcgZnJvbSBkZXBvc2l0IGV2ZW50cz8pDQoJVkY6IFZpZXcgZmlsdGVy cyBvZiBtZXNzYWdlcyBpbiBhIG1haWxib3guDQoNClRoaXMgZHJhZnQgYXBwZWFycyB0byBtZSB0 byBhZGRyZXNzIERGIGZpbHRlcnMgd2hlcmUgImRlcG9zaXQiIGNvbWVzIGZyb20gdGhlIElNQVAg Y2xpZW50LiAgSXMgdGhhdCBhIGNvcnJlY3QgcmVhZGluZz8gIE15IGFsdGVybmF0ZSBndWVzcyBp cyB0aGF0IHRoaXMgc3BlY2lmaWVzIGEgbWVhbnMgb2YgcGVyZm9ybWluZyBhIHZpZXcgZmlsdGVy IGJ5IGF1dG9tYXRpY2FsbHkgKHJlKWZvbGRlcmluZyBtZXNzYWdlcyBpbnRvIGFuIGFsdGVybmF0 ZSBtYWlsYm94LCBpbiB3aGljaCBjYXNlIHlvdSB3YW50IHRvIGNhcHR1cmUgYWxsIHRyaWdnZXIg ZXZlbnRzIHRvIGFwcGx5IHRoZSB2aWV3IGZpbHRlciB0by4NCg0KQ2FuIHlvdSBtYXAgdGhpcyBk b2N1bWVudCB0byB0aGUgYWJvdmUgZmlsdGVyaW5nIG1vZGVsIG9yIHN1Z2dlc3QgY2hhbmdlcyB0 byB0aGUgbW9kZWw/DQoNClRoaXMgZHJhZnQgYWxzbyBkb2VzIG5vdCBkaXNjdXNzIHRoZSBtYW5h Z2VtZW50IG9mIHRoZSBzY3JpcHRzLiAgQXJlIHlvdSBhc3N1bWluZyBNQU5BR0UgU0lFVkU/ICBJ IHdvdWxkIHByZWZlciB0byBzZWUgYSBmdWxsZXIgc2NyaXB0IG1hbmFnZW1lbnQgaW50ZXJmYWNl IGluY2x1ZGVkIGluIElNQVAgdGhhdCBzdWJzdW1lcyBiYXNpYyBtYW5hZ2VtZW50IGNhcGFiaWxp dGllcyBvZiB0aGUgU0lFVkVGSUxURVIgY29tbWFuZC4gIA0KDQpHcmVnIFYuDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxlbW9uYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpsZW1vbmFkZS1ib3VuY2VzQGlldGYub3JnXU9uDQpCZWhhbGYgT2YgQmFycnkgTGVpYmEN ClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTksIDIwMDUgMTI6MTQgQU0NClRvOiBsZW1vbmFkZUBp ZXRmLm9yZw0KU3ViamVjdDogW2xlbW9uYWRlXSBkcmFmdC1pZXRmLWxlbW9uYWRlLWltYXAtc2ll dmUtMDANCg0KDQpJIGhhdmUganVzdCBzZW50IHRoZSBhdHRhY2hlZCBkcmFmdCB0byBiZSBwdWJs aXNoZWQgYXMgYW4gSS1ELiAgSXQncyBhDQpmaXJzdCBwYXNzIGF0IGRlc2NyaWJpbmcgYW4gZXh0 ZW5zaW9uIHRvIElNQVAgYW5kIFNpZXZlIHRoYXQgY291bGQgYmUNCnVzZWQgdG8gZHJpdmUgc2Vy dmVyLXRvLWNsaWVudCBub3RpZmljYXRpb25zIHdpdGggYSBTaWV2ZSBzY3JpcHQuDQoNClBsZWFz ZSByZXZpZXcgYW5kIGNvbW1lbnQgaGVyZSwgYW5kIGVzcGVjaWFsbHkgbm90ZSB0aGUgIm9wZW4g aXNzdWVzIg0Kc2VjdGlvbi4NCg0KQmFycnkNCg0KLS0NCkJhcnJ5IExlaWJhLCBQZXJ2YXNpdmUg Q29tcHV0aW5nIFRlY2hub2xvZ3kgIChsZWliYUB3YXRzb24uaWJtLmNvbSkNCmh0dHA6Ly93d3cu cmVzZWFyY2guaWJtLmNvbS9wZW9wbGUvbC9sZWliYQ0KaHR0cDovL3d3dy5yZXNlYXJjaC5pYm0u Y29tL3NwYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmxlbW9uYWRlIG1haWxpbmcgbGlzdA0KbGVtb25hZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xlbW9uYWRlDQo= --===============1522119499== 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 --===============1522119499==-- From lemonade-bounces@ietf.org Mon Dec 19 10:43:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoNAd-00023M-Nf; Mon, 19 Dec 2005 10:43:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoNAb-00022S-BQ for lemonade@megatron.ietf.org; Mon, 19 Dec 2005 10:43:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02151 for <lemonade@ietf.org>; Mon, 19 Dec 2005 10:42:22 -0500 (EST) Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoNCn-0001e9-Q1 for lemonade@ietf.org; Mon, 19 Dec 2005 10:45:44 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1EoNAD-0008SK-DU; Mon, 19 Dec 2005 15:43:01 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 21E0A498003; Mon, 19 Dec 2005 15:44:12 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02981-10; Mon, 19 Dec 2005 15:44:07 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 0C8B8498002; Mon, 19 Dec 2005 15:44:07 +0000 (GMT) Date: Mon, 19 Dec 2005 15:42:55 +0000 Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> In-Reply-To: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> MIME-Version: 1.0 Message-Id: <24238.1135006975.786474@peirce.dave.cridland.net> From: Dave Cridland <dave@cridland.net> To: Barry Leiba <leiba@watson.ibm.com> Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Dec 19 05:13:53 2005, Barry Leiba wrote: > I have just sent the attached draft to be published as an I-D. =20 > It's a > first pass at describing an extension to IMAP and Sieve that could=20 > be > used to drive server-to-client notifications with a Sieve script. >=20 > Please review and comment here, and especially note the "open=20 > issues" > section. There's quite a few mentions of atomic moves - these can be quite=20 slow for some mailstores, and in general they're tricky, and they=20 almost invariably involve maintaining locking on multiple mailboxes. Moreover, I really do fear what a na=EFve client - or indeed any client=20 - will do when it casually flips a flag, and discovers the message=20 has just been expunged. Even if it's not na=EFve, but is the most=20 intelligent and aware client in the world, I don't see how it's going=20 to detect the difference between "this flag change caused the message=20 to be atomically moved" and "this flag change didn't happen because=20 the message was already expunged". I also have a nasty feeling that some clients will take it upon=20 themselves to make setting the \Deleted flag instantly expunge the=20 message. I also think it's likely to break UIDPLUS - a client will lose track=20 of apparently witnessed moves, because it has no idea of what the new=20 UID is, as well as not knowing if the message still exists somewhere=20 else on the server. If even one message is moved in a MULTIAPPEND,=20 then the APPENDUID response cannot be sent. Section 3.8 suggests that even if the message isn't shifted about=20 atomically behind the client's back, and UIDPLUS actually works, then=20 because the headers may be edited, a client will potentially have the=20 wrong data in the cache. Oddly enough, I do think we could use reject, though. Reject could=20 generate a protocol level error, hence an APPEND or COPY to a mailbox=20 could be forced to fail for a fairly arbitrary reason, for instance.=20 Of course, with APPEND and LITERAL+, that's going to make client=20 implementors a little upset. Really, I think this ought to limit itself to two actions: 1) Notifications, so that message appends, copies, and flag changes=20 can be sent to disconnected devices. 2) Flag changes, primarily for interoperability between clients using=20 locally defined keywords. Otherwise, I'm really not sure how we're going to get all those worms=20 back into the can. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 20 10:32:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojU2-0003vT-Id; Tue, 20 Dec 2005 10:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojU0-0003vE-HN; Tue, 20 Dec 2005 10:32:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12796; Tue, 20 Dec 2005 10:31:51 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EojWQ-0008KJ-Py; Tue, 20 Dec 2005 10:35:28 -0500 X-IronPort-AV: i="3.99,273,1131339600"; d="scan'208"; a="24574736:sNHT29378976" 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 Date: Tue, 20 Dec 2005 10:32:45 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701D93F05@ATLANTIS.Brooktrout.com> Thread-Topic: Announcement: Notifications List Thread-Index: AcYAmxptyBh+0YrjSbud7cG59wlhMQAWwUFw From: "Burger, Eric" <eburger@brooktrout.com> To: <lemonade@ietf.org>, <ietf-smtp@imc.org>, <ietf-imapext@imc.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org Subject: [lemonade] Announcement: Notifications List X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org In Vancouver in the lemonade work group meeting a number of people expressed interest in the creation of a list dedicated to the discussion of user notification technology. This list is for discussions relating to the requirements, definition, and directions for message notifications. While many requirements are driven by lemonade, there is a broader community with interest and expertise that we hope will contribute to the discussion here. Please keep discussions that relate to lemonade, smtp, simple, etc. on their respective lists. Please keep cross-posting to a minimum. Cross-posting to a number of lists will put your message into the spam bucket and will delay or deny your message being posted. More information is at=20 <https://www1.ietf.org/mailman/listinfo/notifications> _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 20 15:52:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooSs-0007kq-Lp; Tue, 20 Dec 2005 15:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooQz-0006uA-JN; Tue, 20 Dec 2005 15:50:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04353; Tue, 20 Dec 2005 15:49:04 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EooTM-0005Xt-TI; Tue, 20 Dec 2005 15:52:38 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008Rj-Nn; Tue, 20 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1EooQr-0008Rj-Nn@newodin.ietf.org> Date: Tue, 20 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-sieve-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Support for Sieve in Internet Message Access Protocol (IMAP4) Author(s) : B. Leiba Filename : draft-ietf-lemonade-imap-sieve-00.txt Pages : 20 Date : 2005-12-20 Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-imap-sieve-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-20124047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-sieve-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20124047.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 --NextPart-- From lemonade-bounces@ietf.org Tue Dec 20 17:46:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoqFP-0007rE-Q7; Tue, 20 Dec 2005 17:46:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoqFO-0007qn-Tb for lemonade@megatron.ietf.org; Tue, 20 Dec 2005 17:46:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10749 for <lemonade@ietf.org>; Tue, 20 Dec 2005 17:45:14 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoqHt-0001LR-8i for lemonade@ietf.org; Tue, 20 Dec 2005 17:48:54 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBKMjxxI030420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Dec 2005 14:46:00 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBKMjuFA028889; Tue, 20 Dec 2005 14:45:58 -0800 (PST) Mime-Version: 1.0 Message-Id: <p07000c10bfce391f807a@[192.168.1.13]> In-Reply-To: <Pine.WNT.4.65.0511301631451.10700@Tomobiki-Cho.CAC.Washington.EDU> References: <438E14BA.9080502@andrew.cmu.edu> <Pine.WNT.4.65.0511301631451.10700@Tomobiki-Cho.CAC.Washington.EDU> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: <http://www.eudora.com> Date: Tue, 20 Dec 2005 14:43:21 -0800 To: Mark Crispin <MRC@CAC.Washington.EDU>, Ken Murchison <murch@andrew.cmu.edu> From: Randall Gellens <randy@qualcomm.com> Subject: Re: [lemonade] CATENATE, URLAUTH and RFC 2192bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 4:35 PM -0800 11/30/05, Mark Crispin wrote: > On Wed, 30 Nov 2005, Ken Murchison wrote: >> In other words, the client has no way of knowing whether the >> server supports partial fetches. > > Unless we want to pull URLAUTH back from the RFC Editor queue, we > will need a new new IMAP capability which announces support for > ipartial in URLs. > > Is ipartial in URLs a LEMONADE requirement? I forget if it is or not. > >> The solution would be to make RFC 2192bis the normative reference >> for both CATENATE and URLAUTH. > > I think that this is a bad idea for URLAUTH. I hope that 2192bis > will replace both RFC 2192 and URLAUTH by incorporating URLAUTH; > but to do 2192bis properly will require time. Can it be done in time for Profile v2? If so, we could do a revision of CATENATE and URLAUTH that makes 2192bis the normative reference, and publish 2192bis, CATENATEbis, URLAUTHbis, and profile bis at the same time. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A child of five would understand this. Send somebody to fetch a child of five. --Groucho Marx, _Duck Soup_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 20 22:10:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EouMe-0006Ua-Fr; Tue, 20 Dec 2005 22:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EouMd-0006Td-Mb for lemonade@megatron.ietf.org; Tue, 20 Dec 2005 22:10:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11534 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:08:59 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EouPB-0001tE-1j for lemonade@ietf.org; Tue, 20 Dec 2005 22:12:41 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBL3BunG001107 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:11:56 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBL39nu228404 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:09:49 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBL39mK228402 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:09:48 -0500 Received: from SATURN ([9.12.239.194]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1135134582.207; Tue, 20 Dec 2005 22:09:42 -0400 Date: Tue, 20 Dec 2005 22:09:48 -0500 From: Barry Leiba <leiba@watson.ibm.com> To: lemonade@ietf.org Subject: RE: [lemonade] draft-ietf-lemonade-imap-sieve-00 Message-ID: <95A94706953659E3C212F982@saturn.watson.ibm.com> In-Reply-To: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> <18152043.1135004334850.JavaMail.teamon@bda035-cell00.bisx.prod.on.blackberry> References: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih. lucent.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Greg says... > In earlier discussions, we determined there were four cases where > filtering occures: > AF: Administrative filtering upstream of user processing > DF: Traditional deposit time filtering > NF: Filtering of notification events (maybe including notification > actions resulting from deposit events?) > VF: View filters of messages in a mailbox. >=20 > This draft appears to me to address DF filters where "deposit" comes > from the IMAP client. St=C3=A9phane says... > I am working on the mapping and examples. Give me a few days to see > if it works. I will try to allign with this new draft and extend to > NF. St=C3=A9phane has basically answered Greg's question, that it falls = into NF. But it could also fall into DF, as Greg suggests. I don't see, right now, where lemonade would need DF filtering at the IMAP APPEND/COPY level, but this will enable that if it be needed. Background: This actually came up on Paris, not Vancouver, only I didn't get the time to write the draft by Vancouver time. In Paris, St=C3=A9phane was talking about s-to-c notifications, and I suggested = that Sieve be used, since it's got a notification framework in the works. St=C3=A9phane agreed that it might be usable if we extended things so = that Sieve scripts were called at times other than mail delivery, and I volunteered to write a draft to get us going on it. > This draft also does not discuss the management of the scripts. Are > you assuming MANAGE SIEVE? I would prefer to see a fuller script > management interface included in IMAP that subsumes basic management > capabilities of the SIEVEFILTER command. =20 Right, it doesn't. It puts in a placeholder for some of it, with the SIEVEFILTER maybe-command, but I'm not, in general, happy with how Sieve scripts can (more properly, can't) be managed. The managesieve protocol is too limited. It assumes that there's one active Sieve script per user, and that there either is or isn't an active script. That's fine when Sieve scripts are only called for mail delivery, but not if we start calling scripts at other times: Now we find we need to consider different scripts for different causes, and perhaps (for efficiency or management purposes) specify which mailboxes trigger the script(s) and which don't. Maybe there are other issues too. I'm not sure we'll get consensus on an extensive script-management interface in IMAP -- it's quite an overload for IMAP. That's why I left the "SIEVEFILTER" command unspecified, and just there as something to open discussion on the issue. Managesieve can certainly be extended, and perhaps this draft should add another section, replacing the SIEVEFILTER stuff, that extends managesieve to handle causes and multiple active scripts, at least. Do others have comments there? Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 20 22:17:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EouTt-0001Qa-M0; Tue, 20 Dec 2005 22:17:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EouTs-0001QV-9f for lemonade@megatron.ietf.org; Tue, 20 Dec 2005 22:17:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12094 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:16:27 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EouWM-00025d-JH for lemonade@ietf.org; Tue, 20 Dec 2005 22:20:10 -0500 Received: from lois.corp.google.com (lois.corp.google.com [172.24.0.50]) by smtp-out.google.com with ESMTP id jBL3HDvn004474 for <lemonade@ietf.org>; Tue, 20 Dec 2005 19:17:13 -0800 Received: from smtp-out2.google.com (fpc20.prod.google.com [10.253.3.20]) by lois.corp.google.com with ESMTP id jBL3H6fO014399 for <lemonade@ietf.org>; Tue, 20 Dec 2005 19:17:06 -0800 Received: by smtp-out2.google.com with SMTP id 20so41817fpc for <lemonade@ietf.org>; Tue, 20 Dec 2005 19:17:06 -0800 (PST) Received: by 10.253.3.17 with SMTP id 17mr22587fpc; Tue, 20 Dec 2005 19:17:06 -0800 (PST) Received: by 10.253.3.15 with HTTP; Tue, 20 Dec 2005 19:17:06 -0800 (PST) Message-ID: <5b93232d0512201917v1bae366t2f4adbfecf4af40f@mail.google.com> Date: Tue, 20 Dec 2005 19:17:06 -0800 From: Rob Siemborski <robsiemb@google.com> To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> X-Spam-Score: -4.3 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, Barry Leiba <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 12/19/05, Vaudreuil, Greg M (Greg) <gregv@lucent.com> wrote: > This draft also does not discuss the management of the scripts. Are you = assuming > MANAGE SIEVE? I would prefer to see a fuller script management interface= included in > IMAP that subsumes basic management capabilities of the SIEVEFILTER comma= nd. Could we please strive to not throw everything *and* the entire kitchen sink into IMAP? MANAGESIEVE may not be perfect, but it can be improved without integrating into the IMAP protocol stream. In any case, SIEVEFILTER seems ripe to be an annotation instead of a command (though then we can have the discussion about ACAP-in-IMAP instead :). -Rob -- Rob Siemborski | PGP:0x5CE32FCC | robsiemb@google.com Software Engineer | | 650-623-6925 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 20 22:44:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EouuH-0003xA-Tm; Tue, 20 Dec 2005 22:44:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EouuG-0003we-SX for lemonade@megatron.ietf.org; Tue, 20 Dec 2005 22:44:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14963 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:43:44 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eouwn-0002uw-NY for lemonade@ietf.org; Tue, 20 Dec 2005 22:47:27 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBL3kfnY007259 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:46:41 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBL3iXk124304 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:44:34 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBL3iXu158050 for <lemonade@ietf.org>; Tue, 20 Dec 2005 22:44:33 -0500 Received: from SATURN ([9.12.239.194]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1135136666.209; Tue, 20 Dec 2005 22:44:26 -0400 Date: Tue, 20 Dec 2005 22:44:32 -0500 From: Barry Leiba <leiba@watson.ibm.com> To: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Message-ID: <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> In-Reply-To: <24238.1135006975.786474@peirce.dave.cridland.net> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave says... > There's quite a few mentions of atomic moves - these can be quite > slow for some mailstores, and in general they're tricky, and they > almost invariably involve maintaining locking on multiple mailboxes. I don't see that what I'm describing as an "atomic move" is any more of a burden for servers than COPY 5 Newmailbox STORE 5 +Flags.Silent (\Deleted) EXPUNGE What the spec means is that one of these "moves" must implement that sequence as one operation, and what that mostly means is that if something fails, none of it is done... and that the clients just see the EXPUNGE responses, and not the intermediate FETCH FLAGS(\Deleted) updates. Do we prefer to just let servers implement these moves as those three separate operations, and allow us to have intermediate states? Or do some agree with what Dave says later, that the moves aren't appropriate at all (see my comments below)? > Moreover, I really do fear what a na=C3=AFve client - or indeed any > client - will do when it casually flips a flag, and discovers the > message has just been expunged. The same thing it does when it sees any message expunged. I remind you that every client, nowever na=C3=AFve or worldly, MUST deal with = EXPUNGE responses, and the underlying expungement (is that a word?) of the messages. Why should you think this should be a problem? This can happen in other situations, such as this: Client 1 Client 2 C: X1 STORE 5 +Flags (\Deleted) S: * FETCH 5 Flags (\Deleted) C: T1 STORE 5 +Flags (\Answered) S: X1 OK done C: X2 EXPUNGE S: * 5 EXPUNGE S: T1 NO failed S: X2 OK done C: T2 NOOP S: * 5 EXPUNGE S: T2 OK done > most intelligent and aware client in the world, I don't see how it's > going to detect the difference between "this flag change caused the > message to be atomically moved" and "this flag change didn't happen > because the message was already expunged". I don't see why it has to detect the difference. Can you explain? > I also have a nasty feeling that some clients will take it upon > themselves to make setting the \Deleted flag instantly expunge the > message. This certainly doesn't give them license to do that. If someone wants to have a Sieve script do that, they certainly can, of course: if allof (${IMAPSieve.cause} :is "FLAG", hasflag "\\Deleted") { discard; } Whether this is a good idea or not is something the implementer of the script has to decide. > I also think it's likely to break UIDPLUS - a client will lose track > of apparently witnessed moves, because it has no idea of what the new > UID is, as well as not knowing if the message still exists somewhere > else on the server. If even one message is moved in a MULTIAPPEND, > then the APPENDUID response cannot be sent. Huh? This makes no sense. Even if the server responds with a UID, the message can disappear before the client can do anything with it anyway. This automates things, perhaps making such situations more apt to happen, but it doesn't change the fact that they can happen. > Section 3.8 suggests that even if the message isn't shifted about > atomically behind the client's back, and UIDPLUS actually works, then > because the headers may be edited, a client will potentially have the > wrong data in the cache. That IS a good point, and I'd originally started to write it to ban EditHeader, but then changed my mind. What do other client-writers think about this? > Oddly enough, I do think we could use reject, though. Reject could > generate a protocol level error, hence an APPEND or COPY to a mailbox > could be forced to fail for a fairly arbitrary reason, for instance. I hadn't thought about that. Yes, we could allow/define the reject action. Other comments? > Of course, with APPEND and LITERAL+, that's going to make client > implementors a little upset. Using APPEND with LITERAL+ is a bad idea anyway, since the server can always say NO to APPEND, without the client's being able to determine that in advance. Again, this doesn't change that. > Really, I think this ought to limit itself to two actions: >=20 > 1) Notifications, so that message appends, copies, and flag changes > can be sent to disconnected devices. >=20 > 2) Flag changes, primarily for interoperability between clients using > locally defined keywords. Noted. Do others agree? Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 20 23:27:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EovZ9-0003rP-DK; Tue, 20 Dec 2005 23:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EovZ7-0003px-Fk for lemonade@megatron.ietf.org; Tue, 20 Dec 2005 23:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18415 for <lemonade@ietf.org>; Tue, 20 Dec 2005 23:25:56 -0500 (EST) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eovbe-0003yP-M3 for lemonade@ietf.org; Tue, 20 Dec 2005 23:29:40 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBL4Quak012093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2005 20:26:56 -0800 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBL4QrE9007797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Dec 2005 20:26:55 -0800 Date: Tue, 20 Dec 2005 20:26:50 -0800 From: Mark Crispin <MRC@CAC.Washington.EDU> To: Barry Leiba <leiba@watson.ibm.com> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> Message-ID: <Pine.WNT.4.65.0512202011210.2748@Shimo-Tomobiki.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0a7aa2e6e558383d84476dc338324fab Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 20 Dec 2005, Barry Leiba wrote: > I don't see that what I'm describing as an "atomic move" is any more of > a burden for servers than > COPY 5 Newmailbox > STORE 5 +Flags.Silent (\Deleted) > EXPUNGE The operations that you describe are not a burden on servers. Mandating that these three operations become one atomic operation is a burden. An even greater burden is the implication that the "move" can take place without requiring additional storage equivalent to the sum of the message(s) being moved. This implication has been in requests for a "move" operation since day 1. This is a can of worms that I am loathe to see opened. >> Moreover, I really do fear what a naive client - or indeed any >> client - will do when it casually flips a flag, and discovers the >> message has just been expunged. > The same thing it does when it sees any message expunged. I remind you > that every client, nowever naive or worldly, MUST deal with EXPUNGE > responses The current IMAP specification guarantees that expunge events will not happen except at certain well-defined points. In particular, a client is guaranteed that no EXPUNGE events will happen during or between a FETCH or STORE. > Client 1 Client 2 > C: X1 STORE 5 +Flags (\Deleted) > S: * FETCH 5 Flags (\Deleted) > C: T1 STORE 5 +Flags (\Answered) > S: X1 OK done > C: X2 EXPUNGE > S: * 5 EXPUNGE > S: T1 NO failed S: X2 OK done > C: T2 NOOP > S: * 5 EXPUNGE > S: T2 OK done This is a broken scenario. As far as I am concerned, this is forbidden by the IMAP base specification, and that text to the contrary in RFC 2180 sections 4.1.2 and 4.1.3 is wrong. [Anyway, RFC 2180 is informational, not normative.] The correct response to command T1 is: * 5 FETCH (Flags (\Deleted \Answered)) T1 OK STORE completed (but this message is expunged, so it's gonna vanish) -- 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 From lemonade-bounces@ietf.org Tue Dec 20 23:40:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eovlu-0000Ib-Bo; Tue, 20 Dec 2005 23:40:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eovlr-0000HQ-NK for lemonade@megatron.ietf.org; Tue, 20 Dec 2005 23:40:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19377 for <lemonade@ietf.org>; Tue, 20 Dec 2005 23:39:06 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EovoQ-0004IO-6m for lemonade@ietf.org; Tue, 20 Dec 2005 23:42:50 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBL4g5oq018203 for <lemonade@ietf.org>; Tue, 20 Dec 2005 23:42:05 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBL4dvu223514 for <lemonade@ietf.org>; Tue, 20 Dec 2005 23:39:58 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBL4dvK219706 for <lemonade@ietf.org>; Tue, 20 Dec 2005 23:39:57 -0500 Received: from SATURN ([9.12.239.194]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1135139990.212; Tue, 20 Dec 2005 23:39:50 -0400 Date: Tue, 20 Dec 2005 23:39:57 -0500 From: Barry Leiba <leiba@watson.ibm.com> To: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Message-ID: <56D35EE27DEB2683A7FB1565@saturn.watson.ibm.com> In-Reply-To: <Pine.WNT.4.65.0512202011210.2748@Shimo-Tomobiki.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <Pine.WNT.4.65.0512202011210.2748@Shimo-Tomobiki.panda.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org >> COPY 5 Newmailbox >> STORE 5 +Flags.Silent (\Deleted) >> EXPUNGE > > Mandating that these three operations become one atomic operation is > a burden. OK. Well, as I said, the draft was a first pass. We can change it in one of two ways, so let's get opinions here. What we're discussing right now is what happens with existing messages (cause=FLAG and cause=ANNOTATE) if the implicit KEEP is cancelled. 1. We can change the text to say that "fileinto" behaves as though the Sieve script were a second client that did COPY/STORE/EXPUNGE, as above, and that "discard" behaves as though it did "STORE/EXPUNGE". 2. We can change it to ban "discard" and NEVER cancel the implicit keep (in which case "fileinto" just does a COPY). ...or we can hear other suggestions. Yes? > The current IMAP specification guarantees that expunge events will > not happen except at certain well-defined points. The current IMAP specification guarantees that EXPUNGE responses will not happen except at certain well-defined points. > This is a broken scenario. As far as I am concerned, this is > forbidden by the IMAP base specification Well, I think you know that we disagree strongly here. But I don't think it matters, so let's not get into it again. We should fix this by deciding how to write it into the imap-sieve spec so that we're all happy. My "atomic" wording was something to start with; I'm happy to change that to something else. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 06:15:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1w1-0000RT-4Z; Wed, 21 Dec 2005 06:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1vx-0000Qa-Ub for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 06:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25420 for <lemonade@ietf.org>; Wed, 21 Dec 2005 06:13:56 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep1yY-00083R-Ig for lemonade@ietf.org; Wed, 21 Dec 2005 06:17:44 -0500 Received: from [172.16.2.170] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 21 Dec 2005 11:14:27 +0000 Message-ID: <43A93914.1030005@isode.com> Date: Wed, 21 Dec 2005 11:14:28 +0000 From: Alexey Melnikov <alexey.melnikov@isode.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Randall Gellens <randy@qualcomm.com> Subject: Re: [lemonade] CATENATE, URLAUTH and RFC 2192bis References: <438E14BA.9080502@andrew.cmu.edu> <Pine.WNT.4.65.0511301631451.10700@Tomobiki-Cho.CAC.Washington.EDU> <p07000c10bfce391f807a@[192.168.1.13]> In-Reply-To: <p07000c10bfce391f807a@[192.168.1.13]> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, Mark Crispin <MRC@CAC.Washington.EDU> X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 4:35 PM -0800 11/30/05, Mark Crispin wrote: > >> On Wed, 30 Nov 2005, Ken Murchison wrote: >> >>> In other words, the client has no way of knowing whether the server >>> supports partial fetches. >> >> Unless we want to pull URLAUTH back from the RFC Editor queue, we >> will need a new new IMAP capability which announces support for >> ipartial in URLs. >> >> Is ipartial in URLs a LEMONADE requirement? I forget if it is or not. > Seems like it is needed to satisfy OMA requirements. >>> The solution would be to make RFC 2192bis the normative reference >>> for both CATENATE and URLAUTH. >> >> I think that this is a bad idea for URLAUTH. I hope that 2192bis >> will replace both RFC 2192 and URLAUTH by incorporating URLAUTH; but >> to do 2192bis properly will require time. > > Can it be done in time for Profile v2? If so, we could do a revision > of CATENATE and URLAUTH that makes 2192bis the normative reference, > and publish 2192bis, CATENATEbis, URLAUTHbis, and profile bis at the > same time. I think that is the plan, but we still need a new capability for partial support in IMAP URLs. Can the same capability cover use of partial in both CATENATE and URLAUTH? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 09:46:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5EC-00068w-W0; Wed, 21 Dec 2005 09:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5E9-00068U-Cx for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 09:46:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21720 for <lemonade@ietf.org>; Wed, 21 Dec 2005 09:44:56 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep5Gm-0007U7-9l for lemonade@ietf.org; Wed, 21 Dec 2005 09:48:45 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Ep5E2-0006an-0e for lemonade@ietf.org; Wed, 21 Dec 2005 14:45:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id AF018498003 for <lemonade@ietf.org>; Wed, 21 Dec 2005 14:47:25 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13877-08 for <lemonade@ietf.org>; Wed, 21 Dec 2005 14:47:15 +0000 (GMT) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:4f5:b25f:997c:cf8d]) by turner.dave.cridland.net (Postfix) with ESMTP id F2EC1498002 for <lemonade@ietf.org>; Wed, 21 Dec 2005 14:47:14 +0000 (GMT) Date: Wed, 21 Dec 2005 14:47:13 +0000 Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> In-Reply-To: <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> MIME-Version: 1.0 Message-Id: <3220.1135176434.535000@JOHN> From: Dave Cridland <dave@cridland.net> To: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Dec 21 03:44:32 2005, Barry Leiba wrote: > Dave says... >=20 > > There's quite a few mentions of atomic moves - these can be quite > > slow for some mailstores, and in general they're tricky, and they > > almost invariably involve maintaining locking on multiple=20 > mailboxes. >=20 > I don't see that what I'm describing as an "atomic move" is any=20 > more of > a burden for servers than > COPY 5 Newmailbox > STORE 5 +Flags.Silent (\Deleted) > EXPUNGE >=20 > What the spec means is that one of these "moves" must implement that > sequence as one operation, and what that mostly means is that if > something fails, none of it is done... That's the burdensome bit. > > Moreover, I really do fear what a na=EFve client - or indeed any > > client - will do when it casually flips a flag, and discovers the > > message has just been expunged. >=20 > The same thing it does when it sees any message expunged. I remind=20 > you > that every client, nowever na=EFve or worldly, MUST deal with EXPUNGE > responses, and the underlying expungement (is that a word?) of the I'm not sure that expungement is a word, but to a client, the phrase=20 you're looking for is "irrevocable destruction without trace". > messages. Why should you think this should be a problem? This can > happen in other situations, such as this: >=20 > Client 1 Client 2 > C: X1 STORE 5 +Flags (\Deleted) > S: * FETCH 5 Flags (\Deleted) > C: T1 STORE 5 +Flags (\Answered) > S: X1 OK done > C: X2 EXPUNGE > S: * 5 EXPUNGE > S: T1 NO failed S: X2 OK done > C: T2 NOOP > S: * 5 EXPUNGE > S: T2 OK done >=20 >=20 Right. But that's not what's happening. It's what *looks* like what's=20 happening, but it's not. > > most intelligent and aware client in the world, I don't see how=20 > it's > > going to detect the difference between "this flag change caused=20 > the > > message to be atomically moved" and "this flag change didn't=20 > happen > > because the message was already expunged". >=20 > I don't see why it has to detect the difference. Can you explain? >=20 >=20 The above case is a rare race condition, which isn't a big deal.=20 (That is, it's a circumstance that arises by a combination of events=20 happening in a precise timing, not a security flaw). When hit send on this message, your message (or rather, the copy of=20 it in my mailbox), will get flagged as answered by Polymer. If it=20 happens to be deleted by another session, that's not a real worry -=20 it's also pretty unlikely. If that happens to every message, Polymer doesn't know what's=20 happening, it just assumes that by fluke, some other session happens=20 to have vapourized the message. Polymer won't get paranoid, although the user might. If Polymer wanted to both answer the message and forward it, however,=20 it now can't - the act of answering the message has destroyed it=20 forever. Of course, in fact, it might not have been destroyed, but=20 Polymer cannot know that. If some other client had cheerfully decided to automatically sweep=20 read messages to an archival folder, that will instantly break things=20 badly for Polymer, and people will think that Polymer is broken, and=20 doesn't support attachments, since Polymer happens to be an online=20 client relying on the implicit Seen. You *could* add in protocol messages to indicate third-party COPY=20 operations, but Polymer won't understand those, so that doesn't=20 actually change the situation at all. Neither of these are problems with Polymer, incidentally. You can=20 subsitute any other client name you like. > > I also have a nasty feeling that some clients will take it upon > > themselves to make setting the \Deleted flag instantly expunge the > > message. >=20 > This certainly doesn't give them license to do that. That's exactly what it does do. This grants full license to anyone=20 and everyone to provide their very own favourite semantics for=20 mailstores. > If someone wants > to have a Sieve script do that, they certainly can, of course: >=20 > if allof (${IMAPSieve.cause} :is "FLAG", hasflag "\\Deleted") { > discard; > } >=20 > Whether this is a good idea or not is something the implementer of=20 > the > script has to decide. >=20 >=20 No, it's not. It's up to the one client author who doesn't like a two=20 phase delete, and sticks an innocuous checkbox marked "Delete=20 Immediately" somewhere. Moreover, there are already server implementors who use precisely the=20 arguments you do here to do immediate expunges of messages. This=20 makes the argument altogether easier - "Well, *if* I supported X, and=20 *if* there was a script Y, then... So it doesn't make a difference." > > I also think it's likely to break UIDPLUS - a client will lose=20 > track > > of apparently witnessed moves, because it has no idea of what the=20 > new > > UID is, as well as not knowing if the message still exists=20 > somewhere > > else on the server. If even one message is moved in a MULTIAPPEND, > > then the APPENDUID response cannot be sent. >=20 > Huh? This makes no sense. Even if the server responds with a UID,=20 > the > message can disappear before the client can do anything with it=20 > anyway. > This automates things, perhaps making such situations more apt to > happen, but it doesn't change the fact that they can happen. >=20 >=20 Okay, so it can lie about the UIDs all the time, breaking the=20 client's cache. That helps things in a Lemonade setting how, exactly?=20 Clients will waste storage space until they happen to look at the=20 mailbox and realize that UID doesn't exist anymore, never knowing=20 that attempting to preserve the cache was a waste of time and=20 resource. In any case, I really dislike the notion of a server saying "OK, I=20 did what you asked, here is the result", and the client later finding=20 out that not only did the server lie about the result, but it did=20 something completely different, which the client cannot find out=20 about. All this is not to say that the likes of fileinto and discard have no=20 purpose for IMAP-level Sieve, just that they really shouldn't be=20 implicit actions that the client might be unaware of. Running a Sieve=20 script explicitly over a set of messages would be nice, and would=20 allow for all sorts of useful behaviour, commonly handled by clients=20 locally: - It could be used to flag a set of messages matching complex=20 criteria currently unexpressable in IMAP's SEARCH. - It could be used to sweep old or irrelevent messages from the INBOX. - etc. The key thing here is "explicit" - the client wouldn't be taken by=20 surprise here, and existing semantics aren't broken. > > Section 3.8 suggests that even if the message isn't shifted about > > atomically behind the client's back, and UIDPLUS actually works,=20 > then > > because the headers may be edited, a client will potentially have=20 > the > > wrong data in the cache. >=20 > That IS a good point, and I'd originally started to write it to ban > EditHeader, but then changed my mind. What do other client-writers > think about this? >=20 >=20 Without meaning to sound arrogant, it doesn't matter a jot what=20 anyone thinks. Message content in IMAP is immutable. The only way to=20 allow EditHeader would be to allocate a new UID for the message,=20 which in turn destroys the cache. These message moves and edits *do* destroy the cache. You're=20 increasing the chances of a client downloading the same thing twice,=20 wasting both a round trip *and* a hefty chunk of bandwidth. I don't=20 see why this can possibly be considered a good thing. > > Oddly enough, I do think we could use reject, though. Reject could > > generate a protocol level error, hence an APPEND or COPY to a=20 > mailbox > > could be forced to fail for a fairly arbitrary reason, for=20 > instance. >=20 > I hadn't thought about that. Yes, we could allow/define the reject > action. Other comments? >=20 > > Of course, with APPEND and LITERAL+, that's going to make client > > implementors a little upset. >=20 > Using APPEND with LITERAL+ is a bad idea anyway, since the server=20 > can > always say NO to APPEND, without the client's being able to=20 > determine > that in advance. Again, this doesn't change that. >=20 >=20 No, it most certainly does change this. If a client understands ACL sufficient to handle MYRIGHTS, then a=20 failed APPEND becomes very much an exceptional condition, and it can=20 eliminate one round trip by using LITERAL+. Moreover, failed APPENDs *are* exceptional anyway, given that they're=20 almost always used in the message send scenario, and, in general, if=20 an APPEND works once, it'll work again. Failed COPY is relatively=20 common, but a failed APPEND is usually a sign of misconfiguration in=20 real-world MUAs. Of course, theoretically, all things are possible, but theory is only=20 right in theory. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 11:06:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6Tg-0001oA-Ey; Wed, 21 Dec 2005 11:06:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6Tf-0001o0-Ap for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 11:06:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07343 for <lemonade@ietf.org>; Wed, 21 Dec 2005 11:05:02 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep6WJ-0003LR-II for lemonade@ietf.org; Wed, 21 Dec 2005 11:08:52 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBLG80lB009247 for <lemonade@ietf.org>; Wed, 21 Dec 2005 11:08:00 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBLG5ru236378 for <lemonade@ietf.org>; Wed, 21 Dec 2005 11:05:53 -0500 Received: from [9.12.242.139] ([9.12.242.139]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBLG5qK236376 for <lemonade@ietf.org>; Wed, 21 Dec 2005 11:05:52 -0500 Message-ID: <43A97D60.5070505@watson.ibm.com> Date: Wed, 21 Dec 2005 11:05:52 -0500 From: Barry Leiba <leiba@watson.ibm.com> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> In-Reply-To: <3220.1135176434.535000@JOHN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > If Polymer wanted to both answer the message and forward it, however, it > now can't - the act of answering the message has destroyed it forever. > Of course, in fact, it might not have been destroyed, but Polymer cannot > know that. Sieve scripts are meant to be user-defined things; if the user wants to file \Answered messages away, and remove them from her inbox, I think the user should be able to do that. I suppose what it comes down to is that you're arguing that clients should provide that function, and users who want it should choose clients that do. And that the function shouldn't be available on the server, through Sieve scripts. That argument is fine, but for "diverse service environments", where we might WANT some of this stuff done on the server. When we get down to it, though, this document was written because of the need to do notifications, so my thoughts about what else one might do with these functions are speculative. See below. >> > I also have a nasty feeling that some clients will take it upon >> > themselves to make setting the \Deleted flag instantly expunge the >> > message. >> >> This certainly doesn't give them license to do that. > > That's exactly what it does do. This grants full license to anyone and > everyone to provide their very own favourite semantics for mailstores. It does not, and I can't see how you can claim that. But let's not get into an "Is so! / Is not!" match. >> Whether this is a good idea or not is something the implementer of the >> script has to decide. >> > No, it's not. It's up to the one client author who doesn't like a two > phase delete, and sticks an innocuous checkbox marked "Delete > Immediately" somewhere. Oh, be real: a client author who wants to do that already can, by just putting in the checkbox and putting code in that always sends EXPUNGE whenever it sets the \Deleted flag. The IMAP spec is quite clear about that being a bad idea, and clients insist on implementing "Trash" mailboxes anyway. This doesn't change anything with respect to THAT. > Okay, so it can lie about the UIDs all the time, breaking I had thought that UIDPLUS allowed an "I don't know the UID" response; as I look again, I see that it doesn't. OK. So we get back to the choices in my response to Mark, extended to the "new message" case. Again, see below. > Running a Sieve script explicitly over a set of messages would be nice, > and would allow for all sorts of useful behaviour, commonly handled by > clients locally: That's a good idea, which might be good to add here: an IMAP RUNSIEVE command, with a corresponding cause=RUNSIEVE. I like it. Do others? Shall I add it? > Without meaning to sound arrogant, it doesn't matter a jot what anyone > thinks. Message content in IMAP is immutable. The only way to allow > EditHeader would be to allocate a new UID for the message, which in turn > destroys the cache. Uh, we ARE assigning new UIDs, and we're NOT changing headers on existing messages. My draft explicitly says that the EditHeader actions are only available for NEW MESSAGES, and so only for cause=APPEND and cause=COPY. That said, you've brought up a point that I hadn't considered: that clients expect the messages created by APPEND and COPY to be unchanged, and that this will hurt their message cache. It might be best, then, to go with my original thought of banning EditHeader in all cases. Any objections? It's "below" now: In my response to Mark, I suggested that we choose to change what happens for cause=FLAG and cause=ANNOTATE in one of these ways (and we have to decide): 1. Have the Sieve script actually behave as a client that has issued the appropriate COPY/STORE/EXPUNGE commands (and, actually, we can discuss whether to eliminate the EXPUNGE from there). 2. ALWAYS retain the implicit keep. Let's expand that to the cases of cause=APPEND and cause=COPY, and say that for the new messages created like that, we actually DO store the message first (which gives the UIDPLUS response code), and THEN behave as we choose, above, for existing messages. I think this will take care of most of the concerns that Dave has raised, though, of course, there's still the issue of wasted effort and resource in the client if we choose option 1. I'm more and more in favour of saying that for all of the cases described in this document, we retain the implicit keep... EXCEPT that we allow the "reject" action, which gives a protocol-level NO to APPEND/MULTIAPPEND/COPY, and stores nothing. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 12:11:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7VJ-0001MP-5M; Wed, 21 Dec 2005 12:11:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7VH-0001MH-S3 for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 12:11:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16719 for <lemonade@ietf.org>; Wed, 21 Dec 2005 12:10:46 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep7Xq-0005bU-LJ for lemonade@ietf.org; Wed, 21 Dec 2005 12:14:37 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jBLHBd3F023116 for <lemonade@ietf.org>; Wed, 21 Dec 2005 10:11:40 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IRU00C01XRNOR00@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for lemonade@ietf.org; Wed, 21 Dec 2005 10:11:39 -0700 (MST) Received: from NIKITA.sun.com ([129.150.26.78]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IRU004KCYFDSF40@mail-amer.sun.com>; Wed, 21 Dec 2005 10:11:39 -0700 (MST) Date: Wed, 21 Dec 2005 09:10:39 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA <Anil.Srivastava@Sun.COM> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-reply-to: <43A97D60.5070505@watson.ibm.com> To: Barry Leiba <leiba@watson.ibm.com> Message-id: <Pine.WNT.4.64.0512210903010.15156@NIKITA> Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7BIT Cc: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 2005-12-21/11:05 [-0500], leiba@watson.ibm.com [Barry Leiba] wrote: > > So we get back to the choices in my response to Mark, extended to the > "new message" case. Again, see below. > > > Running a Sieve script explicitly over a set of messages would be > > nice, and would allow for all sorts of useful behaviour, commonly > > handled by clients locally: > > That's a good idea, which might be good to add here: an IMAP RUNSIEVE > command, with a corresponding cause=RUNSIEVE. I like it. Do others? > Shall I add it? > That is something we have had customers ask for quite often. This is a function most clients support and there are legitimate use cases for such a capability. +1 > > Without meaning to sound arrogant, it doesn't matter a jot what > > anyone thinks. Message content in IMAP is immutable. The only way to > > allow EditHeader would be to allocate a new UID for the message, > > which in turn destroys the cache. > > Uh, we ARE assigning new UIDs, and we're NOT changing headers on > existing messages. My draft explicitly says that the EditHeader > actions are only available for NEW MESSAGES, and so only for > cause=APPEND and cause=COPY. > > That said, you've brought up a point that I hadn't considered: that > clients expect the messages created by APPEND and COPY to be > unchanged, and that this will hurt their message cache. It might be > best, then, to go with my original thought of banning EditHeader in > all cases. Any objections? > I have to agree with Dave's original assertion that allowing for headers to be edited is a bad thing so banning EditHeader sounds like the right thing to do. > > It's "below" now: > In my response to Mark, I suggested that we choose to change what > happens for cause=FLAG and cause=ANNOTATE in one of these ways (and we > have to decide): > > 1. Have the Sieve script actually behave as a client that has issued > the appropriate COPY/STORE/EXPUNGE commands (and, actually, we can > discuss whether to eliminate the EXPUNGE from there). > > 2. ALWAYS retain the implicit keep. > retain the implicit keep. Anil > Let's expand that to the cases of cause=APPEND and cause=COPY, and say > that for the new messages created like that, we actually DO store the > message first (which gives the UIDPLUS response code), and THEN behave > as we choose, above, for existing messages. > > I think this will take care of most of the concerns that Dave has > raised, though, of course, there's still the issue of wasted effort > and resource in the client if we choose option 1. I'm more and more > in favour of saying that for all of the cases described in this > document, we retain the implicit keep... EXCEPT that we allow the > "reject" action, which gives a protocol-level NO to > APPEND/MULTIAPPEND/COPY, and stores nothing. > > Barry > > -- > Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) > http://www.research.ibm.com/people/l/leiba > http://www.research.ibm.com/spam > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 12:28:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7ku-0004E4-Jm; Wed, 21 Dec 2005 12:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7kt-0004Dz-MJ for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 12:27:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19316 for <lemonade@ietf.org>; Wed, 21 Dec 2005 12:26:54 -0500 (EST) Received: from darius.cyrusoft.com ([63.163.82.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep7nY-0006KS-Rm for lemonade@ietf.org; Wed, 21 Dec 2005 12:30:45 -0500 Received: from [10.0.1.2] (pool-71-240-26-158.pitt.east.verizon.net [71.240.26.158]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id jBLHuIUV017310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 12:56:19 -0500 Date: Wed, 21 Dec 2005 12:27:49 -0500 From: Cyrus Daboo <cyrus@daboo.name> To: Barry Leiba <leiba@watson.ibm.com>, Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Message-ID: <118526A6593B0003F7943817@ninevah.local> In-Reply-To: <43A97D60.5070505@watson.ibm.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> X-Mailer: Mulberry/4.0.4 (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, hits=0.0 tests=none X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit 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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Barry, --On December 21, 2005 11:05:52 AM -0500 Barry Leiba <leiba@watson.ibm.com> wrote: >> Running a Sieve script explicitly over a set of messages would be nice, > > and would allow for all sorts of useful behaviour, commonly handled by > > clients locally: > > That's a good idea, which might be good to add here: an IMAP RUNSIEVE > command, with a corresponding cause=RUNSIEVE. I like it. Do others? > Shall I add it? Actually I have to say that despite my initial enthusiasm for the idea of incorporating sieve into IMAP, given the complexity we already have and all the arguments about simplifying things and not doing ACAP in IMAP etc, I am now leaning towards not using sieve. Instead, what I would propose for clients being able to 'run scripts', is a combination of the following: 1) Enhance the SEARCH command with better comparators (globbing, regex etc) 2) Introduce a 'pipe' operation that will allow the result set of the last (or named) search command to be fed into a subsequent fetch/store. I think there was already a proposal for that. 3) Introduce a 'macro' facility that would allow clients to define commonly used commands via a keyword and store those on the server, and then execute the commands via the keyword. This would allow for 'saved searches' - frequently used search commands stored on the server that can be quickly executed without having to uplaod the search each time. Anyone who has written a client that attempts to do traditional mua filtering using IMAP search will appreciate the benefit of something like that. These 'macros' could execute more than one command at a time with some limitations. e.g. a UID SEARCH followed by a UID COPY, followed by a UID STORE, followed by a UID expunge would emulate an mua filter action that could move messages matching certain criteria to another mailbox. These three things combined together can do the majority of what is needed, and won't require clients/servers to have sieve script handling capability - just a few (pretty basic) extensions to the IMAP protocol. That then leaves the question of whether it makes sense to use sieve for notifications. I would argue not - if its just for notifications. Lets define another IMAP extension for setting notification information. Maybe it results in something that is 'script-like' and if so perhaps SIEVE syntax could be borrowed for that, or maybe we stick with parenthesised lists as being more IMAP-like. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 13:10:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8QO-00053o-Fd; Wed, 21 Dec 2005 13:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8QK-00051V-QU for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 13:10:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25324 for <lemonade@ietf.org>; Wed, 21 Dec 2005 13:09:45 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep8Sv-0007sB-P3 for lemonade@ietf.org; Wed, 21 Dec 2005 13:13:34 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Ep8Q8-0002jJ-VP for lemonade@ietf.org; Wed, 21 Dec 2005 18:10:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DD077498003 for <lemonade@ietf.org>; Wed, 21 Dec 2005 18:12:09 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14675-06 for <lemonade@ietf.org>; Wed, 21 Dec 2005 18:12:03 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 34F97498002 for <lemonade@ietf.org>; Wed, 21 Dec 2005 18:12:03 +0000 (GMT) Date: Wed, 21 Dec 2005 18:10:29 +0000 Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> In-Reply-To: <43A97D60.5070505@watson.ibm.com> MIME-Version: 1.0 Message-Id: <28608.1135188629.806587@peirce.dave.cridland.net> From: Dave Cridland <dave@cridland.net> To: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Dec 21 16:05:52 2005, Barry Leiba wrote: > Dave Cridland wrote: >> If Polymer wanted to both answer the message and forward it,=20 >> however, it now can't - the act of answering the message has=20 >> destroyed it forever. Of course, in fact, it might not have been=20 >> destroyed, but Polymer cannot know that. >=20 > Sieve scripts are meant to be user-defined things; if the user=20 > wants to > file \Answered messages away, and remove them from her inbox, I=20 > think the > user should be able to do that. >=20 >=20 Yes. Out of curiosity, do you think all IMAP clients send the message=20 first, then flag as \Answered? Because if they don't, and they happen=20 to reference the message after flagging, perhaps via BURL, perhaps=20 not, for body parts, things might get a little confused if setting=20 \Answered causes the message to be destroyed. > I suppose what it comes down to is that you're arguing that clients=20 > should > provide that function, and users who want it should choose clients=20 > that do. > And that the function shouldn't be available on the server, through=20 > Sieve > scripts. >=20 >=20 Yes, but not because "that function shouldn't be available on the=20 server", but because IMAP servers should remain IMAP servers, and I=20 honestly think this breaks behaviour, because it allows different=20 clients to effectively define arbitrary semantics for flags which the=20 server then manages, in potentially confusing ways. I think allowing=20 message destruction as a automatic byproduct retrofitted onto FLAG=20 changes is opening a container full of worms, let alone a can. I=20 really cannot stress this enough. The APPEND/COPY automatic message destruction is more palatable to=20 me, but the only use for it I can actually see is the notion of=20 retrofitting complex filtering and searching[1], which in my mind=20 would be better handled explicitly, and I think there's at least a=20 economy sized can of worms here too. I very much doubt that I'll ever=20 be comfortable with this. To give a concrete example, I actually really like the notion of=20 telling a na=EFve client to store sent items in a folder which has an=20 APPEND/COPY Sieve script which relocates the message elsewhere,=20 depending on who it's sent to - I think it's a compelling use-case.=20 The only problem is that if a client then chooses to assemble the=20 message via CATENATE in that folder, quite innocently, then it'll=20 never find it again, so in practise a neat hack turns into serious=20 breakage. Which is a shame, as I think that's a reasonable thing for=20 a client to try doing, and worse, I cannot think of a workaround that=20 will interoperate with Lemonade Profile 1 clients. That's not a "concern", for me, that's a complete showstopper. > That argument is fine, but for "diverse service environments",=20 > where we > might WANT some of this stuff done on the server. >=20 >=20 Automated filing of older messages sounds cool to me. Hence an=20 explicit RUNSIEVE command, fully supported by the client. > When we get down to it, though, this document was written because=20 > of the > need to do notifications, so my thoughts about what else one might=20 > do with > these functions are speculative. See below. >=20 >=20 Sure. In general, I think you're on to something good. I just think=20 you're being a little *too* speculative. :-) Let's just stick with notifications, and optionally flag changes, for=20 now at least. I think reject needs a little more thought - I'm not=20 convinced it's a good idea. For a start, I realised that the=20 sync/non-sync literal problem doesn't even register - a Sieve script=20 is likely to want the entire message before deciding to reject it. Fileinto/discard really do scare the hell out of me. >>> > I also have a nasty feeling that some clients will take it upon >>> > themselves to make setting the \Deleted flag instantly expunge=20 >>> the >>> > message. >>>=20 >>> This certainly doesn't give them license to do that. >>=20 >> That's exactly what it does do. This grants full license to anyone=20 >> and everyone to provide their very own favourite semantics for=20 >> mailstores. >=20 > It does not, and I can't see how you can claim that. But let's not=20 > get > into an "Is so! / Is not!" match. >=20 >=20 Aw. We could do "Oh, yes, it is! / Oh, no, it isn't!" if you're up=20 for a bit of Pantomime, it is the season, after all. >>> Whether this is a good idea or not is something the implementer=20 >>> of the >>> script has to decide. >>>=20 >> No, it's not. It's up to the one client author who doesn't like a=20 >> two phase delete, and sticks an innocuous checkbox marked "Delete=20 >> Immediately" somewhere. >=20 > Oh, be real: a client author who wants to do that already can, by=20 > just > putting in the checkbox and putting code in that always sends=20 > EXPUNGE > whenever it sets the \Deleted flag. The IMAP spec is quite clear=20 > about > that being a bad idea, and clients insist on implementing "Trash" > mailboxes anyway. This doesn't change anything with respect to=20 > THAT. >=20 >=20 No, it means that one client author can not only instruct the server=20 to change the semantics for them, but impose their views on everybody=20 else. That's quite a major change, I think. >> Okay, so it can lie about the UIDs all the time, breaking >=20 > I had thought that UIDPLUS allowed an "I don't know the UID"=20 > response; > as I look again, I see that it doesn't. OK. >=20 >=20 Mark's newer draft does allow ommission of the UIDPLUS responses=20 (COPYUID and APPENDUID), but only, IIRC, in the case where the=20 mailbox declares itself as having non-sticky UIDs. In principle, I'd=20 be fine with dropping the response even so, but there's no method for=20 ommitting a single UID, in the case of MULTIAPPEND/COPY. >> Without meaning to sound arrogant, it doesn't matter a jot what=20 >> anyone thinks. Message content in IMAP is immutable. The only way=20 >> to allow EditHeader would be to allocate a new UID for the=20 >> message, which in turn destroys the cache. >=20 > Uh, we ARE assigning new UIDs, and we're NOT changing headers on=20 > existing > messages. My draft explicitly says that the EditHeader actions are=20 > only > available for NEW MESSAGES, and so only for cause=3DAPPEND and=20 > cause=3DCOPY. >=20 >=20 You misunderstood, and reading my own writing, I'm not surprised. I=20 meant allocate a new UID for the message compared with the one=20 generated by the normal APPEND/COPY mechanism and returned by=20 UIDPLUS. It doesn't help that I don't think of APPEND as operating on=20 a new message - messages are only copied in IMAP, in my mind,=20 creation happens outside its scope. > That said, you've brought up a point that I hadn't considered: that > clients expect the messages created by APPEND and COPY to be=20 > unchanged, Exactly. Hence where EditHeader is used, the clients see the message=20 instantly destroyed, exactly like your fileinto/discard proposals. [[ 1. Searching with Sieve, a imap-sieve hack: Create a fresh mailbox.=20 Add a Sieve script which discards messages you don't want on COPY. Go=20 through all source mailboxes you fancy, performing COPY 1:*. Finally,=20 open the fresh mailbox and see what you find. It's much more powerful=20 than the inbuilt IMAP SEARCH, and allows full "virtual scrolling"=20 through the results. ]] Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 21:16:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpG03-0001YF-8x; Wed, 21 Dec 2005 21:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpG01-0001XY-9T for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 21:16:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12096 for <lemonade@ietf.org>; Wed, 21 Dec 2005 21:15:04 -0500 (EST) Received: from smtp1-eth1.andrew.cmu.edu ([128.2.10.107] helo=smtp.andrew.cmu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpG2j-00086H-V5 for lemonade@ietf.org; Wed, 21 Dec 2005 21:18:59 -0500 Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBM2G7Zw011466 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <lemonade@ietf.org>; Wed, 21 Dec 2005 21:16:08 -0500 Message-ID: <43AA0C6F.7030201@andrew.cmu.edu> Date: Wed, 21 Dec 2005 21:16:15 -0500 From: Ken Murchison <murch@andrew.cmu.edu> Organization: Carnegie Mellon University User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih.lucent.com> <5b93232d0512201917v1bae366t2f4adbfecf4af40f@mail.google.com> In-Reply-To: <5b93232d0512201917v1bae366t2f4adbfecf4af40f@mail.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Rob Siemborski wrote: > On 12/19/05, Vaudreuil, Greg M (Greg) <gregv@lucent.com> wrote: > > >>This draft also does not discuss the management of the scripts. Are you assuming >>MANAGE SIEVE? I would prefer to see a fuller script management interface included in >>IMAP that subsumes basic management capabilities of the SIEVEFILTER command. > > > Could we please strive to not throw everything *and* the entire > kitchen sink into IMAP? MANAGESIEVE may not be perfect, but it can be > improved without integrating into the IMAP protocol stream. Agreed. > In any case, SIEVEFILTER seems ripe to be an annotation instead of a > command Yes. We use a /vendor/cmu/cyrus-imapd/sieve mailbox annotation for running a sieve script on a shared mailbox (bboards in CMU-speak). -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 21 21:21:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpG5M-0004Eo-8O; Wed, 21 Dec 2005 21:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpG5J-0004Eg-SX for lemonade@megatron.ietf.org; Wed, 21 Dec 2005 21:21:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12644 for <lemonade@ietf.org>; Wed, 21 Dec 2005 21:20:33 -0500 (EST) Received: from smtp1-eth1.andrew.cmu.edu ([128.2.10.107] helo=smtp.andrew.cmu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpG83-0008HW-Pz for lemonade@ietf.org; Wed, 21 Dec 2005 21:24:28 -0500 Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBM2Lbw6011783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <lemonade@ietf.org>; Wed, 21 Dec 2005 21:21:38 -0500 Message-ID: <43AA0DB9.4090500@andrew.cmu.edu> Date: Wed, 21 Dec 2005 21:21:45 -0500 From: Ken Murchison <murch@andrew.cmu.edu> Organization: Carnegie Mellon University User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih. lucent.com> <95A94706953659E3C212F982@saturn.watson.ibm.com> In-Reply-To: <95A94706953659E3C212F982@saturn.watson.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Barry Leiba wrote: > > I'm not sure we'll get consensus on an extensive script-management > interface in IMAP -- it's quite an overload for IMAP. That's why I > left the "SIEVEFILTER" command unspecified, and just there as something > to open discussion on the issue. Managesieve can certainly be > extended, and perhaps this draft should add another section, replacing > the SIEVEFILTER stuff, that extends managesieve to handle causes and > multiple active scripts, at least. > > Do others have comments there? I think we need to either extend MANAGESIEVE or use mailbox annotations (Cyrus currently does the latter for running a script when a message is delivered to a shared mailbox) -- Kenneth Murchison Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 22 14:47:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpWPr-00070N-PH; Thu, 22 Dec 2005 14:47:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpWPq-00070I-81 for lemonade@megatron.ietf.org; Thu, 22 Dec 2005 14:47:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25266 for <lemonade@ietf.org>; Thu, 22 Dec 2005 14:46:49 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpWSi-0007NQ-59 for lemonade@ietf.org; Thu, 22 Dec 2005 14:50:53 -0500 X-IronPort-AV: i="3.99,285,1131339600"; d="scan'208"; a="24709532:sNHT29329920" 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 Date: Thu, 22 Dec 2005 14:47:45 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701DDD2CA@ATLANTIS.Brooktrout.com> Thread-Topic: LEMONADE Interim Agenda and Venue Thread-Index: AcYHMJRf+PCQ2nlDR6m5GcEZIh8B5A== From: "Burger, Eric" <eburger@brooktrout.com> To: <lemonade@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [lemonade] LEMONADE Interim Agenda and Venue X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Please bash this agenda. We will attempt to put times to the different documents, so very remote folks can chose when to call in. Likewise, if you are very remote, please send us your time slot requests for a given document of interest to you. IETF LEMONADE Interim Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Logistics --------- Day 1: January 24, 2006, noon - 5pm China Time [London: 4am (1/24) - 9am (1/24)] [Boston: 11pm (1/23) - 4am (1/24)] [SF: 8pm (1/23) - 1am (1/24)] Day 2: January 25, 2006, 8am - noon China Time [London: 1am (1/25) - 5am (1/25)] [Boston: 8pm (1/24) - 12am (1/25)] [SF: 5pm (1/24) - 9pm (1/24)] Dinner will be provided the evening of the 24th by our host, China Mobile Communications Corporation Venue: Beijing, CN (Hotel Will Be Announced Shortly) Remote Access: o High-Speed Internet o Conference Bridge w/ Local Numbers o SIP Access to Conference Bridge may be possible Proposed Agenda --------------- Presentation on LEMONADE market drivers (service provider) Document status - last calls, RFC editor, etc.=20 OMA liaison=20 Phase 2 work items:=20 - Reconnect draft-ietf-lemonade-reconnect-xx - Filter draft-ietf-lemonade-convert-xx *draft-ietf-lemonade-sieve-xx draft-maes-lemonade-vfolder-xx - Content Transformation draft-ietf-lemonade-convert-xx *draft-ietf-lemonade-channel derivatives for streaming - S2C notifications draft-maes-lemonade-notifications-server-to-client-01.txt *draft-ietf-lemonade-notifications-xx - Compression draft-maes-lemonade-lzip-01.txt - Firewalls draft-maes-lemonade-http-binding-01.txt draft-smaes-lemonade-intermediary-challenges-01.txt * items not yet available as drafts _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 22 15:41:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXFv-0001An-GK; Thu, 22 Dec 2005 15:41:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXFt-00019f-MX for lemonade@megatron.ietf.org; Thu, 22 Dec 2005 15:41:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01577 for <lemonade@ietf.org>; Thu, 22 Dec 2005 15:40:34 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpXIj-0000ef-0u for lemonade@ietf.org; Thu, 22 Dec 2005 15:44:39 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 9F8292A83; Thu, 22 Dec 2005 13:41:24 -0700 (MST) In-Reply-To: <118526A6593B0003F7943817@ninevah.local> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Thu, 22 Dec 2005 12:41:22 -0800 To: Cyrus Daboo <cyrus@daboo.name> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org>, Barry Leiba <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 21-Dec-05, at 9:27 AM, Cyrus Daboo wrote: > These three things combined together can do the majority of what is > needed, and won't require clients/servers to have sieve script > handling capability - just a few (pretty basic) extensions to the > IMAP protocol. > > That then leaves the question of whether it makes sense to use > sieve for notifications. I would argue not - if its just for > notifications. Lets define another IMAP extension for setting > notification information. Maybe it results in something that is > 'script-like' and if so perhaps SIEVE syntax could be borrowed for > that, or maybe we stick with parenthesised lists as being more IMAP- > like. I agree with Cyrus and this is the best solution to date. Anyone else want to move in this direction? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 22 15:44:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXIL-0002UV-GU; Thu, 22 Dec 2005 15:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXIJ-0002UI-Ba for lemonade@megatron.ietf.org; Thu, 22 Dec 2005 15:44:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01791 for <lemonade@ietf.org>; Thu, 22 Dec 2005 15:43:06 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpXLB-0000ju-Pz for lemonade@ietf.org; Thu, 22 Dec 2005 15:47:11 -0500 X-IronPort-AV: i="3.99,285,1131339600"; d="scan'208"; a="24711616:sNHT46194696" 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 Date: Thu, 22 Dec 2005 15:44:06 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701DDD341@ATLANTIS.Brooktrout.com> Thread-Topic: Lemonade Interim Thread-Index: AcYHOHO+5onsSO/aQDmfRZzWa5Nweg== From: "Burger, Eric" <eburger@brooktrout.com> To: <lemonade@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Lemonade Interim X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I have updated the Supplemental Web Site, <http://flyingfox.snowshore.com/i-d/lemonade/> with up-to-the-minute news and information, including the *correct* non-Beijing start and end times, as well as links to the drafts. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 22 15:46:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXKv-0003Qq-QD; Thu, 22 Dec 2005 15:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EolP0-0006M6-Qv; Tue, 20 Dec 2005 12:35:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05268; Tue, 20 Dec 2005 12:34:51 -0500 (EST) Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EolRR-0006Qz-KV; Tue, 20 Dec 2005 12:38:27 -0500 Received: from localhost (ka [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 358F623598; Tue, 20 Dec 2005 12:35:47 -0500 (EST) Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08443-10; Tue, 20 Dec 2005 12:35:45 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 3C77E2356A; Tue, 20 Dec 2005 12:35:45 -0500 (EST) Message-ID: <43A840F0.3080101@cs.utk.edu> Date: Tue, 20 Dec 2005 12:35:44 -0500 From: Keith Moore <moore@cs.utk.edu> User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Burger, Eric" <eburger@brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701D93F05@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701D93F05@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Dec 2005 15:46:51 -0500 Cc: lemonade@ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, ietf@ietf.org Subject: [lemonade] Re: Announcement: Notifications List X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Burger, Eric wrote: > In Vancouver in the lemonade work group meeting a number of people > expressed interest in the creation of a list dedicated to the discussion > of user notification technology. > > This list is for discussions relating to the requirements, definition, > and directions for message notifications. > > While many requirements are driven by lemonade, there is a broader > community with interest and expertise that we hope will contribute to > the discussion here. > > Please keep discussions that relate to lemonade, smtp, simple, etc. on > their respective lists. Please do not impose this constraint. There is already far too much tendency for narrowly-focused groups to work in isolation and to ignore useful input from parties whose interests are peripheral to the group but affected by the group's output. This in turn causes groups to get strong pushback at Last Call which could have been avoided had the group not isolated itself. > Please keep cross-posting to a minimum. Cross-posting to a number of > lists will put your message into the spam bucket and will delay or deny > your message being posted. If the list manager is going to impose restrictions such as this, it would be better if such discussion happened elsewhere than on this list. Keith _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 22 15:46:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXKw-0003RJ-80; Thu, 22 Dec 2005 15:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eolyi-0000mI-Lp; Tue, 20 Dec 2005 13:12:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10095; Tue, 20 Dec 2005 13:11:45 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eom18-0007lM-ND; Tue, 20 Dec 2005 13:15:21 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <20051220181234014008ig6se>; Tue, 20 Dec 2005 18:12:35 +0000 From: "David B Harrington" <ietfdbh@comcast.net> To: "'Burger, Eric'" <eburger@brooktrout.com> Date: Tue, 20 Dec 2005 13:12:29 -0500 Message-ID: <025b01c60590$f16b5310$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYFjC3i19RMaWoNStiN86IV5KIvygABCSBQ In-Reply-To: <43A840F0.3080101@cs.utk.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Dec 2005 15:46:51 -0500 Cc: lemonade@ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, ietf@ietf.org Subject: [lemonade] RE: Announcement: Notifications List X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > Burger, Eric wrote: > > > > This list is for discussions relating to the requirements, > definition, > > and directions for message notifications. Is this message notifications related to specific technologies, or is this a general notification mechanism? If it's a general notification mechanism, then shouldn't this be addressed within the O&M area, where discussion of notification mechanisms is already ongoing? David Harrington dbharrington@comcast.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 14:30:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epsc9-0002b1-VJ; Fri, 23 Dec 2005 14:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epsc8-0002aa-69 for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 14:30:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25614 for <lemonade@ietf.org>; Fri, 23 Dec 2005 14:28:57 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpsfC-0005g4-DC for lemonade@ietf.org; Fri, 23 Dec 2005 14:33:15 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 5CD592A85 for <lemonade@ietf.org>; Fri, 23 Dec 2005 12:30:01 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43ABF65E.2080406@sun.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Fri, 23 Dec 2005 11:29:58 -0800 To: Enhancements to Internet email to support diverse service enivronments <lemonade@ietf.org> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 23-Dec-05, at 5:06 AM, Arnaud Taddei wrote: > Curtis King wrote: > >> >> On 21-Dec-05, at 9:27 AM, Cyrus Daboo wrote: >> >> >>> These three things combined together can do the majority of what >>> is needed, and won't require clients/servers to have sieve >>> script handling capability - just a few (pretty basic) >>> extensions to the IMAP protocol. >>> >>> That then leaves the question of whether it makes sense to use >>> sieve for notifications. I would argue not - if its just for >>> notifications. Lets define another IMAP extension for setting >>> notification information. Maybe it results in something that is >>> 'script-like' and if so perhaps SIEVE syntax could be borrowed >>> for that, or maybe we stick with parenthesised lists as being >>> more IMAP- like. >>> >> >> I agree with Cyrus and this is the best solution to date. Anyone >> else want to move in this direction? >> > Isn't it what Chris Newman is working on these days? > Yes, and is an other good reason to consider Cyrus idea, only one type of notifications. Does any else think it's better to have the more general solution of extending SEARCH, adding a pipe operation and macros then incorporating sieve into IMAP? I like it because not only does it provide the functionality of incorporating sieve, but also improves IMAP as a whole and allows the servers to cache results for the macros. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 15:01:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ept6R-0002Dz-6v; Fri, 23 Dec 2005 15:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ept6Q-0002Cw-4D for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 15:01:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29071 for <lemonade@ietf.org>; Fri, 23 Dec 2005 15:00:14 -0500 (EST) Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ept9U-0006hD-0T for lemonade@ietf.org; Fri, 23 Dec 2005 15:04:33 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBNK1FVx021565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Dec 2005 12:01:15 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBNK1Eqv004230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2005 12:01:15 -0800 Date: Fri, 23 Dec 2005 12:01:14 -0800 (PST) From: Mark Crispin <mrc@CAC.Washington.EDU> To: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> Message-ID: <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_10 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 23 Dec 2005, Curtis King wrote: > Yes, and is an other good reason to consider Cyrus idea, only one type of > notifications. Does any else think it's better to have the more general > solution of extending SEARCH, adding a pipe operation and macros then > incorporating sieve into IMAP? I like it because not only does it provide the > functionality of incorporating sieve, but also improves IMAP as a whole and > allows the servers to cache results for the macros. I think that it is a terrible idea to add any more bloat to IMAP. -- 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 From lemonade-bounces@ietf.org Fri Dec 23 15:09:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptDw-0004KA-BW; Fri, 23 Dec 2005 15:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptDv-0004K5-Dg for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 15:09:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00442 for <lemonade@ietf.org>; Fri, 23 Dec 2005 15:07:59 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EptGz-00071I-T1 for lemonade@ietf.org; Fri, 23 Dec 2005 15:12:19 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 34A482A83; Fri, 23 Dec 2005 13:09:04 -0700 (MST) In-Reply-To: <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Fri, 23 Dec 2005 12:09:06 -0800 To: Mark Crispin <mrc@CAC.Washington.EDU> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 23-Dec-05, at 12:01 PM, Mark Crispin wrote: > On Fri, 23 Dec 2005, Curtis King wrote: >> Yes, and is an other good reason to consider Cyrus idea, only one >> type of notifications. Does any else think it's better to have the >> more general solution of extending SEARCH, adding a pipe operation >> and macros then incorporating sieve into IMAP? I like it because >> not only does it provide the functionality of incorporating sieve, >> but also improves IMAP as a whole and allows the servers to cache >> results for the macros. > > I think that it is a terrible idea to add any more bloat to IMAP. Adding sieve isn't adding more bloat? There is already suggest to add a RUNSIEVE command. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 15:22:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptQa-0007lo-0g; Fri, 23 Dec 2005 15:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptQW-0007k5-B2 for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 15:22:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01685 for <lemonade@ietf.org>; Fri, 23 Dec 2005 15:21:01 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EptTb-0007R1-9D for lemonade@ietf.org; Fri, 23 Dec 2005 15:25:20 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 2C0642A83; Fri, 23 Dec 2005 13:22:03 -0700 (MST) In-Reply-To: <BC65A3927A12642EA6D53CC6@saturn.watson.ibm.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <B0C49474-C337-4939-BDD3-88A8551EEA5F@mumbo.ca> <BC65A3927A12642EA6D53CC6@saturn.watson.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Fri, 23 Dec 2005 12:22:04 -0800 To: Barry Leiba <leiba@watson.ibm.com> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 23-Dec-05, at 11:44 AM, Barry Leiba wrote: >> Yes, and is an other good reason to consider Cyrus idea, only one >> type of notifications. Does any else think it's better to have the >> more general solution of extending SEARCH, adding a pipe operation >> and macros then incorporating sieve into IMAP? I like it because not >> only does it provide the functionality of incorporating sieve, but >> also improves IMAP as a whole and allows the servers to cache results >> for the macros. > > This would then argue for pulling notifications out of Sieve > altogether, and doing that function by using IMAP notifications on the > mailboxes. The only thing I worry about there is that we make sure > the > notification mechanism is independent of any client actions, because > they have to happen whether there's a client connected or not. Which > means they can't happen as the direct result of a SEARCH command -- > but > could be done by having a persistent SEARCH that the server handles > thereafter. I agree and to me either sieve or persistent SEARCH is the same amount of work. I see persistent SEARCH being useful outside of notifications or I maybe missing something. The question I'm struggling with which one would be a cleaner design? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 15:35:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eptdg-0002tO-5j; Fri, 23 Dec 2005 15:35:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eptdd-0002sw-NR for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 15:35:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03447 for <lemonade@ietf.org>; Fri, 23 Dec 2005 15:34:34 -0500 (EST) Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eptgi-0007rw-Fr for lemonade@ietf.org; Fri, 23 Dec 2005 15:38:53 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBNKZcjw026359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Dec 2005 12:35:38 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBNKZbMR015711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2005 12:35:38 -0800 Date: Fri, 23 Dec 2005 12:35:37 -0800 (PST) From: Mark Crispin <mrc@CAC.Washington.EDU> To: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> Message-ID: <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: cf4fa59384e76e63313391b70cd0dd25 Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 23 Dec 2005, Curtis King wrote: >> I think that it is a terrible idea to add any more bloat to IMAP. > Adding sieve isn't adding more bloat? There is already suggest to add a > RUNSIEVE command. Opposing one form of bloat does not constitute support for another form of bloat. The tendency to take the easy path of "add just one more new feature to IMAP" is something that should be vigorously resisted. -- 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 From lemonade-bounces@ietf.org Fri Dec 23 16:38:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epuc0-00023M-Cf; Fri, 23 Dec 2005 16:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epuby-00023E-IC for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 16:38:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10345 for <lemonade@ietf.org>; Fri, 23 Dec 2005 16:36:56 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epuf4-0001Sm-5e for lemonade@ietf.org; Fri, 23 Dec 2005 16:41:15 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 3A2232A85; Fri, 23 Dec 2005 14:37:51 -0700 (MST) In-Reply-To: <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <505BB402-338D-4BCD-83AB-DEE689DF84D9@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Fri, 23 Dec 2005 13:37:53 -0800 To: Mark Crispin <mrc@CAC.Washington.EDU> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 23-Dec-05, at 12:35 PM, Mark Crispin wrote: > On Fri, 23 Dec 2005, Curtis King wrote: >>> I think that it is a terrible idea to add any more bloat to IMAP. >> Adding sieve isn't adding more bloat? There is already suggest to >> add a RUNSIEVE command. > > Opposing one form of bloat does not constitute support for another > form of bloat. > > The tendency to take the easy path of "add just one more new > feature to IMAP" is something that should be vigorously resisted. So, I gather your not a fun of either sieve or macros ;) I thought it was an either/or discussion. The simplest way to get notifications is have a new notification protocol which IMAP servers, clients, sieve scripts, and out-band push notifications can all use. This is simple to implement, no extensions needed to IMAP, can reuse existing notification technologies, etc. I do believe you and Lyndon have suggested this before. I'm very curious why there is no interest in implementing such a service? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 17:19:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpvG7-0007ZO-0I; Fri, 23 Dec 2005 17:19:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpvG5-0007ZG-1s for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 17:19:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21194 for <lemonade@ietf.org>; Fri, 23 Dec 2005 17:18:23 -0500 (EST) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpvJA-00058U-Q0 for lemonade@ietf.org; Fri, 23 Dec 2005 17:22:42 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBNMJPCD004368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Dec 2005 14:19:26 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBNMJOnA019313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2005 14:19:25 -0800 Date: Fri, 23 Dec 2005 14:19:24 -0800 (PST) From: Mark Crispin <mrc@CAC.Washington.EDU> To: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: <505BB402-338D-4BCD-83AB-DEE689DF84D9@mumbo.ca> Message-ID: <Pine.OSX.4.64.0512231339240.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> <505BB402-338D-4BCD-83AB-DEE689DF84D9@mumbo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 23 Dec 2005, Curtis King wrote: > The simplest way to get notifications is have a new notification protocol > which IMAP servers, clients, sieve scripts, and out-band push notifications > can all use. This is simple to implement, no extensions needed to IMAP, can > reuse existing notification technologies, etc. I agree. > I do believe you and Lyndon > have suggested this before. I'm very curious why there is no interest in > implementing such a service? I am interested in implementing such a service. In 2002, I even implemented a prototype of such a service. It was a nice, sweet protocol, easy to implement. What's more, it had working code. I'm not the only person to have done something like this, either. The problem is that every time someone tries to produce a write up of such an effort, everybody immediately starts making the spurious "if <X> protocol does not have <Y> functionality, then <X> will die" argument to press to add everything but the kitchen sink. Each time this happens, the guy who did the work decides "I don't need this headache" and drops it. This is, sadly, a systemic problem throughout the IETF. -- 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 From lemonade-bounces@ietf.org Fri Dec 23 17:52:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpvmH-0000IZ-U0; Fri, 23 Dec 2005 17:52:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpvmG-0000HV-14 for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 17:52:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24196 for <lemonade@ietf.org>; Fri, 23 Dec 2005 17:51:37 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpvpM-00063Z-4g for lemonade@ietf.org; Fri, 23 Dec 2005 17:55:57 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 6BE282A83; Fri, 23 Dec 2005 15:52:38 -0700 (MST) In-Reply-To: <Pine.OSX.4.64.0512231339240.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> <505BB402-338D-4BCD-83AB-DEE689DF84D9@mumbo.ca> <Pine.OSX.4.64.0512231339240.9510@pangtzu.panda.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <A2536D48-C1C3-46AD-B735-8959A9DC35BB@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Fri, 23 Dec 2005 14:52:40 -0800 To: Mark Crispin <mrc@CAC.Washington.EDU> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 23-Dec-05, at 2:19 PM, Mark Crispin wrote: > > In 2002, I even implemented a prototype of such a service. It was > a nice, sweet protocol, easy to implement. What's more, it had > working code. > > I'm not the only person to have done something like this, either. +1 It's how I implemented IDLE. (btw large phone controls systems use a very simple event notification service) > > The problem is that every time someone tries to produce a write up > of such an effort, everybody immediately starts making the spurious > "if <X> protocol does not have <Y> functionality, then <X> will > die" argument to press to add everything but the kitchen sink. > Each time this happens, the guy who did the work decides "I don't > need this headache" and drops it. For what is worth, I would support such a simple protocol as it becomes possible to handle all the various race conditions. Just refer draft-ietf-lemonade-imap-sieve-00 looking for atomic operations to some of them. I found there is no limit on functionality it just get implemented in the client instead of the protocol. There is the add bonus for this working group of being able to addresses one of big issues, push notifications very quickly. Isn't that worth something? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 18:11:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epw4V-0005zt-BU; Fri, 23 Dec 2005 18:11:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epw4T-0005zo-3A for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 18:11:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25702 for <lemonade@ietf.org>; Fri, 23 Dec 2005 18:10:26 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epw7Y-0006aZ-VL for lemonade@ietf.org; Fri, 23 Dec 2005 18:14:46 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Epw4K-0008WB-RY; Fri, 23 Dec 2005 23:11:24 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 17581498003; Fri, 23 Dec 2005 23:13:21 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26733-10; Fri, 23 Dec 2005 23:13:15 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id B8E15498002; Fri, 23 Dec 2005 23:13:15 +0000 (GMT) Date: Fri, 23 Dec 2005 23:11:18 +0000 Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> <505BB402-338D-4BCD-83AB-DEE689DF84D9@mumbo.ca> <Pine.OSX.4.64.0512231339240.9510@pangtzu.panda.com> In-Reply-To: <Pine.OSX.4.64.0512231339240.9510@pangtzu.panda.com> MIME-Version: 1.0 Message-Id: <1832.1135379479.058411@peirce.dave.cridland.net> From: Dave Cridland <dave@cridland.net> To: Mark Crispin <mrc@CAC.Washington.EDU> Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Dec 23 22:19:24 2005, Mark Crispin wrote: > On Fri, 23 Dec 2005, Curtis King wrote: >> The simplest way to get notifications is have a new notification >> protocol which IMAP servers, clients, sieve scripts, and out-band >> push notifications can all use. This is simple to implement, no >> extensions needed to IMAP, can reuse existing notification >> technologies, etc. > > I agree. > > Yes, same. The tricky bit is that IMAP servers need to implement this, when the mail server package as a whole may already support Sieve, and there are also multiple Sieve implementations available easily. Arguably, adding some form of Sieve support to IMAP - possibly including adding Sieve test or scripts as a SEARCH criterion - effectively adds one item of bloat to IMAP, and passes the entire problem onto Sieve implementors, who're working hard and actively to develop Sieve, and solve many of the problems that IMAP would benefit from being solved. (I phrase this in this awkward way to avoid you thinking I mean "IMAP will die..." - because it won't. But it would be better.) To give an example, I've yet to find a conclusive, efficient, method of searching for messages with parts of a particular type without searching for strings likely to be found in the type's content, and then recutting the search locally - that's painful. The better alternative is to use Sieve, but that's only available at the point of delivery, so the method ends up being "tag mails with a user defined flag on delivery, hope that this is done before we actually need to find those parts". I'm not a huge fan of methods which include the word "hope". Extending SEARCH to allow for Sieve would solve this, and every issue Cyrus raised in his point 1. That all said, I think the interesting uses of Sieve are in post-delivery filtering and SEARCH, and not notifications. >> I do believe you and Lyndon have suggested this before. I'm very >> curious why there is no interest in implementing such a service? > > I am interested in implementing such a service. > > I'm sort of. I think that developing a generalized notification service is tricky. I think that developing a method for the IMAP server to be made to issue notifications (on IDLE or NOOP) might be possible. > In 2002, I even implemented a prototype of such a service. It was > a nice, sweet protocol, easy to implement. What's more, it had > working code. > > I'm not the only person to have done something like this, either. > > The outline you kindly sent me in private mail had one line in it that greatly interested me. You said, and I'm not quoting, something along the lines of using URLAUTH as an authentication-by-proxy for notification access. I mentioned this in passing to Philip Guenther, and between us (but mostly Philip), we arrived at the following concept: [Note this uses Magic in the approved sense of non-IETF] 1) Client requests from GENURLAUTH some form of URL not currently supported, such as SEARCH URLs, mailbox URLs, LIST URLs, etc. Server signs these and returns. 2) Client hands these via Magical Means to a Magic Notification Server. The interesting thing here is that said Magical Means might be SMS, WAP, or TCP. (Mark's implementation is TCP, in fact). 3) Said Magic Notification Server then hands these to IMAP server, using them to request notifications. These notifications are content-free, much like existing in-band IMAP notifications. Should a client which finally receives, or at least responds to, these notifications require content, it must connect, authenticate, and retrieve the content normally. This means that the nasty hideous part of notifications - that is, actually getting the notifications to the client - is actually placed neatly well out of scope of the servers. Thus a Magic Notification Server could be provided by a mobile network operator, or a mailserver ISV. Or even both, covering different actualy notification protocols. The IMAP extensions needed are fairly minimal - yes, we're extending the protocol, but we're not spending as much time extending the software required. > The problem is that every time someone tries to produce a write up > of such an effort, everybody immediately starts making the spurious > "if <X> protocol does not have <Y> functionality, then <X> will > die" argument to press to add everything but the kitchen sink. > Each time this happens, the guy who did the work decides "I don't > need this headache" and drops it. > > This is, sadly, a systemic problem throughout the IETF. No, there's a worse systemic problem, but that involves the creation of new protocols within the IETF. I think what you describe is merely a minor symptom of it. But that's another story for another time. For now, Merry Christmas for those that intend getting merry, Happy Yule for those willing to be happy, and best wishes for the new year, for those that actually have a new year at roughly this time. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 23 19:52:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epxdo-00080t-Ov; Fri, 23 Dec 2005 19:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epxdn-00080o-L2 for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 19:52:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05000 for <lemonade@ietf.org>; Fri, 23 Dec 2005 19:51:00 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epxgu-000179-PE for lemonade@ietf.org; Fri, 23 Dec 2005 19:55:22 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id D2BE02AC2; Fri, 23 Dec 2005 17:52:01 -0700 (MST) In-Reply-To: <1832.1135379479.058411@peirce.dave.cridland.net> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <5BFAF39C-F5A1-4F5D-99D6-2275FA73C875@mumbo.ca> <Pine.OSX.4.64.0512231157000.9510@pangtzu.panda.com> <8BC643F8-B333-42B0-BD71-32E26A1BDE30@mumbo.ca> <Pine.OSX.4.64.0512231233060.9510@pangtzu.panda.com> <505BB402-338D-4BCD-83AB-DEE689DF84D9@mumbo.ca> <Pine.OSX.4.64.0512231339240.9510@pangtzu.panda.com> <1832.1135379479.058411@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <994F3CDB-B413-4B27-B4EC-6F8D81B198C6@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King <cking@mumbo.ca> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Fri, 23 Dec 2005 16:52:04 -0800 To: Dave Cridland <dave@cridland.net> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Enhancements to Internet email to support diverse service enivronments <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 23-Dec-05, at 3:11 PM, Dave Cridland wrote: > On Fri Dec 23 22:19:24 2005, Mark Crispin wrote: >> On Fri, 23 Dec 2005, Curtis King wrote: >>> The simplest way to get notifications is have a new notification >>> protocol which IMAP servers, clients, sieve scripts, and out-band >>> push notifications can all use. This is simple to implement, no >>> extensions needed to IMAP, can reuse existing notification >>> technologies, etc. >> I agree. > Yes, same. The tricky bit is that IMAP servers need to implement > this, when the mail server package as a whole may already support > Sieve, and there are also multiple Sieve implementations available > easily. But, you still need to extend sieve to support notifications. I think imap-sieve is overloaded by providing a notification service. Instead it should reference the notification service being both a generator and consumer of events just like IMAP servers and clients. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Dec 26 10:04:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqtu2-00010A-KN; Mon, 26 Dec 2005 10:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqtu1-000105-9h for lemonade@megatron.ietf.org; Mon, 26 Dec 2005 10:04:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24585 for <lemonade@ietf.org>; Mon, 26 Dec 2005 10:03:36 -0500 (EST) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eqtxe-0001WJ-Q3 for lemonade@ietf.org; Mon, 26 Dec 2005 10:08:32 -0500 Received: from prosecco.oryx.com (prosecco.oryx.com [195.30.37.38]) by kalyani.oryx.com (Postfix) with ESMTP id D47DA4B0BD; Mon, 26 Dec 2005 16:04:25 +0100 (CET) Message-Id: <qBZexGmUaaOud3VZunFrtg.md5@prosecco.oryx.com> Date: Mon, 26 Dec 2005 16:02:31 +0100 From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <B0C49474-C337-4939-BDD3-88A8551EEA5F@mumbo.ca> <BC65A3927A12642EA6D53CC6@saturn.watson.ibm.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> In-Reply-To: <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> 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 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Curtis King writes: > I agree and to me either sieve or persistent SEARCH is the same > amount of work. I see persistent SEARCH being useful outside of > notifications or I maybe missing something. The question I'm > struggling with which one would be a cleaner design? We implemented persistent searches and found it clean and pleasant. Surprisingly so - suddenly we sat there looking at each other asking =ABthat's it? we're done?=BB A draft's sort of ready, all it needs is a references section. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Dec 26 14:57:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqySv-0004bT-BS; Mon, 26 Dec 2005 14:57:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqySt-0004bD-5y for lemonade@megatron.ietf.org; Mon, 26 Dec 2005 14:57:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26492 for <lemonade@ietf.org>; Mon, 26 Dec 2005 14:55:54 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqyWX-0002s1-F5 for lemonade@ietf.org; Mon, 26 Dec 2005 15:00:52 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBQJupT1020847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Dec 2005 11:56:51 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBQJu8j0029454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Dec 2005 11:56:51 -0800 Date: Mon, 26 Dec 2005 11:56:08 -0800 (PST) From: Mark Crispin <mrc@CAC.Washington.EDU> To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: <qBZexGmUaaOud3VZunFrtg.md5@prosecco.oryx.com> Message-ID: <Pine.OSX.4.64.0512261151300.9510@pangtzu.panda.com> References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <B0C49474-C337-4939-BDD3-88A8551EEA5F@mumbo.ca> <BC65A3927A12642EA6D53CC6@saturn.watson.ibm.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> <qBZexGmUaaOud3VZunFrtg.md5@prosecco.oryx.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __ISO_2022_JP_DELIM 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org, Barry Leiba <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 <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon, 26 Dec 2005, Arnt Gulbrandsen wrote: > We implemented persistent searches and found it clean and pleasant. > Surprisingly so - suddenly we sat there looking at each other asking > $B+(Bthat's it? we're done?$B;(B > A draft's sort of ready, all it needs is a references section. You're talking about Alexey's draft-melnikov-imap-search-res proposal, right? -- 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 From lemonade-bounces@ietf.org Tue Dec 27 08:42:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErF5e-000368-Re; Tue, 27 Dec 2005 08:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpmaO-0007cF-Fv for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 08:03:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08412 for <lemonade@ietf.org>; Fri, 23 Dec 2005 08:02:45 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpmdO-0000Zs-9c for lemonade@ietf.org; Fri, 23 Dec 2005 08:07:00 -0500 Received: from phys-zoom-2 ([129.156.48.47]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jBND3h3H017735 for <lemonade@ietf.org>; Fri, 23 Dec 2005 06:03:44 -0700 (MST) Received: from conversion-daemon.zoom-mail1.swiss.sun.com by zoom-mail1.swiss.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IRY00A01BON8S@zoom-mail1.swiss.sun.com> (original mail from Arnaud.Taddei@Sun.COM) for lemonade@ietf.org; Fri, 23 Dec 2005 14:03:42 +0100 (MET) Received: from [129.156.123.205] (d-egva01-205.Swiss.Sun.COM [129.156.123.205]) by zoom-mail1.swiss.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IRY006FUCA4A6@zoom-mail1.swiss.sun.com>; Fri, 23 Dec 2005 14:03:41 +0100 (MET) Date: Fri, 23 Dec 2005 14:06:38 +0100 From: Arnaud Taddei <Arnaud.Taddei@Sun.COM> Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-reply-to: <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> To: Curtis King <cking@mumbo.ca> Message-id: <43ABF65E.2080406@sun.com> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040914 References: <E43A80C785B4B3D755E2248B@saturn.watson.ibm.com> <24238.1135006975.786474@peirce.dave.cridland.net> <FC5426C366FCA6792AF4E3EC@saturn.watson.ibm.com> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> X-Spam-Score: 1.5 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-Mailman-Approved-At: Tue, 27 Dec 2005 08:42:09 -0500 Cc: Cyrus Daboo <cyrus@daboo.name>, diverse service enivronments <lemonade@ietf.org>, Barry Leiba <leiba@watson.ibm.com>, Chris Newman <Chris.Newman@Sun.COM>, Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe> List-Post: <mailto:lemonade@ietf.org> List-Help: <mailto:lemonade-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0321120060==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0321120060== Content-type: multipart/alternative; boundary="Boundary_(ID_UcazfJT00ZoZPBzK43f1GQ)" This is a multi-part message in MIME format. --Boundary_(ID_UcazfJT00ZoZPBzK43f1GQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT Curtis King wrote: > > On 21-Dec-05, at 9:27 AM, Cyrus Daboo wrote: > >> These three things combined together can do the majority of what is >> needed, and won't require clients/servers to have sieve script >> handling capability - just a few (pretty basic) extensions to the >> IMAP protocol. >> >> That then leaves the question of whether it makes sense to use sieve >> for notifications. I would argue not - if its just for >> notifications. Lets define another IMAP extension for setting >> notification information. Maybe it results in something that is >> 'script-like' and if so perhaps SIEVE syntax could be borrowed for >> that, or maybe we stick with parenthesised lists as being more IMAP- >> like. > > > I agree with Cyrus and this is the best solution to date. Anyone else > want to move in this direction? Isn't it what Chris Newman is working on these days? A++ > > ck > > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade -- <http://www.sun.com> * Arnaud Taddei * Senior Architect Communications Products *Sun Microsystems, Inc.* Phone x13541/+41(22)99904-41 Mobile +41 (0)79 506 1129 Email Arnaud.Taddei@Sun.COM --Boundary_(ID_UcazfJT00ZoZPBzK43f1GQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title> Curtis King wrote:

On 21-Dec-05, at 9:27 AM, Cyrus Daboo wrote:

These three things combined together can do the majority of what is  needed, and won't require clients/servers to have sieve script  handling capability - just a few (pretty basic) extensions to the  IMAP protocol.

That then leaves the question of whether it makes sense to use  sieve for notifications. I would argue not - if its just for  notifications. Lets define another IMAP extension for setting  notification information. Maybe it results in something that is  'script-like' and if so perhaps SIEVE syntax could be borrowed for  that, or maybe we stick with parenthesised lists as being more IMAP- like.

I agree with Cyrus and this is the best solution to date. Anyone else  want to move in this direction?
Isn't it what Chris Newman is working on these days?

A++

ck



_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade


--
Arnaud Taddei
Senior Architect Communications Products

Sun Microsystems, Inc.
Phone x13541/+41(22)99904-41
Mobile +41 (0)79 506 1129
Email Arnaud.Taddei@Sun.COM
--Boundary_(ID_UcazfJT00ZoZPBzK43f1GQ)-- --===============0321120060== 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 --===============0321120060==-- From lemonade-bounces@ietf.org Tue Dec 27 08:42:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErF5f-00036X-72; Tue, 27 Dec 2005 08:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epsqo-0006HS-BW for lemonade@megatron.ietf.org; Fri, 23 Dec 2005 14:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27258 for ; Fri, 23 Dec 2005 14:44:07 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epstr-0006AY-Py for lemonade@ietf.org; Fri, 23 Dec 2005 14:48:26 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBNJl4sG003971 for ; Fri, 23 Dec 2005 14:47:04 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBNJitu88790 for ; Fri, 23 Dec 2005 14:44:55 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBNJitK81022 for ; Fri, 23 Dec 2005 14:44:55 -0500 Received: from SATURN ([9.12.240.66]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1135367083.448; Fri, 23 Dec 2005 14:44:43 -0400 Date: Fri, 23 Dec 2005 14:44:52 -0500 From: Barry Leiba To: Curtis King , Arnaud Taddei Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Message-ID: In-Reply-To: References: <24238.1135006975.786474@peirce.dave.cridland.net> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Dec 2005 08:42:09 -0500 Cc: Cyrus Daboo , Enhancements to Internet email to support diverse service enivronments , Chris Newman 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > Yes, and is an other good reason to consider Cyrus idea, only one > type of notifications. Does any else think it's better to have the > more general solution of extending SEARCH, adding a pipe operation > and macros then incorporating sieve into IMAP? I like it because not > only does it provide the functionality of incorporating sieve, but > also improves IMAP as a whole and allows the servers to cache results > for the macros. This would then argue for pulling notifications out of Sieve altogether, and doing that function by using IMAP notifications on the mailboxes. The only thing I worry about there is that we make sure the notification mechanism is independent of any client actions, because they have to happen whether there's a client connected or not. Which means they can't happen as the direct result of a SEARCH command -- but could be done by having a persistent SEARCH that the server handles thereafter. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 27 08:59:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErFMi-0005m1-QA; Tue, 27 Dec 2005 08:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErFMh-0005lf-E4 for lemonade@megatron.ietf.org; Tue, 27 Dec 2005 08:59:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20383 for ; Tue, 27 Dec 2005 08:58:38 -0500 (EST) Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErFQW-00057U-9a for lemonade@ietf.org; Tue, 27 Dec 2005 09:03:46 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBRDxU62027052 for ; Tue, 27 Dec 2005 07:59:31 -0600 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBRDxU0l028306 for ; Tue, 27 Dec 2005 06:59:30 -0700 Received: from us.oracle.com (dhcp-amer-whq-csvpn-gw3-141-144-81-112.vpn.oracle.com [141.144.81.112]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBRDxTFX028298 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 27 Dec 2005 06:59:30 -0700 From: "Stephane H. Maes" To: "Enhancements to Internet email to support diverse service enivronments" Subject: RE: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Tue, 27 Dec 2005 05:59:18 -0800 In-Reply-To: X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20051227055918903.00000004952@smaes-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I think we may be mixing how notification are integrated with IMAP versus h= ow they can be bound to the event and generated via standard scripts. I am working on generating the S2C notification draft to address the first = part. The current draft focuses on how SIEVE can be used to realize the binding t= hat generates the notifications. Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Barry Leiba Sent: Friday, December 23, 2005 11:45 AM To: Curtis King; Arnaud Taddei Cc: Cyrus Daboo; Enhancements to Internet email to support diverse service = enivronments; Chris Newman Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 > Yes, and is an other good reason to consider Cyrus idea, only one > type of notifications. Does any else think it's better to have the > more general solution of extending SEARCH, adding a pipe operation > and macros then incorporating sieve into IMAP? I like it because not > only does it provide the functionality of incorporating sieve, but > also improves IMAP as a whole and allows the servers to cache results > for the macros. This would then argue for pulling notifications out of Sieve altogether, and doing that function by using IMAP notifications on the mailboxes. The only thing I worry about there is that we make sure the notification mechanism is independent of any client actions, because they have to happen whether there's a client connected or not. Which means they can't happen as the direct result of a SEARCH command -- but could be done by having a persistent SEARCH that the server handles thereafter. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 27 17:44:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNYW-0000qy-IU; Tue, 27 Dec 2005 17:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNYU-0000qt-PA for lemonade@megatron.ietf.org; Tue, 27 Dec 2005 17:44:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29215 for ; Tue, 27 Dec 2005 17:43:20 -0500 (EST) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErNcO-0007xm-QU for lemonade@ietf.org; Tue, 27 Dec 2005 17:48:34 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D1B0E4AE7C; Tue, 27 Dec 2005 23:44:20 +0100 (CET) Message-Id: Date: Tue, 27 Dec 2005 23:49:29 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <24238.1135006975.786474@peirce.dave.cridland.net> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Mark Crispin , Barry Leiba 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > You're talking about Alexey's draft-melnikov-imap-search-res proposal, right? No, about a new one of mine. Would you describe search-res as "persistent searches"? (Btw, PLEASE fix your MUA. You wrote RFC 1469 - if anyone can comply with it, you can.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Dec 27 18:16:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErO3X-00064p-P3; Tue, 27 Dec 2005 18:16:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErO3V-00064h-Mh for lemonade@megatron.ietf.org; Tue, 27 Dec 2005 18:16:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02873 for ; Tue, 27 Dec 2005 18:15:21 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErO7O-0000e0-AT for lemonade@ietf.org; Tue, 27 Dec 2005 18:20:35 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBRNGMlU024677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Dec 2005 15:16:22 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jBRNGMtt007642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Dec 2005 15:16:22 -0800 Date: Tue, 27 Dec 2005 15:14:21 -0800 (Pacific Standard Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 In-Reply-To: Message-ID: References: <24238.1135006975.786474@peirce.dave.cridland.net> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org, Barry Leiba 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 27 Dec 2005, Arnt Gulbrandsen wrote: > No, about a new one of mine. Would you describe search-res as "persistent > searches"? I didn't say that. I'm trying to figure out what you are talking about. If it is not search-res, then what is it and what are its characteristics that make it better than search-res? > (Btw, PLEASE fix your MUA. You wrote RFC 1469 - if anyone can comply with it, > you can.) I did not write "IP Multicast over Token-Ring Local Area Networks"; you must be talking about RFC 1468. The message left my MUA in correct ISO-2022-JP (and yes, my MUA did translate them). Something downstream mangled it. In any case, you should stick to ASCII when sending messages to an international forum. -- 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 From lemonade-bounces@ietf.org Tue Dec 27 19:16:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOzM-0005FQ-HR; Tue, 27 Dec 2005 19:16:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOzK-00059H-UG for lemonade@megatron.ietf.org; Tue, 27 Dec 2005 19:16:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16218 for ; Tue, 27 Dec 2005 19:15:06 -0500 (EST) Received: from bda035.bis.na.blackberry.com ([216.9.249.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErP3C-0004rv-KW for lemonade@ietf.org; Tue, 27 Dec 2005 19:20:20 -0500 Received: from bda035-cell00.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda035.bis.na.blackberry.com (8.13.4 TEAMON/8.13.4) with ESMTP id jBS0DDeL024111; Wed, 28 Dec 2005 00:13:13 GMT Message-ID: <21087171.1135728793476.JavaMail.teamon@bda035-cell00.bisx.prod.on.blackberry> References: <24238.1135006975.786474@peirce.dave.cridland.net><3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com><118526A6593B0003F7943817@ninevah.local><65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca><43ABF65E.2080406@sun.com><698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> In-Reply-To: Sensitivity: Normal Importance: Normal To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 From: "Stephane H. Maes" Date: Wed, 28 Dec 2005 00:14:13 +0000 GMT MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephane.maes@oracle.com List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1384701721==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1384701721== Content-Transfer-Encoding: base64 Content-type: text/plain Content-Transfer-Encoding: base64 VmZvbGRlciBpcyBiYXNlZCBvbiBwZXJtYW5lbnQgc2VhcmNoIGEgbGEgcHNlYXJjaCBmcm9tIHBp bWFwLg0KDQpTdGVwaGFuZQ0KX19fX18KU3RlcGhhbmUgSC4gTWFlcywgUGhELApEaXJlY3RvciBv ZiBBcmNoaXRlY3R1cmUsIE1vYmlsZSwgVm9pY2UsIGFuZCBDb21tdW5pY2F0aW9ucyBQbGF0Zm9y bXMsIE9yYWNsZQpQaDogKzEtMjAzLTMwMC03Nzg2IChtb2JpbGUvU01TL3NreXBlKTsgRmF4IC8g T2ZmaWNlIFVNOiArMS02NTAtNjA3LTYyOTYuCmUtbWFpbDogc3RlcGhhbmUubWFlc0BvcmFjbGUu Y29tCklNOiBzaG1hZXMgKEFJTS9ZISkgb3Igc3RlcGhhbmVfbWFlc0Bob3RtYWlsLmNvbSAoTVNO IE1lc3NlbmdlcikNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFybnQgR3Vs YnJhbmRzZW4gPGFybnRAZ3VsYnJhbmRzZW4ucHJpdi5ubz4NCkRhdGU6IFR1ZSwgMjcgRGVjIDIw MDUgMjM6NDk6MjkgDQpUbzpsZW1vbmFkZUBpZXRmLm9yZw0KQ2M6TWFyayBDcmlzcGluIDxNUkNA Q0FDLldhc2hpbmd0b24uRURVPiwgQmFycnkgTGVpYmEgPGxlaWJhQHdhdHNvbi5pYm0uY29tPg0K U3ViamVjdDogUmU6IFtsZW1vbmFkZV0gZHJhZnQtaWV0Zi1sZW1vbmFkZS1pbWFwLXNpZXZlLTAw DQoNCk1hcmsgQ3Jpc3BpbiB3cml0ZXM6DQo+IFlvdSdyZSB0YWxraW5nIGFib3V0IEFsZXhleSdz IGRyYWZ0LW1lbG5pa292LWltYXAtc2VhcmNoLXJlcyBwcm9wb3NhbCwgcmlnaHQ/DQoNCk5vLCBh Ym91dCBhIG5ldyBvbmUgb2YgbWluZS4gV291bGQgeW91IGRlc2NyaWJlIHNlYXJjaC1yZXMgYXMg DQoicGVyc2lzdGVudCBzZWFyY2hlcyI/DQoNCihCdHcsIFBMRUFTRSBmaXggeW91ciBNVUEuIFlv dSB3cm90ZSBSRkMgMTQ2OSAtIGlmIGFueW9uZSBjYW4gY29tcGx5IA0Kd2l0aCBpdCwgeW91IGNh bi4pDQoNCkFybnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmxlbW9uYWRlIG1haWxpbmcgbGlzdA0KbGVtb25hZGVAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xlbW9uYWRlDQo= --===============1384701721== 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 --===============1384701721==-- From lemonade-bounces@ietf.org Wed Dec 28 11:03:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erdlp-0006Pv-Nv; Wed, 28 Dec 2005 11:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erdln-0006PV-Fw for lemonade@megatron.ietf.org; Wed, 28 Dec 2005 11:03:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23591 for ; Wed, 28 Dec 2005 11:02:09 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erdpr-0004gO-Kg for lemonade@ietf.org; Wed, 28 Dec 2005 11:07:31 -0500 X-IronPort-AV: i="3.99,304,1131339600"; d="scan'208"; a="24998472:sNHT30263616" 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 Date: Wed, 28 Dec 2005 11:03:09 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701E45CA3@ATLANTIS.Brooktrout.com> Thread-Topic: INTERIM MEETING VISA and Other Information Thread-Index: AcYLyDItngF7qUYVT6yhQGNlDPJjOw== X-Priority: 1 Priority: Urgent Importance: high From: "Burger, Eric" To: X-Spam-Score: 2.1 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] INTERIM MEETING VISA and Other Information 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org We have venue, hotel, and local information posted to the lemonade supplemental web site, . URGENT NOTICE: IF you chose to get a business visa, you MUST send CMCC a request for an invitation letter. Sending out your request today or tomorrow (or Tuesday) would be a very good thing, and will save YOU a lot of money and aggravation. Visa information is at=20 and from your local Chinese Embassy web page. IF you chose to get a business visa, the request form is at _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Dec 28 12:44:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErfMB-00075i-R1; Wed, 28 Dec 2005 12:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErfMB-00075d-6b for lemonade@megatron.ietf.org; Wed, 28 Dec 2005 12:44:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16583 for ; Wed, 28 Dec 2005 12:43:48 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErfQF-0003p9-OH for lemonade@ietf.org; Wed, 28 Dec 2005 12:49:12 -0500 X-IronPort-AV: i="3.99,304,1131339600"; d="scan'208"; a="25002666:sNHT28914480" 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 Date: Wed, 28 Dec 2005 12:44:49 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701E45D5E@ATLANTIS.Brooktrout.com> Thread-Topic: Drafts for Interim Thread-Index: AcYL1mZL+aOk4c/8Q0WwlyfkpUoSzw== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Drafts for Interim 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org If you are looking to submit a draft for the Interim, please submit it to the Internet Draft editor (internet-drafts@ietf.org) no later than noon on Tuesday, 10 January 2006. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 29 10:59:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es0Bh-0003cO-4m; Thu, 29 Dec 2005 10:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es0Bd-0003c8-V4 for lemonade@megatron.ietf.org; Thu, 29 Dec 2005 10:59:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11572 for ; Thu, 29 Dec 2005 10:58:18 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es0Ft-0001hO-Fk for lemonade@ietf.org; Thu, 29 Dec 2005 11:03:54 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id A63C32A85; Thu, 29 Dec 2005 08:59:18 -0700 (MST) In-Reply-To: <20051227055918903.00000004952@smaes-lap> References: <20051227055918903.00000004952@smaes-lap> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Thu, 29 Dec 2005 07:59:17 -0800 To: "stephane.maes@oracle.com" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 27-Dec-05, at 5:59 AM, Stephane H. Maes wrote: > > I think we may be mixing how notification are integrated with IMAP > versus how they can be bound to the event and generated via > standard scripts. True, but would be nice to have the referenced draft before the referring draft or I'm being too picky? > > I am working on generating the S2C notification draft to address > the first part. The notifcation protocol should be seperate from IMAP for the single reason other protocols (SMTP/LMTP) need to generate events as well. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 29 11:04:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es0GA-0005cj-Mk; Thu, 29 Dec 2005 11:04:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es0G8-0005cc-Vb for lemonade@megatron.ietf.org; Thu, 29 Dec 2005 11:04:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12283 for ; Thu, 29 Dec 2005 11:02:58 -0500 (EST) Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es0KP-0001s0-Vh for lemonade@ietf.org; Thu, 29 Dec 2005 11:08:34 -0500 Received: from [192.168.1.100] (s01060012170dd046.gv.shawcable.net [24.69.30.23]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 9D96C2AC2; Thu, 29 Dec 2005 09:04:06 -0700 (MST) In-Reply-To: References: <24238.1135006975.786474@peirce.dave.cridland.net> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 Date: Thu, 29 Dec 2005 08:04:05 -0800 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 27-Dec-05, at 2:49 PM, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> You're talking about Alexey's draft-melnikov-imap-search-res >> proposal, right? > > No, about a new one of mine. Would you describe search-res as > "persistent searches"? It sure covers part of the problem space. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 29 12:42:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es1n8-0007KM-2d; Thu, 29 Dec 2005 12:42:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es1n6-0007KE-A3 for lemonade@megatron.ietf.org; Thu, 29 Dec 2005 12:42:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23160 for ; Thu, 29 Dec 2005 12:41:04 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es1rN-00052q-MZ for lemonade@ietf.org; Thu, 29 Dec 2005 12:46:42 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBTHfwrF018250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 29 Dec 2005 09:41:58 -0800 Received: from [129.46.172.15] (vpn-10-50-0-98.qualcomm.com [10.50.0.98]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBTHfuYg019829 for ; Thu, 29 Dec 2005 09:41:57 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 29 Dec 2005 09:39:31 -0800 To: lemonade@ietf.org, ("Stephane H. Maes" , Alexey Melnikov , Chris Newman ) From: Randall Gellens Subject: Re: [lemonade] Last Call: 'Lemonade Profile' to Proposed Standard Cc: (iesg@ietf.org) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The draft is in good shape and ready to advance. I do have a few comments, all but one of which are editorial. I want to thank the editors for all their hard work in preparing this draft -- I really appreciate it. (1a) In section 2.4.1, the example includes: S2: {to M} OK (2XX) Submission server returns OK to the MUA: S: 250 2.5.0 Ok. (1b) In Section 2.4.2, the example includes: S2: {to M} OK (2XX) Submission server acknowledges acceptance of the message by sending 250 response to the last BDAT command: S: 250 2.5.0 Ok, message accepted. In both cases, I think the line 'S2: {to M} OK (2XX)' is not needed, is confusing (since 'S2' is not mentioned in the Conventions), and is incorrect since the next line shows the submission server 'S' replying to the messaging client 'M'. (2) I think the first paragraph of 2.4.2 reads poorly, and I suggest changing it from: In the [BURL]/[CHUNKING] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The BURL [BURL] and BDAT [CHINKING] commands are then used to create the messages from multiple parts during submission [RFC2476], existing body parts are referenced using [URLAUTH] format URLs. to: In the [BURL]/[CHUNKING] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. During submission [RFC2476], BURL [BURL] and BDAT [CHINKING] commands are used to create the messages from multiple parts. New body parts are supplied using BDAT commands, while existing body parts are referenced using [URLAUTH] format URLs in BURL commands. (3) Also in 2.4.2, I'd suggest rewording the sentence: It uses BURL to let the SMTP submit server fetch pieces of the message to be sent from the IMAP server (See [BURL] for details of the semantics and steps). as: It uses BURL to instruct the SMTP submit server to fetch from the IMAP server pieces of the message to be sent (See [BURL] for details of the semantics and steps). (4) Section 2.5 states: BURL MUST support URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap" option following the BURL EHLO keyword. Is this in conflict with the example in section 2.4.2 showing the client connecting to a submission server that doesn't announce 'imap' as part of its BURL support? Personally, I like seeing the example, and the requirement is reasonable. But it can be a bit confusing to read the requirement after seeing the example. (5) In section 2.7, I suggest changing 'one or more COPY command' to 'one or more COPY commands' (make 'command' plural). (6) In section 2.8, I think ' $Forwarded IMAP keyword' should be 'The $Forwarded IMAP keyword". (7) In section 3.3, I think: Note a LEMONADE compliant mail submission server must perform message size limit enforcement after performing "expansion" of all BURL parts. Perhaps should be changed to: LEMONADE compliant mail submission servers MUST resolve ("expand") all BURL parts before enforcing a message size limit enforcement. (8) In section 5, "without the need for constant polling for changes" might be better worded as "without needing to poll for changes". (9) In section 6, perhaps delete 'an' from table headings 'Name of an SMTP extension' and 'Name of an IMAP extension or feature'. Maybe change 'Comment' to 'Source' in the second column table heading. (10) In section 7, 'access of email from' might be better as 'usage of email by', to include both submission and retrieval. (11) In section 8.2, I suggest changing 'a replay attack that will disclose' to 'a replay attack that may disclose', since it is not certain that a reply attack will disclose the contents. (12) Also in section 8.2, I think you should make 'connection' plural in 'submission servers SHOULD use TLS protected IMAP connection'. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Procedures! Of course, that's what you'd use with a *sophisticated* machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Dec 29 16:27:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5If-0006MT-HK; Thu, 29 Dec 2005 16:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5Ie-0006MO-0H for lemonade@megatron.ietf.org; Thu, 29 Dec 2005 16:27:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20015 for ; Thu, 29 Dec 2005 16:25:53 -0500 (EST) Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es5Ms-0005Ga-Je for lemonade@ietf.org; Thu, 29 Dec 2005 16:31:32 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Es5IN-0007ih-2D; Thu, 29 Dec 2005 21:26:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D88D3498003; Thu, 29 Dec 2005 21:29:46 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12870-09; Thu, 29 Dec 2005 21:29:42 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id F104D498002; Thu, 29 Dec 2005 21:29:41 +0000 (GMT) Date: Thu, 29 Dec 2005 21:26:41 +0000 Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <24238.1135006975.786474@peirce.dave.cridland.net> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> In-Reply-To: MIME-Version: 1.0 Message-Id: <1832.1135891601.846338@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Dec 26 15:02:31 2005, Arnt Gulbrandsen wrote: > Curtis King writes: >> I agree and to me either sieve or persistent SEARCH is the same >> amount of work. I see persistent SEARCH being useful outside of >> notifications or I maybe missing something. The question I'm >> struggling with which one would be a cleaner design? >=20 > We implemented persistent searches and found it clean and pleasant. > Surprisingly so - suddenly we sat there looking at each other asking > =ABthat's it? we're done?=BB >=20 >=20 Persistent searches are also quite easy client-side, and don't have a=20 huge cost. Persistent SORT and THREAD are not, though, and nor are=20 server-side enumerations. > A draft's sort of ready, all it needs is a references section. >=20 >=20 I'll look forward to it. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 30 05:34:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsHaL-00064F-RD; Fri, 30 Dec 2005 05:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsHaL-00064A-4Z for lemonade@megatron.ietf.org; Fri, 30 Dec 2005 05:34:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29665 for ; Fri, 30 Dec 2005 05:32:58 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsHek-0004Bj-RW for lemonade@ietf.org; Fri, 30 Dec 2005 05:38:44 -0500 Received: from [127.0.0.1] (natchern.atom.ru [194.67.244.30]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 30 Dec 2005 10:33:56 +0000 Message-ID: <43B50CC9.4090200@isode.com> Date: Fri, 30 Dec 2005 13:32:41 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <54E40201497DF142B06B27255953F7971A6925B0@il0015exch007u.ih. lucent.com> <95A94706953659E3C212F982@saturn.watson.ibm.com> <43AA0DB9.4090500@andrew.cmu.edu> In-Reply-To: <43AA0DB9.4090500@andrew.cmu.edu> X-Spam-Score: 1.0 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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="===============1185751386==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1185751386== Content-Type: multipart/alternative; boundary="------------050809060901040709060104" --------------050809060901040709060104 Content-type: text/plain; charset="UTF-8"; format="flowed" Content-Transfer-Encoding: 7bit Ken Murchison wrote: > Barry Leiba wrote: > >> I'm not sure we'll get consensus on an extensive script-management >> interface in IMAP -- it's quite an overload for IMAP. That's why I >> left the "SIEVEFILTER" command unspecified, and just there as something >> to open discussion on the issue. Managesieve can certainly be >> extended, and perhaps this draft should add another section, replacing >> the SIEVEFILTER stuff, that extends managesieve to handle causes and >> multiple active scripts, at least. >> >> Do others have comments there? > Disclaimer: I haven't made my mind yet on whether running Sieve scripts on IMAP events is a proper thing. > I think we need to either extend MANAGESIEVE or use mailbox > annotations (Cyrus currently does the latter for running a script when > a message is delivered to a shared mailbox) Both seems like reasonable approaches. However I have slight bias towards extending ManageSieve to allow for multiple Sieve triggers, as this seems to provides better abstraction layer. Mailstores that implement generic mailbox annotations can still use mailbox annotations to store Sieve scripts. --------------050809060901040709060104 Content-type: text/html; charset="UTF-8" X-Encoded: Changed encoding from 8bit for 7bit transmission Content-Transfer-Encoding: quoted-printable Ken Murchison wrote:
Barry Leiba wrote:
I'm not sure we'll get consensus on an extensive script-management
interface in IMAP -- it's quite an overload for IMAP.=C2=A0 That's why I left the "SIEVEFILTER" command unspecified, and just there as something
to open discussion on the issue.=C2=A0 Managesieve can certainly be
extended, and perhaps this draft should add another section, replacing
the SIEVEFILTER stuff, that extends managesieve to handle causes and
multiple active scripts, at least.

Do others have comments there?
Disclaimer: I haven't made my mind yet on whether running Sieve scripts on IMAP events is a proper thing.
I think we need to either extend MANAGESIEVE or use mailbox annotations (Cyrus currently does the latter for running a script when a message is delivered to a shared mailbox)
Both seems like reasonable approaches. However I have slight bias towards extending ManageSieve to allow for multiple Sieve triggers, as this seems to provides better abstraction layer. Mailstores that implement generic mailbox annotations can still use mailbox annotations to store Sieve scripts.

--------------050809060901040709060104-- --===============1185751386== 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 --===============1185751386==-- From lemonade-bounces@ietf.org Fri Dec 30 05:35:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsHc4-0006dK-Rl; Fri, 30 Dec 2005 05:35:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsHc1-0006Yc-7q for lemonade@megatron.ietf.org; Fri, 30 Dec 2005 05:35:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29853 for ; Fri, 30 Dec 2005 05:34:42 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsHgR-0004Es-U9 for lemonade@ietf.org; Fri, 30 Dec 2005 05:40:28 -0500 Received: from [127.0.0.1] (natchern.atom.ru [194.67.244.30]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 30 Dec 2005 10:35:37 +0000 Message-ID: <43B50D2D.10507@isode.com> Date: Fri, 30 Dec 2005 13:34:21 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger References: In-Reply-To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: lemonade@ietf.org Subject: [lemonade] Re: LEMONADE Interim Agenda and Venue 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="===============1077348996==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1077348996== Content-Type: multipart/alternative; boundary="------------000002070205050804060108" --------------000002070205050804060108 Content-type: text/plain; charset="us-ascii" Eric Burger wrote: >IETF LEMONADE Interim Meeting >============================= > >Logistics >--------- >Date: January 24, 2006, noon - 6pm China Time >Date: January 25, 2006, 8am - noon China Time > >Dinner will be provided the evening of the 24th by our host, >China Mobile Communications Corporation > >Venue: Beijing, CN (Hotel Will Be Announced Shortly) > >Remote Access: > o High-Speed Internet > o Conference Bridge w/ Local Numbers > o SIP Access to Conference Bridge may be possible > >Proposed Agenda >--------------- >Presentation on LEMONADE market drivers (service provider) > >Document status >- last calls, RFC editor, etc. > >OMA liaison > >Phase 2 work items: >- Reconnect > draft-ietf-lemonade-reconnect-xx > > I think the WG should also discuss: 1). Revising IMAP BINARY (or writing a separate draft) to mandate BINARY APPEND. I am not sure if a new draft is needed, or whether this can be just described in Lemonade Profile Phase 2. 2). I was wondering if there is any interest in addressing "CONDSTORE extension can't report messages expunge since the timestamp (modification sequence)" issue in Lemonade Phase 2. The ESEARCH extension which Dave Cridland and I co-writing can be a candidate for this. >- Filter > draft-ietf-lemonade-convert-xx >*draft-ietf-lemonade-sieve-xx > The draft is published, so remove the *. Is there any interest in discussing Manage Sieve Protocol update to support running Sieve on IMAP events? > draft-maes-lemonade-vfolder-xx >- Content Transformation > draft-ietf-lemonade-convert-xx > *draft-ietf-lemonade-channel derivatives for streaming >- S2C notifications > draft-maes-lemonade-notifications-server-to-client-01.txt > *draft-ietf-lemonade-notifications-xx >- Compression > draft-maes-lemonade-lzip-01.txt >- Firewalls > draft-maes-lemonade-http-binding-01.txt > draft-smaes-lemonade-intermediary-challenges-01.txt >* items not yet available as drafts > > --------------000002070205050804060108 Content-type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric Burger wrote: 
IETF LEMONADE Interim Meeting
=============================

Logistics
---------
Date: January 24, 2006, noon - 6pm China Time
Date: January 25, 2006, 8am - noon China Time

Dinner will be provided the evening of the 24th by our host,
China Mobile Communications Corporation

Venue: Beijing, CN (Hotel Will Be Announced Shortly)

Remote Access:
 o  High-Speed Internet
 o  Conference Bridge w/ Local Numbers
 o  SIP Access to Conference Bridge may be possible

Proposed Agenda
---------------
Presentation on LEMONADE market drivers (service provider)

Document status
- last calls, RFC editor, etc.

OMA liaison

Phase 2 work items:
- Reconnect
  draft-ietf-lemonade-reconnect-xx
I think the WG should also discuss:
1). Revising IMAP BINARY (or writing a separate draft) to mandate BINARY APPEND. I am not sure if a new draft is needed, or whether this can be just described in Lemonade Profile Phase 2.
2). I was wondering if there is any interest in addressing "CONDSTORE extension can't report messages expunge since the timestamp (modification sequence)" issue in Lemonade Phase 2. The ESEARCH extension which Dave Cridland and I co-writing can be a candidate for this.
- Filter
  draft-ietf-lemonade-convert-xx
*draft-ietf-lemonade-sieve-xx
The draft is published, so remove the *.

Is there any interest in discussing Manage Sieve Protocol update to support running Sieve on IMAP events?
  draft-maes-lemonade-vfolder-xx
- Content Transformation
  draft-ietf-lemonade-convert-xx
 *draft-ietf-lemonade-channel derivatives for streaming
- S2C notifications
  draft-maes-lemonade-notifications-server-to-client-01.txt
 *draft-ietf-lemonade-notifications-xx
- Compression
  draft-maes-lemonade-lzip-01.txt
- Firewalls
  draft-maes-lemonade-http-binding-01.txt
  draft-smaes-lemonade-intermediary-challenges-01.txt
* items not yet available as drafts


--------------000002070205050804060108-- --===============1077348996== 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 --===============1077348996==-- From lemonade-bounces@ietf.org Fri Dec 30 13:54:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPO5-0001oA-Ls; Fri, 30 Dec 2005 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPO4-0001o5-0s for lemonade@megatron.ietf.org; Fri, 30 Dec 2005 13:54:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26179 for ; Fri, 30 Dec 2005 13:52:47 -0500 (EST) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsPSX-0005H0-Tn for lemonade@ietf.org; Fri, 30 Dec 2005 13:58:39 -0500 Received: from prosecco.oryx.com (prosecco.oryx.com [195.30.37.38]) by kalyani.oryx.com (Postfix) with ESMTP id 2C7F34B103 for ; Fri, 30 Dec 2005 19:53:47 +0100 (CET) Message-Id: <6PUQzOjuf3SXTaK0OKPLrA.md5@prosecco.oryx.com> Date: Fri, 30 Dec 2005 19:51:27 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 References: <24238.1135006975.786474@peirce.dave.cridland.net> <3220.1135176434.535000@JOHN> <43A97D60.5070505@watson.ibm.com> <118526A6593B0003F7943817@ninevah.local> <65914512-DB4C-4D43-A38A-C61ED98C00D8@mumbo.ca> <43ABF65E.2080406@sun.com> <698A7DE5-15D6-4379-BB66-CE8192E6AA0D@mumbo.ca> <1832.1135891601.846338@peirce.dave.cridland.net> In-Reply-To: <1832.1135891601.846338@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > Persistent searches are also quite easy client-side, and don't have a > huge cost. I'd say they're easy if all clients are kept in sync somehow, e.g. by using only a single client or by using only clients that store the search in something like ACAP. That's too limited from my point of view. (There is a difference in server-side cost, btw. It's a little complex and depends on what extensions are used and what clients access the mailboxes in question. With search-res, condstore and either no primitive clients or no big mailboxes, client-side works well. Again, I'm not wild about that. >> A draft's sort of ready, all it needs is a references section. > > I'll look forward to it. Future tense? I blush. Mea culpa. I've left too many people looking forward to things I should do in the past three months and a day. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Dec 30 17:01:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsSJd-0006Gc-By; Fri, 30 Dec 2005 17:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsSJb-0006GN-KU for lemonade@megatron.ietf.org; Fri, 30 Dec 2005 17:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18181 for ; Fri, 30 Dec 2005 17:00:20 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsSO4-0003st-8l for lemonade@ietf.org; Fri, 30 Dec 2005 17:06:14 -0500 Received: from [192.168.0.3] (s142-179-159-132.ab.hsia.telus.net [142.179.159.132]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id jBUM15P0014972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Dec 2005 15:01:06 -0700 (MST) (envelope-from lyndon@orthanc.ca) Message-ID: <43B5AE21.6030205@orthanc.ca> Date: Fri, 30 Dec 2005 15:01:05 -0700 From: Lyndon Nerenberg User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: [lemonade] Re: LEMONADE Interim Agenda and Venue References: <43B50D2D.10507@isode.com> In-Reply-To: <43B50D2D.10507@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, Eric Burger 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > 1). Revising IMAP BINARY (or writing a separate draft) to mandate BINARY > APPEND. I have heard rumblings from a couple of different directions about tweaks to Binary. I would appreciate it if someone could take the time to write up the specific changes being requested and send them to me. I'm going to be pushing an update that fixes up some bugs in the grammar, so we might as well use this opportunity to include the other changes. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade