From exim@www1.ietf.org Thu Jan 1 18:44:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27308 for ; Thu, 1 Jan 2004 18:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcCTx-0006W6-Rv for lemonade-archive@odin.ietf.org; Thu, 01 Jan 2004 18:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i01Ni1PZ025043 for lemonade-archive@odin.ietf.org; Thu, 1 Jan 2004 18:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcCTx-0006Vq-Mq for lemonade-web-archive@optimus.ietf.org; Thu, 01 Jan 2004 18:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27304 for ; Thu, 1 Jan 2004 18:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcCTu-00026J-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 18:43:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcCST-000230-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 18:42:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcCR7-0001zY-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 18:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcCR4-0006TK-Ue; Thu, 01 Jan 2004 18:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcCQJ-0006Sh-OO for lemonade@optimus.ietf.org; Thu, 01 Jan 2004 18:40:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27175 for ; Thu, 1 Jan 2004 18:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcCQG-0001xy-00 for lemonade@ietf.org; Thu, 01 Jan 2004 18:40:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcCP1-0001u9-00 for lemonade@ietf.org; Thu, 01 Jan 2004 18:38:58 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1AcCNd-0001q4-00 for lemonade@ietf.org; Thu, 01 Jan 2004 18:37:29 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i01NbR4l027263; Thu, 1 Jan 2004 15:37:27 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i01NbRWG017538; Thu, 1 Jan 2004 15:37:27 -0800 Date: Thu, 1 Jan 2004 15:37:27 -0800 (PST) From: Mark Crispin To: Ted Hardie cc: Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Wed, 31 Dec 2003, Ted Hardie wrote: > Deciding that the entire burden goes onto the IMAP server is contrary > to existing practice, in that folks in many environments use external > pointers by including URLs in their messages. I don't think that you understand what I'm getting at. People compose messages, using multiple sources, on a regular basis. Sometimes, they send a link in the form of a public-access URL. Other times, they include or attach data from a storage mechanism that they already have. This includes such things data from messages in other mailboxes (perhaps on other servers), data from files, perhaps even data from a private-access web page. Word documents, spreadsheets, PDFs, all sorts of things get sent. CATENATE as it stands is a very inadequate mechanism for the second case. However, with a very simple extension (ignoring a "thou shalt not" paragraph) CATENATE can be made to do everything that's needed. This presents an extremely attractive nuisance. You may think that this "isn't the common case." Well, maybe it's not for people who use cell phones for their email. But they aren't the only case of email users. For many email users (and client developers) there is a very attractive prospect of being able to have the server snarf the PDF file, instead of having to download it over a dialup to the client only to push it out again. Pull will do this. So will CATENATE with one little extension. > And while all of this is a very interesting, I think we have to go back > to the common use case, and ask ourselves whether "forward without > download", which is one of the immediately motivating cases here, > would require anything more than what an IMAP server can do > using the local mailboxes. Indeed. The advocates of pull have seen this coming from the onset. > And perhaps we ough to even ask the larger question "are we > optimizing for the right use case", since the client always has the > option of accessing and including content. Exactly. I believe that if you do so, fairly, you will conclude that pull is the superior solution. Another observation is that CATENATE is not draft-friendly. It is a one-shot assembly. CATENATE+SUBMIT is essentially doing in two operations on the IMAP server compared to one operation (e.g. BURL) on the submit server. Drafts have to be on the client (or stored in a way that the client can pick it apart to know how to CATENATE). A better solution that is draft-friendly would be to have some sort of reference to the text to be included at a particular point (possibly some MIME parameter could be used). Then have an ASSEMBLE command that knows how to do the insertions. That still is two commands, but doesn't have the draft-unfriendliness that CATENATE has. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Jan 1 22:14:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01092 for ; Thu, 1 Jan 2004 22:14:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcFlW-0003Rt-UM for lemonade-archive@odin.ietf.org; Thu, 01 Jan 2004 22:14:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i023EM17013251 for lemonade-archive@odin.ietf.org; Thu, 1 Jan 2004 22:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcFlW-0003Re-Cg for lemonade-web-archive@optimus.ietf.org; Thu, 01 Jan 2004 22:14:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01063 for ; Thu, 1 Jan 2004 22:14:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcFlT-00074e-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 22:14:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcFjK-00071r-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 22:12:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcFiL-0006yR-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 22:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcFiG-0003OH-VJ; Thu, 01 Jan 2004 22:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcFhn-0003Ms-8p for lemonade@optimus.ietf.org; Thu, 01 Jan 2004 22:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00964 for ; Thu, 1 Jan 2004 22:10:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcFhk-0006wP-00 for lemonade@ietf.org; Thu, 01 Jan 2004 22:10:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcFg9-0006q6-00 for lemonade@ietf.org; Thu, 01 Jan 2004 22:08:52 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AcFcb-0006d6-00 for lemonade@ietf.org; Thu, 01 Jan 2004 22:05:09 -0500 Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Thu, 1 Jan 2004 21:04:06 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Thu, 1 Jan 2004 21:04:02 -0600 To: Mark Crispin From: Pete Resnick Subject: RE: [lemonade] IMAP push/pull plan Cc: Ted Hardie , Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On 1/1/04 at 3:37 PM -0800, Mark Crispin wrote: >People compose messages, using multiple sources, on a regular basis. >Sometimes, they send a link in the form of a public-access URL. > >Other times, they include or attach data from a storage mechanism >that they already have. This includes such things data from >messages in other mailboxes (perhaps on other servers), data from >files, perhaps even data from a private-access web page. Word >documents, spreadsheets, PDFs, all sorts of things get sent. With an eye to the discussion below about "optimizing for the right use case", I think the vast majority of things in e-mail that come from different sources are: 1. Publicly-accessible resources which can be accessed via a URL at the remote end. 2. Things in local-to-the-client sources (word processing documents, spreadsheets, PDFs, that are on a device directly accessible by the client). 3. Things that are in my message store (which is either local-to-the-client or on a single IMAP server). and that only a small minority of things that are: 4. Things from other-than-a-single-IMAP-server privately-accessible sources that are "closer" (in terms of bandwidth, compute power, etc) to my submit server than to my client. Given that: >CATENATE as it stands is a very inadequate mechanism for the second case. This strikes me as inaccurate. Your second case is what I've labelled 2, 3, and 4, and CATENATE (as it stands) works perfectly well to collect 2 and 3, and is optimized for 3. It is (as you say) inadequate for 4, but I do think 4 makes up a tiny piece of what gets included in e-mail. >On Wed, 31 Dec 2003, Ted Hardie wrote: >>And perhaps we ough to even ask the larger question "are we >>optimizing for the right use case", since the client always has the >>option of accessing and including content. > >Exactly. I believe that if you do so, fairly, you will conclude >that pull is the superior solution. I think this is the crux of the debate for me. If you think that what you should be optimizing for is "local storage" and "what's on my IMAP server", I think that CATENATE+push is the superior solution. If you think that you should be optimizing for "content that is 'closer' to the submit server than to the local client" (which includes, but is not primarily, items on my single IMAP server), then pull is the superior solution. My leaning is that the former is the right use case. There are other things I like about CATENATE; see below: >Another observation is that CATENATE is not draft-friendly. It is a >one-shot assembly. CATENATE+SUBMIT is essentially doing in two >operations on the IMAP server compared to one operation (e.g. BURL) >on the submit server. Drafts have to be on the client (or stored in >a way that the client can pick it apart to know how to CATENATE). I think CATENATE is sufficiently draft-friendly. I see two choices for storing things in such a way that the client can retrieve a draft without having to download a part originally included from the IMAP store: 1. When CATENATE-ing, put a Content-Location on the part so that the client can notice from the BODYSTRUCTURE that the part was included from the local IMAP store. When the client CATENATE-s the new draft, you include what was in the Content-Location. The downside to this approach is that Content-Location would then be sent with the message, potentially introducing a security problem. 2. When CATENATE-ing, put a Content-ID on the part that has some local part that means to the client "I included this part". When the client looks at the draft, it sees this in the BODYSTRUCTURE. Then, when it CATENATE-s the new draft, it simply includes the part from the old draft (instead of from the original message). This is my preferred method. >A better solution that is draft-friendly would be to have some sort >of reference to the text to be included at a particular point >(possibly some MIME parameter could be used). Then have an ASSEMBLE >command that knows how to do the insertions. That still is two >commands, but doesn't have the draft-unfriendliness that CATENATE >has. We discussed something like this before (see 21 October discussion), where I said: At 1:49 PM -0500 10/21/03, Pete Resnick wrote: >The downside to expand is that you then have a message with >"expandable parts". That means that I can send you an "unexpanded >message" and perhaps invoke some unexpected shenanigans in your >server, perhaps getting it to expand things upon forwarding my >message that you didn't expect. I think the Content-ID trick makes CATENATE draft-friendly. And of course BURL is *completely* draft-unfriendly: With BURL, the draft *must* be stored on the local client. That's another reason I still like CATENATE even if we go for pull instead of push. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Jan 1 23:50:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03001 for ; Thu, 1 Jan 2004 23:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHG7-0005lK-Ic for lemonade-archive@odin.ietf.org; Thu, 01 Jan 2004 23:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i024o3hh022125 for lemonade-archive@odin.ietf.org; Thu, 1 Jan 2004 23:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHG6-0005kU-EN for lemonade-web-archive@optimus.ietf.org; Thu, 01 Jan 2004 23:50:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02980 for ; Thu, 1 Jan 2004 23:50:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHG4-0001lj-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 23:50:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHEG-0001hi-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 23:48:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcHCC-0001eN-00 for lemonade-web-archive@ietf.org; Thu, 01 Jan 2004 23:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHCC-0005cI-Bh; Thu, 01 Jan 2004 23:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHCA-0005c5-SR for lemonade@optimus.ietf.org; Thu, 01 Jan 2004 23:45:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02913 for ; Thu, 1 Jan 2004 23:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHC8-0001e0-00 for lemonade@ietf.org; Thu, 01 Jan 2004 23:45:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHAm-0001b2-00 for lemonade@ietf.org; Thu, 01 Jan 2004 23:44:35 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx with esmtp (Exim 4.12) id 1AcH8i-0001XK-00 for lemonade@ietf.org; Thu, 01 Jan 2004 23:42:24 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i024gMsr001607; Thu, 1 Jan 2004 20:42:22 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i024gMSA022440; Thu, 1 Jan 2004 20:42:22 -0800 Date: Thu, 1 Jan 2004 20:42:22 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Ted Hardie , Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Thu, 1 Jan 2004, Pete Resnick wrote: > And of course BURL > is *completely* draft-unfriendly: With BURL, the draft *must* be stored on the > local client. No. There is no more draft unfriendliness in BURL than there is in CATENATE/SUBMIT. If the draft message does not have any external parts, then: . BURL: an IMAP URL to the draft is submitted to the submit server. . CATENATE/SUBMIT: a SUBMIT command is done. If the draft message has external parts whose pointers are not in the draft but are known to the client, then: . BURL: an IMAP URL to the draft, along with URLs to the other parts, are submitted to the SUBMIT server. . CATENATE/SUBMIT: a CATENATE command is done, then a SUBMIT command. If the draft message has external parts that have pointers in the draft, then: . BURL: the BODYSTRUCTURE of the draft is fetched, the pieces determined, and then a set of URLs (including IMAP URLs to the texts in the draft) are submitted to the SUBMIT server . CATENATE/SUBMIT: the BODYSTRUCTURE of the draft is fetched, the pieces determined, the various pieces are put together via CATENATE, and then a SUBMIT command is done. None of the above is truly "draft-friendly". What would be draft-friendly is if the submit mechanism could recognize the pointers and do the assembly itself. CATENATE is necessary in the push model to avoid this (without CATENATE you'd have no choice), but is draft-unfriendly. In the pull model, CATENATE is a frill; it's not necessary but it may have some use, particularly if it it is not restricted to URLs that reference the currently selected mailbox. BURL has no concept of "currently selected mailbox" and thus such a restriction is meaningless. Note that the CATENATE/SUBMIT case *does* involve an extra client command step (separate CATENATE and SUBMIT commands), along with an implicit assumption that the client wants an fcc on the IMAP server. If the user does not want an fcc, then the user must also do a delete and expunge step on the IMAP server for a total of four commands. The question of a mandatory fcc in the push case raises another thorny issue. Users who are near the limit of their disk quota may not be able to send a message because they do not have the space to do the CATENATE. This is not a problem with BURL. Consider a person with a 10MB quota who has a 6MB video clip in a message that he wants to forward to some other place where he has more space. He's out of luck in the push case; only pull works. Now, far be it for me to argue the benefits of quotas! I'm in the camp of "give the system manager a nickel so he can afford to double my disk quota." But a lot of sites still think that quotas are necessary. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 00:32:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03883 for ; Fri, 2 Jan 2004 00:32:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHuo-0006jL-Ar for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 00:32:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i025W6OQ025870 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 00:32:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHuo-0006jB-5h for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 00:32:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03875 for ; Fri, 2 Jan 2004 00:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHul-0003A9-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 00:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHst-000374-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 00:30:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcHro-00034Y-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 00:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHrp-0006fZ-98; Fri, 02 Jan 2004 00:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHqx-0006ez-Cf for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 00:28:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03817 for ; Fri, 2 Jan 2004 00:28:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHqu-00033E-00 for lemonade@ietf.org; Fri, 02 Jan 2004 00:28:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHp6-0002zp-00 for lemonade@ietf.org; Fri, 02 Jan 2004 00:26:15 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AcHnb-0002wC-00 for lemonade@ietf.org; Fri, 02 Jan 2004 00:24:39 -0500 Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Thu, 1 Jan 2004 23:24:09 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Thu, 1 Jan 2004 23:24:06 -0600 To: Mark Crispin From: Pete Resnick Subject: RE: [lemonade] IMAP push/pull plan Cc: Ted Hardie , Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On 1/1/04 at 8:42 PM -0800, Mark Crispin wrote: >If the draft message does not have any external parts, then: > . BURL: an IMAP URL to the draft is submitted to the submit server. > . CATENATE/SUBMIT: a SUBMIT command is done. No problem. That seems perfectly draft-friendly. >If the draft message has external parts whose pointers are not in the >draft but are known to the client, then: I'm not sure I understand what you mean by this. Do you mean, "the draft message is incomplete at the moment and therefore doesn't have anything in it to be included from the server yet, but the client wants to add those things"? If so: > . BURL: an IMAP URL to the draft, along with URLs to the other parts, are > submitted to the SUBMIT server. > . CATENATE/SUBMIT: a CATENATE command is done, then a SUBMIT command. then that's right. >If the draft message has external parts that have pointers in the draft, >then: On this, I'm completely lost on what you mean. In the CATENATE case, if I am creating a draft which is to contain items that are external, there are no "pointers" in the draft; the external parts *are* in the draft. In that case: > . BURL: the BODYSTRUCTURE of the draft is fetched, the pieces determined, > and then a set of URLs (including IMAP URLs to the texts in the draft) > are submitted to the SUBMIT server > . CATENATE/SUBMIT: the BODYSTRUCTURE of the draft is fetched, the pieces > determined, the various pieces are put together via CATENATE, and then > a SUBMIT command is done. No, in the CATENATE/SUBMIT case, a SUBMIT command is done, full stop. It only has to do the BODYSTRUCTURE business if it is re-editing a draft and re-CATENATE-ing it to the server. I think you've assumed a "pointer then assembly" model, which instantly makes all cases at least two steps. But that's not required. If I make my drafts with an "always assemble the real thing now" model, then I can SUBMIT in one step if I need no other changes to my draft. >What would be draft-friendly is if the submit mechanism could recognize >the pointers and do the assembly itself. CATENATE is necessary in the >push model to avoid this (without CATENATE you'd have no choice), but is >draft-unfriendly. As I said in my previous message, it doesn't have to be draft-unfriendly so long as there is a Content-ID which indicates you don't have to download this part to re-edit the other parts of the message. >In the pull model, CATENATE is a frill; Agreed, but in the pull model using IMAP as a draft store without CATENATE (I assume by instead using APPEND and including the external parts as message/external-body or the like), the client is required to re-download the BODYSTRUCTURE of the draft and then submit the URLs to the SUBMIT server. >Note that the CATENATE/SUBMIT case *does* involve an extra client command >step (separate CATENATE and SUBMIT commands), along with an implicit >assumption that the client wants an fcc on the IMAP server. Yes, CATENATE/SUBMIT always requires a draft, where BURL does allow for not having a draft at all. >The question of a mandatory fcc in the push case raises another thorny >issue. Users who are near the limit of their disk quota may not be able >to send a message because they do not have the space to do the CATENATE. >This is not a problem with BURL. Consider a person with a 10MB quota who >has a 6MB video clip in a message that he wants to forward to some other >place where he has more space. He's out of luck in the push case; only >pull works. It depends on the server: 1. If the server implements CATENATE with references instead of copies, it might take up no more disk quota. 2. The server could allow a different temp quota for the drafts mailbox so that assembly could be done without blowing the normal quota. Things in the drafts mailbox might be auto-purged every so often if the admin is really a hard-ass. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 01:17:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04776 for ; Fri, 2 Jan 2004 01:17:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcIbn-00080C-Oq for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 01:16:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i026GVdf030757 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 01:16:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcIbn-000800-HS for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 01:16:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04764 for ; Fri, 2 Jan 2004 01:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcIbk-0004eQ-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 01:16:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcIZS-0004ZI-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 01:14:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcIYN-0004Vx-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 01:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcIYO-0007wH-P9; Fri, 02 Jan 2004 01:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcIXt-0007vp-E6 for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 01:12:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04668 for ; Fri, 2 Jan 2004 01:12:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcIXq-0004VC-00 for lemonade@ietf.org; Fri, 02 Jan 2004 01:12:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcIWA-0004S3-00 for lemonade@ietf.org; Fri, 02 Jan 2004 01:10:45 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1AcIVE-0004OA-00 for lemonade@ietf.org; Fri, 02 Jan 2004 01:09:44 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0269h4l007192; Thu, 1 Jan 2004 22:09:43 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0269hZj023841; Thu, 1 Jan 2004 22:09:43 -0800 Date: Thu, 1 Jan 2004 22:09:43 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Ted Hardie , Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Thu, 1 Jan 2004, Pete Resnick wrote: > > If the draft message has external parts whose pointers are not in the > > draft but are known to the client, then: > I'm not sure I understand what you mean by this. Do you mean, "the draft > message is incomplete at the moment and therefore doesn't have anything in it > to be included from the server yet, but the client wants to add those things"? No, I mean "the draft has things to be included from external places, but the pointers to those things are stored separately from the draft." > > If the draft message has external parts that have pointers in the draft, > On this, I'm completely lost on what you mean. In the CATENATE case, if I am > creating a draft which is to contain items that are external, there are no > "pointers" in the draft; the external parts *are* in the draft. That's the problem with using CATENATE for a draft. I create a draft that will include a 6MB attachment of some form. I decide to work on it later. Now, I retrieve the draft to work on it...and I've downloaded that entire 6MB attachment. I don't think that people are going to do drafts that way. To be explicit, I do not think that people will use CATENATE to create drafts. They will use APPEND for drafts instead. > I think you've assumed a "pointer then assembly" model, which instantly > makes all cases at least two steps. Indeed I do. If forward-without-download is a requirement, then it should be possible to re-edit a draft without downloading the forwarded content. After all, it's a draft. Drafts tend to be edited! > But that's not required. If I make my drafts with an "always assemble > the real thing now" model, then I can SUBMIT in one step if I need no > other changes to my draft. CATENATE naturally points to "always assemble the real thing now", so I'm not surprised that this is how you suggest it should be used. Hence my observation about CATENATE being draft-unfriendly. "Always assemble the real thing now" also presumes that, when editing, the user has enough storage to store at least two copies of the draft with all its attachments > As I said in my previous message, it doesn't have to be draft-unfriendly so > long as there is a Content-ID which indicates you don't have to download this > part to re-edit the other parts of the message. So, in order to maintain the forward-without-download requirement, instead of just downloading BODY[] of the draft for editing, the client has to download ENVELOPE and BODYSTRUCTURE first and then download individual body parts. This creates a substantial amount of new complexity. Not only is message submission a two-step process (CATENATE+SUBMIT), but now there's a multi-step process to edit drafts. There's also a problem with using Content-ID for anything. Outlook has a nasty bug in reading messages which use Content-ID. Some other way has to be used. > Agreed, but in the pull model using IMAP as a draft store without CATENATE (I > assume by instead using APPEND and including the external parts as > message/external-body or the like), the client is required to re-download the > BODYSTRUCTURE of the draft and then submit the URLs to the SUBMIT server. This is less of a burden than the steps listed above to re-edit the draft, which require much more than the BODYSTRUCTURE. The only savings that CATENATE+SUBMIT would have is if a draft is saved on the server, *not* sent, and then later, *after* the client has forgotten about the draft, the user submits the draft with *no* editing. > 1. If the server implements CATENATE with references instead of copies, it > might take up no more disk quota. This is akin to saying "choose push because the server will do pull internally." > 2. The server could allow a different temp quota for the drafts mailbox so > that assembly could be done without blowing the normal quota. I am not aware of any server which actually works this way. This is yet another new implementation requirement upon the IMAP server which will need to be documented someplace if the push model is considered. I can count at least three IMAP server implementors who oppose the push model because of all these new mandates, although there's less opposition to CATENATE. Are there any IMAP server implementors who think that the push model is a good idea? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 02:26:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20825 for ; Fri, 2 Jan 2004 02:26:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcJhE-000443-NK for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 02:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i027QC9S015623 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 02:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcJhE-00043u-2P for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 02:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20820 for ; Fri, 2 Jan 2004 02:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcJhA-0000gq-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 02:26:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcJfh-0000e9-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 02:24:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcJeD-0000aX-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 02:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcJe9-0003wJ-S1; Fri, 02 Jan 2004 02:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcJdD-0003uw-A1 for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 02:22:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20730 for ; Fri, 2 Jan 2004 02:22:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcJd9-0000Xx-00 for lemonade@ietf.org; Fri, 02 Jan 2004 02:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcJbJ-0000UG-00 for lemonade@ietf.org; Fri, 02 Jan 2004 02:20:08 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AcJZV-0000P6-00 for lemonade@ietf.org; Fri, 02 Jan 2004 02:18:13 -0500 Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Fri, 2 Jan 2004 01:17:44 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Fri, 2 Jan 2004 01:17:40 -0600 To: Mark Crispin From: Pete Resnick Subject: RE: [lemonade] IMAP push/pull plan Cc: Ted Hardie , Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On 1/1/04 at 10:09 PM -0800, Mark Crispin wrote: >That's the problem with using CATENATE for a draft. I create a draft that >will include a 6MB attachment of some form. I decide to work on it later. >Now, I retrieve the draft to work on it...and I've downloaded that entire >6MB attachment. Again, no, they don't have to re-download the attachment. That's a straw man and was never intended by anyone for the push model as far as I know. I've said this twice now. >>As I said in my previous message, it doesn't have to be >>draft-unfriendly so long as there is a Content-ID which indicates >>you don't have to download this part to re-edit the other parts of >>the message. > >So, in order to maintain the forward-without-download requirement, instead >of just downloading BODY[] of the draft for editing, the client has to >download ENVELOPE and BODYSTRUCTURE first and then download individual >body parts. BODYSTRUCTURE, yes. I don't see why they would need to get the ENVELOPE. >This creates a substantial amount of new complexity. Not only is message >submission a two-step process (CATENATE+SUBMIT), but now there's a >multi-step process to edit drafts. I'm sorry, I don't see the substantial new complexity. In the case of BURL with a draft, you download the BODY, and then you must parse that message to figure out where the attachments were in order to edit it. Using the proposed method for CATENATE, you get the pre-parsed BODYSTRUCTURE, and then you download the body parts you need to edit the message. Let's break down the actual steps involved here: - Message submission with an IMAP draft using BURL but not CATENATE is a 3 step process: Create the draft using APPEND, download the BODYSTRUCTURE, submit the pieces using BURL. - Message submission with an IMAP draft using CATENATE is a 2 step process: Create the draft using CATENATE, submit the entire message with SUBMIT. - Re-edit of a draft in the BURL/no-CATENATE case means downloading the message, parsing it, editing it, and uploading the new message, deleting the old draft, and purging. - Re-edit of a draft in the CATENATE base means downloading the BODYSTRUCTURE, downloading the parts of the message you need to edit, editing it, CATENATE-ing the new message , deleting the old draft, and purging. I don't see this big difference. Let's also remember that if you want to save a copy of the sent message, CATENATE gets you that for free. In the BURL/no-CATENATE model, you either are stuck with a template message or you have to get the submit server to give you a copy of the real message back. >There's also a problem with using Content-ID for anything. Outlook has a >nasty bug in reading messages which use Content-ID. Some other way has to >be used. Content-Location is a possibility. We can think about others. It just needs to be a way to mark particular parts as catenated that can be retrieved with BODYSTRUCTURE. > > Agreed, but in the pull model using IMAP as a draft store without >CATENATE (I > > assume by instead using APPEND and including the external parts as >> message/external-body or the like), the client is required to >>re-download the >> BODYSTRUCTURE of the draft and then submit the URLs to the SUBMIT server. > >This is less of a burden than the steps listed above to re-edit the draft, >which require much more than the BODYSTRUCTURE. I don't see it. Please explain. > > 1. If the server implements CATENATE with references instead of copies, it >> might take up no more disk quota. > >This is akin to saying "choose push because the server will do pull >internally." I am saying, "If your only concern with push is about quotas, it's not a problem if your server uses references instead of copies." But it's not a reason to choose push. > > 2. The server could allow a different temp quota for the drafts mailbox so > > that assembly could be done without blowing the normal quota. > >I am not aware of any server which actually works this way. > >This is yet another new implementation requirement upon the IMAP server No, it's a suggested way to deal with a particular concern with push. There are other ways to deal with that concern that don't involve any new implementation requirements. >I can count at least three IMAP server implementors who oppose the >push model because of all these new mandates 1. Don't speak for other people in order to make your own argument. Perhaps the other two (as yet unnamed) server implementors will be completely persuaded by the current debate and no longer oppose the push model. Perhaps they will think it all the worse. They can speak for themselves. It adds nothing to your argument to say "other people agree with me". 2. Saying "all these new mandates" is just hyperbole. Sure, there are several parts to doing push on an IMAP server that need to be implemented. The number of "new mandates" for a submit server in the pull model are pretty impressive to me. And there are things to do on the client side for each model. I'm not prepared at the moment to starting making guess-timates on the number of programmer hours to be spent on each model. >there's less opposition to CATENATE. As I've said before, I think CATENATE is a win even for the pull model, which is why I think there's less opposition to it. >Are there any IMAP server implementors who think that the push model >is a good idea? How about let's change the question to something that people can answer that might bring about consensus: What do other IMAP server implementors think are the good and bad points of the push model in light of what we've been discussing? If you happen to also be a submit server implementor, can you characterize what you see as implementation difficulties of push versus pull? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 13:22:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17441 for ; Fri, 2 Jan 2004 13:22:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcTwM-0001jf-2N for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 13:22:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02IMUO5006670 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 13:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcTwL-0001jV-Tk for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 13:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17435 for ; Fri, 2 Jan 2004 13:22:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcTwE-0004Q0-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 13:22:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcTsn-0004J8-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 13:18:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcTqR-0004Ey-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 13:16:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcTq6-0001dE-M5; Fri, 02 Jan 2004 13:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcTpf-0001c6-5F for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 13:15:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17343 for ; Fri, 2 Jan 2004 13:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcTpO-0004Cx-00 for lemonade@ietf.org; Fri, 02 Jan 2004 13:15:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcTmE-00048L-00 for lemonade@ietf.org; Fri, 02 Jan 2004 13:12:05 -0500 Received: from lin1.andrew.cmu.edu ([128.2.6.59]) by ietf-mx with esmtp (Exim 4.12) id 1AcTif-0003yv-00 for lemonade@ietf.org; Fri, 02 Jan 2004 13:08:21 -0500 Received: from ASG1.WEB.cmu.edu (ASG1.WEB.cmu.edu [128.2.11.38]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i02I7so8000804; Fri, 2 Jan 2004 13:07:54 -0500 Date: Fri, 2 Jan 2004 13:07:55 -0500 (EST) From: Rob Siemborski X-X-Sender: rjs3@asg1.web.cmu.edu To: Pete Resnick cc: Mark Crispin , Ted Hardie , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Fri, 2 Jan 2004, Pete Resnick wrote: > Let's also remember that if you want to save a copy of the sent > message, CATENATE gets you that for free. In the BURL/no-CATENATE > model, you either are stuck with a template message or you have to > get the submit server to give you a copy of the real message back. CATENATE seems to be the sanest way to solve the "I need an FCC" problem when using BURL to submit the message. Of course, if you are pulling from non-IMAP sources (e.g. a web page) then maybe this is bad because now *both* the IMAP and SUBMIT/SMTP server needs to be able to talk to the source of the object. But maybe that doesn't matter since the client can just issue a BURL to the draft on the IMAP server. > As I've said before, I think CATENATE is a win even for the pull > model, which is why I think there's less opposition to it. Yeah, I'd agree with this. > >Are there any IMAP server implementors who think that the push model > >is a good idea? > > How about let's change the question to something that people can > answer that might bring about consensus: What do other IMAP server > implementors think are the good and bad points of the push model in > light of what we've been discussing? Personally, I don't really like the PUSH model in that it adds a new submission mechanism, it assumes "everyone uses IMAP" and implies that if we ever find a new mail retrieval protocol that everyone wants to switch to after IMAP, we'll have to reinvent a submission mechanism for this future protocol as well. Up until this thread, the main drawback that I saw with the BURL model was that getting a FCC back onto the IMAP server was hard. But I think that the use of CATENATE solves that. I'm currently favoring a solution that used CATENATE+BURL+URLAUTH. Sadly, I think this solution involves a lot of work on all sides (SUBMIT/SMTP, IMAP, and client). However, I also feel that it gives us all of the features that LEMONADE needs (forward without download, along with draft messages and fcc capability), and is more future proof than the CATENATE/SUBMIT model. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 13:59:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18756 for ; Fri, 2 Jan 2004 13:59:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUVf-0002qc-23 for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 13:58:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02Iwx7j010945 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 13:58:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUVe-0002qS-Lf for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 13:58:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18710 for ; Fri, 2 Jan 2004 13:58:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUVc-00063N-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 13:58:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUTZ-0005v6-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 13:56:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcURs-0005pm-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 13:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcURq-0002lt-I7; Fri, 02 Jan 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUR2-0002js-UI for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 13:54:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18494 for ; Fri, 2 Jan 2004 13:54:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUR0-0005mD-00 for lemonade@ietf.org; Fri, 02 Jan 2004 13:54:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUP6-0005hH-00 for lemonade@ietf.org; Fri, 02 Jan 2004 13:52:15 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx with esmtp (Exim 4.12) id 1AcUNW-0005e9-00 for lemonade@ietf.org; Fri, 02 Jan 2004 13:50:34 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i02IoVK4031913; Fri, 2 Jan 2004 10:50:31 -0800 Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i02IoJba010533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Jan 2004 10:50:30 -0800 Date: Fri, 2 Jan 2004 10:50:24 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: Pete Resnick , Ted Hardie , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Fri, 2 Jan 2004, Rob Siemborski wrote: > CATENATE seems to be the sanest way to solve the "I need an FCC" problem > when using BURL to submit the message. It is certainly the sanest way that has been offered so far. That is why I have taken the trouble to try to get CATENATE be more draft-friendly and work with non-IMAP sources, instead of flatly opposing CATENATE. > Of course, if you are pulling from non-IMAP sources (e.g. a web page) then > maybe this is bad because now *both* the IMAP and SUBMIT/SMTP server needs > to be able to talk to the source of the object. But maybe that doesn't > matter since the client can just issue a BURL to the draft on the IMAP > server. Perhaps the draft question provides some impetus for additional work in this area. I think that we need both "pre-assembled" (with some form of pointer to the data) and "assembled" forms of CATENATE. I can see some fcc users wanting to store in "pre-assembled" form in order to save space. > > As I've said before, I think CATENATE is a win even for the pull > > model, which is why I think there's less opposition to it. > Yeah, I'd agree with this. I agree as well, but weakly. I'd feel better about CATENATE if its deficiencies were fixed. > Personally, I don't really like the PUSH model in that it adds a new > submission mechanism, it assumes "everyone uses IMAP" and implies that if > we ever find a new mail retrieval protocol that everyone wants to switch > to after IMAP, we'll have to reinvent a submission mechanism for this > future protocol as well. I agree with all of the above. > Up until this thread, the main drawback that I saw with the BURL model was > that getting a FCC back onto the IMAP server was hard. But I think that > the use of CATENATE solves that. Yes, CATENATE is a solution to the fcc problem, and I don't see much point in coming up with an alternative to CATENATE. CATENATE is close enough now and its deficiences are fixable. > I'm currently favoring a solution that used CATENATE+BURL+URLAUTH. As am I. > Sadly, I think this solution involves a lot of work on all sides > (SUBMIT/SMTP, IMAP, and client). Yes, it does. There are no "easy" ways out. However, the benefit of rolling up our sleeves and doing the right thing is that the resulting technology can be leveraged for other purposes. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 14:25:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19384 for ; Fri, 2 Jan 2004 14:25:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUv5-0003uh-8A for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 14:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02JPFlu015042 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 14:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUuv-0003uX-0G for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 14:25:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19369 for ; Fri, 2 Jan 2004 14:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUun-00077F-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:24:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUoL-0006s6-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:18:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcUjX-0006cr-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:13:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUjE-0003gF-Fs; Fri, 02 Jan 2004 14:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUif-0003cE-4r for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 14:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19093 for ; Fri, 2 Jan 2004 14:12:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUiX-0006bR-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUd8-0006Na-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:06:45 -0500 Received: from lin1.andrew.cmu.edu ([128.2.6.59]) by ietf-mx with esmtp (Exim 4.12) id 1AcUXH-00069b-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:00:39 -0500 Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i02J0Jo8000858; Fri, 2 Jan 2004 14:00:19 -0500 Date: Fri, 2 Jan 2004 14:00:20 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: Pete Resnick , Ted Hardie , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Fri, 2 Jan 2004, Mark Crispin wrote: > Yes, CATENATE is a solution to the fcc problem, and I don't see much point > in coming up with an alternative to CATENATE. CATENATE is close enough > now and its deficiences are fixable. Yeah, all of my points were assuming "CATENATE takes URLs" (which I believe has been fixed) and "CATENATE doesn't have an explicit restriction against being used for other purposes" (which I suspect people would be inclined to ignore anyway if it became useful). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 14:30:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19581 for ; Fri, 2 Jan 2004 14:30:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUzU-00040O-DS for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 14:29:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02JTm5G015390 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 14:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUzT-000409-Qe for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 14:29:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19470 for ; Fri, 2 Jan 2004 14:29:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUzR-0007IU-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:29:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUt7-00073U-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:23:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcUnP-0006n8-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUn6-0003lE-PT; Fri, 02 Jan 2004 14:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUmY-0003kz-IZ for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 14:16:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19166 for ; Fri, 2 Jan 2004 14:16:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUmC-0006is-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:16:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUgl-0006XA-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:10:30 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx with esmtp (Exim 4.12) id 1AcUbt-0006Ij-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:05:25 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i02J4n9n002125; Fri, 2 Jan 2004 11:04:49 -0800 Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i02J4lba011440 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Jan 2004 11:04:48 -0800 Date: Fri, 2 Jan 2004 11:04:52 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: Pete Resnick , Ted Hardie , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On Fri, 2 Jan 2004, Rob Siemborski wrote: > Yeah, all of my points were assuming "CATENATE takes URLs" (which I > believe has been fixed) and "CATENATE doesn't have an explicit restriction > against being used for other purposes" (which I suspect people would be > inclined to ignore anyway if it became useful). I believe that the current CATENATE document only permits IMAP URLs that refer to the selected mailbox. That still needs to be fixed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 2 14:57:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20965 for ; Fri, 2 Jan 2004 14:57:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcVQ6-0004ta-Sf for lemonade-archive@odin.ietf.org; Fri, 02 Jan 2004 14:57:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02JvIXr018812 for lemonade-archive@odin.ietf.org; Fri, 2 Jan 2004 14:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcVQ6-0004tL-NR for lemonade-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 14:57:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20946 for ; Fri, 2 Jan 2004 14:57:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcVQ3-0001GG-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:57:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcVNQ-00018N-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:54:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcVLv-00012j-00 for lemonade-web-archive@ietf.org; Fri, 02 Jan 2004 14:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcVLx-0004p3-Cz; Fri, 02 Jan 2004 14:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcVLq-0004ok-2s for lemonade@optimus.ietf.org; Fri, 02 Jan 2004 14:52:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20778 for ; Fri, 2 Jan 2004 14:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcVLn-000122-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:52:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcVKJ-0000sP-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:51:22 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AcVHU-0000Zx-00 for lemonade@ietf.org; Fri, 02 Jan 2004 14:48:24 -0500 Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Fri, 2 Jan 2004 13:47:53 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Fri, 2 Jan 2004 13:47:49 -0600 To: Mark Crispin From: Pete Resnick Subject: RE: [lemonade] IMAP push/pull plan Cc: Rob Siemborski , Ted Hardie , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , On 1/2/04 at 11:04 AM -0800, Mark Crispin wrote: >I believe that the current CATENATE document only permits IMAP URLs >that refer to the selected mailbox. That still needs to be fixed. The only reason I put in that limitation, and the reason I chose the -00 syntax, was because I heard objections (specifically from Chris Newman) to opening up the command to other than the selected mailbox. I certainly have no objection to changing that (as a matter of fact, it was my desire at the get-go), but I'd like to hear from other folks that this is OK. (Chris, are you out there?) Should I still go under the assumption that the URL must only refer to the current server and that other servers or other URL schemes are outside of scope and require extension? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Sat Jan 3 13:18:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08090 for ; Sat, 3 Jan 2004 13:18:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcqLz-0002YZ-9u for lemonade-archive@odin.ietf.org; Sat, 03 Jan 2004 13:18:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i03IIR7J009819 for lemonade-archive@odin.ietf.org; Sat, 3 Jan 2004 13:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcqLy-0002YF-V3 for lemonade-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 13:18:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08030 for ; Sat, 3 Jan 2004 13:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcqLx-0002bm-00 for lemonade-web-archive@ietf.org; Sat, 03 Jan 2004 13:18:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcqIu-0002Pi-00 for lemonade-web-archive@ietf.org; Sat, 03 Jan 2004 13:15:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcqDB-00027f-00 for lemonade-web-archive@ietf.org; Sat, 03 Jan 2004 13:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcqCq-0002GZ-TH; Sat, 03 Jan 2004 13:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcqC1-0002GD-4J for lemonade@optimus.ietf.org; Sat, 03 Jan 2004 13:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07856 for ; Sat, 3 Jan 2004 13:08:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcqBr-0001zJ-00 for lemonade@ietf.org; Sat, 03 Jan 2004 13:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acq2z-0001fG-00 for lemonade@ietf.org; Sat, 03 Jan 2004 12:58:50 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1Acq2W-0001Yc-00 for lemonade@ietf.org; Sat, 03 Jan 2004 12:58:20 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Sat, 3 Jan 2004 11:57:49 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <3FD33929.2010304@isode.com> <3FDDF8B9.3010906@isode.com> <3FE871DA.1020803@isode.com> <2147483647.1072788400@115.216-123-230-0.interbaun.com> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Sat, 3 Jan 2004 11:57:46 -0600 To: Mark Crispin From: Pete Resnick Cc: Lyndon Nerenberg , Alexey Melnikov , Lemonade Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [lemonade] IMAP URL update (Was: CATENATE draft) Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 12/30/03 at 3:39 PM -0800, Mark Crispin wrote: >OK. I think that there is arguably a requirement for more than just >this. Are byte ranges really sufficient, or would some kind of line >range be desirable? What about some means to access envelope and/or >bodystructure via URL? I think byte ranges are sufficient for CATENATE, but perhaps there are other contexts in which these other features would be important. Mark, could you bring this discussion back over to IMAPEXT? There are probably more people there who can give input. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Jan 5 19:39:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15711 for ; Mon, 5 Jan 2004 19:39:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfFq-0006cJ-QE for lemonade-archive@odin.ietf.org; Mon, 05 Jan 2004 19:39:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060dUW5025429 for lemonade-archive@odin.ietf.org; Mon, 5 Jan 2004 19:39:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfFq-0006c4-CF for lemonade-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 19:39:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15673 for ; Mon, 5 Jan 2004 19:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfFo-0005ul-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:39:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfAD-0005cv-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:33:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adf70-0005N9-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:30:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf6h-0005u3-Dn; Mon, 05 Jan 2004 19:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf5V-0005sj-Lt for lemonade@optimus.ietf.org; Mon, 05 Jan 2004 19:29:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15372 for ; Mon, 5 Jan 2004 19:28:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adf5P-0005JU-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adf0N-000597-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:23:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AdewT-0004zh-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:19:29 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i060IxVY021026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2004 16:19:00 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i060IvFB016955; Mon, 5 Jan 2004 16:18:57 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 5 Jan 2004 16:18:55 -0800 To: Mark Crispin , Rob Siemborski From: Ted Hardie Subject: RE: [lemonade] IMAP push/pull plan Cc: Pete Resnick , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 10:50 AM -0800 01/02/2004, Mark Crispin wrote: > > I'm currently favoring a solution that used CATENATE+BURL+URLAUTH. > >As am I. Are you still planning on writing a draft which documents the PULL usage, and, if so, by what date do you have it out? (You'd previously argued that we did have enough data to decide between push and pull, and I understood you to say you would right such a draft) regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Jan 5 19:41:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15962 for ; Mon, 5 Jan 2004 19:41:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfHn-0006jj-ER for lemonade-archive@odin.ietf.org; Mon, 05 Jan 2004 19:41:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060fVB2025889 for lemonade-archive@odin.ietf.org; Mon, 5 Jan 2004 19:41:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfHn-0006j1-8O for lemonade-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 19:41:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15889 for ; Mon, 5 Jan 2004 19:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfHi-00067T-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:41:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfFx-0005wy-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:39:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdfAg-0005dr-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:34:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfAX-00066U-0s; Mon, 05 Jan 2004 19:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf9y-00065Y-4i for lemonade@optimus.ietf.org; Mon, 05 Jan 2004 19:33:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15480 for ; Mon, 5 Jan 2004 19:33:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adf9r-0005aR-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:33:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adf6l-0005Nj-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:30:08 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1Adf1Q-0005Bg-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:24:36 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i060OLVY021293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2004 16:24:22 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i060OJhk027301; Mon, 5 Jan 2004 16:24:19 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 5 Jan 2004 16:24:17 -0800 To: Pete Resnick , Mark Crispin From: Ted Hardie Subject: RE: [lemonade] IMAP push/pull plan Cc: Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 1:47 PM -0600 01/02/2004, Pete Resnick wrote: > >The only reason I put in that limitation, and the reason I chose the -00 syntax, was because I heard objections (specifically from Chris Newman) to opening up the command to other than the selected mailbox. I certainly have no objection to changing that (as a matter of fact, it was my desire at the get-go), but I'd like to hear from other folks that this is OK. (Chris, are you out there?) > >Should I still go under the assumption that the URL must only refer to the current server and that other servers or other URL schemes are outside of scope and require extension? In the discussion to date, there has been a back and forth about the security assumptions around non-IMAP URL schemes. As I understand it, at least some folks believe that the non-IMAP URLs would be accessing data using that was non publicly available. The security model for the restricted CATENATE is pretty easy, since it is providing an IMAP command that uses the same basic permissions for a resource as would a download of that resource. In my personal opinion, the draft needs a very different security analysis if the presumption is going to be that the facility can securely retrieve external non-public resources. It also needs to carefully lay out which schemes can be used (not all uri schemes have the presumption of data retrieval, for example, and the use of those in this context would not make much sense). regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Jan 5 20:00:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16625 for ; Mon, 5 Jan 2004 19:59:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfZC-0007Zt-Mz for lemonade-archive@odin.ietf.org; Mon, 05 Jan 2004 19:59:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060xUmm029121 for lemonade-archive@odin.ietf.org; Mon, 5 Jan 2004 19:59:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfZC-0007Zc-Gy for lemonade-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 19:59:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16580 for ; Mon, 5 Jan 2004 19:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfZA-0006xT-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:59:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfXG-0006tE-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:57:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdfVr-0006pu-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 19:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfVq-0007RE-EI; Mon, 05 Jan 2004 19:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfVJ-0007Q6-B9 for lemonade@optimus.ietf.org; Mon, 05 Jan 2004 19:55:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16479 for ; Mon, 5 Jan 2004 19:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfVH-0006oh-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:55:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfTT-0006m1-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:53:36 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx with esmtp (Exim 4.12) id 1AdfSb-0006i6-00 for lemonade@ietf.org; Mon, 05 Jan 2004 19:52:41 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i060qcK4011685; Mon, 5 Jan 2004 16:52:39 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i060qcba026539 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2004 16:52:38 -0800 Date: Mon, 5 Jan 2004 16:54:42 -0800 (Pacific Standard Time) From: Mark Crispin To: Ted Hardie cc: Rob Siemborski , Pete Resnick , Glenn Parsons , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 5 Jan 2004, Ted Hardie wrote: > Are you still planning on writing a draft which documents the PULL usage, > and, if so, by what date do you have it out? (You'd previously argued > that we did have enough data to decide between push and pull, and > I understood you to say you would right such a draft) Yes, I am planning to do so. I was not planning to do so until this week (I made a half-hearted attempt to be on *vacation* until today), so I haven't started it yet. I hope to get on it in the next day or so, assuming that the threatened major snowstorm tonight doesn't cut off electrical power... -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Jan 5 20:19:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16909 for ; Mon, 5 Jan 2004 20:19:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adfrx-0008IS-4z for lemonade-archive@odin.ietf.org; Mon, 05 Jan 2004 20:18:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i061IrkJ031886 for lemonade-archive@odin.ietf.org; Mon, 5 Jan 2004 20:18:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adfrr-0008IC-St for lemonade-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 20:18:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16894 for ; Mon, 5 Jan 2004 20:18:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adfrk-0007Ti-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 20:18:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfnE-0007NK-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 20:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adfkd-0007Fu-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 20:11:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfkL-0008Ak-B8; Mon, 05 Jan 2004 20:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adfju-00086Z-FL for lemonade@optimus.ietf.org; Mon, 05 Jan 2004 20:10:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16745 for ; Mon, 5 Jan 2004 20:10:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adfjn-0007Eh-00 for lemonade@ietf.org; Mon, 05 Jan 2004 20:10:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdffE-000784-00 for lemonade@ietf.org; Mon, 05 Jan 2004 20:05:45 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AdfcL-00071x-00 for lemonade@ietf.org; Mon, 05 Jan 2004 20:02:45 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i0612GH8014252; Mon, 5 Jan 2004 17:02:16 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i0612EU0027065; Mon, 5 Jan 2004 17:02:14 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 5 Jan 2004 17:02:12 -0800 To: Mark Crispin From: Ted Hardie Subject: RE: [lemonade] IMAP push/pull plan Cc: Rob Siemborski , Glenn Parsons , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 3:37 PM -0800 01/01/2004, Mark Crispin wrote: > > And while all of this is a very interesting, I think we have to go back >> to the common use case, and ask ourselves whether "forward without >> download", which is one of the immediately motivating cases here, >> would require anything more than what an IMAP server can do >> using the local mailboxes. > >Indeed. The advocates of pull have seen this coming from the onset. I'm afraid I don't follow you here. Do you mean that the advocates of pull have seen from the outset that "forward without download" requires more than what an IMAP server can do using the local mailboxes? There is a very critical scope question here, from my point of view. If the working group sees this task as developing what we might call "non-client compose", in which the client can direct some server (be it Submit or IMAP) to assemble a message from multiple data sources without downloading the parts, then the "compose from a single, local data source" would be a degenerate case of the "non-client compose". Using the same mechanism for the degenerate case as the full functionality makes lots of sense. But I think this working group has a much more focused deliverable: >2. Enhance the existing IMAP4 message retrieval and/or message >submission (RFC 2476) protocols to satisfy the requirements for >forwarding a message and/or its attachments without downloading >the message to the client and subsequently uploading the message to a >server. "a message and/or its attachments" does look to me like a message and its parts taken from a single data source were/are the key motivating use case for the words in the charter. Charters are not unchangeable holy writ, of course, and there is some room for disagreement about the limitations inherent even in this statement. But I personally believe that this use case gives a very focused view of what needs to be done and that getting it done quickly and right would be a very valuable piece of work. A quick round of the working group to be sure which problem we're tackling seems to be in order, as the engineering trade-offs are surely different with the different perspectives. Again speaking personally, if the consensus of the working group is that the task is "non-client compose", rather than "forward without download", then I am not really sure that either a Submit server or an IMAP server would be the right place to do the work. Revisiting the use of a multi-function proxy might be appropriate in that case, because the core functionality may be beyond what are safe and sane ways to extend IMAP or Submit servers. I am nagged, though, by the idea that we will end up re-inventing the remote shell, as that is what I and many others use to handle this problem (I sometimes use ssh to reach a remote server with better connectivity when I need to handle email over a very poor link; sometimes, though, I take it as a sign to take a day or two away from email. This is the source of the delay in my reply to this message. Apologies for any inconvenience). regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Jan 5 21:31:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18707 for ; Mon, 5 Jan 2004 21:31:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adh0D-0002Vf-35 for lemonade-archive@odin.ietf.org; Mon, 05 Jan 2004 21:31:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i062VT5n009641 for lemonade-archive@odin.ietf.org; Mon, 5 Jan 2004 21:31:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adh0C-0002VQ-Mn for lemonade-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 21:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18701 for ; Mon, 5 Jan 2004 21:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adh0A-0002Sh-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 21:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdgyQ-0002QA-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 21:29:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adgwq-0002NE-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 21:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adgwq-0002P4-TA; Mon, 05 Jan 2004 21:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdgwJ-0002OM-FL for lemonade@optimus.ietf.org; Mon, 05 Jan 2004 21:27:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18584 for ; Mon, 5 Jan 2004 21:27:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdgwG-0002KA-00 for lemonade@ietf.org; Mon, 05 Jan 2004 21:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdguI-0002E4-00 for lemonade@ietf.org; Mon, 05 Jan 2004 21:25:23 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AdgsK-00025x-00 for lemonade@ietf.org; Mon, 05 Jan 2004 21:23:24 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i062Mme10009 for ; Mon, 5 Jan 2004 20:22:48 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id ; Mon, 5 Jan 2004 20:22:47 -0600 Message-ID: <54E40201497DF142B06B27255953F79709CEF039@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Ted Hardie , Mark Crispin Cc: Rob Siemborski , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan Date: Mon, 5 Jan 2004 20:22:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 For some diversity of opinion... I mildly favor the push model, in part because it feels more secure. In my corner of the world, there is not a wide diversity of legacy clients. If I have IMAP push, I can imagine being able to dispense with a client-accessible SMTP-submit server. This reduces the number of entities that must reside within the DMZ network that need access to fairly sensitive subscriber directory data. An authenticated submission server generally requires access to the users passwords (or encrypted passwords) stored in a directory by the server in the DMZ. An IMAP proxy server in the DMZ only needs access to more limited information mapping the recipient identity to a message store... or less. Gaining control of the IMAP proxy does not gain access to the password data. Gaining access to a submission server does get me access to enough info to authenticate the user.... and to play off-line guess the password games. So, if I get push submission via IMAP, I think I get a more secure environment for my end-users. I also get fewer client-to-server protocols to manage and fewer firewall rules. Overall, this feels like a pretty good win for push. Greg V. -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Monday, January 05, 2004 7:02 PM To: Mark Crispin Cc: Rob Siemborski; Glenn Parsons; IETF LEMONADE (E-mail) Subject: RE: [lemonade] IMAP push/pull plan At 3:37 PM -0800 01/01/2004, Mark Crispin wrote: > > And while all of this is a very interesting, I think we have to go back >> to the common use case, and ask ourselves whether "forward without >> download", which is one of the immediately motivating cases here, >> would require anything more than what an IMAP server can do >> using the local mailboxes. > >Indeed. The advocates of pull have seen this coming from the onset. I'm afraid I don't follow you here. Do you mean that the advocates of pull have seen from the outset that "forward without download" requires more than what an IMAP server can do using the local mailboxes? There is a very critical scope question here, from my point of view. If the working group sees this task as developing what we might call "non-client compose", in which the client can direct some server (be it Submit or IMAP) to assemble a message from multiple data sources without downloading the parts, then the "compose from a single, local data source" would be a degenerate case of the "non-client compose". Using the same mechanism for the degenerate case as the full functionality makes lots of sense. But I think this working group has a much more focused deliverable: >2. Enhance the existing IMAP4 message retrieval and/or message >submission (RFC 2476) protocols to satisfy the requirements for >forwarding a message and/or its attachments without downloading >the message to the client and subsequently uploading the message to a >server. "a message and/or its attachments" does look to me like a message and its parts taken from a single data source were/are the key motivating use case for the words in the charter. Charters are not unchangeable holy writ, of course, and there is some room for disagreement about the limitations inherent even in this statement. But I personally believe that this use case gives a very focused view of what needs to be done and that getting it done quickly and right would be a very valuable piece of work. A quick round of the working group to be sure which problem we're tackling seems to be in order, as the engineering trade-offs are surely different with the different perspectives. Again speaking personally, if the consensus of the working group is that the task is "non-client compose", rather than "forward without download", then I am not really sure that either a Submit server or an IMAP server would be the right place to do the work. Revisiting the use of a multi-function proxy might be appropriate in that case, because the core functionality may be beyond what are safe and sane ways to extend IMAP or Submit servers. I am nagged, though, by the idea that we will end up re-inventing the remote shell, as that is what I and many others use to handle this problem (I sometimes use ssh to reach a remote server with better connectivity when I need to handle email over a very poor link; sometimes, though, I take it as a sign to take a day or two away from email. This is the source of the delay in my reply to this message. Apologies for any inconvenience). regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Jan 5 21:43:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19115 for ; Mon, 5 Jan 2004 21:43:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdhBq-00033Q-Or for lemonade-archive@odin.ietf.org; Mon, 05 Jan 2004 21:43:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i062hUhr011738 for lemonade-archive@odin.ietf.org; Mon, 5 Jan 2004 21:43:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdhBq-00033D-IH for lemonade-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 21:43:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19102 for ; Mon, 5 Jan 2004 21:43:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdhBn-0002tf-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 21:43:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adh9w-0002qL-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 21:41:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adh8T-0002n7-00 for lemonade-web-archive@ietf.org; Mon, 05 Jan 2004 21:40:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adh8V-0002xH-AD; Mon, 05 Jan 2004 21:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adh7v-0002vm-8V for lemonade@optimus.ietf.org; Mon, 05 Jan 2004 21:39:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19018 for ; Mon, 5 Jan 2004 21:39:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adh7s-0002kN-00 for lemonade@ietf.org; Mon, 05 Jan 2004 21:39:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adh63-0002hZ-00 for lemonade@ietf.org; Mon, 05 Jan 2004 21:37:32 -0500 Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx with esmtp (Exim 4.12) id 1Adh4O-0002di-00 for lemonade@ietf.org; Mon, 05 Jan 2004 21:35:48 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i062Zjlo000683; Mon, 5 Jan 2004 18:35:46 -0800 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i062Z0vo012936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2004 18:35:28 -0800 Date: Mon, 5 Jan 2004 18:35:08 -0800 (Pacific Standard Time) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" cc: Ted Hardie , Rob Siemborski , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: <54E40201497DF142B06B27255953F79709CEF039@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F79709CEF039@il0015exch007u.ih.lucent.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 5 Jan 2004, Vaudreuil, Greg M (Greg) wrote: > In my corner of the world, there is not a wide diversity of legacy > clients. If I have IMAP push, I can imagine being able to dispense with > a client-accessible SMTP-submit server. This reduces the number of > entities that must reside within the DMZ network that need access to > fairly sensitive subscriber directory data. This is an argument for a submission mechanism that is within the DMZ network. It is not an argument for push, except in the weak sense that push forces such a configuration. The dichotomy here is MUST vs. MAY (or SHOULD). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Jan 8 15:39:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10977 for ; Thu, 8 Jan 2004 15:39:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegvP-0005Ch-TM for lemonade-archive@odin.ietf.org; Thu, 08 Jan 2004 15:38:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Kcdxp019997 for lemonade-archive@odin.ietf.org; Thu, 8 Jan 2004 15:38:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegvP-0005CS-Po for lemonade-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 15:38:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10953 for ; Thu, 8 Jan 2004 15:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegvO-0004ba-00 for lemonade-web-archive@ietf.org; Thu, 08 Jan 2004 15:38:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegtW-0004VX-00 for lemonade-web-archive@ietf.org; Thu, 08 Jan 2004 15:36:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aegs2-0004QP-00 for lemonade-web-archive@ietf.org; Thu, 08 Jan 2004 15:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aegru-0004pk-6G; Thu, 08 Jan 2004 15:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegrU-0004nU-RU for lemonade@optimus.ietf.org; Thu, 08 Jan 2004 15:34:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10790 for ; Thu, 8 Jan 2004 15:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegrT-0004NQ-00 for lemonade@ietf.org; Thu, 08 Jan 2004 15:34:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aegpg-0004GW-00 for lemonade@ietf.org; Thu, 08 Jan 2004 15:32:45 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1Aegnv-000418-00 for lemonade@ietf.org; Thu, 08 Jan 2004 15:30:55 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 17886; Thu, 08 Jan 2004 15:33:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jan 2004 15:29:04 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB24177@zoe.office.snowshore.com> Thread-Topic: Meeting in Seoul Thread-Index: AcPWJg5rtDgnouc6TwaMV4r0t2KbLQ== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Meeting in Seoul Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It looks like we will have a quorum. We will ask for multicast capability, as there are some people that are = critical to the discussion that will not be able to attend. If we do not get an official multicast setup, we will still get = something going for at least audio, if not video. Details will follow = when we find out which way we're going to go. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 9 14:58:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29973 for ; Fri, 9 Jan 2004 14:58:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af2bh-0003Fc-6h for lemonade-archive@odin.ietf.org; Fri, 09 Jan 2004 14:47:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Jljcu012490 for lemonade-archive@odin.ietf.org; Fri, 9 Jan 2004 14:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af2bh-0003Et-1n for lemonade-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 14:47:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28983 for ; Fri, 9 Jan 2004 14:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af2US-0006PU-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 14:40:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af1c4-0004ie-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 13:44:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af1Fq-0007Lh-01 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 13:21:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af0qI-00075S-L1 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 12:54:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0pq-00045C-PP for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 12:54:14 -0500 Date: Fri, 09 Jan 2004 12:54:14 -0500 Message-ID: <20040109175414.9164.11609.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: lemonade-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, lemonade-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for lemonade-web-archive@ietf.org: List Password // URL ---- -------- lemonade@ietf.org ewunaw https://www1.ietf.org/mailman/options/lemonade/lemonade-web-archive%40ietf.org From exim@www1.ietf.org Fri Jan 9 15:24:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08880 for ; Fri, 9 Jan 2004 15:24:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3B8-0004FB-54 for lemonade-archive@odin.ietf.org; Fri, 09 Jan 2004 15:24:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09KOMCX016305 for lemonade-archive@odin.ietf.org; Fri, 9 Jan 2004 15:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3B7-0004Er-Ss for lemonade-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:24:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08608 for ; Fri, 9 Jan 2004 15:24:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3B5-0007kH-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 15:24:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2bG-0001yc-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 14:47:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af1tn-0000RD-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 14:02:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af1tR-0001nf-Nq; Fri, 09 Jan 2004 14:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adx3M-0006Q8-3P for lemonade@optimus.ietf.org; Tue, 06 Jan 2004 14:39:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00335 for ; Tue, 6 Jan 2004 14:39:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adx3J-0005Ks-00 for lemonade@ietf.org; Tue, 06 Jan 2004 14:39:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adx1R-0005FU-00 for lemonade@ietf.org; Tue, 06 Jan 2004 14:37:50 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx with esmtp (Exim 4.12) id 1Adwzb-000595-00 for lemonade@ietf.org; Tue, 06 Jan 2004 14:35:55 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i06JZrK4022107; Tue, 6 Jan 2004 11:35:53 -0800 Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i06JZkba007558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jan 2004 11:35:52 -0800 Date: Tue, 6 Jan 2004 11:35:57 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick cc: "Vaudreuil, Greg M (Greg)" , Ted Hardie , Rob Siemborski , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] IMAP push/pull plan In-Reply-To: Message-ID: References: <54E40201497DF142B06B27255953F79709CEF039@il0015exch007u.ih.lucent.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 6 Jan 2004, Pete Resnick wrote: > What I read Greg as saying is that > with push, he can have one entity (the IMAP server) that has access to user > authentication data, This is true if (and only if) all the data is located on the IMAP server. > whereas if he has a submission server that users need to > access, it would also need access to user authentication data. The submit server needs authorization data. User authentication data can be used as such, but it is not the only example. Note that in many environments, the submit server and IMAP server are already in the same authorization web. For example, at UW the IMAP servers and submit servers both require authentication and are in the same Kerberos realm. The cases to worry about are: . the case in which the submit server does not require authentication that is, are open relays. I suspect that this is a vanishly small number. . the case in which the submit server authenticates via a weak mechanism such as client IP address. . the case in which the submit server authenticates strongly, but differently from the IMAP server. Where we may differ is my belief that the first two cases are heading towards extinction. I've used strong submit server authentication for so long I find it difficult to believe that, given a choice, anyone who choose otherwise. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 9 16:14:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08879 for ; Fri, 9 Jan 2004 15:24:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3B7-0004Eh-M1 for lemonade-archive@odin.ietf.org; Fri, 09 Jan 2004 15:24:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09KOLUk016283 for lemonade-archive@odin.ietf.org; Fri, 9 Jan 2004 15:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3B7-0004ET-3F for lemonade-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08603 for ; Fri, 9 Jan 2004 15:24:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3B5-0007k8-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 15:24:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2bG-0001yV-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 14:47:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af1tn-0000RC-00 for lemonade-web-archive@ietf.org; Fri, 09 Jan 2004 14:02:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af1tR-0001nW-ED; Fri, 09 Jan 2004 14:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adwrk-0005bl-Fh for lemonade@optimus.ietf.org; Tue, 06 Jan 2004 14:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29754 for ; Tue, 6 Jan 2004 14:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adwrh-0004dc-00 for lemonade@ietf.org; Tue, 06 Jan 2004 14:27:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adwpl-0004U6-00 for lemonade@ietf.org; Tue, 06 Jan 2004 14:25:46 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AdwoL-0004He-00 for lemonade@ietf.org; Tue, 06 Jan 2004 14:24:17 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Tue, 6 Jan 2004 13:23:18 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <54E40201497DF142B06B27255953F79709CEF039@il0015exch007u.ih.lucent.com> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Tue, 6 Jan 2004 13:23:16 -0600 To: Mark Crispin From: Pete Resnick Subject: RE: [lemonade] IMAP push/pull plan Cc: "Vaudreuil, Greg M (Greg)" , Ted Hardie , Rob Siemborski , "IETF LEMONADE (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 1/5/04 at 6:35 PM -0800, Mark Crispin wrote: >On Mon, 5 Jan 2004, Vaudreuil, Greg M (Greg) wrote: >>If I have IMAP push, I can imagine being able to dispense with a >>client-accessible SMTP-submit server. This reduces the number of >>entities that must reside within the DMZ network that need access >>to fairly sensitive subscriber directory data. An authenticated >>submission server generally requires access to the users passwords >>(or encrypted passwords) stored in a directory by the server in the >>DMZ. > >This is an argument for a submission mechanism that is within the DMZ network. Actually, it sounds like there's more to it than that, but I'm not sure I fully understand the security implications: What I read Greg as saying is that with push, he can have one entity (the IMAP server) that has access to user authentication data, whereas if he has a submission server that users need to access, it would also need access to user authentication data. That *sounds* like a more secure environment, but again, I'm not sure I've got a full grasp of the security issues involved. Chairs: Can we get a security "geek" to give us some sort of review as to whether this is really an issue or not? -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Sun Jan 11 19:26:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24133 for ; Sun, 11 Jan 2004 19:26:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afptn-0000X1-E1 for lemonade-archive@odin.ietf.org; Sun, 11 Jan 2004 19:25:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0C0PhYA002037 for lemonade-archive@odin.ietf.org; Sun, 11 Jan 2004 19:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afptn-0000Wm-AV for lemonade-web-archive@optimus.ietf.org; Sun, 11 Jan 2004 19:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24128 for ; Sun, 11 Jan 2004 19:25:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afptg-0005UQ-00 for lemonade-web-archive@ietf.org; Sun, 11 Jan 2004 19:25:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afpr4-0005Pu-00 for lemonade-web-archive@ietf.org; Sun, 11 Jan 2004 19:22:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AfppH-0005MW-00 for lemonade-web-archive@ietf.org; Sun, 11 Jan 2004 19:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfppE-0000HK-K1; Sun, 11 Jan 2004 19:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af47i-0007gq-Ek for lemonade@optimus.ietf.org; Fri, 09 Jan 2004 16:24:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16126; Fri, 9 Jan 2004 16:24:51 -0500 (EST) Message-Id: <200401092124.QAA16126@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: lemonade@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 09 Jan 2004 16:24:51 -0500 Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-catenate-01.txt Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Internet Message Access Protocol (IMAP) CATENATE Extension Author(s) : P. Resnick Filename : draft-ietf-lemonade-catenate-01.txt Pages : 10 Date : 2004-1-9 The CATENATE extension to the Internet Message Access Protocol (IMAP) allows clients to create messages on the IMAP server which may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message on to a new message without having to first download the data and then upload it back to the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-catenate-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-catenate-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: <2004-1-9164412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-catenate-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-catenate-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-9164412.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Jan 20 12:06:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12800 for ; Tue, 20 Jan 2004 12:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AizK2-0001mG-Ue for lemonade-archive@odin.ietf.org; Tue, 20 Jan 2004 12:05:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KH5oXN006831 for lemonade-archive@odin.ietf.org; Tue, 20 Jan 2004 12:05:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AizK2-0001m6-Q8 for lemonade-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 12:05:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12783 for ; Tue, 20 Jan 2004 12:05:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AizK1-0006XR-00 for lemonade-web-archive@ietf.org; Tue, 20 Jan 2004 12:05:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AizJ6-0006SW-00 for lemonade-web-archive@ietf.org; Tue, 20 Jan 2004 12:04:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AizIL-0006NN-00 for lemonade-web-archive@ietf.org; Tue, 20 Jan 2004 12:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AizIH-0001ex-4w; Tue, 20 Jan 2004 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AizHh-0001cV-OE for lemonade@optimus.ietf.org; Tue, 20 Jan 2004 12:03:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12618 for ; Tue, 20 Jan 2004 12:03:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AizHg-0006KC-00 for lemonade@ietf.org; Tue, 20 Jan 2004 12:03:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AizGg-0006Fp-00 for lemonade@ietf.org; Tue, 20 Jan 2004 12:02:23 -0500 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 1AizFh-0006Af-00 for lemonade@ietf.org; Tue, 20 Jan 2004 12:01:22 -0500 Received: from il-tlv-mbdg2.comverse.com (il-tlv-mbdg2.comverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id i0KH0gM09883; Tue, 20 Jan 2004 19:00:45 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Jan 2004 19:00:54 +0200 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E0D010DE1@ismail3.comverse.com> From: Decktor Gev To: "'Lisa Dusseault'" , "'Joe Hildebrand'" Cc: "'lemonade@ietf.org'" Subject: [lemonade] Server To Server notification protocol requirements Date: Tue, 20 Jan 2004 19:00:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DF76.F605BED4" Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3DF76.F605BED4 Content-Type: text/plain; charset="windows-1255" Hi all, basically the points raised in the 58th IETF in the matter of server to server notification protocol requirements, could be divided into 2 main categories: 1. missing/inaccurate requirements details in the document as is 2. why not use XMPP as the answer for these requirements. XMPP's scope is IM, meaning two end point sending each other "small, simple messages that are delivered immediately to online users"(RFC2779). On the other hand Server to Server Messaging Notification (S2SMN), refers to a entity, which defines in an offline manner when and how it would like to be notified upon mailbox events. The entities, which have triggered the event aren't taking an active part in this scenario. This means that the notification event initiator (e.g. voice mail server) will send event about mailbox status change and the notification service will be responsible for deciding what to do with that information, how and when (i.e. the subscriber's notification preferences). In the IM world, the voice mail server from the previous example, would have to "know" the subscriber's notification preferences. As a result the notification service's functionality would diminish to being a gateway to non XMPP networks. This implies that any server which wishes to participate in this scenario, would have to "know" the subscriber's notification preferences as well AND there won't be a single notification logics entity (which would result different notification "look And Feel" for each message store (email messages Vs. Voice messages)) S2SMN is the problem described in part 6.3 of the lemonade goals draft(http://www.ietf.org/internet-drafts/draft-ietf-lemonade-goals-01.txt), not IM (although there may be many similarities). To sum up, XMPP would be regarded as a valid option for implementing the server to server notification protocol, yet this decision should be taken after agreeing on the requirements. These requirements should not be derived from existing protocols, but rather from the needed functionality as described in the charter. Regarding the feedbacks in the LEMONADE meeting itself, I intend to adapt the draft to answer to all of them. A new edition of the draft would be sent in the next week. Please, share you thoughts with me Thanx, Gev. ------_=_NextPart_001_01C3DF76.F605BED4 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable [lemonade] Server To Server notification protocol = requirements

Hi all,

basically the points raised in the 58th IETF in the = matter of server to server notification protocol requirements, could be = divided into 2 main categories:

1. missing/inaccurate requirements details in the = document as is
2. why not use XMPP as the answer for these = requirements.

XMPP's scope is IM, meaning two end point sending = each other "small, simple messages that are delivered immediately = to online users"(RFC2779). On the other hand Server to Server = Messaging Notification (S2SMN), refers to a entity, which defines in an = offline manner when and how it would like to be notified upon mailbox = events. The entities, which have triggered the event aren't taking an = active part in this scenario.

This means that the notification event initiator = (e.g. voice mail server) will send event about mailbox status change = and the notification service will be responsible for deciding what to = do with that information, how and when (i.e. the subscriber's = notification preferences).

In the IM world, the voice mail server from the = previous example, would have to "know" the subscriber's = notification preferences. As a result the notification service's = functionality would diminish to being a gateway to non XMPP networks. =

This implies that any server which wishes to = participate in this scenario, would have to "know" the = subscriber's notification preferences as well AND there won't be a = single notification logics entity (which would result different = notification "look And Feel" for each message store (email = messages Vs. Voice messages))

S2SMN is the problem described in part 6.3 of the = lemonade goals draft(http://www.ietf.org/internet-drafts/draft-ietf-lemonad= e-goals-01.txt), not IM (although there may be many = similarities).

To sum up,
XMPP would be regarded as a valid option for = implementing the server to server notification protocol, yet this = decision should be taken after agreeing on the requirements. These = requirements should not be derived from existing protocols, but rather = from the needed functionality as described in the charter.

Regarding the feedbacks in the LEMONADE meeting = itself, I intend to adapt the draft to answer to all of them. A new = edition of the draft would be sent in the next week.


Please,
share you thoughts with me
Thanx,
Gev.

------_=_NextPart_001_01C3DF76.F605BED4-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Jan 22 22:13:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26383 for ; Thu, 22 Jan 2004 22:13:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajrl5-0000wV-Ah for lemonade-archive@odin.ietf.org; Thu, 22 Jan 2004 22:13:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N3DNfm003617 for lemonade-archive@odin.ietf.org; Thu, 22 Jan 2004 22:13:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajrl0-0000wG-23 for lemonade-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 22:13:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26372 for ; Thu, 22 Jan 2004 22:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajrkr-0006nH-00 for lemonade-web-archive@ietf.org; Thu, 22 Jan 2004 22:13:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajriz-0006kF-00 for lemonade-web-archive@ietf.org; Thu, 22 Jan 2004 22:11:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjrgC-0006g9-00 for lemonade-web-archive@ietf.org; Thu, 22 Jan 2004 22:08:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajrft-0000gJ-9M; Thu, 22 Jan 2004 22:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajrf2-0000Nn-7e for lemonade@optimus.ietf.org; Thu, 22 Jan 2004 22:07:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26272 for ; Thu, 22 Jan 2004 22:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajreq-0006df-00 for lemonade@ietf.org; Thu, 22 Jan 2004 22:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajrbb-0006Zn-00 for lemonade@ietf.org; Thu, 22 Jan 2004 22:03:37 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1Ajran-0006WS-00 for lemonade@ietf.org; Thu, 22 Jan 2004 22:02:45 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i0N32JH8005193 for ; Thu, 22 Jan 2004 19:02:19 -0800 (PST) Received: from [192.168.1.13] (loud.qualcomm.com [129.46.74.63]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i0N32D0Q003942 for ; Thu, 22 Jan 2004 19:02:17 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v6.1a Date: Thu, 22 Jan 2004 19:01:56 -0800 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] IMAP push/pull plan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b26 Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Here is a long-delayed response to the flurry of emails that were sent in late December and early January. I've replied to everything in one long email, with significant snippage throughout. Because the snippage was so great, I didn't use ellipsis or "[snip]". Instead, I'm only including the direct quotation to which I'm replying. ---- At 11:29 AM -0800 12/23/03, Ted Hardie wrote: > For the overall architecture to have both authentication > and authorization, the pull model must actually use some form of > submission in which the sender is authenticated to the SMTP/submit server. > Though this is growing, individually authenticated submission is > still not the norm (IP-based allow lists seem to be) and those that > seem to be seen are of the pop-before-smtp type that limit deployment > in other ways. While I can see the value of a split > authentication/authorization > model, I am quite concerned about a model that will have no authentication > at all in the common case. I think the use of pop-before-smtp is fading off, as most of the popular clients support some form of SMTP AUTH, as do popular SMTP/Submit servers. For a few years now, some servers by default enable the message submission port (587) and require authentication on it. The use of IP-based authorization for message submission from within an organization's firewall is still widespread, for a variety of reasons, including the lack of perceived need for anything stronger. For access from outside, I see increasing use of SMTP AUTH. However, even in the case of unauthenticated submission, I'm not sure a pull model would be introducing any new risks: in the case of a forged email, the submitter would still need a valid pawn ticket to access the message or message fragment to be included. An attacker could potentially email data to himself using a stolen pawn ticket, but this risk depends on the pawn ticket (which has protections against it) and doesn't matter if the attacker authenticates to the Submit server or not (except that authenticating may help pinpoint the identity of the attacker, assuming the credentials are valid). An attacker could send forged mail, but this isn't affected by the inclusion of data from an IMAP server or not. > It is possible, of course, that we can make use of an > authentication mechanism > in the submit server a basic requirement of this protocol. This > adds, however, to the > deployment hurdle we must overcome. I don't think it adds much of a burden, given the widespread deployment of SMTP AUTH capable clients and servers. > As it stands, the historical tendency of IMAP development to put > complexity into the client rather than the server means that the > newly capable "SMTP/Submit Pull" servers will have to implement a > fair amount of code to act as IMAP clients. They will also have to > implement the code required to handle pawn tickets, as well as > their own form of authentication. The "historical tendency of IMAP development to put complexity into the client rather than the server" is one the hurdles to IMAP use on wireless devices that we (lemonade) are trying to address. I think SMTP AUTH support is already fairly widespread; servers shouldn't have to implement "their own form of authentication". > Making the locus of change for our work the SMTP/submit servers means we are > either at the mercy of or constraining other work related to spam abatement, > internationalization, etc. Without very careful coordination, we > could end up > with a protocol that will see little or no deployment, and I don't > think any of > us wants to waste our time. Even if we select a pull mode, I don't see it being at the mercy of, nor constraining, other SPAM-related work. I think the Submit changes are likely to be orthogonal. > The addition of SMTP client functionality to an IMAP server > seems to me far easier than the addition of IMAP client > functionality to an SMTP/Submit > server. I wouldn't say "far easier". Since we're talking about adding a very limited IMAP client functionality to a submit server, as compared to a conceptually unlimited submit functionality to an IMAP server, I see the efforts as being roughly equal, with a risk of feature creep making the IMAP work much larger. ---- At 4:43 PM -0800 12/23/03, Mark Crispin wrote: > SUBMIT implies considerable glue between IMAP and SMTP, which for all its > translation still winds up on the client. For example, note the untagged > SUBMIT response that returns SMTP commands and responses. It also lacks > support for SMTP service extensions (although it requires DSN), meaning > that if a service extension is needed the client is out of luck. Actually, the SUBMIT command has a mechanism for SMTP/Submit extensions. One of my concerns with adding submission to IMAP is the risk of creating two separate, and even worse, potentially divergent mechanisms, for message submission. In order to guard against the latter, and attempt to isolate the IMAP server from knowledge of SMTP/Submit extensions, I used annotations to allow the client to specify arbitrary SMTP/Submit extensions. > Both commands betray "do the minimum to address the task at hand" and "put > all the complexity in the IMAP server" thinking. The SUBMIT command does try to keep the IMAP server from needing to know anything about specific SMTP/Submit extensions. ---- At 3:06 PM -0800 12/29/03, Ted Hardie wrote: > I believe that Randy's draft could be a bit simpler, but that it > demonstrates the fundamentals > of the approach). Part of the complexity is the use of annotations, which is a device to allow SUBMIT to be used with SMTP/Submit extensions without requiring an IMAP-specific facility or knowledge of said extensions. > And while we're talking about the dangers of the easy path, I'd > like to point > out the danger in the Pull model: that Pull-based composition at > the SMTP/Submit > server seems likely to degenerate into Pulls from HTTP (or POP) > document stores instead > of IMAP stores. I can see a risk of this with either Push or Pull. At least with Pull, the mechanism to do so is more logical. I'd support a prohibition in the initial version of either model to limit its use to IMAP data stores, so that we can focus on the immediate task at hand. If and when either mechanism needs to access other kind of data, it can then be done as an extension. This can keep us from getting distracted by the security issues of non-IMAP URLs. ---- At 10:03 AM -0800 12/30/03, Mark Crispin wrote: > The other basic reason is the prospect of having to track all future > developments in SMTP in IMAP push. I note that the current IMAP submit > document pays little heed to SMTP extensions, and apparently expects that > by doing so IMAP submit will never have to consider SMTP extensions. I do > not believe that to be a viable position. The current IMAP SUBMIT document uses annotations to allow use of arbitrary SMTP/Submit extensions without tying them to the IMAP server. This does add complexity, however. ---- At 11:29 AM -0800 12/30/03, Ted Hardie wrote: > I note, though, that the same problem occurs for PULL; it can > force SMTP development > to track salient developments in the access protocols for PULL, > which would include > at least those in IMAP. No matter which connection we make, we > are talking about > entanglement here, and we need to go into that with our eyes open. It seems to me that it will be easier to limit entanglement in the Pull mode, since the Submit server doesn't need to know about or use most IMAP extensions. IMAP extensions are targeted at generalized IMAP clients, while a Submit server would be a highly specialized client. In contrast, once submission is added to IMAP, the IMAP server becomes a generalized Submit server and hence needs a way for clients to access arbitrary SMTP/Submit extensions. ---- At 6:48 PM -0800 12/30/03, Mark Crispin wrote: > > The strains on SMTP/Submit servers seem to me much higher, since they >> are also in the middle of the spam arms race > > Not necessarily! > > UW, like most other large organizations, has separate servers for submit > vs. incoming mail. Not only are they separate boxes, but are on > completely different subnets. > > > and a likely need to support >> new internationalization mechanisms. > > All the more reason to have one (and only one) submit mechanism. I agree, plus, I'm not sure there will be collisions between Pull and other SMTP work anyway; it seems fairly separate. ---- At 11:28 AM -0800 12/31/03, Ted Hardie wrote: > SUBMIT servers are or can be separate from incoming > mail. But the spam arms race includes those servers as well, as one of > the key ways folks fight spam is by ensuring that systems within their > administrative border aren't injecting it (either because of black hats or > "owned" boxes). That can be reactive (driven by black-list servers) or > proactive, but it is still a front in the war, so there is still a > strain here > on those systems. But if IMAP servers become Submit servers, then they are now too part of the same arms race, for the same reasons. > The same entanglement applies to both PULL and PUSH here, but PULL > is in a worse spot. The IMAP server is responsible in PUSH for ensuring > that the message is valid before injecting it into the SMTP/Submit > system; where the SMTP/Submit server must validate it as it is accessed > or assembled in the PULL view. That's a burden on the SMTP/Submit > server, and, as I said before, I think they are already in the more fragile > place in the overall system. But this is a fundamental purpose of Submit servers; in fact, the original impetus for Submission as separate from SMTP came from clients that were injecting improper messages, and SMTP servers that were "correcting" relayed messages. ---- At 1:07 PM -0500 1/2/04, Rob Siemborski wrote: > On Fri, 2 Jan 2004, Pete Resnick wrote: > > > Let's also remember that if you want to save a copy of the sent >> message, CATENATE gets you that for free. In the BURL/no-CATENATE >> model, you either are stuck with a template message or you have to >> get the submit server to give you a copy of the real message back. > > CATENATE seems to be the sanest way to solve the "I need an FCC" problem > when using BURL to submit the message. I agree that CATENATE seems the simplest way to solve the FCC problem, although there has also been talk of an IMAP extension to supply an email address which results in mail being added to a particular mailbox (such as Outbox). The MUA can then include this address in the envelope when it submits the message. It's been suggested that such an IMAP extension would be generally useful. > Personally, I don't really like the PUSH model in that it adds a new > submission mechanism, it assumes "everyone uses IMAP" and implies that if > we ever find a new mail retrieval protocol that everyone wants to switch > to after IMAP, we'll have to reinvent a submission mechanism for this > future protocol as well. I agree. > Up until this thread, the main drawback that I saw with the BURL model was > that getting a FCC back onto the IMAP server was hard. But I think that > the use of CATENATE solves that. > > I'm currently favoring a solution that used CATENATE+BURL+URLAUTH. > Sadly, I think this solution involves a lot of work on all sides > (SUBMIT/SMTP, IMAP, and client). However, I also feel that it gives us > all of the features that LEMONADE needs (forward without download, along > with draft messages and fcc capability), and is more future proof than the > CATENATE/SUBMIT model. I concur. ---- At 10:50 AM -0800 1/2/04, Mark Crispin wrote: > > Sadly, I think this solution involves a lot of work on all sides >> (SUBMIT/SMTP, IMAP, and client). > > Yes, it does. There are no "easy" ways out. > > However, the benefit of rolling up our sleeves and doing the right thing > is that the resulting technology can be leveraged for other purposes. We also avoid the risk of creating a new, parallel (and possibly divergent) submission mechanism for IMAP clients. ---- At 4:24 PM -0800 1/5/04, Ted Hardie wrote: > The security model for the restricted CATENATE > is pretty easy, since it is providing an IMAP command that uses > the same basic > permissions for a resource as would a download of that resource. > In my personal opinion, the draft needs a very different security > analysis if > the presumption is going to be that the facility can securely > retrieve external > non-public resources. It also needs to carefully lay out which > schemes can be > used (not all uri schemes have the presumption of data retrieval, > for example, > and the use of those in this context would not make much sense). I think we should focus on only restricted IMAP URLs for now, and add anything else as extensions, just to avoid this extra work at this time. ---- At 8:22 PM -0600 1/5/04, Greg M (Greg) Vaudreuil wrote: > I mildly favor the push model, in part because it feels more secure. > In my corner of the world, there is not a wide diversity of legacy > clients. If I have IMAP push, I can imagine being able to dispense > with a client-accessible SMTP-submit server. It's not just legacy clients that don't use IMAP. There are a lot of "hidden" submit-only clients in most organizations, including small programs, scripts, web forms, etc. You can put your Submit and IMAP servers in the DMZ, or you let authorized people use a VPN to get inside and use the interior systems. Many large organizations use the latter approach, in part to avoid having boxes in the DMZ with access to user data. > This reduces the number of entities that must reside within the > DMZ network that need access to fairly sensitive subscriber > directory data. An authenticated submission server generally > requires access to the users passwords (or encrypted passwords) > stored in a directory by the server in the DMZ. Or access to an LDAP or AAA or other such server. Or by using client-side certificates and TLS. The Submit and IMAP servers themselves don't need access to the authentication data; they need to be able to authenticate users. > An IMAP proxy server in the DMZ only needs access to more limited > information mapping the recipient identity to a message store... or > less. Gaining control of the IMAP proxy does not gain access to > the password data. Gaining access to a submission server does get > me access to enough info to authenticate the user.... and to play > off-line guess the password games. You can use proxy servers for submission as well as for IMAP. You also don't need to give the systems access to the authentication credentials. You also don't need to have these boxes in the DMZ if you use VPNs. There are many approaches. > So, if I get push submission via IMAP, I think I get a more secure > environment for my end-users. I also get fewer client-to-server > protocols to manage and fewer firewall rules. Overall, this feels > like a pretty good win for push. If you tunnel everything over SSH then you only have one protocol to manage in the DMZ and one firewall rule. That's even better. If you use Webmail then you run everything over HTTP and again you only have one protocol and one firewall rule. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Seduced, shaggy Samson snored. She scissored short. Sorely shorn, Soon shackled slave, Samson sighed, Silently scheming, Sightlessly seeking Some savage, spectacular suicide. --Stanislaw Lem _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Sun Jan 25 15:37:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16886 for ; Sun, 25 Jan 2004 15:37:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akr0b-00088y-CC for lemonade-archive@odin.ietf.org; Sun, 25 Jan 2004 15:37:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PKbTEu031301 for lemonade-archive@odin.ietf.org; Sun, 25 Jan 2004 15:37:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akr0Y-00087k-Dz for lemonade-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 15:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16883 for ; Sun, 25 Jan 2004 15:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Akr0X-0000VE-00 for lemonade-web-archive@ietf.org; Sun, 25 Jan 2004 15:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akqza-0000TA-00 for lemonade-web-archive@ietf.org; Sun, 25 Jan 2004 15:36:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkqzG-0000RK-00 for lemonade-web-archive@ietf.org; Sun, 25 Jan 2004 15:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkqzC-0007vq-Fw; Sun, 25 Jan 2004 15:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkVSN-0004c2-Dp for lemonade@optimus.ietf.org; Sat, 24 Jan 2004 16:36:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24960 for ; Sat, 24 Jan 2004 16:36:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkVSL-0005De-00 for lemonade@ietf.org; Sat, 24 Jan 2004 16:36:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkVRN-0005BM-00 for lemonade@ietf.org; Sat, 24 Jan 2004 16:35:41 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AkVR8-00059o-00; Sat, 24 Jan 2004 16:35:26 -0500 Received: from [63.202.92.156] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OLZMic066706; Sat, 24 Jan 2004 13:35:22 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sat, 24 Jan 2004 13:35:24 -0800 To: (various IETF lists) From: Paul Hoffman / IMC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [lemonade] New mail-ng mailing list open for sign-ups Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL autolearn=no version=2.60 Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Jan 27 06:30:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00323 for ; Tue, 27 Jan 2004 06:30:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRPd-00072z-C1 for lemonade-archive@odin.ietf.org; Tue, 27 Jan 2004 06:29:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RBTjbA027078 for lemonade-archive@odin.ietf.org; Tue, 27 Jan 2004 06:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRPd-00072R-7b for lemonade-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 06:29:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00286 for ; Tue, 27 Jan 2004 06:29:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlRPZ-0001KR-00 for lemonade-web-archive@ietf.org; Tue, 27 Jan 2004 06:29:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlROk-0001HZ-00 for lemonade-web-archive@ietf.org; Tue, 27 Jan 2004 06:28:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlRNy-0001Dw-00 for lemonade-web-archive@ietf.org; Tue, 27 Jan 2004 06:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRNx-00045o-6j; Tue, 27 Jan 2004 06:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRNd-00044o-Js for lemonade@optimus.ietf.org; Tue, 27 Jan 2004 06:27:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00173 for ; Tue, 27 Jan 2004 06:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlRNZ-0001BB-00 for lemonade@ietf.org; Tue, 27 Jan 2004 06:27:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlRMd-00017C-00 for lemonade@ietf.org; Tue, 27 Jan 2004 06:26:39 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx with esmtp (Exim 4.12) id 1AlRLj-00012Q-00 for lemonade@ietf.org; Tue, 27 Jan 2004 06:25:43 -0500 Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i0RBP8Th011186 for ; Tue, 27 Jan 2004 04:25:10 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Tue, 27 Jan 2004 03:25:09 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org Message-ID: <2147483647.1075173909@d154-5-112-162.bchsia.telus.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [lemonade] Channel Update Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've just sent in an updated version of the Channel draft. The major changes are: * revert to the base spec (usage document is split out) * rationalize grammar against RFC 3501 (IMAP) * further grammar changes to incorporate URI-type elements into IMAP astrings in order to simplify (I hope) parsing this stuff * clarify schemes and URIs in the context of the grammar and protocol That said, the protocol and grammar are still a bit fuzzy. The use of versus "(" ")" lists isn't as consistent as I would like, therefore the protocol police should rip the grammar to shreds and regularize it with 3501 further than my late night effort managed to achieve. The document needs a section describing how URIs should be interpreted (on both ends). I think URI interpretation should be very open ended; flexibility is a must if this is to work usefully in the field. But the document needs a section to give guidance to implementers on how to interpret those URIs. especially in the context of partially-formed URIs -- something we will be instigators of, in this context. (See my lame FTP example in the memo for an idea of what I'm getting at.) --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Jan 28 08:20:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29862 for ; Wed, 28 Jan 2004 08:20:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpbQ-00059T-Hv for lemonade-archive@odin.ietf.org; Wed, 28 Jan 2004 08:19:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SDJWYi019798 for lemonade-archive@odin.ietf.org; Wed, 28 Jan 2004 08:19:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpbQ-000592-DD for lemonade-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 08:19:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29840 for ; Wed, 28 Jan 2004 08:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlpbP-0000P5-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 08:19:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpaT-0000LT-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 08:18:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alpa2-0000He-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 08:18:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Alpa3-0007ZT-29 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 08:18:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpZx-00052A-8Q; Wed, 28 Jan 2004 08:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpZX-00050R-FO for lemonade@optimus.ietf.org; Wed, 28 Jan 2004 08:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29802 for ; Wed, 28 Jan 2004 08:17:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlpZW-0000Gy-00 for lemonade@ietf.org; Wed, 28 Jan 2004 08:17:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpYc-0000Cc-00 for lemonade@ietf.org; Wed, 28 Jan 2004 08:16:39 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AlpYL-00003b-01 for lemonade@ietf.org; Wed, 28 Jan 2004 08:16:22 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 7758; Wed, 28 Jan 2004 08:17:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jan 2004 08:15:56 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A09D@zoe.office.snowshore.com> Thread-Topic: [lemonade] IMAP push/pull plan Thread-Index: AcPT8fWj3ENb0F50S3K2rcXruFekMQRG/Uog From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Non-Client Compose and Forward Without Download Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think Ted hit the nail on the head with this one. I didn't see any = further discussion on the topic. I think we need to tackle the issue of = choosing Forward Without Download versus Non-Client Compose first. Once = we know the problem to solve, we can solve it. At this time, I am only opening up a DISCUSSION on the lemonade charter = scope. What I am asking for is consensus that the charter is (or is = not) appropriately scoped. In particular, I am looking for discussion as to the need (technical and = market) for Non-Client Compose. Things I can think of, off the top of my head (where my hair used to be) = are: Pro: - People tend to naturally gravitate to solve it. Many Forward Without = Download proposals artificially limit themselves to NOT address = Non-Client Compose. - Forward Without Download comes for free if we solve Non-Client = Compose, as it is a proper subset. - This is an interesting problem that keeps coming up. There is the = potential that a Forward Without Download solution can become obsolete = in the very near future. Con: - The security issues of Non-Client Compose appear to be more complex = than for Forward Without Download. - Will we ever finish? > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, January 05, 2004 8:02 PM [snip] > There is a very critical scope question here, from my point of view. > If the working group sees this task as developing what we might call > "non-client compose", in which the client can direct some server > (be it Submit or IMAP) to assemble a message from multiple > data sources without downloading the parts, then the "compose > from a single, local data source" would be a degenerate case of the > "non-client compose". Using the same mechanism for the > degenerate case as the full functionality makes lots of sense. [snip] > Again speaking personally, if the consensus of the working group > is that the task is "non-client compose", rather than "forward without > download", then I am not really sure that either a Submit server or > an IMAP server would be the right place to do the work. Revisiting > the use of a multi-function proxy might be appropriate in that > case, because the core functionality may be beyond what are > safe and sane ways to extend IMAP or Submit servers. I am nagged, > though, by the idea that we will end up re-inventing the remote shell, > as that is what I and many others use to handle this problem > (I sometimes use ssh to reach a remote server with better connectivity > when I need to handle email over a very poor link; sometimes, though, > I take it as a sign to take a day or two away from email. This is the > source of the delay in my reply to this message. Apologies for any > inconvenience). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Jan 28 15:39:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27073 for ; Wed, 28 Jan 2004 15:39:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwSU-00076B-Og for lemonade-archive@odin.ietf.org; Wed, 28 Jan 2004 15:38:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SKckrU027283 for lemonade-archive@odin.ietf.org; Wed, 28 Jan 2004 15:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwSU-00075y-KZ for lemonade-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 15:38:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27065 for ; Wed, 28 Jan 2004 15:38:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlwST-0000K0-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 15:38:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlwRc-0000FD-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 15:37:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlwQn-00009i-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 15:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwQm-0006hw-NK; Wed, 28 Jan 2004 15:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwQj-0006ga-2Y for lemonade@optimus.ietf.org; Wed, 28 Jan 2004 15:36:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26997 for ; Wed, 28 Jan 2004 15:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlwQh-00008Y-00 for lemonade@ietf.org; Wed, 28 Jan 2004 15:36:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlwPp-00002E-00 for lemonade@ietf.org; Wed, 28 Jan 2004 15:36:01 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx with esmtp (Exim 4.12) id 1AlwPQ-0007j8-00 for lemonade@ietf.org; Wed, 28 Jan 2004 15:35:36 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0SKZZMM020681 for ; Wed, 28 Jan 2004 12:35:35 -0800 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0SKZFJ1028859 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 28 Jan 2004 12:35:23 -0800 X-Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Wed, 28 Jan 2004 08:28:12 -0800 (PST) X-Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.140]) by ndcms.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0SGSCiZ032000; Wed, 28 Jan 2004 08:28:12 -0800 X-Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0SGRwVM026065; Wed, 28 Jan 2004 08:27:59 -0800 X-Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFt-000729-PJ for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:29 -0500 X-Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsDZ-0006s4-O3 for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:07:05 -0500 X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06469 for ; Wed, 28 Jan 2004 11:07:02 -0500 (EST) Message-Id: <200401281607.LAA06469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 Jan 2004 11:07:02 -0500 Precedence: bulk X-Uwash-Spam: Gauge=XII, Probability=12%, Report='MIME_BOUND_NEXTPART 1.085, NO_REAL_NAME 0.000' ReSent-Date: Wed, 28 Jan 2004 12:35:22 -0800 (Pacific Standard Time) ReSent-From: Mark Crispin ReSent-To: lemonade@ietf.org ReSent-Subject: I-D ACTION:draft-crispin-imap-urlauth-06.txt ReSent-Message-ID: ReSent-Sender: mrc@ndcms.cac.washington.edu Subject: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-06.txt Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Message Access Protocol (IMAP) - URLAUTH Extension Author(s) : M. Crispin, C. Newman Filename : draft-crispin-imap-urlauth-06.txt Pages : 8 Date : 2004-1-27 This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can create 'signed' URLs which can be used to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of 'URLAUTH'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-crispin-imap-urlauth-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imap-urlauth-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imap-urlauth-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imap-urlauth-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112659.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Jan 28 15:42:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27204 for ; Wed, 28 Jan 2004 15:42:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwVN-0007Ru-Iu for lemonade-archive@odin.ietf.org; Wed, 28 Jan 2004 15:41:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SKfj9J028628 for lemonade-archive@odin.ietf.org; Wed, 28 Jan 2004 15:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwVN-0007Rf-EG for lemonade-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 15:41:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27194 for ; Wed, 28 Jan 2004 15:41:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlwVL-0000bP-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 15:41:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlwUT-0000X6-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 15:40:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlwTk-0000SM-00 for lemonade-web-archive@ietf.org; Wed, 28 Jan 2004 15:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwTk-0007Ar-8n; Wed, 28 Jan 2004 15:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlwTW-00079T-2M for lemonade@optimus.ietf.org; Wed, 28 Jan 2004 15:39:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27113 for ; Wed, 28 Jan 2004 15:39:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlwTU-0000Qw-00 for lemonade@ietf.org; Wed, 28 Jan 2004 15:39:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlwSb-0000LX-00 for lemonade@ietf.org; Wed, 28 Jan 2004 15:38:54 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx with esmtp (Exim 4.12) id 1AlwRu-0000Fo-00 for lemonade@ietf.org; Wed, 28 Jan 2004 15:38:10 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0SKc9TZ027935 for ; Wed, 28 Jan 2004 12:38:09 -0800 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0SKblS6026270 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 28 Jan 2004 12:38:06 -0800 Date: Wed, 28 Jan 2004 12:38:01 -0800 (Pacific Standard Time) From: Mark Crispin To: lemonade@ietf.org Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [lemonade] updated URLAUTH document & status of pull document Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I sent an updated URLAUTH document (draft-crispin-imap-urlauth-06.txt) to the I-D repository as well as a pull document. Unfortunately, the pull document got mishandled and is still not available. I'm trying to get that straightened out and I'll announce the pull document when I know that it's there. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Jan 29 14:30:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10617 for ; Thu, 29 Jan 2004 14:30:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHrB-00072Q-8z for lemonade-archive@odin.ietf.org; Thu, 29 Jan 2004 14:29:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TJTfQi027054 for lemonade-archive@odin.ietf.org; Thu, 29 Jan 2004 14:29:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHrB-00072H-45 for lemonade-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 14:29:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10569 for ; Thu, 29 Jan 2004 14:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHr8-0004hk-00 for lemonade-web-archive@ietf.org; Thu, 29 Jan 2004 14:29:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHqA-0004bB-00 for lemonade-web-archive@ietf.org; Thu, 29 Jan 2004 14:28:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmHpc-0004Uo-00 for lemonade-web-archive@ietf.org; Thu, 29 Jan 2004 14:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHpa-0006yp-JT; Thu, 29 Jan 2004 14:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHpP-0006xy-EX for lemonade@optimus.ietf.org; Thu, 29 Jan 2004 14:27:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10428 for ; Thu, 29 Jan 2004 14:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHpM-0004Uh-00 for lemonade@ietf.org; Thu, 29 Jan 2004 14:27:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHoQ-0004Lv-00 for lemonade@ietf.org; Thu, 29 Jan 2004 14:26:51 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1AmHnu-0004DF-00 for lemonade@ietf.org; Thu, 29 Jan 2004 14:26:18 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TJQHGN006336 for ; Thu, 29 Jan 2004 11:26:17 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TJQHDG001546 for ; Thu, 29 Jan 2004 11:26:17 -0800 Date: Thu, 29 Jan 2004 11:26:17 -0800 (PST) From: Mark Crispin To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [lemonade] pull document... Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I don't know what's going on. The I-D repository has a bogus draft-crispin-lemonade-pull-01.txt written on January 28 that alleges that my draft-crispin-lemonade-pull-00.txt was deleted due to having expired after 6 months. That document was submitted on January 23, 2004. I don't know how 5 days equals 6 months. I re-submitted the document yesterday, and pointed out that this was a new document. My request was ignored. What is going on? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Jan 29 22:27:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09278 for ; Thu, 29 Jan 2004 22:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmPIw-0002Sd-5t for lemonade-archive@odin.ietf.org; Thu, 29 Jan 2004 22:26:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U3QorQ009453 for lemonade-archive@odin.ietf.org; Thu, 29 Jan 2004 22:26:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmPIv-0002SO-UX for lemonade-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 22:26:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09272 for ; Thu, 29 Jan 2004 22:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmPIs-0007DM-00 for lemonade-web-archive@ietf.org; Thu, 29 Jan 2004 22:26:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmPHx-00077e-00 for lemonade-web-archive@ietf.org; Thu, 29 Jan 2004 22:25:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmPHC-00071p-00 for lemonade-web-archive@ietf.org; Thu, 29 Jan 2004 22:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmPHD-0002Hp-3l; Thu, 29 Jan 2004 22:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmPH5-0002Gp-TP for lemonade@optimus.ietf.org; Thu, 29 Jan 2004 22:24:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09233 for ; Thu, 29 Jan 2004 22:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmPH2-000717-00 for lemonade@ietf.org; Thu, 29 Jan 2004 22:24:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmPG6-0006up-00 for lemonade@ietf.org; Thu, 29 Jan 2004 22:23:55 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx with esmtp (Exim 4.12) id 1AmPFL-0006gj-00 for lemonade@ietf.org; Thu, 29 Jan 2004 22:23:07 -0500 Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i0U3MXTh029992 for ; Thu, 29 Jan 2004 20:22:34 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 29 Jan 2004 19:22:28 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org Message-ID: <2147483647.1075404148@d154-5-112-162.bchsia.telus.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [lemonade] channel draft Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I screwed up the version number when I submitted the channel draft, thus the delay in getting it published. A temporary copy is at http://orthanc.ca/draft-ietf-lemonade-imap-channel-01.txt The "Changes in -02" section should read "... -01" -- I missed that when I renumbered the version. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Jan 30 16:32:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18416 for ; Fri, 30 Jan 2004 16:32:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgFW-0002hO-KC for lemonade-archive@odin.ietf.org; Fri, 30 Jan 2004 16:32:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULWQxX010373 for lemonade-archive@odin.ietf.org; Fri, 30 Jan 2004 16:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgFW-0002hE-FK for lemonade-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:32:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18403 for ; Fri, 30 Jan 2004 16:32:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgFU-0002jN-00 for lemonade-web-archive@ietf.org; Fri, 30 Jan 2004 16:32:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgEa-0002dZ-00 for lemonade-web-archive@ietf.org; Fri, 30 Jan 2004 16:31:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmgEC-0002XP-00 for lemonade-web-archive@ietf.org; Fri, 30 Jan 2004 16:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgE9-0002cd-5y; Fri, 30 Jan 2004 16:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgDb-0002Uk-Lz for lemonade@optimus.ietf.org; Fri, 30 Jan 2004 16:30:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18329 for ; Fri, 30 Jan 2004 16:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgDZ-0002WN-00 for lemonade@ietf.org; Fri, 30 Jan 2004 16:30:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgCg-0002QJ-00 for lemonade@ietf.org; Fri, 30 Jan 2004 16:29:30 -0500 Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx with esmtp (Exim 4.12) id 1AmgCA-0002Jj-00 for lemonade@ietf.org; Fri, 30 Jan 2004 16:28:59 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0ULSw9h013180 for ; Fri, 30 Jan 2004 13:28:58 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0ULSwio029136 for ; Fri, 30 Jan 2004 13:28:58 -0800 Date: Fri, 30 Jan 2004 13:28:58 -0800 (PST) From: Mark Crispin To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [lemonade] Pull document on I-D repository Sender: lemonade-admin@ietf.org Errors-To: lemonade-admin@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enhancements to Internet email to support diverse service enivronments List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I haven't seen any announcement, but the -00 version of the Pull document for Lemonade is now on http://www.ietf.org/internet-drafts/draft-crispin-lemonade-pull-00.txt and ftp://ftp.ietf.org/internet-drafts/draft-crispin-lemonade-pull-00.txt Please ignore the bogus -01 file. This document discusses the mechanisms of message sending; advantages of pull over push; describes traditional strategy, push strategy, and three variants (BURL, BURL/CATENATE, and BURL/embedded URI) of pull strategy; and finally discusses authorization mechanisms in these strategies. -- 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