From lemonade-bounces@ietf.org Sun Dec 02 00:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyhrB-0001n0-Gz; Sun, 02 Dec 2007 00:59:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyhrA-0001iw-Ku for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 00:59:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyhrA-0001il-A3 for lemonade@ietf.org; Sun, 02 Dec 2007 00:59:08 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyhr9-00069b-GC for lemonade@ietf.org; Sun, 02 Dec 2007 00:59:07 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB25x5v2010708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Dec 2007 21:59:06 -0800 Received: from [192.168.1.13] (vpn-10-50-16-74.qualcomm.com [10.50.16.74]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB25wwkq004889; Sat, 1 Dec 2007 21:59:04 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <47385952.9020009@isode.com> References: <473858BA.7030609@isode.com> <47385952.9020009@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sat, 1 Dec 2007 18:24:35 -0800 To: Alexey Melnikov , Lemonade WG From: Randall Gellens Subject: [lemonade] Re: List of open issues with draft-gulbrandsen-imap-enable-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 1.4 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:46 PM +0000 11/12/07, Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> I will try to summarize the list of open issues so far (some of >> them are related): > > And I would state my preferences: I'll state mine, based on subsequent email discussion: > >> 1). In which states the ENABLE command should be allowed: all, >> only after authentication, ... > > All states. All states or authenticated (I'm not sure there is a compelling argument either way). Although, if I understand Ned's point correctly, limiting ENABLE to the authenticated state (and perhaps even further, to the unselected state or some such) reduces the points at which the state can change, which reduces the complexity. Additionally, allowing ENABLE in unauthenticated state means the server has to keep track of the requested extensions and apply them after authentication. >> 2). Handling of ENABLE for unrecognized extensions: send error or ignore > > Ignore. Agree. >> 3). Handling of ENABLE for extensions that should not be enablable >> (e.g. IDLE): send error or ignore > > Ignore. Agree. >> 4). How the client can learn if a particular extension was enabled >> or not? Does it need to know? > > Clients should only rely on CAPABILITY responses/response codes. Agree. >> 5). Does ENABLE affect CAPABILITY response/response code? > > It shouldn't affect the CAPABILITY command issued in the same > state, but it might change after authentication. Makes sense. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Auntie Em, Hate you; Hate Kansas; Taking the dog. --Dorothy. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 00:59:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyhrH-00028S-N0; Sun, 02 Dec 2007 00:59:15 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyhrG-00027P-DM for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 00:59:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyhrG-00025S-1l for lemonade@ietf.org; Sun, 02 Dec 2007 00:59:14 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyhrF-00088u-E7 for lemonade@ietf.org; Sun, 02 Dec 2007 00:59:14 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB25xAvl010712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Dec 2007 21:59:10 -0800 Received: from [192.168.1.13] (vpn-10-50-16-74.qualcomm.com [10.50.16.74]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB25wwks004889; Sat, 1 Dec 2007 21:59:08 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sat, 1 Dec 2007 19:09:46 -0800 To: Mark Crispin , Peter Coates From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lemonade@ietf.org, 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:33 PM -0800 11/26/07, Mark Crispin wrote: > Saying "it will reduce service calls" is like saying "it's for the > children". Such statements are nothing more than strawmen to > stifle debate ("you want there to be more service calls, you evil > person you"). I think it is possible to disagree as to if a change will reduce service calls without saying that all such arguments are fallacies. > The only situation in which error messages to the end user are > useful are when the end user can do something about the condition. Or in the case of a temporary failure, if the error message clearly says something along the lines of "Oops! This can't be done just at the moment. Please try again later ." Separately from the question of end user behavior is the issue of client behavior. If a client should behave differently, such as retrying the exact same command later, or giving up, then different error responses are useful. If neither the client nor the end user is likely to behave differently, then there isn't a lot of benefit to different error responses other than debugging. >> and I see the demand for two tier >> storage, and the like increasing rather than decreasing. > > Who? Where? It does seem that IT departments are fond of email management systems that give IT extreme control over email, such as the ability to move messages to secondary storage based on their own criteria, as well as permanently delete or prevent the deletion of messages. Needless to say, a lot of this sort of functionality violates the way IMAP works, and some of it could be better accomplished within IMAP (such as using different mailboxes). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- 1. People to whom you are attracted invariably think you remind them of someone else. 2. The love letter you finally got the courage to send will be delayed in the mail long enough for you to make a fool of yourself in person. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 01:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyi0p-00074f-Ez; Sun, 02 Dec 2007 01:09:07 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyi0n-00072W-Px for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 01:09:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyi0m-00072H-Ja for lemonade@ietf.org; Sun, 02 Dec 2007 01:09:04 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyi0l-0000Pr-1m for lemonade@ietf.org; Sun, 02 Dec 2007 01:09:04 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2691VA009315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Dec 2007 22:09:02 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2690TO025165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Dec 2007 22:09:01 -0800 Date: Sat, 1 Dec 2007 22:09:00 -0800 (PST) From: Mark Crispin To: Randall Gellens Subject: RE: [lemonade] extended error reporting In-Reply-To: Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> User-Agent: Alpine 0.99999 (OSX 839 2007-12-01) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.1.215426 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org, Peter Coates , 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat, 1 Dec 2007, Randall Gellens wrote: >> The only situation in which error messages to the end user are useful are >> when the end user can do something about the condition. > Or in the case of a temporary failure, if the error message clearly says > something along the lines of "Oops! This can't be done just at the moment. > Please try again later ." I hope that nobody seriously suggests that IMAP start issuing such errors for FETCH or even URLFETCH. > If neither the client nor the end user is likely to behave differently, then > there isn't a lot of benefit to different error responses other than > debugging. My point exactly. We should not add new error responses unless they lead to different behavior from a client or end user. > It does seem that IT departments are fond of email management systems that > give IT extreme control over email, such as the ability to move messages to > secondary storage based on their own criteria, as well as permanently delete > or prevent the deletion of messages. Needless to say, a lot of this sort of > functionality violates the way IMAP works, and some of it could be better > accomplished within IMAP (such as using different mailboxes). Which is why Exchange and outsource webmail is rapidly replacing IMAP everywhere. One of the reasons why I am trying to calm down this mad rush to add unbounded new features to IMAP is that much of this effort seems to be a waste that will only hasten IMAP's demise. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 02:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyiz4-0000SX-8E; Sun, 02 Dec 2007 02:11:22 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyiz2-0000SJ-QY for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 02:11:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyiz2-0000SA-Cb for lemonade@ietf.org; Sun, 02 Dec 2007 02:11:20 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyiz0-0004vD-QO for lemonade@ietf.org; Sun, 02 Dec 2007 02:11:20 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB27BFmL022242 for ; Sun, 2 Dec 2007 07:11:15 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSE00F01UH2E300@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Sun, 02 Dec 2007 00:11:15 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSE00AJYUMP9F20@mail-amer.sun.com>; Sun, 02 Dec 2007 00:11:15 -0700 (MST) Date: Sat, 01 Dec 2007 23:10:37 -0800 From: Peter Coates Subject: RE: [lemonade] extended error reporting In-reply-to: To: "'Mark Crispin'" , "'Randall Gellens'" Message-id: <00d601c834b2$71dd4a10$5597de30$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: Acg0qeswWd4mUtlCSja2ATXeWyg4CgACDrIw References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: lemonade@ietf.org, 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There is a good error reporting mechanism in CONVERT. And there it is called for as all sorts of things can be wrong. URLFETCH has no error reporting mechanism. URLs can request conversion, so the same sorts of errors than can occur in CONVERT can occur in URLFETCH. That seems just plain wrong to me. Peter -----Original Message----- From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of Mark Crispin Sent: December 1, 2007 22:09 To: Randall Gellens Cc: Peter Coates; lemonade@ietf.org; 'Ned Freed' Subject: RE: [lemonade] extended error reporting On Sat, 1 Dec 2007, Randall Gellens wrote: >> The only situation in which error messages to the end user are useful are >> when the end user can do something about the condition. > Or in the case of a temporary failure, if the error message clearly says > something along the lines of "Oops! This can't be done just at the moment. > Please try again later ." I hope that nobody seriously suggests that IMAP start issuing such errors for FETCH or even URLFETCH. > If neither the client nor the end user is likely to behave differently, then > there isn't a lot of benefit to different error responses other than > debugging. My point exactly. We should not add new error responses unless they lead to different behavior from a client or end user. > It does seem that IT departments are fond of email management systems that > give IT extreme control over email, such as the ability to move messages to > secondary storage based on their own criteria, as well as permanently delete > or prevent the deletion of messages. Needless to say, a lot of this sort of > functionality violates the way IMAP works, and some of it could be better > accomplished within IMAP (such as using different mailboxes). Which is why Exchange and outsource webmail is rapidly replacing IMAP everywhere. One of the reasons why I am trying to calm down this mad rush to add unbounded new features to IMAP is that much of this effort seems to be a waste that will only hasten IMAP's demise. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 10:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyqo7-0005mZ-KM; Sun, 02 Dec 2007 10:32:35 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyqo4-0005jA-JJ for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 10:32:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyqo3-0005iD-1B for lemonade@ietf.org; Sun, 02 Dec 2007 10:32:31 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyqo2-00077S-AR for lemonade@ietf.org; Sun, 02 Dec 2007 10:32:30 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOENGR3HO000JBPG@mauve.mrochek.com> for lemonade@ietf.org; Sun, 2 Dec 2007 07:32:24 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOE330H7GG00GULE@mauve.mrochek.com>; Sun, 02 Dec 2007 07:32:17 -0800 (PST) Message-id: <01MOENGLEQAC00GULE@mauve.mrochek.com> Date: Sun, 02 Dec 2007 07:13:41 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] extended error reporting In-reply-to: "Your message dated Sat, 01 Dec 2007 22:09:00 -0800 (PST)" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> To: Mark Crispin DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196609544; h=Date: From:Subject:MIME-version:Content-type; b=CNga/Yv+zWJwsh59JaNWusWAl e8WISEdShsWvKs1WTC4bsQdwFqUxcqPbYZoK/X8UOPsR4k1sXqUrz1RYuwf9w== X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates , 'Ned Freed' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Sat, 1 Dec 2007, Randall Gellens wrote: > >> The only situation in which error messages to the end user are useful are > >> when the end user can do something about the condition. > > Or in the case of a temporary failure, if the error message clearly says > > something along the lines of "Oops! This can't be done just at the moment. > > Please try again later ." > I hope that nobody seriously suggests that IMAP start issuing such errors > for FETCH or even URLFETCH. > > If neither the client nor the end user is likely to behave differently, then > > there isn't a lot of benefit to different error responses other than > > debugging. > My point exactly. We should not add new error responses unless they lead > to different behavior from a client or end user. But if that's the case then we should consider adding them if a case can be made (and IMO it has been) that the added information will change behavior. > > It does seem that IT departments are fond of email management systems that > > give IT extreme control over email, such as the ability to move messages to > > secondary storage based on their own criteria, as well as permanently delete > > or prevent the deletion of messages. Needless to say, a lot of this sort of > > functionality violates the way IMAP works, and some of it could be better > > accomplished within IMAP (such as using different mailboxes). > Which is why Exchange and outsource webmail is rapidly replacing IMAP > everywhere. One of the reasons why I am trying to calm down this mad rush > to add unbounded new features to IMAP is that much of this effort seems to > be a waste that will only hasten IMAP's demise. OK, so let me see if I have this right. Because of various missing functionality in IMAP people are moving in droves to other solutions with better functionality. And the way to solve this is by keeping IMAP "pure" and not adding the features users are demanding to it? More generally, conspicuously missing from what most people seem to want these days is a desire for things to be simple, especially when that means less capable. Those same droves are also delightedly writing and deploying stuff based on AJAX, JSON, increasingly elaborate web services, and using toolkits designed around object models so complex that their own designers cannot explain them. This stuff is all vastly more complex than anything proposed for IMAP. This is not to say simpler isn't better. It is. (That's why I've been advocating using a capabilities response to indicaate what's enabled - it's the simpler way to do it.) But there's a point past which simplicity is no longer a virtue. We need to follow Einstein's advice and keep things as simple as possible, but no simpler. If we can offer a ways for people to do the stuff they want to do but still keep the protocols as clean and simple as possible we have a valid value proposition here. (OK, OK, so this ignores marketing. But that's outside our area of competence.) Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 12:19:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IysSa-0002XD-3v; Sun, 02 Dec 2007 12:18:28 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IysSZ-0002X5-Fl for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 12:18:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IysSZ-0002VR-4Q for lemonade@ietf.org; Sun, 02 Dec 2007 12:18:27 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IysSY-00030Z-LY for lemonade@ietf.org; Sun, 02 Dec 2007 12:18:26 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2HIPmF012700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Dec 2007 09:18:25 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2HIHnr009214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Dec 2007 09:18:25 -0800 Date: Sun, 2 Dec 2007 09:18:16 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] extended error reporting In-Reply-To: <01MOENGLEQAC00GULE@mauve.mrochek.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> User-Agent: Alpine 0.99999 (OSX 839 2007-12-01) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.2.90248 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_700_799 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 2 Dec 2007, Ned Freed wrote: >> On Sat, 1 Dec 2007, Randall Gellens wrote: > OK, so let me see if I have this right. Because of various missing > functionality in IMAP people are moving in droves to other solutions with > better functionality. And the way to solve this is by keeping IMAP "pure" and > not adding the features users are demanding to it? No. People are moving away to other solutions because IMAP is too damn complicated. The big vendors refuse to implement even all of the base specification, much less all of these bizarre extensions. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 13:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytwN-0007UD-BQ; Sun, 02 Dec 2007 13:53:19 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IytwM-0007Sm-0R for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 13:53:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytwL-0007Rl-Ll for lemonade@ietf.org; Sun, 02 Dec 2007 13:53:17 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IytwL-0006Xt-2H for lemonade@ietf.org; Sun, 02 Dec 2007 13:53:17 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOEUHNGBZ400H1YM@mauve.mrochek.com> for lemonade@ietf.org; Sun, 2 Dec 2007 10:53:10 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOE330H7GG00GULE@mauve.mrochek.com>; Sun, 02 Dec 2007 10:53:06 -0800 (PST) Message-id: <01MOEUHLCOSG00GULE@mauve.mrochek.com> Date: Sun, 02 Dec 2007 10:37:08 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] extended error reporting In-reply-to: "Your message dated Sun, 02 Dec 2007 09:18:16 -0800 (PST)" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> To: Mark Crispin DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196621589; h=Date: From:Subject:MIME-version:Content-type; b=JIsh8cGENYaQYoroa/ERFMRIO NUIgEhmjU+9ggxaq+vNXvJ30nC27Pfo3gX2bbpKDRZAz/PeSVk0Otd5Fv4XPA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Randall Gellens , lemonade@ietf.org, Peter Coates , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Sun, 2 Dec 2007, Ned Freed wrote: > >> On Sat, 1 Dec 2007, Randall Gellens wrote: > > OK, so let me see if I have this right. Because of various missing > > functionality in IMAP people are moving in droves to other solutions with > > better functionality. And the way to solve this is by keeping IMAP "pure" and > > not adding the features users are demanding to it? > No. People are moving away to other solutions because IMAP is too damn > complicated. I'm sorry, but I think this is quite simply wrong. As I pointed out, people have zero problem embracing vastly more complex solutions on both the client and the server, and indeed the things pepople are switching to from IMAP are almost without exception far more complex than IMAP. The big vendors refuse to implement even all of the base > specification, much less all of these bizarre extensions. But the reason for that is that they don't see any reason to implement those things. And this is a real problem: How do you get a vendor who believes certain parts of IMAP aren't useful to them to do the right thing and implement them anyway? I think the only solution to this problem that's available to us is to make the entire IMAP story more attractive. And that means adding additional capabilities people want. By making the overall IMAP story more appealing we broaden the user base. And if that broader user base runs into issues with some vendors not implementing stuff they will exert pressure on those vendors to clean up their act. That's pressure we cannot possibly apply ourselves. But regardless, it definitely isn't helping that IMAP is seen as not offering sufficient value in its present form. You cannot solve the problem of getting complete implementations when there's nothing compelling to keep people using IMAP. In fact I'll go so far as to say that if anything is going to kill IMAP it is this continued intransigence towwards enhancements. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 14:02:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyu5a-0001ol-5q; Sun, 02 Dec 2007 14:02:50 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyu5Y-0001gX-LK for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:02:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyu5Y-0001eM-9u for lemonade@ietf.org; Sun, 02 Dec 2007 14:02:48 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyu5W-0007wf-H8 for lemonade@ietf.org; Sun, 02 Dec 2007 14:02:48 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB2J2cvi025463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 11:02:39 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-0-62.qualcomm.com [10.50.0.62]) by sabrina.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB2J2bmx027878; Sun, 2 Dec 2007 11:02:37 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <13695.1196158990.303583@peirce.dave.cridland.net> References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <12639.1196123345.809039@peirce.dave.cridland.net> <13695.1196158990.303583@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 11:00:48 -0800 To: Dave Cridland , Mark Crispin From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:23 AM +0000 11/27/07, Dave Cridland wrote: >>> Taking this specific example, mobile devices aren't always aware >>> of the correct time, and a client trying to generate, then use >>> (via BURL) an IMAP URL which has a tight expiration is perfectly >>> capable of finding a largely opaque error coming back from the >>> submission server, purely because the clock is wrong. (And >>> sometimes, it's wrong because the GSM network is helpfully >>> broadcasting the wrong time). >> >> That scenario suggests that the correct protocol fix is to have a >> relative expiration date/time for the client doing the GENURLAUTH, >> and have the returned URLAUTH replace that relative expiration >> date/time with an absolute value. For example, > > Well, I'm not sure that helps, and more importantly I suspect that > this would be a more radical change than Peter's proposal anyway. > BURL/URLAUTH are deployed technologies [ie, not just Polymer], and > the simplest way of handling this deficiency without breaking > existing implementations would be to have the BURL command produce > more useful diagnostics. Just playing Devil's Advocate, but if the problem is that the client is on a device that has the wrong time, and hence the client calculated an expiration time that has already passed or is otherwise not far enough in the future to be useful, a detailed error message would only help the developer, not the end user (unless the time-to-expiration is user-settable, which would probably not be something most users would understand). I suppose you could code the client so that if it gets the detailed error report from a BURL extended response code, it could react by automatically increasing the expiration time. But that seems difficult. A relative expiration time in the GENURLAUTH does seem simpler in this example. > Besides which, there are other cases, including any case which > involves server-side manipulation of a body part during the > URLFETCH. My proposal of BINARY-mode is one such (consider bogus > base64), and any similar proposal involving CONVERT-in-URLFETCH. Yes, this makes sense. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Corollaries: 1. Nobody whom you ask for help will see it. 2. The first person who stops by, whose advice you really don't want to hear, will see it immediately. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 14:16:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuIr-0006wl-J8; Sun, 02 Dec 2007 14:16:33 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyuIq-0006u5-Ra for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuIq-0006sm-57 for lemonade@ietf.org; Sun, 02 Dec 2007 14:16:32 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyuIo-0001HF-FY for lemonade@ietf.org; Sun, 02 Dec 2007 14:16:32 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2JGTEh026296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Dec 2007 11:16:29 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2JGSo4016422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Dec 2007 11:16:28 -0800 Date: Sun, 2 Dec 2007 11:16:27 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] extended error reporting In-Reply-To: <01MOEUHLCOSG00GULE@mauve.mrochek.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> User-Agent: Alpine 0.99999 (OSX 839 2007-12-01) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.2.110232 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 2 Dec 2007, Ned Freed wrote: > I'm sorry, but I think this is quite simply wrong. As I pointed out, people > have zero problem embracing vastly more complex solutions on both the client > and the server, and indeed the things pepople are switching to from IMAP are > almost without exception far more complex than IMAP. Why does Exchange not implement any of the optional facilities of the base specification, much less any extensions? Why does Gmail not implement all of the mandatory facilties of the base specification, much less any extensions? If you want to fix IMAP to add the functionality that people really want, you need to have things as contact management, task management, and calendaring. The IETF has failed miserably on all points. Nobody cares about email-only applications any more. Email is a small part of the overall picture, yet you guys are focusing on how to create the Email Protocol From Hell. Not only that, but email itself is a dying means of communication, and you can't blame IMAP for that. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 14:45:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyukw-0002yG-Ri; Sun, 02 Dec 2007 14:45:34 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyukv-0002y8-OY for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:45:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyukv-0002y0-Dp for lemonade@ietf.org; Sun, 02 Dec 2007 14:45:33 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyuku-0005AA-OU for lemonade@ietf.org; Sun, 02 Dec 2007 14:45:33 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOEWBH34PC00IFXC@mauve.mrochek.com> for lemonade@ietf.org; Sun, 2 Dec 2007 11:45:28 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOE330H7GG00GULE@mauve.mrochek.com>; Sun, 02 Dec 2007 11:45:20 -0800 (PST) Message-id: <01MOEWBCGHJG00GULE@mauve.mrochek.com> Date: Sun, 02 Dec 2007 11:23:40 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] extended error reporting In-reply-to: "Your message dated Sun, 02 Dec 2007 11:16:27 -0800 (PST)" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> To: Mark Crispin DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196624727; h=Date: From:Subject:MIME-version:Content-type; b=kUR8ztx7hvZg/K1Z+pF9WBdx4 yK51tOdP9jdpx1hI9KTbi7LW4wkxYqApRQ8Qf2lkLGGpVs237IyArI0Q/qGOg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Sun, 2 Dec 2007, Ned Freed wrote: > > I'm sorry, but I think this is quite simply wrong. As I pointed out, people > > have zero problem embracing vastly more complex solutions on both the client > > and the server, and indeed the things pepople are switching to from IMAP are > > almost without exception far more complex than IMAP. > Why does Exchange not implement any of the optional facilities of the base > specification, much less any extensions? Now you're changing the subject, which was whether or not protocol simplicity is seen as a virtue, not whether or not some alternative solution chooses to implement some part of the IMAP base. So let's consider Outlook/Exchange. Have you looked at the protocol they use to talk to each other? IMAP is simplicity personified by comparison. > Why does Gmail not implement all of the mandatory facilties of the base > specification, much less any extensions? Same response: Have you looked at the complexity of the web pages and such gmail uses? Now, as for the question of why they don't implement certain parts of the base specification, I already answered that in my previous message. > If you want to fix IMAP to add the functionality that people really want, > you need to have things as contact management, task management, and > calendaring. The IETF has failed miserably on all points. I agree 100% that people want this functionality and providing a standards-based way to get it has to be part of our overall value proposition. But people do not care in the slightest if it is provided by IMAP or by some other protocol. They just want it to work. I also agree that the IETF's history in the area is nothing short of dismal. We defined both an addressbook and calendar format but then let both of them lie fallow for much too long (vCard especially) and did nothing useful in the area of defining protocol level access to them. (Yes, I'm well aware of the ICAP work, but I stand by my assessment.) But this is finally starting to change. Soon we'll have caldav and carddav and ical is being cleaned up. I think vCard is going to be a tougher nut to crack, but I think it can be done. The real question is whether it can happen in time. But one things for sure: Sitting around wringing our hands and moaning about unnecessary complexity isn't helping. > Nobody cares about email-only applications any more. Email is a small > part of the overall picture, yet you guys are focusing on how to create > the Email Protocol From Hell. No, we're trying to add the capabiites to email that it needs in order to survive as a useful component of a much larger set of colaborative tools. The fact that there are lots of problems that cannot be solved by email is not a reason to ignore the subset of problems that can be solved through email. > Not only that, but email itself is a dying > means of communication, and you can't blame IMAP for that. And therefore we should leave it along and let it die in peace? I'm sorry, but this is nothing short of absurd. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 15:18:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvGa-0005hk-Lq; Sun, 02 Dec 2007 15:18:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyvGZ-0005hY-La for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvGZ-0005hM-Bp for lemonade@ietf.org; Sun, 02 Dec 2007 15:18:15 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyvGY-0000qK-Jl for lemonade@ietf.org; Sun, 02 Dec 2007 15:18:15 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2KIDBq010451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Dec 2007 12:18:13 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2KICG3020107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Dec 2007 12:18:13 -0800 Date: Sun, 2 Dec 2007 12:18:12 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] extended error reporting In-Reply-To: <01MOEWBCGHJG00GULE@mauve.mrochek.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> User-Agent: Alpine 0.99999 (OSX 839 2007-12-01) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.2.120340 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 2 Dec 2007, Ned Freed wrote: > The real question is whether it can happen in time. I don't think that it will. > But one things for sure: > Sitting around wringing our hands and moaning about unnecessary complexity > isn't helping. Nor does it help to add complexity that is not widely implemented. I have had vendors (note the plural) tell me that they are NOT going to do the trio, and that their mobile device strategy does not involve Lemonade (or much of IETF). > No, we're trying to add the capabiites to email that it needs in order to > survive as a useful component of a much larger set of colaborative tools. I don't see how the current set of extensions, much less all the stuff that is being proposed for addition now, in any way assists in that goal. Extensions by their very nature are flawed. A client implementor can not rely upon a server offering it; nor can a client necessarily assume that the extension will be correctly implemented by the server even if it is offered. Case in point: METADATA, which was ANNOTATEMORE, which was the less wide-eyed way of doing ANNOTATE. I can't imagine building a new messaging product that uses anything but the most basic aspects of IMAP. In fact, a POP3 that had the POP2 FOLD command would do equally as well. There's just too much deployed software that doesn't even do the base specification right. Yes, it was a cool idea to have the server do header/MIME parsing; I use that capability all the time and love it. But it has been so badly misimplemented (especially in MIME parsing) that no client can reasonably rely upon it. And now you claim that servers will do complex conversions correctly? I am deeply skeptical. I have good reason. >> Not only that, but email itself is a dying >> means of communication, and you can't blame IMAP for that. > And therefore we should leave it along and let it die in peace? I'm sorry, > but this is nothing short of absurd. Blaming me, one person, for "killing IMAP by obstructing progress" is what is absurd. I can't obstruct anything. Like it or not, few people under 30 use email as a daily tool, especially the under-25s. I don't see how any of this addresses that problem. You're adding complexity in an attempt to keep email from dying. I don't see any clear or coherant plan to save email, rather a frantic effort to try every possible notion in the hope that one of them works. Letting it die in peace be the best thing. We should instead think about what is replacing email and what we can contribute to that technology based upon the lessons that we learned from 35 years of email and news. Or, rather, we should think about what will replace email; I think that the technology that will put the final nail in email's coffin hasn't shown itself yet. But it is coming. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 15:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvMS-0004E8-Pl; Sun, 02 Dec 2007 15:24:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyvMS-0004Dx-7J for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvMR-0004Dp-U1 for lemonade@ietf.org; Sun, 02 Dec 2007 15:24:19 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyvMQ-0001d7-Eu for lemonade@ietf.org; Sun, 02 Dec 2007 15:24:19 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2KOH8V004303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Dec 2007 12:24:17 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lB2KOGPn020284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Dec 2007 12:24:17 -0800 Date: Sun, 2 Dec 2007 12:24:16 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] extended error reporting In-Reply-To: <01MOEWBCGHJG00GULE@mauve.mrochek.com> Message-ID: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> User-Agent: Alpine 0.99999 (OSX 839 2007-12-01) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.2.120807 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Randall Gellens , lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 2 Dec 2007, Ned Freed wrote: > So let's consider Outlook/Exchange. Have you looked at the protocol they > use to talk to each other? IMAP is simplicity personified by comparison. It's also a single-vendor protocol, and that vendor has absolute dictatorial power over it. The protocol is thus architected towards a single, unified vision and purpose. Such protocols can have considerable complexity yet retain their strength. IETF protocols lack the luxury of a dictator who says "no" and whose word is unquestioned and final. IETF protocols are a compromise between many conflicting factions. The compromise frequently results in a bunch of cruft added to satisfy a small constituency and/or something that nobody really likes (IMAP hierarchy comes to mind). Not that there aren't strengths to IETF protocols. The strengths come in when the compromise process leads to cutting away cruft, especially cruft that is hard for some to implement. IETF does a great job when it strives towards simplicity in all things, and it does a wretched job when it allows complexity to take over. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 16:32:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywPy-0006rV-Hl; Sun, 02 Dec 2007 16:32:02 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IywPx-0006r8-AM for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:32:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywPx-0006qy-0X for lemonade@ietf.org; Sun, 02 Dec 2007 16:32:01 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IywPv-0001rd-SV for lemonade@ietf.org; Sun, 02 Dec 2007 16:32:00 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOF01GG1E800IMOA@mauve.mrochek.com> for lemonade@ietf.org; Sun, 2 Dec 2007 13:31:54 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOEXJQ0HIO00BDC1@mauve.mrochek.com>; Sun, 02 Dec 2007 13:31:50 -0800 (PST) Message-id: <01MOF01DL8RS00BDC1@mauve.mrochek.com> Date: Sun, 02 Dec 2007 12:22:56 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] extended error reporting In-reply-to: "Your message dated Sun, 02 Dec 2007 12:18:12 -0800 (PST)" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> To: Mark Crispin DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196631114; h=Date: From:Subject:MIME-version:Content-type; b=xNQGLQ4NWMaVNrfFFbhafRp3H 7OYnfU1HURQOT5HvNoQwj1eOTPXH03zKyqjUbkalWnP7bLWdFTEyUvhKZUX4Q== X-Spam-Score: -0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Sun, 2 Dec 2007, Ned Freed wrote: > > The real question is whether it can happen in time. > I don't think that it will. > > But one things for sure: > > Sitting around wringing our hands and moaning about unnecessary complexity > > isn't helping. > Nor does it help to add complexity that is not widely implemented. > I have had vendors (note the plural) tell me that they are NOT going to do > the trio, and that their mobile device strategy does not involve Lemonade > (or much of IETF). And I have had vendors tell me the exact opposite. Indeed, the problem I hear over and over from the handset vendor types is that to the extent they are unhappy with the IETF, it is because we're much too slow and do much too little. > > No, we're trying to add the capabiites to email that it needs in order to > > survive as a useful component of a much larger set of colaborative tools. > I don't see how the current set of extensions, much less all the stuff > that is being proposed for addition now, in any way assists in that goal. Then with all due repect, you need to make the argument on that basis and do it case by case. What I'm objecting to is your assertion that simplicity is something people value over other things. There are simply too many counterexmaples to this for it to be in any way credible. > Extensions by their very nature are flawed. A client implementor can not > rely upon a server offering it; nor can a client necessarily assume that > the extension will be correctly implemented by the server even if it is > offered. This is of course true for the Internet as a whole. But this misses a key point: We're not talking about the Internet as a whole here. Rather, we're talking about trying to solve a set of problems for a specific type of client with specific limitations. Such clients usually operate in an environment that's quite different than open Internet. In particular, it is often quite reasonable in such environments to specify a minimum set of extensions. This is sort of the point of having a LEMONADE profile, as a matter of fact. > Case in point: METADATA, which was ANNOTATEMORE, which was the less > wide-eyed way of doing ANNOTATE. > I can't imagine building a new messaging product that uses anything but > the most basic aspects of IMAP. In fact, a POP3 that had the POP2 FOLD > command would do equally as well. There's just too much deployed software > that doesn't even do the base specification right. Well, perhaps you cannot imagine such a thing, but I can and more importantly so can Sun. And Sun is acting on this by designing an entirely new product that depends on many of the more advanced features of various protocols and their extensions, including but not limited to IMAP. I will also add that I'm am only tangentially involved with the project I'm referring to and in particular I had basically no involvement in starting it. This is all the work of people I doubt you've ever heard of, many of whom only know the IETF as being "the place where RFCs come from". So this isn't a case of drinking IETF koolaid, assuming we have any. Rather, it's a case of people wanting to solve a problem and find the current work the IETF is doing to be useful to that end. > Yes, it was a cool idea to have the server do header/MIME parsing; I use > that capability all the time and love it. But it has been so badly > misimplemented (especially in MIME parsing) that no client can reasonably > rely upon it. > And now you claim that servers will do complex conversions correctly? I > am deeply skeptical. I have good reason. I don't recall making any such claim, but never mind that for now. Conversions are kind of a special case in that there is often no "correct" way to do a conversion. (X.400 even formalized this by defining conversion-with-loss.) So the question for many conversions, especially the complex ones, is whether what's producded is "good enough". In any case, I've actually been pleasantly surprised at how well complex conversions work overall. And since I operate in what is effectively a Microsoft-software-free environment and yet have to deal with the output of the Office suite on a daily basis, this is not due to lack of use of such tools. In other words, I'm actually cautiously optimistic about the ability to do complex conversions properly. > >> Not only that, but email itself is a dying > >> means of communication, and you can't blame IMAP for that. > > And therefore we should leave it along and let it die in peace? I'm sorry, > > but this is nothing short of absurd. > Blaming me, one person, for "killing IMAP by obstructing progress" is what > is absurd. I can't obstruct anything. Once again you're putting words in my mouth. But I see no point in pursuing this so I'll let it pass. > Like it or not, few people under 30 use email as a daily tool, especially > the under-25s. I don't see how any of this addresses that problem. > You're adding complexity in an attempt to keep email from dying. I don't > see any clear or coherant plan to save email, rather a frantic effort to > try every possible notion in the hope that one of them works. No. Again, what we're doing is trying to solve a specific set of problems a specific sort of client has. I am on record as opposing expansion of this groups work to include activities that fall outside this limited scope. Will this solve the "email is dying" problem? Of course not, but I can see making email work really well on mobile devices as a part of such a solution. > Letting it die in peace be the best thing. We should instead think about > what is replacing email and what we can contribute to that technology > based upon the lessons that we learned from 35 years of email and news. > Or, rather, we should think about what will replace email; I think that > the technology that will put the final nail in email's coffin hasn't shown > itself yet. But it is coming. Of that I have no doubt. Nothing is permanent. But I fail to see how any of this doom and gloom is relevant to the matters at hand. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 17:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBl-000164-R9; Sun, 02 Dec 2007 17:21:25 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyxBk-000112-DK for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:21:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBk-00010q-2G for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:24 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxBj-0000DD-3r for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:23 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB2MLKtq004605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 14:21:20 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-80.qualcomm.com [10.50.16.80]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB2MLHPk027860; Sun, 2 Dec 2007 14:21:18 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 14:16:17 -0800 To: Mark Crispin , Ned Freed From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:18 PM -0800 12/2/07, Mark Crispin wrote: > Nor does it help to add complexity that is not widely implemented. I agree with this -- cool features that aren't widely implemented aren't much of a help, because a client can't count on them (and of course servers have little incentive to implement something that clients don't use). > I have had vendors (note the plural) tell me that they are NOT > going to do the trio, and that their mobile device strategy does > not involve Lemonade (or much of IETF). This can't be much of a surprise to anyone -- given that multiple vendors have multiple "mobile email" solutions now, many of which use non-IETF protocols (except for perhaps HTTP), we can't have expected that they'd all drop their current offerings and switch to IMAP. But for those that will use IMAP, we need to have the functionality they need. > Extensions by their very nature are flawed. A client implementor > can not rely upon a server offering it; nor can a client > necessarily assume that the extension will be correctly implemented > by the server even if it is offered. True, and this is especially bad with IMAP. Which is one reason for lemonade: to have a collection of functionality, extensions, and server behavior under one name. A mobile client might reasonably insist on a lemonade server, to avoid needing to implement multiple code paths for every variant, or offer different UI when some extensions aren't available. > Yes, it was a cool idea to have the server do header/MIME parsing; > I use that capability all the time and love it. But it has been so > badly misimplemented (especially in MIME parsing) that no client > can reasonably rely upon it. > > And now you claim that servers will do complex conversions > correctly? I am deeply skeptical. I have good reason. A number of years ago, IMAP interoperability was exceedingly poor. The IMC IMAP bake-offs really helped a lot. Some extensions that announce server behavior have also helped. Such things can be done again. > You're adding complexity in an attempt to keep email from dying. I > don't see any clear or coherant plan to save email, rather a > frantic effort to try every possible notion in the hope that one of > them works. I don't see extended error reporting specifically to help with "the trio" and related lemonade stuff, which is really focused on mobile email, as a "frantic effort to try every possible notion." I just don't see much franticness, and so far things have been focused on mobile email. > Or, rather, we should think about what will replace email; I think > that the technology that will put the final nail in email's coffin > hasn't shown itself yet. But it is coming. This is entirely separate from extensions to email. When email is finally replaced, it won't be an overnight thing. Something new starts getting used in its place, and over time email gets used less and less, perhaps it becomes a protocol for automated process, since they don't care. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The highlight of the annual Computer Bowl occurred when Bill Gates, who was a judge, posed the following question to the contestants: "What contest, held via Usenet, is dedicated to examples of weird, obscure, bizarre, and really bad programming?" After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple) hit his buzzer and answered "Windows." --Recounted by Adam C. Engst _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 17:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBm-00016t-W1; Sun, 02 Dec 2007 17:21:26 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyxBl-00016D-V1 for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:21:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBl-00015i-Iv for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:25 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxBl-0000DY-63 for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:25 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB2MLMaI004609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 14:21:23 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-80.qualcomm.com [10.50.16.80]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB2MLHPm027860; Sun, 2 Dec 2007 14:21:21 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 14:19:43 -0800 To: Mark Crispin , Ned Freed From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:24 PM -0800 12/2/07, Mark Crispin wrote: > IETF does a great job when it strives towards simplicity in all > things, and it does a wretched job when it allows complexity to > take over. Yes, indeed. It is often hard to determine what is really needed and what is cool-sounding cruft. Hence the storied reliance on "running code." It is often that it only becomes apparent during implementation. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- All probabilities are 50%. Either a thing will happen or it won't. This is especially true when dealing with someone you're attracted to. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 17:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBl-000164-R9; Sun, 02 Dec 2007 17:21:25 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyxBk-000112-DK for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:21:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBk-00010q-2G for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:24 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxBj-0000DD-3r for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:23 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB2MLKtq004605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 14:21:20 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-80.qualcomm.com [10.50.16.80]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB2MLHPk027860; Sun, 2 Dec 2007 14:21:18 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 14:16:17 -0800 To: Mark Crispin , Ned Freed From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:18 PM -0800 12/2/07, Mark Crispin wrote: > Nor does it help to add complexity that is not widely implemented. I agree with this -- cool features that aren't widely implemented aren't much of a help, because a client can't count on them (and of course servers have little incentive to implement something that clients don't use). > I have had vendors (note the plural) tell me that they are NOT > going to do the trio, and that their mobile device strategy does > not involve Lemonade (or much of IETF). This can't be much of a surprise to anyone -- given that multiple vendors have multiple "mobile email" solutions now, many of which use non-IETF protocols (except for perhaps HTTP), we can't have expected that they'd all drop their current offerings and switch to IMAP. But for those that will use IMAP, we need to have the functionality they need. > Extensions by their very nature are flawed. A client implementor > can not rely upon a server offering it; nor can a client > necessarily assume that the extension will be correctly implemented > by the server even if it is offered. True, and this is especially bad with IMAP. Which is one reason for lemonade: to have a collection of functionality, extensions, and server behavior under one name. A mobile client might reasonably insist on a lemonade server, to avoid needing to implement multiple code paths for every variant, or offer different UI when some extensions aren't available. > Yes, it was a cool idea to have the server do header/MIME parsing; > I use that capability all the time and love it. But it has been so > badly misimplemented (especially in MIME parsing) that no client > can reasonably rely upon it. > > And now you claim that servers will do complex conversions > correctly? I am deeply skeptical. I have good reason. A number of years ago, IMAP interoperability was exceedingly poor. The IMC IMAP bake-offs really helped a lot. Some extensions that announce server behavior have also helped. Such things can be done again. > You're adding complexity in an attempt to keep email from dying. I > don't see any clear or coherant plan to save email, rather a > frantic effort to try every possible notion in the hope that one of > them works. I don't see extended error reporting specifically to help with "the trio" and related lemonade stuff, which is really focused on mobile email, as a "frantic effort to try every possible notion." I just don't see much franticness, and so far things have been focused on mobile email. > Or, rather, we should think about what will replace email; I think > that the technology that will put the final nail in email's coffin > hasn't shown itself yet. But it is coming. This is entirely separate from extensions to email. When email is finally replaced, it won't be an overnight thing. Something new starts getting used in its place, and over time email gets used less and less, perhaps it becomes a protocol for automated process, since they don't care. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The highlight of the annual Computer Bowl occurred when Bill Gates, who was a judge, posed the following question to the contestants: "What contest, held via Usenet, is dedicated to examples of weird, obscure, bizarre, and really bad programming?" After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple) hit his buzzer and answered "Windows." --Recounted by Adam C. Engst _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 17:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBm-00016t-W1; Sun, 02 Dec 2007 17:21:26 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyxBl-00016D-V1 for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:21:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxBl-00015i-Iv for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:25 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxBl-0000DY-63 for lemonade@ietf.org; Sun, 02 Dec 2007 17:21:25 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB2MLMaI004609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 14:21:23 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-80.qualcomm.com [10.50.16.80]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB2MLHPm027860; Sun, 2 Dec 2007 14:21:21 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 14:19:43 -0800 To: Mark Crispin , Ned Freed From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:24 PM -0800 12/2/07, Mark Crispin wrote: > IETF does a great job when it strives towards simplicity in all > things, and it does a wretched job when it allows complexity to > take over. Yes, indeed. It is often hard to determine what is really needed and what is cool-sounding cruft. Hence the storied reliance on "running code." It is often that it only becomes apparent during implementation. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- All probabilities are 50%. Either a thing will happen or it won't. This is especially true when dealing with someone you're attracted to. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 17:30:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxKQ-0006RC-Mq; Sun, 02 Dec 2007 17:30:22 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyxKP-0006Gw-6n for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:30:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxKO-0006En-R1 for lemonade@ietf.org; Sun, 02 Dec 2007 17:30:20 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxKO-0001O4-EW for lemonade@ietf.org; Sun, 02 Dec 2007 17:30:20 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB2MUHDq022283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 14:30:18 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-80.qualcomm.com [10.50.16.80]) by neophyte.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB2MUGPY025399; Sun, 2 Dec 2007 14:30:17 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <01MOF01DL8RS00BDC1@mauve.mrochek.com> References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> <01MOEWBCGHJG00GULE@mauve.mrochek.com> <01MOF01DL8RS00BDC1@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 14:30:08 -0800 To: Ned Freed , Mark Crispin From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org, Peter Coates , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:22 PM -0800 12/2/07, Ned Freed wrote: > What I'm objecting to is your assertion that simplicity is something people > value over other things. Indeed, simplicity is only valued in the abstract. When given a choice, people invariably choose the bells and whistles. That's part of what makes protocol design and standards development hard: weeding out the complexity, and putting off to version 2 what can be left out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Adding manpower to a late software project makes it later. -- Fred Brooks in _The Mythical Man Month_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 18:49:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyyYX-0000KM-FE; Sun, 02 Dec 2007 18:49:01 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IyyYV-0000Jy-6U for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 18:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyyYU-0000Jn-T8 for lemonade@ietf.org; Sun, 02 Dec 2007 18:48:58 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyyYT-0002qD-Dg for lemonade@ietf.org; Sun, 02 Dec 2007 18:48:58 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB2NmsUu005627 for ; Sun, 2 Dec 2007 23:48:54 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSG006014RFHQ00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Sun, 02 Dec 2007 16:48:54 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSG00DCU4T1A470@mail-amer.sun.com> for lemonade@ietf.org; Sun, 02 Dec 2007 16:48:54 -0700 (MST) Date: Sun, 02 Dec 2007 15:47:58 -0800 From: Peter Coates Subject: RE: [lemonade] extended error reporting To: lemonade@ietf.org Message-id: <012701c8353d$ce66cd20$6b346760$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acg1PcQG0i5afIBCQfirmyLClcznzA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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="===============2124453677==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============2124453677== Content-type: multipart/alternative; boundary="Boundary_(ID_avxixZhTh7OmQnve0FKfIQ)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_avxixZhTh7OmQnve0FKfIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I am somewhat bemused by the thread that has developed out of my suggestion for extended error reporting. It is an interesting debate, if marked by rather more heat than light. However, going back to the original point, the extended error reporting. This is an extension that is, I thought, remarkable in how innocuous it is. It requires nothing of either the server or the client. The client can tell the server that it is interested in extended error information, and once it has done that the server may send some. That this proposal has snowballed into a philosophical debate on the direction of IMAP, whether is should be preserved in aspic for old fuddy-duddies who still used email, or whatever, seems to me to be indicative that this argument was awaiting only a nucleation particle. I would like a more linear discussion on the merits of my proposal at some point, perhaps after the heat has dies down. Peter --Boundary_(ID_avxixZhTh7OmQnve0FKfIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I am somewhat bemused by the thread that has developed out of my suggestion for extended error reporting.  It is an interesting debate, if marked by rather more heat than light.

 

However, going back to the original point, the extended error reporting.  This is an extension  that is, I thought, remarkable in how innocuous it is.  It requires nothing of either the server or the  client.  The client can tell the server that it is interested in extended error information, and once it has done that the server may send some.   That this proposal has snowballed into a philosophical debate on the direction of IMAP, whether is should be preserved in aspic for old fuddy-duddies who still used email, or whatever, seems to me to be indicative that this argument was awaiting only a nucleation particle.

 

I would like a more linear discussion on the merits of my proposal at some point, perhaps after the heat has dies down.

 

Peter

--Boundary_(ID_avxixZhTh7OmQnve0FKfIQ)-- --===============2124453677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============2124453677==-- From lemonade-bounces@ietf.org Sun Dec 02 19:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0J-0003C7-VX; Sun, 02 Dec 2007 19:17:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyz0I-0003BY-AT for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0I-0003BO-0q for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyz0G-000602-CR for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB30HcDe010980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 16:17:39 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-0-196.qualcomm.com [10.50.0.196]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB30HYmJ011260; Sun, 2 Dec 2007 16:17:38 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <033901c8308b$93d81b20$bb885160$%coates@sun.com> References: <033901c8308b$93d81b20$bb885160$%coates@sun.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 15:54:07 -0800 To: Peter Coates , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] FW: notify and context Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 4:22 PM -0800 11/26/07, Peter Coates wrote: > The intent is that a client can register its interests, and sit back being > fed the information it wants as it arrives. Thus if it is only interested > in messages meeting a specific set of criteria in particular mailboxes, it > says so and gets headers or whatnot for just those messages. > > What actually happens is that the search program specified and the fetch > program specified are only used if the mail box in question is selected. > Otherwise, if a new message arrives, the client is told about it, end of > story. The implication of this is that if a client is interested in > messages from multiple folders, it will have to select those folders from > time to time to see it the new mail is "interesting". Why does it only work for the selected mailbox? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I have nothing but contempt for someone who can spell a word only one way. --Thomas Jefferson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 19:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0K-0003CK-3m; Sun, 02 Dec 2007 19:17:44 -0500 ReceFrom lemonade-bounces@ietf.org Sun Dec 02 19:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0J-0003C7-VX; Sun, 02 Dec 2007 19:17:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyz0I-0003BY-AT for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0I-0003BO-0q for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyz0G-000602-CR for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB30HcDe010980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 16:17:39 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-0-196.qualcomm.com [10.50.0.196]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB30HYmJ011260; Sun, 2 Dec 2007 16:17:38 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <033901c8308b$93d81b20$bb885160$%coates@sun.com> References: <033901c8308b$93d81b20$bb885160$%coates@sun.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 15:54:07 -0800 To: Peter Coates , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] FW: notify and context Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 4:22 PM -0800 11/26/07, Peter Coates wrote: > The intent is that a client can register its interests, and sit back being > fed the information it wants as it arrives. Thus if it is only interested > in messages meeting a specific set of criteria in particular mailboxes, it > says so and gets headers or whatnot for just those messages. > > What actually happens is that the search program specified and the fetch > program specified are only used if the mail box in question is selected. > Otherwise, if a new message arrives, the client is told about it, end of > story. The implication of this is that if a client is interested in > messages from multiple folders, it will have to select those folders from > time to time to see it the new mail is "interesting". Why does it only work for the selected mailbox? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I have nothing but contempt for someone who can spell a word only one way. --Thomas Jefferson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 19:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0K-0003CK-3m; Sun, 02 Dec 2007 19:17:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyz0I-0003Bp-VV for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0I-0003Bf-Lj for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyz0I-00060W-Bn for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB30HdXP010983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 16:17:40 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-0-196.qualcomm.com [10.50.0.196]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB30HYmL011260; Sun, 2 Dec 2007 16:17:39 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <474C5CF1.3030702@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 16:03:21 -0800 To: Mark Crispin , Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:53 AM -0800 11/27/07, Mark Crispin wrote: > Any measures that reduce complexity and increase demand are good things IMHO. Sure, reducing complexity while at the same time increasing demand for lemonade is great. Which proposals do so? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The whole dream of democracy is to raise the proletarian to the level of stupidity attained by the bourgeois. --Gustave Flaubert _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade ived: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyz0I-0003Bp-VV for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz0I-0003Bf-Lj for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyz0I-00060W-Bn for lemonade@ietf.org; Sun, 02 Dec 2007 19:17:42 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB30HdXP010983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 16:17:40 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-0-196.qualcomm.com [10.50.0.196]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB30HYmL011260; Sun, 2 Dec 2007 16:17:39 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <474C5CF1.3030702@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 16:03:21 -0800 To: Mark Crispin , Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:53 AM -0800 11/27/07, Mark Crispin wrote: > Any measures that reduce complexity and increase demand are good things IMHO. Sure, reducing complexity while at the same time increasing demand for lemonade is great. Which proposals do so? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The whole dream of democracy is to raise the proletarian to the level of stupidity attained by the bourgeois. --Gustave Flaubert _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 19:55:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyzaj-000455-La; Sun, 02 Dec 2007 19:55:21 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iyzah-00043c-N6 for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 19:55:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyzah-00043T-CL for lemonade@ietf.org; Sun, 02 Dec 2007 19:55:19 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyzag-0002He-Qd for lemonade@ietf.org; Sun, 02 Dec 2007 19:55:19 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB30tHBk018354 for ; Mon, 3 Dec 2007 00:55:17 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSG007017U8UK00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Sun, 02 Dec 2007 17:55:17 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSG00H4T7V8C860@mail-amer.sun.com>; Sun, 02 Dec 2007 17:55:04 -0700 (MST) Date: Sun, 02 Dec 2007 16:54:05 -0800 From: Peter Coates Subject: RE: [lemonade] FW: notify and context In-reply-to: To: "'Randall Gellens'" , lemonade@ietf.org Message-id: <014701c83547$0c7df2b0$2579d810$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: Acg1Qe1GYCI5yHF7RjSdyo/NaVPCTAABPuAg References: <033901c8308b$93d81b20$bb885160$%coates@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org It is prohibitively expensive for a server to search non selected mailboxes. That has never been suggested. Peter -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: December 2, 2007 15:54 To: Peter Coates; lemonade@ietf.org Subject: Re: [lemonade] FW: notify and context At 4:22 PM -0800 11/26/07, Peter Coates wrote: > The intent is that a client can register its interests, and sit back being > fed the information it wants as it arrives. Thus if it is only interested > in messages meeting a specific set of criteria in particular mailboxes, it > says so and gets headers or whatnot for just those messages. > > What actually happens is that the search program specified and the fetch > program specified are only used if the mail box in question is selected. > Otherwise, if a new message arrives, the client is told about it, end of > story. The implication of this is that if a client is interested in > messages from multiple folders, it will have to select those folders from > time to time to see it the new mail is "interesting". Why does it only work for the selected mailbox? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I have nothing but contempt for someone who can spell a word only one way. --Thomas Jefferson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 02 22:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2Qe-0005n2-1g; Sun, 02 Dec 2007 22:57:08 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iz2Qc-0005mK-4M for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 22:57:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2Qb-0005mC-Ph for lemonade@ietf.org; Sun, 02 Dec 2007 22:57:05 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz2Qa-0004OO-Sz for lemonade@ietf.org; Sun, 02 Dec 2007 22:57:05 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB33v0if008702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Dec 2007 19:57:01 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-0-196.qualcomm.com [10.50.0.196]) by neophyte.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB33uwE3002695; Sun, 2 Dec 2007 19:56:59 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <003901c83554$d514e320$6e02a8c0@DGCSonyFS> References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com><023001c83057$0630d250$12927 6f0$%coates@sun.com><01MO6FC6ONKS00GULE@mauve.mrochek.com><025d01c83066$0cb62440$2 6226cc0$%coates@sun.com> <003901c83554$d514e320$6e02a8c0@DGCSonyFS> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 2 Dec 2007 19:47:52 -0800 To: "Darryl Champagne" From: Randall Gellens Subject: RE: [lemonade] extended error reporting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:33 PM -0500 12/2/07, Darryl Champagne wrote: > One comment about this comment... > > Saying that a lot of this sort of functionality violates the way IMAP works > doesn't really help - since there is an increasing amount of US Federal > legislation that wants it done that way. Sure, which is why my remark about it being contrary to the way IMAP works was within a "needless to say" clause, by which I meant that it was obvious and also besides the point, and hence there was no need to say it (but I couldn't help myself from saying it anyway). > Many the corporate lawyer demands > that emails be deleted after a fixed amount of time (no matter how stupid > that actually is relative to productivity), to cut down on legal risk. This can only be reliably done with client support (such as a plug-in to certain clients) and even then, the recipient may have forwarded the message, or copied it somewhere, or done something else to it (even printed it). Thus, the original message might be securely deleted, but copies of it may exist in places that might be turned up by searches. > Similarly, once a subpoena has been received, there are all sorts of > restrictions on what can be deleted, which conflict with the desire to > auto-delete, meaning that backup tapes do not easily do what is needed. A separate archive that is connected to the mail system via IMAP could do this. It can make copies of all messages, and could either never delete anything, or permanently delete those items which are not under restriction, possibly triggered by deletion from the user's mailbox. > We may not like the functionality, but if the CIO could go to jail if that > functionality can't be achieved, then supporting it _is_ important, and the > ease in supporting it does matter for market share. Sure. But much of this could be done today by connecting to the mail store with IMAP. Other functionality can't really be done, and what approximation of it can be done can only be done with tight controls on all clients that have access to the mail. At that point it isn't really mail. To be really sure, don't have any local cache, and don't permit forward, copy, or print. The functionality of moving some messages to a secondary storage that takes time to access can even be done within the IMAP model by moving those messages to an archive mailbox (such as a mailbox corresponding to the original but under a different hierarchy). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Ninety percent of the politicians give the other ten percent a bad name. --Henry Kissinger _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 03 12:32:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF9S-0004mk-GZ; Mon, 03 Dec 2007 12:32:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IzF9R-0004mc-FD for lemonade-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:32:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF9R-0004mS-5a for lemonade@ietf.org; Mon, 03 Dec 2007 12:32:13 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzF9P-0002Jy-PB for lemonade@ietf.org; Mon, 03 Dec 2007 12:32:13 -0500 Received: from [130.129.17.12] (dhcp-110c.ietf70.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 3 Dec 2007 17:32:09 +0000 Message-ID: <47543D90.20907@isode.com> Date: Mon, 03 Dec 2007 17:32:00 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG , IMAP Extensions WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Cc: Subject: [lemonade] Friends of IMAP dinner meeting time X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Let's meet at 8pm today near the IETF message board. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 03 17:37:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJv5-0001jH-NO; Mon, 03 Dec 2007 17:37:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iz1fK-00009V-Hn for lemonade-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 22:08:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Iz1fK-00009N-8O for lemonade@ietf.org; Sun, 02 Dec 2007 22:08:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz17O-0003dP-NV for lemonade@ietf.org; Sun, 02 Dec 2007 21:33:10 -0500 Received: from qmta08.westchester.pa.mail.comcast.net ([76.96.62.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz17O-0004UE-C6 for lemonade@ietf.org; Sun, 02 Dec 2007 21:33:10 -0500 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id L2Uy1Y0070vyq2s0500a00; Mon, 03 Dec 2007 02:33:10 +0000 Received: from DGCSonyFS ([75.67.229.125]) by OMTA05.westchester.pa.mail.comcast.net with comcast id L2Z81Y00F2iybpX0300000; Mon, 03 Dec 2007 02:33:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=E7OQYOO8jeLjofVbOZAA:9 a=Jrt84Dpi1AkMfLuB970A:7 a=9VMn2QlBBAt01RU9lZcDuifq79cA:4 a=LY0hPdMaydYA:10 From: "Darryl Champagne" To: , "'Randall Gellens'" References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com><023001c83057$0630d250$129276f0$%coates@sun.com><01MO6FC6ONKS00GULE@mauve.mrochek.com><025d01c83066$0cb62440$26226cc0$%coates@sun.com> Subject: RE: [lemonade] extended error reporting Date: Sun, 2 Dec 2007 21:33:03 -0500 Message-ID: <003901c83554$d514e320$6e02a8c0@DGCSonyFS> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acg0qHmj2MxNw9HYQKmuiXfrVQdg+gAqY8BQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-TMDA-Confirmed: Sun, 02 Dec 2007 22:08:14 -0500 X-Mailman-Approved-At: Mon, 03 Dec 2007 17:37:42 -0500 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org One comment about this comment... Saying that a lot of this sort of functionality violates the way IMAP works doesn't really help - since there is an increasing amount of US Federal legislation that wants it done that way. Many the corporate lawyer demands that emails be deleted after a fixed amount of time (no matter how stupid that actually is relative to productivity), to cut down on legal risk. Similarly, once a subpoena has been received, there are all sorts of restrictions on what can be deleted, which conflict with the desire to auto-delete, meaning that backup tapes do not easily do what is needed. We may not like the functionality, but if the CIO could go to jail if that functionality can't be achieved, then supporting it _is_ important, and the ease in supporting it does matter for market share. dgc -----Original Message----- ... Randall Gellens wrote: It does seem that IT departments are fond of email management systems that give IT extreme control over email, such as the ability to move messages to secondary storage based on their own criteria, as well as permanently delete or prevent the deletion of messages. Needless to say, a lot of this sort of functionality violates the way IMAP works, and some of it could be better accomplished within IMAP (such as using different mailboxes). -- Randall Gellens _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 04 13:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcVs-0000hO-9m; Tue, 04 Dec 2007 13:28:56 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IzMpE-00042k-Bq for lemonade-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:43:52 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IzMpD-0003ue-P7 for lemonade@ietf.org; Mon, 03 Dec 2007 20:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMP1-0000nI-RK for lemonade@ietf.org; Mon, 03 Dec 2007 20:16:47 -0500 Received: from outmail128077.authsmtp.net ([62.13.128.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzMP1-0001Lh-52 for lemonade@ietf.org; Mon, 03 Dec 2007 20:16:47 -0500 Received: from outmail128181.authsmtp.net (outmail128181.authsmtp.net [62.13.128.181]) by punt4.authsmtp.com (8.14.1/8.14.1/Kp) with ESMTP id lB41GgIF094709; Tue, 4 Dec 2007 01:16:42 GMT Received: from DGCSonyFS (c-75-67-229-125.hsd1.nh.comcast.net [75.67.229.125]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id lB41GeFi045597; Tue, 4 Dec 2007 01:16:41 GMT From: "Darryl G. Champagne" To: "'Randall Gellens'" References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com><023001c83057$0630d250$129276f0$%coates@sun.com><01MO6FC6ONKS00GULE@mauve.mrochek.com><025d01c83066$0cb62440$26226cc0$%coates@sun.com> <003901c83554$d514e320$6e02a8c0@DGCSonyFS> Subject: RE: [lemonade] extended error reporting Date: Mon, 3 Dec 2007 20:16:40 -0500 Message-ID: <00cc01c83613$53b1f830$6e02a8c0@DGCSonyFS> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acg1YJVqN2yB0Dp8TH+xMMag20v4OQAq1M+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Server-Quench: 9235059b-a206-11dc-814e-001185d377ca X-AuthRoute: OCdyYgEXBlZZQw8y AygBSihaRhMgOxlQ AAcHIEsAYUxRCUN9 P00ddAILbxVEHAMA BWwPWRpTVUN3Xn13 aQNPbAdYfUhLQAUk DDpNQyUHYlxoBRkE DxlQVh53fktPen11 ZUNrDG0KXkR8aEd8 Fh1JHWwCMHpgaGEe WEUMdARTI1IEHGpP ejsjAS5SPzRTMxdw Eh8vMjY9MDkXJT5P RRtFN18KRlwXHzgz L2Fs X-Authentic-SMTP: 61633132393235.squirrel.dmpriest.net.uk:787/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-TMDA-Confirmed: Mon, 03 Dec 2007 20:43:51 -0500 X-Mailman-Approved-At: Tue, 04 Dec 2007 13:28:54 -0500 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, I do understand that all the examples listed (and far more) can be done (but not easily interoperably!), and many of the ways to actually do them, and the issues with printing, forwarding, and so on, but I was actually trying to tie in with the comments about market share, other large products, and so on... E.g. - Mark's comments like: "If you want to fix IMAP to add the functionality that people really want, you need to have things as contact management, task management, and calendaring. The IETF has failed miserably on all points. Nobody cares about email-only applications any more. Email is a small part of the overall picture, yet you guys are focusing on how to create the Email Protocol From Hell. Not only that, but email itself is a dying means of communication, and you can't blame IMAP for that. " The thing is, if the big consumers of email (actually integrated messaging) products require certain features, and they can only be done in custom ways not supported/obvious by the core protocols, then the protocols themselves aren't really meeting the existing needs, are they? Email (etc.) is not just for geeks anymore... Right now, IMAP/Lemonade is an absolute bear to try and approach from the outside. I know how to address all this functionality in SyncML as well, but it runs into similar issues, that non-experts don't see how, and thus it ends up not being interoperable (and people outside of SyncML will happily tell others how it can't be done). The bare fact of the matter is that when a large company assigns a group of non-subject experts to do something, they don't see how to do what is needed with the existing stuff, and they do their own thing, and usually everyone loses. I don't know what direction is the best to go in, but either the protocols have to have an interoperable way to do everything that is actually needed in the real world, and/or they need to be simpler (or they gradually fade away in relevance). Really I was just objecting to the sentiment expressed, in that it causes problems, not helps. dgc -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Sunday, December 02, 2007 10:48 PM To: Darryl Champagne Cc: lemonade@ietf.org Subject: RE: [lemonade] extended error reporting At 9:33 PM -0500 12/2/07, Darryl Champagne wrote: > One comment about this comment... > > Saying that a lot of this sort of functionality violates the way IMAP works > doesn't really help - since there is an increasing amount of US Federal > legislation that wants it done that way. Sure, which is why my remark about it being contrary to the way IMAP works was within a "needless to say" clause, by which I meant that it was obvious and also besides the point, and hence there was no need to say it (but I couldn't help myself from saying it anyway). > Many the corporate lawyer demands > that emails be deleted after a fixed amount of time (no matter how stupid > that actually is relative to productivity), to cut down on legal risk. This can only be reliably done with client support (such as a plug-in to certain clients) and even then, the recipient may have forwarded the message, or copied it somewhere, or done something else to it (even printed it). Thus, the original message might be securely deleted, but copies of it may exist in places that might be turned up by searches. ... -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Ninety percent of the politicians give the other ten percent a bad name. --Henry Kissinger _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 05 19:08:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04I4-0005Ob-HL; Wed, 05 Dec 2007 19:08:32 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J04I3-0005OD-2a for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 19:08:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04I2-0005O1-CI for lemonade@ietf.org; Wed, 05 Dec 2007 19:08:30 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J04I1-0004VC-PG for lemonade@ietf.org; Wed, 05 Dec 2007 19:08:30 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB608S9L016089 for ; Wed, 5 Dec 2007 16:08:28 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB608MZk020634 for ; Wed, 5 Dec 2007 16:08:27 -0800 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: 7bit Subject: RE: [lemonade] draft-ietf-lemonade-notifications-05.txt Date: Wed, 5 Dec 2007 16:08:23 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] draft-ietf-lemonade-notifications-05.txt Thread-Index: Acgx/xpF7NJACUu5T9+Z4XNuKrhSuwFnPyTg References: From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Does utter silence mean we are done? -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Wednesday, November 28, 2007 3:35 PM To: lemonade@ietf.org Subject: [lemonade] draft-ietf-lemonade-notifications-05.txt This document has been significantly cleaned up and cut down, per . The Security Considerations has also been reworded. Other minor editing as well. I am not aware of any open issues with the document, therefore I propose that no meeting time be spent on it. I'd appreciate people reviewing it and sending editorial comments to me, and technical comments to the list. If you believe this document does need agenda time in Vancouver, please speak up now. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Some days you feel like Schrodinger's cat. --M. S. Hutchenreuther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 05 20:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05jK-0004Xa-Gg; Wed, 05 Dec 2007 20:40:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J05jJ-0004K5-7b for lemonade-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 20:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05jI-0004DM-JY for lemonade@ietf.org; Wed, 05 Dec 2007 20:40:44 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J05jG-000423-Ow for lemonade@ietf.org; Wed, 05 Dec 2007 20:40:44 -0500 Received: from [130.129.17.12] (dhcp-110c.ietf70.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 6 Dec 2007 01:40:40 +0000 Message-ID: <47575314.8060008@isode.com> Date: Thu, 06 Dec 2007 01:40:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Burger Subject: Re: [lemonade] draft-ietf-lemonade-notifications-05.txt References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >Does utter silence mean we are done? > > I don't think we need to talk about this document, but this document still needs some work. I've sent some [mostly editorial] comments directly to Randy. >-----Original Message----- >From: Randall Gellens [mailto:randy@qualcomm.com] >Sent: Wednesday, November 28, 2007 3:35 PM >To: lemonade@ietf.org >Subject: [lemonade] draft-ietf-lemonade-notifications-05.txt > >This document has been significantly cleaned up and cut down, per >. >The Security Considerations has also been reworded. Other minor editing >as well. > >I am not aware of any open issues with the document, therefore I propose >that no meeting time be spent on it. I'd appreciate people reviewing it >and sending editorial comments to me, and technical comments to the >list. > >If you believe this document does need agenda time in Vancouver, please >speak up now. >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- >Some days you feel like Schrodinger's cat. --M. S. Hutchenreuther > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > >Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Dec 06 18:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QLu-0003jr-Kn; Thu, 06 Dec 2007 18:41:58 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0QLt-0003jY-8x for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 18:41:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QLs-0003jQ-Uo for lemonade@ietf.org; Thu, 06 Dec 2007 18:41:56 -0500 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QLq-0005L6-Nu for lemonade@ietf.org; Thu, 06 Dec 2007 18:41:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id A826DEC8F2; Fri, 7 Dec 2007 00:34:52 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzVBgXhPpoVd; Fri, 7 Dec 2007 00:34:52 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 6594715D295; Fri, 7 Dec 2007 00:34:52 +0100 (CET) Subject: RE: [lemonade] extended error reporting From: Philip Van Hoof To: Mark Crispin In-Reply-To: References: <012201c8302d$f3b2ebf0$db18c3d0$%coates@sun.com> <023001c83057$0630d250$129276f0$%coates@sun.com> <01MO6FC6ONKS00GULE@mauve.mrochek.com> <025d01c83066$0cb62440$26226cc0$%coates@sun.com> <01MOENGLEQAC00GULE@mauve.mrochek.com> <01MOEUHLCOSG00GULE@mauve.mrochek.com> Content-Type: text/plain Date: Fri, 07 Dec 2007 00:41:53 +0100 Message-Id: <1196984513.8801.60.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Randall Gellens , lemonade@ietf.org, Peter Coates , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 2007-12-02 at 11:16 -0800, Mark Crispin wrote: > Nobody cares about email-only applications any more. Email is a small > part of the overall picture, yet you guys are focusing on how to create > the Email Protocol From Hell. Not only that, but email itself is a dying > means of communication, and you can't blame IMAP for that. In the past people predicted the end of radio, news papers and called for editors, radio hosts and radio DJs to start finding a new job. And now Mark thinks that E-mail is going to die ... Meanwhile, I'm pragmatically making E-mail work on mobiles. And I'm going to keep doing that. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Dec 06 19:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RB0-0006ml-Bz; Thu, 06 Dec 2007 19:34:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0RAz-0006k2-W5 for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 19:34:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RAz-0006jb-L0 for lemonade@ietf.org; Thu, 06 Dec 2007 19:34:45 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0RAz-0007Oo-3E for lemonade@ietf.org; Thu, 06 Dec 2007 19:34:45 -0500 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB70YhNJ028821; Thu, 6 Dec 2007 16:34:43 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB70YfSJ014153; Thu, 6 Dec 2007 16:34:42 -0800 Received: from 172.24.28.66 ([172.24.28.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Dec 2007 00:34:41 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 06 Dec 2007 07:10:09 -0800 Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis From: Eric Burger To: Alexey Melnikov , Lemonade WG Message-ID: Thread-Topic: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis Thread-Index: Acg4Ghc5Va+ADqQNEdyv4gAWy4mm/w== In-Reply-To: <474C5CF1.3030702@isode.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.9 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I noted in the discussion on error reporting that absolute times, particularly for a mobile device, often just do not work. In fact, the solution offered for URLAUTH is to use relative times. The main purpose of WITHIN is to store a search pattern, e.g., "get me mail that is less than a day old" without having to calculate, upload, re-parse, and re-optimize search indices before doing the search. However, it also has what might be the desirable property of using relative times. Is that not of value? More importantly, will we run afoul of OMA requirements if we drop WITHIN? What is the complex interaction? I missed it on the list. If we refine CONTEXT, would it provide the functionality required that drove us to write WITHIN in the first place? Believe me, I am all for the philosophy of dumping stuff to get this work done! I just want to make sure we do not cut to the point our constituency says our work is irrelevant. One of the work group's customers, and probably our largest market, is the OMA. If we can meet their requirements easily without WITHIN, then I would +1 dumping it. If we cannot, then I would do a big -1. On 11/27/07 10:07 AM, "Alexey Melnikov" wrote: > Based on various discussions during the Lemonade interop in Munich, I > would like to propose the following changes to the Lemonade Profile Bis > document: > > After reviewing existing server and client implementations, there was > support for removing RFC 5032 (WITHIN) from the Lemonade Profile Bis. > The reason for this is because server implementors found interaction > between WITHIN and CONTEXT to be too complex to implement, while client > implementors didn't find the extension to be useful. If somebody would > like to argue that RFC 3052 should be in Lemonade Profile Bis, please > speak up now. [snip] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Dec 06 19:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RB3-00070D-Hg; Thu, 06 Dec 2007 19:34:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0RB2-0006wO-8T for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 19:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RB1-0006ta-TU for lemonade@ietf.org; Thu, 06 Dec 2007 19:34:47 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0RB0-0000dZ-CY for lemonade@ietf.org; Thu, 06 Dec 2007 19:34:47 -0500 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB70YiaI028867 for ; Thu, 6 Dec 2007 16:34:44 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB70YfSL014153 for ; Thu, 6 Dec 2007 16:34:43 -0800 Received: from 172.24.28.66 ([172.24.28.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Dec 2007 00:34:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 06 Dec 2007 15:01:14 -0800 From: Eric Burger To: Message-ID: Thread-Topic: Last Chance: Future Delivery Thread-Index: Acg4W+Z6JTB22qRPEdyv4gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [lemonade] Last Chance: Future Delivery X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Does ANYONE besides Greg want future delivery to be in profile-bis? Speak now or forever hold your peace. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Dec 06 19:58:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RY5-0003Jd-CR; Thu, 06 Dec 2007 19:58:37 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0RY4-0003E4-Hk for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 19:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RY4-0003Bs-7a for lemonade@ietf.org; Thu, 06 Dec 2007 19:58:36 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0RY3-0002L3-RD for lemonade@ietf.org; Thu, 06 Dec 2007 19:58:36 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB70wY2h005381 for ; Thu, 6 Dec 2007 16:58:34 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB70wWR9025091 for ; Thu, 6 Dec 2007 16:58:33 -0800 Received: from 172.24.28.66 ([172.24.28.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Dec 2007 00:58:32 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 06 Dec 2007 16:58:31 -0800 Subject: Re: [lemonade] extended error reporting From: Eric Burger To: Message-ID: Thread-Topic: [lemonade] extended error reporting Thread-Index: Acg4bEjbh4mkrqRfEdyv4gAWy4mm/w== In-Reply-To: <1196984513.8801.60.camel@schtrumpf> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Let us not forget that our success is from having a focus on the e-mail *component* of unified communications systems. That is what makes us relevant in the new world. On 12/6/07 3:41 PM, "Philip Van Hoof" wrote: > > On Sun, 2007-12-02 at 11:16 -0800, Mark Crispin wrote: > >> Nobody cares about email-only applications any more. Email is a small >> part of the overall picture, yet you guys are focusing on how to create >> the Email Protocol From Hell. Not only that, but email itself is a dying >> means of communication, and you can't blame IMAP for that. > > In the past people predicted the end of radio, news papers and called > for editors, radio hosts and radio DJs to start finding a new job. > > And now Mark thinks that E-mail is going to die ... > > Meanwhile, I'm pragmatically making E-mail work on mobiles. > > And I'm going to keep doing that. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Dec 06 20:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RtZ-0003Yq-9m; Thu, 06 Dec 2007 20:20:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0RtY-0003Yc-Fe for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 20:20:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RtY-0003YR-5V for lemonade@ietf.org; Thu, 06 Dec 2007 20:20:48 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0RtW-0003Xa-Kv for lemonade@ietf.org; Thu, 06 Dec 2007 20:20:48 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB71Kix17347 for ; Fri, 7 Dec 2007 01:20:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Dec 2007 20:20:06 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D12D4DD4F@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call calendar thread-index: Acg4b0zW3QekUXABSguNUmYcXXkIqA== From: "Glenn Parsons" To: X-Spam-Score: -4.0 (----) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [lemonade] Last call calendar 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="===============0410585244==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0410585244== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8386F.4D61D120" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8386F.4D61D120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, The slides that we put up in a hurry at the end of the meeting today was = focused on the actions to move to last calls on our outstanding = documents. To reiterate here it is (along with dates for expected new = drafts): IMAP Message Events --> Shepherd URLFETCH Binary --> WG LC (now, deadline for update 1/4, with = example and ABNF fix) Notifications and Filters --> WG LC (12/15) IMAP Convert --> WG LC (12/15) ENABLE (individual now) --> IWG LC (12/15) IMAP Streaming --> WG LC (done...) IMAP NOTIFY --> WG LC (1/18) Architecture --> WG LC (whenever) Profile bis --> finish! (2/8) IMAP Sieve --> WG LC?? To accelerate further, we plan to have a design team conference call to = review contentious issues in the first set of drafts on Dec 18th 17:00 = UTC (9am PT, 12 noon ET, 6pm CET). We may have more... Also, if we need to, I am suggesting a one day interim in either London = or Geneva on Feb 8th. Cheers, Glenn. ------_=_NextPart_001_01C8386F.4D61D120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Last call calendar

Folks,

The slides that we put up in a hurry at = the end of the meeting today was focused on the actions to move to last = calls on our outstanding documents.  To reiterate here it is (along = with dates for expected new drafts):

IMAP Message = Events       =       à = Shepherd
URLFETCH Binary =         =         à WG LC =          (now, deadline for = update 1/4, with example and ABNF fix)
Notifications and = Filters       =         à WG LC =         (12/15)
IMAP Convert    =         =         à WG LC =         (12/15)
ENABLE (individual now) =         à IWG LC =        (12/15)
IMAP Streaming  =         =         à WG LC =         (done…)
IMAP NOTIFY     =         =         à WG LC =         (1/18)
Architecture    =         =         à WG LC =         (whenever)
Profile bis     =         =         à finish! =       (2/8)
IMAP = Sieve      =         =         à WG = LC??

To accelerate further, we plan to have = a design team conference call to review contentious issues in the first = set of drafts on Dec 18th 17:00 UTC (9am PT, 12 noon ET, 6pm CET).  = We may have more...

Also, if we need to, I am suggesting a = one day interim in either London or Geneva on Feb 8th.

Cheers,
Glenn.

------_=_NextPart_001_01C8386F.4D61D120-- --===============0410585244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0410585244==-- From lemonade-bounces@ietf.org Thu Dec 06 20:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0S7h-0003CM-Sq; Thu, 06 Dec 2007 20:35:25 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0S7g-0003CG-SC for lemonade-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 20:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0S7g-0003C8-IV for lemonade@ietf.org; Thu, 06 Dec 2007 20:35:24 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0S7e-0004J9-RD for lemonade@ietf.org; Thu, 06 Dec 2007 20:35:24 -0500 Received: from dhcp-14db.ietf70.org (dhcp-14db.ietf70.org [130.129.20.219]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lB71ZGM9019873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Dec 2007 20:35:19 -0500 Date: Thu, 06 Dec 2007 17:35:16 -0800 From: Cyrus Daboo To: lemonade@ietf.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=2.7 required=5.0 tests=HELO_DYNAMIC_DHCP autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [lemonade] Comments on notify extension X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, Some comments on notify: - does not indicate which other extensions are required - e.g. is LISTEXT required? - "extended LIST" is not used in all places it should be - Section 5.8 shows an example where a METADATA value is returned in the unsolicited response. However METADATA does not include the annotation values in its unsolicited extended LIST response. This is inconsistent. I suggest notify only return the entry names of the entries changed. - Why is there no notification for server metadata changes? This would be useful if the "message of the day" changed, for example. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 07 17:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lwZ-0006s8-3w; Fri, 07 Dec 2007 17:45:15 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0lwX-0006pE-Mg for lemonade-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 17:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lwX-0006mk-BM for lemonade@ietf.org; Fri, 07 Dec 2007 17:45:13 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0lwV-0002Zl-N9 for lemonade@ietf.org; Fri, 07 Dec 2007 17:45:13 -0500 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB7MjAUB005155 for ; Fri, 7 Dec 2007 14:45:10 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB7Mj2M6002291 for ; Fri, 7 Dec 2007 14:45:08 -0800 Received: from 172.24.29.107 ([172.24.29.107]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Dec 2007 22:44:51 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 07 Dec 2007 16:36:17 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Dis-ENABLEd Chair Thread-Index: Acg5GTLXcYbtCKUMEdyv4gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [lemonade] Dis-ENABLEd Chair X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I do not fully understand ENABLE, and from the nearly 50 messages on the list, it is not clear that it is clear what it is for. For example, the text says the purpose of ENABLE is for the *client* to tell the *server* the client can support some extensions. Think of it as push CAPABILITIES ;-) Great. So now I do not understand any of the discussion about CAPABILITY. For that matter, I do not understand the example in draft-gulbrandsen-imap-enable-03. Namely, why is CONDSTORE not in the initial CAPABILITY? I don't see anything in RFC 4551 that says, "keep this a secret until the client logs in" or "keep this a secret until the client ENABLEs condstore." As far as I can tell, there is nothing in imap-enable to say *what* a server *does* with ENABLE. All it does is says it lets the server know the client supports the extension. Like the text says, "most IMAP implementations do not require the client to enable the extension in any way." This would imply the specifications for CONDSTORE and ANNOTATE have text explaining how the client has to issue an ENABLE, or at least have text explaining how it would be good if the client issues an ENABLE. However, they do not. The text says ENABLE "turns on" extensions without side effects. But it never says why that is important. Text describing *why* we do ENABLE and *how* it works would go a long way. I would offer that would end decisively the mystery of CAPABILITY values coming and going (yes or now). Likewise, it would end decisively the question of whether there is any value to the server returning BAD for a capability that exists but is not available to the client. If the capability is not available to the client, it does not get listed to the client in the CAPABILITY response. If it does not get listed, then the client never even thinks of issuing an ENABLE, because the server has told the client the server does not support the capability. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 07 22:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0qpU-0005eY-NC; Fri, 07 Dec 2007 22:58:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J0qpT-0005eM-AI for lemonade-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 22:58:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0qpS-0005dk-WB for lemonade@ietf.org; Fri, 07 Dec 2007 22:58:15 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0qpS-00033u-JH for lemonade@ietf.org; Fri, 07 Dec 2007 22:58:14 -0500 Received: from dhcp-14db.ietf70.org (piper.mulberrymail.com [151.201.22.177] (may be forged)) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lB83w3qR004889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 22:58:03 -0500 Date: Fri, 07 Dec 2007 19:58:03 -0800 From: Cyrus Daboo To: Eric Burger , lemonade@ietf.org Subject: Re: [lemonade] Dis-ENABLEd Chair Message-ID: <6BBD3C565B5E4E8DB36996DF@dhcp-14db.ietf70.org> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=2.7 required=5.0 tests=HELO_DYNAMIC_DHCP autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Eric, --On December 7, 2007 4:36:17 PM -0500 Eric Burger wrote: > Text describing *why* we do ENABLE and *how* it works would go a long way. One key reason: Some IMAP extensions allow the server to return unsolicited responses specific to that extension in certain circumstances. However, servers cannot send those unsolicited responses until they know that the clients "know" about the extension and thus won't choke on the extension response data. Up until now extensions have typically stated that a server cannot send the unsolicited responses until after the client has used a command with the extension data (i.e. at that point the server knows the client is aware of the extension). This is somewhat awkward. What ENABLE does is provide an explicit indication from the client that it supports a particular extension. As soon as it sees that the server knows that extension response data for the enabled extensions is OK to send. I will leave it to someone else to explain the interaction with CAPABILITY. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Dec 08 15:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J169e-0005oK-Oj; Sat, 08 Dec 2007 15:20:06 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J169d-0005o7-JW for lemonade-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 15:20:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J169d-0005nz-9C for lemonade@ietf.org; Sat, 08 Dec 2007 15:20:05 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J169c-0000uw-Pa for lemonade@ietf.org; Sat, 08 Dec 2007 15:20:05 -0500 Received: from [192.168.1.129] (S0106005018446c5d.vc.shawcable.net [24.85.75.120]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 8 Dec 2007 20:20:02 +0000 Message-ID: <475AFC66.3040108@isode.com> Date: Sat, 08 Dec 2007 20:19:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: [lemonade] Comments on notify extension References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus Daboo wrote: > Hi, > Some comments on notify: Hi Cyrus, Thank you for the comments. > - does not indicate which other extensions are required - e.g. is > LISTEXT required? Clarified that support for LIST-EXTENDED is not required. > - "extended LIST" is not used in all places it should be I am not sure about that. Obviously the client needs to handle both the standard LIST response and the extended LIST response. > - Section 5.8 shows an example where a METADATA value is returned in > the unsolicited response. However METADATA does not include the > annotation values in its unsolicited extended LIST response. This is > inconsistent. Right. > I suggest notify only return the entry names of the entries changed. Unless people think that METADATA response must return values automatically, I will fix the example. > - Why is there no notification for server metadata changes? This would > be useful if the "message of the day" changed, for example. I will add this. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 09 08:52:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1MZg-0002Zq-DP; Sun, 09 Dec 2007 08:52:04 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J1MZe-0002ZX-28 for lemonade-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 08:52:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1MZd-0002Z1-CV for lemonade@ietf.org; Sun, 09 Dec 2007 08:52:01 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1MZU-00067H-VJ for lemonade@ietf.org; Sun, 09 Dec 2007 08:52:01 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB9DpqcJ021312 for ; Sun, 9 Dec 2007 13:51:52 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSS00901BMFU800@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Sun, 09 Dec 2007 06:51:51 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSS00N0IBU23Z50@mail-amer.sun.com> for lemonade@ietf.org; Sun, 09 Dec 2007 06:51:51 -0700 (MST) Date: Sun, 09 Dec 2007 05:50:41 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <013301c83a6a$7e200070$7a600150$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acg6anns/cMocQAhT1yKFLld2Ls0+w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 04c2b1ebb10cfa15bd207724a97e1464 Subject: [lemonade] suggested changes to NOTIFY 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="===============0609494861==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============0609494861== Content-type: multipart/alternative; boundary="Boundary_(ID_PNAKDSgl6REkQAbQk2ij4g)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_PNAKDSgl6REkQAbQk2ij4g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT In Vancouver I said I would write up my proposal for changes to NOTIFY. I have marked up the -07 draft with my changes. Deletions I have marked thus, and additions thus. I have not made any efforts to correct section numbers. Peter Network Working Group Curtis King Internet-Draft Alexey Melnikov Intended Status: Proposed Standard Isode Ltd. Arnt Gulbrandsen Oryx Mail Systems GmbH July 9, 2007 The IMAP NOTIFY Extension draft-gulbrandsen-imap-notify-07.txt 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 expires in November 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications, such as messages being added to or deleted from mailboxes. King, et al. Expires January 2008 FF[Page 1] Internet-draft July 2007 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Formal syntax is defined by [RFC4234] as extended by [RFC3501] and [RFC4466]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. 2. Overview The IDLE command (defined in [RFC2177]) provides a way for the client to go into a mode where the IMAP server pushes notifications about IMAP mailstore events for the selected mailbox. However, the IDLE extension doesn't restrict or control which server events can be sent, or what information the server sends in response to each event. This document defines an IMAP extension that allows clients to express their preferences about unsolicited events generated by the server. The extension allows clients to only receive events they are interested in, while servers know that they don't need to go into effort of generating certain types of untagged responses. IMAP servers which support this extension advertise the X-DRAFT- I07-NOTIFY extension. Comments regarding this draft may be sent either to the lemonade@ietf.org mailing list or to the authors. 3. Rationale and Principals of Operation Without the Notify command, and IMAP server will only send information About changes of state to the client in one of three places: - as the result of a client command (eg *FETCH responses to a FETCH or STORE command), - unsolicited responses sent just before the end of a command (eg * EXISTS or * EXPUNGED responses return just before a TAGGED response as the result of changes outside the current context, and - during an IDLE command. The NOTIFY command extends what information may be returned in those last two cases, and also permits and requires the server to send information about updates between command. The NOTIFY command also allows for the client to extend what information is sent unsolicited about the selected mailbox, and to request some update information to be sent regarding other mailboxes. For the new messages delivered to or appended to the selected mailbox, The NOTIFY command can be used to request that a set of attributes be Sent to the client in an unsolicited FETCH response. This allows a Client to be passive recipient of events and new mail, and be able to Maintain full synchonisation without having to issue any subsequent Commands except to modify the state of the mailbox on the server. Some mobile clients, however, may want mail "pushed" only for mail that matches a search pattern. To meet that need [CONTEXT] is augmented by yhis draft to extend the UPDATE return option to specify a list of fetch-atts to be returned when a new message is delivered or appended in another context. 3. The NOTIFY Command Arguments: "ADD" or "SET" Mailboxes to be watched Events about which to notify the client Or Arguments: "NONE" Responses: Possibly untagged STATUS responses (for ADD/SET) Result: OK The server will notify the client as requested. NO NOTIFY too complex or expensive, lack of permissions. BAD Command unknown, invalid, unsupported or unknown arguments. The NOTIFY command informs the server that the client listens for event notifications all the time (even when no command is in progress) and requests the server to notify it about the specified set of events for the selected mailbox or for specific mailboxes. The NOTIFY command has 3 forms. The NOTIFY NONE specifies that the client is not interested in any kind of event happening on the server. The NOTIFY ADD prepends one or more events to the list of events which are interesting to the client. The NOTIFY SET replaces the current list of interesting events with a new list of events. (Note that NOTIFY SET is effectively the same as NOTIFY NONE followed by NOTIFY ADD .) Until the NOTIFY command is used for the first time, the server only sends notifications while a command is being processed, and notifies the client about these events on the selected mailbox: (see section 5 for definitions): MessageNew, MessageExpunge, FlagChange and (if [ANNOTATE] is being used) AnnotationChange. It does not notify the client about any events on other mailboxes. The effect of NOTIFY lasts until the next NOTIFY command, or until the IMAP connection is closed. The NOTIFY command can request notifications of changes to the selected mailbox whatever it may be at the time the notifications are being generated, specified by the SELECTED mailbox selector in the NOTIFY COMMAND. It can also request notifications on other mailboxes by name or by a limited pattern match. The notifications returned for the currently selected mailbox will be those specified by the SELECTED mailbox specifier, even if the selected mailbox also appears by name in the command. The information returned for message level changes to the SELECTED mailbox will be in the form of untagged FETCH, EXISTS, RECENT, EXPUNGE or VANISHED responses. The information returned for message level changes to other mailboxes will be in the form a untagged STATUS responses. If the NOTIFY command enables MessageNew, MessageExpunge, AnnotationChange or FlagChange notification for a mailbox other than SELECTED, the server MUST send a STATUS response for that mailbox before NOTIFY's tagged OK. If MessageNew is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST contain MESSAGES. If either AnnotationChange or FlagChange are included, the STATUS response MUST contain UIDVALIDITY and HIGHESTMODSEQ. Clients are advised to limit the number of mailboxes used with NOTIFY. Particularly, if a client asks for events for all accessible mailboxes, the server may swamp the client with updates about shared mailboxes. This wastes both server resources and network traffic, and the client may have to pay for every byte. For each mailbox specified, the server verifies that the client has access using the following test: - If the name does not refer to a mailbox, the server MUST ignore it. - If the name refers to a mailbox which the client can't LIST, the server MUST ignore it. For a server that implements [RFC4314] this means that the client that doesn't have the 'l' (lookup) right for King, et al. Expires January 2008 FF[Page 3] Internet-draft July 2007 the name, it MUST ignore it. - If the name refers to a mailbox for which the client has 'l', but misses another required right, the server MUST respond with a tagged NO. [[Alexey: I still think that ignoring such mailboxes would be better from security standpoint.]] If the notification would be prohibitively expensive for the server (e.g. "notify me of all flag changes in all mailboxes"), the server MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] response. If the client requests information for events of an unsupported type (e.g. QuotaExceed and the server does not advertise the QUOTA extension defined in [RFC2087]), the server MUST refuse the command with a tagged BAD response. Here's an example: S: * OK [CAPABILITY IMAP4REV1 NOTIFY] C: a login bob alice S: a OK Password matched C: b notify set (selected MessageNew (uid body.peek[header.fields (from to subject)]) (all) MessageExpunge) (subtree Lists MessageNew (uid) (all)) S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 500) S: [...] S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) S: b OK done C: c select inbox S: [...] (the usual 7-8 responses to SELECT) S: c OK INBOX selected (Time passes. A new message is delivered to mailbox Lists/Lemonade.) S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES 501) (Time passes. A new message is delivered to inbox.) S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)] {75} S: Subject: Re: good morning S: From: alice@example.org S: To: bob@example.org S: S: ) (Time passes. The client decides it wants to know about one more mailbox.) C: d notify add (mailboxes misc MessageNew (uid) (all)) King, et al. Expires January 2008 FF[Page 4] Internet-draft July 2007 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) (This command enables notification on one mailbox and otherwise changes nothing, so one STATUS response is sent.) S: d OK done 4. Interaction with the IDLE Command If IDLE (as well as this extension) is supported, the server should send MessageExpunge while processing IDLE, and otherwise send the same events as the client instructed using NOTIFY. NOTIFY makes IDLE unnecessary for some clients. If a client does not use MSNs and '*' in commands, it can request MessageExpunge and MessageNew for the selected mailbox using NOTIFY instead of entering IDLE mode. 5. Event Types Only some of the events in [MSGEVENT] can be expressed in IMAP, and for some of them there are several possible ways to express the event. This section specifies the events of which an IMAP server can notify an IMAP client, and how. The server SHOULD omit notifying the client if the event is caused by this client. For example, if the client issues CREATE and has requested MailboxCreate event that would cover the newly created mailbox, the server SHOULD NOT notify the client of the MailboxCreate change. All event types require the 'l' and 'r' rights (see [RFC4314]) on all observed mailboxes. AdminMailbox and the quota-related event types additionally require the 'a' right. Servers that don't implement [RFC4314] should map the above rights to their access control model. If the client instructs the server to not send MessageNew or MessageExpunge for the SELECTED mailbox, the server MUST send EXISTS and EXPUNGE responses as required by IMAP (see RFC3501 section 7). In other words, MessageNew instructs the server to notify the client immediately, and the lack of MessageNew instructs the server to notify the client during execution of the next command. MessageExpunge is similar. King, et al. Expires January 2008 FF[Page 5] Internet-draft July 2007 5.1. FlagChange and AnnotationChange If the flag/annotation change happens in the SELECTED mailbox, the server notifies the client by sending an unsolicited FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses. If a search context is in effect as specified in [CONTEXT], an ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated if appropriate. In this case, the FETCH response will precede the ESEARCH response. If the change happens in another mailbox, then the response depends on whether CONDSTORE [RFC4551] is being used. If so, the server sends a STATUS (HIGHESTMODSEQ) response. (Note that whenever mailbox UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the STATUS response.) If not, the server does not notify the client. FlagChange covers the MessageRead, MessageTrash, FlagsSet and FlagsClear events in [MSGEVENT]. [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent for MessageRead. Arnt considers that unsound, since it involves processing all messages in a mailbox after an event affecting only one message, and since it's not reliable anyway.]] Example in the selected mailbox: S: * 99 FETCH (UID 9999 FLAGS ($Junk)) And in another, with CONDSTORE in use: S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 5.2. MessageNew This covers both MessageNew and MessageAppend in [MSGEVENT]. If the new/appended message is in the SELECTED mailbox, the server notifies the client by sending an unsolicited EXISTS response, followed by an unsolicited FETCH response containing the information requested by the client. A FETCH response will not be generated for a new message created in this context, for instance as the result of an APPEND or COPY command to the selected mailbox. The server MAY also send a RECENT response, if the server marks the message as \Recent. Note that a single EXISTS response can be returned for multiple MessageAppend/MessageNew events. If a search context is in effect as specified in [CONTEXT], an ESEARCH ADDTO will also be generated if appropriate. In this case, the EXISTS response will precede the ESEARCH response. Both the NOTIFY command and the SEARCH and SORT commands can specify attributes to be returned for new messages. These attributes MAY be combined into a single FETCH response. The server SHOULD avoid sending duplicate data. The FETCH response(s) SHOULD follow any ESEARCH ADDTO responses. If the new/appended message is in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the HIGHESTMODSEQ status data item MUST be included in the STATUS response. The client SHOULD NOT use FETCH attributes that implicitly set the King, et al. Expires January 2008 FF[Page 6] Internet-draft July 2007 \seen flag, or that presuppose the existence of a given bodypart. UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and BODY/BODYSTRUCTURE may be the most useful attributes. Whatever FETCH attributes are specified, the server SHOULD NOT set the \seen flag. Note that if a client asks to be notified of MessageNew events, the number of messages can increase at any time, and therefore the client cannot refer to a specific message using the MSN/UID '*'. Example in the selected mailbox: S: * 444 EXISTS S: * 444 FETCH (UID 9999) And in another, without CONDSTORE: S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 5.3. MessageExpunge If the expunged message(s) is/are in the selected mailbox, the server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] is being used). If the expunged message(s) is/are in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be included in the STATUS response. Note that if a client requests MessageExpunge, the meaning of an MSN can change at any time, so the client cannot use MSNs in commands any more. For example, such a client cannot use FETCH (it must only use UID FETCH). The meaning of '*' can also change when messages are added or expunged. The MessageExpunge notification covers both MessageExpunge and MessageExpire events from [MSGEVENT]. Example in the selected mailbox, without QRESYNC: S: * 444 EXPUNGE The same example in the selected mailbox, with QRESYNC: S: * VANISHED 5444 And in another: S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 5.4. QuotaExceed, QuotaWithin and QuotaChange [[Alexey: I liked the following version more: If the client has permission to perform GETQUOTA (defined in [RFC2087]), the server King, et al. Expires January 2008 FF[Page 7] Internet-draft July 2007 sends an unsolicited QUOTA response containing the new quotas. ]] The server sends an unsolicited QUOTA response containing the new quotas. The server also sends an unsolicited QUOTAROOT response, so that the client can correlate the affected mailbox to the quota root. These notifications are sent if the client has requested notifications for at least one affected mailbox. Example: S: * QUOTAROOT INBOX "" S: * QUOTA "" (STORAGE 10 512) In this example the quota root named "" (see [RFC2087] for the definition of quota root) governs the mailbox INBOX. Note that the server may return the QUOTAROOT and the QUOTA response in any order. 5.5. MailboxCreate and MailboxDelete The server notifies the client by sending an unsolicited LIST responses for each affected mailbox name. If the mailbox name does not refer to a mailbox after the event, the \Nonexistent flag MUST be included. These notifications are sent if the client has requested notifications for at least one affected mailbox. In the case of MailboxCreate, the mailbox itself and its parent are considered to be affected. In the case of MailboxDelete, all deleted mailboxes and their parent(s) are considered to be affected. Example of a newly created mailbox: S: * LIST () "/" "NewMailbox" And a deleted mailbox: S: * LIST (\NoSelect) "/" "INBOX.DeletedMailbox" 5.6. MailboxRename For each selectable mailbox renamed, the server sends an extended LIST response [LISTEXT] for the new mailbox name, containing the OLDNAME extended data item with the old mailbox name. When a mailbox is renamed, its children are renamed too. No additional MailboxRename events are sent for children in this case. When INBOX is renamed, a new INBOX is assumed to be created. No MailboxCreate event must be sent for INBOX in this case. Example: King, et al. Expires January 2008 FF[Page 8] Internet-draft July 2007 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 5.7. SubscriptionChange The server notifies the client by sending an unsolicited LIST responses for each affected mailbox name. If and only if the mailbox is subscribed after the event, the \Subscribed attribute (see [LISTEXT]) is included. Example: S: * LIST (\Subscribed) "/" "SubscribedMailbox" 5.8. MailboxMetadataChange The server sends an unsolicited LIST response including METADATA. If possible, only the changed metadata should be included, but if necessary, all metadata must be included. Example: S: * LIST "/" "INBOX" (METADATA (/comment (value.priv "My comment"))) 5.9. AdminMailbox If the user has the right to perform GETACL (see [RFC4314]) after the event, the server notifies the client by sending an unsolicited ACL response with the mailbox' new rights. If the user loses the right to perform GETACL as a result of this event, the server MAY also send the ACL response. In all other cases, the server does not notify the client. Example: S: * ACL INBOX Fred rwipslxcetda David lrswideta 5.10. Notification Overflow If the server is unable or unwilling to deliver as many notifications as it is being asked to, it may disable notifications for some or all clients. It MUST notify these clients by sending an untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE command had just been received. King, et al. Expires January 2008 FF[Page 9] Internet-draft July 2007 Example: S: * OK [NOTIFICATIONOVERFLOW] CPU overloaded, sorry 5.11. ACL Changes Even if NOTIFY succeeds, it is still possible to lose access to the mailboxes monitoried at a later time. If this happens, the server MUST silently stop monitoring these mailboxes. If access is later granted, the server MUST restart event monitoring. [[Open issue: This similar with the GETACL treatment in 5.9, which noone has complained about, but is it optimal?]] 6. Mailbox Specification. Mailboxes to be monitored can be specified in several different ways. If the client specifies monitoring of the same mailbox several times, the first specification wins. A common example is asking for events on the selected mailbox and some named mailboxes. In this example, the client asks for MessageExpunge events for all personal mailboxes except the selected mailbox: C: a notify set (selected (MessageNew (uid flags) flagchange)) (personal (MessageNew (uid flags) flagchange MessageExpunge)) 6.1. Selected Selected refers to the mailbox selected using either SELECT or EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP connection is not in selected state, selected does not refer to any mailbox. 6.2. Personal Personal refers to all selectable mailboxes in the user's personal namespace(s). 6.3. Inboxes Inboxes refers to all selectable mailboxes in the user's personal namespace(s) to which messages may be delivered by an MDA (see King, et al. Expires January 2008 FF[Page 10] Internet-draft July 2007 [EMAIL-ARCH], particularly section 4.3.3). If the IMAP server cannot easily compute this set, it MUST treat "inboxes" as equivalent to "personal". 6.4 Subscribed Subscribed refers to all mailboxes subscribed by the user. If the subscription list changes, the list MUST be reevaluated. 6.5 Subtree Subtree is followed by a mailbox name or list of mailbox names. A subtree refers to all selectable mailboxes which are subordinate to the specified mailbox plus the mailbox itself. [[Open Issue: Making this "all selectable mailboxes" makes it easy to implement this well. The pattern can be evaluated at NOTIFY time and notification information affixed to the mailboxes in RAM. Fine. But what about "notify me if any mailboxes are created whose name contains the letters xxx"? Not useful IMO...? (writes arnt)]] 6.6 Mailboxes Mailboxes is followed by a mailbox name or list of mailbox names. Note that the LIST wildcard characters ('*' and '%') are not treated specially in mailbox names. 8. Search and Sort commands If the server supports CONTEXT=SEARCH or CONTEXT=SORT as defined in [CONTEXT], the UPDATE return option is extended to a client can request that FETCH attributes be returned when a new message is added to a result set. For example: C: a00 SEARCH RETURN (COUNT UPDATE (BODY[HEADER.FIELDS (TO FROM SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT 17) S: a00 OK [a new message is delivered] S: * EXISTS 93 S: * ESEARCH (TAG "a00") ADDTO (0 93) S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76} S: Subject: Re: good morning S: From: myboss@example.org S: To: bob@example.org S: S: ) Note that the EXISTS response MUST precede the ESEARCH response, and the FETCH response SHOULD follow the ESEARCH response 7. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines the non-terminals "capability", "command-auth", "mailbox", "mailbox- data", "resp-text-code" and "search-key". Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "X-DRAFT-I07-NOTIFY" ;; [[Note to RFC Editor: change the capability King, et al. Expires January 2008 FF[Page 11] Internet-draft July 2007 ;; name before publication]] command-auth =/ notify notify = "NOTIFY" SP (notify-add / notify-set / notify-none) notify-add = "ADD" SP event-groups ; Add (prepend) registered notification ; events to the list of notification ; events. Newer events override older ; events. [[Alexey: what about "most specific" event overriding a pattern?]] notify-set = "SET" SP event-groups ; Replace registered notification events ; with the specified list of events notify-none = "NONE" ; Cancel all registered notification ; events. The client is not interested ; in receiving any events. one-or-more-mailbox = mailbox / many-mailboxes many-mailboxes = "(" mailbox *(SP mailbox) ")" event-groups = event-group *(SP event-group) event-group = "(" filter-mailboxes SP events ")" filter-mailboxes = "selected" / "inboxes" / "personal" / "subscribed" / ( "subtree" SP one-or-more-mailbox ) / ("mailboxes" SP one-or-more-mailbox) events = ( "(" event *(SP event) ")" ) / "NONE" ;; As in [MSGEVENT]. ;; "NONE" means that the client does not wish ;; to receive any events for the specified ;; mailboxes. event = message-event / mailbox-event / user-event / event-ext message-match-criteria = "(" search-key ")" King, et al. Expires January 2008 FF[Page 12] Internet-draft July 2007 message-event = ( "MessageNew" [ SP "(" fetch-att *(SP fetch-att) ")" SP message-match-criteria ] ) / "MessageExpunge" / "FlagChange" SP message-match-criteria / "AnnotationChange" SP message-match-criteria ;; "MessageNew" includes "MessageAppend" from ;; [MSGEVENT]. "FlagChange" is any of ;; "MessageRead", "MessageTrash", "FlagsSet", ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" ;; includes "MessageExpire" [MSGEVENT]. ;; the fett-att list may only be present for the ;; SELECTED mailbox filter mailbox-event = "MailboxCreate" / "MailboxDelete" / "MailboxRename" / "SubscriptionChange" / "MailboxMetadataChange" / "QuotaChange" / "AdminMailbox" ; "SubscriptionChange" includes ; MailboxSubscribe and MailboxUnSubscribe user-event = "QuotaExceed" / "QuotaWithin" event-ext = atom ;; For future extensions oldname-extended-item = "OLDNAME" SP "(" mailbox ")" ;; Extended data item (mbox-list-extended-item) ;; returned in a LIST response when a mailbox is ;; renamed. ;; Note 1: the OLDNAME tag can be returned ;; with and without surrounding quotes, as per ;; mbox-list-extended-item-tag production. resp-text-code =/ "NOTIFICATIONOVERFLOW" 8. Security considerations It is very easy for a client to deny itself service using NOTIFY: Asking for all events on all mailboxes may work on a small server, but with a big server can swamp the client's network connection or processing capability. In the worst case, the server's processing could also degrade the service it offers to other clients. Servers authors should be aware that if a client issues requests and does not listen to the resulting responses, the TCP window can easily fill up, and a careless server might block. This problem exists in plain IMAP, however this extension magnifies the problem. King, et al. Expires January 2008 FF[Page 13] Internet-draft July 2007 This extensions makes it possible to retrieve messages immediately when they are added to the mailbox. This makes it wholly impractical to delete sensitive messages using programs like imapfilter. Using [SIEVE] or similar is much better. 9. IANA considerations The IANA is requested to add NOTIFY to the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. 9.1. Initial LIST-EXTENDED extended data item registrations It is requested that the following entry be added to the LIST- EXTENDED extended data item registry [LISTEXT]: To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED extended data item LIST-EXTENDED extended data item tag: OLDNAME LIST-EXTENDED extended data item description: The OLDNAME extended data item describes the old mailbox name for the mailbox identified by the LIST response. Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): none Published specification : RFC XXXX, Section 5.6. Security considerations: none Intended usage: COMMON Person and email address to contact for further information: Alexey Melnikov Owner/Change controller: iesg@ietf.org 10. Acknowedgements The authors gratefully acknowledge the help of Peter Coates, Dave Cridland, Mark Crispin, Cyrus Daboo and Abhijit Menon-Sen. Various example lines are copied from other RFCs. This document builds on one published and two unpublished drafts by the same authors. King, et al. Expires January 2008 FF[Page 14] Internet-draft July 2007 11. Normative References [RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997. [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC4234] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Brandenburg Internetworking, Demon Internet Ltd, October 2005. [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006. [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, Isode Ltd., June 2006. [ANNOTATE] Gellens, Daboo, "IMAP ANNOTATE Extension", draft-ietf- imapext-annotate-16 (work in progress). [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- ietf-imapext-list-extensions-18 (work in progress), IBM, September 2006. [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- annotatemore-11 (work in progress), Apple Computer, Inc., February 2007. [MSGEVENT] Newman, "Internet Message Store Events", draft-ietf- lemonade-msgevent-03.txt (work in progress), Sun, July 2007. 12. Informative References [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, Mirapoint Inc, January 2001. King, et al. Expires January 2008 FF[Page 15] Internet-draft July 2007 [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", draft-ietf-lemonade- reconnect-client-05.txt (work in progress), February 2007. [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- email-arch-09 (work in progress), March 2007. 13. Authors' Addresses Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Curtis.King@isode.com Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany Email: arnt@oryx.com King, et al. Expires January 2008 FF[Page 16] Internet-draft July 2007 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. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. King, et al. Expires January 2008 FF[Page 17] --Boundary_(ID_PNAKDSgl6REkQAbQk2ij4g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

In Vancouver I said I would write up my proposal for changes to NOTIFY.  I have marked up the -07 draft with my changes.  Deletions I have marked thus, and additions thus.  I have not made any efforts to correct section numbers.

 

Peter

 

 

 

Network Working Group                                        Curtis King

Internet-Draft                                           Alexey Melnikov

Intended Status: Proposed Standard                            Isode Ltd.

                                                        Arnt Gulbrandsen

                                                  Oryx Mail Systems GmbH

                                                            July 9, 2007

 

 

                       The IMAP NOTIFY Extension

                  draft-gulbrandsen-imap-notify-07.txt

 

 

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 expires in November 2007.

 

 

Copyright Notice

 

    Copyright (C) The IETF Trust (2007).

 

 

Abstract

 

    This document defines an IMAP extension which allows a client to

    request specific kinds of unsolicited notifications, such as

    messages being added to or deleted from mailboxes.

 

 

 

 

King, et al.              Expires January 2008                FF[Page 1]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

1.  Conventions Used in This Document

 

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

    document are to be interpreted as described in [RFC2119].

 

    Formal syntax is defined by [RFC4234] as extended by [RFC3501] and

    [RFC4466].

 

    Example lines prefaced by "C:" are sent by the client and ones

    prefaced by "S:" by the server. "[...]" means elision.

 

 

2.  Overview

 

    The IDLE command (defined in [RFC2177]) provides a way for the

    client to go into a mode where the IMAP server pushes notifications

    about IMAP mailstore events for the selected mailbox.  However, the

    IDLE extension doesn't restrict or control which server events can

    be sent, or what information the server sends in response to each

    event.

 

    This document defines an IMAP extension that allows clients to

    express their preferences about unsolicited events generated by the

    server.  The extension allows clients to only receive events they

    are interested in, while servers know that they don't need to go

    into effort of generating certain types of untagged responses.

 

    IMAP servers which support this extension advertise the X-DRAFT-

    I07-NOTIFY extension.

 

    Comments regarding this draft may be sent either to the

    lemonade@ietf.org mailing list or to the authors.

 

 

3.  Rationale and Principals of Operation

 

    Without the Notify command, and IMAP server will only send information

    About changes of state to the client in one of three places:

    -  as the result of a client command (eg *FETCH responses to a FETCH

       or STORE command),

    -  unsolicited responses sent just before the end of a command (eg

       * EXISTS or * EXPUNGED responses return just before a TAGGED

       response as the result of changes outside the current context, and

    -  during an IDLE command.

 

    The NOTIFY command extends what information may be returned in those

    last two cases, and also permits and requires the server to send

    information about updates between command.  The NOTIFY command also

    allows for the client to extend what information is sent unsolicited

    about the selected mailbox, and to request some update information to

    be sent regarding other mailboxes.

 

    For the new messages delivered to or appended to the selected mailbox,

    The NOTIFY command can be used to request that a set of attributes be

    Sent to the client in an unsolicited FETCH response.  This allows a

    Client to be passive recipient of events and new mail, and be able to

    Maintain full synchonisation without having to issue any subsequent

    Commands except to modify the state of the mailbox on the server.

 

    Some mobile clients, however, may want mail "pushed" only for mail that

    matches a search pattern.  To meet that need [CONTEXT] is augmented by

    yhis draft to extend the UPDATE return option to specify a list of

    fetch-atts to be returned when a new message is delivered or appended

    in another context.

 

3.  The NOTIFY Command

 

    Arguments: "ADD" or "SET"

               Mailboxes to be watched

               Events about which to notify the client

 

    Or

    Arguments: "NONE"

 

    Responses: Possibly untagged STATUS responses (for ADD/SET)

 

    Result: OK The server will notify the client as requested.

            NO NOTIFY too complex or expensive, lack of permissions.

           BAD Command unknown, invalid, unsupported or unknown

               arguments.

 

    The NOTIFY command informs the server that the client listens for

    event notifications all the time (even when no command is in

    progress) and requests the server to notify it about the specified

    set of events for the selected mailbox or for specific mailboxes.

    The NOTIFY command has 3 forms. The NOTIFY NONE specifies that the

    client is not interested in any kind of event happening on the

    server. The NOTIFY ADD prepends one or more events to the list of

    events which are interesting to the client. The NOTIFY SET replaces

    the current list of interesting events with a new list of events.

    (Note that NOTIFY SET <events> is effectively the same as NOTIFY

    NONE followed by NOTIFY ADD <events>.)

 

    Until the NOTIFY command is used for the first time, the server only

    sends notifications while a command is being processed, and notifies

    the client about these events on the selected mailbox: (see section

    5 for definitions): MessageNew, MessageExpunge, FlagChange and (if

    [ANNOTATE] is being used) AnnotationChange. It does not notify the

    client about any events on other mailboxes.

 

    The effect of NOTIFY lasts until the next NOTIFY command, or until

    the IMAP connection is closed.

 

    The NOTIFY command can request notifications of changes to the

    selected mailbox whatever it may be at the time the notifications are

    being generated, specified by the SELECTED mailbox selector in the

    NOTIFY COMMAND.  It can also request notifications on other mailboxes

    by name or by a limited pattern match.  The notifications returned for

    the currently selected mailbox will be those specified by the SELECTED

    mailbox specifier, even if the selected mailbox also appears by name in

    the command.

 

    The information returned for message level changes to the SELECTED

    mailbox will be in the form of untagged FETCH, EXISTS, RECENT, EXPUNGE

    or VANISHED responses.  The information returned for message level

    changes to other mailboxes will be in the form a untagged STATUS

    responses.

 

    If the NOTIFY command enables MessageNew, MessageExpunge,

    AnnotationChange or FlagChange notification for a mailbox other than

    SELECTED, the server MUST send a STATUS response for that mailbox

    before NOTIFY's tagged OK. If MessageNew is enabled, the STATUS

    response MUST contain MESSAGES, UIDNEXT and UIDVALIDITY. If

    MessageExpunge is enabled, the STATUS response MUST contain MESSAGES.

    If either AnnotationChange or FlagChange are included, the STATUS

    response MUST contain UIDVALIDITY and HIGHESTMODSEQ.

 

    Clients are advised to limit the number of mailboxes used with

    NOTIFY. Particularly, if a client asks for events for all accessible

    mailboxes, the server may swamp the client with updates about shared

    mailboxes. This wastes both server resources and network traffic,

    and the client may have to pay for every byte.

 

    For each mailbox specified, the server verifies that the client has

    access using the following test:

 

    - If the name does not refer to a mailbox, the server MUST ignore

      it.

 

    - If the name refers to a mailbox which the client can't LIST, the

      server MUST ignore it. For a server that implements [RFC4314] this

      means that the client that doesn't have the 'l' (lookup) right for

 

 

 

King, et al.              Expires January 2008                FF[Page 3]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

      the name, it MUST ignore it.

 

    - If the name refers to a mailbox for which the client has 'l', but

      misses another required right, the server MUST respond with a

      tagged NO.  [[Alexey: I still think that ignoring such mailboxes

      would be better from security standpoint.]]

 

    If the notification would be prohibitively expensive for the server

    (e.g. "notify me of all flag changes in all mailboxes"), the server

    MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW]

    response.

 

    If the client requests information for events of an unsupported type

    (e.g. QuotaExceed and the server does not advertise the QUOTA

    extension defined in [RFC2087]), the server MUST refuse the command

    with a tagged BAD response.

 

    Here's an example:

 

         S: * OK [CAPABILITY IMAP4REV1 NOTIFY]

         C: a login bob alice

         S: a OK Password matched

         C: b notify set (selected MessageNew (uid

            body.peek[header.fields (from to subject)]) (all)

            MessageExpunge) (subtree Lists MessageNew (uid) (all))

         S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES

            500)

         S: [...]

         S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)

         S: b OK done

         C: c select inbox

         S: [...] (the usual 7-8 responses to SELECT)

         S: c OK INBOX selected

                (Time passes. A new message is delivered to mailbox

                 Lists/Lemonade.)

         S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000

            MESSAGES 501)

                (Time passes. A new message is delivered to inbox.)

         S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To

            Subject)] {75}

         S: Subject: Re: good morning

         S: From: alice@example.org

         S: To: bob@example.org

         S:

         S: )

                (Time passes. The client decides it wants to know about

                 one more mailbox.)

         C: d notify add (mailboxes misc MessageNew (uid) (all))

 

 

 

King, et al.              Expires January 2008                FF[Page 4]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

         S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)

                (This command enables notification on one mailbox and

                 otherwise changes nothing, so one STATUS response is

                 sent.)

         S: d OK done

 

 

4.  Interaction with the IDLE Command

 

    If IDLE (as well as this extension) is supported, the server should

    send MessageExpunge while processing IDLE, and otherwise send the

    same events as the client instructed using NOTIFY.

 

    NOTIFY makes IDLE unnecessary for some clients. If a client does not

    use MSNs and '*' in commands, it can request MessageExpunge and

    MessageNew for the selected mailbox using NOTIFY instead of entering

    IDLE mode.

 

 

5.  Event Types

 

    Only some of the events in [MSGEVENT] can be expressed in IMAP, and

    for some of them there are several possible ways to express the

    event.

 

    This section specifies the events of which an IMAP server can notify

    an IMAP client, and how.

 

    The server SHOULD omit notifying the client if the event is caused

    by this client. For example, if the client issues CREATE and has

    requested MailboxCreate event that would cover the newly created

    mailbox, the server SHOULD NOT notify the client of the

    MailboxCreate change.

 

    All event types require the 'l' and 'r' rights (see [RFC4314]) on

    all observed mailboxes. AdminMailbox and the quota-related event

    types additionally require the 'a' right.  Servers that don't

    implement [RFC4314] should map the above rights to their access

    control model.

 

    If the client instructs the server to not send MessageNew or

    MessageExpunge for the SELECTED mailbox, the server MUST send EXISTS

    and EXPUNGE responses as required by IMAP (see RFC3501 section 7).

    In other words, MessageNew instructs the server to notify the client

    immediately, and the lack of MessageNew instructs the server to

    notify the client during execution of the next command.

    MessageExpunge is similar.

 

 

 

 

King, et al.              Expires January 2008                FF[Page 5]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

5.1. FlagChange and AnnotationChange

 

    If the flag/annotation change happens in the SELECTED mailbox, the

    server notifies the client by sending an unsolicited FETCH response,

    which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY

    also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses.  If a

    search context is in effect as specified in [CONTEXT], an ESEARCH

    ADDTO or ESEARCH REMOVEFROM will also be generated if appropriate.

    In this case, the FETCH response will precede the ESEARCH response.

 

    If the change happens in another mailbox, then the response depends

    on whether CONDSTORE [RFC4551] is being used. If so, the server

    sends a STATUS (HIGHESTMODSEQ) response. (Note that whenever mailbox

    UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the

    STATUS response.)  If not, the server does not notify the client.

 

    FlagChange covers the MessageRead, MessageTrash, FlagsSet and

    FlagsClear events in [MSGEVENT].

 

    [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent

    for MessageRead. Arnt considers that unsound, since it involves

    processing all messages in a mailbox after an event affecting only

    one message, and since it's not reliable anyway.]]

 

    Example in the selected mailbox:

        S: * 99 FETCH (UID 9999 FLAGS ($Junk))

 

    And in another, with CONDSTORE in use:

        S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665)

 

 

5.2. MessageNew

 

    This covers both MessageNew and MessageAppend in [MSGEVENT].

 

    If the new/appended message is in the SELECTED mailbox, the server

    notifies the client by sending an unsolicited EXISTS response,

    followed by an unsolicited FETCH response containing the information

    requested by the client. A FETCH response will not be generated for

    a new message created in this context, for instance as the result of

    an APPEND or COPY command to the selected mailbox. The server MAY

    also send a RECENT response, if the server marks the message as \Recent.

 

    Note that a single EXISTS response can be returned for multiple

    MessageAppend/MessageNew events.

 

    If a search context is in effect as specified in [CONTEXT], an ESEARCH

    ADDTO will also be generated if appropriate. In this case, the EXISTS

    response will precede the ESEARCH response.  Both the NOTIFY command and

    the SEARCH and SORT commands can specify attributes to be returned for

    new messages.  These attributes MAY be combined into a single FETCH

    response.  The server SHOULD avoid sending duplicate data.  The FETCH

    response(s) SHOULD follow any ESEARCH ADDTO responses.

 

 

    If the new/appended message is in another mailbox, the server sends

    an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant

    mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the

    HIGHESTMODSEQ status data item MUST be included in the STATUS

    response.

 

    The client SHOULD NOT use FETCH attributes that implicitly set the

 

 

 

King, et al.              Expires January 2008                FF[Page 6]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

    \seen flag, or that presuppose the existence of a given bodypart.

    UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and

    BODY/BODYSTRUCTURE may be the most useful attributes. Whatever FETCH

    attributes are specified, the server SHOULD NOT set the \seen flag.

 

    Note that if a client asks to be notified of MessageNew events, the

    number of messages can increase at any time, and therefore the

    client cannot refer to a specific message using the MSN/UID '*'.

 

    Example in the selected mailbox:

        S: * 444 EXISTS

        S: * 444 FETCH (UID 9999)

 

    And in another, without CONDSTORE:

        S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)

 

 

5.3. MessageExpunge

 

    If the expunged message(s) is/are in the selected mailbox, the

    server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC]

    is being used).

 

    If the expunged message(s) is/are in another mailbox, the server

    sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the

    relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be

    included in the STATUS response.

 

    Note that if a client requests MessageExpunge, the meaning of an MSN

    can change at any time, so the client cannot use MSNs in commands

    any more. For example, such a client cannot use FETCH (it must only

    use UID FETCH). The meaning of '*' can also change when messages are

    added or expunged.

 

    The MessageExpunge notification covers both MessageExpunge and

    MessageExpire events from [MSGEVENT].

 

    Example in the selected mailbox, without QRESYNC:

        S: * 444 EXPUNGE

    The same example in the selected mailbox, with QRESYNC:

        S: * VANISHED 5444

    And in another:

        S: * STATUS misc (UIDNEXT 999 MESSAGES 554)

 

 

5.4. QuotaExceed, QuotaWithin and QuotaChange

 

    [[Alexey: I liked the following version more: If the client has

    permission to perform GETQUOTA (defined in [RFC2087]), the server

 

 

 

King, et al.              Expires January 2008                FF[Page 7]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

    sends an unsolicited QUOTA response containing the new quotas.  ]]

    The server sends an unsolicited QUOTA response containing the new

    quotas. The server also sends an unsolicited QUOTAROOT response, so

    that the client can correlate the affected mailbox to the quota

    root.

 

    These notifications are sent if the client has requested

    notifications for at least one affected mailbox.

 

    Example:

        S: * QUOTAROOT INBOX ""

        S: * QUOTA "" (STORAGE 10 512)

    In this example the quota root named "" (see [RFC2087] for the

    definition of quota root) governs the mailbox INBOX.  Note that the

    server may return the QUOTAROOT and the QUOTA response in any order.

 

 

5.5. MailboxCreate and MailboxDelete

 

    The server notifies the client by sending an unsolicited LIST

    responses for each affected mailbox name. If the mailbox name does

    not refer to a mailbox after the event, the \Nonexistent flag MUST

    be included.

 

    These notifications are sent if the client has requested

    notifications for at least one affected mailbox. In the case of

    MailboxCreate, the mailbox itself and its parent are considered to

    be affected. In the case of MailboxDelete, all deleted mailboxes and

    their parent(s) are considered to be affected.

 

    Example of a newly created mailbox:

        S: * LIST () "/" "NewMailbox"

 

    And a deleted mailbox:

        S: * LIST (\NoSelect) "/" "INBOX.DeletedMailbox"

 

 

5.6. MailboxRename

 

    For each selectable mailbox renamed, the server sends an extended

    LIST response [LISTEXT] for the new mailbox name, containing the

    OLDNAME extended data item with the old mailbox name.  When a

    mailbox is renamed, its children are renamed too.  No additional

    MailboxRename events are sent for children in this case.  When INBOX

    is renamed, a new INBOX is assumed to be created.  No MailboxCreate

    event must be sent for INBOX in this case.

 

    Example:

 

 

 

King, et al.              Expires January 2008                FF[Page 8]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

        S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))

 

 

5.7. SubscriptionChange

 

    The server notifies the client by sending an unsolicited LIST

    responses for each affected mailbox name. If and only if the mailbox

    is subscribed after the event, the \Subscribed attribute (see

    [LISTEXT]) is included.

 

    Example:

        S: * LIST (\Subscribed) "/" "SubscribedMailbox"

 

 

5.8. MailboxMetadataChange

 

    The server sends an unsolicited LIST response including METADATA. If

    possible, only the changed metadata should be included, but if

    necessary, all metadata must be included.

 

    Example:

        S: * LIST "/" "INBOX" (METADATA (/comment (value.priv "My

           comment")))

 

 

5.9. AdminMailbox

 

    If the user has the right to perform GETACL (see [RFC4314]) after

    the event, the server notifies the client by sending an unsolicited

    ACL response with the mailbox' new rights.

 

    If the user loses the right to perform GETACL as a result of this

    event, the server MAY also send the ACL response.

 

    In all other cases, the server does not notify the client.

 

    Example:

        S: * ACL INBOX Fred rwipslxcetda David lrswideta

 

 

5.10. Notification Overflow

 

    If the server is unable or unwilling to deliver as many

    notifications as it is being asked to, it may disable notifications

    for some or all clients.  It MUST notify these clients by sending an

    untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a

    NOTIFY NONE command had just been received.

 

 

 

 

King, et al.              Expires January 2008                FF[Page 9]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

    Example:

        S: * OK [NOTIFICATIONOVERFLOW] CPU overloaded, sorry

 

 

5.11. ACL Changes

 

    Even if NOTIFY succeeds, it is still possible to lose access to the

    mailboxes monitoried at a later time. If this happens, the server

    MUST silently stop monitoring these mailboxes. If access is later

    granted, the server MUST restart event monitoring.

 

    [[Open issue: This similar with the GETACL treatment in 5.9, which

    noone has complained about, but is it optimal?]]

 

 

6.  Mailbox Specification.

 

    Mailboxes to be monitored can be specified in several different

    ways.

 

    If the client specifies monitoring of the same mailbox several

    times, the first specification wins. A common example is asking for

    events on the selected mailbox and some named mailboxes.

 

    In this example, the client asks for MessageExpunge events for all

    personal mailboxes except the selected mailbox:

        C: a notify set (selected (MessageNew (uid flags) flagchange))

           (personal (MessageNew (uid flags) flagchange MessageExpunge))

 

 

6.1. Selected

 

    Selected refers to the mailbox selected using either SELECT or

    EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP

    connection is not in selected state, selected does not refer to any

    mailbox.

 

 

6.2. Personal

 

    Personal refers to all selectable mailboxes in the user's personal

    namespace(s).

 

 

6.3. Inboxes

 

    Inboxes refers to all selectable mailboxes in the user's personal

    namespace(s) to which messages may be delivered by an MDA (see

 

 

 

King, et al.              Expires January 2008               FF[Page 10]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

    [EMAIL-ARCH], particularly section 4.3.3).

 

    If the IMAP server cannot easily compute this set, it MUST treat

    "inboxes" as equivalent to "personal".

 

 

6.4 Subscribed

 

    Subscribed refers to all mailboxes subscribed by the user.

 

    If the subscription list changes, the list MUST be reevaluated.

 

 

6.5 Subtree

 

    Subtree is followed by a mailbox name or list of mailbox names.  A

    subtree refers to all selectable mailboxes which are subordinate to

    the specified mailbox plus the mailbox itself.

 

    [[Open Issue: Making this "all selectable mailboxes" makes it easy

    to implement this well. The pattern can be evaluated at NOTIFY time

    and notification information affixed to the mailboxes in RAM. Fine.

    But what about "notify me if any mailboxes are created whose name

    contains the letters xxx"? Not useful IMO...? (writes arnt)]]

 

 

6.6 Mailboxes

 

    Mailboxes is followed by a mailbox name or list of mailbox names.

    Note that the LIST wildcard characters ('*' and '%') are not treated

    specially in mailbox names.

 

8.  Search and Sort commands

 

    If the server supports CONTEXT=SEARCH or CONTEXT=SORT as defined in

    [CONTEXT], the UPDATE return option is extended to a client can

    request that FETCH attributes be returned when a new message is added

    to a result set.

 

    For example:

 

    C: a00 SEARCH RETURN (COUNT UPDATE (BODY[HEADER.FIELDS (TO FROM SUBJECT)]))

       FROM "boss"

    S: * ESEARCH (TAG "a00") (COUNT 17)

    S: a00 OK

     [a new message is delivered]

    S: * EXISTS 93

    S: * ESEARCH (TAG "a00") ADDTO (0 93)

    S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76}

    S: Subject: Re: good morning

    S: From: myboss@example.org

    S: To: bob@example.org

    S:

    S: )

 

    Note that the EXISTS response MUST precede the ESEARCH response, and the

    FETCH response SHOULD follow the ESEARCH response

 

7.  Formal Syntax

 

    The following syntax specification uses the Augmented Backus-Naur

    Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines

    the non-terminals "capability", "command-auth", "mailbox", "mailbox-

    data", "resp-text-code" and "search-key".

 

    Except as noted otherwise, all alphabetic characters are case-

    insensitive.  The use of upper or lower case characters to define

    token strings is for editorial clarity only.  Implementations MUST

    accept these strings in a case-insensitive fashion.

 

        capability      =/ "X-DRAFT-I07-NOTIFY"

                        ;; [[Note to RFC Editor: change the capability

 

 

 

King, et al.              Expires January 2008               FF[Page 11]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

                        ;; name before publication]]

 

        command-auth    =/ notify

 

        notify          = "NOTIFY" SP

                        (notify-add / notify-set / notify-none)

 

        notify-add      = "ADD" SP event-groups

                        ; Add (prepend) registered notification

                        ; events to the list of notification

                        ; events. Newer events override older

                        ; events.

                        [[Alexey: what about "most specific" event

                        overriding a pattern?]]

 

        notify-set      = "SET" SP event-groups

                        ; Replace registered notification events

                        ; with the specified list of events

 

        notify-none     = "NONE"

                        ; Cancel all registered notification

                        ; events. The client is not interested

                        ; in receiving any events.

 

        one-or-more-mailbox = mailbox / many-mailboxes

 

        many-mailboxes = "(" mailbox *(SP mailbox) ")"

 

        event-groups    = event-group *(SP event-group)

 

        event-group     = "(" filter-mailboxes SP events ")"

 

        filter-mailboxes = "selected" / "inboxes" / "personal" /

                        "subscribed" /

                        ( "subtree" SP one-or-more-mailbox ) /

                        ("mailboxes" SP one-or-more-mailbox)

 

        events          = ( "(" event *(SP event) ")" ) / "NONE"

                        ;; As in [MSGEVENT].

                        ;; "NONE" means that the client does not wish

                        ;; to receive any events for the specified

                        ;; mailboxes.

 

        event           = message-event

                        / mailbox-event / user-event / event-ext

 

        message-match-criteria = "(" search-key ")"

 

 

 

 

King, et al.              Expires January 2008               FF[Page 12]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

        message-event   = ( "MessageNew" [ SP

                            "(" fetch-att *(SP fetch-att) ")"

                          SP message-match-criteria ] )

                        / "MessageExpunge"

                        / "FlagChange" SP message-match-criteria

                        / "AnnotationChange" SP message-match-criteria

                        ;; "MessageNew" includes "MessageAppend" from

                        ;; [MSGEVENT]. "FlagChange" is any of

                        ;; "MessageRead", "MessageTrash", "FlagsSet",

                        ;; "FlagsClear" [MSGEVENT]. "MessageExpunge"

                        ;; includes "MessageExpire" [MSGEVENT].

                        ;; the fett-att list may only be present for the

                        ;; SELECTED mailbox filter

 

        mailbox-event   = "MailboxCreate" / "MailboxDelete" /

                        "MailboxRename" /

                        "SubscriptionChange" / "MailboxMetadataChange"

                        / "QuotaChange" / "AdminMailbox"

                        ; "SubscriptionChange" includes

                        ; MailboxSubscribe and MailboxUnSubscribe

 

        user-event      = "QuotaExceed" / "QuotaWithin"

 

        event-ext       = atom

                        ;; For future extensions

 

        oldname-extended-item =  "OLDNAME" SP "(" mailbox ")"

                        ;; Extended data item (mbox-list-extended-item)

                        ;; returned in a LIST response when a mailbox is

                        ;; renamed.

                        ;; Note 1: the OLDNAME tag can be returned

                        ;; with and without surrounding quotes, as per

                        ;; mbox-list-extended-item-tag production.

 

        resp-text-code  =/ "NOTIFICATIONOVERFLOW"

 

 

8.  Security considerations

 

    It is very easy for a client to deny itself service using NOTIFY:

    Asking for all events on all mailboxes may work on a small server,

    but with a big server can swamp the client's network connection or

    processing capability. In the worst case, the server's processing

    could also degrade the service it offers to other clients.

 

    Servers authors should be aware that if a client issues requests and

    does not listen to the resulting responses, the TCP window can

    easily fill up, and a careless server might block. This problem

    exists in plain IMAP, however this extension magnifies the problem.

 

 

 

 

King, et al.              Expires January 2008               FF[Page 13]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

    This extensions makes it possible to retrieve messages immediately

    when they are added to the mailbox. This makes it wholly impractical

    to delete sensitive messages using programs like imapfilter. Using

    [SIEVE] or similar is much better.

 

 

9.  IANA considerations

 

    The IANA is requested to add NOTIFY to the list of IMAP extensions,

    http://www.iana.org/assignments/imap4-capabilities.

 

    9.1.  Initial LIST-EXTENDED extended data item registrations

 

    It is requested that the following entry be added to the LIST-

    EXTENDED extended data item registry [LISTEXT]:

 

    To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED

    extended data item

 

    LIST-EXTENDED extended data item tag: OLDNAME

 

    LIST-EXTENDED extended data item description: The OLDNAME extended

    data item describes the old mailbox name for the mailbox identified

    by the LIST response.

 

    Which LIST-EXTENDED option(s) (and their types) causes this extended

    data item to be returned (if any): none

 

    Published specification : RFC XXXX, Section 5.6.

 

    Security considerations: none

 

    Intended usage: COMMON

 

    Person and email address to contact for further information:

      Alexey Melnikov <Alexey.Melnikov@isode.com>

 

    Owner/Change controller: iesg@ietf.org

 

 

10. Acknowedgements

 

    The authors gratefully acknowledge the help of Peter Coates, Dave

    Cridland, Mark Crispin, Cyrus Daboo and Abhijit Menon-Sen. Various

    example lines are copied from other RFCs.

 

    This document builds on one published and two unpublished drafts by

    the same authors.

 

 

 

King, et al.              Expires January 2008               FF[Page 14]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

11. Normative References

 

    [RFC2087]  Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997.

 

    [RFC2119]  Bradner, "Key words for use in RFCs to Indicate

               Requirement Levels", RFC 2119, Harvard University, March

               1997.

 

    [RFC2177]  Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997.

 

    [RFC3501]  Crispin, "Internet Message Access Protocol - Version

               4rev1", RFC 3501, University of Washington, June 2003.

 

    [RFC4234]  Crocker, Overell, "Augmented BNF for Syntax

               Specifications: ABNF", RFC 4234, Brandenburg

               Internetworking, Demon Internet Ltd, October 2005.

 

    [RFC4314]  Melnikov, "IMAP4 Access Control List (ACL) Extension",

               RFC 4314, December 2005.

 

    [RFC4466]  Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF",

               RFC 4466, Isode Ltd., April 2006.

 

    [RFC4551]  Melnikov, Hole, "IMAP Extension for Conditional STORE

               Operation or Quick Flag Changes Resynchronization", RFC

               4551, Isode Ltd., June 2006.

 

    [ANNOTATE] Gellens, Daboo, "IMAP ANNOTATE Extension", draft-ietf-

               imapext-annotate-16 (work in progress).

 

    [LISTEXT]  Leiba, Melnikov, "IMAP4 List Command Extensions", draft-

               ietf-imapext-list-extensions-18 (work in progress), IBM,

               September 2006.

 

    [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap-

               annotatemore-11 (work in progress), Apple Computer, Inc.,

               February 2007.

 

    [MSGEVENT] Newman, "Internet Message Store Events", draft-ietf-

               lemonade-msgevent-03.txt (work in progress), Sun, July

               2007.

 

 

12. Informative References

 

    [SIEVE]    Showalter, "Sieve: A Mail Filtering Language", RFC 3028,

               Mirapoint Inc, January 2001.

 

 

 

 

King, et al.              Expires January 2008               FF[Page 15]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

    [QRESYNC]  Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick

               Mailbox Resynchronization", draft-ietf-lemonade-

               reconnect-client-05.txt (work in progress), February

               2007.

 

    [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker-

               email-arch-09 (work in progress), March 2007.

 

 

13. Authors' Addresses

 

    Curtis King

    Isode Ltd

    5 Castle Business Village

    36 Station Road

    Hampton, Middlesex  TW12 2BX

    UK

 

    Email: Curtis.King@isode.com

 

 

    Alexey Melnikov

    Isode Ltd

    5 Castle Business Village

    36 Station Road

    Hampton, Middlesex  TW12 2BX

    UK

 

    Email: Alexey.Melnikov@isode.com

 

 

    Arnt Gulbrandsen

    Oryx Mail Systems GmbH

    Schweppermannstr. 8

    D-81671 Muenchen

    Germany

 

    Email: arnt@oryx.com

 

 

 

 

 

 

 

 

 

 

 

 

 

King, et al.              Expires January 2008               FF[Page 16]

 

 

 

 

 

Internet-draft                                                 July 2007

 

 

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.

 

 

Full Copyright Statement

 

    Copyright (C) The IETF Trust (2007).  This document is subject to

    the rights, licenses and restrictions contained in BCP 78, and

    except as set forth therein, the authors retain all their rights.

 

    This document and the information contained herein are provided on

    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE

    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE

    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL

    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY

    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE

    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS

    FOR A PARTICULAR PURPOSE.

 

 

Acknowledgment

 

    Funding for the RFC Editor function is currently provided by the

    Internet Society.

 

 

 

 

 

 

King, et al.              Expires January 2008               FF[Page 17]

 

 

 

--Boundary_(ID_PNAKDSgl6REkQAbQk2ij4g)-- --===============0609494861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0609494861==-- From lemonade-bounces@ietf.org Mon Dec 10 11:05:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1l8D-0000Dr-1L; Mon, 10 Dec 2007 11:05:21 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J1l8C-0000Dm-GX for lemonade-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 11:05:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1l8C-0000De-5x for lemonade@ietf.org; Mon, 10 Dec 2007 11:05:20 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1l8B-0007nR-Kw for lemonade@ietf.org; Mon, 10 Dec 2007 11:05:20 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Mon, 10 Dec 2007 16:05:06 +0000 Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis References: In-Reply-To: MIME-Version: 1.0 Message-Id: <11509.1197302700.706461@peirce.dave.cridland.net> Date: Mon, 10 Dec 2007 16:05:00 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Dec 6 15:10:09 2007, Eric Burger wrote: > The main purpose of WITHIN is to store a search pattern, e.g., "get > me mail > that is less than a day old" without having to calculate, upload, > re-parse, > and re-optimize search indices before doing the search. However, > it also > has what might be the desirable property of using relative times. > > Is that not of value? > > It depends... As things stand, no, since the client has to re-send the CONTEXT anyway. But it does mean that messages won't "drop out" of the context when they have aged sufficiently. > More importantly, will we run afoul of OMA requirements if we drop > WITHIN? > > Not as far as I can see. > What is the complex interaction? I missed it on the list. If we > refine > CONTEXT, would it provide the functionality required that drove us > to write > WITHIN in the first place? > > Even with all the hand-waving that we added to WITHIN to avoid the issue, it still changes CONTEXT from being event-driven to being time-driven as well. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 11 08:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25ai-0003cO-2H; Tue, 11 Dec 2007 08:56:08 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J25ah-0003c9-2P for lemonade-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 08:56:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25ag-0003c0-OI for lemonade@ietf.org; Tue, 11 Dec 2007 08:56:06 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J25af-0006C5-Um for lemonade@ietf.org; Tue, 11 Dec 2007 08:56:06 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 34FBB4AC71; Tue, 11 Dec 2007 14:56:05 +0100 (CET) Message-Id: Date: Tue, 11 Dec 2007 14:55:08 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis References: <11509.1197302700.706461@peirce.dave.cridland.net> In-Reply-To: <11509.1197302700.706461@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Thu Dec 6 15:10:09 2007, Eric Burger wrote: >> What is the complex interaction? I missed it on the list. If we >> refine CONTEXT, would it provide the functionality required that >> drove us to write WITHIN in the first place? > > Even with all the hand-waving that we added to WITHIN to avoid the > issue, it still changes CONTEXT from being event-driven to being > time-driven as well. For the server. For the client it's the other way. Without WITHIN, the client has to use BEFORE/SINCE, change the argument every so often and resend the context. And how often is "every so"? (Cue to repeat that long, long discussion ;) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 11 09:07:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25lt-0000i5-9k; Tue, 11 Dec 2007 09:07:41 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J25ls-0000hB-An for lemonade-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 09:07:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25ls-0000h3-0E for lemonade@ietf.org; Tue, 11 Dec 2007 09:07:40 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J25lr-0006Vi-CV for lemonade@ietf.org; Tue, 11 Dec 2007 09:07:39 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 11 Dec 2007 14:07:25 +0000 Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis References: <11509.1197302700.706461@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <11509.1197382042.295821@peirce.dave.cridland.net> Date: Tue, 11 Dec 2007 14:07:22 +0000 From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Dec 11 13:55:08 2007, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> On Thu Dec 6 15:10:09 2007, Eric Burger wrote: >>> What is the complex interaction? I missed it on the list. If we >>> refine CONTEXT, would it provide the functionality required that >>> drove us to write WITHIN in the first place? >> >> Even with all the hand-waving that we added to WITHIN to avoid the >> issue, it still changes CONTEXT from being event-driven to being >> time-driven as well. > > For the server. For the client it's the other way. Without WITHIN, > the client has to use BEFORE/SINCE, change the argument every so > often and resend the context. From a client's perspective, this is quite true - somewhere, if what you want to do is show messages within a certain timeframe (and typically you want YOUNGER), then filters need re-evaluating. However, I have yet to use WITHIN. My client does support it, as well as CONTEXT=SEARCH, but the only times I've used it are for testing. The actual purpose of WITHIN, it seems, is not to restrict the summary listing by time, but by volume, and PARTIAL manages this considerably more effectively - just grab the last X messages matching the filter, and if the user wants more, grab more, again with PARTIAL. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 11 19:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2FgM-0006pH-RH; Tue, 11 Dec 2007 19:42:38 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J2FgL-0006p0-2b for lemonade-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 19:42:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2FgK-0006os-Ma for lemonade@ietf.org; Tue, 11 Dec 2007 19:42:36 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2FgK-0006DW-5c for lemonade@ietf.org; Tue, 11 Dec 2007 19:42:36 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBC0gZou006775 for ; Wed, 12 Dec 2007 00:42:35 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSW00701V4FUI00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Tue, 11 Dec 2007 17:42:35 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSW00973VASA990@mail-amer.sun.com> for lemonade@ietf.org; Tue, 11 Dec 2007 17:42:29 -0700 (MST) Date: Tue, 11 Dec 2007 16:41:13 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <041101c83c57$b5bec9a0$213c5ce0$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acg8V7JDGUbODHuIReqj1z3R803TfQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [lemonade] CONVERT draft and headers 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="===============0884473402==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============0884473402== Content-type: multipart/alternative; boundary="Boundary_(ID_9Sg1+/M2gViP8S6z2iXTPQ)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_9Sg1+/M2gViP8S6z2iXTPQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT The CONVERT command gives clients with knowledge only of UTF-8 the ability to retrieve text message parts converted into UTF-8. But there is no mechanism for such clients to ask the server to deal with headers with weird encoded words. I propose that the CONVERT command be augmented so that commands of the form Xa convert 83 (NIL) body[header] Xb convert 83 (NIL) body[1.header] Have the expected result of returning the requested headers with encoded words replace with utf-8 encoded words. We could go further as support Xc convert 83 (NIL (charset foo)) body[header] But I see little point. WHY, you ask, am I suggestion replacing weird encoded words with UTF-8 encoded words rather than just returning the headers in UTF-8. Well, the answer is that encoded words occur in structured headers, and act as a quoting mechanism. It is hideously difficult to requite such a string correctly. Things like addresses in To: headers still need to be teased apart by clients, so the output of the convert has to be parsable. Please comment. The requirement to convert headers is obvious. That this is a solution is clear. That it is the best solution is not yet clear to me (although I have implemented it). Peter --Boundary_(ID_9Sg1+/M2gViP8S6z2iXTPQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

The CONVERT command gives clients with knowledge only of UTF-8 the ability to retrieve text message parts converted into UTF-8.  But there is no mechanism for such clients to ask the server to deal with headers with weird encoded words.  I propose that the CONVERT command be augmented so that commands of the form

 

Xa convert 83 (NIL) body[header]

Xb convert 83 (NIL) body[1.header]

 

Have the expected result of returning the requested headers with encoded words replace with utf-8 encoded words.

 

We could go further as support

Xc convert 83 (NIL (charset foo)) body[header]

 

But I see little point.

 

WHY, you ask, am I suggestion replacing weird encoded words with UTF-8 encoded words rather than just returning the headers in UTF-8.  Well, the answer is that encoded words occur in structured headers, and act as a quoting mechanism.  It is hideously difficult to requite such a string correctly.  Things like addresses in To: headers still need to be teased apart by clients, so the output of the convert has to be parsable.

 

Please comment.  The requirement to convert headers is obvious.  That this is a solution is clear.  That it is the best solution is not yet clear to me (although I have implemented it).

 

Peter

--Boundary_(ID_9Sg1+/M2gViP8S6z2iXTPQ)-- --===============0884473402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0884473402==-- From lemonade-bounces@ietf.org Tue Dec 11 23:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Izx-00039Z-Pi; Tue, 11 Dec 2007 23:15:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J2Izw-00039U-E4 for lemonade-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 23:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Izw-00039M-4H for lemonade@ietf.org; Tue, 11 Dec 2007 23:15:04 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Izs-0003jc-Ih for lemonade@ietf.org; Tue, 11 Dec 2007 23:15:04 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBC4F02t026577 for ; Wed, 12 Dec 2007 04:15:00 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00D0153EJ500@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Tue, 11 Dec 2007 21:15:00 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX004IR54T74D0@mail-amer.sun.com> for lemonade@ietf.org; Tue, 11 Dec 2007 21:14:59 -0700 (MST) Date: Tue, 11 Dec 2007 20:13:42 -0800 From: Peter Coates In-reply-to: To: lemonade@ietf.org Message-id: <001201c83c75$64efdaa0$2ecf8fe0$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acg8V7JDGUbODHuIReqj1z3R803TfQAHMwvA References: X-Spam-Score: -1.0 (-) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Subject: [lemonade] RE: CONVERT draft and headers 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="===============1083779249==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============1083779249== Content-type: multipart/alternative; boundary="Boundary_(ID_KdLAOGsxvuAZOiFK88YNew)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_KdLAOGsxvuAZOiFK88YNew) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Presumably convert body(header) should support RFC 2231 as well as RFC 2047. That is actually a much harder problem especially to handle the title*0*=us-ascii'en'This%20is%20even%20more%20 title*1*=%2A%2A%2Afun%2A%2A%2A%20 title*2="isn't it!" variant. In general these need putting together and taking apart again. We can not trust that there isn't a break in the middle of some escape sequence or some such foolishness. And when breaking the resulting UTF-8 into chunks, we ought to be careful not to repeat the foolishness by breaking UTF-8 is daft places. I believe that we should be processing 2047 encoded words wherever we find them, even if they are in places where there are not supposed to be encoded words: they were probably put there by a broken client. that is far more likely than something looking like an encoded word by accident. And there is the 2231 variant of 2047 encoded words to handle. But the 2231 parameters are more difficult. We should only look for then in the correct places: content-type and content-disposition fields (anywhere else?). Peter From: Peter Coates [mailto:peter.coates@sun.com] Sent: December 11, 2007 16:41 To: 'lemonade@ietf.org' Subject: CONVERT draft and headers The CONVERT command gives clients with knowledge only of UTF-8 the ability to retrieve text message parts converted into UTF-8. But there is no mechanism for such clients to ask the server to deal with headers with weird encoded words. I propose that the CONVERT command be augmented so that commands of the form Xa convert 83 (NIL) body[header] Xb convert 83 (NIL) body[1.header] Have the expected result of returning the requested headers with encoded words replace with utf-8 encoded words. We could go further as support Xc convert 83 (NIL (charset foo)) body[header] But I see little point. WHY, you ask, am I suggestion replacing weird encoded words with UTF-8 encoded words rather than just returning the headers in UTF-8. Well, the answer is that encoded words occur in structured headers, and act as a quoting mechanism. It is hideously difficult to requite such a string correctly. Things like addresses in To: headers still need to be teased apart by clients, so the output of the convert has to be parsable. Please comment. The requirement to convert headers is obvious. That this is a solution is clear. That it is the best solution is not yet clear to me (although I have implemented it). Peter --Boundary_(ID_KdLAOGsxvuAZOiFK88YNew) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Presumably convert body(header) should support RFC 2231 as well as RFC 2047.  That is actually a much harder problem especially to handle the

 

    title*0*=us-ascii'en'This%20is%20even%20more%20

    title*1*=%2A%2A%2Afun%2A%2A%2A%20

    title*2="isn't it!"

 

variant.  In general these need putting together and taking apart again.  We can not trust that there isn't a break in the middle of some escape sequence or some such foolishness.  And when breaking the resulting UTF-8 into chunks, we ought to be careful not to repeat the foolishness by breaking UTF-8 is daft places.

 

I believe that we should be processing 2047 encoded words wherever we find them, even if they are in places where there are not supposed to be encoded words: they were probably put there by a broken client… that is far more likely than something looking like an encoded word by accident.  And there is the 2231 variant of 2047 encoded words to handle.  But the 2231 parameters are more difficult.  We should only look for then in the correct places: content-type and content-disposition fields (anywhere else?).

 

Peter

 

From: Peter Coates [mailto:peter.coates@sun.com]
Sent: December 11, 2007 16:41
To: 'lemonade@ietf.org'
Subject: CONVERT draft and headers

 

The CONVERT command gives clients with knowledge only of UTF-8 the ability to retrieve text message parts converted into UTF-8.  But there is no mechanism for such clients to ask the server to deal with headers with weird encoded words.  I propose that the CONVERT command be augmented so that commands of the form

 

Xa convert 83 (NIL) body[header]

Xb convert 83 (NIL) body[1.header]

 

Have the expected result of returning the requested headers with encoded words replace with utf-8 encoded words.

 

We could go further as support

Xc convert 83 (NIL (charset foo)) body[header]

 

But I see little point.

 

WHY, you ask, am I suggestion replacing weird encoded words with UTF-8 encoded words rather than just returning the headers in UTF-8.  Well, the answer is that encoded words occur in structured headers, and act as a quoting mechanism.  It is hideously difficult to requite such a string correctly.  Things like addresses in To: headers still need to be teased apart by clients, so the output of the convert has to be parsable.

 

Please comment.  The requirement to convert headers is obvious.  That this is a solution is clear.  That it is the best solution is not yet clear to me (although I have implemented it).

 

Peter

--Boundary_(ID_KdLAOGsxvuAZOiFK88YNew)-- --===============1083779249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1083779249==-- From lemonade-bounces@ietf.org Fri Dec 14 07:26:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39cD-0000mP-Fr; Fri, 14 Dec 2007 07:26:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J39cB-0000m3-Du for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 07:26:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39cA-0000lj-SZ for lemonade@ietf.org; Fri, 14 Dec 2007 07:26:03 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J39cA-0004J1-9n for lemonade@ietf.org; Fri, 14 Dec 2007 07:26:02 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Dec 2007 12:25:58 +0000 Message-ID: <47620CAE.2090200@isode.com> Date: Fri, 14 Dec 2007 04:55:10 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Burger Subject: Re: [lemonade] Dis-ENABLEd Chair References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >I do not fully understand ENABLE, and from the nearly 50 messages on the >list, it is not clear that it is clear what it is for. > >For example, the text says the purpose of ENABLE is for the *client* to tell >the *server* the client can support some extensions. Think of it as push >CAPABILITIES ;-) > >Great. So now I do not understand any of the discussion about CAPABILITY. >For that matter, I do not understand the example in >draft-gulbrandsen-imap-enable-03. Namely, why is CONDSTORE not in the >initial CAPABILITY? I don't see anything in RFC 4551 that says, "keep this >a secret until the client logs in" or "keep this a secret until the client >ENABLEs condstore." > Indeed. I don't believe this behavior is described in RFC 3501 either, but in practice several servers "hide" some capabilities before authentication and list a full (or different) set of capabilities after authentication. Arguably, this is something that needs to be clarifier in 3501bis. [...] >I would offer that would end decisively the mystery of CAPABILITY values >coming and going (yes or no). Likewise, it would end decisively the >question of whether there is any value to the server returning BAD for a >capability that exists but is not available to the client. > I hope this particular issue is closed: server should never reject extensions that can't be enabled with BAD. >If the capability is not available to the client, it does not get listed to the >client in the CAPABILITY response. If it does not get listed, then the >client never even thinks of issuing an ENABLE, because the server has told >the client the server does not support the capability. > Several people have requested to allow ENABLE to be used in "dumb mode", i.e. the client just tries to ENABLE all extensions is supports unconditionally. This might save a roundtrip in some cases. This can also be used by clients to tell servers their capabilities, kind of CAPABILITY command in reverse. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 07:37:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39n6-0006Ib-8N; Fri, 14 Dec 2007 07:37:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J39n4-0006CG-9v for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 07:37:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39n3-0006C6-Uy for lemonade@ietf.org; Fri, 14 Dec 2007 07:37:18 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J39n3-0004dr-FE for lemonade@ietf.org; Fri, 14 Dec 2007 07:37:17 -0500 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBECbDfb021523; Fri, 14 Dec 2007 04:37:13 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBECbCrf023622; Fri, 14 Dec 2007 04:37:12 -0800 Received: from 10.43.242.21 ([10.43.242.21]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Dec 2007 12:37:11 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 14 Dec 2007 07:37:10 -0500 Subject: Re: [lemonade] Dis-ENABLEd Chair From: Eric Burger To: Message-ID: Thread-Topic: [lemonade] Dis-ENABLEd Chair Thread-Index: Acg5TpNs/C5U8qIBTXiiusezH3fnlAE/3f/e In-Reply-To: <6BBD3C565B5E4E8DB36996DF@dhcp-14db.ietf70.org> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Anyone have a problem including this (or similar) explanatory text in the document? Remember, implementers will be even more clueless than your Chairs. On 12/7/07 10:58 PM, "Cyrus Daboo" wrote: > Hi Eric, > > --On December 7, 2007 4:36:17 PM -0500 Eric Burger wrote: > >> Text describing *why* we do ENABLE and *how* it works would go a long way. > > One key reason: > > Some IMAP extensions allow the server to return unsolicited responses > specific to that extension in certain circumstances. However, servers > cannot send those unsolicited responses until they know that the clients > "know" about the extension and thus won't choke on the extension response > data. > > Up until now extensions have typically stated that a server cannot send the > unsolicited responses until after the client has used a command with the > extension data (i.e. at that point the server knows the client is aware of > the extension). This is somewhat awkward. > > What ENABLE does is provide an explicit indication from the client that it > supports a particular extension. As soon as it sees that the server knows > that extension response data for the enabled extensions is OK to send. > > I will leave it to someone else to explain the interaction with CAPABILITY. > > -- > Cyrus Daboo > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 12:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EEy-00042J-V6; Fri, 14 Dec 2007 12:22:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3EEx-0003to-Lb for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 12:22:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EEx-0003rD-8M for lemonade@ietf.org; Fri, 14 Dec 2007 12:22:23 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3EEv-0002sy-IE for lemonade@ietf.org; Fri, 14 Dec 2007 12:22:23 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBEHMLUt021844 for ; Fri, 14 Dec 2007 17:22:21 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT100G01UMW8K00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 14 Dec 2007 10:22:21 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT100H8VUX5TA30@mail-amer.sun.com>; Fri, 14 Dec 2007 10:22:19 -0700 (MST) Date: Fri, 14 Dec 2007 09:20:57 -0800 From: Peter Coates In-reply-to: To: "'Arnt Gulbrandsen'" Message-id: <002601c83e75$b1ebde60$15c39b20$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: Acg+UmQ82Dk10qlWTx2/myOBE+EkvQAIiHPw References: <03ce01c83c3d$90af0540$b20d0fc0$%coates@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: lemonade@ietf.org Subject: [lemonade] RE: notify X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org First , the principle of operation of our server is that there are potentially several variant views of a mailbox, one for each context that has it open. They synchronize with each command (up to a point...) So postulate that context 1 asks for newmessages only: C1: 1A NOTIFY (SELECTED ewmessages) S: ... S: 1A OK Then context 2 deleted and expunges a message C2: 2A STORE 2 +flags \deleted C2: 2B EXPUNGE S: ... S: * EXPUNGED 2 S: 2B OK Session 1 receives notification of the expunge, but ignores it until the next normal imap moment A new message is delivered. Session1 is informed of this, and wants to present information to the user. But the "real" version of the mailbox has a message expunged as well as a new message. It CAN NOT report the new message without also reporting the expunged message. Peter -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@oryx.com] Sent: December 14, 2007 05:07 To: Peter Coates Subject: Re: notify Peter Coates writes: > Arnt, > > I'm looking at implementing this, now that I've simplified it! > > And I have run into a problem. If something has happened to the > mailbox outside of my context, I have two versions of what is in the > mailbox: the one in my context, and the true one. I can ignore a > notification that a message has been expunged, if the user has not > asked for such notifications. But that change is in the "true" > version of the maibox. If after an expunge I get notification of new > mail, then I have two choices: either not report the new mail, or > report both the new mail and the expunge. I think I have to do the > first option, not report the new mail. Somehow this paragraph doesn't make sense to me. At all. Maybe I'm dense, but could you try again? > This requesting not to be told about expunges is a real pain. What > does it actually mean? It means do not report them except when you > would be told about them anyway. It means to not report them unsolicited. > I would to expand the words at the end of section 5 about this. It > currently reads: > ... > I would like to add to this: > > If a client specifies some but not all of MessageNew, MessageExpunge, > FlagChange, and AnnotationChange for the SELECTED mailbox, the server > MAY omit some of the requested notifications. Clients SHOULD specify > all or none of these event types. I don't like this... for example it makes sense to want new mail, but not care about flags. That's what my hobby client does, and in this respect I believe it behaves like a good lemonadish client should. (It's odd in various other ways, so I wouldn't argue that everything it does is worth consideration.) 1. It wants to be notified of mail immediately, even if no command is in progress, and wants the UID, From and Message-ID at once. I believe this is reasonable. 2. It doesn't want flag updates. Flag processing can be done on the server instead of fetching flags. For example, instead of showing unread messages by issuing "uid fetch 1:* flags" and categorising on the client, it asks the server to "uid search unseen", and when a new message or HIGHESTMODSEQ arrives, it updates the result with something like "uid search unseen changedsince x". Like CONTEXT, except implemented on the client. Maybe few clients will be like this, but it makes sense, and IMO it's not odd or perverted. Rather, it's how a good lemonadish client can behave, so it shows that one can reasonably want "some but not all of these event types". > I do not need AnnotationChange to be listed here, but someone might. > > I believe I also missed that it makes no sense to specify any event > types other than these four for SELECTED. I agree. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 13:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EvU-0005Hi-0W; Fri, 14 Dec 2007 13:06:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3EvS-0005Hd-Qc for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 13:06:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EvS-0005HV-Gt for lemonade@ietf.org; Fri, 14 Dec 2007 13:06:18 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3EvR-00041P-64 for lemonade@ietf.org; Fri, 14 Dec 2007 13:06:18 -0500 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lBEI6GQA023970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Dec 2007 13:06:16 -0500 Message-ID: <4762C607.6080604@andrew.cmu.edu> Date: Fri, 14 Dec 2007 13:05:59 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lemonade WG Subject: Re: [lemonade] Proposal to include draft-cridland-urlfetch-binary-00.txt into Lemonade Profile Bis References: <474AA9CC.7060309@isode.com> In-Reply-To: <474AA9CC.7060309@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83 X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov wrote: > In my capacity of an individual contributor: > Based on some discussions during the last Lemonade interop, I would like > to suggest that this document should be included into the Lemonade > Profile Bis. I've reviewed the document and I believe it is ready for > immediate Working Group Last Call. A couple of last call comments: - RFC 3516 restricts FETCH BINARY to 'section-part' (numeric-only parts), shouldn't URLFETCH BINARY do the same? Currently RFC 5092 allows all of 'section-spec'. - As stated by someone (Phil?) the last IETF meeting, I think an example should be included, probably containing both BINARY and BODYPARTSTRUCTURE. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 13:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Fip-0006Oj-PP; Fri, 14 Dec 2007 13:57:19 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3Fin-0006OR-NR for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 13:57:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Fin-0006Mi-CN for lemonade@ietf.org; Fri, 14 Dec 2007 13:57:17 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3Fin-00065N-3G for lemonade@ietf.org; Fri, 14 Dec 2007 13:57:17 -0500 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lBEIvG9b021978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Dec 2007 13:57:16 -0500 Message-ID: <4762D1FA.7020001@andrew.cmu.edu> Date: Fri, 14 Dec 2007 13:56:58 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.85 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] draft-gulbrandsen-imap-enable-04 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A couple of issues, all related to ENABLE now being allowed only in non-authenticated state. - Section 3.1, paragraph 6 (pipelining). The sentence discussing ENABLE before AUTHENTICATE should be removed. - Section 3.1, examples. Most of the example text discusses pre-authentication use of ENABLE. This has to be changed. - Section 5. Discusses pre-authenticated use of ENABLE. There probably are no security considerations at this point. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 14:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Fne-0005I3-DV; Fri, 14 Dec 2007 14:02:18 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3Fnd-0005Fi-DB for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 14:02:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Fnc-0005Fa-RT for lemonade@ietf.org; Fri, 14 Dec 2007 14:02:16 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3Fnc-0006DI-IR for lemonade@ietf.org; Fri, 14 Dec 2007 14:02:16 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id B5595DE8DC2; Fri, 14 Dec 2007 11:02:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 015B0185F1B; Fri, 14 Dec 2007 11:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dkc-yBYOfvC3; Fri, 14 Dec 2007 11:02:06 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 93CB4185CE5; Fri, 14 Dec 2007 11:02:06 -0800 (PST) Date: Fri, 14 Dec 2007 11:02:06 -0800 (PST) From: Dan Karp To: Ken Murchison Message-ID: <1968631179.215651197658926234.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <4762D1FA.7020001@andrew.cmu.edu> Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-04 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > A couple of issues, all related to ENABLE now being allowed only in > non-authenticated state. Really? ENABLE is now valid only in the NOT AUTHENTICATED state? Can someone publish a wrapup of the major changes decided on at the last IETF meeting? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 16:16:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HtI-0004RF-P5; Fri, 14 Dec 2007 16:16:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3HtH-0004KZ-5M for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 16:16:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HtG-0004KR-FO for lemonade@ietf.org; Fri, 14 Dec 2007 16:16:14 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3HtE-0001FN-7E for lemonade@ietf.org; Fri, 14 Dec 2007 16:16:14 -0500 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lBELGBqC023988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Dec 2007 16:16:11 -0500 Message-ID: <4762F289.9030808@andrew.cmu.edu> Date: Fri, 14 Dec 2007 16:15:53 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Karp Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-04 References: <1968631179.215651197658926234.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1968631179.215651197658926234.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83 X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >> A couple of issues, all related to ENABLE now being allowed only in >> non-authenticated state. > > Really? ENABLE is now valid only in the NOT AUTHENTICATED state? > > Can someone publish a wrapup of the major changes decided on at the last IETF meeting? Check out the jabbber log http://www.ietf.org/meetings/ietf-logs/lemonade/2007-12-06.html starting at 17:26:34 -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 16:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3IMI-0003kL-L1; Fri, 14 Dec 2007 16:46:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3IMI-0003kF-Bl for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 16:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3IMI-0003iB-13 for lemonade@ietf.org; Fri, 14 Dec 2007 16:46:14 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3IMH-00021u-MW for lemonade@ietf.org; Fri, 14 Dec 2007 16:46:14 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 162B6DE937A; Fri, 14 Dec 2007 13:46:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id EA007185F1C; Fri, 14 Dec 2007 13:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7T7Uc+VrC2u; Fri, 14 Dec 2007 13:46:05 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id B6DA9185F1A; Fri, 14 Dec 2007 13:46:05 -0800 (PST) Date: Fri, 14 Dec 2007 13:46:05 -0800 (PST) From: Dan Karp To: Ken Murchison Message-ID: <1458533651.249201197668765254.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <4762F289.9030808@andrew.cmu.edu> Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-04 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Dan Karp wrote: > >> A couple of issues, all related to ENABLE now being allowed only in > >> non-authenticated state. > > > > Really? ENABLE is now valid only in the NOT AUTHENTICATED state? > > > > Can someone publish a wrapup of the major changes decided on at the > > last IETF meeting? > > Check out the jabbber log > http://www.ietf.org/meetings/ietf-logs/lemonade/2007-12-06.html > starting at 17:26:34 Sure thing. But it says the opposite of what you said: [17:41:57] Alexey: consensus: [17:42:05] - enable is only allowed in auth state. [17:42:31] - client must not send enable if ever been in selected state, server does not have to check _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 14 18:32:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3K1X-00020f-8G; Fri, 14 Dec 2007 18:32:55 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3K1W-00020D-11 for lemonade-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 18:32:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3K1V-0001zk-My for lemonade@ietf.org; Fri, 14 Dec 2007 18:32:53 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3K1U-0004Bd-Cv for lemonade@ietf.org; Fri, 14 Dec 2007 18:32:53 -0500 Received: by nz-out-0506.google.com with SMTP id n1so741625nzf.4 for ; Fri, 14 Dec 2007 15:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=6+O/TzTy9KE0ZhD0/ya3+4kTPu9v7R0ErOxYjxlnMag=; b=sIhS6kQF+QNe0aSxcLMMJVvZVzpqP9tVweA93aLp6E60MxYFDdltg8uQbluqzxd6Kw0uX+8zqHkaWky0zq+fmBLxmVx62X18X83QS5lWoskFlCerdB8sEw1zwFFWH+uZMq9RQ+LhZNzT2KulXF2mcunu62O+/AFdba2+mLjX1cM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=EtUFE/iEj9TjJOJkGjV+9DLIPm49SDsIKJVN90NO4ySaVrb89uUmXreNAUP1SiZPMhYW4tCtpOH47XMnQPE3F5hizHz12tYmWDOpt67+ZFvPP157r9NQU1yESXZI6oJ5BsVCMy3GIHpUtmUciegtyOEHDOnlpBOHlaH/cOua79U= Received: by 10.142.242.8 with SMTP id p8mr1962369wfh.142.1197675171095; Fri, 14 Dec 2007 15:32:51 -0800 (PST) Received: by 10.143.121.7 with HTTP; Fri, 14 Dec 2007 15:32:51 -0800 (PST) Message-ID: <7ff232d10712141532h41c06474s575c3d37b28494f@mail.gmail.com> Date: Fri, 14 Dec 2007 17:32:51 -0600 From: "Nick Irelan" To: lemonade@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [lemonade] Mail Organization 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="===============1252555286==" Errors-To: lemonade-bounces@ietf.org --===============1252555286== Content-Type: multipart/alternative; boundary="----=_Part_1034_31095651.1197675171081" ------=_Part_1034_31095651.1197675171081 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would like to see the lemonade group focus on providing a standard way for clients to organize email. Information overload is a signifigant problem that has been recognized by the users of nearly all corperate email accounts. Today, users are forced to develop stratagies that help allow them to co-exist with the problem rather than face it. Is the group willing to develop new protocols to combat this problem? ------=_Part_1034_31095651.1197675171081 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would like to see the lemonade group focus on providing a standard way for clients to organize email. Information overload is a signifigant problem that has been recognized by the users of nearly all corperate email accounts. Today, users are forced to develop stratagies that help allow them to co-exist with the problem rather than face it. Is the group willing to develop new protocols to combat this problem? ------=_Part_1034_31095651.1197675171081-- --===============1252555286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1252555286==-- From lemonade-bounces@ietf.org Sat Dec 15 06:57:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Vdh-0006Ew-8c; Sat, 15 Dec 2007 06:57:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3Vdg-0006Er-43 for lemonade-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 06:57:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Vdf-0006Ej-QC for lemonade@ietf.org; Sat, 15 Dec 2007 06:57:03 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Vdf-0002Yz-3b for lemonade@ietf.org; Sat, 15 Dec 2007 06:57:03 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Sat, 15 Dec 2007 11:56:56 +0000 Subject: Re: [lemonade] Proposal to include draft-cridland-urlfetch-binary-00.txt into Lemonade Profile Bis References: <474AA9CC.7060309@isode.com> <4762C607.6080604@andrew.cmu.edu> In-Reply-To: <4762C607.6080604@andrew.cmu.edu> MIME-Version: 1.0 Message-Id: <11509.1197719812.870587@peirce.dave.cridland.net> Date: Sat, 15 Dec 2007 11:56:52 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Dec 14 18:05:59 2007, Ken Murchison wrote: > - RFC 3516 restricts FETCH BINARY to 'section-part' (numeric-only > parts), shouldn't URLFETCH BINARY do the same? Currently RFC 5092 > allows all of 'section-spec'. > > My immediate reaction to this was that Ken's right - but on more thought I wondered. The intention with this restriction in RFC3516 was to restrict the FETCH BINARY to leaf nodes, on the basis that a node can be known to be a leaf in advance by the client. I'm not sure that this is the case, here - in particular, I have a gut feeling that URLs should be - or can be - treated largely as an opaque string by the resolver. So if a client asks for the BINARY or - most especially - BODYPARTSTRUCTURE of a non-neaf node, that seems reasonable. Moreover, the client using the URLAUTH URL cannot simply choose to use "1" instead of "TEXT", yet a URL referring to TEXT is legal to generate. So thinking about this in the cold light of day, I think that section-spec is probably right. > - As stated by someone (Phil?) the last IETF meeting, I think an > example should be included, probably containing both BINARY and > BODYPARTSTRUCTURE. Indeed. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Dec 15 07:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3VjW-0001Sp-8w; Sat, 15 Dec 2007 07:03:06 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3VjV-0001Si-5J for lemonade-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 07:03:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3VjU-0001Sa-R8 for lemonade@ietf.org; Sat, 15 Dec 2007 07:03:04 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3VjU-0008N4-9B for lemonade@ietf.org; Sat, 15 Dec 2007 07:03:04 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Sat, 15 Dec 2007 12:02:49 +0000 Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-04 References: <1458533651.249201197668765254.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1458533651.249201197668765254.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <11509.1197720165.520449@peirce.dave.cridland.net> Date: Sat, 15 Dec 2007 12:02:45 +0000 From: Dave Cridland To: Dan Karp Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Dec 14 21:46:05 2007, Dan Karp wrote: > > Dan Karp wrote: > > >> A couple of issues, all related to ENABLE now being allowed > only in > > >> non-authenticated state. > > > > > Really? ENABLE is now valid only in the NOT AUTHENTICATED > state? > > > > > Can someone publish a wrapup of the major changes decided > on at the > > > last IETF meeting? > > > Check out the jabbber log > > http://www.ietf.org/meetings/ietf-logs/lemonade/2007-12-06.html > > starting at 17:26:34 > > Sure thing. But it says the opposite of what you said: > > [17:41:57] Alexey: consensus: > [17:42:05] - enable is only allowed in auth state. > [17:42:31] - client must not send enable if ever been > in selected state, server does not have to check Ken's first sentence appears to be a typo - I read it twice before realising. His points all only make sense with the position in the jabber log, that is, ENABLE is never used in non-authenticated state. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Dec 15 07:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Vjx-0002Um-KR; Sat, 15 Dec 2007 07:03:33 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3Vjv-0002CR-Rd for lemonade-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 07:03:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Vjv-00027M-CO for lemonade@ietf.org; Sat, 15 Dec 2007 07:03:31 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Vju-0002hx-PR for lemonade@ietf.org; Sat, 15 Dec 2007 07:03:31 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Sat, 15 Dec 2007 12:03:24 +0000 X-SMTP-Protocol-Errors: PIPELINING Subject: Re: [lemonade] Mail Organization References: <7ff232d10712141532h41c06474s575c3d37b28494f@mail.gmail.com> In-Reply-To: <7ff232d10712141532h41c06474s575c3d37b28494f@mail.gmail.com> MIME-Version: 1.0 Message-Id: <11509.1197720203.881872@peirce.dave.cridland.net> Date: Sat, 15 Dec 2007 12:03:23 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Dec 14 23:32:51 2007, Nick Irelan wrote: > I would like to see the lemonade group focus on providing a > standard way for > clients to organize email. Information overload is a signifigant > problem > that has been recognized by the users of nearly all corperate email > accounts. Today, users are forced to develop stratagies that help > allow them > to co-exist with the problem rather than face it. Is the group > willing to > develop new protocols to combat this problem? It's largely out of scope for Lemonade - I say largely, because information overload on a mobile phone is substantially worse than for a desktop, and so Lemonade has developed techniques for filtering mail - CONTEXT, WITHIN, etc. Similarly, IMAPEXT developed ANNOTATE (now experimental), and i18n support for IMAP, also directly applicable to this problem domain. However, there is a mailing list for this exact topic, called morg@ietf.org. The general intent is to examine the techniques we have now, and figure out what else is needed. FWIW, this list has been very quite recently, as the key players have been busy getting Lemonade out of the door, and I've been more than a bit slack about keeping discussion moving. I suggest you join that list, and read the archives, where there was a brief discussion at the beginning about the technologies we actually have already (which is quite a lot). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Dec 15 09:23:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XvV-0000au-2q; Sat, 15 Dec 2007 09:23:37 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3XvT-0000am-P8 for lemonade-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 09:23:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XvT-0000ad-Dn for lemonade@ietf.org; Sat, 15 Dec 2007 09:23:35 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3XvT-0003Py-1j for lemonade@ietf.org; Sat, 15 Dec 2007 09:23:35 -0500 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lBFENXDO022388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Dec 2007 09:23:33 -0500 Message-ID: <4763E34F.9080105@andrew.cmu.edu> Date: Sat, 15 Dec 2007 09:23:11 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dave Cridland , Dan Karp Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-04 References: <1458533651.249201197668765254.JavaMail.root@dogfood.zimbra.com> <11509.1197720165.520449@peirce.dave.cridland.net> In-Reply-To: <11509.1197720165.520449@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Fri Dec 14 21:46:05 2007, Dan Karp wrote: >> > Dan Karp wrote: >> > >> A couple of issues, all related to ENABLE now being allowed only in >> > >> non-authenticated state. >> > > > > Really? ENABLE is now valid only in the NOT AUTHENTICATED state? >> > > > > Can someone publish a wrapup of the major changes decided on >> at the >> > > last IETF meeting? >> > > Check out the jabbber log >> > http://www.ietf.org/meetings/ietf-logs/lemonade/2007-12-06.html >> > starting at 17:26:34 >> >> Sure thing. But it says the opposite of what you said: >> >> [17:41:57] Alexey: consensus: >> [17:42:05] - enable is only allowed in auth state. >> [17:42:31] - client must not send enable if ever been in >> selected state, server does not have to check > > Ken's first sentence appears to be a typo - I read it twice before > realising. His points all only make sense with the position in the > jabber log, that is, ENABLE is never used in non-authenticated state. Correct. It was certainly a typo, and it took me several readings before I realized my mistake. I originally wrote the sentence with a double negative (not allowed in not-auth) and decided to change it, but mistakenly only changed half. I guess that's what I get for trying to eat lunch at the same time. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 12:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3xks-0002u4-FF; Sun, 16 Dec 2007 12:58:22 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3xkr-0002ty-SC for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 12:58:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3xkr-0002tq-Ht for lemonade@ietf.org; Sun, 16 Dec 2007 12:58:21 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3xkr-0000XI-3M for lemonade@ietf.org; Sun, 16 Dec 2007 12:58:21 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 16 Dec 2007 17:58:19 +0000 Message-ID: <4765672F.6060308@isode.com> Date: Sun, 16 Dec 2007 17:58:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ken Murchison Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-04 References: <4762D1FA.7020001@andrew.cmu.edu> In-Reply-To: <4762D1FA.7020001@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Ken, Ken Murchison wrote: > A couple of issues, all related to ENABLE now being allowed only in > non-authenticated state. > > - Section 3.1, paragraph 6 (pipelining). The sentence discussing > ENABLE before AUTHENTICATE should be removed. Fixed (I've changed AUTHENTICATE to SELECT) > - Section 3.1, examples. Most of the example text discusses > pre-authentication use of ENABLE. This has to be changed. I've either removed or updated them. Thanks for spotting that. > - Section 5. Discusses pre-authenticated use of ENABLE. There > probably are no security considerations at this point. Removed, thanks. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 13:07:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3xtw-0007Eu-LC; Sun, 16 Dec 2007 13:07:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J3xtv-0007E7-C4 for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 13:07:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3xtu-00078Q-Rq for lemonade@ietf.org; Sun, 16 Dec 2007 13:07:42 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3xtu-0003c0-79 for lemonade@ietf.org; Sun, 16 Dec 2007 13:07:42 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 16 Dec 2007 18:06:09 +0000 Message-ID: <47656905.2080901@isode.com> Date: Sun, 16 Dec 2007 18:05:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Burger Subject: Re: [lemonade] Dis-ENABLEd Chair References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >Anyone have a problem including this (or similar) explanatory text in the >document? > >Remember, implementers will be even more clueless than your Chairs. > No objection from me. A reworded version of Cyrus' text will appear in -05. >On 12/7/07 10:58 PM, "Cyrus Daboo" wrote: > > >>Hi Eric, >> >>--On December 7, 2007 4:36:17 PM -0500 Eric Burger wrote: >> >> >>>Text describing *why* we do ENABLE and *how* it works would go a long way. >>> >>> >>One key reason: >> >>Some IMAP extensions allow the server to return unsolicited responses >>specific to that extension in certain circumstances. However, servers >>cannot send those unsolicited responses until they know that the clients >>"know" about the extension and thus won't choke on the extension response >>data. >> >>Up until now extensions have typically stated that a server cannot send the >>unsolicited responses until after the client has used a command with the >>extension data (i.e. at that point the server knows the client is aware of >>the extension). This is somewhat awkward. >> >>What ENABLE does is provide an explicit indication from the client that it >>supports a particular extension. As soon as it sees that the server knows >>that extension response data for the enabled extensions is OK to send. >> >>I will leave it to someone else to explain the interaction with CAPABILITY. >> >> _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40ig-0003Bl-SU; Sun, 16 Dec 2007 16:08:18 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J40if-0003Be-Ri for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 16:08:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40if-0003BL-GR for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:17 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J40if-0003DZ-1R for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:17 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL8BMc026413; Sun, 16 Dec 2007 13:08:11 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL87bS016467; Sun, 16 Dec 2007 13:08:09 -0800 Received: from 10.43.242.73 ([10.43.242.73]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 21:08:08 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 15 Dec 2007 10:15:24 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Profile-bis and IMAP Notifications Thread-Index: Acg/LVCyjxM19qsgEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Alexey Melnikov , St=?ISO-8859-1?B?6Q==?=phane Maes Subject: [lemonade] Profile-bis and IMAP Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org WITH CHAIR HAT OFF, just a member of the work group... Right now we say Lemonade Message Stores MUST support IDLE and is silent on NOTIFY. I would offer Lemonade Message Stores MUST support NOTIFY and MAY support IDLE. Mandating support for IDLE means IDLE lives forever, even if no one uses it in the future. If there are other reasons for servers to support IDLE, like no extant client today supports NOTIFY, then market forces will ensure Lemonade Message Stores will support IDLE for the time being. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40ie-0003B9-Ja; Sun, 16 Dec 2007 16:08:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J40id-0003Ap-NR for lemonade-confirm+ok@megatron.ietf.oFrom lemonade-bounces@ietf.org Sun Dec 16 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40ig-0003Bl-SU; Sun, 16 Dec 2007 16:08:18 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J40if-0003Be-Ri for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 16:08:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40if-0003BL-GR for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:17 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J40if-0003DZ-1R for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:17 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL8BMc026413; Sun, 16 Dec 2007 13:08:11 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL87bS016467; Sun, 16 Dec 2007 13:08:09 -0800 Received: from 10.43.242.73 ([10.43.242.73]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 21:08:08 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 15 Dec 2007 10:15:24 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Profile-bis and IMAP Notifications Thread-Index: Acg/LVCyjxM19qsgEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Alexey Melnikov , St=?ISO-8859-1?B?6Q==?=phane Maes Subject: [lemonade] Profile-bis and IMAP Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org WITH CHAIR HAT OFF, just a member of the work group... Right now we say Lemonade Message Stores MUST support IDLE and is silent on NOTIFY. I would offer Lemonade Message Stores MUST support NOTIFY and MAY support IDLE. Mandating support for IDLE means IDLE lives forever, even if no one uses it in the future. If there are other reasons for servers to support IDLE, like no extant client today supports NOTIFY, then market forces will ensure Lemonade Message Stores will support IDLE for the time being. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40ie-0003B9-Ja; Sun, 16 Dec 2007 16:08:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J40id-0003Ap-NR for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40id-0003Ae-Dj for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J40id-0002KS-0P for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL89Rf026402; Sun, 16 Dec 2007 13:08:09 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL87bQ016467; Sun, 16 Dec 2007 13:08:08 -0800 Received: from 10.43.242.73 ([10.43.242.73]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 21:08:07 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 15 Dec 2007 10:12:14 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Profile-bis and IMAP-COMPRESS Thread-Index: Acg/LN9yHkiQPKsgEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Alexey Melnikov , St=?ISO-8859-1?B?6Q==?=phane Maes Subject: [lemonade] Profile-bis and IMAP-COMPRESS X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ALL WITH CHAIR HAT OFF, I'm just an individual contributor here... Since we are two years late, is application-layer compression still a major issue? What is the Work Group's feelings if we change the conformance language in Section 5.2 from MUST support IMAP-COMPRESS to: However, the working group acknowledges that legacy endpoints rarely deployed TLS. Thus, while Lemonade Message Stores MUST support TLS with deflate, a Lemonade Message Store SHOULD provide [IMAP-COMPRESS] support for fall-back application-level stream compression. Three years from now, there is no reason to require a Lemonade server to support IMAP-COMPRESS. However, TLS needs to be there. Conversely, the *market* will drive current implementations to do IMAP-COMPRESS today, but will also alleviate that pain over time. No reason to leave donkey tracks if we do not have to. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade rg; Sun, 16 Dec 2007 16:08:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40id-0003Ae-Dj for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J40id-0002KS-0P for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL89Rf026402; Sun, 16 Dec 2007 13:08:09 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL87bQ016467; Sun, 16 Dec 2007 13:08:08 -0800 Received: from 10.43.242.73 ([10.43.242.73]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 21:08:07 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 15 Dec 2007 10:12:14 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Profile-bis and IMAP-COMPRESS Thread-Index: Acg/LN9yHkiQPKsgEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Alexey Melnikov , St=?ISO-8859-1?B?6Q==?=phane Maes Subject: [lemonade] Profile-bis and IMAP-COMPRESS X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ALL WITH CHAIR HAT OFF, I'm just an individual contributor here... Since we are two years late, is application-layer compression still a major issue? What is the Work Group's feelings if we change the conformance language in Section 5.2 from MUST support IMAP-COMPRESS to: However, the working group acknowledges that legacy endpoints rarely deployed TLS. Thus, while Lemonade Message Stores MUST support TLS with deflate, a Lemonade Message Store SHOULD provide [IMAP-COMPRESS] support for fall-back application-level stream compression. Three years from now, there is no reason to require a Lemonade server to support IMAP-COMPRESS. However, TLS needs to be there. Conversely, the *market* will drive current implementations to do IMAP-COMPRESS today, but will also alleviate that pain over time. No reason to leave donkey tracks if we do not have to. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40if-0003BU-Np; Sun, 16 Dec 2007 16:08:17 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J40ie-0003B4-7h for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 16:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40id-0003Av-UE for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J40id-0002Kb-HD for lemonade@ietf.org; Sun, 16 Dec 2007 16:08:15 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL8CTw026423; Sun, 16 Dec 2007 13:08:12 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGL87bU016467; Sun, 16 Dec 2007 13:08:11 -0800 Received: from 10.43.242.73 ([10.43.242.73]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 21:08:09 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 15 Dec 2007 10:20:33 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Profile-bis and Future Delivery Thread-Index: Acg/LgjfR01PgKshEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.6 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Gregory Vaudreuil , Alexey Melnikov , St=?ISO-8859-1?B?6Q==?=phane Maes Subject: [lemonade] Profile-bis and Future Delivery X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org WITH CHAIR HAT OFF, just a Work Group participant... We have been on-again / off-again on having Future Delivery in profile-bis. How does this language sound: We RECOMMEND Lemonade Message Stores implement Future Delivery. This relieves clients from the obligation to physically hold a message the user wishes to release at a later date. That way, there is a lemonade pointer to future delivery. The pointer is slightly stronger than MAY implement future delivery, as MAY says nothing. Moreover, the RECOMMEND grammatical construct (We RECOMMEND foo *because of* bar) explains why someone would want to use it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 16:38:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J41Br-0004TM-UF; Sun, 16 Dec 2007 16:38:27 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J41Bq-0004TG-CO for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 16:38:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J41Bq-0004T7-2a for lemonade@ietf.org; Sun, 16 Dec 2007 16:38:26 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J41Bo-0002sp-GZ for lemonade@ietf.org; Sun, 16 Dec 2007 16:38:26 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 16 Dec 2007 21:38:22 +0000 Message-ID: <47659AB5.4010504@isode.com> Date: Sun, 16 Dec 2007 21:37:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Burger References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, =?ISO-8859-1?Q?St=E9phane_Maes?= Subject: [lemonade] Re: Profile-bis and IMAP Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >WITH CHAIR HAT OFF, just a member of the work group... > >Right now we say Lemonade Message Stores MUST support IDLE and is silent on >NOTIFY. > >I would offer Lemonade Message Stores MUST support NOTIFY and MAY support >IDLE. > > Personally, this would be fine with me. However this would violate the implicit assumption that Profile Bis is a superset of Profile. Maybe you should poll the WG if people want to do that. >Mandating support for IDLE means IDLE lives forever, even if no one uses it >in the future. > >If there are other reasons for servers to support IDLE, like no extant >client today supports NOTIFY, then market forces will ensure Lemonade >Message Stores will support IDLE for the time being. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 18:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42fb-0001ox-Aa; Sun, 16 Dec 2007 18:13:15 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J42fZ-0001he-Rm for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 18:13:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42fZ-0001gB-Fw for lemonade@ietf.org; Sun, 16 Dec 2007 18:13:13 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J42fZ-00066P-1r for lemonade@ietf.org; Sun, 16 Dec 2007 18:13:13 -0500 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGNDBQv002108 for ; Sun, 16 Dec 2007 15:13:11 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGND9gI010419 for ; Sun, 16 Dec 2007 15:13:10 -0800 Received: from 10.43.242.163 ([10.43.242.163]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 23:13:09 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 16 Dec 2007 17:00:31 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Minutes posted Thread-Index: AchALxM1Ua1XrKwiEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [lemonade] Minutes posted X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Take a look and let us know if we missed or misinterpreted something. http://www3.ietf.org/proceedings/07dec/minutes/lemonade.txt Jabber log for correlation is at: http://www.ietf.org/meetings/ietf-logs/lemonade/2007-12-06.html Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Dec 16 18:13:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42fg-0002Jm-Ae; Sun, 16 Dec 2007 18:13:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J42ff-0002JF-Mx for lemonade-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 18:13:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42ff-0002Ht-48 for lemonade@ietf.org; Sun, 16 Dec 2007 18:13:19 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J42fb-0004Xp-OV for lemonade@ietf.org; Sun, 16 Dec 2007 18:13:19 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGNDEQB002125 for ; Sun, 16 Dec 2007 15:13:14 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBGNDCdP001711 for ; Sun, 16 Dec 2007 15:13:13 -0800 Received: from 10.43.242.163 ([10.43.242.163]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Dec 2007 23:13:12 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 16 Dec 2007 17:20:10 -0500 From: Eric Burger To: Message-ID: Thread-Topic: OMA Architecture Document Updates Thread-Index: AchAMdHzEMIdJKwlEdyt0AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [lemonade] OMA Architecture Document Updates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org We had sent a few questions to MEM, and they updated the AD, but forgot to tell us. The information is at the lemonade Liaisons page on the Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade/liaisons/liaisons.html Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 04:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CBk-0007to-21; Mon, 17 Dec 2007 04:23:04 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4CBh-0007ti-UV for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 04:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CBh-0007tZ-Kq for lemonade@ietf.org; Mon, 17 Dec 2007 04:23:01 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4CBf-0005Fe-Mu for lemonade@ietf.org; Mon, 17 Dec 2007 04:23:01 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CBB2A4AC7B; Mon, 17 Dec 2007 10:22:54 +0100 (CET) Message-Id: Date: Mon, 17 Dec 2007 10:21:13 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile-bis and IMAP Notifications References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Alexey Melnikov , =?iso-8859-1?q?St=E9phane?= Maes X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > WITH CHAIR HAT OFF, just a member of the work group... > > Right now we say Lemonade Message Stores MUST support IDLE and is > silent on NOTIFY. > > I would offer Lemonade Message Stores MUST support NOTIFY and MAY > support IDLE. > > Mandating support for IDLE means IDLE lives forever, even if no one > uses it in the future. > > If there are other reasons for servers to support IDLE, like no extant > client today supports NOTIFY, then market forces will ensure Lemonade > Message Stores will support IDLE for the time being. I submit that a) IDLE is easy for servers to implement, b) most extant servers have it already and c) we should have at least two good reasons before we make profile-bis anything other than strict superset of profile. So my vote is to keep IDLE. I may or may not change my vote if other things are taken out of profile-bis. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 04:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CCu-0008LX-0V; Mon, 17 Dec 2007 04:24:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4CCs-0008LR-5R for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 04:24:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CCr-0008LJ-RN for lemonade@ietf.org; Mon, 17 Dec 2007 04:24:13 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4CCr-0000TS-Ba for lemonade@ietf.org; Mon, 17 Dec 2007 04:24:13 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D6C634AC7C; Mon, 17 Dec 2007 10:24:10 +0100 (CET) Message-Id: Date: Mon, 17 Dec 2007 10:22:29 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile-bis and IMAP-COMPRESS References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Alexey Melnikov , =?iso-8859-1?q?St=E9phane?= Maes X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > Since we are two years late, is application-layer compression still a > major issue? What is the Work Group's feelings if we change the > conformance language in Section 5.2 from MUST support IMAP-COMPRESS > to: > > However, the working group acknowledges that legacy endpoints > rarely deployed TLS. Thus, while Lemonade Message Stores MUST > support TLS with deflate, a Lemonade Message Store SHOULD provide > [IMAP-COMPRESS] support for fall-back application-level stream > compression. I like that. > Three years from now, there is no reason to require a Lemonade server > to support IMAP-COMPRESS. And I hope you're right. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 04:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CHs-0000ln-Qi; Mon, 17 Dec 2007 04:29:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4CHr-0000l9-HS for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 04:29:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CHr-0000ks-7B for lemonade@ietf.org; Mon, 17 Dec 2007 04:29:23 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4CHq-0005MR-Pi for lemonade@ietf.org; Mon, 17 Dec 2007 04:29:23 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 99C574AC7B; Mon, 17 Dec 2007 10:29:20 +0100 (CET) Message-Id: Date: Mon, 17 Dec 2007 10:27:39 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile-bis and Future Delivery References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Alexey Melnikov , =?iso-8859-1?q?St=E9phane?= Maes , Gregory Vaudreuil X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > How does this language sound: > > We RECOMMEND Lemonade Message Stores implement Future Delivery. > This relieves clients from the obligation to physically hold a > message the user wishes to release at a later date. I like it. +1. (And I have a low-priority todo item floating around, to implement "resend the message in a week". That's a handy command to have when mail bounces with a quota-related error.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 09:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4HFN-0000Rc-BM; Mon, 17 Dec 2007 09:47:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4HFL-0000Jq-Bx for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 09:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4HFL-0000IM-18 for lemonade@ietf.org; Mon, 17 Dec 2007 09:47:07 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4HFK-0004ei-M1 for lemonade@ietf.org; Mon, 17 Dec 2007 09:47:07 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lBHEkEIn008350; Mon, 17 Dec 2007 08:46:58 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 08:46:56 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [lemonade] Profile-bis and Future Delivery Date: Mon, 17 Dec 2007 08:46:56 -0600 Message-ID: <89017B166CB7E140BA80577FF744AE19017C150F@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Profile-bis and Future Delivery Thread-Index: AchAj1ORcpHLnvQjSlioRW+k+iEILAAIdtvQ From: "Vaudreuil, Greg M \(Greg\)" To: "Arnt Gulbrandsen" , X-OriginalArrivalTime: 17 Dec 2007 14:46:56.0854 (UTC) FILETIME=[ABFBFF60:01C840BB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Alexey Melnikov , =?iso-8859-1?Q?St=E9phane_Maes?= X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Almost, message stores don't implement future delivery, the MSA does. Greg V. -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@oryx.com] Sent: Monday, December 17, 2007 4:28 AM To: lemonade@ietf.org Cc: Eric Burger; Alexey Melnikov; Vaudreuil, Greg M (Greg); St=E9phane Maes Subject: Re: [lemonade] Profile-bis and Future Delivery Eric Burger writes: > How does this language sound: > > We RECOMMEND Lemonade Message Stores implement Future Delivery.=20 > This relieves clients from the obligation to physically hold a=20 > message the user wishes to release at a later date. I like it. +1. (And I have a low-priority todo item floating around, to implement=20 "resend the message in a week". That's a handy command to have when=20 mail bounces with a quota-related error.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 11:47:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4J7V-0001yU-0W; Mon, 17 Dec 2007 11:47:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4J7U-0001xc-0y for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 11:47:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4J7T-0001wg-Lo for lemonade@ietf.org; Mon, 17 Dec 2007 11:47:07 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4J7T-00052T-1Y for lemonade@ietf.org; Mon, 17 Dec 2007 11:47:07 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 17 Dec 2007 16:46:56 +0000 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <16833.1197910002.686355@peirce.dave.cridland.net> Date: Mon, 17 Dec 2007 16:46:42 +0000 From: Dave Cridland To: Eric Burger Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , "Stephane H. Maes" Subject: [lemonade] Re: Profile-bis and IMAP-COMPRESS X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Dec 15 15:12:14 2007, Eric Burger wrote: > Since we are two years late, is application-layer compression still > a major > issue? I'm unaware of any changes to the situation, and as far as I can tell from a modicum of research (read: a very cursory look about), mobile devices still don't natively do TLS compression by default. > What is the Work Group's feelings if we change the conformance > language in Section 5.2 from MUST support IMAP-COMPRESS to: > > However, the working group acknowledges that legacy endpoints > rarely deployed TLS. Thus, while Lemonade Message Stores MUST > support TLS with deflate, a Lemonade Message Store SHOULD > provide [IMAP-COMPRESS] support for fall-back application-level > stream compression. > > Argh! SHOULD! See my other message. > Three years from now, there is no reason to require a Lemonade > server to > support IMAP-COMPRESS. However, TLS needs to be there. > Conversely, the > *market* will drive current implementations to do IMAP-COMPRESS > today, but > will also alleviate that pain over time. No reason to leave donkey > tracks > if we do not have to. > > In a conversation with Alexey, I came up with the following proposal: (16:22:49) dwd@jabber.org/Office: I think we ought to merely note that COMPRESS=DEFLATE, whilst mandatory for Lemonade Message Stores, is to be considered an interim measure, and may be deprecated in the future. Clients SHOULD use TLS-based compression wherever possible. In other words, we put clients "on notice" that this is not the future, but we also ensure that servers still implement it. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 11:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4J9j-0003bc-5Y; Mon, 17 Dec 2007 11:49:27 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4J9g-0003Z9-Ab for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 11:49:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4J9f-0003YF-B1 for lemonade@ietf.org; Mon, 17 Dec 2007 11:49:23 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4J9e-00057B-Q5 for lemonade@ietf.org; Mon, 17 Dec 2007 11:49:23 -0500 Received: from turner.dave.cridland.net (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (smtp internal) via TCP with ESMTP id ; Mon, 17 Dec 2007 16:49:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 77C72C4051; Mon, 17 Dec 2007 16:32:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net 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 Po23e1N0hSwt; Mon, 17 Dec 2007 16:32:05 +0000 (GMT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 04D34C404D; Mon, 17 Dec 2007 16:32:05 +0000 (GMT) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <16833.1197909125.019417@peirce.dave.cridland.net> Date: Mon, 17 Dec 2007 16:32:05 +0000 From: Dave Cridland To: Eric Burger Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , "Stephane H. Maes" Subject: [lemonade] Re: Profile-bis and IMAP Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Dec 15 15:15:24 2007, Eric Burger wrote: > Right now we say Lemonade Message Stores MUST support IDLE and is > silent on > NOTIFY. > > Indeed, and that's sane - a client which wants to use MSNs - a quite sensible option for various tasks - won't want to be notified about expunges except when it's ready for them, and IDLE provides an excellent method for telling the server when it can handle them, by dint of it being a long running command when expunge events may be sent. Perhaps in the future all clients will be written such that they use only UIDs, and use no MSNs at all, but this isn't how IMAP works now, and I'd be much happier to know that we really knew what we were talking about before we abandoned IDLE. > I would offer Lemonade Message Stores MUST support NOTIFY and MAY > support > IDLE. > > And I'd deeply uncomfortable about having optional parts of the specification at this stage - up until now, we have had a very clear policy on this - servers have a list of mandatory features, clients have a set of SHOULDs above the base specifications. Before introducing optional portions of the profile for servers, I'd want a clear consensus to be reached that this, in itself, is a good idea. I also agree with the backwards compatibility arguments, so that's three nails in the coffin for this proposal, from where I'm sitting. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 11:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JAL-0005ar-3n; Mon, 17 Dec 2007 11:50:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4JAK-0005ZW-ET for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 11:50:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JAJ-0005Tq-Vq for lemonade@ietf.org; Mon, 17 Dec 2007 11:50:04 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4JAJ-00058r-FZ for lemonade@ietf.org; Mon, 17 Dec 2007 11:50:03 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 17 Dec 2007 16:49:59 +0000 X-SMTP-Protocol-Errors: PIPELINING References: In-Reply-To: MIME-Version: 1.0 Message-Id: <16833.1197910193.123965@peirce.dave.cridland.net> Date: Mon, 17 Dec 2007 16:49:53 +0000 From: Dave Cridland To: Eric Burger Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , "Stephane H. Maes" Subject: [lemonade] Re: Profile-bis and IMAP Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Dec 15 15:15:24 2007, Eric Burger wrote: > Right now we say Lemonade Message Stores MUST support IDLE and is > silent on > NOTIFY. > > Indeed, and that's sane - a client which wants to use MSNs - a quite sensible option for various tasks - won't want to be notified about expunges except when it's ready for them, and IDLE provides an excellent method for telling the server when it can handle them, by dint of it being a long running command when expunge events may be sent. Perhaps in the future all clients will be written such that they use only UIDs, and use no MSNs at all, but this isn't how IMAP works now, and I'd be much happier to know that we really knew what we were talking about before we abandoned IDLE. > I would offer Lemonade Message Stores MUST support NOTIFY and MAY > support > IDLE. > > And I'd deeply uncomfortable about having optional parts of the specification at this stage - up until now, we have had a very clear policy on this - servers have a list of mandatory features, clients have a set of SHOULDs above the base specifications. Before introducing optional portions of the profile for servers, I'd want a clear consensus to be reached that this, in itself, is a good idea. I also agree with the backwards compatibility arguments, so that's three nails in the coffin for this proposal, from where I'm sitting. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 12:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JS0-0005Pi-7g; Mon, 17 Dec 2007 12:08:20 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4JRy-0005PZ-Oe for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 12:08:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JRy-0005PR-Ez for lemonade@ietf.org; Mon, 17 Dec 2007 12:08:18 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4JRw-0008Cs-UA for lemonade@ietf.org; Mon, 17 Dec 2007 12:08:18 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBHH8Bgj031832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Dec 2007 09:08:11 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBHH8ADP025511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Dec 2007 09:08:11 -0800 Date: Mon, 17 Dec 2007 09:08:09 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Re: Profile-bis and IMAP Notifications In-Reply-To: <16833.1197909125.019417@peirce.dave.cridland.net> Message-ID: References: <16833.1197909125.019417@peirce.dave.cridland.net> User-Agent: Alpine 1.00 (OSX 873 2007-12-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.17.84633 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_500_599 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Enhancements to Internet email to support diverse service enivronments , "Stephane H. Maes" , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 17 Dec 2007, Dave Cridland wrote: > Perhaps in the future all clients will be written such that they use only > UIDs, and use no MSNs at all, but this isn't how IMAP works now, and I'd be > much happier to know that we really knew what we were talking about before we > abandoned IDLE. I hope that such a thing never happens. Appropriate use of MSNs is key to using IMAP effectively. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 13:53:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4L5X-00018H-CG; Mon, 17 Dec 2007 13:53:15 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4L5V-00014n-P5 for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 13:53:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4L5V-00014W-Ee for lemonade@ietf.org; Mon, 17 Dec 2007 13:53:13 -0500 Received: from ironportdmz5.qualcomm.com ([199.106.114.254] helo=wolverine01.qualcomm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4L5T-0004qN-RM for lemonade@ietf.org; Mon, 17 Dec 2007 13:53:13 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:Date:To:From:Subject:Cc: Content-Type; b=hRIzxbWCxfM3guuWPyrsg7RjlZybl3vUyLUG7ooL12gdlJizbf9Ve45K dVGWCSuUSvZNPtMYZBB1S9dgd5hwdIvmpX4iR7A7Ua9pcE/ab7Fnt5NBE fOwQInFDpmV8HPn4J/WFpYvSbVGy5+2mq3V1rLkmLvKk0SVR3zFV8ctZO A=; X-IronPort-AV: E=McAfee;i="5100,188,5187"; a="163044" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2007 10:53:11 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lBHIrA7M017211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Dec 2007 10:53:10 -0800 Received: from [76.126.60.89] (carbuncle.qualcomm.com [129.46.226.27]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lBHIr71i026119; Mon, 17 Dec 2007 10:53:08 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <47659AB5.4010504@isode.com> References: <47659AB5.4010504@isode.com> Date: Mon, 17 Dec 2007 10:53:11 -0800 To: Alexey Melnikov , Eric Burger From: Ted Hardie Subject: [lemonade] Re: Profile-bis and IMAP Notifications Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, =?iso-8859-1?Q?St=E9phane_Maes?= X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:37 PM +0000 12/16/07, Alexey Melnikov wrote: >> >Personally, this would be fine with me. However this would violate the implicit assumption that Profile Bis is a superset of Profile. >Maybe you should poll the WG if people want to do that. Is this just an implicit assumption? I thought that the working group's discussions with OMA had pretty much said that the profile-bis would be a superset of profile. I just checked my email copies of some of the liaison statements, and it doesn't seem to be said quite as clearly as that in those, so I may be confused. But it might be worth informally confirming that this assumption change won't cause heartburn there. regards, Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 14:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4M1X-0004vp-Mt; Mon, 17 Dec 2007 14:53:11 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4M1W-0004lt-8j for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:53:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4M1V-0004jU-TR for lemonade@ietf.org; Mon, 17 Dec 2007 14:53:09 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4M1V-0005ld-BV for lemonade@ietf.org; Mon, 17 Dec 2007 14:53:09 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 17 Dec 2007 19:53:07 +0000 Message-ID: <4766D39D.8020507@isode.com> Date: Mon, 17 Dec 2007 19:53:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Coates Subject: Re: [lemonade] CONVERT draft and headers References: <041101c83c57$b5bec9a0$213c5ce0$%coates@sun.com> In-Reply-To: <041101c83c57$b5bec9a0$213c5ce0$%coates@sun.com> 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Peter, We've already reached an agreement on this during our private discussion, the following reply is mostly for the sake of other WG participants. Peter Coates wrote: > The CONVERT command gives clients with knowledge only of UTF-8 the > ability to retrieve text message parts converted into UTF-8. But > there is no mechanism for such clients to ask the server to deal with > headers with weird encoded words. I propose that the CONVERT command > be augmented so that commands of the form > > > > Xa convert 83 (NIL) body[header] > > Xb convert 83 (NIL) body[1.header] > > > > Have the expected result of returning the requested headers with > encoded words replace with utf-8 encoded words. > > > > We could go further as support > > Xc convert 83 (NIL (charset foo)) body[header] > > > > But I see little point. > > > > WHY, you ask, am I suggestion replacing weird encoded words with UTF-8 > encoded words rather than just returning the headers in UTF-8. Well, > the answer is that encoded words occur in structured headers, and act > as a quoting mechanism. It is hideously difficult to requite such a > string correctly. Things like addresses in To: headers still need to > be teased apart by clients, so the output of the convert has to be > parsable. > While I am not entirely happy that the result needs to be re-encoded using encoded words (as this would still require that Lemonade clients understand RFC 2047), the only other alternative is to reference EAI work. However EAI message format is going to be experimental and we will have some practical difficulties normatively referencing an Experimental document from a Standard Track document. > Please comment. The requirement to convert headers is obvious. That > this is a solution is clear. That it is the best solution is not yet > clear to me (although I have implemented it). > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 14:59:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4M7n-0007j1-Iv; Mon, 17 Dec 2007 14:59:39 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4M7l-0007iv-Jd for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:59:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4M7l-0007in-8S for lemonade@ietf.org; Mon, 17 Dec 2007 14:59:37 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4M7k-0005y6-GI for lemonade@ietf.org; Mon, 17 Dec 2007 14:59:37 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBHJxaAN004394 for ; Mon, 17 Dec 2007 19:59:36 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT700601LYC7A00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 17 Dec 2007 12:59:35 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT700427M6X2D40@mail-amer.sun.com>; Mon, 17 Dec 2007 12:59:23 -0700 (MST) Date: Mon, 17 Dec 2007 11:59:09 -0800 From: Peter Coates Subject: RE: [lemonade] CONVERT draft and headers In-reply-to: <4766D39D.8020507@isode.com> To: "'Alexey Melnikov'" Message-id: <000901c840e7$4abb21a0$e03164e0$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: AchA5n6Osn+aQpAzToqbmMUjCLZd7wAAHCUw References: <041101c83c57$b5bec9a0$213c5ce0$%coates@sun.com> <4766D39D.8020507@isode.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The proposed new forms of the convert command are actually more like 1 convert 83 (NIL (charset "utf-8")) body[header] 1 convert 83 (NIL (charset "utf-8")) body[1.header] 1 convert 83 (NIL (charset "utf-8")) body[1.mime] Peter -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: December 17, 2007 11:53 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] CONVERT draft and headers Peter, We've already reached an agreement on this during our private discussion, the following reply is mostly for the sake of other WG participants. Peter Coates wrote: > The CONVERT command gives clients with knowledge only of UTF-8 the > ability to retrieve text message parts converted into UTF-8. But > there is no mechanism for such clients to ask the server to deal with > headers with weird encoded words. I propose that the CONVERT command > be augmented so that commands of the form > > > > Xa convert 83 (NIL) body[header] > > Xb convert 83 (NIL) body[1.header] > > > > Have the expected result of returning the requested headers with > encoded words replace with utf-8 encoded words. > > > > We could go further as support > > Xc convert 83 (NIL (charset foo)) body[header] > > > > But I see little point. > > > > WHY, you ask, am I suggestion replacing weird encoded words with UTF-8 > encoded words rather than just returning the headers in UTF-8. Well, > the answer is that encoded words occur in structured headers, and act > as a quoting mechanism. It is hideously difficult to requite such a > string correctly. Things like addresses in To: headers still need to > be teased apart by clients, so the output of the convert has to be > parsable. > While I am not entirely happy that the result needs to be re-encoded using encoded words (as this would still require that Lemonade clients understand RFC 2047), the only other alternative is to reference EAI work. However EAI message format is going to be experimental and we will have some practical difficulties normatively referencing an Experimental document from a Standard Track document. > Please comment. The requirement to convert headers is obvious. That > this is a solution is clear. That it is the best solution is not yet > clear to me (although I have implemented it). > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 17 15:36:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MhD-0000DY-VY; Mon, 17 Dec 2007 15:36:15 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4MhD-0000CN-5K for lemonade-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 15:36:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MhC-0000CF-Ru for lemonade@ietf.org; Mon, 17 Dec 2007 15:36:14 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4MhA-0008JR-WD for lemonade@ietf.org; Mon, 17 Dec 2007 15:36:14 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E53B14AC73; Mon, 17 Dec 2007 21:36:09 +0100 (CET) Message-Id: Date: Mon, 17 Dec 2007 21:34:25 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: Profile-bis and IMAP Notifications References: <16833.1197909125.019417@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Alexey Melnikov , Dave, Mark Crispin , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > On Mon, 17 Dec 2007, Dave Cridland wrote: >> Perhaps in the future all clients will be written such that they use >> only UIDs, and use no MSNs at all, but this isn't how IMAP works >> now, and I'd be much happier to know that we really knew what we >> were talking about before we abandoned IDLE. > > I hope that such a thing never happens. Appropriate use of MSNs is > key to using IMAP effectively. I used to think so too, but then I rewrote my hobby client to never go out of its way to obtain an MSN (although it remembers them when it receives some), and found that it was an improvement in terms of round trips and bytes sent/received. The main problem is that if I get an EXPUNGE and don't know the UID, I may noeed to mark many messages in the client's cache as "possibly gone, verify with UID FETCH UID before using". That turns out to happen very seldom. The similar problem with flag updates is also small in practice. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 10:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eNd-0005Mj-NJ; Tue, 18 Dec 2007 10:29:13 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4eNd-0005Me-AB for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 10:29:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eNc-0005MU-Vl for lemonade@ietf.org; Tue, 18 Dec 2007 10:29:13 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4eNc-0006Yh-BL for lemonade@ietf.org; Tue, 18 Dec 2007 10:29:12 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D24F04AC73; Tue, 18 Dec 2007 16:29:08 +0100 (CET) Message-Id: Date: Tue, 18 Dec 2007 16:27:18 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <03ce01c83c3d$90af0540$b20d0fc0$%coates@sun.com> <002601c83e75$b1ebde60$15c39b20$%coates@sun.com> In-Reply-To: <002601c83e75$b1ebde60$15c39b20$%coates@sun.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Peter Coates Subject: [lemonade] Re: notify X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Peter Coates writes: > First , the principle of operation of our server is that there are > potentially several variant views of a mailbox, one for each context > that has it open. They synchronize with each command (up to a > point...) > > So postulate that context 1 asks for newmessages only: > > C1: 1A NOTIFY (SELECTED ewmessages) > S: ... > S: 1A OK > > Then context 2 deleted and expunges a message > > C2: 2A STORE 2 +flags \deleted > C2: 2B EXPUNGE > S: ... > S: * EXPUNGED 2 > S: 2B OK > > Session 1 receives notification of the expunge, but ignores it until the > next normal imap moment > > A new message is delivered. Session1 is informed of this, and wants to > present information to the user. But the "real" version of the > mailbox has a message expunged as well as a new message. It CAN NOT > report the new message without also reporting the expunged message. Why not? I do basically the same thing and don't have this problem. If the expunge cannot be sent, it just isn't. When it can be sent, it is. Each time I look at what I can send, the code does something like this: if the set of unreported expunged messages is nonempty if expunges can and should be sent now send the expunges, adjust the MSN-UID map, clear the set if the set of messages with unreported flag updates is nonempty if flag updates can and should be sent now send the updates, clear the set if the set of new messages is nonempty ... you get the idea Perhaps I'm misunderstanding you, or perhaps there is some subtle point that divides our two implementations. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 11:46:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fZi-0001U9-Eq; Tue, 18 Dec 2007 11:45:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4fZh-0001U3-9s for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 11:45:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fZh-0001Lw-02 for lemonade@ietf.org; Tue, 18 Dec 2007 11:45:45 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4fZS-0003zw-V4 for lemonade@ietf.org; Tue, 18 Dec 2007 11:45:40 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBIGj9jZ012333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2007 08:45:09 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBIGj7ea026684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Dec 2007 08:45:09 -0800 Date: Tue, 18 Dec 2007 08:45:07 -0800 (PST) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: notify In-Reply-To: Message-ID: References: <03ce01c83c3d$90af0540$b20d0fc0$%coates@sun.com> <002601c83e75$b1ebde60$15c39b20$%coates@sun.com> User-Agent: Alpine 1.00 (OSX 873 2007-12-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.18.82434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 18 Dec 2007, Arnt Gulbrandsen wrote: >> A new message is delivered. Session1 is informed of this, and wants to >> present information to the user. But the "real" version of the mailbox has >> a message expunged as well as a new message. It CAN NOT report the new >> message without also reporting the expunged message. > Why not? > I do basically the same thing and don't have this problem. If the expunge > cannot be sent, it just isn't. When it can be sent, it is. I don't have this problem either. Expunge announcement is separate from new mail announcement. In my mail stores, expunge message space is only recovered at an exclusive-access point. So shared expunge just makes the message become invisible in the sessions which have reported the expunge (or new sessions), at which point it is easy to implement the ideal IMAP semantics for expunge. Later space reclamation is a cleanup operation. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 13:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hDQ-0002QL-UY; Tue, 18 Dec 2007 13:30:52 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4hDP-0002QF-D9 for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 13:30:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hDP-0002Q7-1r for lemonade@ietf.org; Tue, 18 Dec 2007 13:30:51 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4hDN-0006Qh-TT for lemonade@ietf.org; Tue, 18 Dec 2007 13:30:50 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBIIUl4g010147 for ; Tue, 18 Dec 2007 18:30:47 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT9000019LJHD00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Tue, 18 Dec 2007 11:30:47 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT9003ZZCQ84920@mail-amer.sun.com>; Tue, 18 Dec 2007 11:30:12 -0700 (MST) Date: Tue, 18 Dec 2007 10:29:52 -0800 From: Peter Coates In-reply-to: To: "'Arnt Gulbrandsen'" , lemonade@ietf.org Message-id: <00ea01c841a3$fd5a3000$f80e9000$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: AchBissr+JncXOagS1SrqitNrXhQPQAFTCTA References: <03ce01c83c3d$90af0540$b20d0fc0$%coates@sun.com> <002601c83e75$b1ebde60$15c39b20$%coates@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [lemonade] RE: notify X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The problem is the "index file", which holds some information about each message. This is a contiguous array of records. If a message is deleted, the file is rewritten from that point on. When a context resynchronises, it rereads this file and that becomes its index into the mailbox. If I fail to report a deleted message, my index is wrong. Changing this would be close to a rewrite. Peter -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@oryx.com] Sent: December 18, 2007 07:27 To: lemonade@ietf.org Cc: Peter Coates Subject: Re: notify Peter Coates writes: > First , the principle of operation of our server is that there are > potentially several variant views of a mailbox, one for each context > that has it open. They synchronize with each command (up to a > point...) > > So postulate that context 1 asks for newmessages only: > > C1: 1A NOTIFY (SELECTED ewmessages) > S: ... > S: 1A OK > > Then context 2 deleted and expunges a message > > C2: 2A STORE 2 +flags \deleted > C2: 2B EXPUNGE > S: ... > S: * EXPUNGED 2 > S: 2B OK > > Session 1 receives notification of the expunge, but ignores it until the > next normal imap moment > > A new message is delivered. Session1 is informed of this, and wants to > present information to the user. But the "real" version of the > mailbox has a message expunged as well as a new message. It CAN NOT > report the new message without also reporting the expunged message. Why not? I do basically the same thing and don't have this problem. If the expunge cannot be sent, it just isn't. When it can be sent, it is. Each time I look at what I can send, the code does something like this: if the set of unreported expunged messages is nonempty if expunges can and should be sent now send the expunges, adjust the MSN-UID map, clear the set if the set of messages with unreported flag updates is nonempty if flag updates can and should be sent now send the updates, clear the set if the set of new messages is nonempty ... you get the idea Perhaps I'm misunderstanding you, or perhaps there is some subtle point that divides our two implementations. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 14:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hft-0006ex-KK; Tue, 18 Dec 2007 14:00:17 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4hfs-0006eo-Hb for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 14:00:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hfs-0006eR-7Z for lemonade@ietf.org; Tue, 18 Dec 2007 14:00:16 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4hfq-0008MY-NZ for lemonade@ietf.org; Tue, 18 Dec 2007 14:00:16 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBIJ0DGB019858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2007 11:00:13 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBIJ0AYY006825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Dec 2007 11:00:13 -0800 Date: Tue, 18 Dec 2007 10:59:51 -0800 (Pacific Standard Time) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] RE: notify In-Reply-To: <00ea01c841a3$fd5a3000$f80e9000$%coates@sun.com> Message-ID: References: <03ce01c83c3d$90af0540$b20d0fc0$%coates@sun.com> <002601c83e75$b1ebde60$15c39b20$%coates@sun.com> <00ea01c841a3$fd5a3000$f80e9000$%coates@sun.com> User-Agent: Alpine 1.00 (WNT 873 2007-12-15) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.18.103358 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_900_999 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 18 Dec 2007, Peter Coates wrote: > The problem is the "index file", which holds some information about each > message. This is a contiguous array of records. If a message is deleted, > the file is rewritten from that point on. When a context resynchronises, it > rereads this file and that becomes its index into the mailbox. If I fail to > report a deleted message, my index is wrong. Changing this would be close > to a rewrite. I have a similar implementation, but I do not require that a message exist in the index, nor do I remove messages that are not in the index until I am at a point where it is safe to expunge. I don't have to worry about index rewrites putting an expunged message back since I would never rewrite the index unless I am at a safe to expunge point. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 15:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqP-0001gd-KZ; Tue, 18 Dec 2007 15:15:13 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4iqG-0001er-1C for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 15:15:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqF-0001eK-EZ; Tue, 18 Dec 2007 15:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4iqF-0001vg-28; Tue, 18 Dec 2007 15:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B116D175BD; Tue, 18 Dec 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4iqE-0005iv-87; Tue, 18 Dec 2007 15:15: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: Tue, 18 Dec 2007 15:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP CONVERT extension Author(s) : A. Melnikov, P. Coates Filename : draft-ietf-lemonade-convert-13.txt Pages : 0 Date : 2007-12-18 CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.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-convert-13.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-convert-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-18140650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18140650.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue Dec 18 16:00:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jY8-0005hw-Cp; Tue, 18 Dec 2007 16:00:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4jY7-0005gL-GF for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 16:00:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jY7-0005e0-4N; Tue, 18 Dec 2007 16:00:23 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4jY5-00063L-Lz; Tue, 18 Dec 2007 16:00:23 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id 9C61CDE8D56; Tue, 18 Dec 2007 13:00:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 06BD9185CF4; Tue, 18 Dec 2007 13:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9xSGVm8I3Xp; Tue, 18 Dec 2007 13:00:11 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id C6B7F185CF2; Tue, 18 Dec 2007 13:00:10 -0800 (PST) Date: Tue, 18 Dec 2007 13:00:10 -0800 (PST) From: Dan Karp To: Internet-Drafts@ietf.org Message-ID: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <2067502224.11611198011523339.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: lemonade@ietf.org, i-d-announce@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > 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 : IMAP CONVERT extension I know that this will sound like a broken record, but *please* remove the dependency on METADATA from the CONVERT draft. No other Lemonade draft requires METADATA. Even a slimmed-down server-level-only METADATA is an extension that's way too much work for the benefit, and this CONVERT draft depends on the old non-slimmed-down METADATA. And the syntax required to do CONVERT discovery via METADATA is baroque, to put it mildly. I understand that there's a push to get this out the door. But METADATA is still unpublished (for good reason) and the CONVERT discovery mechanism is just plain bad. We're going to be stuck with Lemonade for some time, and it's worthwhile to try to make it not suck. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 16:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kFP-0001nZ-6t; Tue, 18 Dec 2007 16:45:07 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4kFO-0001mt-2q for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 16:45:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kFN-0001ku-HA for lemonade@ietf.org; Tue, 18 Dec 2007 16:45:05 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4kFN-0008C3-2u for lemonade@ietf.org; Tue, 18 Dec 2007 16:45:05 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBILj2a6029459 for ; Tue, 18 Dec 2007 13:45:02 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lBILj1rc012571 for ; Tue, 18 Dec 2007 13:45:01 -0800 Received: from 10.43.242.240 ([10.43.242.240]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 18 Dec 2007 21:45:01 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 18 Dec 2007 16:44:59 -0500 From: Eric Burger To: Message-ID: Thread-Topic: WGLC CONVERT Thread-Index: AchBvzyFey6Gvq2yEdyzqwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [lemonade] WGLC CONVERT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The work group last call for CONVERT ends 8 January 2008. Please have at it. http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.txt Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 17:08:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kbj-0006wj-AT; Tue, 18 Dec 2007 17:08:11 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4kbi-0006wa-CN for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 17:08:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kbi-0006wS-1T for lemonade@ietf.org; Tue, 18 Dec 2007 17:08:10 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4kbh-0000Rt-FP for lemonade@ietf.org; Tue, 18 Dec 2007 17:08:09 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id BD98CDE90E0; Tue, 18 Dec 2007 14:08:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 9F1E2185CF2; Tue, 18 Dec 2007 14:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozduRUHS2RIW; Tue, 18 Dec 2007 14:08:01 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 36AFA185CF1; Tue, 18 Dec 2007 14:08:01 -0800 (PST) Date: Tue, 18 Dec 2007 14:08:00 -0800 (PST) From: Dan Karp To: Eric Burger Message-ID: <1099612670.16891198015680285.JavaMail.root@dogfood.zimbra.com> In-Reply-To: Subject: Re: [lemonade] WGLC CONVERT MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > The work group last call for CONVERT ends 8 January 2008. Please have > at it. The client can request header convertions using the BODY[...HEADER] CONVERT request, for example C: D001 FETCH 2 BODY[HEADER] S: * 2 FETCH (BODY[HEADER] {152} S: Date: Mon, 20 Apr 2007 20:05:43 +0200 S: From: peter S: To: Alexey S: Subject: =?USASCII*EN?Q?why encode this?= S: S: ) S: D001 OK C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER] S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {150} S: Date: Mon, 20 Apr 2007 20:05:43 +0200 S: From: peter S: To: Alexey S: Subject: =?UTF-8*EN?Q?why encode this?= S: S: ) S: D002 OK Was there a copy/paste error here? From the explanatory text, I'd expect the second Subject header to read "why encode this" without the 2047 encoding. The server ought to endeavour to preserver the headers during the conversion as much as possible. But in a case like this, where characters are split (legally!) between fragments of an encoded parameter what is the server to do? A safe answer is to consolidate parameters that are in pieces, convert them and emit them fragmenting them again if necessary to keep the line length less than 78. Comments embedded like this can be moved to after the parameter: C: D011 FETCH 3 BODY[1.MIME] S: * 3 FETCH (BODY[1.MIME] {118} S: Content-Type: text/plain; charset=utf-8; S: foo*0*=utf-8'fr'tr%c0; S: foo*1*(very)=%03s_m%c0; S: foo*2*=(nasty)%09chant S: S: D011 OK C: D012 CONVERT 3 (NIL) BODY[1.MIME] S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109} S: Content-Type: text/plain; charset=utf-8; S: foo*0*=utf-8'fr'tr%c0%03s_; S: foo*1*=%m%c0%09chant (very)(nasty) S: S: D012 OK Please leave it simple and explicitly allow servers to drop comments when transcoding headers. (Also, I'm not sure that RFC 2231 actually allows comments in either of those places...) We may also want to change the wording regarding 2231 encoding to flat-out state that Servers also SHOULD decode any parameters as described in [RFC2231], then re-encode the result in RFC 2231 format in the requested charset if necessary. We should also include the expected transcoding behavior for messages that encode compound headers using the illegal-but-popular mechanism of RFC 2047 encoded-words inside quoted-strings. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Dec 18 17:59:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4lPO-0005QJ-F5; Tue, 18 Dec 2007 17:59:30 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4lPN-0005QB-2o for lemonade-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 17:59:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4lPL-0005Pz-O1 for lemonade@ietf.org; Tue, 18 Dec 2007 17:59:28 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4lPL-0002TN-0H for lemonade@ietf.org; Tue, 18 Dec 2007 17:59:27 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 18 Dec 2007 22:59:16 +0000 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <6840.1198018750.475943@peirce.dave.cridland.net> Date: Tue, 18 Dec 2007 22:59:10 +0000 From: Dave Cridland To: Dan Karp Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Dec 18 21:00:10 2007, Dan Karp wrote: > I know that this will sound like a broken record, but *please* > remove the dependency on METADATA from the CONVERT draft. No other > Lemonade draft requires METADATA. Even a slimmed-down > server-level-only METADATA is an extension that's way too much work > for the benefit, and this CONVERT draft depends on the old > non-slimmed-down METADATA. And the syntax required to do CONVERT > discovery via METADATA is baroque, to put it mildly. > > I understand that there's a push to get this out the door. But > METADATA is still unpublished (for good reason) and the CONVERT > discovery mechanism is just plain bad. We're going to be stuck > with Lemonade for some time, and it's worthwhile to try to make it > not suck. I'm willing to acccept that CONVERT discovery is useful, and, moreover, that METADATA represents the best choice for doing so. However, I'm also of the opinion that CONVERT discovery of this kind - ie, pre-meditated discovery - is not what clients what nor need in the common case, based on conversations with Philip Van Hoof, and others. The problem is when considering data which the server has more knowledge of than the client, which, I feel, is actually the common case Consider the following two fairly extreme cases: 1) The "PDF case". Imagine a PDF - or similar self-contained compound document format - which contains a single page. Is this page an image, or is it text? The client doesn't know, the server may be able to determine which basic media type is more suited. 2) The "Unknown case". Imagine a badly behaved MUA sends an email with an attachment typed as application/octet-stream, which is actually a simple JFIF. I appreciate that nobody present really believes that this could be the case, but it will no doubt come as a complete shock that this actually happens. The server may be able to determine this quickly and easily. You can easily come up with more ordinary cases, such as whether an image is best encoded as image/jpeg or image/png, but you get the drift. It seems to me that this is a case where the HTTP-like content negotiation mechanism is of more use than the discovery/request type. In other words. a client might signal its capabilities for media types to the server once per session, and the server would then provide the body part in the "most acceptable" format it could via the NIL "default conversion". If there's interest, I think I can design a zero-RTT mechanism for clients to specify their media capabilities to the server. I think this can be optimized using techniques similar to those in XEP-0115, too, although that will get more complex. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 08:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4yzh-0008Rc-U3; Wed, 19 Dec 2007 08:29:53 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4yzg-0008Np-CL for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 08:29:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4yzg-0008NL-1t for lemonade@ietf.org; Wed, 19 Dec 2007 08:29:52 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4yze-0005Ur-9b for lemonade@ietf.org; Wed, 19 Dec 2007 08:29:52 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 13:29:48 +0000 Message-ID: <47691CC8.7020903@isode.com> Date: Wed, 19 Dec 2007 13:29:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org One of the goals of Lemonade Profile Bis is to try to satisfy majority of OMA MEM requirements. Recently Zoltan and I (with some help with Dave Cridland) went through OMA MEM requirements trying to figure out how they can be mapped to Lemonade (and/or Sieve). My personal belief is that multiple requirements can be satisfied by IMAP METADATA extension (or ACAP, but I am not going to go into this discussion here). Here is an incomplete list of the corresponding OMA MEM requirements (some of them also need Sieve and Sieve Metadata extension): ADMIN-1: It MUST be possible to provision the mobile email client, based on any combination of who the user is and what the device is. ADMIN-4: Authorized principals MUST be able to configure the settings of the user preferences/filters/configurable settings for a particular user ADMIN-7: It MUST be possible for a user to view, edit and reset settings of a mobile email client USAB-11: The mobile email enabler MUST support: Different methods for notifying the client about new emails based on capabilities of the network The ability for the user to select the transport method based on the capabilities of the client and network (e.g. SMS, Push, MMS etc) The ability for the user to select if, when and how events are accessed by the client USAB-16: Authorized principals MUST be able to select the ways that email events are sent to or accessed by the mobile email client and other email settings that may affect the server behaviour USAB-28: The mobile email enabler SHOULD support activation/deactivation of auto-reply from the client. Automatically generated replies SHOULD avoid mail loops (RFC 2821 and related RFCs) After looking at this list Dave and I agreed that there doesn't seem to be any requirement to use per-mailbox metadata, per-user metadata seems to be sufficient. So I would like to propose that the METADATA extension is split into 2 separate extensions: per-user METADATA and per-mailbox METADATA. I would also like to propose that only the former extension is included into Lemonade Profile Bis. Per-user metadata extensions is relatively easy to implement: it would only consist of GETMETADATA command (with mailbox parameter being ""), GETMETADATA response and SETMETADATA command, it doesn't depend on LIST-EXTENDED. Support for the COMPARATOR extension can be made optional. Opinions? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 08:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zSf-0007Dk-1f; Wed, 19 Dec 2007 08:59:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J4zSe-0007Df-AQ for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 08:59:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zSd-0007DX-VP for lemonade@ietf.org; Wed, 19 Dec 2007 08:59:48 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4zSd-0002BA-J9 for lemonade@ietf.org; Wed, 19 Dec 2007 08:59:47 -0500 Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lBJDxkWQ012437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Dec 2007 08:59:47 -0500 Message-ID: <476923C4.5020105@andrew.cmu.edu> Date: Wed, 19 Dec 2007 08:59:32 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.85 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >> 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 : IMAP CONVERT extension > > I know that this will sound like a broken record, but *please* remove the dependency on METADATA from the CONVERT draft. No other Lemonade draft requires METADATA. Even a slimmed-down server-level-only METADATA is an extension that's way too much work for the benefit, and this CONVERT draft depends on the old non-slimmed-down METADATA. And the syntax required to do CONVERT discovery via METADATA is baroque, to put it mildly. > > I understand that there's a push to get this out the door. But METADATA is still unpublished (for good reason) and the CONVERT discovery mechanism is just plain bad. We're going to be stuck with Lemonade for some time, and it's worthwhile to try to make it not suck. I have mixed feelings on this. I certainly understand Dan's concern that dependency on METADATA adds unnecessary complexity in trying to implement CONVERT. As someone that has already implemented ANNOTATEMORE, trying to upgrade this to METADATA has proven non-trivial, mainly because of its interaction with LIST-EXTENDED, which itself is non-trivial. I also understand and support the reluctance to add another discovery mechanism, when we already have an extensible, although complex, one in place. I'm intrigued by Dave's content negotiation proposal, and I'd like to see a strawman. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 09:42:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J507y-0000em-Lo; Wed, 19 Dec 2007 09:42:30 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J507x-0000an-Uj for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 09:42:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J507x-0000YC-Jr for lemonade@ietf.org; Wed, 19 Dec 2007 09:42:29 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J507w-0007Ig-7y for lemonade@ietf.org; Wed, 19 Dec 2007 09:42:29 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBJEgQlc026440 for ; Wed, 19 Dec 2007 14:42:26 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTA00G01VLPEV00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 19 Dec 2007 07:42:26 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTA004YGWUL3XF0@mail-amer.sun.com>; Wed, 19 Dec 2007 07:42:23 -0700 (MST) Date: Wed, 19 Dec 2007 06:42:02 -0800 From: Peter Coates In-reply-to: <47691F93.30305@isode.com> To: "'Dan Karp'" , lemonade@ietf.org Message-id: <01af01c8424d$52c92c90$f85b85b0$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: AchCROi9DV7do1ljSAmvEq1LNrdHiwABYz2Q References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <47691F93.30305@isode.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'Alexey Melnikov' Subject: [lemonade] RE: Inclusion of METADATA into Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I agree with a lot of these points. On the other hand, there needs to be some sort of discovery mechanism. What are the options? Can the METADATA section be made conditional in some way? FWIW, we do not have metadata implemented on our server because of its dependency on listext. We do have the old annotatemore form instead. I have implemented CONVERT, including image conversion. And I have included the metadata for that... it is not that bad with the extra wildcarding. OTOH, I have looked at what is implied with configuring plugins for conversions, and the metadata gets pretty ugly. I have no personal objections to loosing the metadata section. If we do that we will need documents describing what parameters are needed for the various conversion types, and probably a set of capabilities: CONVERT => text/ charset= -> text/ charset= is plain or html is a range of charsets as listed in the draft is utf-8 Required parameter: charset. Permitted parameter: unknown-character-replacement CONVERT=IMAGE => image/xxx -> image/yyy Parameters x-size, y-size, color-depth, greyscale (or something like that) And so on. And these would have to be well defined. Peter Dan Karp wrote: >>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 : IMAP CONVERT extension >> >> >I know that this will sound like a broken record, but *please* remove the dependency on METADATA from the CONVERT draft. No other Lemonade draft requires METADATA. Even a slimmed-down server-level-only METADATA is an extension that's way too much work for the benefit, and this CONVERT draft depends on the old non-slimmed-down METADATA. And the syntax required to do CONVERT discovery via METADATA is baroque, to put it mildly. > >I understand that there's a push to get this out the door. But METADATA is still unpublished (for good reason) and the CONVERT discovery mechanism is just plain bad. We're going to be stuck with Lemonade for some time, and it's worthwhile to try to make it not suck. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 09:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Hv-0005dW-KL; Wed, 19 Dec 2007 09:52:47 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J50Hu-0005dP-BL for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 09:52:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Hu-0005cq-0p for lemonade@ietf.org; Wed, 19 Dec 2007 09:52:46 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J50Ht-0003iW-IY for lemonade@ietf.org; Wed, 19 Dec 2007 09:52:45 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 14:52:44 +0000 Message-ID: <47693035.7090902@isode.com> Date: Wed, 19 Dec 2007 14:52:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Coates References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <47691F93.30305@isode.com> <01af01c8424d$52c92c90$f85b85b0$%coates@sun.com> In-Reply-To: <01af01c8424d$52c92c90$f85b85b0$%coates@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org Subject: [lemonade] Re: Inclusion of METADATA into Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Peter Coates wrote: >I agree with a lot of these points. On the other hand, there needs to be >some sort of discovery mechanism. What are the options? Can the METADATA >section be made conditional in some way? > Speaking as an individual: this would be Ok with me. >FWIW, we do not have metadata implemented on our server because of its dependency on listext. > See my other message on METADATA. My proposal to split METADATA would address that. >We do have the old annotatemore form instead. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 10:10:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Z9-0005fc-OJ; Wed, 19 Dec 2007 10:10:35 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J50Z8-0005ev-Gb for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:10:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Z7-0005eh-LQ for lemonade@ietf.org; Wed, 19 Dec 2007 10:10:33 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50Z7-0007rx-7M for lemonade@ietf.org; Wed, 19 Dec 2007 10:10:33 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 970FDDE8EF4; Wed, 19 Dec 2007 07:10:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 963B1185CE5; Wed, 19 Dec 2007 07:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvEC0QTq+iIC; Wed, 19 Dec 2007 07:10:26 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id AEC77185CF1; Wed, 19 Dec 2007 07:10:26 -0800 (PST) Date: Wed, 19 Dec 2007 07:10:26 -0800 (PST) From: Dan Karp To: Peter Coates Message-ID: <214172189.8941198077026463.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <01af01c8424d$52c92c90$f85b85b0$%coates@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, Alexey Melnikov Subject: [lemonade] Re: Inclusion of METADATA into Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I agree with a lot of these points. On the other hand, there needs to > be some sort of discovery mechanism. What are the options? Well, you could have the client tell the server its capabilities and have the server automatically do the conversion based on the client's stated preferences. Or you could have a simple CONVERT-specific command that allows a client to query what a given MIME type or message part can be converted to (and what parameters can be supplied to the conversion). Either one is fine with me. I just want something that solves the problem at hand and doesn't try to solve problems we don't have yet. Because when people try to generalize from one data point, that generalization's almost guaranteed to be wrong.... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 10:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5197-0007jJ-ES; Wed, 19 Dec 2007 10:47:45 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J5196-0007aN-Mw for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:47:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5196-0007V7-8W for lemonade@ietf.org; Wed, 19 Dec 2007 10:47:44 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5195-0000MY-3N for lemonade@ietf.org; Wed, 19 Dec 2007 10:47:44 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Wed, 19 Dec 2007 15:47:30 +0000 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> In-Reply-To: <476923C4.5020105@andrew.cmu.edu> MIME-Version: 1.0 Message-Id: <6840.1198079247.296478@peirce.dave.cridland.net> Date: Wed, 19 Dec 2007 15:47:27 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Dec 19 13:59:32 2007, Ken Murchison wrote: > I also understand and support the reluctance to add another > discovery mechanism, when we already have an extensible, although > complex, one in place. > > Indeed - I think the one we have is good for those cases where a client actually wants to get a specific conversion out of the server. The problem is the client is rarely in the best position to make a judgement call on what the best conversion might be. > I'm intrigued by Dave's content negotiation proposal, and I'd like > to see a strawman. Okay. So, in my proposal, we'd do something like: 1) The client specifies a media capability list, something like HTTP's Accept header. We would need to say things like "I can do text/plain or text/html. Whichever, I can do UTF-8 or US-ASCII charsets, and I know about format=flowed and format=fixed for text/plain". And "I can do image/jpeg, image/png, and image/gif. My screen resolution is QVGA portrait, and my colour depth is 16". A proposal for a syntax might be that: a) We handle the charset and screen resolution by saying "text/*", for example. b) We otherwise list types in order of preference. The server may choose to override preferences - for example, the client may have suggested that HTML is preferable to plain text, but the server may determine that the PDF it's converting contains little formatting. This gets us something that would look like: A01 MEDIACAPS ("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320") I've chosen a fairly complex, but hopefully concise, syntax here. The client is saying (each parenthesized list converted to a sentence): "I do text/html. I will also do text/plain, preferably with format=flowed, but I can handle format=fixed too. For all text media types I do, I can handle a charset of either UTF-8 or US-ASCII. I can handle image/jpge, image/png, and, least preferred, image/gif, and my ideal resolution is 240x320." I couldn't immediately spot anything for colour depth, but you get the idea. In ABNF, this looks like: mediacaps-cmd = "MEDIACAPS" 1*(SP mediacap) mediacap = "(" media-type SP media-subtype *( SP media-param SP media-param-values ) ")" media-type = astring media-subtype = DQUOTE "*" DQUOTE / astring / "(" astring *( SP astring ) ")" ;; "*" means all subtypes for the type mentioned in the command. ;; Otherwise, either the specific subtype or a list of them. media-param = astring media-param-values = astring / "(" astring *(SP astring) ")" ;; Either a single acceptable value or a list of acceptable values. The command can't ever return NO. Even if the server hasn't a clue about any of the media types mentioned, returning NO doesn't make sense - the client is hardly likely to retry with a different screen size. :-) We can make this more complicated by allowing a NO tagged response to MEDIACAPS, and allowing the argument to mediacaps to also be a hash used to identify the mediacaps in shorthand, so you'd get an exchange like: C: A01 MEDIACAPS "1234567890123456" S: A01 NO Unknown device C: A02 MEDIACAPS (...) S: A02 OK (This form is subject to a potential preimage poisoning attack, but MD5 is sufficient to protect against this for the foreseeable future). Both these look as if they're adding round-trips to session startup, but pipelining these commands is entirely practical. I'd imagine MEDIACAPS would be pipelined typically with ENABLE, and the second MEDIACAPS (in the second form) would be pipelinable with the first SELECT. 2) The client then uses the default conversion for all CONVERTs, unless it wants to do something specific - in which case it has to use the METADATA discovery. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 11:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51QY-0006aV-Il; Wed, 19 Dec 2007 11:05:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J51QX-0006aO-7s for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:05:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51QW-0006aG-UC for lemonade@ietf.org; Wed, 19 Dec 2007 11:05:44 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51QW-0000gc-9w for lemonade@ietf.org; Wed, 19 Dec 2007 11:05:44 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJG5hNB004193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Dec 2007 08:05:43 -0800 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJG5gpr028250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Dec 2007 08:05:43 -0800 Date: Wed, 19 Dec 2007 08:05:37 -0800 From: Mark Crispin To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt In-Reply-To: <476923C4.5020105@andrew.cmu.edu> Message-ID: References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> User-Agent: Alpine 1.00 (WNT 873 2007-12-15) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.19.74000 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_600_699 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 19 Dec 2007, Ken Murchison wrote: > I have mixed feelings on this. I certainly understand Dan's concern that > dependency on METADATA adds unnecessary complexity in trying to implement > CONVERT. As someone that has already implemented ANNOTATEMORE, trying to > upgrade this to METADATA has proven non-trivial, mainly because of its > interaction with LIST-EXTENDED, which itself is non-trivial. When I read text such as the above I get a very nervous feeling about the entire Lemonade effort. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 11:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51co-0002TZ-TN; Wed, 19 Dec 2007 11:18:26 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J51cn-0002R5-47 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:18:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51cm-0002Qv-QF for lemonade@ietf.org; Wed, 19 Dec 2007 11:18:24 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51cl-0001FR-AU for lemonade@ietf.org; Wed, 19 Dec 2007 11:18:24 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id C31A7DE8AB2; Wed, 19 Dec 2007 08:18:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id B6BFF185CE5; Wed, 19 Dec 2007 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghzjbWCLgUR1; Wed, 19 Dec 2007 08:18:16 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id A73AF185CF8; Wed, 19 Dec 2007 08:18:13 -0800 (PST) Date: Wed, 19 Dec 2007 08:18:13 -0800 (PST) From: Dan Karp To: Dave Cridland Message-ID: <125995622.11121198081093542.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <58486232.11041198081061072.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > I also understand and support the reluctance to add another > > discovery mechanism, when we already have an extensible, although > > complex, one in place. > > Indeed - I think the one we have is good for those cases where a > client actually wants to get a specific conversion out of the server. Ah. You see, here's where we differ. *You* have an already-implemented extension that you think you can can shoehorn discovery into. *I* have a METADATA draft that I've got zero intention of implementing because it's an utter pain in the ass. If you add discovery behavior into METADATA, I and every other wannabe- Lemonade-compliant server implementor are stuck doing the rest of the mailbox-level stuff, the LISTEXT integration, the shared/priv nightmare, the value/size stuff, and handling writable annotations. I DO NOT WANT TO DO THIS. Lemonade should be the smallest set of IMAP extensions that solves the problem we're trying to solve. AND NO MORE. METADATA falls on the wrong side of that balance and thus needs to be excised from Lemonade. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 11:28:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51mx-0000a7-1i; Wed, 19 Dec 2007 11:28:55 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J51mv-0000Uq-SI for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:28:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51mv-0000Ui-Ia for lemonade@ietf.org; Wed, 19 Dec 2007 11:28:53 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51mt-0001TN-Qp for lemonade@ietf.org; Wed, 19 Dec 2007 11:28:53 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 1D01B4AC46 for ; Wed, 19 Dec 2007 17:28:44 +0100 (CET) Message-Id: Date: Wed, 19 Dec 2007 17:26:44 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <125995622.11121198081093542.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <125995622.11121198081093542.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp writes: > METADATA falls on the wrong side of that balance and thus needs to be > excised from Lemonade. I agree with the latter, but for somewhat different reasons. I don't think metadata is a good fit for the problem. I like Dave's suggestion rather better. And since this is probably my last mail before 2008: Merry Chrismas, everyone, and a happy new year! Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 11:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51qJ-0001Uk-TT; Wed, 19 Dec 2007 11:32:23 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J51qI-0001Ud-Fo for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:32:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51qI-0001UU-5S for lemonade@ietf.org; Wed, 19 Dec 2007 11:32:22 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J51qH-0006bS-SZ for lemonade@ietf.org; Wed, 19 Dec 2007 11:32:22 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id 45FC1DE9286; Wed, 19 Dec 2007 08:32:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id DC698185CF4; Wed, 19 Dec 2007 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1DGQG2HuUJf; Wed, 19 Dec 2007 08:32:14 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 1AF20185CF1; Wed, 19 Dec 2007 08:32:14 -0800 (PST) Date: Wed, 19 Dec 2007 08:32:14 -0800 (PST) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <1195617645.11771198081933998.JavaMail.root@dogfood.zimbra.com> In-Reply-To: Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > METADATA falls on the wrong side of that balance and thus needs to > > be excised from Lemonade. > > I agree with the latter, but for somewhat different reasons. I don't > think metadata is a good fit for the problem. I like Dave's suggestion > rather better. I think I'd lean towards Dave's solution as the right one as well. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 11:42:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J520X-00085K-MC; Wed, 19 Dec 2007 11:42:57 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J520W-000857-6Q for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J520V-00084z-T3 for lemonade@ietf.org; Wed, 19 Dec 2007 11:42:55 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J520U-0001i7-GH for lemonade@ietf.org; Wed, 19 Dec 2007 11:42:55 -0500 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lBJGglSN024784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 11:42:50 -0500 Date: Wed, 19 Dec 2007 11:42:42 -0500 From: Cyrus Daboo To: Dave Cridland , Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt Message-ID: In-Reply-To: <6840.1198079247.296478@peirce.dave.cridland.net> References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <6840.1198079247.296478@peirce.dave.cridland.net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On December 19, 2007 3:47:27 PM +0000 Dave Cridland wrote: > Both these look as if they're adding round-trips to session startup, but > pipelining these commands is entirely practical. I'd imagine MEDIACAPS > would be pipelined typically with ENABLE, and the second MEDIACAPS (in > the second form) would be pipelinable with the first SELECT. So MEDIACAPS is just another example of where an extension does its own thing to push client info to the server. METADATA was meant to solve the other problem of extensions wanting to push information from the server to the client. In spite of what Dan said in another message in this thread about trying to generalize leading to over engineering, I believe we need to generalize for this case. So lets not invent another command specific to CONVERT - namely MEDIACAPS. Lets just figure out a way to do it with ENABLE. Then ENABLE can become the generic "client tells the server what it wants" extension that can be reused by other extensions. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 11:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52BE-0002yj-C5; Wed, 19 Dec 2007 11:54:00 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J52BD-0002wP-64 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:53:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52BC-0002wH-Ry for lemonade@ietf.org; Wed, 19 Dec 2007 11:53:58 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J52BC-0006yf-1f for lemonade@ietf.org; Wed, 19 Dec 2007 11:53:58 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 16:53:55 +0000 Message-ID: <47694C96.9090206@isode.com> Date: Wed, 19 Dec 2007 16:53:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Wed, 19 Dec 2007, Ken Murchison wrote: > >> I have mixed feelings on this. I certainly understand Dan's concern >> that dependency on METADATA adds unnecessary complexity in trying to >> implement CONVERT. As someone that has already implemented >> ANNOTATEMORE, trying to upgrade this to METADATA has proven >> non-trivial, mainly because of its interaction with LIST-EXTENDED, >> which itself is non-trivial. > > When I read text such as the above I get a very nervous feeling about > the entire Lemonade effort. Mark, why would you say that? The WG has started a long delayed discussion about things that needs to be added in Profile Bis versa things that should be removed. If the outcome of this discussion, for example, is that METADATA needs to be removed or split, then so be it. This tells absolutely nothing about the direction where this effort is going. Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 12:28:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52iH-000085-Md; Wed, 19 Dec 2007 12:28:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J52iG-00007i-Vu for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 12:28:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52iG-000075-Ki for lemonade@ietf.org; Wed, 19 Dec 2007 12:28:08 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J52iG-0007y4-6y for lemonade@ietf.org; Wed, 19 Dec 2007 12:28:08 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id AF7DBDE92CD; Wed, 19 Dec 2007 09:28:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 1C13B185CF7; Wed, 19 Dec 2007 09:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 695KAXdUV4Zo; Wed, 19 Dec 2007 09:28:00 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8F5FA185CE5; Wed, 19 Dec 2007 09:28:00 -0800 (PST) Date: Wed, 19 Dec 2007 09:28:00 -0800 (PST) From: Dan Karp To: Alexey Melnikov Message-ID: <1716662269.15121198085280450.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1636341845.14841198085162619.JavaMail.root@dogfood.zimbra.com> Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > ADMIN-1: It MUST be possible to provision the mobile email client, based > on any combination of who the user is and what the device is. > ADMIN-4: Authorized principals MUST be able to configure the settings of > the user preferences/filters/configurable settings for a particular user > ADMIN-7: It MUST be possible for a user to view, edit and reset settings > of a mobile email client > USAB-11: The mobile email enabler MUST support: > Different methods for notifying the client about new emails based > on capabilities of the network > The ability for the user to select the transport method based on > the capabilities of the client and network (e.g. SMS, Push, MMS etc) > The ability for the user to select if, when and how events are > accessed by the client > USAB-16: Authorized principals MUST be able to select the ways that > email events are sent to or accessed by the mobile email client and > other email settings that may affect the server behaviour > USAB-28: The mobile email enabler SHOULD support activation/deactivation > of auto-reply from the client. Automatically generated replies SHOULD > avoid mail loops (RFC 2821 and related RFCs) Forgive me if I've misunderstood, but this seems like a significant expansion of Lemonade. Putting aside the discussion of slightly slimming METADATA, I'm not convinced of the wisdom of such a thing at this point. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 12:28:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52im-00010A-Gq; Wed, 19 Dec 2007 12:28:40 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J52il-0000vr-7W for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 12:28:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52ik-0000sY-Ro for lemonade@ietf.org; Wed, 19 Dec 2007 12:28:38 -0500 Received: from renoir.mumbo.ca ([68.144.1.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J52ik-0007yi-IP for lemonade@ietf.org; Wed, 19 Dec 2007 12:28:38 -0500 Received: from [192.168.1.5] (S010600079517e007.cg.shawcable.net [68.144.107.7]) by renoir.mumbo.ca (Postfix) with ESMTPA id 5442E17688; Wed, 19 Dec 2007 10:28:37 -0700 (MST) Message-Id: <6CA38DC4-90CF-4C9C-AAC4-772DD762A7FA@mumbo.ca> From: Curtis King To: Dan Karp In-Reply-To: <125995622.11121198081093542.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt Date: Wed, 19 Dec 2007 10:28:36 -0700 References: <125995622.11121198081093542.JavaMail.root@dogfood.zimbra.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 19-Dec-07, at 9:18 AM, Dan Karp wrote: > Lemonade should be the smallest set of IMAP extensions that solves the > problem we're trying to solve. AND NO MORE. METADATA falls on the > wrong side of that balance and thus needs to be excised from Lemonade. +1 ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 12:48:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J531q-0002YF-IL; Wed, 19 Dec 2007 12:48:22 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J531p-0002Sv-CZ for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 12:48:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J531p-0002Q9-11 for lemonade@ietf.org; Wed, 19 Dec 2007 12:48:21 -0500 Received: from renoir.mumbo.ca ([68.144.1.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J531o-0000Tw-J6 for lemonade@ietf.org; Wed, 19 Dec 2007 12:48:20 -0500 Received: from [192.168.1.5] (S010600079517e007.cg.shawcable.net [68.144.107.7]) by renoir.mumbo.ca (Postfix) with ESMTPA id F0537174A4; Wed, 19 Dec 2007 10:48:19 -0700 (MST) Message-Id: From: Curtis King To: Alexey Melnikov In-Reply-To: <47691CC8.7020903@isode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications Date: Wed, 19 Dec 2007 10:48:19 -0700 References: <47691CC8.7020903@isode.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 19-Dec-07, at 6:29 AM, Alexey Melnikov wrote: > ADMIN-1: It MUST be possible to provision the mobile email client, > based on any combination of who the user is and what the device is. > ADMIN-4: Authorized principals MUST be able to configure the > settings of the user preferences/filters/configurable settings for a > particular user > ADMIN-7: It MUST be possible for a user to view, edit and reset > settings of a mobile email client > USAB-11: The mobile email enabler MUST support: > Different methods for notifying the client about new emails > based on capabilities of the network > The ability for the user to select the transport method based on > the capabilities of the client and network (e.g. SMS, Push, MMS etc) > The ability for the user to select if, when and how events are > accessed by the client > USAB-16: Authorized principals MUST be able to select the ways that > email events are sent to or accessed by the mobile email client and > other email settings that may affect the server behaviour > USAB-28: The mobile email enabler SHOULD support activation/ > deactivation of auto-reply from the client. Automatically generated > replies SHOULD avoid mail loops (RFC 2821 and related RFCs) These are valid problems to solve but have nothing to-do with IMAP. They should be solved using an other protocol for example ACAP, LDAP or LACAP. Pushing everything into IMAP is wrong and needs to stop, as IMAP is coming complex enough just solving the core problem of pushing email to a mobile client. I have no problem with expanding lemonade to include mobile configuration, so OMA MEM keeps one contact group within IETF. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 12:59:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Cv-00087t-S7; Wed, 19 Dec 2007 12:59:49 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53Cu-00083h-MW for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 12:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Cu-00082e-CQ for lemonade@ietf.org; Wed, 19 Dec 2007 12:59:48 -0500 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53Ct-0003h8-QV for lemonade@ietf.org; Wed, 19 Dec 2007 12:59:48 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; format=flowed; delsp=yes Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MP2JKC2ECG00J5CM@mauve.mrochek.com> for lemonade@ietf.org; Wed, 19 Dec 2007 09:59:45 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MP11B3HDXS00BDC1@mauve.mrochek.com>; Wed, 19 Dec 2007 09:59:43 -0800 (PST) Message-id: <01MP2JKB301C00BDC1@mauve.mrochek.com> Date: Wed, 19 Dec 2007 09:56:02 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications In-reply-to: "Your message dated Wed, 19 Dec 2007 10:48:19 -0700" References: <47691CC8.7020903@isode.com> To: Curtis King DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1198087185; h=Date: From:Subject:MIME-version:Content-type; b=FimEZpG+itzqvoV+F+ERaNUWu 9xlrdB4r3RSRponip62HkuCE//qIZJP/puC6l6r68FrYfA19H0HoND8YBoThw== X-Spam-Score: -0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Lemonade WG , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On 19-Dec-07, at 6:29 AM, Alexey Melnikov wrote: > > ADMIN-1: It MUST be possible to provision the mobile email client, > > based on any combination of who the user is and what the device is. > > ADMIN-4: Authorized principals MUST be able to configure the > > settings of the user preferences/filters/configurable settings for a > > particular user > > ADMIN-7: It MUST be possible for a user to view, edit and reset > > settings of a mobile email client > > USAB-11: The mobile email enabler MUST support: > > Different methods for notifying the client about new emails > > based on capabilities of the network > > The ability for the user to select the transport method based on > > the capabilities of the client and network (e.g. SMS, Push, MMS etc) > > The ability for the user to select if, when and how events are > > accessed by the client > > USAB-16: Authorized principals MUST be able to select the ways that > > email events are sent to or accessed by the mobile email client and > > other email settings that may affect the server behaviour > > USAB-28: The mobile email enabler SHOULD support activation/ > > deactivation of auto-reply from the client. Automatically generated > > replies SHOULD avoid mail loops (RFC 2821 and related RFCs) > These are valid problems to solve but have nothing to-do with IMAP. More to the point, while the group isn't constrained to only extend IMAP, these things are pretty clearly outside the current group's charter and deliverables. > They should be solved using an other protocol for example ACAP, LDAP > or LACAP. Pushing everything into IMAP is wrong and needs to stop, as > IMAP is coming complex enough just solving the core problem of pushing > email to a mobile client. Agreed. > I have no problem with expanding lemonade to include mobile > configuration, so OMA MEM keeps one contact group within IETF. That would either require that we recharter or else create a new group. If this sort of thing is to done in the IETF I'd prefer having a new group do it. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Kn-0008C2-62; Wed, 19 Dec 2007 13:07:57 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53Km-0008Az-0S for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:07:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Kl-0008AF-MA for lemonade@ietf.org; Wed, 19 Dec 2007 13:07:55 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J53Kl-00018L-BD for lemonade@ietf.org; Wed, 19 Dec 2007 13:07:55 -0500 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lBJI7mXo025877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 13:07:51 -0500 Date: Wed, 19 Dec 2007 13:07:43 -0500 From: Cyrus Daboo To: Curtis King , Alexey Melnikov Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications Message-ID: In-Reply-To: References: <47691CC8.7020903@isode.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Curtis, --On December 19, 2007 10:48:19 AM -0700 Curtis King wrote: > These are valid problems to solve but have nothing to-do with IMAP. They > should be solved using an other protocol for example ACAP, LDAP or LACAP. > Pushing everything into IMAP is wrong and needs to stop, as IMAP is > coming complex enough just solving the core problem of pushing email to a > mobile client. > > I have no problem with expanding lemonade to include mobile > configuration, so OMA MEM keeps one contact group within IETF. We don't need to do much on this. A solution already exists in the form of XCAP which at least SIP-based mobile devices are likely to be supporting. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Nf-0005aj-VW; Wed, 19 Dec 2007 13:10:55 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53Nf-0005ae-50 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:10:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Ne-0005aV-R9 for lemonade@ietf.org; Wed, 19 Dec 2007 13:10:54 -0500 Received: from outmail136019.authsmtp.co.uk ([62.13.136.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53Nd-0003tR-VF for lemonade@ietf.org; Wed, 19 Dec 2007 13:10:54 -0500 Received: from outmail128175.authsmtp.net (outmail128175.authsmtp.net [62.13.128.175]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id lBJIAqQq079892; Wed, 19 Dec 2007 18:10:52 GMT Received: from DGCSonyFS (85-18-37-27.ip.fastwebnet.it [85.18.37.27]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id lBJIAoE5035342; Wed, 19 Dec 2007 18:10:50 GMT From: "Darryl Champagne" To: "'Curtis King'" , "'Alexey Melnikov'" References: <47691CC8.7020903@isode.com> Subject: RE: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications Date: Wed, 19 Dec 2007 13:10:49 -0500 Message-ID: <038501c8426a$7c8c3870$5700a8c0@DGCSonyFS> 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.3198 In-Reply-To: Thread-Index: AchCZ1qmb12RHIArQCyNJSGfxtIgUAAAO5xA X-Server-Quench: bbc2b1d3-ae5d-11dc-814e-001185d377ca X-AuthRoute: OCdyYgEXBlZZQw9C UXtZVgdJRQghPh1N CFkFIBdMJUcNSQVJ NksadRtFaQxbaVxS HGQLW1NEUVV7WGN/ bgsfZQBDY0JQXAJ0 Uk9WQFdQERpoT0Bz fGdvDWx3dwZDe3py K0RnXHMVDhYpdxR8 Fk1JRDgDMXphaTRM TUhZc1ZJcANLfxdA PlN4UyBcLwdybGoL GwI2ODY4MThqYAF4 fighBG47CVsQE3Y2 VlgmEDAoG0QJSm0L NRsoK1oRVGwQKQ07 N1dpQk8XPBIJFgBS BEBIGCtYKVgKTjYq CgVBNVMo X-Authentic-SMTP: 61633132393235.squirrel.dmpriest.net.uk:787/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'Lemonade WG' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > -----Original Message----- > From: Curtis King [mailto:cking@mumbo.ca] > .. > On 19-Dec-07, at 6:29 AM, Alexey Melnikov wrote: > > > ADMIN-1: It MUST be possible to provision the mobile email client, > > based on any combination of who the user is and what the device is. .. > > These are valid problems to solve but have nothing to-do with IMAP. > They should be solved using an other protocol for example ACAP, LDAP > or LACAP. Pushing everything into IMAP is wrong and needs to stop, as > IMAP is coming complex enough just solving the core problem of pushing > email to a mobile client. > > I have no problem with expanding lemonade to include mobile > configuration, so OMA MEM keeps one contact group within IETF. > > ck > It's also worth remembering that OMA already has a provisioning/Device Management specification/Enabler, DM, which is deployed on 95+% of the handsets produced this year ***. Thus an easy way for OMA-MEM to support provisioning (and various other settings) is by specifying just the data to configure on the handset (a DM Management object). The DM Working Group also has guidelines on creating management objects available. Having yet another way to change configuration settings seems of marginal value - especially since you will not be able to specify the address of the email server via IMAP no matter what goes in, whereas operators will configure handsets via DM to access their own servers, and frequently provide Web UIs of their own to revise settings. Dgc *** Based on poll including manufacturers producing 700 million handsets, summary available at http://member.openmobilealliance.org/ftp/TP/2007london/OMAWorldPresentation2 007.zip for OMA Members, public versions to follow in a week or so on the OMA website. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:24:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53aj-0001fb-4W; Wed, 19 Dec 2007 13:24:25 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53ah-0001a1-L1 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:24:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53ah-0001X6-8v for lemonade@ietf.org; Wed, 19 Dec 2007 13:24:23 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J53ag-0001SA-Mj for lemonade@ietf.org; Wed, 19 Dec 2007 13:24:23 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 18:24:21 +0000 Message-ID: <476961CE.60600@isode.com> Date: Wed, 19 Dec 2007 18:24:14 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Curtis King Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications References: <47691CC8.7020903@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King wrote: > On 19-Dec-07, at 6:29 AM, Alexey Melnikov wrote: > >> ADMIN-1: It MUST be possible to provision the mobile email client, >> based on any combination of who the user is and what the device is. >> ADMIN-4: Authorized principals MUST be able to configure the >> settings of the user preferences/filters/configurable settings for a >> particular user >> ADMIN-7: It MUST be possible for a user to view, edit and reset >> settings of a mobile email client >> USAB-11: The mobile email enabler MUST support: >> Different methods for notifying the client about new emails >> based on capabilities of the network >> The ability for the user to select the transport method based on >> the capabilities of the client and network (e.g. SMS, Push, MMS etc) >> The ability for the user to select if, when and how events are >> accessed by the client >> USAB-16: Authorized principals MUST be able to select the ways that >> email events are sent to or accessed by the mobile email client and >> other email settings that may affect the server behaviour >> USAB-28: The mobile email enabler SHOULD support activation/ >> deactivation of auto-reply from the client. Automatically generated >> replies SHOULD avoid mail loops (RFC 2821 and related RFCs) > > These are valid problems to solve but have nothing to-do with IMAP. I almost agree with you. Almost, because support for virtual views is missing one small piece, which is storing search filters on IMAP server (draft-melnikov-imapext-filters-02.txt). This piece currently depends on per-user METADATA. > They should be solved using an other protocol for example ACAP, LDAP > or LACAP. Pushing everything into IMAP is wrong and needs to stop, as > IMAP is coming complex enough just solving the core problem of > pushing email to a mobile client. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53ce-0004gd-6g; Wed, 19 Dec 2007 13:26:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53cc-0004gX-AB for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:26:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53cb-0004gP-W0 for lemonade@ietf.org; Wed, 19 Dec 2007 13:26:22 -0500 Received: from renoir.mumbo.ca ([68.144.1.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J53cb-0001Yc-ME for lemonade@ietf.org; Wed, 19 Dec 2007 13:26:21 -0500 Received: from [192.168.1.5] (S010600079517e007.cg.shawcable.net [68.144.107.7]) by renoir.mumbo.ca (Postfix) with ESMTPA id 26EAC174A4; Wed, 19 Dec 2007 11:26:21 -0700 (MST) Message-Id: <20DD3C95-E30F-4E9A-B65F-6EB4DBE1BF9B@mumbo.ca> From: Curtis King To: Alexey Melnikov In-Reply-To: <476961CE.60600@isode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications Date: Wed, 19 Dec 2007 11:26:20 -0700 References: <47691CC8.7020903@isode.com> <476961CE.60600@isode.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 19-Dec-07, at 11:24 AM, Alexey Melnikov wrote: > > I almost agree with you. Almost, because support for virtual views > is missing one small piece, which is storing search filters on IMAP > server (draft-melnikov-imapext-filters-02.txt). This piece currently > depends on per-user METADATA. Which it shouldn't. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:32:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53ia-0005Np-Ky; Wed, 19 Dec 2007 13:32:32 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53iZ-0005NT-FT for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53iZ-0005NK-5k for lemonade@ietf.org; Wed, 19 Dec 2007 13:32:31 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53iX-0004Mc-Cz for lemonade@ietf.org; Wed, 19 Dec 2007 13:32:31 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 18:32:27 +0000 Message-ID: <476963B4.7000802@isode.com> Date: Wed, 19 Dec 2007 18:32:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dan Karp Subject: Re: [lemonade] WGLC CONVERT References: <1099612670.16891198015680285.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1099612670.16891198015680285.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >>The work group last call for CONVERT ends 8 January 2008. Please have >>at it. >> >> Hi Dan, Thank you for your comments. > The client can request header convertions using the BODY[...HEADER] > CONVERT request, for example > > C: D001 FETCH 2 BODY[HEADER] > S: * 2 FETCH (BODY[HEADER] {152} > S: Date: Mon, 20 Apr 2007 20:05:43 +0200 > S: From: peter > S: To: Alexey > S: Subject: =?USASCII*EN?Q?why encode this?= > S: > S: ) > S: D001 OK > > C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER] > S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {150} > S: Date: Mon, 20 Apr 2007 20:05:43 +0200 > S: From: peter > S: To: Alexey > S: Subject: =?UTF-8*EN?Q?why encode this?= > S: > S: ) > S: D002 OK > >Was there a copy/paste error here? > The example matches the current description, but ... >From the explanatory text, I'd expect the second Subject header to read "why encode this" without the 2047 encoding. > > ... this is a valid point and I think the text should be adjusted accordingly. The example can also be changed to convert from ISO-8859-1 to UTF-8. > The server ought to endeavour to preserver the headers during the > conversion as much as possible. But in a case like this, where > characters are split (legally!) between fragments of an encoded > parameter what is the server to do? A safe answer is to > consolidate parameters that are in pieces, convert them and > emit them fragmenting them again if necessary to keep the line > length less than 78. Comments embedded like this can be moved to > after the parameter: > > C: D011 FETCH 3 BODY[1.MIME] > S: * 3 FETCH (BODY[1.MIME] {118} > S: Content-Type: text/plain; charset=utf-8; > S: foo*0*=utf-8'fr'tr%c0; > S: foo*1*(very)=%03s_m%c0; > S: foo*2*=(nasty)%09chant > S: > S: D011 OK > > C: D012 CONVERT 3 (NIL) BODY[1.MIME] > S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109} > S: Content-Type: text/plain; charset=utf-8; > S: foo*0*=utf-8'fr'tr%c0%03s_; > S: foo*1*=%m%c0%09chant (very)(nasty) > S: > S: D012 OK > >Please leave it simple and explicitly allow servers to drop comments when transcoding headers. > That is fine with me. Suggest text? >(Also, I'm not sure that RFC 2231 actually allows comments in either of those places...) We may also want to change the wording regarding 2231 encoding to flat-out state that > > Servers also SHOULD decode any parameters as described in [RFC2231], > then re-encode the result in RFC 2231 format in the requested charset > if necessary. > >We should also include the expected transcoding behavior for messages that encode compound headers using the illegal-but-popular mechanism of RFC 2047 encoded-words inside quoted-strings. > > If it is illegal according to RFC 2047, then we don't need to mention how to deal with them. GIGO. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:38:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53oh-00019k-R9; Wed, 19 Dec 2007 13:38:51 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53og-00017a-Mi for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:38:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53og-00016B-8s for lemonade@ietf.org; Wed, 19 Dec 2007 13:38:50 -0500 Received: from renoir.mumbo.ca ([68.144.1.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J53of-0001pL-VW for lemonade@ietf.org; Wed, 19 Dec 2007 13:38:50 -0500 Received: from [192.168.1.5] (S010600079517e007.cg.shawcable.net [68.144.107.7]) by renoir.mumbo.ca (Postfix) with ESMTPA id 68513174A4; Wed, 19 Dec 2007 11:38:49 -0700 (MST) Message-Id: <02E2D846-D9EA-4641-BB62-E9D95280C5BF@mumbo.ca> From: Curtis King To: Cyrus Daboo In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt Date: Wed, 19 Dec 2007 11:38:49 -0700 References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <6840.1198079247.296478@peirce.dave.cridland.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 19-Dec-07, at 9:42 AM, Cyrus Daboo wrote: > So lets not invent another command specific to CONVERT - namely > MEDIACAPS. Lets just figure out a way to do it with ENABLE. Then > ENABLE can become the generic "client tells the server what it > wants" extension that can be reused by other extensions. I like the idea. Do you have a strawman in mind? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:41:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53rN-0000EI-A6; Wed, 19 Dec 2007 13:41:37 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53rM-0008Nn-6N for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53rL-0008IN-N6 for lemonade@ietf.org; Wed, 19 Dec 2007 13:41:35 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53rL-0004Wu-1G for lemonade@ietf.org; Wed, 19 Dec 2007 13:41:35 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJIfY9p022516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Dec 2007 10:41:34 -0800 X-Auth-Received: from D-128-208-207-17.dhcp4.washington.edu (D-128-208-207-17.dhcp4.washington.edu [128.208.207.17]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJIfXGT032275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Dec 2007 10:41:34 -0800 Date: Wed, 19 Dec 2007 10:41:19 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt In-Reply-To: <47694C96.9090206@isode.com> Message-ID: References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <47694C96.9090206@isode.com> User-Agent: Alpine 1.00 (LN8 873 2007-12-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.19.102435 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_500_599 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 19 Dec 2007, Alexey Melnikov wrote: > Mark, why would you say that? Multiple interlocking interdependecies frighten me. So does the inclusion of facilities that are not absolutely necessary for mobile devices ("nice to have" is not the same). These should frighten you too. Lemonade really needed a mini-IMAP. It did maxi-IMAP instead. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 13:43:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53sw-0005N2-SS; Wed, 19 Dec 2007 13:43:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J53sv-0005Mv-Lg for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:43:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53sv-0005Ml-Bm for lemonade@ietf.org; Wed, 19 Dec 2007 13:43:13 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53su-0004Yl-U0 for lemonade@ietf.org; Wed, 19 Dec 2007 13:43:13 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJIhCok000458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Dec 2007 10:43:12 -0800 X-Auth-Received: from D-128-208-207-17.dhcp4.washington.edu (D-128-208-207-17.dhcp4.washington.edu [128.208.207.17]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJIhBIH014721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Dec 2007 10:43:11 -0800 Date: Wed, 19 Dec 2007 10:42:57 -0800 (PST) From: Mark Crispin To: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt In-Reply-To: <6CA38DC4-90CF-4C9C-AAC4-772DD762A7FA@mumbo.ca> Message-ID: References: <125995622.11121198081093542.JavaMail.root@dogfood.zimbra.com> <6CA38DC4-90CF-4C9C-AAC4-772DD762A7FA@mumbo.ca> User-Agent: Alpine 1.00 (LN8 873 2007-12-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.19.102435 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_400_499 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org +1. Strongly. On Wed, 19 Dec 2007, Curtis King wrote: > On 19-Dec-07, at 9:18 AM, Dan Karp wrote: >> Lemonade should be the smallest set of IMAP extensions that solves the >> problem we're trying to solve. AND NO MORE. METADATA falls on the >> wrong side of that balance and thus needs to be excised from Lemonade. > > +1 -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:02:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Bs-0001Zl-IW; Wed, 19 Dec 2007 14:02:48 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54Br-0001WA-A8 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:02:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Bq-0001W2-Vx for lemonade@ietf.org; Wed, 19 Dec 2007 14:02:47 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54Bq-0002Ia-Gg for lemonade@ietf.org; Wed, 19 Dec 2007 14:02:46 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 19:02:45 +0000 Message-ID: <47696ACC.2070906@isode.com> Date: Wed, 19 Dec 2007 19:02:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <47694C96.9090206@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Wed, 19 Dec 2007, Alexey Melnikov wrote: > >> Mark, why would you say that? > > Multiple interlocking interdependecies frighten me. So does the > inclusion of facilities that are not absolutely necessary for mobile > devices ("nice to have" is not the same). > > These should frighten you too. They frighten me too. But this concern needs to be balanced against the need to have (a) a list of available facilities that is usable by mobile devices and (b) it is better to reuse protocol pieces, if possible. You've originally commented on something which is not a final product yet. You should let the WG decide on the final choice first (and of course you should provide your feedback on that choice before it becomes final). > Lemonade really needed a mini-IMAP. It did maxi-IMAP instead. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54F0-0004gT-DS; Wed, 19 Dec 2007 14:06:02 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54Ez-0004gN-0N for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:06:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Ey-0004gF-Md for lemonade@ietf.org; Wed, 19 Dec 2007 14:06:00 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J54Ey-0004wy-7N for lemonade@ietf.org; Wed, 19 Dec 2007 14:06:00 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 19:05:58 +0000 Message-ID: <47696B8E.4030805@isode.com> Date: Wed, 19 Dec 2007 19:05:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dan Karp Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications References: <1716662269.15121198085280450.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1716662269.15121198085280450.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >>ADMIN-1: It MUST be possible to provision the mobile email client, based >>on any combination of who the user is and what the device is. >>ADMIN-4: Authorized principals MUST be able to configure the settings of >>the user preferences/filters/configurable settings for a particular user >>ADMIN-7: It MUST be possible for a user to view, edit and reset settings >>of a mobile email client >>USAB-11: The mobile email enabler MUST support: >> Different methods for notifying the client about new emails based >>on capabilities of the network >> The ability for the user to select the transport method based on >>the capabilities of the client and network (e.g. SMS, Push, MMS etc) >> The ability for the user to select if, when and how events are >>accessed by the client >>USAB-16: Authorized principals MUST be able to select the ways that >>email events are sent to or accessed by the mobile email client and >>other email settings that may affect the server behaviour >>USAB-28: The mobile email enabler SHOULD support activation/deactivation >>of auto-reply from the client. Automatically generated replies SHOULD >>avoid mail loops (RFC 2821 and related RFCs) >> >> >Forgive me if I've misunderstood, but this seems like a significant >expansion of Lemonade. > While I think I already got all response I needed on this subject, I am replying to this for completeness. I've already mentioned storing SEARCH criteria on the server in another thread. I would also note that "USAB-11" was addressed in earlier versions of draft-ietf-lemonade-notifications. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:06:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54FK-0005D2-2M; Wed, 19 Dec 2007 14:06:22 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54FI-0005Ce-3v for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:06:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54FH-0005CV-Po for lemonade@ietf.org; Wed, 19 Dec 2007 14:06:19 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54FH-0002NF-GQ for lemonade@ietf.org; Wed, 19 Dec 2007 14:06:19 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 033C2DE92E7; Wed, 19 Dec 2007 11:06:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id D891E185CF1; Wed, 19 Dec 2007 11:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXAXfP6hdsFj; Wed, 19 Dec 2007 11:06:12 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 0E6E9185CE5; Wed, 19 Dec 2007 11:06:12 -0800 (PST) Date: Wed, 19 Dec 2007 11:06:11 -0800 (PST) From: Dan Karp To: Curtis King Message-ID: <1792079180.22741198091171861.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <20DD3C95-E30F-4E9A-B65F-6EB4DBE1BF9B@mumbo.ca> Subject: Re: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Lemonade WG , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > I almost agree with you. Almost, because support for virtual views > > is missing one small piece, which is storing search filters on IMAP > > server (draft-melnikov-imapext-filters-02.txt). This piece currently > > depends on per-user METADATA. > > Which it shouldn't. +1 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54LE-00007e-Lk; Wed, 19 Dec 2007 14:12:28 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54LE-00007O-2W for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:12:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54LD-00007G-P7 for lemonade@ietf.org; Wed, 19 Dec 2007 14:12:27 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J54LD-00053q-Bz for lemonade@ietf.org; Wed, 19 Dec 2007 14:12:27 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 19:12:25 +0000 Message-ID: <47696D10.5080302@isode.com> Date: Wed, 19 Dec 2007 19:12:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dan Karp References: <1792079180.22741198091171861.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1792079180.22741198091171861.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Lemonade WG Subject: [lemonade] Include draft-melnikov-imapext-filters into Lemonade Profile Bis? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >>>I almost agree with you. Almost, because support for virtual views >>>is missing one small piece, which is storing search filters on IMAP >>>server (draft-melnikov-imapext-filters-02.txt). This piece currently >>>depends on per-user METADATA. >>> >>> >>Which it shouldn't. >> >> >+1 > > Am I correct in interpreting that as: 1). People would like to make draft-melnikov-imapext-filters independent of METADATA (so that it can be used with METADATA, ACAP, LDAP, XCAP, whatever) 2). People would like to include draft-melnikov-imapext-filters (after it is updated as described in 1) into Profile Bis, because they agree it is a missing piece? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54LU-0000SR-Vb; Wed, 19 Dec 2007 14:12:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54LU-0000SJ-4t for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:12:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54LT-0000SB-RF for lemonade@ietf.org; Wed, 19 Dec 2007 14:12:43 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J54LT-000544-Hf for lemonade@ietf.org; Wed, 19 Dec 2007 14:12:43 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id 208F8DE92FB; Wed, 19 Dec 2007 11:12:43 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id A641A185CF4; Wed, 19 Dec 2007 11:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDo-ttH5c5El; Wed, 19 Dec 2007 11:12:36 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id BC3D6185CE5; Wed, 19 Dec 2007 11:12:36 -0800 (PST) Date: Wed, 19 Dec 2007 11:12:36 -0800 (PST) From: Dan Karp To: Alexey Melnikov Message-ID: <564853245.23091198091556463.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <476963B4.7000802@isode.com> Subject: Re: [lemonade] WGLC CONVERT MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > We should also include the expected transcoding behavior for messages > > that encode compound headers using the illegal-but-popular mechanism > > of RFC 2047 encoded-words inside quoted-strings. > > If it is illegal according to RFC 2047, then we don't need to mention > how to deal with them. GIGO. A large percentage of past and current MUAs generate and parse that illegal garbage, mainly because RFC 2231 support is still fairly rare. Ignoring this particular way of encoding strings in compound headers in the CONVERT draft just ignores much of the non-ASCII mail out there. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Of-0002J4-Az; Wed, 19 Dec 2007 14:16:01 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54Oe-0002Bx-5N for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:16:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Od-00028x-P7 for lemonade@ietf.org; Wed, 19 Dec 2007 14:15:59 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54Od-0002ad-9C for lemonade@ietf.org; Wed, 19 Dec 2007 14:15:59 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 19:15:57 +0000 Message-ID: <47696DE4.6030307@isode.com> Date: Wed, 19 Dec 2007 19:15:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <6840.1198079247.296478@peirce.dave.cridland.net> In-Reply-To: <6840.1198079247.296478@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > This gets us something that would look like: > > A01 MEDIACAPS ("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" > "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" > ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320") > > I've chosen a fairly complex, but hopefully concise, syntax here. > > The client is saying (each parenthesized list converted to a > sentence): "I do text/html. I will also do text/plain, preferably > with format=flowed, but I can handle format=fixed too. For all text > media types I do, I can handle a charset of either UTF-8 or US-ASCII. > I can handle image/jpge, image/png, and, least preferred, image/gif, > and my ideal resolution is 240x320." I couldn't immediately spot > anything for colour depth, but you get the idea. Whatever you do, make sure that is works for desktop clients, which might support hundreds of MIME types (via OS facilities) and might not be able to know in advance which conversion parameters are supported by which MIME types. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Qz-0005Zz-Rr; Wed, 19 Dec 2007 14:18:25 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54Qz-0005ZW-1K for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:18:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Qy-0005YP-N0 for lemonade@ietf.org; Wed, 19 Dec 2007 14:18:24 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54Qy-0002eG-Cw for lemonade@ietf.org; Wed, 19 Dec 2007 14:18:24 -0500 Received: from dogfood.zimbra.com (dsl092-025-198.sfo1.dsl.speakeasy.net [66.92.25.198]) by mta01.zimbra.com (Postfix) with ESMTP id 08079DE8F43; Wed, 19 Dec 2007 11:18:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CDDBA185CF2; Wed, 19 Dec 2007 11:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFq0mbwAso02; Wed, 19 Dec 2007 11:18:17 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id D1049185CF4; Wed, 19 Dec 2007 11:18:16 -0800 (PST) Date: Wed, 19 Dec 2007 11:18:16 -0800 (PST) From: Dan Karp To: Alexey Melnikov Message-ID: <94182959.23481198091896693.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <47696D10.5080302@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Lemonade WG Subject: [lemonade] Re: Include draft-melnikov-imapext-filters into Lemonade Profile Bis? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Am I correct in interpreting that as: > 1). People would like to make draft-melnikov-imapext-filters independent > of METADATA (so that it can be used with METADATA, ACAP, LDAP, XCAP, > whatever) Yes. I'd think it'd make more sense as an extension to CONTEXT=SEARCH. > 2). People would like to include draft-melnikov-imapext-filters (after > it is updated as described in 1) into Profile Bis, because they agree it > is a missing piece? No. I don't see a screaming need for it in Lemonade. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Xk-0000XN-3K; Wed, 19 Dec 2007 14:25:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J54Xj-0000XH-4S for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:25:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54Xi-0000X8-QJ for lemonade@ietf.org; Wed, 19 Dec 2007 14:25:22 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54Xi-0002oK-Ar for lemonade@ietf.org; Wed, 19 Dec 2007 14:25:22 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 19:25:20 +0000 Message-ID: <47697016.3010608@isode.com> Date: Wed, 19 Dec 2007 19:25:10 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dan Karp References: <94182959.23481198091896693.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <94182959.23481198091896693.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Lemonade WG Subject: [lemonade] Re: Include draft-melnikov-imapext-filters into Lemonade Profile Bis? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >>Am I correct in interpreting that as: >>1). People would like to make draft-melnikov-imapext-filters independent= =20 >>of METADATA (so that it can be used with METADATA, ACAP, LDAP, XCAP,=20 >>whatever) >> =20 >> >Yes. > Ok. >I'd think it'd make more sense as an extension to CONTEXT=3DSEARCH. > =20 > It is a syntactically independent extension and can be used in a regular=20 SEARCH. >>2). People would like to include draft-melnikov-imapext-filters (after >>it is updated as described in 1) into Profile Bis, because they agree it= =20 >>is a missing piece? >> =20 >> >No. I don't see a screaming need for it in Lemonade. > =20 > As a server guy and as an author of the document I am not really allowed=20 to have an opinion ;-). I can only proxy Roger Gr=C3=B6nberg from Momail on this. He requested this= =20 functionality during the Lemonade interop in Munich. (And I've already mentioned the OMA MEM requirement) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J552F-00026x-Ut; Wed, 19 Dec 2007 14:56:55 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J552F-00026r-1x for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:56:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J552E-00026j-NT for lemonade@ietf.org; Wed, 19 Dec 2007 14:56:54 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J552E-0003V8-8C for lemonade@ietf.org; Wed, 19 Dec 2007 14:56:54 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 566EE4AC5B for ; Wed, 19 Dec 2007 20:56:50 +0100 (CET) Message-Id: <2mQZbIKnI81IpxJ2b1a3Ow.md5@libertango.oryx.com> Date: Wed, 19 Dec 2007 20:54:49 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <6840.1198079247.296478@peirce.dave.cridland.net> <47696DE4.6030307@isode.com> In-Reply-To: <47696DE4.6030307@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Whatever you do, make sure that is works for desktop clients, which > might support hundreds of MIME types (via OS facilities) and might > not be able to know in advance which conversion parameters are > supported by which MIME types. Why is that even interesting? Why would a desktop client with support for hundres of mime types (and presumably lots of RAM, hard disk and bandwidth, and no limited battery) want to use CONVERT at all? (Yeah, I know, I should be packing the suitcases.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 14:58:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J554D-0003ip-43; Wed, 19 Dec 2007 14:58:57 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J554C-0003ii-Ev for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J554C-0003ia-5H for lemonade@ietf.org; Wed, 19 Dec 2007 14:58:56 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J554B-0005ts-EM for lemonade@ietf.org; Wed, 19 Dec 2007 14:58:56 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJJws1n013421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Dec 2007 11:58:54 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBJJws9l003495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Dec 2007 11:58:54 -0800 Date: Wed, 19 Dec 2007 11:58:29 -0800 (Pacific Standard Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt In-Reply-To: <47696ACC.2070906@isode.com> Message-ID: References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <47694C96.9090206@isode.com> <47696ACC.2070906@isode.com> User-Agent: Alpine 1.00 (WNT 873 2007-12-15) Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.19.113939 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 19 Dec 2007, Alexey Melnikov wrote: > They frighten me too. But this concern needs to be balanced against the need > to have (a) a list of available facilities that is usable by mobile devices > and (b) it is better to reuse protocol pieces, if possible. These are desirable goals, but the overriding concern must be simplicity. It doesn't matter that a new feature is small, or that it is simple to implement in [your | my] server, or that it would make life much easier for a nice guy who's a client implementor. If the proposal is not absolutely necessary to the goal, it should be rejected; furthermore, if the proposal creates a dependency on something that is not absolutely necessary to the goal, it should also be rejected. > You've originally commented on something which is not a final product yet. > You should let the WG decide on the final choice first (and of course you > should provide your feedback on that choice before it becomes final). "Please wait for us to finish our work before commenting" is subsequently replaced with "the time to complain about this was when we were doing our work, and it's entirely too late to say anything now" (or a injured "why didn't you say something earlier?"). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:02:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J557F-00025h-V1; Wed, 19 Dec 2007 15:02:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J557E-00025X-F6 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:02:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J557E-00024m-20 for lemonade@ietf.org; Wed, 19 Dec 2007 15:02:04 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J557D-0003fP-Ae for lemonade@ietf.org; Wed, 19 Dec 2007 15:02:03 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Dec 2007 20:02:01 +0000 Message-ID: <476978AC.6060701@isode.com> Date: Wed, 19 Dec 2007 20:01:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [lemonade] Should Sieve extensions be included into Profile Bis? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi everyone, I hope if I am starting another rant it is going to be a short one ;-). Just to be clear, I am currently stating no opinion on whether this should be a part of Lemonade Profile Bis document or not. But looking at the list of requirements from OMA MEM I can see that several of them can be addressed by Sieve (invoked on message delivery) + some existing Sieve extensions: USAB-9: When connectivity is not available or drops, email events on the client that may take place MUST be stored on the client until connectivity becomes available and then sent to the email server as soon as possible. The mobile email enabler MUST allow the user to set filtering rules based on Email header fields Mailbox folder options. Spam score. USAB-10: The mobile email enabler MUST allow the user to change filtering rules on his mobile email client. USAB-11: The mobile email enabler MUST support: Different methods for notifying the client about new emails based on capabilities of the network The ability for the user to select the transport method based on the capabilities of the client and network (e.g. SMS, Push, MMS etc) The ability for the user to select if, when and how events are accessed by the client USAB-12: The mobile email enabler MUST support the use of a number of different means to transport notifications this could include SMS, MMS, WAP Push, SIP Notification, UDP, in band, polled) USAB-27: The mobile email enabler SHOULD support definition of auto-reply messages for each filtered messages. Automatically generated replies SHOULD avoid mail loops (RFC 2821 and related RFCs) And also possibly: SEC-10: The mobile email enabler MUST support spam protection SEC-11: The mobile email enabler MUST support virus protection ======== Here is my take on how these requirements can be addressed: USAB-9 can be satisfied by the base Sieve (draft-ietf-sieve-3028bis-13.txt, soon to become a new RFC). The last point is also related to draft-ietf-sieve-spamtestbis-05.txt (soon to become a new RFC). USAB-10 can be satisfied by the base Sieve (draft-ietf-sieve-3028bis-13.txt) + by a Sieve management protocol (multiple choices). USAB-11 and USAB-12 can be satisfied by the Sieve notify framework (draft-ietf-sieve-notify-11.txt, in IESG review now) and possibly by draft-melnikov-sieve-imapext-metadata-02.txt. USAB-27 can be satisfied by the Sieve vacation extension (draft-ietf-sieve-vacation-07.txt, soon to become a new RFC) And finally SEC-10 and SEC-11 can be partially satisfied by draft-ietf-sieve-spamtestbis-05.txt ======== So, if the WG decides to defined Sieve related requirements in the Lemonade Profile Bis document, here is my suggestion: Sieve email filtering language (draft-ietf-sieve-3028bis-13.txt) Sieve vacation extension (draft-ietf-sieve-vacation-07.txt) Sieve notify extension (draft-ietf-sieve-notify-11.txt) But to be more useful for clients (in particular to allow clients to control vacation auto-replies without rewriting Sieve scripts, etc.) I would also recommend the following: Sieve variables extension (draft-ietf-sieve-variables-08, soon to be a new RFC) Sieve extension for accessing IMAP METADATA (draft-melnikov-sieve-imapext-metadata-02.txt) Sieve relational test (draft-ietf-sieve-3431bis-04.txt) If there is a decision to include this into Lemonade Profile Bis, then this list would become a new section titled "Requirements on Lemonade-compliant Sieve engines". Regards, Alexey P.S. At this point I don't see any need for IMAP Sieve (i.e. invocation of Sieve scripts on flag change, IMAP APPEND/COPY or message expunge events). I think IMAP Sieve is important, but not for Lemonade purposes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55Bm-0004nZ-HM; Wed, 19 Dec 2007 15:06:46 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J55Bl-0004mK-OH for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:06:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55Bl-0004l9-Cw for lemonade@ietf.org; Wed, 19 Dec 2007 15:06:45 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J55Bk-0003mb-Ql for lemonade@ietf.org; Wed, 19 Dec 2007 15:06:45 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Wed, 19 Dec 2007 20:06:40 +0000 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1195617645.11771198081933998.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1195617645.11771198081933998.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <11315.1198094793.842681@peirce.dave.cridland.net> Date: Wed, 19 Dec 2007 20:06:33 +0000 From: Dave Cridland To: Dan Karp Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Dec 19 16:32:14 2007, Dan Karp wrote: > > > METADATA falls on the wrong side of that balance and thus needs > to > > > be excised from Lemonade. > > > I agree with the latter, but for somewhat different reasons. I > don't > think metadata is a good fit for the problem. I like Dave's > suggestion > > rather better. > > I think I'd lean towards Dave's solution as the right one as well. You're making it sound like it's an either/or case, and I think it's a "both". There are two use-cases: 1) "Give me this part in a way that I probably understand it!" 2) "What can I turn this part into?" The first is handled by default conversion, the missing bit has always been that we have no method for telling the server what we probably understand. This missing bit is what I've proposed. The second is currently handled by METADATA based discovery, which seems reasonable, excepting the case where the part involved is application/octet-stream or otherwise mis-typed. A counter-proposal would, for me, need to address this case, as well as remaining capable of operating by type, rather than only on a specific part. I suspect that mobile clients will generally only use (1), whereas desktop clients will use both. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55Eu-0006Rd-Ux; Wed, 19 Dec 2007 15:10:00 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J55Et-0006R0-H2 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:09:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55Et-0006Qh-6O for lemonade@ietf.org; Wed, 19 Dec 2007 15:09:59 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J55Es-0003vs-Ob for lemonade@ietf.org; Wed, 19 Dec 2007 15:09:59 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Wed, 19 Dec 2007 20:09:50 +0000 X-SMTP-Protocol-Errors: PIPELINING Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <6840.1198079247.296478@peirce.dave.cridland.net> <47696DE4.6030307@isode.com> <2mQZbIKnI81IpxJ2b1a3Ow.md5@libertango.oryx.com> In-Reply-To: <2mQZbIKnI81IpxJ2b1a3Ow.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <11315.1198094990.127591@peirce.dave.cridland.net> Date: Wed, 19 Dec 2007 20:09:50 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Dec 19 19:54:49 2007, Arnt Gulbrandsen wrote: > Alexey Melnikov writes: >> Whatever you do, make sure that is works for desktop clients, >> which might support hundreds of MIME types (via OS facilities) and >> might not be able to know in advance which conversion parameters >> are supported by which MIME types. > > Why is that even interesting? Why would a desktop client with > support for hundres of mime types (and presumably lots of RAM, hard > disk and bandwidth, and no limited battery) want to use CONVERT at > all? Well, there's the laptop-on-a-train scenario that I often find myself in. Plenty of RAM, disk, and sometimes even mains power, but not a lot of bandwidth. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55LC-0002uE-DW; Wed, 19 Dec 2007 15:16:30 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J55LB-0002re-Kj for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:16:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55LB-0002nv-7b for lemonade@ietf.org; Wed, 19 Dec 2007 15:16:29 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J55LA-0004Ej-K2 for lemonade@ietf.org; Wed, 19 Dec 2007 15:16:29 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Wed, 19 Dec 2007 20:16:24 +0000 Subject: RE: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications References: <47691CC8.7020903@isode.com> <038501c8426a$7c8c3870$5700a8c0@DGCSonyFS> In-Reply-To: <038501c8426a$7c8c3870$5700a8c0@DGCSonyFS> MIME-Version: 1.0 Message-Id: <11315.1198095381.303084@peirce.dave.cridland.net> Date: Wed, 19 Dec 2007 20:16:21 +0000 From: Dave Cridland To: Darryl Champagne Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Dec 19 18:10:49 2007, Darryl Champagne wrote: > > These are valid problems to solve but have nothing to-do with > IMAP. (Agreed) > > They should be solved using an other protocol for example ACAP, > LDAP > > or LACAP. Pushing everything into IMAP is wrong and needs to > stop, as > > IMAP is coming complex enough just solving the core problem of > pushing > > email to a mobile client. > > (Agreed, although s/mobile/restricted/) > > I have no problem with expanding lemonade to include mobile > > configuration, so OMA MEM keeps one contact group within IETF. If another WG were setup to handle this, then Lemonade would be the logical place to put those peices into the form of a support package for diverse environments. It'd be effectively similar to IMAPEXT's development of CONDSTORE et al. > It's also worth remembering that OMA already has a > provisioning/Device > Management specification/Enabler, DM, which is deployed on 95+% of > the > handsets produced this year ***. Use of DM would essentially isolate the mobile world from the desktop. So settings made on a desktop cleint wouldn't propogate to the mobile device. I've seen the effect this facility has on people first hand - people are impressed with the concept that they configure their desktop client and the mobile device client follows suite. I'm also less than convinced by XCAP - it requires SIP to be by any reasonable definition "useful", and mandating SIP in every MUA is just not going to happen. Of course, I'm biased, I've used ACAP for these purposes for years now, but I didn't pick that technology because it had a cool name, nor have I stuck with it out of some weird sense of pride. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55La-0003sr-55; Wed, 19 Dec 2007 15:16:54 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J55LZ-0003oQ-F8 for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:16:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55LZ-0003mI-33 for lemonade@ietf.org; Wed, 19 Dec 2007 15:16:53 -0500 Received: from mta01.zimbra.com ([77.67.121.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J55LY-0004FL-Iz for lemonade@ietf.org; Wed, 19 Dec 2007 15:16:52 -0500 Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.130.20]) by mta01.zimbra.com (Postfix) with ESMTP id 08E11DE92AE; Wed, 19 Dec 2007 12:16:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8448C185CF2; Wed, 19 Dec 2007 12:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJRTWov578NG; Wed, 19 Dec 2007 12:16:44 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 7E741185CE5; Wed, 19 Dec 2007 12:16:44 -0800 (PST) Date: Wed, 19 Dec 2007 12:16:44 -0800 (PST) From: Dan Karp To: Dave Cridland Message-ID: <39741682.27961198095404218.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <11315.1198094793.842681@peirce.dave.cridland.net> Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.130.163.17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > I think I'd lean towards Dave's solution as the right one as well. > > There are two use-cases: > 1) "Give me this part in a way that I probably understand it!" > 2) "What can I turn this part into?" > > The second is currently handled by METADATA based discovery, which > seems reasonable, excepting the case where the part involved is > application/octet-stream or otherwise mis-typed. A counter-proposal > would, for me, need to address this case, as well as remaining > capable of operating by type, rather than only on a specific part. I'm not convinced that there's a real-world need for a solution to the second use case. Odds are that your desktop client can handle far more MIME types than your server can convert. I also think that solving the second use case is not a Lemonade problem. A solution that nails the first use case should suffice. But if you must have an alternate solution, here's the one I sent out a little while back: CONVERSIONS where and are partially or completely wildcardable. For instance, for conversion info from GIF to JPEG (no untagged CONVERT would be returned if no conversion was possible): C: a CONVERSIONS "image/gif" "image/jpeg" S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced") S: a OK CONVERSIONS completed For conversion info from GIF to anything: C: b CONVERSIONS "image/gif" * S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced") S: * CONVERT "image/gif" "image/png" (...) S: ... S: b OK CONVERSIONS completed For conversion of anything to JPEG: C: c CONVERSIONS * "image/jpeg" S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced") S: * CONVERT "image/png" "image/jpeg" (...) S: ... S: c OK CONVERSIONS completed For conversions from all image formats to all text formats (maybe via OCR?): C: d CONVERSIONS "image/*" "text/*" S: d OK CONVERSIONS completed _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55cH-0002wE-9R; Wed, 19 Dec 2007 15:34:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J55cF-0002vY-Pb for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:34:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55cF-0002vQ-FE for lemonade@ietf.org; Wed, 19 Dec 2007 15:34:07 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J55cE-0004g4-TV for lemonade@ietf.org; Wed, 19 Dec 2007 15:34:07 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D14F94AC7F for ; Wed, 19 Dec 2007 21:34:03 +0100 (CET) Message-Id: Date: Wed, 19 Dec 2007 21:32:03 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt References: <1253716212.11911198011610435.JavaMail.root@dogfood.zimbra.com> <476923C4.5020105@andrew.cmu.edu> <6840.1198079247.296478@peirce.dave.cridland.net> <47696DE4.6030307@isode.com> <2mQZbIKnI81IpxJ2b1a3Ow.md5@libertango.oryx.com> <11315.1198094990.127591@peirce.dave.cridland.net> In-Reply-To: <11315.1198094990.127591@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Wed Dec 19 19:54:49 2007, Arnt Gulbrandsen wrote: >> Alexey Melnikov writes: >>> Whatever you do, make sure that is works for desktop clients, which >>> might support hundreds of MIME types (via OS facilities) and might >>> not be able to know in advance which conversion parameters are >>> supported by which MIME types. >> >> Why is that even interesting? Why would a desktop client with >> support for hundres of mime types (and presumably lots of RAM, hard >> disk and bandwidth, and no limited battery) want to use CONVERT at >> all? > > Well, there's the laptop-on-a-train scenario that I often find myself > in. Plenty of RAM, disk, and sometimes even mains power, but not a > lot of bandwidth. In which case I presume the MUA would carefully specify e.g. only jpeg, not all of the dozens of image types for which the OS provides support, so as to avoid getting a 64-bits-per-pixel uncompressed image (16 bits R, G, B and alpha - I've seen worse) in a format the OS supports but the MUA doesn't know about. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 19 15:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55qu-00036X-Jp; Wed, 19 Dec 2007 15:49:16 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J55qs-00036B-Ti for lemonade-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:49:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55qs-000362-JI for lemonade@ietf.org; Wed, 19 Dec 2007 15:49:14 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J55qr-00055B-Vz for lemonade@ietf.org; Wed, 19 Dec 2007 15:49:14 -0500 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lBJKn0EU028454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 15:49:02 -0500 Date: Wed, 19 Dec 2007 15:48:55 -0500 From: Cyrus Daboo To: Dave Cridland , Darryl Champagne Subject: RE: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications Message-ID: <3F633EF99366F14CC7BCB753@caldav.corp.apple.com> In-Reply-To: <11315.1198095381.303084@peirce.dave.cridland.net> References: <47691CC8.7020903@isode.com> <038501c8426a$7c8c3870$5700a8c0@DGCSonyFS> <11315.1198095381.303084@peirce.dave.cridland.net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On December 19, 2007 8:16:21 PM +0000 Dave Cridland wrote: > I'm also less than convinced by XCAP - it requires SIP to be by any > reasonable definition "useful", and mandating SIP in every MUA is just > not going to happen. > > Of course, I'm biased, I've used ACAP for these purposes for years now, > but I didn't pick that technology because it had a cool name, nor have I > stuck with it out of some weird sense of pride. My feeling is XCAP will work just fine and there really is no absolute requirement on implementing SIP. XCAP would be an order of magnitude more easy to implement on both clients and servers, but then again it does not attempt to address all the bells and whistles that ACAP does. But I believe it would be sufficient for the key requirements we would have. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Dec 20 15:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SKq-0007WN-J3; Thu, 20 Dec 2007 15:49:40 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J5SKp-0007R2-5J for lemonade-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 15:49:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SKo-0007NO-0Z for lemonade@ietf.org; Thu, 20 Dec 2007 15:49:38 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5SKn-0002RZ-MF for lemonade@ietf.org; Thu, 20 Dec 2007 15:49:37 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBKKnbBI012450 for ; Thu, 20 Dec 2007 20:49:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTD009015T4YR00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Thu, 20 Dec 2007 13:49:37 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTD00EEF8IDJV20@mail-amer.sun.com> for lemonade@ietf.org; Thu, 20 Dec 2007 13:49:27 -0700 (MST) Date: Thu, 20 Dec 2007 12:49:00 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <02c901c84349$c1089d60$4319d820$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: AchDSb91qntjMheoR4iAeuTPD1FePQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [lemonade] notify 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="===============0912167896==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============0912167896== Content-type: multipart/alternative; boundary="Boundary_(ID_1cpriB24oZbbTHKu/cQAxw)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_1cpriB24oZbbTHKu/cQAxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I have a problem with the quotachange notification. I have quota, and I even have notifications about quota. But quota for me can be by user, by mailbox, by subtree, by messagetype. It is hard (and possibly meaningless) to implement notification on quotachange by mailboxname or subtree. This needs rethinking. Also, the point of having notifications add was to keep (and augment) the functionality for clients while simplifying the syntax of the command. If notifications are add, then the command only need deal with one event-group. It is likely that some servers will have a greater or lesser ability to implement all the functionality of this command. They may or may not be able to support all the event types. This suggests tome that either the capability advertised for this indicate what is actually available, or the error reporting on this command be spelt out allowing the server to indicate what it couldn't do. Peter --Boundary_(ID_1cpriB24oZbbTHKu/cQAxw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I have a problem with the quotachange notification.  I have quota, and I even have notifications about quota.  But quota for me can be by user, by mailbox, by subtree, by messagetype.  It is hard (and possibly meaningless) to implement notification on quotachange by mailboxname or subtree.  This needs rethinking.

 

Also, the point of having notifications add was to keep (and augment) the functionality for clients while simplifying the syntax of the command.  If notifications are add, then the command only need deal with one event-group.

 

It is likely that some servers will have a greater or lesser ability to implement all the functionality of this command.  They may or may not be able to support all the event types.  This suggests tome that either the capability advertised for this indicate what is actually available, or the error reporting on this command be spelt out allowing the server to indicate what it couldn’t do.

 

Peter

--Boundary_(ID_1cpriB24oZbbTHKu/cQAxw)-- --===============0912167896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0912167896==-- From lemonade-bounces@ietf.org Thu Dec 20 16:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Sek-0005Yw-Um; Thu, 20 Dec 2007 16:10:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J5Sej-0005JG-Jn for lemonade-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Sei-0005Bg-TH for lemonade@ietf.org; Thu, 20 Dec 2007 16:10:12 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5Sei-0003oD-DP for lemonade@ietf.org; Thu, 20 Dec 2007 16:10:12 -0500 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lBKLA2vw016716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 16:10:04 -0500 Date: Thu, 20 Dec 2007 16:09:57 -0500 From: Cyrus Daboo To: Peter Coates , lemonade@ietf.org Subject: Re: [lemonade] notify Message-ID: In-Reply-To: <02c901c84349$c1089d60$4319d820$%coates@sun.com> References: <02c901c84349$c1089d60$4319d820$%coates@sun.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 1.8 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Peter, --On December 20, 2007 12:49:00 PM -0800 Peter Coates=20 wrote: > I have a problem with the quotachange notification. I have quota, and I > even have notifications about quota. But quota for me can be by user, by > mailbox, by subtree, by messagetype. It is hard (and possibly > meaningless) to implement notification on quotachange by mailboxname or > subtree. This needs rethinking. > > > > Also, the point of having notifications add was to keep (and augment) the > functionality for clients while simplifying the syntax of the command. > If notifications are add, then the command only need deal with one > event-group. > > > > It is likely that some servers will have a greater or lesser ability to > implement all the functionality of this command. They may or may not be > able to support all the event types. This suggests tome that either the > capability advertised for this indicate what is actually available, or > the error reporting on this command be spelt out allowing the server to > indicate what it couldn=E2=80=99t do. There was discussion at the meeting on removing a number of non-essential=20 event types from the base spec. My belief is that quota and acl changes should definitely go. Note that many servers already support over quota messages via the existing = [ALERT] mechanism. Those you can receive during IDLE already, if I am not=20 mistaken. --=20 Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Dec 21 18:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5r2J-00029m-B8; Fri, 21 Dec 2007 18:12:11 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J5r2G-00023f-OT for lemonade-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 18:12:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5r2G-00023W-CQ for lemonade@ietf.org; Fri, 21 Dec 2007 18:12:08 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5r2G-0004Kb-2G for lemonade@ietf.org; Fri, 21 Dec 2007 18:12:08 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBLNC7m4024787 for ; Fri, 21 Dec 2007 23:12:07 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTF00D019S4M800@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 21 Dec 2007 16:12:07 -0700 (MST) Received: from kluane ([199.247.229.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTF00IWH9S4TS50@mail-amer.sun.com> for lemonade@ietf.org; Fri, 21 Dec 2007 16:12:06 -0700 (MST) Date: Fri, 21 Dec 2007 15:12:03 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <040901c84426$e7344e70$b59ceb50$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: AchEJuU2yZPYH5ILRSqJymnzCArH+Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [lemonade] NOTIFY 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="===============1601180220==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============1601180220== Content-type: multipart/alternative; boundary="Boundary_(ID_k2QZ9mw/IMrg5ZHwzuuY5A)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_k2QZ9mw/IMrg5ZHwzuuY5A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Well, I can authoritatively say that much of the NOTIFY specification is implementable as it stands with the following caveats (1) It is hard to do the necessary error recovery for partially successful commands. If the command is simplified in the manner suggested in my last email (get rid of SET/ADD, specify only one eventgroup per command), then error recovery becomes feasible (2) I have not experimented with implementing beyond the messagenew/messageexpunge/FlagChange/AnnotationChange events (3) I have a structural issue with reporting on a subset of messagenew/messageexpunge: do I have any hope of persuading people to combine these two? I base this assertion on having implemented these event types with a variant notify command of the sort I suggest. Kind of weird seeing a changeflag event being triggered by a BODY[.] fetch triggered by a notify. Peter --Boundary_(ID_k2QZ9mw/IMrg5ZHwzuuY5A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Well, I can authoritatively say that much of the NOTIFY specification is implementable as it stands with the following caveats

 

(1)    It is hard to do the necessary error recovery for partially successful commands.  If the command is simplified in the manner suggested in my last email (get rid of SET/ADD, specify only one eventgroup per command), then error recovery becomes feasible

(2)    I have not experimented with implementing beyond the messagenew/messageexpunge/FlagChange/AnnotationChange events

(3)    I have a structural issue with reporting on a subset of messagenew/messageexpunge: do I have any hope of persuading people to combine these two?

 

 

I base this assertion on having implemented these event types with a variant notify command of the sort I suggest.

 

Kind of weird seeing a changeflag event being triggered by a BODY[…] fetch triggered by a notify.

 

Peter 

--Boundary_(ID_k2QZ9mw/IMrg5ZHwzuuY5A)-- --===============1601180220== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1601180220==-- From lemonade-bounces@ietf.org Sat Dec 22 11:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J676E-0001Zi-01; Sat, 22 Dec 2007 11:21:18 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J676D-0001ZJ-4U for lemonade-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 11:21:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J676C-0001Z2-Ql; Sat, 22 Dec 2007 11:21:16 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J6767-0001lz-0P; Sat, 22 Dec 2007 11:21:16 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17476d9d4f; Sun, 23 Dec 2007 00:34:26 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm124768a011; Wed, 19 Dec 2007 06:33:19 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 19 Dec 2007 06:33:19 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqT-0001lB-HI; Tue, 18 Dec 2007 15:15:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqF-0001eK-EZ; Tue, 18 Dec 2007 15:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4iqF-0001vg-28; Tue, 18 Dec 2007 15:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B116D175BD; Tue, 18 Dec 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4iqE-0005iv-87; Tue, 18 Dec 2007 15:15: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: Tue, 18 Dec 2007 15:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 4.9 (++++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt X-BeenThere: lemonade@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP CONVERT extension Author(s) : A. Melnikov, P. Coates Filename : draft-ietf-lemonade-convert-13.txt Pages : 0 Date : 2007-12-18 CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.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-convert-13.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-convert-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-18140650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18140650.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sun Dec 23 16:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Xy8-0004E8-Ha; Sun, 23 Dec 2007 16:02:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J6Xy6-0004E3-Pz for lemonade-confirm+ok@megatron.ietf.org; Sun, 23 Dec 2007 16:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Xy6-0004Dv-GD for lemonade@ietf.org; Sun, 23 Dec 2007 16:02:42 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6Xy6-0003bE-1F for lemonade@ietf.org; Sun, 23 Dec 2007 16:02:42 -0500 Received: from [192.168.0.11] (atomnet2.ttr.ru [195.245.249.86]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Dec 2007 21:02:40 +0000 Message-ID: <476ECEAF.6050501@isode.com> Date: Mon, 24 Dec 2007 00:10:07 +0300 From: Alexey Melnikov User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: Peter Coates Subject: Re: [lemonade] notify References: <02c901c84349$c1089d60$4319d820$%coates@sun.com> In-Reply-To: <02c901c84349$c1089d60$4319d820$%coates@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable X-Spam-Score: 3.3 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Peter Coates wrote: > I have a problem with the quotachange notification. I have quota, and=20 > I even have notifications about quota. But quota for me can be by=20 > user, by mailbox, by subtree, by messagetype. It is hard (and possibly=20 > meaningless) to implement notification on quotachange by mailboxname=20 > or subtree. This needs rethinking. You are right. As IMAP QUOTA is not a part of Lemonade Profile Bis, I will be taking quota events out of the document. > Also, the point of having notifications add was to keep (and augment)=20 > the functionality for clients while simplifying the syntax of the=20 > command. If notifications are add, then the command only need deal=20 > with one event-group. > Considering that one can implement storing of event-groups as a linked list, I don't think this change would simplify anything. Besides, I think it is important to keep syntax consistent between NOTIFY SET and NOTIFY ADD. > It is likely that some servers will have a greater or lesser ability=20 > to implement all the functionality of this command. They may or may=20 > not be able to support all the event types. This suggests to me that=20 > either the capability advertised for this indicate what is actually=20 > available, or the error reporting on this command be spelt out=20 > allowing the server to indicate what it couldn=92t do. I've already added the latter (a new BADEVENT response code). But I think the document should also define which events from the document are mandatory. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Dec 24 19:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6xTP-0001Sy-6N; Mon, 24 Dec 2007 19:16:43 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J6xTO-0001St-Pd for lemonade-confirm+ok@megatron.ietf.org; Mon, 24 Dec 2007 19:16:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6xTO-0001Sj-Dy for lemonade@ietf.org; Mon, 24 Dec 2007 19:16:42 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6xTN-0006JM-KO for lemonade@ietf.org; Mon, 24 Dec 2007 19:16:42 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBP0Gfb1021183 for ; Tue, 25 Dec 2007 00:16:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTK00G01WJJ1C00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 24 Dec 2007 17:16:41 -0700 (MST) Received: from kluane ([72.55.211.224]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTK00FIZWRSH100@mail-amer.sun.com>; Mon, 24 Dec 2007 17:16:41 -0700 (MST) Date: Mon, 24 Dec 2007 17:16:35 -0700 From: Peter Coates Subject: RE: [lemonade] notify In-reply-to: <476ECEAF.6050501@isode.com> To: "'Alexey Melnikov'" Message-id: <005801c8468b$698d1030$3ca73090$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-ca Content-transfer-encoding: 7BIT Thread-index: AchFpyrNn9Uf1nCzRBij0U4a898ZUwA4bzaw References: <02c901c84349$c1089d60$4319d820$%coates@sun.com> <476ECEAF.6050501@isode.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'm glad quota is out. Now the single event group thing. The object of my suggestion here is to minimize complexity for the server while maximizing functionality available. I see no gain whatsoever is having more than one event group on the command. Clients can as easily issue several notify commands each specifying a single event group as they can one command specifying several. Similarly though, it is as easy for the server to handle one as many... as long as we do not worry about error handling. IMAP commands are supposed to be atomic, all succeed or all fail. I suppose that there is little difference between allowing one mailboxes or a set of them and a set of subtrees. But reporting the cause of a failure just starts getting more difficult the more things you allow at once. I don't suppose for a moment I'm going to get traction on this, so I think I'll stop. But I will continue to think that this shows a continued lack of attention to error recovery, error recovery, and error handling in IMAP. Peter -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: December 23, 2007 14:10 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] notify Peter Coates wrote: > I have a problem with the quotachange notification. I have quota, and > I even have notifications about quota. But quota for me can be by > user, by mailbox, by subtree, by messagetype. It is hard (and possibly > meaningless) to implement notification on quotachange by mailboxname > or subtree. This needs rethinking. You are right. As IMAP QUOTA is not a part of Lemonade Profile Bis, I will be taking quota events out of the document. > Also, the point of having notifications add was to keep (and augment) > the functionality for clients while simplifying the syntax of the > command. If notifications are add, then the command only need deal > with one event-group. > Considering that one can implement storing of event-groups as a linked list, I don't think this change would simplify anything. Besides, I think it is important to keep syntax consistent between NOTIFY SET and NOTIFY ADD. > It is likely that some servers will have a greater or lesser ability > to implement all the functionality of this command. They may or may > not be able to support all the event types. This suggests to me that > either the capability advertised for this indicate what is actually > available, or the error reporting on this command be spelt out > allowing the server to indicate what it couldn't do. I've already added the latter (a new BADEVENT response code). But I think the document should also define which events from the document are mandatory. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Dec 26 14:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bic-0007Tf-7M; Wed, 26 Dec 2007 14:15:06 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J7biZ-0007Sq-9d for lemonade-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 14:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7biY-0007Sb-SG; Wed, 26 Dec 2007 14:15:02 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7biY-00038n-G9; Wed, 26 Dec 2007 14:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 275E7175AA; Wed, 26 Dec 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J7biX-0004Ei-ML; Wed, 26 Dec 2007 14:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Dec 2007 14:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-notify-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : The IMAP NOTIFY Extension Author(s) : C. King Filename : draft-ietf-lemonade-imap-notify-02.txt Pages : 17 Date : 2007-12-26 This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-notify-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-imap-notify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-notify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-26133525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-notify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-notify-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-26133525.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sat Dec 29 21:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8nwg-0000uo-8k; Sat, 29 Dec 2007 21:30:34 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1J8nwe-0000ug-Qh for lemonade-confirm+ok@megatron.ietf.org; Sat, 29 Dec 2007 21:30:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8nwe-0000uY-4a; Sat, 29 Dec 2007 21:30:32 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8nwd-0006En-Pl; Sat, 29 Dec 2007 21:30:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BCE0232897; Sun, 30 Dec 2007 02:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J8nw9-00005y-M6; Sat, 29 Dec 2007 21:30: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: Sat, 29 Dec 2007 21:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-architecture-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet Mail Author(s) : E. Burger, G. Parsons Filename : draft-ietf-lemonade-architecture-01.txt Pages : 14 Date : 2007-12-29 This document specifies the architecture for mobile email, as described by the OMA, using Internet Mail protocols. This architecture is the basis of the work of the LEMONADE WG and is a guideline for the LEMONADE Profile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-architecture-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-architecture-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-architecture-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-29212823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-architecture-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-architecture-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-29212823.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart--