From exim@www1.ietf.org Sun Feb 1 09:56:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19858 for ; Sun, 1 Feb 2004 09:56: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 1AnJ1C-0007sL-D6 for lemonade-archive@odin.ietf.org; Sun, 01 Feb 2004 09:56:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11EuEka030267 for lemonade-archive@odin.ietf.org; Sun, 1 Feb 2004 09:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJ1C-0007s6-7u for lemonade-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 09:56:14 -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 JAA19544 for ; Sun, 1 Feb 2004 09:56:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJ1A-0000Wj-00 for lemonade-web-archive@ietf.org; Sun, 01 Feb 2004 09:56:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnIc8-00025f-00 for lemonade-web-archive@ietf.org; Sun, 01 Feb 2004 09:30:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIOw-0006UO-01 for lemonade-web-archive@ietf.org; Sun, 01 Feb 2004 09:16:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIIb-0004oL-Bv for lemonade-web-archive@ietf.org; Sun, 01 Feb 2004 09:10:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIIX-0002Gx-09 for lemonade-web-archive@ietf.org; Sun, 01 Feb 2004 09:10:05 -0500 Date: Sun, 01 Feb 2004 09:10:04 -0500 Message-ID: <20040201141004.1364.62922.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 Mon Feb 2 13:13:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28187 for ; Mon, 2 Feb 2004 13:13: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 1AniZS-0007rB-66 for lemonade-archive@odin.ietf.org; Mon, 02 Feb 2004 13:13:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IDITs030191 for lemonade-archive@odin.ietf.org; Mon, 2 Feb 2004 13:13:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniZR-0007qo-Ug for lemonade-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:13: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 NAA28138 for ; Mon, 2 Feb 2004 13:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniZP-0003o2-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 13:13:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniYM-0003cS-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 13:12:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AniXJ-0003QJ-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 13: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 1AniXH-0007Y2-LG; Mon, 02 Feb 2004 13:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniWr-0007Vf-1Y for lemonade@optimus.ietf.org; Mon, 02 Feb 2004 13:10:38 -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 NAA27864 for ; Mon, 2 Feb 2004 13:10:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniWp-0003IW-00 for lemonade@ietf.org; Mon, 02 Feb 2004 13:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniV9-0002vd-00 for lemonade@ietf.org; Mon, 02 Feb 2004 13:08:54 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AniRk-0001pp-00 for lemonade@ietf.org; Mon, 02 Feb 2004 13:05:20 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12I4lJ08851 for ; Mon, 2 Feb 2004 12:04:47 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id ; Mon, 2 Feb 2004 12:04:46 -0600 Message-ID: <54E40201497DF142B06B27255953F7970A75B359@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Eric Burger , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] Non-Client Compose and Forward Without Download Date: Mon, 2 Feb 2004 12:04:40 -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 I believe in cutting down the problem to the minimum we can all agree to. The minimum we agreed we needed at chartering time is forward without download. That is still enough for me to make standards-based compelling products and services. I note that the emerging wireless messaging market is demanding, and industry is providing, products that perform forward without download. I see no such pressure for generalized client composition. The question on whether to upscope already has prevented a decision on the planned timeframe and threatens to delay this key decision well past Korea. I fear that the more "speculative" work towards a general client composition extension will unnecessarily delay our work and entrench the growing base of proprietary HTTP or WAP-based solutions. We are blocked on this decision... many lemonade-required protocol elements can't be designed until we know whether we are push or pull. Greg V. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Wednesday, January 28, 2004 7:16 AM To: IETF LEMONADE (E-mail) Subject: [lemonade] Non-Client Compose and Forward Without Download 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 2 14:39:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04538 for ; Mon, 2 Feb 2004 14:39:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjuF-0007sq-Vk for lemonade-archive@odin.ietf.org; Mon, 02 Feb 2004 14:38:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12JcpMV030298 for lemonade-archive@odin.ietf.org; Mon, 2 Feb 2004 14:38:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjuF-0007sb-Ok for lemonade-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:38: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 OAA04520 for ; Mon, 2 Feb 2004 14:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjuD-00011D-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 14:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjtM-0000va-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 14:37:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjsS-0000px-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 14:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjsT-0007WD-Go; Mon, 02 Feb 2004 14:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjsO-0007Vk-7y for lemonade@optimus.ietf.org; Mon, 02 Feb 2004 14:36:56 -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 OAA04433 for ; Mon, 2 Feb 2004 14:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjsL-0000oi-00 for lemonade@ietf.org; Mon, 02 Feb 2004 14:36:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjrS-0000jG-00 for lemonade@ietf.org; Mon, 02 Feb 2004 14:35:58 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx with esmtp (Exim 4.12) id 1AnjqX-0000dD-00 for lemonade@ietf.org; Mon, 02 Feb 2004 14:35:01 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i12JYsFp020877; Mon, 2 Feb 2004 11:34:54 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i12JYsle007939; Mon, 2 Feb 2004 11:34:54 -0800 Date: Mon, 2 Feb 2004 11:34:54 -0800 (PST) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" cc: Eric Burger , "IETF LEMONADE (E-mail)" Subject: RE: [lemonade] Non-Client Compose and Forward Without Download In-Reply-To: <54E40201497DF142B06B27255953F7970A75B359@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F7970A75B359@il0015exch007u.ih.lucent.com> 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 I am very distressed by the implication that a final decision must be made in Seoul. Many of us don't have the luxury of employers who will pay for unlimited junkets around the world, and will not be in Seoul. The argument of "we have to do something now, otherwise our competition will overwhelm us" has been used many times to cover many sins. In our own field of email, we are being overwhelmed by viruses brought about by email software which had to display pretty pictures and sounds "now" without waiting for proper engineering. We should learn from this lesson and repeat the same mistake. We are the Internet *Engineering* Task Force, and should keep that word "engineering" in mind. Both the pull and push strategies include composition. Indeed, one of the variants of pull strategies outlined in draft-crispin-lemonade-pull-00.txt uses the same composition facility that has been advanced for pull. Push requires composition, as does two of the three variants of pull. If you reject composition as a task, then the *only* choice is pull with the embedded URI variant, as described in draft-crispin-lemonade-pull-00.txt Although the embedded URI variant of pull is the simplest of all choices from a client submission protocol standpoint, it doesn't address all the problems. In particular, a solution to the fcc problem is needed. I have some ideas on how to do this, but I didn't want to waste too much time working on it given that two of the other three choices solve the fcc problem. -- 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 Feb 2 15:58:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08900 for ; Mon, 2 Feb 2004 15:58:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl8l-0006yF-Gq for lemonade-archive@odin.ietf.org; Mon, 02 Feb 2004 15:57:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Kvtgd026789 for lemonade-archive@odin.ietf.org; Mon, 2 Feb 2004 15:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl8l-0006y0-Bu for lemonade-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:57: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 PAA08860 for ; Mon, 2 Feb 2004 15:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anl8j-0000NN-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 15:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anl7v-0000HY-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 15:57:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anl79-0000Au-00 for lemonade-web-archive@ietf.org; Mon, 02 Feb 2004 15:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl6w-0006a5-Uk; Mon, 02 Feb 2004 15: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 1Anl6r-0006W6-FQ for lemonade@optimus.ietf.org; Mon, 02 Feb 2004 15:55:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08515; Mon, 2 Feb 2004 15:55:54 -0500 (EST) Message-Id: <200402022055.PAA08515@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: Mon, 02 Feb 2004 15:55:54 -0500 Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-channel-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.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. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP4 Channel Transport Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-lemonade-imap-channel-01.txt Pages : 6 Date : 2004-2-2 This specifications defines a method for IMAP4 clients to retrieve message content via an external (i.e. non-IMAP) protocol mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-channel-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-imap-channel-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-channel-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-2-2150151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-channel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-channel-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150151.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 6 15:02:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12431 for ; Fri, 6 Feb 2004 15:02: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 1ApCAs-0002xR-Bs for lemonade-archive@odin.ietf.org; Fri, 06 Feb 2004 15:02:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16K22Al011362 for lemonade-archive@odin.ietf.org; Fri, 6 Feb 2004 15:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCAs-0002wu-5z for lemonade-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 15:02: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 PAA12421 for ; Fri, 6 Feb 2004 15:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCAp-0007jk-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 15:01:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApC9r-0007fx-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 15:01:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApC90-0007c7-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 15:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC8y-0000Ar-9N; Fri, 06 Feb 2004 15:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC85-0008Uo-Tw for lemonade@optimus.ietf.org; Fri, 06 Feb 2004 14:59:09 -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 OAA12336 for ; Fri, 6 Feb 2004 14:59:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApC83-0007XN-00 for lemonade@ietf.org; Fri, 06 Feb 2004 14:59:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApC74-0007T6-00 for lemonade@ietf.org; Fri, 06 Feb 2004 14:58:07 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1ApC6X-0007Nu-00 for lemonade@ietf.org; Fri, 06 Feb 2004 14:57:34 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 28247; Fri, 06 Feb 2004 14:58:32 -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: Fri, 6 Feb 2004 14:57:01 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB242B6@zoe.office.snowshore.com> Thread-Topic: 59th IETF Agenda - As of 2/4/2004 Thread-Index: AcPrZqhj0MEF4U3PRHKLUPy3Ot++XgBhIyaA From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] FW: 59th IETF Agenda - As of 2/4/2004 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: quoted-printable Content-Transfer-Encoding: quoted-printable This is very preliminary. Very subject to change without notice. Note that we DO have a multicast session -- Mark et. al should be able = to tap in and participate. 9am 3/3 Korea is 4pm 3/2 in California. -----Original Message----- DRAFT Agenda of the Fifty-ninth IETF February 29 - March 5, 2004 WEDNESDAY, March 3, 2004 0800-1700 IETF Registration =20 0800-0900 Continental Breakfast =20 0900-1130 Morning Sessions APP lemonade Enhancements to Internet email to Support Diverse = Service Environments=20 WG * GEN icar Improved Cross Area Review BOF OPS multi6 Site Multihoming in IPv6 WG RTG ccamp Common Control and Measurement Plane WG SEC inch Extended Incident Handling WG TSV enum Telephone Number Mapping WG _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 6 16:57:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23806 for ; Fri, 6 Feb 2004 16:57: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 1ApDyD-0002qt-Bf for lemonade-archive@odin.ietf.org; Fri, 06 Feb 2004 16:57:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Lv566010960 for lemonade-archive@odin.ietf.org; Fri, 6 Feb 2004 16:57:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDyD-0002qh-2O for lemonade-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 16:57:05 -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 QAA23668 for ; Fri, 6 Feb 2004 16:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDyB-00052h-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDvp-0004YQ-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:54:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApDuZ-0004JM-01 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:53:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApDqP-0008EA-UK for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDqP-00028Y-0t; Fri, 06 Feb 2004 16:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDqG-00028F-1P for lemonade@optimus.ietf.org; Fri, 06 Feb 2004 16:48:52 -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 QAA22812 for ; Fri, 6 Feb 2004 16:48:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDqE-0003fe-00 for lemonade@ietf.org; Fri, 06 Feb 2004 16:48:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDpG-0003U5-00 for lemonade@ietf.org; Fri, 06 Feb 2004 16:47:50 -0500 Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx with esmtp (Exim 4.12) id 1ApDo2-0003FH-00 for lemonade@ietf.org; Fri, 06 Feb 2004 16:46:34 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i16LkW9h004745 for ; Fri, 6 Feb 2004 13:46:32 -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.11+UW04.02) with ESMTP id i16LkWsa028795 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Feb 2004 13:46:32 -0800 X-Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Fri, 6 Feb 2004 13:14:03 -0800 (PST) X-Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by ndcms.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i16LE3X5018176; Fri, 6 Feb 2004 13:14:03 -0800 X-Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i16LDrGU011821; Fri, 6 Feb 2004 13:13:53 -0800 X-Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1ApD0E-0007Rl-Oa for ietf-announce-list@asgard.ietf.org; Fri, 06 Feb 2004 15:55:06 -0500 X-Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1ApCnv-0007Fg-8f for all-ietf@asgard.ietf.org; Fri, 06 Feb 2004 15:42:23 -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 PAA15156 for ; Fri, 6 Feb 2004 15:42:20 -0500 (EST) Message-Id: <200402062042.PAA15156@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: Fri, 06 Feb 2004 15:42:20 -0500 Precedence: bulk X-Uwash-Spam: Gauge=XII, Probability=12%, Report='MIME_BOUND_NEXTPART 1.085, NO_REAL_NAME 0.000' ReSent-Date: Fri, 6 Feb 2004 13:46:27 -0800 (Pacific Standard Time) ReSent-From: Mark Crispin ReSent-To: lemonade@ietf.org ReSent-Subject: I-D ACTION:draft-crispin-lemonade-pull-01.txt ReSent-Message-ID: ReSent-Sender: mrc@ndcms.cac.washington.edu Subject: [lemonade] I-D ACTION:draft-crispin-lemonade-pull-01.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 : Message Submission Author(s) : M. Crispin Filename : draft-crispin-lemonade-pull-01.txt Pages : 0 Date : 2004-2-6 This document describes a set of strategies to allow clients to submit new email messages incorporating content which resides on locations external to the client. This is the so-called 'IMAP Pull' approach currently being considered by the LEMONADE working group as one solution to the 'forward without download' problem (that is, as a means for clients to send new messages consisting of or containing all or parts of previously received messages without having to download and upload the data). Some of the strategies in this document rely upon extensions to other protocols; specifically URLAUTH and CATENATE in the IMAP protocol (RFC 3501) and BURL in the SUBMIT protocol (RFC 2476). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-lemonade-pull-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-crispin-lemonade-pull-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-crispin-lemonade-pull-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-2-6155746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-lemonade-pull-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-lemonade-pull-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6155746.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 6 17:00:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24567 for ; Fri, 6 Feb 2004 17:00:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApE16-0003AZ-1E for lemonade-archive@odin.ietf.org; Fri, 06 Feb 2004 17:00:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16M03e1012158 for lemonade-archive@odin.ietf.org; Fri, 6 Feb 2004 17:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApE13-00039u-FZ for lemonade-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:00: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 QAA24510 for ; Fri, 6 Feb 2004 16:59:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApE11-0005Yc-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:59:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApE03-0005Th-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:59:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApDz6-0005Hm-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 16:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDz7-0002sx-6B; Fri, 06 Feb 2004 16:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDyL-0002rB-Nm for lemonade@optimus.ietf.org; Fri, 06 Feb 2004 16:57: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 QAA23686 for ; Fri, 6 Feb 2004 16:57:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDyJ-000551-00 for lemonade@ietf.org; Fri, 06 Feb 2004 16:57:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDvy-0004Zs-00 for lemonade@ietf.org; Fri, 06 Feb 2004 16:54:47 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1ApDuf-0004Mf-00 for lemonade@ietf.org; Fri, 06 Feb 2004 16:53:25 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i16LrLX9027984 for ; Fri, 6 Feb 2004 13:53:21 -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.11+UW04.02) with ESMTP id i16LrLQa021456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Feb 2004 13:53:21 -0800 Date: Fri, 6 Feb 2004 13:53:21 -0800 (Pacific Standard Time) From: Mark Crispin To: lemonade@ietf.org In-Reply-To: <200402062042.PAA15156@ietf.org> Message-ID: References: <200402062042.PAA15156@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [lemonade] draft-crispin-lemonade-pull-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.0 required=5.0 tests=none autolearn=no version=2.60 The -01 version (real, this time) of the Lemonade Pull document has a new chapter dealing with the "fcc problem" as it relates to the various submission strategies. This is important, because it turns out that in real life the "sent messages" copy of a message is not necessarily the same as what it actually sent. -- 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 Feb 6 19:15:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01050 for ; Fri, 6 Feb 2004 19:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApG7i-0001Xh-S1 for lemonade-archive@odin.ietf.org; Fri, 06 Feb 2004 19:15:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i170F2ES005922 for lemonade-archive@odin.ietf.org; Fri, 6 Feb 2004 19:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApG7i-0001XC-7m for lemonade-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 19:15: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 TAA01032 for ; Fri, 6 Feb 2004 19:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApG7g-0006qa-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 19:15:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApG6i-0006nK-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 19:14:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApG5j-0006is-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 19: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 1ApG5j-0001SG-0I; Fri, 06 Feb 2004 19:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApG4r-0001Rf-Ej for lemonade@optimus.ietf.org; Fri, 06 Feb 2004 19:12:05 -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 TAA01007 for ; Fri, 6 Feb 2004 19:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApG4p-0006hd-00 for lemonade@ietf.org; Fri, 06 Feb 2004 19:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApG3u-0006es-00 for lemonade@ietf.org; Fri, 06 Feb 2004 19:11:06 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx with esmtp (Exim 4.12) id 1ApG3H-0006Zk-00 for lemonade@ietf.org; Fri, 06 Feb 2004 19:10:27 -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 i1709rTi084713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Feb 2004 17:09:54 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 06 Feb 2004 15:58:22 -0800 From: Lyndon Nerenberg To: "IETF LEMONADE (E-mail)" Subject: Re: [lemonade] FW: 59th IETF Agenda - As of 2/4/2004 Message-ID: <2147483647.1076083102@localhost> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB242B6@zoe.office.snowshore.com> References: <4A3384433CE2AB46A63468CB207E209DB242B6@zoe.office.snowshore .com> 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 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 --On 2004-2-6 2:57 PM -0500 Eric Burger wrote: > Note that we DO have a multicast session -- Mark et. al should be > able to tap in and participate. 9am 3/3 Korea is 4pm 3/2 in > California. Is there anyone on the list who can provide me with a tunnel feed? Multicast does not exist in Canada. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 6 21:14:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04575 for ; Fri, 6 Feb 2004 21:14:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHz0-00015D-FJ for lemonade-archive@odin.ietf.org; Fri, 06 Feb 2004 21:14:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i172EArT004157 for lemonade-archive@odin.ietf.org; Fri, 6 Feb 2004 21:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHz0-00014y-9g for lemonade-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 21:14: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 VAA04568 for ; Fri, 6 Feb 2004 21:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHyx-0006I9-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 21:14:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHy0-0006FO-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 21:13:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApHxs-0006CT-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 21:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHxt-00012a-5g; Fri, 06 Feb 2004 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHx6-00011r-9T for lemonade@optimus.ietf.org; Fri, 06 Feb 2004 21:12: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 VAA04556 for ; Fri, 6 Feb 2004 21:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHx3-0006Bs-00 for lemonade@ietf.org; Fri, 06 Feb 2004 21:12:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHwC-00068w-00 for lemonade@ietf.org; Fri, 06 Feb 2004 21:11:16 -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 1ApHvV-00062K-00 for lemonade@ietf.org; Fri, 06 Feb 2004 21:10:33 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4) for ; Fri, 6 Feb 2004 20:10:03 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Fri, 6 Feb 2004 20:10:01 -0600 To: lemonade@ietf.org From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [lemonade] Embedded URI variant 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 The Embedded URI variant described in draft-crispin-lemonade-pull-01.txt is not a pull-specific mechanism. It can also be done using push (e.g., as part of the SUBMIT command). Personally, I find Embedded URI troublesome, for either push or pull, since it requires MIME parsing on the part of the assembler, again upping the ante on the task at hand. But either way, I think it should be either removed from the pull document, or added to the push document, if we want a reasonable comparison of the mechanisms. Again, speaking personally, I would prefer it simply be removed from the pull document. 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 Feb 6 21:50:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05170 for ; Fri, 6 Feb 2004 21:50: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 1ApIXv-0003FG-Eu for lemonade-archive@odin.ietf.org; Fri, 06 Feb 2004 21:50:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i172oFYv012468 for lemonade-archive@odin.ietf.org; Fri, 6 Feb 2004 21:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApIXv-0003F1-AU for lemonade-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 21:50: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 VAA05167 for ; Fri, 6 Feb 2004 21:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApIXs-0000Oa-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 21:50:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApIWv-0000LI-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 21:49:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApIWh-0000Hp-00 for lemonade-web-archive@ietf.org; Fri, 06 Feb 2004 21:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApIWj-0002wz-2f; Fri, 06 Feb 2004 21:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApIVs-0002uU-Oq for lemonade@optimus.ietf.org; Fri, 06 Feb 2004 21:48: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 VAA05129 for ; Fri, 6 Feb 2004 21:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApIVp-0000GL-00 for lemonade@ietf.org; Fri, 06 Feb 2004 21:48:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApIUr-0000D0-00 for lemonade@ietf.org; Fri, 06 Feb 2004 21:47:06 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx with esmtp (Exim 4.12) id 1ApITy-00009h-00 for lemonade@ietf.org; Fri, 06 Feb 2004 21:46:10 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i172k6hU007085; Fri, 6 Feb 2004 18:46:06 -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.11+UW04.02) with ESMTP id i172k6sa021978 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2004 18:46:06 -0800 Date: Fri, 6 Feb 2004 18:46:06 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick cc: lemonade@ietf.org Subject: Re: [lemonade] Embedded URI variant In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 6 Feb 2004, Pete Resnick wrote: > The Embedded URI variant described in draft-crispin-lemonade-pull-01.txt is not > a pull-specific mechanism. It can also be done using push (e.g., as part of the > SUBMIT command). I disagree. The URIs have to be pulled before they could be pushed. There is no way to push an external URI. > Personally, I find Embedded URI troublesome, for either push > or pull, since it requires MIME parsing on the part of the assembler, again > upping the ante on the task at hand. Fortunately, IMAP has an excellent MIME parser so this is not a problem. One obvious way of addressing the problem is to have the URLFETCH command do the necessary processing. Conceivably, URLFETCH could even do some limited on-the-fly assembly. > But either way, I think it should be > either removed from the pull document, or added to the push document, if we > want a reasonable comparison of the mechanisms. Embedded URI is something that particularly highlights the superiority of pull. Requesting that Embedded URI be removed to make a "reasonable comparison" is tantamount to saying that pull should be handicapped. If you wish to propose a push-type mechanism for Embedded URI, please be my guest. I am starting to believe that, due to the draft and fcc problems, embedded URI is a necessary part of any solution; either alone or in conjunction with CATENATE. Several interesting possibilities open up with a form of CATENATE that is savvy about Embedded URIs. -- 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 Sat Feb 7 11:42:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08355 for ; Sat, 7 Feb 2004 11:42: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 1ApVWY-0007Zk-93 for lemonade-archive@odin.ietf.org; Sat, 07 Feb 2004 11:41:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17Gfg5w029116 for lemonade-archive@odin.ietf.org; Sat, 7 Feb 2004 11:41:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVWY-0007ZX-3m for lemonade-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 11:41:42 -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 LAA08349 for ; Sat, 7 Feb 2004 11:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVWW-0002S5-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 11:41:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVVc-0002No-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 11:40:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApVVA-0002Ix-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 11:40:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVUx-0007Qn-Cy; Sat, 07 Feb 2004 11: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 1ApVUe-0007PO-Oq for lemonade@optimus.ietf.org; Sat, 07 Feb 2004 11:39:44 -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 LAA08288 for ; Sat, 7 Feb 2004 11:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVUd-0002IK-00 for lemonade@ietf.org; Sat, 07 Feb 2004 11:39:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVTp-0002E5-00 for lemonade@ietf.org; Sat, 07 Feb 2004 11:38:54 -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 1ApVTR-00028s-00 for lemonade@ietf.org; Sat, 07 Feb 2004 11:38:29 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4); Sat, 7 Feb 2004 10:37:58 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Sat, 7 Feb 2004 10:37:56 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] Embedded URI variant Cc: lemonade@ietf.org 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/6/04 at 6:46 PM -0800, Mark Crispin wrote: >On Fri, 6 Feb 2004, Pete Resnick wrote: >>The Embedded URI variant described in >>draft-crispin-lemonade-pull-01.txt is not a pull-specific >>mechanism. It can also be done using push (e.g., as part of the >>SUBMIT command). > >I disagree. The URIs have to be pulled before they could be pushed. >There is no way to push an external URI. The distinction between "push" and "pull", as far as we have been using those terms in LEMONADE, is whether the mail message in the user's IMAP store that is to be submitted is pushed from the IMAP store or pulled from the IMAP store. Though I don't disagree that external content (i.e., from outside of the user's IMAP store) will always be pulled, our conversation in this group to date hasn't made the distinction on that level. (See earlier suggestions that the "push" mechanism use a template message with references to other content.) We're trying to figure out whether all of this should be implemented by the client interacting with the IMAP server alone or by interacting with the submission server. >>Personally, I find Embedded URI troublesome, for either push or >>pull, since it requires MIME parsing on the part of the assembler, >>again upping the ante on the task at hand. > >Fortunately, IMAP has an excellent MIME parser so this is not a >problem. One obvious way of addressing the problem is to have the >URLFETCH command do the necessary processing. Conceivably, URLFETCH >could even do some limited on-the-fly assembly. Again, the same can be said for the IMAP SUBMIT command in the push proposal. I don't think it's impossible, but this raises the ante. >>But either way, I think it should be either removed from the pull >>document, or added to the push document, if we want a reasonable >>comparison of the mechanisms. > >Embedded URI is something that particularly highlights the >superiority of pull. I disagree. Embedded URI is something that can be done from either the IMAP server or the submission server. Therefore it makes no distinction at all between using one of those mechanisms. In fact, your draft says that the advantages of embedded URI are: - No assembly burden for client - Draft friendly (if you want unassembled drafts) If you want to describe a superiority of doing embedded URI from the SUBMIT server instead of doing it from the IMAP server, then you'd be making a reasonable comparison. For the record, I didn't think that any of the advantage/disadvantage discussion should be going on in this document in the first place. I had thought the intention of this document was to document usage, just as the push document did, and that Randy's draft-ietf-lemonade-submit-* was supposed to document advantages and disadvantages of each strategy. (And on that score: This document does not give a detailed description of embedded URI. It describes possible mechanisms, like "some easily-identifiable form, perhaps as an added parameter to the [MIME] Content-Type header", but doesn't actually make a proposal. If we are actually going to be comparing mechanisms, I'd like to see the mechanism.) >Requesting that Embedded URI be removed to make a "reasonable >comparison" is tantamount to saying that pull should be handicapped. Nonsense. All that I asked for was for the comparison to be made between the two strategies being discussed or not made at all. The present text attributes advantages to one strategy without noting that they apply equally well to the other strategy. >If you wish to propose a push-type mechanism for Embedded URI, >please be my guest. I'd first like to see the mechanism that you are proposing for the pull document and see if it can be re-used for the SUBMIT command. We're supposed to be comparing apples to apples here, at least so far as we can. >I am starting to believe that, due to the draft and fcc problems, >embedded URI is a necessary part of any solution; either alone or in >conjunction with CATENATE. Several interesting possibilities open >up with a form of CATENATE that is savvy about Embedded URIs. Can you detail what you mean by "a form of CATENATE that is savvy about Embedded URIs"? What would end up on the server after you use such a CATENATE? 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 Feb 7 14:03:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11444 for ; Sat, 7 Feb 2004 14:03:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApXj9-0002N9-KH for lemonade-archive@odin.ietf.org; Sat, 07 Feb 2004 14:02:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17J2pe0009113 for lemonade-archive@odin.ietf.org; Sat, 7 Feb 2004 14:02:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApXj9-0002Mu-De for lemonade-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 14:02: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 OAA11441 for ; Sat, 7 Feb 2004 14:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApXj7-00052n-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 14:02:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApXi0-0004za-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 14:01:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApXhN-0004wE-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 14:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApXhN-0002HO-N8; Sat, 07 Feb 2004 14:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApXh3-0002DY-4N for lemonade@optimus.ietf.org; Sat, 07 Feb 2004 14:00: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 OAA11423 for ; Sat, 7 Feb 2004 14:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApXh0-0004vu-00 for lemonade@ietf.org; Sat, 07 Feb 2004 14:00:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApXg3-0004sX-00 for lemonade@ietf.org; Sat, 07 Feb 2004 13:59:40 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx with esmtp (Exim 4.12) id 1ApXfa-0004p8-00 for lemonade@ietf.org; Sat, 07 Feb 2004 13:59:10 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i17Ix2Fp026086; Sat, 7 Feb 2004 10:59:02 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i17Ix2EP005892; Sat, 7 Feb 2004 10:59:02 -0800 Date: Sat, 7 Feb 2004 10:59:02 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: lemonade@ietf.org Subject: Re: [lemonade] Embedded URI variant In-Reply-To: Message-ID: References: MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Sat, 7 Feb 2004, Pete Resnick wrote: > The distinction between "push" and "pull", as far as we have been using those > terms in LEMONADE, is whether the mail message in the user's IMAP store that > is to be submitted is pushed from the IMAP store or pulled from the IMAP > store. There is more to it than that. There is also the question of external content, and whether it is pushed to the MSA or does the MSA pull it. This is a critical question. It has enormous implications for existing service facilities and their overall architecture. Push has the effect of declaring a great many existing facilities "broken", and of closing a great many doors in how a service facility is designed. > Though I don't disagree that external content (i.e., from outside of the > user's IMAP store) will always be pulled, our conversation in this group to > date hasn't made the distinction on that level. Which is probably why there is still a discussion on the push/pull question at all. Once you consider these details, it becomes clear that push is an unmitigated diaster. > (See earlier suggestions that the "push" mechanism use a template message > with references to other content.) Which is a concession by you that some form of Embedded URI is necessary. In fact, it was those suggestions of yours that made me realize that fact. > We're trying to figure out whether all of this should be implemented by the > client interacting with the IMAP server alone or by interacting with the > submission server. It is far more complicated than that. It is a question of roles: of the client, of the IMAP server, and of the MSA. >> Fortunately, IMAP has an excellent MIME parser so this is not a problem. >> One obvious way of addressing the problem is to have the URLFETCH command >> do the necessary processing. Conceivably, URLFETCH could even do some >> limited on-the-fly assembly. > Again, the same can be said for the IMAP SUBMIT command in the push proposal. > I don't think it's impossible, but this raises the ante. Wrong, unless you wish to mandate that the IMAP server (and ultimately, every other protocol which has a submission mechanism) have an embedded client for other protocols. Otherwise, SUBMIT is useless for attachments. I know what you're going to say: we're just putting in a CATENATE and SUBMIT command into IMAP to make it easy for cell phones to forward messages, and we don't care about attachments. But think about how this looks to the larger community: a great deal of existing IMAP server infrastructure will be broken, and a large additional mandate added to IMAP, to put in a SUBMIT command that is useless for attachments! This is why you are getting such strong push-back against push from the IMAP server community. >> Embedded URI is something that particularly highlights the superiority of >> pull. > I disagree. Embedded URI is something that can be done from either the IMAP > server or the submission server. You miss the point. In order to do Embedded URI the agent which resolves these URIs has to have clients which are capable of resolving those various URIs. At a minimum, the necessary protocols are IMAP, NNTP, POP3, HTTP, and FTP. In push, this must be done in *every* protocol that has submit. In pull, this is done in only *one* protocol. This is why Embedded URI renders pull superior. > Therefore it makes no distinction at all > between using one of those mechanisms. The distinction comes out when submission is needed outside of IMAP. Either all that work has to be done all over again, or it's already done. > In fact, your draft says that the > advantages of embedded URI are: > - No assembly burden for client > - Draft friendly (if you want unassembled drafts) These are the advantages of Embedded URI from the client standpoint. In other respects, Embedded URI is a requirement as opposed to an advantage. For example, Embedded URI is the only way to address the requirement that an fcc not be the same as the message received by the recipient. This is an absolute requirement for people who send attachments. > For the record, I didn't think that any of the advantage/disadvantage > discussion should be going on in this document in the first place. I disagree. People are easily overwhelmed by descriptions of mechanisms that lack a statement as to *why*. In the case of pull, there are multiple directions with tradeoffs, and those tradeoffs have to be considered. > (And on that score: This document does not give a detailed description of > embedded URI. It describes possible mechanisms, like "some > easily-identifiable form, perhaps as an added parameter to the [MIME] > Content-Type header", but doesn't actually make a proposal. If we are > actually going to be comparing mechanisms, I'd like to see the mechanism.) Ahem. You've done the same thing. When it was pointed out that CATENATE was draft-unfriendly, you handwaved that something like Embedded URI could be done to solve that. But you offered no specifics. The basic notion of Embedded URI is clear: it has to be something comes out as the result of an IMAP MIME parse, and preferably from existing servers. This suggests a new well-known parameter on Content-Type, which will show up on any BODYSTRUCTURE fetch. The means by which it may interact with URLFETCH and CATENATE needs fleshing out, but there are some obvious directions. If the Lemonade WG would like me to present a detailed proposal for Embedded URI, I will take on producing one. However, I am *NOT* going to go to all that work if it is going to be shouted down with a "we won't even consider it." > The present text > attributes advantages to one strategy without noting that they apply equally > well to the other strategy. As I have shown, that is incorrect. From the introduction, we have: Pull has the distinct advantage of maintaining one submission protocol, and thus avoids the risk of having multiple parallel and possible divergent mechanisms for submission. Furthermore, by keeping the details of message submission in the SUBMIT server, the pull strategies are prepared to work with other message retrieval protocols such as POP, NNTP, or whatever else may be designed in the future. With that in mind, and *in that context*, push is completely disadvantaged compared to pull on the issues raised later in the document. > Can you detail what you mean by "a form of CATENATE that is savvy about > Embedded URIs"? What would end up on the server after you use such a > CATENATE? It all depends upon what is being CATENATEd. The first question that has to be answered is if, given Embedded URI, does CATENATE's syntax need to be anything other than a form of APPEND? If CATENATE were to become a type of APPEND that resolves Embedded URIs, then it is no longer really a CATEATE; it is just an assembly command. However, the draft and fcc problems require that it distinguish between an Embedded URI that needs to be resolved now, vs. one that needs to be resolved later. The easy answer is to leave CATENATE as-is, and have it ignore any Embedded URIs. The problem is that as the client moves from drafts to fcc to submission, the desired form of the message will change. This shifts the burden on the client to change the Embedded URIs to CATENATE arguments, which is precisely what we want to avoid. A way around this may be to have the Embedded URIs tagged by when they should be resolved (draft, fcc, submit, recipient), and then to have this resolution type as an argument to the upload/assembly command (CATENATE or fancy APPEND or whatever). This leaves open the question whether CATENATE should continue to take the arguments that it does, or if everything should be Embedded URIs. Note that I listed four resolution points. Those names are actually a minimum level of resolution, as opposed to a resolution level: . draft is "always resolve" . fcc is "don't resolve if saving a draft" . submit is "don't resolve if saving a draft or writing an fcc" . recipient is "don't resolve if saving a draft, writing an fcc, or submitting the message." Perhaps we won't use recipient, because message/external-body arguably fufills that role. -- 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 Sat Feb 7 16:53:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15110 for ; Sat, 7 Feb 2004 16:53: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 1ApaNi-0004lO-7n for lemonade-archive@odin.ietf.org; Sat, 07 Feb 2004 16:52:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17Lqs7c018306 for lemonade-archive@odin.ietf.org; Sat, 7 Feb 2004 16:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApaNi-0004lB-2t for lemonade-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 16: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 QAA15107 for ; Sat, 7 Feb 2004 16:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApaNf-0000wM-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 16:52:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApaMi-0000rd-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 16:51:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApaLy-0000ms-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 16:51:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApaLt-0004eg-IT; Sat, 07 Feb 2004 16:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApaLg-0004dz-Lz for lemonade@optimus.ietf.org; Sat, 07 Feb 2004 16:50: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 QAA15068 for ; Sat, 7 Feb 2004 16:50:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApaLe-0000ls-00 for lemonade@ietf.org; Sat, 07 Feb 2004 16:50:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApaKl-0000hc-00 for lemonade@ietf.org; Sat, 07 Feb 2004 16:49: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 1ApaKL-0000d2-00 for lemonade@ietf.org; Sat, 07 Feb 2004 16:49:26 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4); Sat, 7 Feb 2004 15:48:55 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Sat, 7 Feb 2004 15:48:53 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] Embedded URI variant Cc: lemonade@ietf.org 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/7/04 at 10:59 AM -0800, Mark Crispin wrote: >On Sat, 7 Feb 2004, Pete Resnick wrote: >>The distinction between "push" and "pull", as far as we have been >>using those terms in LEMONADE, is whether the mail message in the >>user's IMAP store that is to be submitted is pushed from the IMAP >>store or pulled from the IMAP store. > >There is more to it than that. There is also the question of >external content, and whether it is pushed to the MSA or does the >MSA pull it. There is *not* more to "how the terms push and pull are being used" than that. Of course, there is an open issue about *whether* to do something about external content, but we haven't even gotten to the question of whether external content is to be pushed or pulled since we haven't answered the question of whether we're going to do address in the first place. >This is a critical question. It has enormous implications for >existing service facilities and their overall architecture. Push >has the effect of declaring a great many existing facilities >"broken", and of closing a great many doors in how a service >facility is designed. Which existing facilities are you talking about, and which of those would be "declared 'broken'" by a push architecture? >>Though I don't disagree that external content (i.e., from outside >>of the user's IMAP store) will always be pulled, our conversation >>in this group to date hasn't made the distinction on that level. > >Which is probably why there is still a discussion on the push/pull >question at all. Once you consider these details, it becomes clear >that push is an unmitigated diaster. It is certainly not clear to me that push is anything near a disaster if we don't address the external content issue, nor is it clear to me why it would be if the external content was pushed from IMAP to MSA. Care to explain instead of just labeling things "unmitigated disasters"? >>(See earlier suggestions that the "push" mechanism use a template >>message with references to other content.) > >Which is a concession by you that some form of Embedded URI is necessary. No, if you read my response to Cyrus (who is one of the people who suggested it) on 21 Oct 2003, you'll see that I actually opposed doing embedded URI (what was being called "expand") and did not "concede" that it was "necessary". I don't think it is. > In fact, it was those suggestions of yours that made me realize that fact. Perhaps you mistook my discussion of some sort of MIME-based markup of included parts (so that a client wouldn't have to re-download parts included in a draft) as something like embedded URI? >I know what you're going to say: we're just putting in a CATENATE >and SUBMIT command into IMAP to make it easy for cell phones to >forward messages, and we don't care about attachments. It's not that we don't care about attachments. It's that: 1. Attachments are too big a piece of work to address in LEMONADE. 2. The vast majority of attachments are either local storage (which are easier to send by current mechanisms) or publicly accessible (which are easier to send by reference), making assembly of other attachments for sending by e-mail of marginal use at best. >But think about how this looks to the larger community: a great deal >of existing IMAP server infrastructure will be broken What IMAP server infrastructure will be broken, and in what way? I don't understand what you mean. >and a large additional mandate added to IMAP to put in a SUBMIT >command that is useless for attachments! No question, it is an additional mandate to IMAP. But again, it is only useless for attachments which are not local to the client or publicly accessible by the recipient, which constitutes a small gain as far as I can tell. >This is why you are getting such strong push-back against push from >the IMAP server community. Again, stop characterizing others. We are certainly getting strong push-back from you. Others can judge for themselves the push-back we've seen from others on this list. >In order to do Embedded URI the agent which resolves these URIs has >to have clients which are capable of resolving those various URIs. >At a minimum, the necessary protocols are IMAP, NNTP, POP3, HTTP, >and FTP. I have seen no call (other than from you) for embedded URIs to NNTP or POP3. I don't see either one of them being put to serious use. IMAP is an issue if you use embedded URI for the inclusion of IMAP parts (required in pull, not so in push). That leaves FTP and HTTP, of which again I think the majority of uses are publicly accessible. >In push, this must be done in *every* protocol that has submit. Which other protocols other than IMAP are you thinking of? >In pull, this is done in only *one* protocol. > >This is why Embedded URI renders pull superior. It is superior because it only has to be done in one place as opposed to some-as-yet-unnamed-number-of other places? OK, I'll take that for what it's worth. >In other respects, Embedded URI is a requirement as opposed to an >advantage. For example, Embedded URI is the only way to address the >requirement that an fcc not be the same as the message received by >the recipient. This is an absolute requirement for people who send >attachments. I'm so glad you're knowledge extends to all people who send attachments. So is this an absolute requirement for people who send attachments which are in their IMAP store? Is the reason *only* because they are charged double in storage if a copy of the attachment is made? Perhaps this is more of an implementation requirement than a requirement of embedded URI. >People are easily overwhelmed by descriptions of mechanisms that >lack a statement as to *why*. In the case of pull, there are >multiple directions with tradeoffs, and those tradeoffs have to be >considered. Are you saying that there isn't sufficient discussion of those tradeoffs in draft-ietf-lemonade-submit-*? If so, how does that mean that such additional discussion doesn't belong in that document? >>This document does not give a detailed description of embedded URI. >>It describes possible mechanisms, like "some easily-identifiable >>form, perhaps as an added parameter to the [MIME] Content-Type >>header", but doesn't actually make a proposal. If we are actually >>going to be comparing mechanisms, I'd like to see the mechanism. > >Ahem. You've done the same thing. When it was pointed out that >CATENATE was draft-unfriendly, you handwaved that something like >Embedded URI could be done to solve that. But you offered no >specifics. First of all, use of CATENATE does not require embedded URI to be useful. Surely draft-friendliness would be nice, and if it becomes a requirement of the WG, I will surely start discussing a specific mechanism. However, "BURL/Embedded URI Variant" is one of the called out mechanisms in your pull document. In that context, I think you need to flesh out the details. Second of all, in the case of CATENATE, the markup described would be done *by the client* during the CATENATE *for the later use of the client*. It is not part of the protocol itself, but rather implementation advice for the client so that it doesn't have to re-download included content. I would be glad to contribute to the discussion of some implementation advice to put into the SUBMIT draft to make it more draft-friendly and will try to before the I-D deadline. In any event, I think it's a far cry from "the same thing". >The basic notion of Embedded URI is clear: it has to be something >comes out as the result of an IMAP MIME parse, and preferably from >existing servers. This suggests a new well-known parameter on >Content-Type, which will show up on any BODYSTRUCTURE fetch. The >means by which it may interact with URLFETCH and CATENATE needs >fleshing out, but there are some obvious directions. I agree. >If the Lemonade WG would like me to present a detailed proposal for >Embedded URI, I will take on producing one. However, I am *NOT* >going to go to all that work if it is going to be shouted down with >a "we won't even consider it." I don't know where you get the idea that "we won't even consider it"; that seems like another characterization, this time on the willingness of push proponents to compromise. I've certainly heard nothing of the sort. But whether we eventually take on pull or push, I think having a proposal for embedded URI would be useful: It will give us something more serious to consider, and it will give at least one mechanism which we might be able to use in the push proposal for markup of parts to make it more draft-friendly. >>The present text attributes advantages to one strategy without >>noting that they apply equally well to the other strategy. > >As I have shown, that is incorrect. No, not with regard to embedded URI (which, if you look at my message, is the strategy that I was referring to). As I already pointed out, the only advantages attributed to embedded URI in the document are those having to do with the client which are not pull-specific. >>Can you detail what you mean by "a form of CATENATE that is savvy >>about Embedded URIs"? What would end up on the server after you use >>such a CATENATE? > >It all depends upon what is being CATENATEd. > >The first question that has to be answered is if, given Embedded >URI, does CATENATE's syntax need to be anything other than a form of >APPEND? > >If CATENATE were to become a type of APPEND that resolves Embedded >URIs, then it is no longer really a CATEATE; it is just an assembly >command. Right. At that point, I wouldn't even call this CATENATE. It's just an "APPENDANDEXPAND" (or "fancy APPEND", as you say below) command. >However, the draft and fcc problems require that it distinguish >between an Embedded URI that needs to be resolved now, vs. one that >needs to be resolved later. Do you see draft and fcc essentially different beasts? What things would you expect to be different. >The easy answer is to leave CATENATE as-is, and have it ignore any >Embedded URIs. That's what I would do. >The problem is that as the client moves from drafts to fcc to >submission, the desired form of the message will change. This >shifts the burden on the client to change the Embedded URIs to >CATENATE arguments, which is precisely what we want to avoid. Agreed. >A way around this may be to have the Embedded URIs tagged by when >they should be resolved (draft, fcc, submit, recipient), and then to >have this resolution type as an argument to the upload/assembly >command (CATENATE or fancy APPEND or whatever). Why would you want to do this at upload/assembly time instead of at submit time (either by a parameter to the IMAP SUBMIT command or to the BURL command)? >This leaves open the question whether CATENATE should continue to >take the arguments that it does, or if everything should be Embedded >URIs. Again, that makes it a fancy APPEND, not a CATENATE command. >Note that I listed four resolution points. Those names are actually >a minimum level of resolution, as opposed to a resolution level: >. draft is "always resolve" >. fcc is "don't resolve if saving a draft" >. submit is "don't resolve if saving a draft or writing an fcc" >. recipient is "don't resolve if saving a draft, writing an fcc, or > submitting the message." > >Perhaps we won't use recipient, because message/external-body >arguably fufills that role. Indeed, is there any reason not to use message/external-body with a Content-Type parameter as the embedded URI mechansim? 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 Feb 7 21:50:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21899 for ; Sat, 7 Feb 2004 21:50:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apf19-00076K-UU for lemonade-archive@odin.ietf.org; Sat, 07 Feb 2004 21:49:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i182ntgN027292 for lemonade-archive@odin.ietf.org; Sat, 7 Feb 2004 21:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apf19-000766-MM for lemonade-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 21:49: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 VAA21875 for ; Sat, 7 Feb 2004 21:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apf16-0007jW-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 21:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apf0C-0007fp-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 21:48:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApezI-0007cK-00 for lemonade-web-archive@ietf.org; Sat, 07 Feb 2004 21:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApezI-0006yq-U0; Sat, 07 Feb 2004 21:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApezD-0006yc-1x for lemonade@optimus.ietf.org; Sat, 07 Feb 2004 21:47: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 VAA21859 for ; Sat, 7 Feb 2004 21:47:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApezA-0007bj-00 for lemonade@ietf.org; Sat, 07 Feb 2004 21:47:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApeyC-0007YL-00 for lemonade@ietf.org; Sat, 07 Feb 2004 21:46:53 -0500 Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx with esmtp (Exim 4.12) id 1ApexI-0007V8-00 for lemonade@ietf.org; Sat, 07 Feb 2004 21:45:56 -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 i182ju9h014175; Sat, 7 Feb 2004 18:45:56 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i182jtM0016624; Sat, 7 Feb 2004 18:45:56 -0800 Date: Sat, 7 Feb 2004 18:45:55 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: lemonade@ietf.org Subject: Re: [lemonade] Embedded URI variant In-Reply-To: Message-ID: References: MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Sat, 7 Feb 2004, Pete Resnick wrote: > There is *not* more to "how the terms push and pull are being used" than > that. If external content has a bearing on whether or not push or pull is selected, then it is very relevant to the discussion at hand. A discussion that excludes consideration of relevant and critical information (particularly at the behest of one side of the discussion) is unlikely to arrive at a correct conclusion. > Which existing facilities are you talking about, and which of those would be > "declared 'broken'" by a push architecture? There are large (5-6 digit user community) IMAP server facilities in production deployment today which have gone to great length to separate message retrieval from message submission, and which furthermore split the location of user data across multiple servers in the facility. Having gone to great effort to split the location of user data and to separate the functions of retrieval and submission, push represents a threat -- a *MAJOR* threat -- to these facilities. CATENATE can address split locations in push by allowing arbitrary URLs. That is, every IMAP server must have a built in IMAP, POP3, NNTP, HTTP, and FTP client. However, this does not address separation of function. Nor does it address the requirement that a draft be a different form than an fcc, and that an fcc in turn be a different form that the submitted message. Push's fatal failing is that it is simultaneously too simplistic, disallows what we are doing now, and mandates a *huge* burden upon every IMAP server. > It is certainly not clear to me that push is anything near a disaster if we > don't address the external content issue, nor is it clear to me why it would > be if the external content was pushed from IMAP to MSA. Care to explain > instead of just labeling things "unmitigated disasters"? Off the top of my head: Disaster 1: every IMAP server must have built in IMAP, POP3, NNTP, HTTP, and FTP clients. Disaster 2: every IMAP server must have built in submit client. Disaster 3: every future message access mechanism must repeat disasters 1 and 2. Disaster 4: server facilities which separated their IMAP data across multiple servers must put them back on a single server. Disaster 5: readonly IMAP servers must have writeable mailboxes for submit. Disaster 6: server facilties which separated IMAP from submission to different machines (and sometimes different networks) must put them back on a single server. Not all of these disasters happen at one. Some of the disasters are the effect of ameliorating the other disasters. But from the point of view of an IMAP server implementor, all of these disasters must be considered in the software. >>> (See earlier suggestions that the "push" mechanism use a template message >>> with references to other content.) >> Which is a concession by you that some form of Embedded URI is necessary. > No, if you read my response to Cyrus (who is one of the people who suggested > it) on 21 Oct 2003, you'll see that I actually opposed doing embedded URI > (what was being called "expand") and did not "concede" that it was > "necessary". I don't think it is. You are splitting hairs. Embedded URI is simply a form of "reference to other content." >> In fact, it was those suggestions of yours that made me realize that fact. > Perhaps you mistook my discussion of some sort of MIME-based markup of > included parts (so that a client wouldn't have to re-download parts included > in a draft) as something like embedded URI? Not at all. Instead, I took your handwave, and from it built something with substance and use. > 1. Attachments are too big a piece of work to address in LEMONADE. Whoa! I can just see this how this plays now: the Lemonade Working Group is removing attachments from something you can submit in email! > 2. The vast majority of attachments are either local storage (which are > easier to send by current mechanisms) or publicly accessible (which are > easier to send by reference) Wrong. I need to send attachments which are neither local storage nor publicly accessible all the time. I see no point to this work if it does not do something to make attachments less clanky. > What IMAP server infrastructure will be broken, and in what way? I don't > understand what you mean. If push is adopted, server facilities with tens of thousands of users will have to be re-architected and reconfigured. > it is only > useless for attachments which are not local to the client or publicly > accessible by the recipient, which constitutes a small gain as far as I can > tell. Are you saying that a fix to a problem that I deal with every day of my life is a "small gain"? >> This is why you are getting such strong push-back against push from the >> IMAP server community. > Again, stop characterizing others. We are certainly getting strong push-back > from you. Others can judge for themselves the push-back we've seen from > others on this list. I count at least three other IMAP server implementors who have also pushed back. > I have seen no call (other than from you) for embedded URIs to NNTP or POP3. > I don't see either one of them being put to serious use. Do you seriously mean to say that you believe that nobody forwards mail from NNTP? I respectfully suggest that you are very much out of the loop if you really believe that. > That leaves FTP and HTTP, of which again I think the majority > of uses are publicly accessible. That's mainly because FTP is insecure. We really need SCP as one of the mechanisms. >> In push, this must be done in *every* protocol that has submit. > Which other protocols other than IMAP are you thinking of? POP3. NNTP. Any future access protocol -- surely nobody thinks that IMAP will be the last word in access protocols! > I'm so glad you're knowledge extends to all people who send attachments. So > is this an absolute requirement for people who send attachments which are in > their IMAP store? Yes, I have very extensive knowledge on the question of not including attachments in the fcc. Our first version didn't have that capability. We had to add it pretty quickly. > Is the reason *only* because they are charged double in > storage if a copy of the attachment is made? I doubt that this is the only reason, since it isn't my reason. But it probably is a reason for many people. > Are you saying that there isn't sufficient discussion of those tradeoffs in > draft-ietf-lemonade-submit-*? If so, how does that mean that such additional > discussion doesn't belong in that document? Yes, and some of the tradeoffs involve tradeoffs between pull variants which the submit document didn't consider. > First of all, use of CATENATE does not require embedded URI to be useful. > Surely draft-friendliness would be nice, and if it becomes a requirement of > the WG, I will surely start discussing a specific mechanism. It "would be nice" to be usable with drafts? It "would be nice" to allow fccs to omit attachments? I don't see those as "nice". I see those as absolute requirements. > However, > "BURL/Embedded URI Variant" is one of the called out mechanisms in your pull > document. In that context, I think you need to flesh out the details. It would be much easier for me to flesh out Embedded URI than for you to flesh out your "template messages with references to external content", or how CATENATE can be made other than draft-hostile and separate-form-fcc hostile. What needs to be determined first is if there is enough WG interest to see any of this fleshed out. > Second of all, in the case of CATENATE, the markup described would be done > *by the client* during the CATENATE *for the later use of the client*. So, now the client must do all the parsing? Wasn't the whole idea of this exercise to make things easier for small clients? > I don't know where you get the idea that "we won't even consider it"; that > seems like another characterization, this time on the willingness of push > proponents to compromise. I've certainly heard nothing of the sort. In the spirit of compromise, CATENATE in some form is in the pull proposal. Pull acknowledges a need to do some level of assembly in IMAP. There does not seem to be a corresponding spirit of compromise within push. If there is, it has been so muted as to be completely inaudible to me. > Do you see draft and fcc essentially different beasts? What things would you > expect to be different. Yes, they are different. Drafts will almost always have pointers to external content rather than include the content itself. The idea is to enable fast downloads of drafts. Fccs will assemble some external content. It's likely that fccs will include forwarded messages and/or replyed-to text. It's also likely that fccs will exclude some, if not all, attachments. Submissions will assembly most external content, excepting only that content that the recipient is supposed to fetch himself. >> A way around this may be to have the Embedded URIs tagged by when they >> should be resolved (draft, fcc, submit, recipient), and then to have this >> resolution type as an argument to the upload/assembly command (CATENATE or >> fancy APPEND or whatever). > Why would you want to do this at upload/assembly time instead of at submit > time (either by a parameter to the IMAP SUBMIT command or to the BURL > command)? That begs the question of what value is there to the CATENATE command. > Indeed, is there any reason not to use message/external-body with a > Content-Type parameter as the embedded URI mechansim? As I recall, there were deficiencies identified in message/external-body which make it unsuitable for an embedded URI mechanism. Chris would remember the details better than I would. -- 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 Feb 9 17:31:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23931 for ; Mon, 9 Feb 2004 17:31: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 1AqJva-0001u6-DM for lemonade-archive@odin.ietf.org; Mon, 09 Feb 2004 17:30:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MUsSl007317 for lemonade-archive@odin.ietf.org; Mon, 9 Feb 2004 17:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJva-0001tv-5j for lemonade-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:30: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 RAA23869 for ; Mon, 9 Feb 2004 17:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJvX-0000Xa-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 17:30:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJug-0000OI-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 17:29:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJtn-0000El-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 17:29:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqJtn-000263-Ph for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 17:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJtk-0001oY-Gr; Mon, 09 Feb 2004 17:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJt9-0001kX-Qv for lemonade@optimus.ietf.org; Mon, 09 Feb 2004 17:28: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 RAA23657 for ; Mon, 9 Feb 2004 17:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJt7-00009u-00 for lemonade@ietf.org; Mon, 09 Feb 2004 17:28:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJsD-00000x-00 for lemonade@ietf.org; Mon, 09 Feb 2004 17:27:27 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AqJr4-0007We-00 for lemonade@ietf.org; Mon, 09 Feb 2004 17:26:14 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i19MQ6vf027691; Mon, 9 Feb 2004 14:26:06 -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 i19MQ3tR003307; Mon, 9 Feb 2004 14:26:03 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 9 Feb 2004 14:26:03 -0800 To: Mark Crispin , Pete Resnick From: Ted Hardie Subject: Re: [lemonade] Embedded URI variant Cc: lemonade@ietf.org 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Setting fire to strawmen may produce heat, but it won't give us much light. I've made some comments below, but I encourage folks who plan to contribute to the evaluation of the push vs. pull documents to read the push and pull documents rather than relying on this discussion. The smoke is getting in my eyes, personally, and I read them before this started. At 6:45 PM -0800 02/07/2004, Mark Crispin wrote: >On Sat, 7 Feb 2004, Pete Resnick wrote: >>There is *not* more to "how the terms push and pull are being used" >>than that. > >If external content has a bearing on whether or not push or pull is >selected, then it is very relevant to the discussion at hand. > >A discussion that excludes consideration of relevant and critical >information (particularly at the behest of one side of the >discussion) is unlikely to arrive at a correct conclusion. If you are arguing that the group must decide whether to support external attachments (not local to client, client's IMAP store, and not publicly available to the recipients) before deciding on push vs. pull, I suggest you ask the working group chairs to call for consensus on this point. My reading of this text from the charter: > 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. is that is is limited to attachments already on the server, and that going beyond that is well outside the charter. If we are going all the way to an external composition protocol, using arbitrary protocols to collect the pieces of the composed message, I personally believe neither SUBMIT nor IMAP is well suited to the task. To put it more strongly, I believe that the charter is clear, and that much of the concern Mark expresses here is around functionality the working group has no consensus to tackle. >>Which existing facilities are you talking about, and which of those >>would be "declared 'broken'" by a push architecture? > >There are large (5-6 digit user community) IMAP server facilities in >production deployment today which have gone to great length to >separate message retrieval from message submission, and which >furthermore split the location of user data across multiple servers >in the facility. > >Having gone to great effort to split the location of user data and >to separate the functions of retrieval and submission, push >represents a threat -- a *MAJOR* threat -- to these facilities. I find it interesting that you see this in terms of a threat to the facilities. Are you concerned about specific losses of functionality? Are you concerned about slow deployment because of costs? I can think of several ways to use PUSH at the protocol level and still have outbound queues on separate disk arrays, etc. If these folks find this to be a valuable protocol extension, they will no doubt do the same. If they don't, then presumably the use cases motivating this are not compelling for them, and they wouldn't support push or pull for forward without download. To go on to Mark's disasters: >Off the top of my head: > >Disaster 1: every IMAP server must have built in IMAP, POP3, NNTP, >HTTP, and FTP clients. This is not true. The chartered use does not create this requirement at all. > > >Disaster 2: every IMAP server must have built in submit client. Every IMAP server must be able to use the Submit facility, which is not quite the same. Explaining why this is a "disaster" and not a normal consequence of the engineering choice would help transform this from a flat statement of preference to useful input. >Disaster 3: every future message access mechanism must repeat >disasters 1 and 2. Not true. One isn't true, two isn't proved to be a disaster, and there is no requirement on other messaging systems to adopt this strategy. >Disaster 4: server facilities which separated their IMAP data across >multiple servers must put them back on a single server. Apparently presumes a specific implementation and assumes facts which have not been presented to this working group. There are lots of deployment scenarios where this would not be the case. >Disaster 5: readonly IMAP servers must have writeable mailboxes for submit. How did you come to the conclusion that read only IMAP servers would offer this facility? >Disaster 6: server facilties which separated IMAP from submission to >different machines (and sometimes different networks) must put them >back on a single server. Again, apparently presumes a specific implementation and assumes facts which have not been presented to the working group. >Not all of these disasters happen at one. Some of the disasters are >the effect of ameliorating the other disasters. But from the point >of view of an IMAP server implementor, all of these disasters must >be considered in the software. To say this gently, these "disasters" seem to arise out of a mistaken sense of the requirements and mainly to require a calm application of software engineering and deployment. No one is asking anyone to rip up server farms and replant; no one is asking that IMAP grow the kitchen garden in its sink. This is a protocol enhancement to support a common use case, and it will require work to implement and deploy whatever path is chosen. We need go forward with our decision understanding that reality and making the engineering choices it implies, but without a sense of panic or disaster at chimera and without a nimby view of change. Speaking personally, as ever, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 9 18:28:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29754 for ; Mon, 9 Feb 2004 18:28:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKoY-00035h-L5 for lemonade-archive@odin.ietf.org; Mon, 09 Feb 2004 18:27:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19NRg4c011876 for lemonade-archive@odin.ietf.org; Mon, 9 Feb 2004 18:27:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKoY-00035K-5E for lemonade-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 18:27:42 -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 SAA29612 for ; Mon, 9 Feb 2004 18:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKoV-00006N-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 18:27:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKn1-0007aQ-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 18:26:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqKlO-0007Gp-01 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 18:24:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqKZO-0002c6-LB for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 18:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKZM-0000Jr-Tp; Mon, 09 Feb 2004 18:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKYo-0008R9-4f for lemonade@optimus.ietf.org; Mon, 09 Feb 2004 18:11: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 SAA28149 for ; Mon, 9 Feb 2004 18:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKYl-00063n-00 for lemonade@ietf.org; Mon, 09 Feb 2004 18:11:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKXu-0005yw-00 for lemonade@ietf.org; Mon, 09 Feb 2004 18:10:31 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1AqKXD-0005sx-00 for lemonade@ietf.org; Mon, 09 Feb 2004 18:09:47 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i19N9kX9030607; Mon, 9 Feb 2004 15:09:46 -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.11+UW04.02) with ESMTP id i19N9ksa004317 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2004 15:09:46 -0800 Date: Mon, 9 Feb 2004 15:09:47 -0800 (Pacific Standard Time) From: Mark Crispin To: Ted Hardie cc: Pete Resnick , lemonade@ietf.org Subject: Re: [lemonade] Embedded URI variant In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 9 Feb 2004, Ted Hardie wrote: > If you are arguing that the group must decide whether to support external > attachments (not local to client, client's IMAP store, and not publicly > available to the recipients) before deciding on push vs. pull Now you're setting fire to a strawman. Nowhere did I say that the group "must decide whether to support external attachments before deciding on push vs. pull." It is, however, quite relevant to a discussion of push vs. pull that the current push proposal is hostile to external attachments, and that it is possible to build pull so that it is not hostile to external attachments. It is relevant to the discussion because the impact of standarding a solution to any problem often goes far beyond the problem space. This is particularly the case with harmful impact. > If we are going all the way to > an external composition protocol, using arbitrary protocols to collect > the pieces of the composed message, I personally believe neither SUBMIT > nor IMAP is well suited to the task. I do not disagree. I believe that push (CATENATE+SUBMIT) will be treated as a general purpose composition protocol; that the lack of support for attachments, drafts, and fccs will be amended by means of extensions; and that there is nothing that the Lemonade WG can do (or say) that would prevent such an outcome. I consider such an outcome to be extraordinarily harmful. It is one thing to appeal to the charter to limit the scope of functionality that a WG works on. It is quite another to appeal to the charter to close the WG's eyes to what may be done with its work. > I find it interesting that you see this in terms of a threat to the > facilities. > Are you concerned about specific losses of functionality? Are you > concerned about slow deployment because of costs? No, I am concerned about the fact that push violates the architecture of a deployed facility. I'm not talking about "separate disk arrays"; I'm talking about separate machines on separate networks. I'm talking about readonly IMAP servers which contain shared (group) mailboxes. It is impossible to CATENATE on these servers. Push insists that all mailboxes be resident upon a readwrite IMAP server. >> Disaster 1: every IMAP server must have built in IMAP, POP3, NNTP, HTTP, >> and FTP clients. > This is not true. The chartered use does not create this requirement at all. What surety do you offer that the Lemonade charter will remain a permanent restriction upon message submission? There is no surety. We have to consider what will happen to this post-Lemonade. >> Disaster 2: every IMAP server must have built in submit client. > Every IMAP server must be able to use the Submit facility, which is not > quite the same. Explaining why this is a "disaster" and not a normal > consequence of the engineering choice would help transform this from a > flat statement of preference to useful input. In order for an IMAP server to have a submit facility, the users of that IMAP server must have the ability to upload (via CATENATE) to that IMAP server. This declares our readonly group IMAP servers to be non-compliant. In order for an IMAP server to submit, the IMAP server must be in the path for submission. This declares our server architecture, in which IMAP servers are on a different network from the submit servers, to be non-compliant. In order for an IMAP user to submit, the credentials for message submission must be equivalent to the credentials for message access. This declares our userspace architecture, in which the two are independent credentials, to be non-compliant. >> Disaster 4: server facilities which separated their IMAP data across >> multiple servers must put them back on a single server. > Apparently presumes a specific implementation and assumes facts which > have not been presented to this working group. There are lots of > deployment scenarios where this would not be the case. By design, UW has multiple independent servers. We split user space and function space. My personal mail is not on the same server as the support inboxes that I track. Nor do authentication credentials for one necessarily coincide with credentials for the other. We do not have a single monolithic IMAP server which has access to all mailbox data which a user may choose to forward in a message. >> Disaster 5: readonly IMAP servers must have writeable mailboxes for submit. > How did you come to the conclusion that read only IMAP servers would offer > this facility? Of course they would not. That's the problem. How is this to work if the user forwards a message from a readonly IMAP server? I read a message from an IMAP server called support. The message went to the product support mailbox, but it turns out that the message really should be handled by user services and thus needs to be forwarded to them. The problem with push is, I can't CATENATE on "support" since "support" is a readonly server for me. I can CATENATE on the IMAP server called "mrc.imap", but "mrc.imap" doesn't have access to the messages on "support". This isn't a problem with pull. >> Disaster 6: server facilties which separated IMAP from submission to >> different machines (and sometimes different networks) must put them back on >> a single server. > Again, apparently presumes a specific implementation and assumes facts > which have not been presented to the working group. By design, UW has IMAP servers on different machines/subnets from submit servers, which in turn are different from incoming SMTP servers. Suddenly, Lemonade push decrees that we can't do that any more; the IMAP servers now much have a path to the submit servers, and submission now must use IMAP credentials instead of the separate submit credentials. This isn't a problem with pull. > To say this gently, these "disasters" seem to arise out of a mistaken > sense of the requirements and mainly to require a calm application of > software engineering and deployment. No one is asking anyone to rip up > server farms and replant; no one is asking that IMAP grow the kitchen > garden in its sink. Wrong! If Lemonade results in a declaration that certain server farms are incompatible with the standard that Lemonade has defined, then the management of those server farms will come under extreme pressure to comply with Lemonade. Once the bookstore starts selling new handhelds and cell phones with Lemonade technology, the purchasers will be very distraught to find that these will not work with our facilties, and they will scream bloody murder. For better or worse, Lemonade represents something that can not be ignored by existing server farms or IMAP server implementations. -- 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 Feb 9 19:46:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06678 for ; Mon, 9 Feb 2004 19:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM2A-0007Jh-1b for lemonade-archive@odin.ietf.org; Mon, 09 Feb 2004 19:45:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0joTD028124 for lemonade-archive@odin.ietf.org; Mon, 9 Feb 2004 19:45:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM29-0007JX-G4 for lemonade-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 19:45: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 TAA06587 for ; Mon, 9 Feb 2004 19:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqM27-0003AU-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 19:45:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqM0S-0002lk-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 19:44:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLyK-0002L2-02 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 19:41:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqLnv-0003ee-KJ for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 19:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLnp-0006da-7V; Mon, 09 Feb 2004 19: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 1AqLnN-0006ct-Lx for lemonade@optimus.ietf.org; Mon, 09 Feb 2004 19:30:33 -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 TAA05143 for ; Mon, 9 Feb 2004 19:30:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLnL-0000tv-00 for lemonade@ietf.org; Mon, 09 Feb 2004 19:30:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLma-0000l4-00 for lemonade@ietf.org; Mon, 09 Feb 2004 19:29:45 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AqLlT-0000Wd-00 for lemonade@ietf.org; Mon, 09 Feb 2004 19:28: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 i1A0SPnp015733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2004 16:28:26 -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 i1A0SNtR017216; Mon, 9 Feb 2004 16:28:23 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 9 Feb 2004 16:28:23 -0800 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] Embedded URI variant Cc: Pete Resnick , lemonade@ietf.org 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 3:09 PM -0800 02/09/2004, Mark Crispin wrote: >On Mon, 9 Feb 2004, Ted Hardie wrote: >>If you are arguing that the group must decide whether to support >>external attachments (not local to client, client's IMAP store, and >>not publicly available to the recipients) before deciding on push >>vs. pull > >Now you're setting fire to a strawman. > >Nowhere did I say that the group "must decide whether to support >external attachments before deciding on push vs. pull." > >It is, however, quite relevant to a discussion of push vs. pull that >the current push proposal is hostile to external attachments, and >that it is possible to build pull so that it is not hostile to >external attachments. "hostile to external attachments" is not the term I would use, you will no doubt be surprised to learn. Its scope is limited by design, and it is not intended to cover a complete all-uri-scheme inclusion mechanism. That's a feature, in my opinion. > > >I believe that push (CATENATE+SUBMIT) will be treated as a general >purpose composition protocol; that the lack of support for >attachments, drafts, and fccs will be amended by means of >extensions; and that there is nothing that the Lemonade WG can do >(or say) that would prevent such an outcome. And I disagree. One, with your consistent use of "lack of support for attachments" when the class of objects not included is very different from the common use of the term. Two, with your prediction that extensions will automatically expand the very useful scope of the initial proposal to some general purpose composition protocol. Three, with the implicit assumption that Pull would not be similarly twisted out of shape by later forces. > >It is one thing to appeal to the charter to limit the scope of >functionality that a WG works on. It is quite another to appeal to >the charter to close the WG's eyes to what may be done with its work. If you wish to expand the scope of work the group will work on, you should amend the charter. As it stands, you seem to be arguing that the group should build to meet the eventual development of a general purpose composition protocol, without arguing that it should actually build such a general purpose composition protocol. From my perspective, if it is building to meet that eventuality, the group would need to develop at least an initial architecture for the eventual protocol. I disagree, both with the supposition and the scope creep, but it does seem to be the outcome of your argument. And that alone looks like it needs a charter amendment to my eyes. This is not meant to torch another strawman, as we have enough alight as it stands. I simply mean that if this is the working group's vision of where this is going, it has to plan enough to get it right. >>I find it interesting that you see this in terms of a threat to the >>facilities. >>Are you concerned about specific losses of functionality? Are you >>concerned about slow deployment because of costs? > >No, I am concerned about the fact that push violates the >architecture of a deployed facility. I'm not talking about >"separate disk arrays"; I'm talking about separate machines on >separate networks. > >I'm talking about readonly IMAP servers which contain shared (group) >mailboxes. It is impossible to CATENATE on these servers. Push >insists that all mailboxes be resident upon a readwrite IMAP server. No, it does not. It says that if you are going to take advantage of forward without download, you need a readwrite IMAP server. That's a real engineering trade off, and it bears repeating. But that doesn't mean that you need to re-architect anything, as the current mechanism (download and upload to the appropriate server) is not destroyed by the introduction of this one. >>>Disaster 1: every IMAP server must have built in IMAP, POP3, NNTP, >>>HTTP, and FTP clients. >>This is not true. The chartered use does not create this requirement at all. > >What surety do you offer that the Lemonade charter will remain a >permanent restriction upon message submission? > >There is no surety. We have to consider what will happen to this >post-Lemonade. I can only say that as a member of this working group I would oppose it. Further, there is no surety that the IETF will not decide instead to deprecate this message submission mechanism or IMAP as a part of the mail handling infrastructure. After all, there is no surety in the future. As it stands, though, we have a task at hand. By imagining some future task that is much larger without any reason to believe it would be our work to do, we are hindering getting this work done at all. >>>Disaster 2: every IMAP server must have built in submit client. >>Every IMAP server must be able to use the Submit facility, which is >>not quite the same. Explaining why this is a "disaster" and not a >>normal consequence of the engineering choice would help transform >>this from a flat statement of preference to useful input. > >In order for an IMAP server to have a submit facility, the users of >that IMAP server must have the ability to upload (via CATENATE) to >that IMAP server. This declares our readonly group IMAP servers to >be non-compliant. No, it declares that they do not offer this facility in that configuration. > >In order for an IMAP user to submit, the credentials for message >submission must be equivalent to the credentials for message access. >This declares our userspace architecture, in which the two are >independent credentials, to be non-compliant. Again, it doesn't have to. It may have the affect that the users' credentials and the servers credentials' are taken together to mean that a submission should be accepted. That doesn't mean your existing credentials would work as they do now or are "non-compliant". >>>Disaster 4: server facilities which separated their IMAP data >>>across multiple servers must put them back on a single server. >>Apparently presumes a specific implementation and assumes facts >>which have not been presented to this working group. There are >>lots of deployment scenarios where this would not be the case. > >By design, UW has multiple independent servers. We split user space >and function space. My personal mail is not on the same server as >the support inboxes that I track. Nor do authentication credentials >for one necessarily coincide with credentials for the other. > >We do not have a single monolithic IMAP server which has access to >all mailbox data which a user may choose to forward in a message. Nor is this required by a push architecture. Nothing in the above is an argument against PUSH-based forward without download. >>>Disaster 5: readonly IMAP servers must have writeable mailboxes for submit. >>How did you come to the conclusion that read only IMAP servers would offer >>this facility? > >Of course they would not. That's the problem. How is this to work >if the user forwards a message from a readonly IMAP server? By using exactly the same mechanism as is used today. > >>>Disaster 6: server facilties which separated IMAP from submission >>>to different machines (and sometimes different networks) must put >>>them back on a single server. >>Again, apparently presumes a specific implementation and assumes facts >>which have not been presented to the working group. > >By design, UW has IMAP servers on different machines/subnets from >submit servers, which in turn are different from incoming SMTP >servers. Suddenly, Lemonade push decrees that we can't do that any >more; the IMAP servers now much have a path to the submit servers, >and submission now must use IMAP credentials instead of the separate >submit credentials. > >This isn't a problem with pull. Exactly the same "doesn't have a path" problem can arise with PULL. Having a submit server in the DMZ because it is also the outbound MTA is common; that may not currently have any access to non-SMTP traffic inside the firewall. That would have to change with PULL, since it would have to allow that server to PULL data from any of the IMAP servers which might be referenced. >>To say this gently, these "disasters" seem to arise out of a >>mistaken sense of the requirements and mainly to require a calm >>application of software engineering and deployment. No one is >>asking anyone to rip up server farms and replant; no one is asking >>that IMAP grow the kitchen garden in its sink. > >Wrong! > >If Lemonade results in a declaration that certain server farms are >incompatible with the standard that Lemonade has defined, then the >management of those server farms will come under extreme pressure to >comply with Lemonade. There is a very big difference between declaring something incompatible (which implies the old methods don't work) and adding a mechanism to a protocol that leaves the old mechanisms intact. The second is being proposed here, not the first. >Once the bookstore starts selling new handhelds and cell phones with >Lemonade technology, the purchasers will be very distraught to find >that these will not work with our facilties, and they will scream >bloody murder. And they will scream bloody murder if your SUBMIT servers have not been upgraded to support PULL, too. >For better or worse, Lemonade represents something that can not be >ignored by existing server farms or IMAP server implementations. No one is proposing that the existing mechanisms be torn out, and both proposed mechanisms require upgrades to existing facilities. For better, I believe. Your mileage may vary. Again, speaking personally, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 9 21:41:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11732 for ; Mon, 9 Feb 2004 21:41:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNpC-0004oq-5C for lemonade-archive@odin.ietf.org; Mon, 09 Feb 2004 21:40:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A2eYcP018520 for lemonade-archive@odin.ietf.org; Mon, 9 Feb 2004 21:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNpB-0004od-S7 for lemonade-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 21:40:33 -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 VAA11699 for ; Mon, 9 Feb 2004 21:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqNp9-0006kp-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 21:40:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqNoJ-0006gL-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 21:39:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqNnf-0006b4-00 for lemonade-web-archive@ietf.org; Mon, 09 Feb 2004 21:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNng-0004jb-Lt; Mon, 09 Feb 2004 21:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNnJ-0004iw-4s for lemonade@optimus.ietf.org; Mon, 09 Feb 2004 21:38:37 -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 VAA11641 for ; Mon, 9 Feb 2004 21:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqNnG-0006Z6-00 for lemonade@ietf.org; Mon, 09 Feb 2004 21:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqNmL-0006Tp-00 for lemonade@ietf.org; Mon, 09 Feb 2004 21:37:38 -0500 Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqNlp-0006OM-00 for lemonade@ietf.org; Mon, 09 Feb 2004 21:37:05 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i1A2b59h008070; Mon, 9 Feb 2004 18:37:05 -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.11+UW04.02) with ESMTP id i1A2b4sa025022 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2004 18:37:04 -0800 Date: Mon, 9 Feb 2004 18:37:05 -0800 (Pacific Standard Time) From: Mark Crispin To: Ted Hardie cc: Pete Resnick , lemonade@ietf.org Subject: Re: [lemonade] Embedded URI variant In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 9 Feb 2004, Ted Hardie wrote: > "hostile to external attachments" is not the term I would use, you will no > doubt be surprised to learn. Its scope is limited by design, and it is not > intended to cover a complete all-uri-scheme inclusion mechanism. That's a > feature, in my opinion. The scope of IMAP (and earlier of POP) is limited by design, and is not intended to include message submission. For IMAP, RFC 3501 says: IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. Similar text appears in the older IMAP specifications, e.g. in RFC 1176: Like POP, IMAP2 specifies a means of accessing stored mail and not of posting mail; this function is handled by a mail transfer protocol such as SMTP (RFC 821). In the POP3 specification (RFC 1939), we find: When the user agent on a client host wishes to enter a message into the transport system, it establishes an SMTP connection to its relay host and sends all mail to it. This relay host could be, but need not be, the POP3 server host for the client host. In the POP2 specification (RFC 937), we find: The intent of the Post Office Protocol Version 2 (POP2) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). For further information see RFC-821 [1] and RFC-822 [2]. This is a feature, in my opinion. The point is that this is all irrelevant. It doesn't matter what my opinion is. Nor does it matter that the specifications all say that access protocols do not post. The IMAP specification does not have the force of veto over Lemonade's decision. Nor do I. We (meaning the entire Lemonade WG) can not take comfort that the scope of forward-without-download does not contain a complete inclusion mechanism. We must consider what may happen when a future effort builds upon what we do. The differences between push and pull are negligible in terms of protocol over the wire. Both can be restricted in scope to Lemonade's specific forward without download. What is very different is what happens when a future effort overturns that restriction. There are three possibilities of such a follow-on to push: (1) The future effort decides that push (CATENATE+SUBMIT) is a dead end, and builds a completely new submission facility which is likely to be pull-based. (2) The future effort eschews reinventing the wheel, and extends push. (3) There will never be such a future effort. I believe that when you dismiss my worries by pointing to the limited scope of Lemonade, you are in effect contending that (1) or (3) are more likely than (2). [If this is not the case then I have missed your point.] I believe that (3) is extremely unlikely. The bad thing about (1) is that of annoyance: effort wasted in building push when it was known that pull was the correct long-term solution, and yet another protocol wart that will have to be supported for an indefinite time even though something better exists. My real fear is (2). You've implied that you don't consider (2) to be likely; you've even implied that you agree that (2) is highly undesirable. I am less sanguine. > And I disagree. One, with your consistent use of "lack of support for > attachments" when the class of objects not included is very different from > the common use of the term. I'm not sure what you mean by this. I use attachments in multiple mail clients, and most commonly in Pine; and thus my use is in line with how Pine defines "attachments". If you feel that Pine's use of "attachments" is not the "common use of the term" then I am bewildered at what that may be. > Two, with your prediction that extensions will automatically expand the very > useful scope of the initial proposal to some general purpose composition > protocol. As specified, CATENATE doesn't solve forward-without-download when the user is on an IMAP server that does not give the user write privileges. That *is* in the Lemonade charter. Nor does it solve the problem that users of desktop or web based clients can not attach files from a shell server without having to download the file to the client first. That may not be in the Lemonade charter, but it is a problem that users of mobile clients face now. I encounter it every day. The obvious fix to both problems is to extend CATENATE to accept any arbitrary URL. That's my feared outcome (2). > Three, with the implicit assumption that Pull would not be similarly twisted > out of shape by later forces. On the contrary, I assume that pull *will* be twisted. That is part of pull's design. > If you wish to expand the scope of work the group will work on, you should > amend the charter. I think that you're torching a strawman here. I do not wish to expand the scope of work the group will work on. I wish that the group consider how that work may be expanded upon in the future. The group must decide between two competing proposals which otherwise are largely equivalent, and whose differences would seem to be cosmetic to most observers. > As it stands, you seem to be arguing that the group should build to meet the > eventual development of a general purpose composition protocol, without > arguing that it should actually build such a general purpose composition > protocol. No, I argue that the group should build with the assumption that future efforts expand its work, as opposed to building with the assumption that its work will be a dead end. > From my perspective, if it is building > to meet that eventuality, the group would need to develop at least an > initial architecture for the eventual protocol. I disagree, both with the > supposition and the scope creep, but it does seem to be the outcome > of your argument. And that alone looks like it needs a charter amendment > to my eyes. For better or worse, forward-without-download is a revision to submit. Either we expand the existing submit protocol to do pull, or we expand the existing access protocol (IMAP) to do push. You seem to be arguing that: 1) push is an architectural dead end, and will surely not lead to the eventual protocol 2) pull is an initial architecutre for the eventual protocol and that since a charter amendment is necessary to do the eventual protocol that push is preferable. [Again, please correct me if I am misstating your position.] I believe that whatever we decide -- push or pull -- will wind up being the initial architecture for the eventual protocol. I do not believe that push is a dead-end. Push can be made to work as the eventual protocol; the extension to CATENATE is obvious. There will be pressure not to reinvent the wheel by creating yet another submit mechanism. > This is not meant to torch another strawman, as we have enough alight > as it stands. I simply mean that if this is the working group's vision > of where this is going, it has to plan enough to get it right. I am not opposed to amending the charter to take on the task of a general composition protocol, although I think that it is unnecessary if pull is selected. If push is selected, I think that a charter amendment is necessary. >> Push insists that all mailboxes be resident upon a readwrite IMAP server. > No, it does not. It says that if you are going to take advantage of forward > without download, you need a readwrite IMAP server. That's a real > engineering trade off, and it bears repeating. So, as a "real engineering tradeoff", we are seriously considering *not* solving a charter item for a current real-world situation? > I can only say that as a member of this working group I would oppose it. I wish that I could take comfort in that. I don't. > As it stands, though, we have a task at hand. By imagining some future task > that is much larger without any reason to believe it would be our work to do, > we are hindering getting this work done at all. The difference is that I don't see it as a future task. I am a mobile client user. I use a laptop with a CDPD modem every day while I'm on the ferry going to/from work. Most of that traffic is email. I use Pine, not just because I am a member of its development team, but also because it's the *only* email client which is tolerable with CDPD. For my everyday mobile client use, forward-without-download has limited value. I've already read the silly message, and it's in my client's cache. It may be a few more bytes to upload it, but that has to be weighed against the extra RTTs to do forward-without-download with either push or pull. FWIW, push seems to have more RTTs than pull. Now, if the message has attachments, that makes a difference. I may not have downloaded those attachments to read the message, and I certainly don't want to upload them. The problem is, I'm constantly needing to attach files which are not on my laptop but instead are on the UNIX system at work. I need to do that more often than I need to forward messages. >> In order for an IMAP server to have a submit facility, the users of that >> IMAP server must have the ability to upload (via CATENATE) to that IMAP >> server. This declares our readonly group IMAP servers to be non-compliant. > No, it declares that they do not offer this facility in that configuration. Unfortunately, history shows us that within a relatively short time after either push or pull is adopted by Lemonade, we will see the advent of clients which insist upon using the Lemonade mechanism (either push or pull) and will not have a capability to use the old-fashioned way via submit. Such clients will issue an error message stating that the IMAP server is "deficient." You can't say that this won't happen. >> In order for an IMAP user to submit, the credentials for message submission >> must be equivalent to the credentials for message access. > Again, it doesn't have to. It may have the affect that the users' > credentials and the servers credentials' are taken together to mean that a > submission should be accepted. You're missing the point, which is that the current push SUBMIT proposal for IMAP assumes that the credentials used to authenticate to the IMAP server in some way relate to submit credentials. Put another way, the proposed SUBMIT command assumes that IMAP credentials are equivalent to submit credentials. It may also assume trust between the IMAP server and MSA. >> We do not have a single monolithic IMAP server which has access to all >> mailbox data which a user may choose to forward in a message. > Nor is this required by a push architecture. Nothing in the above is an > argument against PUSH-based forward without download. The problem is that you need the monolith to do push-based forward. In a non-monolith world, either every IMAP server needs to allow every submit-privileged user to do CATENATE, or every IMAP server needs to have access to mailboxes on every other IMAP server. >> How is this to work if the user forwards a message from a readonly IMAP >> server? > By using exactly the same mechanism as is used today. Are you supposing that every client will support both the old way and the new way forever? If not, what do you mean? > Exactly the same "doesn't have a path" problem can arise with PULL. Having a > submit server in the DMZ because it is also the outbound MTA is common; that > may not currently have any access to non-SMTP traffic inside the firewall. > That would have to change with PULL, since it would have to allow that server > to PULL data from any of the IMAP servers which might be referenced. I will conceed that point. My only answer is that we gave up having the submit server co-exist with the outbound MTA (much less the inbound MTA!) long ago. They're all separate boxes. > There is a very big difference between declaring something incompatible > (which implies the old methods don't work) and adding a mechanism > to a protocol that leaves the old mechanisms intact. The second is > being proposed here, not the first. True, but client authors have a way of doing the first even if it wasn't intended by the WG. That has been the bane of my existance over the past several years. My experience is not unique. >> Once the bookstore starts selling new handhelds and cell phones with >> Lemonade technology, the purchasers will be very distraught to find that >> these will not work with our facilties, and they will scream bloody murder. > And they will scream bloody murder if your SUBMIT servers have not > been upgraded to support PULL, too. Indeed they will. The difference is that pull just involves adding functionality. Push involves revoking architectural decisions first. -- 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 Tue Feb 10 08:59:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18788 for ; Tue, 10 Feb 2004 08:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYPb-0004jO-FM for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 08:58:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ADwpqD018180 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 08:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYPb-0004j9-9Z for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 08:58: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 IAA18778 for ; Tue, 10 Feb 2004 08:58:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYPZ-0002hV-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 08:58:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYOe-0002cq-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 08:57:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqYNp-0002YZ-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 08:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYNo-0004f3-TD; Tue, 10 Feb 2004 08:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYNg-0004em-Jf for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 08:56:52 -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 IAA18733 for ; Tue, 10 Feb 2004 08:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYNf-0002Xm-00 for lemonade@ietf.org; Tue, 10 Feb 2004 08:56:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYMi-0002Tb-00 for lemonade@ietf.org; Tue, 10 Feb 2004 08:55:53 -0500 Received: from lin1.andrew.cmu.edu ([128.2.6.59]) by ietf-mx with esmtp (Exim 4.12) id 1AqYMC-0002PB-00 for lemonade@ietf.org; Tue, 10 Feb 2004 08:55:20 -0500 Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3/admin mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i1ADtKtH012207 for ; Tue, 10 Feb 2004 08:55:20 -0500 Date: Tue, 10 Feb 2004 08:55:19 -0500 (EST) From: Rob Siemborski To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [lemonade] Advantages of Pull 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 Ted/Pete, I'm sitting here reading through the "Embedded URI Varient" thread, and I think I'm missing something important. What do you see as the man *advantages* of push over pull? Currently, I can see: a) Fits exactly into the LEMONADE charter -- no more, no less. b) There is a perception that is simpler to deploy (possibly because it only modifies the IMAP server, possibly because it does not require implementing a URLFETCH client). Am I missing something? -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 Tue Feb 10 09:04:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18942 for ; Tue, 10 Feb 2004 09:04:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYUS-0004wj-6g for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 09:03:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AE3qnS019007 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 09:03:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYUS-0004wU-1h for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 09:03:52 -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 JAA18911 for ; Tue, 10 Feb 2004 09:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYUQ-00038k-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 09:03:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYTV-00033Z-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 09:02:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqYSd-0002yu-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 09:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYSe-0004pg-EW; Tue, 10 Feb 2004 09:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYSa-0004pG-7I for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 09:01:56 -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 JAA18863 for ; Tue, 10 Feb 2004 09:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYSY-0002yB-00 for lemonade@ietf.org; Tue, 10 Feb 2004 09:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYRd-0002sP-00 for lemonade@ietf.org; Tue, 10 Feb 2004 09:00:58 -0500 Received: from lin1.andrew.cmu.edu ([128.2.6.59]) by ietf-mx with esmtp (Exim 4.12) id 1AqYQc-0002nD-00 for lemonade@ietf.org; Tue, 10 Feb 2004 08:59:54 -0500 Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3/admin mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i1ADxstH012215 for ; Tue, 10 Feb 2004 08:59:54 -0500 Date: Tue, 10 Feb 2004 08:59:53 -0500 (EST) From: Rob Siemborski X-X-Sender: rjs3@sourcefour.andrew.cmu.edu To: lemonade@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [lemonade] Re: Advantages of PUSH 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 On Tue, 10 Feb 2004, Rob Siemborski wrote: > Am I missing something? (Other than the fact that the subject of this message probably should have been "Advantages of Push?") :) Sigh. -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 Tue Feb 10 10:16:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22191 for ; Tue, 10 Feb 2004 10:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcI-000672-4E for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFG1PU023481 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcH-00065v-5O for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:16: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 KAA22123 for ; Tue, 10 Feb 2004 10:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZcF-0001eU-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 10:15:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZbG-0001YJ-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 10:14:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaK-0001SN-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 10:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZaK-0005W3-OW; Tue, 10 Feb 2004 10:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZaF-0005Uf-5V for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 10:13: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 KAA21900 for ; Tue, 10 Feb 2004 10:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaC-0001RI-00 for lemonade@ietf.org; Tue, 10 Feb 2004 10:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZZF-0001LZ-00 for lemonade@ietf.org; Tue, 10 Feb 2004 10:12:53 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqZYM-0001By-00 for lemonade@ietf.org; Tue, 10 Feb 2004 10:11:58 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFBPA04304 for ; Tue, 10 Feb 2004 09:11:25 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Feb 2004 09:11:24 -0600 Message-ID: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: lemonade@ietf.org Date: Tue, 10 Feb 2004 09:11:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [lemonade] Time to Stand up and be counted 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'd like to see all who have a stake to clearly express their views and a few lines supporting their position. A collection of such positions will help determine if we have an emerging consensus or not. I now strongly favor a IMAP PUSH model. 1) It can be implemented using an IMAP submission proxy in front of any current IMAP server. This reduces the barrier to entry for early deployments. 2) It simplifies the engineering of a secure submission service. I don't need a separate DMZ-resident submission service with access to users credentials as SMTP-Submit now requires. (I can proxy IMAP without access to passwords to a store in a more secure zone, while I can't do that easily with SMTP-submit) One less hole in the firewall, one less avenue for attack. 3) It saves a network connection for the SMTP-submit, a number of round-trips, and at least some bandwidth. While this may be of marginal benefit in well connected environments, I find faster and cheaper to be compelling on today's wireless data networks. (Also 1/3 fewer new connections / flows to manage on firewalls and load-balancers also saves $$) 4) It seems overall simpler in avoiding the hard work of getting a third-party trust model right. It also avoids an obvious race condition and simplifies the logic for doing a reliable, coordinated delete from the "outbox". This benefit is especially evident in the likely case where the submission server and IMAP store are provided by different vendors. 5) It seems easier to add in other lemonade-charter items such as future delivery with revocation. In the case of future delivery the long-term queues and associated message data are in a single place, usually subject to regular backups. I view the PUSH model as sharing state between submission queues on the SMTP-Submit server and content in the IMAP store, creating conditions where the two may easily get out-of-sync. Also, submission servers don't typically store long-term persistent data and are rarely backed-up. Storing long-term future-delivery queues will require adding backup to that system as well as requiring higher availability hardware. I see both proposals as equally capable of being extended over time to support richer composition capabilities, for good or bad. Other views? Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 10 11:03:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22190 for ; Tue, 10 Feb 2004 10:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcI-00067H-7S for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFG29l023498 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 10: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 1AqZcH-00066Z-QW for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:16: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 KAA22126 for ; Tue, 10 Feb 2004 10:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZcF-0001eZ-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 10:15:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZbH-0001YR-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 10:15:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaK-0001SO-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 10:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZaK-0005Vv-HH; Tue, 10 Feb 2004 10:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZaE-0005UD-Dz for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 10:13: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 KAA21894 for ; Tue, 10 Feb 2004 10:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaC-0001RD-00 for lemonade@ietf.org; Tue, 10 Feb 2004 10:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZZE-0001LR-00 for lemonade@ietf.org; Tue, 10 Feb 2004 10:12:53 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqZYM-0001Bx-00 for lemonade@ietf.org; Tue, 10 Feb 2004 10:11:58 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFBP320923 for ; Tue, 10 Feb 2004 09:11:25 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Feb 2004 09:11:24 -0600 Message-ID: <54E40201497DF142B06B27255953F7970AA25404@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: lemonade@ietf.org Date: Tue, 10 Feb 2004 09:11:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [lemonade] Channel questions 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 Having recently reviewed the URLauth document, I am curious why we don't use that mechanism to authenticate the channel extension? I see the channel extension has the same security problems as the IMAP PULL scheme, that is, the URL established by the IMAP server can be guessed, or snooped and re-fetched. Is there something I am missing that makes the risk model different for Channel? Also, the security considerations sections needs to be substantially beefed up. In the current scheme, I would suggest discussion on at least the following points: - Don't use a predictable namespace for the URL's. Seems simple, but don't make URL's for message contents that are world-readable with identifiers based on message-id and/or body structure. - Make URL's available for a limited time window only. In fact, it would be best if the URL went "poof" after being accessed the first time. - Don't assume the channel client is in the same security zone as the the IMAP server. I see this as an Internet service. It may be too easy for an implementer to assume that the phone client, for example, is always on the same LAN segment, firewalled from the rest of the world. Deploying that implmentation elsewhere would be an open invitation. Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 10 19:59:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07215 for ; Tue, 10 Feb 2004 19:59:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqii0-0001ca-UZ for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 19:58:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B0wWLW006231 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 19:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqii0-0001cQ-QC for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 19:58: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 TAA07085 for ; Tue, 10 Feb 2004 19:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqihz-0004N8-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 19:58:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqif8-0003hF-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 19:55:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqid4-0003BP-05 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 19:53:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqiQF-0005Jc-Co for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 19:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiQ7-0008Tk-KW; Tue, 10 Feb 2004 19: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 1AqiPQ-0008Qh-Lw for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 19:39:20 -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 TAA04747 for ; Tue, 10 Feb 2004 19:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiPO-0000xr-00 for lemonade@ietf.org; Tue, 10 Feb 2004 19:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiOK-0000hQ-00 for lemonade@ietf.org; Tue, 10 Feb 2004 19:38:13 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AqiN7-0000QA-00 for lemonade@ietf.org; Tue, 10 Feb 2004 19:36:57 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1B0aqVo008955 for ; Tue, 10 Feb 2004 17:36:52 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HSW007C79PGMJ@edgemail1.Central.Sun.COM> for lemonade@ietf.org; Tue, 10 Feb 2004 17:36:52 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HSW00D499PF7N@mail.sun.net> for lemonade@ietf.org; Tue, 10 Feb 2004 17:36:52 -0700 (MST) Date: Tue, 10 Feb 2004 16:38:30 -0800 From: Chris Newman To: lemonade@ietf.org Message-id: <2147483647.1076431110@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Content-Transfer-Encoding: 7BIT Subject: [lemonade] Server implementors for Pull 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 have been asked by several people to weigh in on the mailing list about push vs. pull. I strongly favor the pull model. It is a more scalable and better architecture, will be much simpler to implement and deploy, and is a much safer for the future of the email infrastructure. 1. Simpler We have multiple access protocols (IMAP, POP, NNTP, etc) and multiple transport protocols (SMTP, XMPP, SIMPLE, etc) for messages. To do forward without download, we can take all the complexity of every transport protocol and shove it into every access protocol -- that's a complexity increase of N x M. Or we can do something elegant: change every access protocol so there is a simple and secure way to extract content, and change every submission protocol so these simple profiles can be used to assemble the message when appropriate. The result is significantly less complexity because we optimize both ends of the protocol for integration. 2. Faster to Implement We have separate teams of people working on IMAP and SMTP and I'm sure most implementers do (sometimes they're even separate companies). The "pull" model splits the work so a modest parallel investment across the teams finishes the work. In fact, BURL and URLAUTH are bite-sized projects that get something useful released and CATENATE can be done in a later release when the "copy-to-sent-mail-and-forward-without-download" feature is needed. On that basis, I would recommend to management that we implement "pull" before we're asked. The push model requires all the work be done in the IMAP server. The IMAP server is more security sensitive, the protocol is much more complex already, and we already have real reluctance by developers to use the protocol because it is too bloated. I will recommend to management that we do not implement the "push" model unless it appears in RFPs from customers with lots of money. The cost is too concentrated on one team and better to risk being a bit behind the times than adding unnecessary complexity to a sensitive system. 3. Scalable Architecture A scalable IMAP server needs a very high caliber disk array and I/O subsystem and tends to be the choke-point in the scalability of the messaging system. We have recently achieved surprising performance improvements in the messaging system by moving complexity off the IMAP server and into the MTA (by using LMTP instead of SMTP for delivery to the message store machine from the MTA machine). The last thing we want to do is put more load on the IMAP servers again. The submit servers, on the other hand, often have CPU, disk and network I/O to burn in a messaging deployment. 4. Optimizing for Client Convenience can be a _Big Mistake_. I used to think it was a good idea and proceeded to produce ACAP. I learned my lesson the hard way. Good protocol design must balance the complexity of the client against the complexity of the server. Push ignores server and system architecture in favor of client convenience. You will notice most of the server implementers on this list are crying foul. We could end up with a proposal that deploys just as fast as ACAP for the same reasons. Go read item 2 again if you don't believe this is a risk. 5. Functional Separation Functional separation is a very valuable property of the IETF's present IMAP/SMTP messaging architecture. It's better for deployment. It's better for support. It's better for management. It's better for scalability. It's great when the SMTP server can be upgraded separately from the IMAP server and vice-versa. You can get best-of-breed IMAP servers and best-of-breed SMTP servers and they work together (presuming a common SMTP -> IMAP delivery mechanism like LMTP). The loss of functional separation can be _very_ expensive. Even a loss as mild as "POP before SMTP" results in a significant performance loss, requirements to upgrade the systems in lockstep, buy them from the same vendor, and make migrations to a different vendor more difficult. I find the "authrole=submit" in URLAUTH to be worrisome for functional separation (albeit unavoidable for the best security), but the "push" model is a full-scale disaster for functional separation. This will hurt a lot. I wish I could predict how, but I've learned over time that it's impossible to predict exactly when and how architecture mistakes will bite. 6. IMAP bloat Full-function access protocols for complex data structures are necessarily complex and as a result, IMAP is complex. Because IMAP is a bit different from other protocols it is perceived to be more complex than it actually is. And because of the behavior variations permitted by the spec it is also complex in practice. This complexity is a deterrent to implementing IMAP. Now IMAP must grow some complex extensions as the access needs for a mailstore become better understood and more sophisticated (e.g. i18n SORT/THREAD). But the last thing we should do is shove a boatload of functionality into IMAP that's unrelated to accessing a mailstore. GETURL is all about accessing a mailstore and even without the URLAUTH facilities it enhances the protocol by providing a long desired shortcut for simple access transactions. But IMAP Submit is orders of magnitude more complex and unrelated to the primary function of IMAP. And yes, I've written both an SMTP client and an SMTP proxy so I'm well aware of the complexity needed to implement submit correctly (since it's a blend of the two). 7. Security Putting my "deployable security" hat on, I find both proposals to be about equally worrisome in different ways. IMAP Submit creates a new channel for message data that needs to be audited in addition to the "access over IMAP" channel. It also requires configuring a full trust proxy authentication relationship between the IMAP server and the first MTA. IMAP Submit is also worrisome from a code-review perspective since it adds lots of complex code to the more security-sensitive part of the system. URLAUTH creates a new authentication mechanism with tremendous abuse potential if the sysadmin misconfigures it. The "authrole=submit" also requires setting up a trust relationship between submit and IMAP, but it's really just a different kind of administrative user so may be simpler than the IMAP pull issue. There's also the risk that the GETURL code to validate the URLAUTH has bugs, although that's much less code than the submit code. 8. Bolt Sendmail onto UW imapd This is how the push model will be implemented in most early deployments and it will become the de-facto "reference implementation" for the feature. I've mentioned this to folks at both UW and sendmail and they all shudder at the idea. This is your future if you choose "push". Trust me, you don't want this to happen. I'm sure I'm missing some, but that is enough of a tome for now. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 10 20:56:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11919 for ; Tue, 10 Feb 2004 20:56:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjbv-0006hi-Nl for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 20:56:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B1uJDb025764 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 20:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjbv-0006hT-Ik for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 20:56:19 -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 UAA11915 for ; Tue, 10 Feb 2004 20:56:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqjbt-0005JC-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 20:56:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqjb2-0005EP-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 20:55:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqjag-00058x-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 20:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjah-0006eY-0N; Tue, 10 Feb 2004 20:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqjZz-0006bd-PI for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 20:54:19 -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 UAA11890 for ; Tue, 10 Feb 2004 20:54:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqjZx-000585-00 for lemonade@ietf.org; Tue, 10 Feb 2004 20:54:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqjYx-00053D-00 for lemonade@ietf.org; Tue, 10 Feb 2004 20:53:16 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AqjYp-0004yY-00 for lemonade@ietf.org; Tue, 10 Feb 2004 20:53:07 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1B1r2vf015342 for ; Tue, 10 Feb 2004 17:53:02 -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 i1B1r0tR029280 for ; Tue, 10 Feb 2004 17:53:01 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Tue, 10 Feb 2004 17:53:00 -0800 To: lemonade@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [lemonade] Push, I say Push, son. 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 (For those not addicted to cartoons as children, the above is a reference to Foghorn Leghorn, a large cartoon rooster). I believe PUSH is a better way forward than PULL. I agree with the points Greg has made. A few more below, but before that, an overarching concern: PUSH or PULL: Simplify, simplify, simplify. Whatever choice this working group makes (PUSH or PULL), it is critically important that we keep focus and do not allow this work item to expand past our capabilities. Getting nothing done is far worse than choosing a sub-optimal solution. In favor of PUSH: 1) I believe PUSH will be easier to implement and deploy in the environments that need it most. The need we're addressing is one for clients in limited-capacity environments. That need is real, it is a major problem for wireless deployments today, and there is a real risk that delay will cause the need to be met with protocols not based in the email world at all. That's a serious risk to interoperablity, and a serious mistake. If you are worried about imapd+sendmail, you should also be worried about sendmail+apache, which is a major risk of placing this burden on the submit server. 2) It is relatively easy to chain this service in ways that meet common network topologies in both wireless and enterprise environments. Having an IMAP/submit server speak to a next hop MTA inside an administrative boundary is relatively easy, and the next-hop MTA can handle the majority of queueing and retransmission. 3) IMAP's complexity has historically been made worse by behavior variations, and it is historically the clients which have been required to handle the majority of that variation. It is also true that adding complexity to any service is a deterrent to implementation and deployment. But in this case, the client's view of this is that the functionality needed is core to the IMAP service--it is "access to a mailstore". Rather than "download access" to a mailstore, it is "forward access", and, from a client's point of view, these are very strongly related sets of actions and permissions. Shifting the actions and permissions to another protocol which has no similar functionality is not a client-friendly action. 4) It does not require a fundamentally new security model. While I think URLAUTH may eventually be very useful, I have concerns both about how it ties authorization to location and in the deployment of a "pawn ticket" model of authorization. As it stands, this is not just undeployed code; authorization without authentication is not in the security lexicon of many people. Even with a great deal more security review in the IETF, there is a serious risk that deployment would be stalled by the unwillingness of corporations to shift away from authentication/authorization mechanisms. 5) I believe PUSH avoids both some race conditions and some very serious risks of head-of-line blocking issues; even in multithreaded servers, a long delay in reply by a server accessed for PULL can consume network buffers and raise the risk of a denial of service. I also disagree with Chris's assertions on a number of points, but I will reply to those in a separate message. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 10 21:17:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12947 for ; Tue, 10 Feb 2004 21:17:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjva-0000Rb-5R for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 21:16:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B2Gck1001701 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 21:16:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjva-0000RM-0Z for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 21:16:38 -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 VAA12941 for ; Tue, 10 Feb 2004 21:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqjvX-0007d3-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 21:16:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqjuQ-0007VZ-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 21:15:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqju0-0007PO-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 21:15:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqju1-0000HE-MG; Tue, 10 Feb 2004 21:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqjtT-0000CV-H4 for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 21:14: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 VAA12859 for ; Tue, 10 Feb 2004 21:14:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqjtQ-0007OP-00 for lemonade@ietf.org; Tue, 10 Feb 2004 21:14:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqjsa-0007IX-00 for lemonade@ietf.org; Tue, 10 Feb 2004 21:13:33 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AqjsC-0007BY-00 for lemonade@ietf.org; Tue, 10 Feb 2004 21:13:09 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1B2D7vf016390; Tue, 10 Feb 2004 18:13:08 -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 i1B2D4VK004031; Tue, 10 Feb 2004 18:13:05 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2147483647.1076431110@nifty-jr.west.sun.com> References: <2147483647.1076431110@nifty-jr.west.sun.com> Date: Tue, 10 Feb 2004 18:13:04 -0800 To: Chris Newman , lemonade@ietf.org From: Ted Hardie Subject: Re: [lemonade] Server implementors for Pull 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Chris, Thanks for weighing in, some comments and responses below. At 4:38 PM -0800 02/10/2004, Chris Newman wrote: >I have been asked by several people to weigh in on the mailing list about push >vs. pull. > >I strongly favor the pull model. It is a more scalable and better >architecture, will be much simpler to implement and deploy, and is a >much safer >for the future of the email infrastructure. > >1. Simpler > >We have multiple access protocols (IMAP, POP, NNTP, etc) and >multiple transport >protocols (SMTP, XMPP, SIMPLE, etc) for messages. To do forward without >download, we can take all the complexity of every transport protocol and shove >it into every access protocol -- that's a complexity increase of N x M. Or we >can do something elegant: change every access protocol so there is a >simple and >secure way to extract content, and change every submission protocol so these >simple profiles can be used to assemble the message when appropriate. The >result is significantly less complexity because we optimize both ends of the >protocol for integration. Again, this working group is not chartered to do a cross product of every transport and access protocol. Nor is it chartered to change every access protocol so there is "a simple and secure way to extract content" and "change every submission protocol so these simple profiles can be used to assemble messages". It's chartered to achieve forward without download. Push or Pull, if it sets out to achieve the latter, it will fail. I don't think it has the expertise for that, and it certainly doesn't have the time. Creating a reasonable "pawn ticket" model of authorization could be a very useful piece of work, but assuming that we could get from there to extraction from every access protocol is a big leap. >2. Faster to Implement > >We have separate teams of people working on IMAP and SMTP and I'm sure most >implementers do (sometimes they're even separate companies). The "pull" model >splits the work so a modest parallel investment across the teams finishes the >work. In fact, BURL and URLAUTH are bite-sized projects that get something >useful released and CATENATE can be done in a later release when the >"copy-to-sent-mail-and-forward-without-download" feature is needed. On that >basis, I would recommend to management that we implement "pull" before we're >asked. > >The push model requires all the work be done in the IMAP server. The IMAP >server is more security sensitive, This is a critical point for me. If you are starting from the more security sensitive point and moving forward (which PUSH does), I believe it will be easier to achieve confidence that you have the security done to a degree adequate to the task. Putting that same sensitivity in another server seems like it creates a barrier to deployment. > >A scalable IMAP server needs a very high caliber disk array and I/O subsystem >and tends to be the choke-point in the scalability of the messaging >system. We >have recently achieved surprising performance improvements in the messaging >system by moving complexity off the IMAP server and into the MTA (by >using LMTP >instead of SMTP for delivery to the message store machine from the MTA >machine). The last thing we want to do is put more load on the IMAP servers >again. The submit servers, on the other hand, often have CPU, disk >and network >I/O to burn in a messaging deployment. This is very useful data; thank you. If the IMAP server moves the data quickly from submission to an internal MTA (so that the IMAP server is not intending to do final delivery), how much of this advantage can be retained? >4. Optimizing for Client Convenience can be a _Big Mistake_. > >I used to think it was a good idea and proceeded to produce ACAP. I >learned my >lesson the hard way. Good protocol design must balance the complexity of the >client against the complexity of the server. Push ignores server and system >architecture in favor of client convenience. You will notice most of the >server implementers on this list are crying foul. We could end up with a >proposal that deploys just as fast as ACAP for the same reasons. Go read item >2 again if you don't believe this is a risk. Optimizing without regard for client convenience is also a mistake. It's a balance. It's particularly critical that we understand what the client thinks the functionality in question is: I believe it is "access to a message store to get something done" in both cases. I've argued that elsewhere, but it is also worth pointing out that the client is already taking the brunt of the complexity in the IMAP world today. Putting this there has to be balanced not just for this extension, but in general. >5. Functional Separation > >Functional separation is a very valuable property of the IETF's present >IMAP/SMTP messaging architecture. It's better for deployment. It's >better for >support. It's better for management. It's better for scalability. >It's great >when the SMTP server can be upgraded separately from the IMAP server and >vice-versa. You can get best-of-breed IMAP servers and best-of-breed SMTP >servers and they work together (presuming a common SMTP -> IMAP delivery >mechanism like LMTP). > >The loss of functional separation can be _very_ expensive. Even a >loss as mild >as "POP before SMTP" results in a significant performance loss, >requirements to >upgrade the systems in lockstep, buy them from the same vendor, and make >migrations to a different vendor more difficult. > >I find the "authrole=submit" in URLAUTH to be worrisome for functional >separation (albeit unavoidable for the best security), but the "push" model is >a full-scale disaster for functional separation. This will hurt a >lot. I wish >I could predict how, but I've learned over time that it's impossible >to predict >exactly when and how architecture mistakes will bite. I agree that functional separation is a desirable element of the current architecture, and one of the reasons I have pushed for limiting the scope is that it keeps the IMAP store out of the business of assembling parts using other protocols. The difference I see here is that the submit server's functional separation is also lost, in my view, and I think it is worse because of the risk that it will start working outside the set of mail protocols entirely. That's a "scrying game" charge, though, so I should say simply that I agree with this point, but feel it applies equally to both methods. Some of my own points in favor of PUSH answer Chris's other points, so I won't repeat them again. Thanks again for your contribution, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 10 21:41:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13581 for ; Tue, 10 Feb 2004 21:41:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkJU-00028J-A3 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 21:41:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B2fKsr008193 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 21:41:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkJU-000284-2u for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 21:41:20 -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 VAA13578 for ; Tue, 10 Feb 2004 21:41:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkJR-0002Nj-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 21:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkIU-0002IL-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 21:40:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqkIH-0002DZ-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 21:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkIJ-0001nv-8l; Tue, 10 Feb 2004 21:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkHb-0001jY-2C for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 21:39: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 VAA13561 for ; Tue, 10 Feb 2004 21:39:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkHY-0002D9-00 for lemonade@ietf.org; Tue, 10 Feb 2004 21:39:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkGb-000280-00 for lemonade@ietf.org; Tue, 10 Feb 2004 21:38:22 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx with esmtp (Exim 4.12) id 1AqkGL-00022h-00 for lemonade@ietf.org; Tue, 10 Feb 2004 21:38:05 -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 i1B2c476013288 for ; Tue, 10 Feb 2004 18:38:04 -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.11+UW04.02) with ESMTP id i1B2besa032391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 10 Feb 2004 18:37:57 -0800 Date: Tue, 10 Feb 2004 18:37:34 -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; format=flowed Subject: [lemonade] proxies 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 have read Greg's message about proxies many times. The same arguments for using a proxy for push can also be used for using a proxy with pull. I do not see any circumstance in which the use of a proxy favors either pull or push. However, there is a question about implementation. I have implemented multiple IMAP servers and IMAP proxies. I have also implement an SMTP server and an SMTP proxy. Few other individuals in the world have done all of this. Speaking from this experience, the implementation of an IMAP proxy is a very large and complex task, involving a substantial amount of work (more than an IMAP server). Unlike SMTP, IMAP does not function well with "pass-through" proxies. I doubt very much that many (if any) sites will find the implementation of an IMAP proxy to be a viable means to achieve rapid deployment of push. -- 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 Tue Feb 10 22:11:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14727 for ; Tue, 10 Feb 2004 22:11:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqkme-0004NZ-Ac for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 22:11:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B3BSMQ016830 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 22:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqkmd-0004NN-U6 for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 22:11: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 WAA14724 for ; Tue, 10 Feb 2004 22:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqkma-0005gf-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 22:11:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqklg-0005ax-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 22:10:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqklE-0005Ui-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 22:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqklF-0004JO-1u; Tue, 10 Feb 2004 22:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqkka-0004IV-3u for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 22:09:20 -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 WAA14664 for ; Tue, 10 Feb 2004 22:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkkX-0005TP-00 for lemonade@ietf.org; Tue, 10 Feb 2004 22:09:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqkja-0005O7-00 for lemonade@ietf.org; Tue, 10 Feb 2004 22:08:18 -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 1Aqkie-0005ED-00 for lemonade@ietf.org; Tue, 10 Feb 2004 22:07: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.3b4); Tue, 10 Feb 2004 21:06:51 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Tue, 10 Feb 2004 21:06:48 -0600 To: Rob Siemborski From: Pete Resnick Subject: Re: [lemonade] Advantages of Push Cc: lemonade@ietf.org 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 Since I was asked: On 2/10/04 at 8:55 AM -0500, Rob Siemborski wrote: >What do you see as the main *advantages* of push over pull? > >Currently, I can see: >a) Fits exactly into the LEMONADE charter -- no more, no less. That's an administrative reason, not a technical one, and it's not a big deal to me. >b) There is a perception that is simpler to deploy (possibly because >it only modifies the IMAP server, possibly because it does not >require implementing a URLFETCH client). That has some traction to it for me, but is not primary. Greg and Ted laid out some interesting ones in their messages. For me, the main two are: - For the use cases that I think are going to be the vast majority, push seems the simplest architecturally - I think the security model is more manageable Architecturally: As a client, I've got an IMAP reference to data which is already on my IMAP server because I am either collecting together from other places in my IMAP store or I'm putting it there because I wanted a copy of the sent message. With push, in the same IMAP session, I give that IMAP reference to the IMAP server, tell it to collect together the data from its local storage, and push it out to the submit server. It's a straight line conversation: client->IMAP Server->Submit Server. With pull, I tell the IMAP server to collect together the data (if I'm using CATENATE or making my own copy of a new message), I form a different reference to that data (which includes the authorization data), I have an independent conversation with a submit server using a different protocol, and tell the submit server to have a conversation with my IMAP server to retrieve the data. The conversation is client->IMAP Server, client->Submit Server, and Submit Server->IMAP Server. That 3-way handshake just seems more complicated. Aside from that, IMAP servers seem well equipped to retrieve and transmit data. Submit servers do not seem well equipped to retrieve data. Putting this burden on the IMAP server seems like a logical extension of operations it already does. Putting the burden on the submit server seems a significant departure from its current operations. Security: The primary security consideration for me is "Who gets to look at user message data?". Next in order is "Who has access to user credentials?" Further down the list is "Who on my network is authorized to send messages?". With push, there is an obvious security configuration that makes sense to me: Users are authenticated and authorized to use the IMAP server (and therefore the IMAP server has an authorization/authentication database), only the IMAP server is authorized to send mail through the submit server (by co-locating the IMAP and submit server on the same machine or secure network), and the submit server has no access to authorization/authentication information or to any user message data not sent to it by the IMAP server directly. I could even firewall off port 143 from the submit server. That means that a compromised submit server will not give the attacker access to the authorization/authentication database, or any permission to messages not specifically sent to it by the IMAP server. It also means that some of the easier-to-write rouge SMTP processes on my net aren't able to use my submit server. My submit server can have one and only one job: To receive submissions from my IMAP server. That seems like a more secure environment. 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 Tue Feb 10 23:53:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17265 for ; Tue, 10 Feb 2004 23:53:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqmNG-0001ku-3u for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 23:53:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B4rMYs006741 for lemonade-archive@odin.ietf.org; Tue, 10 Feb 2004 23:53:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqmNF-0001kd-Un for lemonade-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 23:53: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 XAA17262 for ; Tue, 10 Feb 2004 23:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqmND-0007fc-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 23:53:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqmMJ-0007b3-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 23:52:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqmLy-0007WC-00 for lemonade-web-archive@ietf.org; Tue, 10 Feb 2004 23:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqmLx-0001d7-7F; Tue, 10 Feb 2004 23:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqmLN-0001ce-Fq for lemonade@optimus.ietf.org; Tue, 10 Feb 2004 23:51:25 -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 XAA17213 for ; Tue, 10 Feb 2004 23:51:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqmLJ-0007VF-00 for lemonade@ietf.org; Tue, 10 Feb 2004 23:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqmKP-0007QY-00 for lemonade@ietf.org; Tue, 10 Feb 2004 23:50:25 -0500 Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqmJn-0007LX-00 for lemonade@ietf.org; Tue, 10 Feb 2004 23:49:47 -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 i1B4nk5I010426; Tue, 10 Feb 2004 20:49:46 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i1B4njxH026708; Tue, 10 Feb 2004 20:49:45 -0800 Date: Tue, 10 Feb 2004 20:49:45 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Rob Siemborski , lemonade@ietf.org Subject: Re: [lemonade] Advantages of Push In-Reply-To: Message-ID: References: MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 10 Feb 2004, Pete Resnick wrote: > Aside from that, IMAP servers seem well equipped to retrieve and transmit > data. I think that you may have a misunderstanding of what IMAP servers do. IMAP servers are well equipped to manipulate disk files. IMAP servers are also well equipped to do stdio type I/O (to the controlling TTY). Many IMAP servers have no TCP code at all; they are spawned by [x]inetd and as far as they know are console applications on under a shell. It would be a major new mandate for IMAP servers to require them to have TCP code capable of acting as a protocol client of an MSA (e.g. SMTP server). -- 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 Wed Feb 11 00:18:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18856 for ; Wed, 11 Feb 2004 00:18:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqmkj-0003VR-VF for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 00:17:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B5HbQ0013471 for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 00:17:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqmkj-0003VC-Qb for lemonade-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 00:17:37 -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 AAA18820 for ; Wed, 11 Feb 2004 00:17:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqmkh-0003Eq-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 00:17:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqmjm-00037O-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 00:16:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqmjB-000306-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 00:16:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqmjD-0005Wu-IE for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 00:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqmjB-0003Ro-QG; Wed, 11 Feb 2004 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqmiX-0003Qb-Ig for lemonade@optimus.ietf.org; Wed, 11 Feb 2004 00:15: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 AAA18662 for ; Wed, 11 Feb 2004 00:15:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqmiV-0002wQ-00 for lemonade@ietf.org; Wed, 11 Feb 2004 00:15:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqmhW-0002o7-00 for lemonade@ietf.org; Wed, 11 Feb 2004 00:14:19 -0500 Received: from adsl-64-142-6-24.sonic.net ([64.142.6.24] helo=dmz.askneil.com) by ietf-mx with esmtp (Exim 4.12) id 1AqmgZ-0002fQ-00 for lemonade@ietf.org; Wed, 11 Feb 2004 00:13:20 -0500 Received: from askneil.com (neil-xp2.askneil.com [192.168.1.23]) by dmz.askneil.com (Postfix) with ESMTP id 58FCE9F18B; Tue, 10 Feb 2004 21:11:46 -0800 (PST) Message-ID: <4029BA2F.5070701@askneil.com> Date: Tue, 10 Feb 2004 21:14:23 -0800 From: Neil Katin User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin Cc: Pete Resnick , Rob Siemborski , lemonade@ietf.org Subject: Re: [lemonade] Advantages of Push References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit Content-Transfer-Encoding: 7bit To follow your argument forward Mark, couldn't those programs that are not "tcp aware, but spun off by inetd" just fork and exec /usr/lib/sendmail, and pipe the message to it? I'm not saying that's the optimal solution, but if you really feel that tcp programming is a great burden, there are (platform dependent) easy solutions. Neil Mark Crispin wrote: > On Tue, 10 Feb 2004, Pete Resnick wrote: > >> Aside from that, IMAP servers seem well equipped to retrieve and >> transmit data. > > > I think that you may have a misunderstanding of what IMAP servers do. > > IMAP servers are well equipped to manipulate disk files. IMAP servers > are also well equipped to do stdio type I/O (to the controlling TTY). > Many IMAP servers have no TCP code at all; they are spawned by [x]inetd > and as far as they know are console applications on under a shell. > > It would be a major new mandate for IMAP servers to require them to have > TCP code capable of acting as a protocol client of an MSA (e.g. SMTP > server). > > -- 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 > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Feb 11 18:40:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11260 for ; Wed, 11 Feb 2004 18:40: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 1Ar3xL-0002zY-2Q for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 18:39:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BNdlup011496 for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 18:39:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3xK-0002zL-QI for lemonade-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 18:39: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 SAA11234 for ; Wed, 11 Feb 2004 18:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3xH-0006YN-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 18:39:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3wP-0006Sp-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 18:38:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3vb-0006MY-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 18:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3vc-0002h5-Ie; Wed, 11 Feb 2004 18:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3uh-0002Tq-Pj for lemonade@optimus.ietf.org; Wed, 11 Feb 2004 18:37: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 SAA10800 for ; Wed, 11 Feb 2004 18:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3ue-0006BU-00 for lemonade@ietf.org; Wed, 11 Feb 2004 18:37:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3ti-00061q-00 for lemonade@ietf.org; Wed, 11 Feb 2004 18:36:03 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3sr-0005rb-00 for lemonade@ietf.org; Wed, 11 Feb 2004 18:35:09 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1BNZ9NE028751 for ; Wed, 11 Feb 2004 16:35:09 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HSY00ID31IKWJ@edgemail1.Central.Sun.COM> for lemonade@ietf.org; Wed, 11 Feb 2004 16:35:09 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HSY00EUU1IHDR@mail.sun.net> for lemonade@ietf.org; Wed, 11 Feb 2004 16:35:08 -0700 (MST) Date: Wed, 11 Feb 2004 15:36:45 -0800 From: Chris Newman Subject: Re: [lemonade] Server implementors for Pull In-reply-to: To: Ted Hardie , lemonade@ietf.org Message-id: <2147483647.1076513805@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <2147483647.1076431110@nifty-jr.west.sun.com> Content-Transfer-Encoding: 7BIT 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 Ted Hardie wrote on 2/10/04 18:13 -0800: > Again, this working group is not chartered to do a cross product of every > transport > and access protocol. Nor is it chartered to change every access protocol > so there is "a simple and secure way to extract content" and "change every > submission protocol so these simple profiles can be used to assemble > messages". It's chartered to achieve forward without download. Push or > Pull, if it sets out to achieve the latter, it will fail. I don't think it > has the > expertise for that, and it certainly doesn't have the time. Our charter clearly permits us to change both IMAP and SMTP so both push and pull are clearly in scope for the charter. When evaluating the quality of the proposals, the impact on the entire suite of Internet protocols MUST be considered. So not only is this design issue in-scope, it would be irresponsible to ignore it. >> The push model requires all the work be done in the IMAP server. The IMAP >> server is more security sensitive, > > This is a critical point for me. If you are starting from the more security > sensitive point and moving forward (which PUSH does), I believe it will > be easier to achieve confidence that you have the security done to a > degree adequate to the task. Putting that same sensitivity in another > server seems like it creates a barrier to deployment. When it comes to actual implementation, the security sensitive code should be as small and isolated as possible. But an IMAP server generally has access to an entire message store, so less code in the IMAP server is better for security. Push puts _all_ the new complexity in the already complex IMAP server. > This is very useful data; thank you. If the IMAP server moves the data > quickly > from submission to an internal MTA (so that the IMAP server is not intending > to do final delivery), how much of this advantage can be retained? >From the scalability standpoint, if the data touches the disk on the IMAP server, then push loses big time on scalability. If the data doesn't touch the disk, then the IMAP server becomes an SMTP proxy. About 90% of the protocol interoperability problems in SMTP are caused by poorly implemented SMTP proxies. I can tell you from first hand experience that writing a good SMTP proxy is very hard. And this brings up another security problem with the push model. It is critical to track the IP address and timestamp of the client. So IMAP submit MUST add a received header. That makes the proxy approach even more complicated. I would estimate the amount of server code to implement the push model properly is 3-4 times the amount of code necessary to implement the pull model. The client complexity for pull is at most twice as much as push. I prefer the simpler overall solution. > Optimizing without regard for client convenience is also a mistake. It's > a balance. Actually one of the reasons I like GETURL so much is that it reduces the complexity for many IMAP clients (especially for mini clients). So the URLAUTH approach is a rather balanced proposal. The balance also must be skewed by the motivation of the implementers. Forward-without-download is a feature driven by client requirements. The clients need it and the server vendors don't. So you've got to balance the complexity in favor of the server vendors if you want it to deploy. > It's particularly critical that we understand what the client > thinks > the functionality in question is: I believe it is "access to a message store > to get something done" in both cases. The functional separation between a "message store" and a "submit server" is critically important to a well designed system. But I will admit that the widespread ignorance in the client implementer community of the value this separation provides is probably the strongest argument in favor of the push model. Sometimes it is true that good architecture has to be compromised to accommodate ignorance. But this is not one of those cases. If we standardize the pull model, it looks like we have strong buy-in from server implementers. Once the servers do it, the client vendors will follow because they need the feature. > I agree that functional separation is a desirable element of the current > architecture, and one of the reasons I have pushed for limiting the > scope is that it keeps the IMAP store out of the business of assembling > parts using other protocols. The difference I see here is that the submit > server's functional separation is also lost, in my view, and I think it is > worse because of the risk that it will start working outside the set of > mail protocols entirely. That's a "scrying game" charge, though, so I > should say simply that I agree with this point, but feel it applies equally > to both methods. The difference is the level of entanglement. In the push model, the IMAP server gets all the functionality and responsibility of a submit server in addition to its own functionality. That's a complete loss of function separation. In the pull model, both protocols retain their core functions and do not inherit any functionality from the other. The submit server simply has the additional ability to act as a very slim IMAP client (LOGIN + STARTTLS + GETURL), but the functional separation is retained. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Feb 11 19:22:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13465 for ; Wed, 11 Feb 2004 19:22: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 1Ar4c0-0007Wp-JV for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 19:21:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0LmpO028938 for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 19:21:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4c0-0007Wf-Co for lemonade-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:21: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 TAA13440 for ; Wed, 11 Feb 2004 19:21:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4by-0003ic-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:21:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4bC-0003c6-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:20:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar4aJ-0003Vi-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:20:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar4aJ-0000qb-P9 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4aI-0007Jt-4U; Wed, 11 Feb 2004 19:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4a6-0007HY-WA for lemonade@optimus.ietf.org; Wed, 11 Feb 2004 19:19: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 TAA13356 for ; Wed, 11 Feb 2004 19:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4a5-0003U5-00 for lemonade@ietf.org; Wed, 11 Feb 2004 19:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4ZF-0003Lj-00 for lemonade@ietf.org; Wed, 11 Feb 2004 19:18:58 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4YS-0003CG-00 for lemonade@ietf.org; Wed, 11 Feb 2004 19:18:08 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1C0I6vf014845; Wed, 11 Feb 2004 16:18:07 -0800 (PST) Received: from [205.214.163.27] (vpn-10-50-0-35.qualcomm.com [10.50.0.35]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1C0HxVK003248; Wed, 11 Feb 2004 16:18:00 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2147483647.1076513805@nifty-jr.west.sun.com> References: <2147483647.1076431110@nifty-jr.west.sun.com> <2147483647.1076513805@nifty-jr.west.sun.com> Date: Wed, 11 Feb 2004 16:17:58 -0800 To: Chris Newman , lemonade@ietf.org From: Ted Hardie Subject: Re: [lemonade] Server implementors for Pull 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 3:36 PM -0800 02/11/2004, Chris Newman wrote: >Ted Hardie wrote on 2/10/04 18:13 -0800: >> Again, this working group is not chartered to do a cross product of every >> transport >> and access protocol. Nor is it chartered to change every access protocol >> so there is "a simple and secure way to extract content" and "change every >> submission protocol so these simple profiles can be used to assemble >> messages". It's chartered to achieve forward without download. Push or >> Pull, if it sets out to achieve the latter, it will fail. I don't think it >> has the >> expertise for that, and it certainly doesn't have the time. > >Our charter clearly permits us to change both IMAP and SMTP so both push and >pull are clearly in scope for the charter. Yes. >When evaluating the quality of the >proposals, the impact on the entire suite of Internet protocols MUST be >considered. So not only is this design issue in-scope, it would be >irresponsible to ignore it. This is a big leap, in my opinion. Going from saying that we're chartered to consider changes to both SMTP and IMAP to saying we MUST consider changes to every transport and access protocol because there might be some reuse doesn't fly. > >> The push model requires all the work be done in the IMAP server. The IMAP >>> server is more security sensitive, >> >> This is a critical point for me. If you are starting from the more security >> sensitive point and moving forward (which PUSH does), I believe it will >> be easier to achieve confidence that you have the security done to a >> degree adequate to the task. Putting that same sensitivity in another >> server seems like it creates a barrier to deployment. > >When it comes to actual implementation, the security sensitive code should be >as small and isolated as possible. But an IMAP server generally has access to >an entire message store, so less code in the IMAP server is better for >security. Push puts _all_ the new complexity in the already complex IMAP >server. But from a "roles" perspective, the IMAP server already has the role "has access to the message store". You're assigning a new role to the SUBMIT serve in the PULL proposal. Whether it is a small amount of code or not, the security model is very different. > > This is very useful data; thank you. If the IMAP server moves the data >> quickly >> from submission to an internal MTA (so that the IMAP server is not intending > > to do final delivery), how much of this advantage can be retained? > >From the scalability standpoint, if the data touches the disk on the IMAP >server, then push loses big time on scalability. If the data >doesn't touch the >disk, then the IMAP server becomes an SMTP proxy. I'm missing something. For the case that is core to this, the IMAP server already has the data to be forwarded on disk. Are you comparing this to the case where the IMAP serve would assemble pieces that were not already at the server or provided by the client? If so, I agree that it would not be a good idea, and I've argued against its inclusion in PUSH for exactly this reason. >And this brings up another security problem with the push model. It is >critical to track the IP address and timestamp of the client. So IMAP submit >MUST add a received header. That makes the proxy approach even more >complicated. > >I would estimate the amount of server code to implement the push >model properly >is 3-4 times the amount of code necessary to implement the pull model. The >client complexity for pull is at most twice as much as push. I prefer the >simpler overall solution. I'd really like a breakdown of this. Are you counting just the code on the IMAP server? It seems to me adding the functionality of the pawn ticket code and the IMAP client code, plus the new routines needed to handle the error conditions is going to bloat SUBMIT server code pretty severely. Then we need to consider what the changes would be on the clients. I think client handling of submit+pawn ticket is a major piece of new work, since it will have to have the pawn ticket handling code built from scratch. > > Optimizing without regard for client convenience is also a mistake. It's >> a balance. > >Actually one of the reasons I like GETURL so much is that it reduces the >complexity for many IMAP clients (especially for mini clients). So >the URLAUTH >approach is a rather balanced proposal. The balance also must be >skewed by the >motivation of the implementers. Forward-without-download is a feature driven >by client requirements. The clients need it and the server vendors don't. So >you've got to balance the complexity in favor of the server vendors >if you want >it to deploy. The *users* need it. They need forward without download to work so their mail works in conditions of low bandwidth. They need both clients and servers to cooperate to get that done. And again, I see a real risk here that operators that pull will move to submit+http (or webdav), with a complete loss of interoperability with IMAP. If server vendors are sanguine about that possibility, I can't see why. > > It's particularly critical that we understand what the client >> thinks >> the functionality in question is: I believe it is "access to a >>message store >> to get something done" in both cases. > >The functional separation between a "message store" and a "submit server" is >critically important to a well designed system. But I will admit that the >widespread ignorance in the client implementer community of the value this >separation provides is probably the strongest argument in favor of the push >model. Sometimes it is true that good architecture has to be compromised to >accommodate ignorance. But this is not one of those cases. If we standardize >the pull model, it looks like we have strong buy-in from server implementers. >Once the servers do it, the client vendors will follow because they need the >feature. See above. To quote an old song "it ain't necessarily so". If you do it with PULL, you have both the risk that operators will want to use document store rather than message store access protocols and the risk that they will not deploy something with an untested security model. > > I agree that functional separation is a desirable element of the current >> architecture, and one of the reasons I have pushed for limiting the >> scope is that it keeps the IMAP store out of the business of assembling >> parts using other protocols. The difference I see here is that the submit >> server's functional separation is also lost, in my view, and I think it is >> worse because of the risk that it will start working outside the set of >> mail protocols entirely. That's a "scrying game" charge, though, so I >> should say simply that I agree with this point, but feel it applies equally >> to both methods. > >The difference is the level of entanglement. In the push model, the IMAP >server gets all the functionality and responsibility of a submit server in >addition to its own functionality. That's a complete loss of function >separation. In the pull model, both protocols retain their core functions and >do not inherit any functionality from the other. The submit server simply has >the additional ability to act as a very slim IMAP client (LOGIN + STARTTLS + >GETURL), but the functional separation is retained. > I really don't see how you can see it becoming a pull based access client, with the consequent storage and assembly problems, as not entanglement. It sure looks like it to me. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Feb 11 19:59:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15729 for ; Wed, 11 Feb 2004 19:59: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 1Ar5Bs-0001dc-AS for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 19:58:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0wqi5006290 for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 19:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Bs-0001dN-6F for lemonade-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:58:52 -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 TAA15696 for ; Wed, 11 Feb 2004 19:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Bq-0000gm-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:58:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5B1-0000aI-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:58:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5A6-0000U7-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 19:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5A5-0001V6-5S; Wed, 11 Feb 2004 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar59u-0001Ts-9E for lemonade@optimus.ietf.org; Wed, 11 Feb 2004 19:56: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 TAA15553 for ; Wed, 11 Feb 2004 19:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar59s-0000SY-00 for lemonade@ietf.org; Wed, 11 Feb 2004 19:56:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar58w-0000MD-00 for lemonade@ietf.org; Wed, 11 Feb 2004 19:55:51 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1Ar585-0000GG-00 for lemonade@ietf.org; Wed, 11 Feb 2004 19:54:57 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1C0svNE026936 for ; Wed, 11 Feb 2004 17:54:57 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HSY00IQC57KWJ@edgemail1.Central.Sun.COM> for lemonade@ietf.org; Wed, 11 Feb 2004 17:54:57 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HSY00EM857IDR@mail.sun.net> for lemonade@ietf.org; Wed, 11 Feb 2004 17:54:56 -0700 (MST) Date: Wed, 11 Feb 2004 16:56:33 -0800 From: Chris Newman Subject: Re: [lemonade] Push, I say Push, son. In-reply-to: To: Ted Hardie , lemonade@ietf.org Message-id: <2147483647.1076518593@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: Content-Transfer-Encoding: 7BIT 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 Ted Hardie wrote on 2/10/04 17:53 -0800: > I believe PUSH is a better way forward than PULL. I agree with the > points Greg has made. A few more below, but before that, an > overarching concern: > > PUSH or PULL: > > Simplify, simplify, simplify. Whatever choice this working group > makes (PUSH or PULL), it is critically important that we keep focus > and do not allow this work item to expand past our capabilities. > Getting nothing done is far worse than choosing a sub-optimal > solution. Pull is much simpler than push. I have first-hand experience writing and supporting mini IMAP clients, IMAP proxies, IMAP servers, SMTP clients, SMTP proxies and SMTP servers. Push involves putting an SMTP proxy into an IMAP server. Pull involves a very thin IMAP client in SMTP plus GETURL. My estimate is that push requires 2-3 times as much code overall than pull does and therefore pull is simpler. > In favor of PUSH: > > 1) I believe PUSH will be easier to implement and deploy in the environments > that need it most. The need we're addressing is one for clients > in limited-capacity environments. That need is real, it is a major > problem for wireless deployments today, and there is a real risk > that delay will cause the need to be met with protocols not based > in the email world at all. That's a serious risk to interoperablity, > and a serious mistake. If you are worried about imapd+sendmail, > you should also be worried about sendmail+apache, which is > a major risk of placing this burden on the submit server. You're missing the distinction between a proxy and a client. Push is a proxy problem and it's easier to link two servers than write a good proxy, thus you get uw-imapd+sendmail. Pull adds a mini URL resolution client to the submit server, so you'll get sendmail+libwww (or the equivalent). Pull is definitely easier to implement and deploy. > 2) It is relatively easy to chain this service in ways that meet common > network topologies in both wireless and enterprise environments. > Having an IMAP/submit server speak to a next hop MTA inside an > administrative boundary is relatively easy, and the next-hop > MTA can handle the majority of queueing and retransmission. Having written an SMTP proxy, I can assure you this is not "relatively easy". I'd call it subtle and challenging. > 3) IMAP's complexity has historically been made worse by > behavior variations, and it is historically the clients which > have been required to handle the majority of that variation. It is > also true that adding complexity to any service is a deterrent to > implementation and deployment. But in this case, the client's > view of this is that the functionality needed is core to the > IMAP service--it is "access to a mailstore". Rather than "download > access" to a mailstore, it is "forward access", and, from a client's > point of view, these are very strongly related sets of actions and > permissions. Shifting the actions and permissions to another > protocol which has no similar functionality is not a client-friendly > action. IMAP already provides read/write access to a mailstore with FETCH, STORE and APPEND. You are adding completely new functionality to IMAP: the ability to transfer messages to other message stores. But what you're really getting at is that client vendors see "send mail" and "read mail" as closely related functions and due to their hostility to multiple TCP connections, they want them in one protocol. But this path leads to madness. Outlook has raised the bar so the client vendors now see "send mail", "read mail", "access calendar" and "schedule calendar events" as closely related functions and due to their hostility to multiple TCP connections, they want them in one protocol. I'm told there are are deployed systems which use IMAP for calendar storage and scheduling today. While client implementer perception is one of the stronger arguments for the push model, it is not strong enough to merit a complete destruction of the functional separation we have today at the protocol level. > 4) It does not require a fundamentally new security model. While I > think URLAUTH may eventually be very useful, I have concerns both > about how it ties authorization to location and in the deployment > of a "pawn ticket" model of authorization. As it stands, this is > not just undeployed code; authorization without authentication is > not in the security lexicon of many people. Even with a great deal more > security review in the IETF, there is a serious risk that deployment would > be stalled by the unwillingness of corporations to shift away from > authentication/authorization mechanisms. You haven't been keeping up with the recent pull specs. The latest specs make "authrole=submit" mandatory to implement so we're back to a traditional authentication model, but using the signed URL to provide fine-grained authorization for the submit server. > 5) I believe PUSH avoids both some race conditions and some very > serious risks of head-of-line blocking issues; even in multithreaded > servers, a long delay in reply by a server accessed for PULL can consume > network buffers and raise the risk of a denial of service. The race condition is an issue, but I don't see it as a significant issue. MTAs already have to deal with all the buffering, blocking and denial-of-service issues when implementing SMTP. With pull, they can simply re-use the logic (which they fully understand) when implementing a tiny IMAP client. But IMAP servers don't make connections to the network (with the possible exception of login) so most IMAP implementers have never dealt with the class of denial-of-service and buffering issues they will face with the push model. They'll have to pull all the complexity and logic that's already in the SMTP servers down into the IMAP server to deal with these issues. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Wed Feb 11 20:14:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16586 for ; Wed, 11 Feb 2004 20:14:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5QT-0003Ef-Sk for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 20:13:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C1DvPX012431 for lemonade-archive@odin.ietf.org; Wed, 11 Feb 2004 20:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5QT-0003EQ-O5 for lemonade-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 20:13: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 UAA16559 for ; Wed, 11 Feb 2004 20:13:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5QR-0002Rs-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 20:13:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5PX-0002LN-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 20:13:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5OZ-0002Ej-00 for lemonade-web-archive@ietf.org; Wed, 11 Feb 2004 20:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Oa-000367-51; Wed, 11 Feb 2004 20:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5OO-00034d-6t for lemonade@optimus.ietf.org; Wed, 11 Feb 2004 20:11: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 UAA16456 for ; Wed, 11 Feb 2004 20:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5OM-0002D4-00 for lemonade@ietf.org; Wed, 11 Feb 2004 20:11:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5NY-00027N-00 for lemonade@ietf.org; Wed, 11 Feb 2004 20:10:56 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Mq-00021a-00 for lemonade@ietf.org; Wed, 11 Feb 2004 20:10:12 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1C1AAVo018384 for ; Wed, 11 Feb 2004 18:10:10 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HSY00IEM5WYWJ@edgemail1.Central.Sun.COM> for lemonade@ietf.org; Wed, 11 Feb 2004 18:10:10 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HSY00EZ15WVDR@mail.sun.net> for lemonade@ietf.org; Wed, 11 Feb 2004 18:10:10 -0700 (MST) Date: Wed, 11 Feb 2004 17:11:46 -0800 From: Chris Newman Subject: Re: [lemonade] Time to Stand up and be counted In-reply-to: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> To: "Vaudreuil, Greg M (Greg)" , lemonade@ietf.org Message-id: <2147483647.1076519506@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> Content-Transfer-Encoding: 7BIT 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 Vaudreuil, Greg M (Greg) wrote on 2/10/04 9:11 -0600: > 1) It can be implemented using an IMAP submission proxy in front of any > current IMAP server. This reduces the barrier to entry for early > deployments. Most of these proxies will have fundamental design errors. About 95% of the protocol-level interoperability problems in SMTP are caused by SMTP proxies, and that's exactly what you're proposing to write only much more complex. This will not interoperate well so I do not consider this a compelling argument for push. One of my responsibilities at work is to maintain an IMAP/POP/SMTP proxy. It consumes about 50% of my time. We regularly find new bugs and the original author of the code was an above average engineer (top 20%). The proxies I maintain go into a pure pass-through mode after authentication so they are much simpler than the proxy you're proposing to write. > 2) It simplifies the engineering of a secure submission service. I don't > need a separate DMZ-resident submission service with access to users > credentials as SMTP-Submit now requires. (I can proxy IMAP without access to > passwords to a store in a more secure zone, while I can't do that easily with > SMTP-submit) One less hole in the firewall, one less avenue for attack. This is a valid point. However, it applies only to a narrow subset of mail deployments. Most real-world deployments require SMTP AUTH to audit spamming from local users and thus already have the submit server in the DMZ. The one I'm using right now requires SSL/TLS and SMTP AUTH. > 3) It saves a network connection for the SMTP-submit, a number of > round-trips, and at least some bandwidth. While this may be of marginal > benefit in well connected environments, I find faster and cheaper to be > compelling on today's wireless data networks. (Also 1/3 fewer new > connections / flows to manage on firewalls and load-balancers also saves $$) Valid point. > 4) It seems overall simpler in avoiding the hard work of getting a > third-party trust model right. It also avoids an obvious race condition and > simplifies the logic for doing a reliable, coordinated delete from the > "outbox". This benefit is especially evident in the likely case where the > submission server and IMAP store are provided by different vendors. Yes, it _seems_ simpler. But I've thought through the code I'd have to write for push vs. pull on both client and server, and pull is significantly simpler in practice. Pull is a bit harder for the client implementer, but push is _a lot_ harder for the server implementer. > 5) It seems easier to add in other lemonade-charter items such as future > delivery with revocation. In the case of future delivery the long-term > queues and associated message data are in a single place, usually subject to > regular backups. I view the PUSH model as sharing state between submission > queues on the SMTP-Submit server and content in the IMAP store, creating > conditions where the two may easily get out-of-sync. Also, submission > servers don't typically store long-term persistent data and are rarely > backed-up. Storing long-term future-delivery queues will require adding > backup to that system as well as requiring higher availability hardware. When you lose functional separation, it is simpler to implement boundary features because you don't have to worry about functional separation any longer. But these problems can be solved while preserving functional separation and the benefits will outweigh the costs. If we dropped the distinction between TCP and IP, then HIP would be much easier to implement. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Feb 12 12:46:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04134 for ; Thu, 12 Feb 2004 12:46:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKu7-00008D-Cf for lemonade-archive@odin.ietf.org; Thu, 12 Feb 2004 12:45:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHjYbw000501 for lemonade-archive@odin.ietf.org; Thu, 12 Feb 2004 12:45:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKu6-000080-CQ for lemonade-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 12:45:34 -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 MAA04128 for ; Thu, 12 Feb 2004 12:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKu2-0006fC-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 12:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKt9-0006Y8-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 12:44:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKsa-0006RT-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 12:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKsa-0008CX-Va; Thu, 12 Feb 2004 12:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKs9-0008BO-D8 for lemonade@optimus.ietf.org; Thu, 12 Feb 2004 12:43:33 -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 MAA04021 for ; Thu, 12 Feb 2004 12:43:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKs5-0006N3-00 for lemonade@ietf.org; Thu, 12 Feb 2004 12:43:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKr1-0006FD-00 for lemonade@ietf.org; Thu, 12 Feb 2004 12:42:23 -0500 Received: from lin1.andrew.cmu.edu ([128.2.6.59]) by ietf-mx with esmtp (Exim 4.12) id 1ArKq9-00069W-00 for lemonade@ietf.org; Thu, 12 Feb 2004 12:41:29 -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 i1CHfUGv002998 for ; Thu, 12 Feb 2004 12:41:30 -0500 Date: Thu, 12 Feb 2004 12:41:31 -0500 (EST) From: Rob Siemborski X-X-Sender: rjs3@sourcefour.andrew.cmu.edu To: lemonade@ietf.org Subject: Re: [lemonade] Time to Stand up and be counted In-Reply-To: <2147483647.1076519506@nifty-jr.west.sun.com> Message-ID: References: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> <2147483647.1076519506@nifty-jr.west.sun.com> 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=AWL autolearn=no version=2.60 On Wed, 11 Feb 2004, Chris Newman wrote: > Vaudreuil, Greg M (Greg) wrote on 2/10/04 9:11 -0600: > > 1) It can be implemented using an IMAP submission proxy in front of any > > current IMAP server. This reduces the barrier to entry for early > > deployments. > > Most of these proxies will have fundamental design errors. About 95% of the > protocol-level interoperability problems in SMTP are caused by SMTP proxies, > and that's exactly what you're proposing to write only much more complex. This > will not interoperate well so I do not consider this a compelling argument for > push. I agree -- implementing a stateful IMAP proxy is a non-trivial amount of work, and even then is likely to have problems coping with the wide variety of different extensions that different backend servers implement of. > When you lose functional separation, it is simpler to implement boundary > features because you don't have to worry about functional separation any > longer. But these problems can be solved while preserving functional > separation and the benefits will outweigh the costs. > > If we dropped the distinction between TCP and IP, then HIP would be much easier > to implement. I think the functional separation argument is still the key, and is why I prefer the pull method. Both from an architectural standpoint *and* from the standpoint that IMAP is not the end-all-be-all of message retrieval protocols. It is very difficult for me to accept a proposal that throws out a longstanding separation of functionality just because it is perceived to be easier. Regardless of charter limitations, we cannot ignore the fact that IMAP is not the only message retrieval protocol and we should at least acknowledge that fact in our design. We definitely don't want to find out that we need to add SUBMIT to POP in a few years. I don't want to find out in 10 years that we've added SUBMIT to POP, NNTP, IMAP, and HTTP for whatever various reasons. Take the example of SASL -- despite being *designed* as a protocol that could be integrated in other protocols, there are a significant number of subtle difference in each application protocol that cause easily (and often) overlooked subtle problems in implementation. This is for a protocol that is *simple* compared to SUBMIT, and is *designed* to be integrated into other protocols. I don't welcome an era of a large number of subtlety different SUBMIT mechanisms. In the long run, the right answer here is to keep SUBMIT on the submission server. -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 Thu Feb 12 22:14:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05041 for ; Thu, 12 Feb 2004 22:14: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 1ArTlr-0000BO-PR for lemonade-archive@odin.ietf.org; Thu, 12 Feb 2004 22:13:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D3DdKw000698 for lemonade-archive@odin.ietf.org; Thu, 12 Feb 2004 22:13:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTlr-0000BB-Ju for lemonade-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 22:13: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 WAA05018 for ; Thu, 12 Feb 2004 22:13:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTlm-0002rF-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 22:13:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTky-0002ln-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 22:12:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArTkL-0002gh-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 22:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTkG-0008G8-OT; Thu, 12 Feb 2004 22:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTjw-0008FT-5A for lemonade@optimus.ietf.org; Thu, 12 Feb 2004 22:11:40 -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 WAA04956 for ; Thu, 12 Feb 2004 22:11:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTjr-0002eT-00 for lemonade@ietf.org; Thu, 12 Feb 2004 22:11:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTiu-0002aH-00 for lemonade@ietf.org; Thu, 12 Feb 2004 22:10:37 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ArTib-0002W7-00 for lemonade@ietf.org; Thu, 12 Feb 2004 22:10:17 -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 i1D3AIvf023283; Thu, 12 Feb 2004 19:10:18 -0800 (PST) Received: from [192.168.1.13] (vpn-10-50-0-33.qualcomm.com [10.50.0.33]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1D3ABvx002422; Thu, 12 Feb 2004 19:10:12 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2147483647.1076431110@nifty-jr.west.sun.com> <2147483647.1076513805@nifty-jr.west.sun.com> X-Mailer: Eudora for Mac OS X v6.1a Date: Thu, 12 Feb 2004 19:09:14 -0800 To: Ted Hardie , Chris Newman , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Server implementors for Pull 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 At 4:17 PM -0800 2/11/04, Ted Hardie wrote: >> When evaluating the quality of the >> proposals, the impact on the entire suite of Internet protocols MUST be >> considered. So not only is this design issue in-scope, it would be >> irresponsible to ignore it. > > This is a big leap, in my opinion. Going from saying that we're chartered > to consider changes to both SMTP and IMAP to saying we MUST > consider changes to every transport and access protocol because > there might be some reuse doesn't fly. I agree that we absolutely must limit the scope of the work we take on to the immediate problem at hand. I'd object very much if we tried to do a fully generalized split composition protocol that handled access to arbitrary data. However, I think there are two different uses of "consider" in the above quotes, and I think that may be causing some of the confusion. I agree our charter allows us to "consider" (that is, to decide to do or not to do) changes in both IMAP and SMTP/Submit. In making decisions, I agree that we need to "consider" (that is, think about the implications) of our work on other protocols and on future extensions. I'd agree that we do not want to "consider" (that, seriously consider doing) making changes to other protocols. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When we remember we are all mad, the mysteries disappear and life stands explained. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Feb 12 22:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05359 for ; Thu, 12 Feb 2004 22:27: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 1ArTyS-0000fF-BO for lemonade-archive@odin.ietf.org; Thu, 12 Feb 2004 22:26:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D3QeQA002547 for lemonade-archive@odin.ietf.org; Thu, 12 Feb 2004 22:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTyS-0000f0-7H for lemonade-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 22:26:40 -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 WAA05347 for ; Thu, 12 Feb 2004 22:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTyN-00040j-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 22:26:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTxX-0003wc-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 22:25:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArTwp-0003sG-00 for lemonade-web-archive@ietf.org; Thu, 12 Feb 2004 22:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTws-0000bU-23; Thu, 12 Feb 2004 22:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTwV-0000b0-Q9 for lemonade@optimus.ietf.org; Thu, 12 Feb 2004 22:24: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 WAA05313 for ; Thu, 12 Feb 2004 22:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTwQ-0003r0-00 for lemonade@ietf.org; Thu, 12 Feb 2004 22:24:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTvU-0003mc-00 for lemonade@ietf.org; Thu, 12 Feb 2004 22:23:36 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ArTv3-0003iG-00 for lemonade@ietf.org; Thu, 12 Feb 2004 22:23:09 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1D3NAvf023627; Thu, 12 Feb 2004 19:23:10 -0800 (PST) Received: from [192.168.1.13] (vpn-10-50-0-33.qualcomm.com [10.50.0.33]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1D3N6tR015410; Thu, 12 Feb 2004 19:23:07 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com > References: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com > X-Mailer: Eudora for Mac OS X v6.1a Date: Thu, 12 Feb 2004 19:18:51 -0800 To: "Vaudreuil, Greg M (Greg)" , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Time to Stand up and be counted 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 Even though we are only solving the forward without download problem, I think we need to think about the impact of the changes we consider. Adding message submission to IMAP has a risk of creating two divergent submission mechanisms, one for IMAP clients and one for everyone else (including POP clients, scripts, etc.) Every Submit extension would need to be replicated as an IMAP extension, and many submission-related IMAP extensions would need to be replicated in Submit. In my detailed IMAP Submit proposal I tried to avoid this by explicitly using Annotate as a pass-through mechanism for Submit extensions, thus allowing the use of arbitrary Submit extensions without the IMAP server needing to be explicitly aware of them. This does add extra complexity to the protocol, but the alternative would be far worse long-term. Even with this protection mechanism, I worry that Push would be a short-term kludge that seemed easier at the time, but would lead to long-term pain. I've seen the ill effects of layer and functional separation violations, and they can take many years to fix. The Pull model seems to me to be a cleaner approach, one in keeping with the decision to split SMTP relay from message submission, and less likely to have ill effects if or when extended in the future. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Good breeding consists in concealing how much we think of ourselves and how little we think of the other person. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 13 08:35:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08663 for ; Fri, 13 Feb 2004 08:35: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 1ArdT8-0004bt-NN for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 08:34:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDYwvR017715 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 08:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdT8-0004be-Hr for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:34: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 IAA08567 for ; Fri, 13 Feb 2004 08:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdT7-0000SE-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 08:34:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdSA-0000OG-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 08:33:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArdRF-0000K9-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 08:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdRE-0004Y7-Pc; Fri, 13 Feb 2004 08:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdQJ-0004X7-QH for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 08:32: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 IAA08522 for ; Fri, 13 Feb 2004 08:32:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdQI-0000Fu-00 for lemonade@ietf.org; Fri, 13 Feb 2004 08:32:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdPM-0000Bk-00 for lemonade@ietf.org; Fri, 13 Feb 2004 08:31:04 -0500 Received: from libertango.oryx.com ([195.30.94.163]) by ietf-mx with esmtp (Exim 4.12) id 1ArdP1-00007H-00 for lemonade@ietf.org; Fri, 13 Feb 2004 08:30:43 -0500 Message-Id: From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 13 Feb 2004 14:30:51 +0100 Subject: [lemonade] pull, please, not push. 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 Someone mentioned the other day that with push, SMTP/Submit extensions have to be mirrored in IMAP. I just realized that that, for me, settles it. With Pull, it seems likely that no IMAP extensions will be optional in the SMTP/Submit server. The puller will require some extensions and never use any others. Does that seem true to you? Looking at the IMAP extensions to date, it seems true to me. With Push, it seems likely to me that SMTP/Submit extensions will be mirrored into IMAP/Push. If that's correct, a good client has to handle the cases where an extension is present in the server(s), is present in the Submit server but not in the Push server, or is not present at all. Down that road lies client trouble and interoperability testing hell. Arnt (I hate combinatorial explosions of test cases) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 13 11:12:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17160 for ; Fri, 13 Feb 2004 11:12:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfvD-0000CP-Um for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 11:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGC7ao000757 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 11:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfvD-0000C8-Ou for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:12: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 LAA17096 for ; Fri, 13 Feb 2004 11:12:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfvD-0006EH-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 11:12:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfuG-00067g-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 11:11:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArftD-00062N-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 11:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArftB-0008CR-TN; Fri, 13 Feb 2004 11:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfsK-0008AL-AZ for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 11:09: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 LAA16959 for ; Fri, 13 Feb 2004 11:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfsH-0005yR-00 for lemonade@ietf.org; Fri, 13 Feb 2004 11:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfrP-0005un-00 for lemonade@ietf.org; Fri, 13 Feb 2004 11:08:12 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1Arfqi-0005qg-00 for lemonade@ietf.org; Fri, 13 Feb 2004 11:07:28 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1DG7Lnp001098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 08:07:21 -0800 (PST) Received: from [205.214.163.53] (vpn-10-50-16-38.qualcomm.com [10.50.16.38]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1DG7GlH010386; Fri, 13 Feb 2004 08:07:18 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Fri, 13 Feb 2004 08:07:17 -0800 To: Arnt Gulbrandsen , lemonade@ietf.org From: Ted Hardie Subject: Re: [lemonade] pull, please, not push. 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > >With Pull, it seems likely that no IMAP extensions will be optional >in the SMTP/Submit server. The puller will require some extensions >and never use any others. Does that seem true to you? Looking at the >IMAP extensions to date, it seems true to me. Frankly, it doesn't seem true to me, since there could be IMAP extensions fundamental to one set of clients using an IMAP server and out of the area of interest to another set; that certainly can be the case today. But this raises a more fundamental point, going back to the "simplify, simplify, simplify" chant I started a few days ago: any proposal is going to need to define how to pass through extensions of the other service without needing to process them or to limit very severely what extensions may be used. As Arnt points out, without that restriction you're going to end up in client hello. For Push, Randy's proposal provides a way using Annotate to accomplish this. For PULL, it seems likely to me that the strict limitation would be the better approach, so that an IMAP client built into the SUBMIT server would not have to have a negotiation burden at all. And since I haven't said it lately, just my opinion, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 13 12:43:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22464 for ; Fri, 13 Feb 2004 12:43:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhLS-0000tk-Sz for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 12:43:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHhIJY003446 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 12:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhLS-0000tV-Nz for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 12:43: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 MAA22412 for ; Fri, 13 Feb 2004 12:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhLR-0007k6-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 12:43:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhKR-0007dg-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 12:42:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArhJZ-0007Yg-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 12:41:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhJK-0000MW-Ii; Fri, 13 Feb 2004 12:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhIM-00006I-Ju for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 12:40: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 MAA22322 for ; Fri, 13 Feb 2004 12:40:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhIK-0007Sn-00 for lemonade@ietf.org; Fri, 13 Feb 2004 12:40:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhHT-0007Oq-00 for lemonade@ietf.org; Fri, 13 Feb 2004 12:39:12 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1ArhGe-0007K6-00 for lemonade@ietf.org; Fri, 13 Feb 2004 12:38:20 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout2.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1DHcAnj029116; Fri, 13 Feb 2004 09:38:11 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i1DHcAhK018134; Fri, 13 Feb 2004 09:38:10 -0800 Date: Fri, 13 Feb 2004 09:38:10 -0800 (PST) From: Mark Crispin To: Ted Hardie cc: Arnt Gulbrandsen , lemonade@ietf.org Subject: Re: [lemonade] pull, please, not push. In-Reply-To: Message-ID: References: MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 13 Feb 2004, Ted Hardie wrote: > For Push, Randy's proposal provides a way using Annotate to accomplish > this. Note that ANNOTATE is not widely deployed among IMAP servers, although in fairness ANNOTATE hasn't made it to RFC status yet. ANNOTATE is a large and complex extension. As a pre-requisite to Push, that means that Push is also a large and complex extension to IMAP. > For PULL, it seems likely to me that the strict limitation would be the > better approach, so that an IMAP client built into the SUBMIT server > would not have to have a negotiation burden at all. This is already in Pull. This is the purpose of the URLFETCH command. Pull has a (modest) advantage in that the various measures of Pull are not pre-requisities, but instead can be layered as desired. I say "modest" because most sites will probably want to deploy all of the Pull measures; and consequently I have not trumpted it. For example, no IMAP extensions are strictly needed to do Pull. URLAUTH is a convenience, to address what otherwise be unacceptable security issues in some environments. However, URLAUTH may not be necessary in a Kerberos environment within a protected zone (what is highly-inaccurately called a "DMZ"). -- 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 Feb 13 14:22:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27291 for ; Fri, 13 Feb 2004 14:22: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 1AritC-0001Im-TD for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 14:22:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJME5C004998 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 14:22:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AritC-0001IX-OH for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 14:22:14 -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 OAA27262 for ; Fri, 13 Feb 2004 14:22:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AritA-0000tW-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 14:22:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArisB-0000hV-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 14:21:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arir4-0000Tj-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 14:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arir5-000150-Q6; Fri, 13 Feb 2004 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriqL-00013s-37 for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 14:19: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 OAA26976 for ; Fri, 13 Feb 2004 14:19:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriqI-0000PG-00 for lemonade@ietf.org; Fri, 13 Feb 2004 14:19:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AripQ-0000IB-00 for lemonade@ietf.org; Fri, 13 Feb 2004 14:18:21 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1ArioP-00009d-00 for lemonade@ietf.org; Fri, 13 Feb 2004 14:17:17 -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 i1DJHBnp011705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 11:17:11 -0800 (PST) Received: from [192.168.1.13] (vpn-10-50-0-33.qualcomm.com [10.50.0.33]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1DJH5VK007959; Fri, 13 Feb 2004 11:17:08 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v6.1a Date: Fri, 13 Feb 2004 11:13:43 -0800 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] pull, please, not push. 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 With Push, the client may need arbitrary Submit extensions, and hence a pass-through mechanism is needed. This is because Submit extensions go to the fundamental use of Submit, and hence cannot be arbitrarily limited when Submit is added to IMAP. That is, by adding message submission to IMAP we are adding the entire functionality of message submission to IMAP. With Pull, the client is submitting a message and hence itself has no need of IMAP extensions. The mini-IMAP client within the Submit server is not a full IMAP client, and thus will have no use for any IMAP extensions not directly related to its task of fetching a limited and defined item. With Pull, we are not adding all of IMAP to message submission, we are only adding a very small and well-defined use of IMAP to the submission server. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- And still I persist in wondering if folly must always be man's nemesis. --Edgar Pangborn _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 13 18:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12928 for ; Fri, 13 Feb 2004 18:05:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmN5-0000Wa-W5 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 18:05:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DN5JMi002015 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 18:05:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmN5-0000WQ-Rn for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 18:05:19 -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 SAA12885 for ; Fri, 13 Feb 2004 18:05:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmN3-0006q4-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:05:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmM5-0006mr-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:04:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArmLo-0006ja-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmLp-0000CD-4R; Fri, 13 Feb 2004 18: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 1ArmLF-0008Q4-4G for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 18:03:25 -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 SAA12703 for ; Fri, 13 Feb 2004 18:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmLC-0006jF-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:03:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmKQ-0006fI-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:02:34 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ArmJr-0006ad-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:01:59 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DN17dZ018975; Fri, 13 Feb 2004 18:01:07 -0500 (EST) Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i1DN15dZ018949; Fri, 13 Feb 2004 18:01:06 -0500 (EST) Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2) id QAA27384; Fri, 13 Feb 2004 16:01:58 -0700 Message-ID: <402D5765.6040207@avaya.com> Date: Fri, 13 Feb 2004 16:01:57 -0700 From: Rick Block User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" CC: lemonade@ietf.org Subject: Re: [lemonade] Time to Stand up and be counted References: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit Content-Transfer-Encoding: 7bit Vaudreuil, Greg M (Greg) wrote: > I'd like to see all who have a stake to clearly express their views and a few lines supporting their position. A collection of such positions will help determine if we have an emerging consensus or not. I could likely live with either approach, although favor "pull" for many of the same reasons recently expressed ("push" seems to entangle current and future submit extensions; "pull" seems more generally useful). A couple of specific examples (the server I work on supports both IMAP and SMTP; it's primarily a "voicemail" server): 1) Future delivery is a voicemail concept which we've implemented in SMTP, per Greg's very own I-D. It's not obvious to me how we'd mirror this in the "push" model. 2) The imap reference part of "pull" will lead to a mechanism allowing a piece of a message to be (reasonably) securely referenced in another protocol (SMTP for the discussion at hand). We have need to allow a full desktop GUI (not what you'd normally consider a "bandwidth limited" device) the ability to direct a networked server to "play" a voice message on the phone (using, at this point, a proprietary protocol). The very same solution used to allow a submit server to "pull" content from an imap server can be used in this situation to allow the voice server to pull the content to be played on the phone (avoiding requiring the client to download the content from imap and then upload it to the voice server, sound familiar?). Pull seems simpler to me and solutions to its issues seem to apply to other problems as well. -Rick Block _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 13 18:36:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15598 for ; Fri, 13 Feb 2004 18:36:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmrD-0006CW-Go for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 18:36:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DNaRhN023832 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 18:36:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmrD-0006CI-Bn for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 18:36: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 SAA15595 for ; Fri, 13 Feb 2004 18:36:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmrA-0001gy-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmqG-0001d3-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:35:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Armpp-0001YL-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Armpq-00068N-Nn; Fri, 13 Feb 2004 18: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 1ArmpB-00067D-CE for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 18:34: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 SAA15440 for ; Fri, 13 Feb 2004 18:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Armp8-0001Uo-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmoE-0001ON-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:33:23 -0500 Received: from rembrandt.esys.ca ([198.161.92.131]) by ietf-mx with esmtp (Exim 4.12) id 1ArmnN-0001IS-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:32:30 -0500 Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i1DNVm512668; Fri, 13 Feb 2004 16:31:49 -0700 From: Steve Hole Date: Fri, 13 Feb 2004 16:32:10 -0700 To: Pete Resnick Cc: lemonade@ietf.org In-Reply-To: References: Message-ID: Priority: NORMAL X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Re: Can I offer you some lemonade? 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 On Thu, 12 Feb 2004 17:42:38 -0600 Pete Resnick =20 wrote: > Hey Steve, Hey Pete. Long time since we last talked. =20 > I don't know if you've been at all following the LEMONADE working=20 > group. We're having this big discussion about "forward without=20 > download", and it's pretty polarized. I have a lot of respect for=20 > your opinion on this sort of thing (and I think others in the IMAP=20 > community do to). I'd be interested in hearing your opinion as to=20 > whether I'm just nuts and there's really something to the argument=20 > the other side is making, or otherwise. Can I rope you in?=20 Well thank you. And yes you can. > I'll try=20 > to objectively summarize for you or point you to particular messages,=20 > even if you don't want to read the whole archive. Prior to this I had not spent any time on Lemonade. Surprise ... I=20 actually have a draft with my name on it inside. I went and read through the archive of messages starting in January. I= =20 believe that it gave me enough to go on. Nobody is nuts that I can see. It seems like a good discussion of the=20 issues and both sides have valid points. I was a little surprised that= =20 it was so polarized, but then I remembered who was participating :-) =20 You guys are all getting older, you should have mellowed somewhat by now.= =20 I'm in agreement with Chris Newman's (very well stated) position, and with Mark Crispin on this. That is, I would say that I'm a PULL guy. Several reasons have been tossed out to support either side and most of=20 them carry water even when in total contradiction. The obvious reason=20 for this is that the issue is very complex. All reasoning about charters, existing infrastructure deployments and=20 client vs. server complexity aside, the key decision criteria seems fairl= y obvious to me -- what features are offerred by the alternative approaches= .=20 I don't think that I buy into any arguments for either side that suggest= =20 one or the other is going to be more or less difficult to implement. =20 One of the reasons for this is that I have actually (to my surprise) done= =20 both of them in some form as private mechanisms. The PULL mechanism offers a better abstraction of the service that you=20 want to employ. I believe the following to be facts: 1. The abstraction of where content comes from is both complete and=20 source independent. That is, you can specify anything you want as long= =20 as it can be expressed in a URI, a mechanism to dereference the URI is=20 available in the service implementation and the resource is "visible". =20 That's nice. You'd probably want a mandatory to implement set of supported mechanisms,= =20 obviously including IMAP (and maybe only including IMAP). Good abstraction is a fundamental design goal that I rarely select=20 against. Sort of a "SHOULD" on steriods. 2. The locality within a single service means that it can be used by mor= e than just IMAP client use. Other services can then use the same facilit= y for doing other types of composition work with little or no extension. = I would think it good engineering practice to provide a general solution=20 that exceeds the requirements for which it was conceived. I'm sure that=20 there are those who will state that it opens a Pandora's box or some such= , but in practice general solutions are always better than specific ones if= =20 the development effort is within a magnitude of one another. In a twist of fate, it turns out that the work that one of my product=20 groups is doing maps quite closely (if not exactly) to the PULL=20 architecture. The product takes an XML message definition on the way into= =20 the "submit" server that is then composed into a MIME message and=20 submitted. The XML message definition supports a variety of URI schemes= =20 for identifying content within the MIME parts. Specifically: HTTP, FILE= , IMAP, a private JOBDATA scheme which references input queue (MQSeries) da= ta buffers, as well as "inline" content. The interesting thing is that the service is used by a variety of=20 applications that wish to generate structured mail messages with=20 forwarded content (Customer Service Representative web applications), as= =20 well as a dedicated IMAP mail client. This seems to be anecdotal evidence= =20 that a generalized composition facility that supports forwarding IMAP=20 stored content is both desirable and an eventuality. There are some serious issues to resolve with the PULL scheme: 1. Security. Both PUSH and PULL have this problem though and you just= =20 have to deal with forwarding credentials. I wish you great good luck in= =20 this endeavor. 2. Representation of a "message that must be filled". I did it with an= =20 XML representation of a fully secured (S/MIME) MIME structure. This=20 will have to do it somewhat differently within the constraints of MIME=20 itself. I'm sure that can be done reasonably however. Cheers. --- Steve Hole Chief Technology Officer ACI Worldwide Phone: 780-424-4922 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Fri Feb 13 18:38:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15665 for ; Fri, 13 Feb 2004 18:38:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Armt5-0006eo-TL for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 18:38:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DNcNEF025584 for lemonade-archive@odin.ietf.org; Fri, 13 Feb 2004 18:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Armt5-0006eZ-PT for lemonade-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 18:38: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 SAA15658 for ; Fri, 13 Feb 2004 18:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Armt2-0001qx-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmsB-0001nJ-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:37:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Armri-0001ib-00 for lemonade-web-archive@ietf.org; Fri, 13 Feb 2004 18:36:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Armrk-0006H8-Ms; Fri, 13 Feb 2004 18: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 1ArmrC-0006CA-3L for lemonade@optimus.ietf.org; Fri, 13 Feb 2004 18:36: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 SAA15592 for ; Fri, 13 Feb 2004 18:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Armr8-0001go-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:36:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmqE-0001cn-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:35:27 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx with esmtp (Exim 4.12) id 1Armpm-0001YF-00 for lemonade@ietf.org; Fri, 13 Feb 2004 18:34:58 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1DNYsSY020856; Fri, 13 Feb 2004 15:34:54 -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.11+UW04.02) with ESMTP id i1DNYsQa019415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Feb 2004 15:34:54 -0800 Date: Fri, 13 Feb 2004 15:34:54 -0800 (Pacific Standard Time) From: Mark Crispin To: Rick Block cc: lemonade@ietf.org Subject: Re: [lemonade] Time to Stand up and be counted In-Reply-To: <402D5765.6040207@avaya.com> Message-ID: References: <54E40201497DF142B06B27255953F7970AA25403@il0015exch007u.ih.lucent.com> <402D5765.6040207@avaya.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 13 Feb 2004, Rick Block wrote: > The very > same solution used to allow a submit server to "pull" content > from an imap server can be used in this situation to allow the > voice server to pull the content to be played on the phone > (avoiding requiring the client to download the content from > imap and then upload it to the voice server, sound familiar?). Hi Rick - Indeed, one of my considerations was to see if it would be possible to make you voicemail guys happy as a side effect. A marriage of URLAUTH and CHANNEL is not out of the question either (although they're currently not dating, they look like a hot couple just waiting to be introduced...). If there are any obvious ways to make URLAUTH friendlier to voicemail, please let me know. It'd be great to get you folks on board. -- 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 Sat Feb 14 12:17:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24386 for ; Sat, 14 Feb 2004 12:17:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3PO-0003yY-E7 for lemonade-archive@odin.ietf.org; Sat, 14 Feb 2004 12:16:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHGo0A015278 for lemonade-archive@odin.ietf.org; Sat, 14 Feb 2004 12:16:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3PO-0003yL-8V for lemonade-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 12:16: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 MAA24375 for ; Sat, 14 Feb 2004 12:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3PM-0002tr-00 for lemonade-web-archive@ietf.org; Sat, 14 Feb 2004 12:16:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3OS-0002qt-00 for lemonade-web-archive@ietf.org; Sat, 14 Feb 2004 12:15:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3Nm-0002ns-00 for lemonade-web-archive@ietf.org; Sat, 14 Feb 2004 12:15:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3Ne-0003kV-GG; Sat, 14 Feb 2004 12:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3NT-0003k0-2D for lemonade@optimus.ietf.org; Sat, 14 Feb 2004 12:14: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 MAA24331 for ; Sat, 14 Feb 2004 12:14:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3NR-0002my-00 for lemonade@ietf.org; Sat, 14 Feb 2004 12:14:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3MU-0002jq-00 for lemonade@ietf.org; Sat, 14 Feb 2004 12:13:51 -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 1As3M0-0002ed-00 for lemonade@ietf.org; Sat, 14 Feb 2004 12:13: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.3b4); Sat, 14 Feb 2004 11:12:45 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a13] Date: Sat, 14 Feb 2004 11:12:43 -0600 To: Steve Hole From: Pete Resnick Subject: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/13/04 at 4:32 PM -0700, Steve Hole wrote: >>Can I rope you in? > >Well thank you. And yes you can. Thanks for the excellent analysis. I've got a few followup questions myself. >Nobody is nuts that I can see. Well, you mean on this issue, right? :-) >I don't think that I buy into any arguments for either side that >suggest one or the other is going to be more or less difficult to >implement. One of the reasons for this is that I have actually (to >my surprise) done both of them in some form as private mechanisms. Well, that's actually good to hear. I don't know that I'm convinced, but it's at least comforting to know that we're not in trouble either way we go. >2. The locality within a single service means that it can be used by >more than just IMAP client use. Other services can then use the same >facility for doing other types of composition work with little or no >extension. I would think it good engineering practice to provide a >general solution that exceeds the requirements for which it was >conceived. [...] >This seems to be anecdotal evidence that a generalized composition >facility that supports forwarding IMAP stored content is both >desirable and an eventuality. Would your opinion of this change if the mechanism we come up with does *not* do the composition work on the PULL server? That is, one of the proposals is to do all of the composition work on the IMAP server and then PULL only completed messages from there. (Some of the reasons for this are that it provides one solution to the "save a copy of the sent message" problem and it simplifies the protocol down to handing off a single URI.) I personally like this mechanism, for either PUSH or PULL. (I did write the draft on it, so it is close to my heart. :-) ). But it does limit the flexibility of the mechanism, since it would require PULL-ing only completed messages, and that's not something you're likely to find today via HTTP, for example. Would you still be in favor of PULL if it didn't provide the composition facility on the PULL server? >There are some serious issues to resolve with the PULL scheme: > >1. Security. Both PUSH and PULL have this problem though and you >just have to deal with forwarding credentials. I wish you great good >luck in this endeavor. One of the suggestions on the list (which so far I believe) is that with PUSH, you *could* design your network such that the submit server trusts all and only submissions from the IMAP server, thereby not having to explicitly forward credentials or even provide an authentication/authorization database to the submit server, whereas with PULL you couldn't do something similar because having the IMAP server trust the submit server would mean that a compromise of the the submit server would compromise all of the data on the IMAP server. We've not had any security people comment on this to date, so maybe this is just nonsense. Are you saying you don't buy the argument? >2. Representation of a "message that must be filled". One of the PULL proposals is that the client would actually generate this on the fly, basically sending a "insert this data here into the message" command when it wants to include something external. Did you encounter some sort of problem that required having a pre-composed "message that must be filled", or was that just an implementation choice? 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 Sun Feb 15 19:35:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04512 for ; Sun, 15 Feb 2004 19:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsWiu-0001MN-AF for lemonade-archive@odin.ietf.org; Sun, 15 Feb 2004 19:34:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G0Yucc005221 for lemonade-archive@odin.ietf.org; Sun, 15 Feb 2004 19:34:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsWiu-0001M8-5D for lemonade-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 19:34:56 -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 TAA04481 for ; Sun, 15 Feb 2004 19:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsWis-0002kw-00 for lemonade-web-archive@ietf.org; Sun, 15 Feb 2004 19:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsWhx-0002h6-00 for lemonade-web-archive@ietf.org; Sun, 15 Feb 2004 19:33:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsWh7-0002cm-00 for lemonade-web-archive@ietf.org; Sun, 15 Feb 2004 19:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsWh2-0001H9-DG; Sun, 15 Feb 2004 19:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsWgA-0001GR-WB for lemonade@optimus.ietf.org; Sun, 15 Feb 2004 19:32: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 TAA04399 for ; Sun, 15 Feb 2004 19:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsWg9-0002Vs-00 for lemonade@ietf.org; Sun, 15 Feb 2004 19:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsWfB-0002QX-00 for lemonade@ietf.org; Sun, 15 Feb 2004 19:31:05 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AsWeM-0002Lt-00 for lemonade@ietf.org; Sun, 15 Feb 2004 19:30:14 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1G0U7np002027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2004 16:30:07 -0800 (PST) Received: from [192.168.1.13] (vpn-10-50-0-3.qualcomm.com [10.50.0.3]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1G0U1vx028739; Sun, 15 Feb 2004 16:30:03 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v6.1a Date: Sun, 15 Feb 2004 16:28:47 -0800 To: Pete Resnick , Steve Hole From: Randall Gellens Subject: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org 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 At 11:12 AM -0600 2/14/04, Pete Resnick wrote: > Would your opinion of this change if the mechanism we come up with > does *not* do the composition work on the PULL server? That is, one > of the proposals is to do all of the composition work on the IMAP > server and then PULL only completed messages from there. (Some of > the reasons for this are that it provides one solution to the "save > a copy of the sent message" problem and it simplifies the protocol > down to handing off a single URI.) I personally like this > mechanism, for either PUSH or PULL. (I did write the draft on it, > so it is close to my heart. :-) ). But it does limit the > flexibility of the mechanism, since it would require PULL-ing only > completed messages, and that's not something you're likely to find > today via HTTP, for example. I thought the proposal was that composition could be done on the IMAP server and then the composed message be submitted, or composition could be done during submission. That is, if the message has been composed on the IMAP server than the simplest case of external reference is used on submission (entire message in one reference), otherwise muliple references are used. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Majority: That quality that distinguishes a crime from a law. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 16 00:52:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14925 for ; Mon, 16 Feb 2004 00:52:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbg5-0002HY-2v for lemonade-archive@odin.ietf.org; Mon, 16 Feb 2004 00:52:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G5qL1M008766 for lemonade-archive@odin.ietf.org; Mon, 16 Feb 2004 00:52:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbg4-0002HJ-Sc for lemonade-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 00:52:20 -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 AAA14866 for ; Mon, 16 Feb 2004 00:52:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asbg2-0006sY-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 00:52:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asbek-0006oU-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 00:50:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asbdq-0006m2-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 00:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbdr-0002EQ-3f; Mon, 16 Feb 2004 00: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 1Asbcs-0002Cu-UN for lemonade@optimus.ietf.org; Mon, 16 Feb 2004 00:49: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 AAA14799 for ; Mon, 16 Feb 2004 00:48:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asbcq-0006ig-00 for lemonade@ietf.org; Mon, 16 Feb 2004 00:49:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asbbv-0006g9-00 for lemonade@ietf.org; Mon, 16 Feb 2004 00:48:04 -0500 Received: from rembrandt.esys.ca ([198.161.92.131]) by ietf-mx with esmtp (Exim 4.12) id 1Asbbc-0006dI-00 for lemonade@ietf.org; Mon, 16 Feb 2004 00:47:44 -0500 Received: from fermi ([24.66.6.197]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i1G5lI511449; Sun, 15 Feb 2004 22:47:18 -0700 From: Steve Hole Date: Sun, 15 Feb 2004 22:47:38 -0700 To: Pete Resnick Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org In-Reply-To: References: Message-ID: Priority: NORMAL X-Mailer: Execmail for Win32 5.1.1 Build (10) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Multipart/mixed; BOUNDARY="Part10402152247.A" 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 --Part10402152247.A Content-Type: Text/Plain; charset="us-ascii" On Sat, 14 Feb 2004 11:12:43 -0600 Pete Resnick wrote: > Would your opinion of this change if the mechanism we come up with > does *not* do the composition work on the PULL server? That is, one > of the proposals is to do all of the composition work on the IMAP > server and then PULL only completed messages from there. (Some of the > reasons for this are that it provides one solution to the "save a > copy of the sent message" problem and it simplifies the protocol down > to handing off a single URI.) I personally like this mechanism, for > either PUSH or PULL. (I did write the draft on it, so it is close to > my heart. :-) ). But it does limit the flexibility of the mechanism, > since it would require PULL-ing only completed messages, and that's > not something you're likely to find today via HTTP, for example. > > Would you still be in favor of PULL if it didn't provide the > composition facility on the PULL server? The question is "why would you limit it"? I would make it any valid URI scheme, with a mandatory to implement for the IMAP URL scheme. That way you leave it up to the implementor to decide which they will support. I'm not sure how you would advertise what was supported, but it might not matter. Any implementation worth it's salt would make such support extensible (factory) oriented so that you can switch on the scheme and try and find a suitable driver. > >There are some serious issues to resolve with the PULL scheme: > > > >1. Security. Both PUSH and PULL have this problem though and you > >just have to deal with forwarding credentials. I wish you great good > >luck in this endeavor. > > One of the suggestions on the list (which so far I believe) is that > with PUSH, you *could* design your network such that the submit > server trusts all and only submissions from the IMAP server, thereby > not having to explicitly forward credentials or even provide an > authentication/authorization database to the submit server, whereas > with PULL you couldn't do something similar because having the IMAP > server trust the submit server would mean that a compromise of the > the submit server would compromise all of the data on the IMAP > server. We've not had any security people comment on this to date, so > maybe this is just nonsense. Are you saying you don't buy the > argument? Hmm ... It is clear that you have to solve the issue of passing credentials for accessing the IMAP server from the Submit server. It is not clear that you could get around the inverse problem of passing credentials to the Submit server from the IMAP server by creating an authorization linkage between the IMAP server and the Submit server. As these things are quite likely running on separate machines, I think that you have the same problem no matter what you do. Any scheme that would require colocation of the Submit server and the IMAP server would be architecturally ill conceived. Either you have to provide for credential forwarding or proxy authentication (via SASL) in either case I would think. In either case, I'm not really in love with the security prospects. I think the idea is reasonably cool, but the security problems have always been the blocker for doing the work. I remember talking about this in the core IMAP group at least 5 years ago without any real good ideas on the security. We get around this in our implementation by using Kerberos. Difficult to mandate this level of service in a standard though. Thus the "I wish you good luck" statement. > >2. Representation of a "message that must be filled". > > One of the PULL proposals is that the client would actually generate > this on the fly, basically sending a "insert this data here into the > message" command when it wants to include something external. Did you > encounter some sort of problem that required having a pre-composed > "message that must be filled", or was that just an implementation > choice? We had a choice to provide an external composition specification or extend the MIME headers to include the external content references. In the end, it was private, more expressive and just easier to do things in XML. We weren't trying to build something that was intended for standardized use. I've attached the DTD grammar for interest sake. It's a stripped version that deals only with the message structure (822 and MIME structure oriented data) version because there are some things in the larger composition scope that have competitive significance. In the end, there really isn't anything magical. I suspect that a single new Content-{mumble} header or a variation on an existing one will suffice. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 --Part10402152247.A Content-Type: Application/Octet-Stream; name="rfc822_msg.dtd" Content-Disposition: attachment; filename="rfc822_msg.dtd" Content-Transfer-Encoding: base64 PCEtLSBNT0RVTEU6IFJGQzgyMiBtZXNzYWdlIHNwZWNpZmljYXRpb24gZG9j dW1lbnQgdHlwZSBkZWZpbml0aW9uIC0tPg0KDQo8IS0tIENPUFlSSUdIVA0K JFJDU2ZpbGU6IHJmYzgyMl9tc2cuZHRkLHYgJA0KJFJldmlzaW9uOiAxLjE1 ICQNCiREYXRlOiAyMDAzLzAzLzIwIDE3OjMyOjAyICQNCiRBdXRob3I6IGpw cyAkDQoNCkNvcHlyaWdodCAoYykgMjAwMSBNZXNzYWdpbmdEaXJlY3QgTGlt aXRlZCwgRWRtb250b24sIENhbmFkYQ0KQWxsIHJpZ2h0cyByZXNlcnZlZC4N CiANCkFjcXVpc2l0aW9uIGFuZCB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSBhbmQg cmVsYXRlZCBtYXRlcmlhbHMgZm9yIGFueQ0KcHVycG9zZSByZXF1aXJlcyBh IHdyaXR0ZW4gbGljZW5zZSBhZ3JlZW1lbnQgZnJvbSBNZXNzYWdpbmdEaXJl Y3QgTGltaXRlZCwNCm9yIGEgd3JpdHRlbiBsaWNlbnNlIGZyb20gYW4gb3Jn YW5pemF0aW9uIGxpY2Vuc2VkIGJ5IE1lc3NhZ2luZ0RpcmVjdCBMaW1pdGVk DQp0byBncmFudCBzdWNoIGEgbGljZW5zZS4NCkVORCBDT1BZUklHSFQgLS0+ DQoNCjwhLS0gT1ZFUlZJRVc6IA0KVjEuMA0KDQpUaGlzIGRvY3VtZW50IHR5 cGUgZGVmaW5lcyBhIGRhdGEgcmVwcmVzZW50YXRpb24gZm9yIGFuIFJGQzgy MiBtZXNzYWdlDQp3aXRoIE1JTUUgY29udGVudC4gIFRoZSBzcGVjaWZpY2F0 aW9uIGlzIGRlc2lnbmVkIHRvIHJlcHJlc2VudCB0aGUNCnN0cnVjdHVyZSBv ZiBhIG1lc3NhZ2UgaW5jbHVkaW5nIHRoZSBlbnZlbG9wZSBhbmQgdGhlIGJv ZHkgb2YgdGhlDQptZXNzYWdlLg0KRU5EIE9WRVJWSUVXIC0tPg0KDQo8IS0t IEhJU1RPUlkNCkNyZWF0ZWQgTWFyIDEsIDIwMDEgYnkgc2g6DQpFTkQgSElT VE9SWSAtLT4NCg0KPCEtLSBQVUJMSUMgREVQRU5ERU5DSUVTIC0tPg0KPCFF TlRJVFkgJSBtaW1lX29iamVjdCBTWVNURU0gIm1pbWVfb2JqZWN0LmR0ZCI+ DQolbWltZV9vYmplY3Q7DQo8IS0tIEVORCBQVUJMSUMgREVQRU5ERU5DSUVT IC0tPg0KDQo8IS0tIFBSSVZBVEUgREVQRU5ERU5DSUVTIC0tPg0KPCFFTlRJ VFkgJSBib29sZWFuX2VudW0gIih0cnVlIHwgZmFsc2UpIj4NCjwhLS0gRU5E IFBSSVZBVEUgREVQRU5ERU5DSUVTIC0tPg0KDQo8IS0tIG1lc3NhZ2U6ICAN Cg0KVGhpcyBlbGVtZW50IGRlZmluZXMgdGhlIGVudmVsb3BlIGFuZCBib2R5 IGNvbnRlbnRzIGZvciBhbiBSRkM4MjIgbWVzc2FnZS4gIEl0DQppcyBhIHN0 cnVjdHVyZWQgZWxlbWVudCB3aXRoIGEgbWFuZGF0b3J5ICJlbnZlbG9wZSIg YW5kICJib2R5IiBlbGVtZW50IGJlbG93DQppdC4gIEl0IGFsc28gY29udGFp bnMgYSBudW1iZXIgb2YgYXR0cmlidXRlcyB0aGF0IHByb3ZpZGUgb3V0cHV0 IHJ1bGVzIGZvciB0aGUNCm1lc3NhZ2Ugd2hlbiBpdCBpcyBnZW5lcmF0ZWQu DQoNCi0tPg0KDQo8IUVMRU1FTlQgbWVzc2FnZSAoDQogICAgZW52ZWxvcGUs DQogICAgYm9keQ0KKT4NCg0KPCEtLSBtZXNzYWdlIEF0dHJpYnV0ZXMNCg0K cHJpb3JpdHk6DQoNClRoaXMgYXR0cmlidXRlIHNldHMgdGhlIHByaW9yaXR5 IGxldmVsIGZvciB0aGUgbWVzc2FnZS4gIEEgbWFpbCB1c2VyIGFnZW50IGNh bg0KdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYWx0ZXIgdGhlIGRpc3BsYXkg b2YgdGhlIG1lc3NhZ2UgdG8gdGhlIHJlY2lwaWVudC4gIEl0DQppcyBwdXJl bHkgYWR2aXNvcnkgYW5kIG1heSBiZSBpZ25vcmVkIGVudGlyZWx5IGJ5IHRo ZSByZWNlaXZpbmcgYWdlbnQgc29mdHdhcmUuDQoNCnJlYWRfcmVjZWlwdDoN Cg0KSWYgdGhpcyBhdHRyaWJ1dGUncyB2YWx1ZSBpcyAidHJ1ZSIgdGhlbiB0 aGUgb3V0Z29pbmcgbWVzc2FnZSB3aWxsIGNvbnRhaW4gYQ0KcmVhZCByZWNl aXB0IHJlcXVlc3QuICBUaGlzIGlzIGEgcmVxdWVzdCB0aGF0IGEgTWVzc2Fn ZSBEaXNwb3NpdGlvbiBOb3RpZmljYXRpb24NCihNRE4pIGJlIGdlbmVyYXRl ZCBieSB0aGUgcmVjZWl2aW5nIG1haWwgYWdlbnQgd2hlbiB0aGUgbWVzc2Fn ZSBpcyBwcmVzZW50ZWQgdG8gdGhlDQpyZWNpcGllbnQgZm9yIHZpZXdpbmcu ICBNYWlsIHVzZXIgYWdlbnRzIGFyZSBub3QgcmVxdWlyZWQgdG8gb2JleSB0 aGlzIHJlcXVlc3QNCmFuZCB3aGlsZSBtb3N0IGhhdmUgdGhlIGNhcGFiaWxp dHkgb2YgcmV0dXJuaW5nIHRoZSBNRE4gbWFueSBvZiB0aGVtIGNhbiBiZQ0K Y29uZmlndXJlZCB0byBpZ25vcmUgdGhlIHJlcXVlc3QuDQoNCnNlY3VyaXR5 X2Zvcm1hdDoNCg0KVGhpcyBhdHRyaWJ1dGUgc3BlY2lmaWVzIHRoZSBwcmlt YXJ5IHNlY3VyaXR5IGZvcm1hdCBmb3IgdGhlIG1lc3NhZ2UuICBUaGlzIG1h eQ0KYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBwYXNzd29yZCBl bmNyeXB0aW9uIGNhcGFiaWxpdGllcyBkZXNjcmliZWQNCmxhdGVyLiAgVGhl cmUgYXJlIHR3byBtZXNzYWdlIHNlY3VyaXR5IGZvcm1hdHM6ICdzbWltZScg YW5kICdwZ3BtaW1lJy4gIFRoZQ0KcHJvZ3JhbSBwcm9jZXNzaW5nIHRoaXMg bWVzc2FnZSBkZXNjcmlwdGlvbiBtdXN0IGFsc28gaGF2ZSB0aGUgcmVxdWly ZWQNCnNlY3VyaXR5IHBsdWdpbiBmb3IgdGhlIHJlcXVlc3RlZCBmb3JtYXQu ICBBdCB0aGUgdGltZSB0aGlzIHdhcyB3cml0dGVuIG1nZW4NCm9ubHkgc3Vw cG9ydGVkICdzbWltZScuDQoNCnNpZ246DQoNCkFuIGF0dHJpYnV0ZSB2YWx1 ZSBvZiAidHJ1ZSIgcmVxdWVzdHMgdGhhdCB0aGUgb3V0cHV0IG1lc3NhZ2Ug YmUgZGlnaXRhbGx5DQpzaWduZWQgaW4gdGhlIHNlY3VyaXR5IGZvcm1hdCBy ZXF1ZXN0ZWQuICBUaGUgZGVmYXVsdCB2YWx1ZSAiZmFsc2UiIGluZGljYXRl cw0KbWVzc2FnZSB3aWxsIG5vdCBiZSBzaWduZWQuDQoNCmVuY3J5cHQ6DQoN CkFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiAidHJ1ZSIgcmVxdWVzdHMgdGhhdCB0 aGUgb3V0cHV0IG1lc3NhZ2UgYmUgZW5jcnlwdGVkIGluDQp0aGUgc2VjdXJp dHkgZm9ybWF0IHJlcXVlc3RlZC4gIEEgZGVmYXVsdCB2YWx1ZSBvZiAiZmFs c2UiIGluZGljYXRlcyBtZXNzYWdlDQp3aWxsIG5v dCBiZSBlbmNyeXB0ZWQuDQoNCmVuY3J5cHRfYWxnOg0KDQpTZWN1cml0eSBm b3JtYXRzIGJhc2VkIG9uIHB1YmxpYyBrZXkgdGVjaG5vbG9naWVzIGdlbmVy YWxseSB1c2UgYSBzeW1tZXRyaWMNCmVuY3J5cHRpb24gYWxnb3JpdGhtIA0K DQogICJkZWZhdWx0IiAtIGluZGljYXRlcyB0aGF0IHRoZSBjdXJyZW50IGRl ZmF1bHQgb2YgcmMyX2NiY18xMjhfYml0Lg0KDQpPdGhlciB2YWx1ZXMgZW5h YmxlIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBhbGdvcml0aG1zOiANCiAgICJy YzIiIC0gcmVmZXJzIHRvIHRoZSByYzIgYWxnb3JpdGhtIGZyb20gUlNBDQog ICAiM2RlcyIgLSBpbmRpY2F0ZXMgdHJpcGxlLWRlczsgDQogICAiY2JjIiAt IHNpZ25hbHMgdGhlIHVzZSBvZiBjaXBoZXIgYmxvY2sgY2hhaW5pbmcNCg0K VGhlIGJpdCBzaXplIGluZGljYXRlcyB0aGUgcmF3IHNpemUgb2YgdGhlIHN5 bW1ldHJpY2FsIGtleSB1c2VkLg0KDQpleF9zaWduX29wYXF1ZTogDQoNClMv TUlNRSBzdXBwb3J0cyBib3RoIGNsZWFyIGFuZCBvcGFxdWUgc2lnbmVkIG1l c3NhZ2VzLiAgVGhpcyBhdHRyaWJ1dGUgYWxsb3dzDQp5b3UgdG8gc2VsZWN0 IG9wYXF1ZSBzaWduYXR1cmVzIHdpdGggYSB2YWx1ZSBvZiAidHJ1ZSIuICBU aGUgZGVmYXVsdCB2YWx1ZSBvZg0KImZhbHNlIiBkZW5vdGVzIGNsZWFyIHNp Z25pbmcuDQoNClRoaXMgYXR0cmlidXRlIG9ubHkgYXBwbGllcyBpZiB0aGUg c2lnbiBhdHRyaWJ1dGUgaXMgJ3RydWUnIGFuZCB0aGUNCnNlY3VyaXR5X2Zv cm1hdCBpcyAnc21pbWUnLg0KDQpleF9wYXNzd29yZF9lbmM6IA0KDQpJZiB0 aGlzIGF0dHJpYnV0ZSBpcyBzZXQgdG8gInRydWUiIHRoZW4gcGFzc3dvcmQg YmFzZWQgZW5jcnlwdGlvbiB3aWxsIGJlDQphcHBsaWVkIHRvIHRoZSBtZXNz YWdlLiAgVGhpcyBjYW4gYmUgZG9uZSBpbiBhZGRpdGlvbiB0byBvciBpbnN0 ZWFkIG9mIHRoZSBwcmltYXJ5DQpzZWN1cml0eSBmb3JtYXQncyBlbmNyeXB0 aW9uIGFuZCBjYW4gYmUgY29tYmluZWQgd2l0aCBzaWduaW5nLg0KDQpQYXNz d29yZCBlbmNyeXB0aW9uIGlzIGFsd2F5cyBhcHBsaWVkIGZpcnN0LiAgVGhp cyBsZWF2ZXMgdGhlIHByaW1hcnkNCmVuY3J5cHRpb24gYW5kIHNpZ25pbmcg YXMgdGhlIG91dGVybW9zdCBzZWN1cml0eSB3cmFwcGVyLg0KDQpleF9wYXNz d29yZDogDQoNClRoZSBhY3R1YWwgcGFzc3dvcmQgdXNlZCB0byBwYXNzd29y ZC1lbmNyeXB0IHRoZSBtZXNzYWdlLiAgVGhpcyBwYXNzd29yZCBtYXkNCmFs cmVhZHkgYmUgaGFzaGVkLiAgSWYgdGhpcyBpcyB0aGUgY2FzZSB0aGVuIHlv dSBtdXN0IHNwZWNpZnkgd2hpY2ggaGFzaA0KYWxnb3JpdGhtIHdhcyB1c2Vk LiAgVGhpcyBpcyBkb25lIHRocm91Z2ggdGhlIGV4X3Bhc3N3b3JkX2hhc2hf YWxnIGF0dHJpYnV0ZS4NCg0KZXhfcGFzc3dvcmRfaGFzaF9hbGc6IA0KDQpU aGlzIGF0dHJpYnV0ZSBuYW1lcyB0aGUgaGFzaCBhbGdvcml0aG0gd2hpY2gg d2FzIGFwcGxpZWQgdG8gdGhlIGV4X3Bhc3N3b3JkDQphdHRyaWJ1dGUgdmFs dWUuICBUaGlzIGFsZ29yaXRobSBpcyBwYXNzZWQgdGhyb3VnaCB0aGUgY29u dGVudCBoZWFkZXJzIG9mIHRoZQ0KcGFzc3dvcmQtZW5jcnlwdGVkIHBhcnQg dG8gZW5hYmxlIGEgcmVjZWl2ZXIgdG8gcmVjcmVhdGUgdGhlDQpwYXNzd29y ZC1lbmNyeXB0aW9uIGtleSBmcm9tIGEgcGFzc3dvcmQgYW5kIGRlY3J5cHQg dGhlIG1lc3NhZ2UuICBUbyBlbnN1cmUNCnRoYXQgdGhlIHJlc3VsdGluZyBo YXNoZXMgYXJlIFhNTCBzYWZlIHRoZXkgbXVzdCBhbHNvIGJlIEJhc2U2NCBl bmNvZGVkIGJlZm9yZQ0KdGhleSBhcmUgcGxhY2VkIGluIHRoZSBleF9wYXNz d29yZCBhdHRyaWJ1dGUuDQoNCmV4X3Bhc3N3b3JkX2FsZzogDQoNClRoZXJl IGFyZSBudW1lcm91cyBzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbGdvcml0aG1z IHN1cHBvcnRlZCBmb3IgcGFzc3dvcmQNCmVuY3J5cHRpb246DQoNCiAgICAg ZGVzICAgICAgOiA1NiBiaXQga2V5IERFUyBlbmNyeXB0aW9uDQogICAgIGRl c19lZGUgIDoxMTIgYml0IGtleSBlZGUgREVTIGVuY3J5cHRpb24NCiAgICAg ZGVzX2VkZTMgOjE2OCBiaXQga2V5IGVkZSBERVMgZW5jcnlwdGlvbg0KICAg ICBpZGVhICAgICA6MTI4IGJpdCBrZXkgSURFQSBlbmNyeXB0aW9uDQogICAg IHJjMiAgICAgIDoxMjggYml0IGtleSBSQzIgZW5jcnlwdGlvbg0KICAgICBi ZiAgICAgICA6MTI4IGJpdCBrZXkgQmxvd2Zpc2ggZW5jcnlwdGlvbg0KICAg ICByYzQgICAgICA6MTI4IGJpdCBrZXkgUkM0IGVuY3J5cHRpb24NCiAgICAg Y2FzdDUgICAgOjEyOCBiaXQga2V5IENBU1Q1IGVuY3J5cHRpb24NCiAgICAg cmM1ICAgICAgOjEyOCBiaXQga2V5IFJDNSBlbmNyeXB0aW9uDQoNCiAgICAg QWxzbyBub3RlIHRoZSBmb2xsb3dpbmcgc2hvcnQtaGFuZHM6DQoNCiAgICAg LWRlcyAgKGRlcy1jYmMpDQogICAgIC1kZXN4IChub25lKQ0KICAgICAtZGVz MyAoZGVzLWVkZTMtY2JjKQ0KICAgICAtaWRlYSAoaWRlYS1jYmMpDQogICAg IC1yYzIgIChyYzItY2JjKQ0KICAgICAtYmYgICAoYmYtY2JjKQ0KICAgICAt Y2FzdCAoY2FzdDUtY2JjKQ0KICAgICAtcmM1ICAocmM1LWNiYykNCg0KICAg ICBUaGUgZGVmYXVsdCBpcyBiZi1jYmMuIA0KDQpleF9wYXNzd29yZF92ZXJz aW9uOg0KDQpUaGlzIGluZGljYXRlcyB0aGUgdmVyc2lvbiBvZiB0aGUgcGFz c3dvcmQgZW5jcnlwdGlvbiBmb3JtYXQgdXNlZC4gIEl0DQptYXkgYmUgdXNl ZnVsIGluIHRoZSBmdXR1cmUgdG8gZW1pdCB2ZXJzaW9ucyBvZiBwYXNzd29y ZCBlbmNyeXB0aW9uDQpmb3JtYXQgdG8gZW5zdXJlIGludGVyb3Agd2l0aCBw cmV2aW91c2x5IGRlcGxveWVkIHZlcnNpb25zIG9mDQpTZWN1cmVWaWV3LCBm b3IgaW5zdGFuY2UuICBSaWdodCBub3cgdGhlcmUgaXMgb25seSBvbmUgdmVy c2lvbiBzdXBwb3J0ZWQgYW5kIGl0DQppcyB0aGUgZGVmYXVsdC4NCg0KSW4g dGhlIGZ1dHVyZSB0byBlbmdhZ2UgYSBwYXJ0aWN1 bGFyIHZlcnNpb24geW91IHdvdWxkIHB1dCB0aGUgdmVyc2lvbiBzdHJpbmcN CmluIHRoaXMgYXR0cmlidXRlLiAgVG8gZGVub3RlIHRoZSBkZWZhdWx0IHZl cnNpb24gdXNlIHRoZSB2ZXJzaW9uIHN0cmluZyAnMCcgb3INCmxlYXZlIG91 dCB0aGUgYXR0cmlidXRlIGVudGlyZWx5Lg0KDQpUbyB1c2UgdGhlIGRlZmF1 bHQgdmVyc2lvbiBvZiBwYXNzd29yZCBlbmNyeXB0aW9uLCBkb24ndCBwYXNz IGEgdmFsdWUgaW4NCnRoaXMgZmllbGQsIG9yIGFsdGVybmF0aXZlbHkgcGFz cyAnMCcgaW4gdGhlIGZpZWxkLg0KDQpleF9wYXNzd29yZF9lbmNyeXB0b3IN Cg0KVGhpcyBzdHJpbmcgaW5kaWNhdGVzIHRoZSBpZGVudGl0eSBvZiB0aGUg ZW5jcnlwdG9yLCBjb21tYSBkZWxpbWl0ZWQuICANClNlY3VyZVZpZXcgd2ls bCBzdWJzdGl0dXRlIG5ld2xpbmVzIGZvciBjb21tYXMgYW5kIGRpc3BsYXkg dGhpcyANCmlkZW50aXR5IG9uIHRoZSBwYXNzd29yZCBlbnRyeSBzY3JlZW4u DQoNCmV4X3Bhc3N3b3JkX2hpbnQNCg0KVGhpcyBzdHJpbmcgaXMgYSBwYXNz d29yZCBoaW50LiAgVGhpcyBzdHJpbmcgZGlzcGxheXMgaW4gcHJveGltaXR5 IHRvIHRoZQ0KcGFzc3dvcmQgZW50cnkgYmxhbmsgaW4gU2VjdXJlVmlldyB0 byByZW1pbmQgdGhlIHVzZXIgb2YgdGhlIHBhc3N3b3JkLg0KDQpleF9jcnlw dG9fZmlsZW5hbWVfYmFzZQ0KDQpUeXBpY2FsbHkgd2l0aCBzL21pbWUgZW5j cnlwdGlvbiwgdGhlIGVuY3J5cHRlZCBwYXJ0cyBvZiB0aGUgbWVzc2FnZSBh cmUNCnJlcHJlc2VudGVkIHdpdGggdGhlIGZpbGVuYW1lICdzbWltZS5wN20n IGFuZCB3aXRoIHBhc3N3b3JkIGVuY3J5cHRpb24NCmFzICdwYXNzLmFwYS4n DQoNClRoaXMgb3B0aW9uIHN1YnN0aXR1dGVzIHRoZSBzdXBwbGllZCBzdHJp bmcgZm9yIHRoZSBiYXNlIHBhcnQgb2YgdGhlDQpmaWxlbmFtZSwga2VlcGlu ZyB0aGUgZXh0ZW5zaW9uIGFzIGlzLg0KDQoNCi0tPg0KDQoNCjwhQVRUTElT VCBtZXNzYWdlDQogICAgcHJpb3JpdHkgKGxvdyB8IG5vcm1hbCB8IGhpZ2gp ICJub3JtYWwiDQogICAgcmVhZF9yZWNlaXB0ICVib29sZWFuX2VudW07ICJm YWxzZSINCg0KICAgIHNlY3VyaXR5X2Zvcm1hdCAoc21pbWUgfCBwZ3BtaW1l KSAic21pbWUiDQogICAgc2lnbiAgICAlYm9vbGVhbl9lbnVtOyAiZmFsc2Ui DQogICAgZW5jcnlwdCAlYm9vbGVhbl9lbnVtOyAiZmFsc2UiDQogICAgZW5j cnlwdF9hbGcgKCBkZWZhdWx0IHwgDQogICAgICAgICAgICAgICAgICByYzJf Y2JjXzQwX2JpdCB8IA0KICAgICAgICAgICAgICAgICAgcmMyX2NiY18xMjhf Yml0IHwNCiAgICAgICAgICAgICAgICAgIDNkZXNfY2JjX2VkZV8xNjhfYml0 ICkgImRlZmF1bHQiDQogICAgZXhfc2lnbl9vcGFxdWUgJWJvb2xlYW5fZW51 bTsgImZhbHNlIg0KDQogICAgZXhfcGFzc3dvcmRfZW5jICVib29sZWFuX2Vu dW07ICJmYWxzZSINCiAgICBleF9wYXNzd29yZCBDREFUQSAjSU1QTElFRA0K ICAgIGV4X3Bhc3N3b3JkX2hhc2hfYWxnICggbm9uZSB8IG1kNSB8IHNoYTEg KSAibm9uZSINCg0KICAgIGV4X3Bhc3N3b3JkX2FsZyAoIG5vbmUgfA0KICAg ICAgZGVzLWVjYiB8IGRlcy1jYmMgfCBkZXMtY2ZiIHwgZGVzLW9mYiB8IGRl cyB8IA0KICAgICAgZGVzLWVkZSB8IGRlcy1lZGUtY2JjIHwgZGVzLWVkZS1j ZmIgfCBkZXMtZWRlLW9mYiB8IGRlc3ggfA0KICAgICAgZGVzLWVkZTMgfCBk ZXMtZWRlMy1jYmMgfCBkZXMtZWRlMy1jZmIgfCBkZXMtZWRlMy1vZmIgfCBk ZXMzIHwNCiAgICAgIGlkZWEtZWNiIHwgaWRlYS1jYmMgfCBpZGVhLWNmYiB8 IGlkZWEtb2ZiIHwgaWRlYSB8DQogICAgICByYzItZWNiIHwgcmMyLWNiYyB8 IHJjMi1jZmIgfCByYzItb2ZiIHwgcmMyIHwNCiAgICAgIGJmLWVjYiB8IGJm LWNiYyB8IGJmLWNmYiB8IGJmLW9mYiB8IGJmIHwNCiAgICAgIGNhc3Q1LWVj YiB8IGNhc3Q1LWNiYyB8IGNhc3Q1LWNmYiB8IGNhc3Q1LW9mYiB8IGNhc3Qg fA0KICAgICAgcmM1LWVjYiB8IHJjNS1jYmMgfCByYzUtY2ZiIHwgcmM1LW9m YiB8IHJjNSApIA0KICAgICAgImJmLWNiYyINCg0KICAgIGV4X3Bhc3N3b3Jk X3ZlcnNpb24gQ0RBVEEgIjAiDQogICAgZXhfcGFzc3dvcmRfZW5jcnlwdG9y IENEQVRBICNJTVBMSUVEDQogICAgZXhfcGFzc3dvcmRfaGludCBDREFUQSAj SU1QTElFRA0KICAgIGV4X2NyeXB0b19maWxlbmFtZV9iYXNlIENEQVRBICNJ TVBMSUVEDQo+DQoNCg0KPCEtLSBlbnZlbG9wZQ0KDQpUaGlzIGRlZmluZXMg dGhlIHNldCBvZiBoZWFkZXJzIHRoYXQgYXJlIGluY2x1ZGVkIGluIHRoZSBv dXRwdXQgUkZDODIyIG1lc3NhZ2UuDQpJdCBpcyBhIHN0cnVjdHVyZWQgZWxl bWVudCB3aXRoIGEgbWFuZGF0b3J5IGFuZCBvcHRpb25hbCBzZXQgb2YgImhl YWRlciINCmVsZW1lbnRzIGJlbG93IGl0LiAgSXQgTVVTVCBoYXZlIHRoZSBm b2xsb3dpbmcgbWluaW1hbCBoZWFkZXJzOg0KDQogICAgICogdG8NCiAgICAg KiBmcm9tDQoNCkFueSBvdGhlciB2YWxpZCBSRkM4MjIgaGVhZGVyLCBpbmNs dWRpbmcgZXhwZXJpbWVudGFsIFgtIGhlYWRlcnMgbWF5IGJlDQppbmNsdWRl ZC4gIFRoZSBlbnZlbG9wZSBlbGVtZW50IGhhcyBubyBhdHRyaWJ1dGVzLg0K DQotLT4NCg0KPCFFTEVNRU5UIGVudmVsb3BlIChoZWFkZXIpKyA+DQoNCg0K PCEtLSBoZWFkZXIgDQoNClJGQzgyMiBoZWFkZXJzIGFyZSBzdHJpbmdzIHRo YXQgYXJlIG9uZSBvZiB0d28gdHlwZXM6DQoNCjEuIGFuIFJGQzgyMiBhZGRy ZXNzIA0KMi4gYSBzdHJpbmcuICANCg0KQWRkcmVzcyBoZWFkZXJzIE1VU1Qg Y29uZm9ybSB0byB0aGUgc3ludGF4IHNwZWNpZmllZCBpbiBSRkMyODIyIHdp dGggdGhlDQpleGNlcHRpb24gdGhhdCA4IGJpdCBkYXRhIGNhbiBiZSBwYXNz ZWQgZGlyZWN0bHkgaW4gYWxsIHBhcnRzIGV4Y2VwdCBmb3IgdGhlDQphZGRy c3BlYy4gIFRoZSBhcHBsaWNhdGlvbiB0aGF0IGdlbmVyYXRlcyB0aGUgUkZD ODIyIGhlYWRlciBpbnRvIHRoZSBvdXRwdXQNCm1l c3NhZ2Ugd2lsbCBlbmNvZGUgYWxsIGNoYXJhY3RlciBzZXQgY29udGVudCBh Y2NvcmRpbmcgdG8gdGhlIGNoYXJzZXQNCmF0dHJpYnV0ZS4gIC0tPg0KDQo8 IUVMRU1FTlQgaGVhZGVyICgjUENEQVRBKSA+DQoNCg0KPCEtLSBoZWFkZXIg QXR0cmlidXRlcw0KDQpuYW1lOg0KDQpUaGUgbmFtZSBvZiB0aGUgaGVhZGVy LiAgVGhpcyBhdHRyaWJ1dGUgTVVTVCBiZSBwcm92aWRlZC4NCg0KZHNuX3Jl cXVlc3Q6DQoNCklmIHRoZSB2YWx1ZSBvZiB0aGUgYXR0cmlidXRlIGlzICJ0 cnVlIiBBTkQgdGhlIGhlYWRlciBpcyBvbmUgb2YgdG8sIGNjLCBvciBiY2MN CihhIHJlY2lwaWVudCBhZGRyZXNzIGhlYWRlciksIHRoZW4gcG9zaXRpdmUg ZGVsaXZlcnkgc3RhdHVzIG5vdGlmaWNhdGlvbnMgd2lsbA0KYmUgcmVxdWVz dGVkIGZvciB0aGlzIGFkZHJlc3MuDQoNCmNoYXJzZXQ6DQoNCkNoYXJhY3Rl ciBzZXQgZm9yIHRoZSBoZWFkZXIgdmFsdWUuICBUaGlzIGRpcmVjdHMgdGhl IGdlbmVyYXRpbmcgYXBwbGljYXRpb24sDQppZiBuZWNlc3NhcnksIHRvIGxh YmVsIGFueSA4IGJpdCBoZWFkZXIgY29udGVudCB3aXRoIGEgcGFydGljdWxh ciBjaGFyYWN0ZXINCnNldC4gIElmIHRoaXMgYXR0cmlidXRlIGlzIG5vdCBw cmVzZW50LCBhbmQgdGhlcmUgaXMgbm9uLWFzY2lpICg3IGJpdCkgZGF0YSBp bg0KdGhlIGhlYWRlciBzdHJpbmcsIGl0IHdpbGwgYmUgbGFiZWxsZWQgd2l0 aCBhIGRlZmF1bHQgY2hhcmFjdGVyIHNldCBkZXRlcm1pbmVkDQpieSB0aGUg Z2VuZXJhdGluZyBhcHBsaWNhdGlvbidzIGN1cnJlbnQgbG9jYWxlIHNldHRp bmcuDQoNCi0tPg0KDQo8IUFUVExJU1QgaGVhZGVyDQogICAgbmFtZSBDREFU QSAjUkVRVUlSRUQNCiAgICBkc25fcmVxdWVzdCAlYm9vbGVhbl9lbnVtOyAi ZmFsc2UiDQogICAgY2hhcnNldCBDREFUQSAjSU1QTElFRA0KPg0KDQo8IS0t IGJvZHkNCg0KUkZDODIyIGJvZHkgc3BlY2lmaWNhdGlvbi4gIFJGQzgyMiBi b2RpZXMgY2FuIGJlIG9uZSBvZiB0d28gdHlwZXMuICBFaXRoZXIgdGhlDQpi b2R5IGlzIHVuc3RydWN0dXJlZCwgdW50eXBlZCB0ZXh0LCBvciBpdCBpcyBh IE1JTUUgYm9keSBwYXJ0IGFzIHNwZWNpZmllZCBieQ0KUkZDMjA0NS4gIE1J TUUgYm9kaWVzIGFyZSBkZWZpbmVkIGluIHRoZSBNSU1FIG9iamVjdCBzcGVj aWZpY2F0aW9uIGluDQptaW1lX29iamVjdC5kdGQuICBUaGUgdG9wIGxldmVs IGVsZW1lbnQgaW4gYSBNSU1FIG9iamVjdCBzcGVjaWZpY2F0aW9uIGlzIGEN CiJwYXJ0Ii4NCg0KLS0+DQoNCjwhRUxFTUVOVCBib2R5IChwYXJ0KyB8IE1J WEVEKSA+DQoNCjwhLS0gRU5EIE1PRFVMRTogUkZDODIyIG1lc3NhZ2Ugc3Bl Y2lmaWNhdGlvbiBkb2N1bWVudCB0eXBlIGRlZmluaXRpb24gLS0+DQo= --Part10402152247.A Content-Type: Application/Octet-Stream; name="mime_object.dtd" Content-Disposition: attachment; filename="mime_object.dtd" Content-Transfer-Encoding: base64 PCEtLSBNT0RVTEU6IE1JTUUgb2JqZWN0IHNwZWNpZmljYXRpb24gZG9jdW1l bnQgdHlwZSBkZWZpbml0aW9uIC0tPg0KDQo8IS0tIENPUFlSSUdIVA0KJFJD U2ZpbGU6IG1pbWVfb2JqZWN0LmR0ZCx2ICQNCiRSZXZpc2lvbjogMS43ICQN CiREYXRlOiAyMDAyLzA4LzA5IDE0OjU2OjE2ICQNCiRBdXRob3I6IGpwcyAk DQoNCkNvcHlyaWdodCAoYykgMjAwMSBNZXNzYWdpbmdEaXJlY3QgTGltaXRl ZCwgRWRtb250b24sIENhbmFkYQ0KQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAN CkFjcXVpc2l0aW9uIGFuZCB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSBhbmQgcmVs YXRlZCBtYXRlcmlhbHMgZm9yIGFueQ0KcHVycG9zZSByZXF1aXJlcyBhIHdy aXR0ZW4gbGljZW5zZSBhZ3JlZW1lbnQgZnJvbSBNZXNzYWdpbmdEaXJlY3Qg TGltaXRlZCwNCm9yIGEgd3JpdHRlbiBsaWNlbnNlIGZyb20gYW4gb3JnYW5p emF0aW9uIGxpY2Vuc2VkIGJ5IE1lc3NhZ2luZ0RpcmVjdCBMaW1pdGVkDQp0 byBncmFudCBzdWNoIGEgbGljZW5zZS4NCkVORCBDT1BZUklHSFQgLS0+DQoN CjwhLS0gT1ZFUlZJRVc6IA0KVjEuMA0KDQpUaGlzIGRvY3VtZW50IHR5cGUg ZGVmaW5lcyBhIGRhdGEgcmVwcmVzZW50YXRpb24gZm9yIGEgTUlNRSBvYmpl Y3QuICBUaGUNCnNwZWNpZmljYXRpb24gaXMgZGVzaWduZWQgdG8gcmVwcmVz ZW50IHRoZSBzdHJ1Y3R1cmUgb2YgYSBoaWVyYXJjaGljYWxseQ0Kb3JnYW5p emVkLCBtdWx0aXBhcnQsIG11bHRpbWVkaWEgZG9jdW1lbnQuICAgSXQgaXMg YSBkZWNsYXJhdGl2ZSBzcGVjaWZpY2F0aW9uDQpmb3IgdGhlIGNvbnN0cnVj dGlvbiBvZiBhIE1JTUUgb2JqZWN0Lg0KRU5EIE9WRVJWSUVXIC0tPg0KDQo8 IS0tIEhJU1RPUlkNCkluY3JEZXYgTWFyIDgsIDIwMDEgYnkgc2g6IGV4dGVu ZGVkIHNjaGVtYSB0byBzdXBwb3J0IGNvbnRlbnRfdHlwZSBwYXJhbWV0ZXJz DQpDcmVhdGVkIE1hciAxLCAyMDAxIGJ5IHNoOg0KRU5EIEhJU1RPUlkgLS0+ DQoNCjwhLS0gUFVCTElDIERFUEVOREVOQ0lFUyAtLT4NCjwhLS0gRU5EIFBV QkxJQyBERVBFTkRFTkNJRVMgLS0+DQoNCg0KPCEtLSBwYXJ0DQoNCkEgTUlN RSBvYmplY3QgcGFydCBzcGVjaWZpY2F0aW9uLiAgVGhpcyBlbGVtZW50IGRl ZmluZXMgYSBub2RlIGluIGENCmhpZXJhcmNoaWNhbCBNSU1FIG9iamVjdC4g IFBhcnRzIGhhdmUgInR5cGVzIiB0aGF0IGFyZSBlcXVpdmFsZW50IHRvIHRo ZSBwYXJ0DQp0eXBlcyBkZWZpbmVkIGluIFJGQzIwNDUuDQoNCkEgTUlNRSBv YmplY3QgInBhcnQiIGlzIGEgc3RydWN0dXJlZCBlbGVtZW50IHdpdGggZWl0 aGVyIGEgc2V0IG9mIGRlc2NlbmRhbnQNCiJwYXJ0IiBlbGVtZW50cyBvciBh ICJjb250ZW50IiBlbGVtZW50LiAgSWYgdGhlIHBhcnQgaGFzIGRlc2NlbmRh bnQgcGFydA0KZWxlbWVudHMsIHRoZW4gdGhlIGNvbnRlbnRfdHlwZSBvZiB0 aGUgcGFydCBtdXN0IGJlIG9uZSBvZiAibXVsdGlwYXJ0L3ttdW1ibGV9Ig0K b3IgIm1lc3NhZ2UvcmZjODIyIi4gIElmIHRoZSBwYXJ0IGhhcyBhIGRlc2Nl bmRhbnQgImNvbnRlbnQiIGVsZW1lbnQsIHRoZW4gdGhlDQpjb250ZW50X3R5 cGUgYXR0cmlidXRlIG11c3Qgbm90IGJlICJtdWx0aXBhcnQve211bWJsZX0i IG9yICJtZXNzYWdlL3JmYzgyMiIuDQpUaHVzIG9ubHkgdGVybWluYWwgKG5v bi1zdHJ1Y3R1cmVkKSBNSU1FIHBhcnRzIGFyZSBhbGxvd2VkIHRvIGhhdmUg Y29udGVudC4NCiAgICAgDQpJdCBhbHNvIGNvbnRhaW5zIGEgbnVtYmVyIG9m IGF0dHJpYnV0ZXMgdGhhdCBwcm92aWRlIG1ldGEgZGF0YSBmb3Igc3RhbmRh cmQNCk1JTUUgb2JqZWN0cy4gIFRoZXNlIGFyZSAiY29udGVudF97bXVtYmxl fSIgYXR0cmlidXRlcyB0aGF0IGNvcnJlc3BvbmQgZGlyZWN0bHkNCnRvIENv bnRlbnQte011bWJsZX0gaGVhZGVycyBkZWZpbmVkIGluIE1JTUUgb3IgaW4g ZXh0ZW5zaW9ucyB0byBNSU1FDQooZWcuIENvbnRlbnQtRGlzcG9zaXRpb24p Lg0KDQotLT4NCg0KPCFFTEVNRU5UIHBhcnQgKHBhcnQrIHwgcGFydF9jb250 ZW50KSA+DQoNCg0KPCEtLSBwYXJ0IEF0dHJpYnV0ZXMNCg0KY29udGVudF90 eXBlOg0KDQpUaGlzIGF0dHJpYnV0ZSBpcyBtYW5kYXRvcnkgYW5kIGRlZmlu ZXMgdGhlIE1JTUUgY29udGVudCB0eXBlIGZvciB0aGUgTUlNRSBwYXJ0DQoo Q29udGVudC1UeXBlIGhlYWRlcikuDQoNCmNvbnRlbnRfdHlwZV9wYXJhbWV0 ZXJzOg0KDQpUaGlzIGF0dHJpYnV0ZSBpcyBvcHRpb25hbCBhbmQgZXh0ZW5k cyB0aGUgY29udGVudCB0eXBlIHRvIGluY2x1ZGUgTUlNRSBjb250ZW50DQp0 eXBlIHBhcmFtZXRlcnMuICBUaGUgcGFyYW1ldGVycyBhcmUgZXhwcmVzc2Vk IGFzIGEgc2VtaWNvbG9uIGRlbGltaXRlZCBzZXQgb2YNCmtleS92YWx1ZSBw YWlycyB1c2luZyB0aGUgZXhhY3Qgc3ludGF4IHRoYXQgTUlNRSBDb250ZW50 LVR5cGUgcGFyYW1ldGVycyB1c2UuDQpUaGUgQUJORiBmb3IgdGhlIHN5bnRh eCBpczoNCg0KICAgICBwYXJhbXMgOj0gcGFyYW1ldGVyICooIjsiIHBhcmFt ZXRlcikNCiAgICAgcGFyYW1ldGVyIDo9IGF0dHJpYnV0ZSAiPSIgdmFsdWUN Cg0KQW4gZXhhbXBsZSBvZiBhIHNldCBvZiBwYXJhbWV0ZXJzIGlzOg0KDQog ICAgIG5hbWU9YmlsbC5odG07cm9vdD10ZXh0L2h0bWwNCg0KKioqIE5PVEU6 DQoNClRoaXMgYXR0cmlidXRlIHNob3VsZCBiZSB1c2VkIHdpdGggY2FyZSBi ZWNhdXNlIGl0IHJlcXVpcmVzIHNwZWNpZmljIGtub3dsZWRnZQ0Kb2Ygc3Bl Y2lmaWMgTUlNRSBleHRlbnNpb24gZm9ybWF0cyBsaWtlIE1IVE1MIG9yIE11 bHRpcGFydC9BcHBsZWRvdWJsZSBhbmQgdGhlDQpwYXJhbWV0ZXJzIHRoYXQg dGhleSByZXF1aXJlIGZvciB1c2UuICBGb3IgYmFzaWMgbXVsdGlwYXJ0IG1l c3NhZ2VzLCB0aGUNCnJlbWFpbmluZyBjb250ZW50X3ttdW1ibGV9IGF0dHJp YnV0ZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQgdG8gZnVsbHkgc3BlY2lmeSB0 aGUNCmNvbnN0cnVjdGlvbiBvZiBhIE1JTUUgbWVz c2FnZS4gDQoNCg0KY29udGVudF9jaGFyc2V0Og0KDQpUaGlzIGF0dHJpYnV0 ZSBkZWZpbmVzIHRoZSBjaGFyYWN0ZXIgc2V0IHRoYXQgdGhlIHBhcnQgc2hv dWxkIGJlIGxhYmVsbGVkIHdpdGgNCklGIHRoZSBwYXJ0J3MgY29udGVudCB0 eXBlIGlzIG9mIHRoZSBmb3JtICJ0ZXh0L3ttdW1ibGV9Ii4gIFRoaXMgYXR0 cmlidXRlIGlzDQppZ25vcmVkIGZvciBhbnkgb3RoZXIgcGFydCBjb250ZW50 IHR5cGVzLiAgVGhlIGRlZmF1bHQgdmFsdWUgb2YgdGhlIGF0dHJpYnV0ZQ0K aXMgaW1wbGllZCBieSB0aGUgYXBwbGljYXRpb24gdGhhdCBnZW5lcmF0ZXMg dGhlIG91dHB1dCBNSU1FIG9iamVjdC4gIFRoZQ0KYXBwbGljYXRpb24gd2ls bCB1c2UgY2hhcmFjdGVyIHNldCBhc3NvY2lhdGVkIHdpdGggdGhlIGdlbmVy YXRpbmcgcHJvZ3JhbSdzDQpvcGVyYXRpbmcgc3lzdGVtIGxvY2FsZSB0byBk ZXRlcm1pbmUgdGhpcy4NCg0KY29udGVudF9lbmNvZGluZzoNCg0KVGhlIGNv bnRlbnQgZW5jb2RpbmcgZm9yIHRoZSBwYXJ0LiAgSWYgdGhlIGNvbnRlbnQg aXMgYWxyZWFkeSBlbmNvZGVkIHdpdGggb25lDQpvZiB0aGUgc3VwcG9ydGVk IE1JTUUgZW5jb2RpbmdzLCB5b3UgY2FuIHBhc3MgdGhlIGVuY29kaW5nIHRv IHRoZSBnZW5lcmF0b3INCnByb2dyYW0gc28gdGhhdCBpdCBwcm9wZXJseSBy ZXByZXNlbnRzIHRoYXQgZW5jb2RpbmcgaW4gdGhlIG91dHB1dCBNSU1FDQpt ZXNzYWdlLiAgVGhpcyBhbGxvd3MgeW91IHRvIHRyYW5zcGFyZW50bHkgcGFz cyB0aHJvdWdoIE1JTUUgb2JqZWN0IGJsb2JzIHRoYXQNCmhhdmUgYWxyZWFk eSBiZWVuIHByZXBhcmVkIGJ5IGFub3RoZXIgcHJvZ3JhbS4gDQoNCmNvbnRl bnRfZGVzY3JpcHRpb246DQoNClRoaXMgYXR0cmlidXRlIGlzIG9wdGlvbmFs IGFuZCB3aWxsIGJlIHdyaXR0ZW4gZGlyZWN0bHkgaW50byB0aGUNCkNvbnRl bnQtRGVzY3JpcHRpb24gaGVhZGVyIGluIHRoZSBNSU1FIG9iamVjdC4gIEl0 IGlzIHVzZWQgdG8gcHJvdmlkZSBhIHRleHQNCmRlc2NyaXB0aW9uIG9mIHRo ZSBwYXJ0IHN1aXRhYmxlIGZvciBwcmVzZW50YXRpb24gdGhlIHRvIG1lc3Nh Z2UgcmVjaXBpZW50Lg0KDQpjb250ZW50X2lkOg0KDQpUaGUgcGFydCdzIHVu aXF1ZSBjb250ZW50IGlkZW50aWZpZXIuICBUaGlzIGF0dHJpYnV0ZSBpcyBv cHRpb25hbCBhbmQgd2lsbCBiZSB3cml0dGVuDQpkaXJlY3RseSBpbnRvIHRo ZSBDb250ZW50LUlkIGhlYWRlciBpbiB0aGUgTUlNRSBvYmplY3QuICBUaGlz IGlzIHRoZSB2YWx1ZSB0aGF0DQppcyB1c2VkIHRvIGRlcmVmZXJlbmNlIGEg Q0lEIFVSTCBpbiBhbiBNSFRNTCBkb2N1bWVudC4gIFRoaXMgYXR0cmlidXRl J3MgdmFsdWUNCm11c3QgYmUgY3JlYXRlZCBpbiBjb25mb3JtYW5jZSB3aXRo IFJGQzIwNDUncyBkZWZpbml0aW9uIGZvciB0aGUgQ29udGVudC1JZCBoZWFk ZXIuDQoNCmNvbnRlbnRfbG9jYXRpb246DQoNClRoaXMgYXR0cmlidXRlIGlz IG9wdGlvbmFsIGFuZCB3aWxsIGJlIHdyaXR0ZW4gZGlyZWN0bHkgaW50byB0 aGUNCkNvbnRlbnQtTG9jYXRpb24gaGVhZGVyIGluIHRoZSBNSU1FIG9iamVj dC4gIFRoaXMgaXMgdGhlIHZhbHVlIHRoYXQgaXMgdXNlZCB0bw0KbG9jYWxs eSBkZXJlZmVyZW5jZSBhIHJlbGF0aXZlIFVSTCBpbiBhbiBNSFRNTCBkb2N1 bWVudC4gDQoNCmNvbnRlbnRfZGlzcG9zaXRpb246DQoNClRoaXMgYXR0cmli dXRlIGRlZmluZXMgaG93IHRoZSBkaXNwbGF5IGFkdmljZSBwb3J0aW9uIG9m IHRoZSBNSU1FDQpDb250ZW50LURpc3Bvc2l0aW9uIGV4dGVuc2lvbiBoZWFk ZXIgd2lsbCBiZSB3cml0dGVuLiAgSXQgc2VsZWN0cyB0aGUgbW9kZSB0aGF0 DQphIHJlY2VpdmluZyBNSU1FIGRpcGxheSBhZ2VudCB3aWxsIHRyeSB0byBy ZW5kZXIgdGhlIHBhcnQgaW4uICBUaGVyZSBhcmUgdHdvDQpzdXBwb3J0ZWQg cmVuZGVyaW5nIG1vZGVzOg0KDQogICJpbmxpbmUiIGluZGljYXRlcyB0aGF0 IHRoZSBwYXJ0IHNob3VsZCBiZSByZW5kZXJlZCBpbmxpbmUsIGluIHNlcXVl bmNlIHdpdGgNCiAgICAgICAgICAgb3RoZXIgTUlNRSBvYmplY3QgcGFydHMN Cg0KICAiYXR0YWNobWVudCIgaW5kaWNhdGVzIHRoYXQgdGhlIHBhcnQgc2hv dWxkIGJlIGRpc3BsYXllZCBhcyBhbiBhdHRhY2htZW50DQogICAgICAgICAg ICAgICBvYmplY3QsIHdoaWNoIGlzIHJlbmRlcmVkIG9ubHkgaWYgdGhlcmUg aXMgYW4gZXhwbGljaXQgcmVxdWVzdA0KICAgICAgICAgICAgICAgdG8gZG8g c28gYnkgdGhlIHVzZXIuDQoNClRoZSBkZWZhdWx0IHZhbHVlIGlzICJhdHRh Y2htZW50Ii4gIA0KDQpzdWdnZXN0ZWRfZmlsZW5hbWU6DQoNCkEgc3VnZ2Vz dGVkIGZpbGVuYW1lIGZvciB0aGUgcGFydC4gIFRoaXMgYXR0cmlidXRlcyBk ZWZpbmVzIGEgZmlsZW5hbWUgZm9yIGENCnJlY2VpdmluZyBhZ2VudCB0byB1 c2Ugd2hlbiBwcm9jZXNzaW5nIG9yIHNhdmluZyB0aGUgcGFydCBpbnRvIGEg ZmlsZXN5c3RlbS4NCkl0IGlzIGV4cHJlc3NlZCBhcyBvbmUgb2YgdGhlIGV4 dGVuZGVkIGF0dHJpYnV0ZXMgb2YgdGhlIENvbnRlbnQtRGlzcG9zaXRpb24N Ck1JTUUgZXh0ZW5zaW9uIGhlYWRlci4NCg0KLS0+DQoNCjwhQVRUTElTVCBw YXJ0IA0KICAgIGNvbnRlbnRfdHlwZSBDREFUQSAjUkVRVUlSRUQNCiAgICBj b250ZW50X3R5cGVfcGFyYW1ldGVycyBDREFUQSAjSU1QTElFRA0KICAgIGNv bnRlbnRfY2hhcnNldCBDREFUQSAjSU1QTElFRA0KICAgIGNvbnRlbnRfZW5j b2RpbmcgKGJhc2U2NCkgI0lNUExJRUQNCiAgICBjb250ZW50X2Rlc2NyaXB0 aW9uIENEQVRBICNJTVBMSUVEDQogICAgY29udGVudF9pZCBDREFUQSAjSU1Q TElFRA0KICAgIGNvbnRlbnRfbG9jYXRpb24gQ0RBVEEgI0lNUExJRUQNCiAg ICBjb250ZW50X2Rpc3Bvc2l0aW9uIChpbmxpbmUgfCBhdHRhY2htZW50KSAi YXR0YWNobWVudCINCg0KICAgIHN1Z2dlc3RlZF9maWxlbmFtZSBDREFUQSAj SU1QTElFRA0KPg0KDQo8IS0tIHBhcnRfY29udGVu dA0KDQpNSU1FIG9iamVjdCBwYXJ0IGNvbnRlbnQgZGF0YS4gIFRoaXMgZWxl bWVudCBkZWZpbmVzIGhvdyB0aGUgY29udGVudCBkYXRhIGZvciBhDQp0ZXJt aW5hbCBNSU1FIG9iamVjdCBwYXJ0IGlzIGNhcnJpZWQuICBUaGVyZSBhcmUg dHdvIG1lY2hhbmlzbXMgZm9yDQpyZXByZXNlbnRpbmcgdGhlIGNvbnRlbnQg ZGF0YTogImlubGluZSIgc3BlY2lmaWVzIHRoYXQgdGhlIGNvbnRlbnRfZGF0 YQ0KZWxlbWVudCdzIHZhbHVlIGlzIHRoZSBjb250ZW50LCAidXJpIiBzcGVj aWZpZXMgdGhhdCB0aGUgY29udGVudF9kYXRhIGVsZW1lbnQncw0KdmFsdWUg aXMgYSBVUkkgdG8gdGhlIGxvY2F0aW9uIG9mIGFuIGV4dGVybmFsIHNvdXJj ZSBvZiB0aGUgY29udGVudCBkYXRhLiANCg0KLS0+DQoNCjwhRUxFTUVOVCBw YXJ0X2NvbnRlbnQgKE1JWEVEKSA+DQoNCg0KPCEtLSBwYXJ0X2NvbnRlbnRf YXR0cmlidXRlcw0KDQpsb2NhdGlvbl90eXBlOg0KDQpMb2NhdGlvbiBvZiBj b250ZW50X2RhdGEuICBUaGVyZSBhcmUgdHdvIHN1cHBvcnRlZCBsb2NhdGlv bnMgb2YgY29udGVudDoNCmNvbnRlbnQgYnkgcmVmZXJlbmNlICh1cmkpIGFu ZCBpbmxpbmUgY29udGVudCBkYXRhLiAgVGhlIG1lc3NhZ2UgZ2VuZXJhdG9y IHdpbGwNCnByb2Nlc3MgYW5kIGluY2x1ZGUgZGF0YSBpbiB0aGUgb3V0cHV0 IE1JTUUgbWVzc2FnZSBiYXNlZCBvbiB0aGUgdHlwZSBvZg0KY29udGVudCBl bGVtZW50Lg0KDQpOb3RlIHRoYXQgdGhlIG9ubHkgdHlwZSBvZiBVUkkgdGhh dCBpcyBjdXJyZW50bHkgc3VwcG9ydGVkIGlzIGEgVVJMLiAgU3VwcG9ydGVk DQpVUkwgc2NoZW1lcyBpbmNsdWRlOg0KDQogICAgIGZpbGU6IGFuIGFic29s dXRlIHJlZmVyZW5jZSB0byBhIHBhcnRpY3VsYXIgZmlsZSBpbiB0aGUgbG9j YWwgDQogICAgICAgZmlsZXN5c3RlbS4NCg0KICAgICBqb2JkYXRhOiBhbiBy ZWxhdGl2ZSByZWZlcmVuY2UgdG8gYSBwYXJ0aWN1bGFyIGRhdGEgcGFydCBv Zg0KICAgICAgIGN1cnJlbnQgam9iLiAgIFRoZSBzeW50YXggZm9yIGpvYmRh dGEgVVJMcyBpczoNCg0KICAgICAgIGpvYmRhdGE6e259DQoNCiAgICAgICB3 aGVyZSB7bn0gaXMgdGhlIG51bWJlciBvZiB0aGUgZGF0YSBwYXJ0IHRoYXQg Y29udGFpbnMNCiAgICAgICB0aGUgY29udGVudC4NCg0KICAgICBodHRwOiBh IHJlZmVyZW5jZSB0byBhbiBIVFRQIHNlcnZlZCByZXNvdXJjZS4NCg0KICAg ICBpbWFwOiBhIHJlZmVyZW5jZSB0byBhIG1lc3NhZ2UgcGFydCBpbiBhIHJl bW90ZSBJTUFQIG1lc3NhZ2Ugc3RvcmUuDQogICAgICAgVVJJIE1VU1QgcmVm ZXJlbmNlIGEgdGVybWluYWwgKG5vbi1tdWx0aXBhcnQpIHBhcnQuICAgQWxs IA0KICAgICAgICJtZXNzYWdlL3ttdW1ibGV9IiBhcmUgc3VwcG9ydGVkLCB0 cmVhdGVkIGFzIGEgdGVybWluYWwgYXRvbWljIHBhcnQNCiAgICAgICBvYmpl Y3QuDQoNCg0KUmVsYXRpdmUgVVJMcyBhcmUgYWx3YXlzIHJlc29sdmVkIHJl bGF0aXZlIHRvIGEgYmFzZSBVUkwgc3BlY2lmaWVkIGluIHRoZQ0KcnVudGlt ZSBjb25maWd1cmF0aW9uIG9mIHRoZSBnZW5lcmF0aW9uIHByb2dyYW0uICBJ biB0aGUgY2FzZSBvZiBtZ2VuLCB0aGlzIGlzDQp0aGUgdmFsdWUgb2YgdGhl IG1nZW4uYmFzZV91cmwgb3B0aW9uLiANCg0KLS0+DQoNCjwhQVRUTElTVCBw YXJ0X2NvbnRlbnQNCiAgICBsb2NhdGlvbl90eXBlIChpbmxpbmUgfCB1cmkp ICJpbmxpbmUiDQo+DQoNCjwhLS0gRU5EIE1PRFVMRTogTUlNRSBvYmplY3Qg c3BlY2lmaWNhdGlvbiBkb2N1bWVudCB0eXBlIGRlZmluaXRpb24gLS0+DQo= --Part10402152247.A-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 16 10:34:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25333 for ; Mon, 16 Feb 2004 10:34:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askka-0004pY-42 for lemonade-archive@odin.ietf.org; Mon, 16 Feb 2004 10:33:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFXaN4018567 for lemonade-archive@odin.ietf.org; Mon, 16 Feb 2004 10:33:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskkZ-0004pO-Ur for lemonade-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:33: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 KAA25269 for ; Mon, 16 Feb 2004 10:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskkX-0004Zd-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 10:33:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskjY-0004Vh-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 10:32:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AskjB-0004RQ-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 10:32:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askj3-0004Yj-Dg; Mon, 16 Feb 2004 10:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskiT-0004XQ-J5 for lemonade@optimus.ietf.org; Mon, 16 Feb 2004 10:31:25 -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 KAA24825 for ; Mon, 16 Feb 2004 10:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskiN-0004Ox-00 for lemonade@ietf.org; Mon, 16 Feb 2004 10:31:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskhW-0004Lc-00 for lemonade@ietf.org; Mon, 16 Feb 2004 10:30:26 -0500 Received: from libertango.oryx.com ([195.30.94.163]) by ietf-mx with esmtp (Exim 4.12) id 1Askgc-0004H7-00 for lemonade@ietf.org; Mon, 16 Feb 2004 10:29:30 -0500 Message-Id: <2FcYLZ+tYvVzyIwDQQT1EQ.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: Randall Gellens Subject: Re: [lemonade] pull, please, not push. Cc: lemonade@ietf.org References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Mon, 16 Feb 2004 16:29:51 +0100 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 Randall Gellens writes: > With Push, the client may need arbitrary Submit extensions, and hence > a pass-through mechanism is needed. This is because Submit > extensions go to the fundamental use of Submit, and hence cannot be > arbitrarily limited when Submit is added to IMAP. That is, by adding > message submission to IMAP we are adding the entire functionality of > message submission to IMAP. Yes, agreed. I'd like to note that the (very clever) passthrough mechanism in the push draft seems a little limited. More of a "BSMTP extension passthrough" than ESMTP, so to speak. Would it be capable of passing e.g. draft-ietf-fax-esmtp-conneg through? The conneg-09 draft looks okay, -08 doesn't. So I still think IMAP extensions are needed for some SMTP/Submit extensions. > With Pull, the client is submitting a message and hence itself has no > need of IMAP extensions. The mini-IMAP client within the Submit > server is not a full IMAP client, and thus will have no use for any > IMAP extensions not directly related to its task of fetching a > limited and defined item. With Pull, we are not adding all of IMAP > to message submission, we are only adding a very small and > well-defined use of IMAP to the submission server. Quite. Much more manageable. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 16 21:21:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20273 for ; Mon, 16 Feb 2004 21:21: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 1Asuqm-0003yO-UJ for lemonade-archive@odin.ietf.org; Mon, 16 Feb 2004 21:20:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H2Ked5015272 for lemonade-archive@odin.ietf.org; Mon, 16 Feb 2004 21:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuqm-0003yF-PY for lemonade-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 21:20:40 -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 VAA20223 for ; Mon, 16 Feb 2004 21:20:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asuqk-0000yH-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 21:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asuoz-0000ej-00 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 21:18:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsuoR-0000ai-01 for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 21:18:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AsulU-0008Df-Co for lemonade-web-archive@ietf.org; Mon, 16 Feb 2004 21:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsulM-0001Y2-27; Mon, 16 Feb 2004 21:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuky-0001X3-Py for lemonade@optimus.ietf.org; Mon, 16 Feb 2004 21:14:40 -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 VAA20051 for ; Mon, 16 Feb 2004 21:14:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asukw-0000Px-00 for lemonade@ietf.org; Mon, 16 Feb 2004 21:14:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asujz-0000M3-00 for lemonade@ietf.org; Mon, 16 Feb 2004 21:13:39 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asuj6-0000HA-00 for lemonade@ietf.org; Mon, 16 Feb 2004 21:12:44 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1H2CcOp010719; Mon, 16 Feb 2004 18:12:38 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i1H2CcER018470; Mon, 16 Feb 2004 18:12:38 -0800 Date: Mon, 16 Feb 2004 18:12:38 -0800 (PST) From: Mark Crispin To: Steve Hole cc: Pete Resnick , lemonade@ietf.org Subject: Re: [lemonade] Re: Can I offer you some lemonade? In-Reply-To: Message-ID: References: MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Sun, 15 Feb 2004, Steve Hole wrote: > It is clear that you have to solve the issue of passing credentials for > accessing the IMAP server from the Submit server. It is not clear that > you could get around the inverse problem of passing credentials to the > Submit server from the IMAP server by creating an authorization linkage > between the IMAP server and the Submit server. As these things are quite > likely running on separate machines, I think that you have the same > problem no matter what you do. Any scheme that would require colocation > of the Submit server and the IMAP server would be architecturally ill > conceived. I believe that Push assumes that submit servers are either co-located with the IMAP server or will promiscuously accept anything from the IMAP server. As such, the claim is made that there is no need for any credentials passing in the Push case. This is one of the major problems that I have with Push. IMHO, Push is designed for an MSA architecture which is rapidly heading towards extinction. -- 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 Tue Feb 17 04:04:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18016 for ; Tue, 17 Feb 2004 04:04:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At192-0007GT-T2 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 04:03:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H93uW6027890 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 04:03:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At190-0007FZ-Ia for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 04:03: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 EAA18003 for ; Tue, 17 Feb 2004 04:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At18y-00040n-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 04:03:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At183-0003ut-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 04:02:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At17E-0003sG-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 04:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At17B-00072x-Dy; Tue, 17 Feb 2004 04: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 1At179-00072c-40 for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 04:01: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 EAA17964 for ; Tue, 17 Feb 2004 04:01:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At176-0003rI-00 for lemonade@ietf.org; Tue, 17 Feb 2004 04:01:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At16D-0003oa-00 for lemonade@ietf.org; Tue, 17 Feb 2004 04:01:02 -0500 Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 1At15q-0003kw-00 for lemonade@ietf.org; Tue, 17 Feb 2004 04:00:38 -0500 Received: from il-tlv-mbdg1.comverse.com (il-tlv-mbdg1.comverse.com [10.115.243.99]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id i1H90QM04815 for ; Tue, 17 Feb 2004 11:00:26 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 11:00:33 +0200 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E0D58F104@ismail3.comverse.com> From: Decktor Gev To: "'lemonade@ietf.org'" Subject: [lemonade] Notification requirements draft 01 Date: Tue, 17 Feb 2004 11:00:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F534.7F5C586E" 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.3 required=5.0 tests=AWL,HTML_20_30,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_01C3F534.7F5C586E Content-Type: text/plain Hi folks, For some reason I haven't received yet a formal notification for my draft submission. So there it is: http://www.ietf.org/internet-drafts/draft-decktor-s2s-notif-01.txt The main changes from version 00 (the full list is at the end of the draft): 1. Abstract Preface enhanced - Added to goals having the ability of not knowing the actual notification media. 2. Added task types specification in Informative section 3. Added rationale part in subscription section. Please have a look and share your thoughts. Thanx, Gev. ------_=_NextPart_001_01C3F534.7F5C586E Content-Type: text/html Content-Transfer-Encoding: quoted-printable [lemonade] Notification requirements draft 01

Hi folks,

For some reason I haven't received yet a formal = notification for my draft submission.

So there it is:
http://www.ietf.org/internet-drafts/draft-decktor-s2s-= notif-01.txt


The main changes from version 00 (the full list is at = the end of the draft):
1. Abstract Preface enhanced - Added to goals having = the ability of not knowing the actual notification media.
2. Added task types specification in Informative = section
3. Added rationale part in subscription = section.

Please have a look and share your thoughts.

Thanx,
Gev.

------_=_NextPart_001_01C3F534.7F5C586E-- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 17 13:13:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23277 for ; Tue, 17 Feb 2004 13:13:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9ij-0003RS-VJ for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:13:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIDL9q013224 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9ij-0003RD-Qe for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:13: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 NAA23251 for ; Tue, 17 Feb 2004 13:13:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9ii-000616-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:13:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9hu-0005xN-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:12:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At9hS-0005sm-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9hS-0003BF-0P; Tue, 17 Feb 2004 13:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9gv-00034l-DV for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 13:11: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 NAA23067 for ; Tue, 17 Feb 2004 13:11:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9gt-0005qO-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:11:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9g8-0005kQ-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:10:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1At9fC-0005eF-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:09:42 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1HI9bvf015617; Tue, 17 Feb 2004 10:09:39 -0800 (PST) Received: from [205.214.163.53] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1HI9YVK025171; Tue, 17 Feb 2004 10:09:35 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Tue, 17 Feb 2004 10:09:42 -0800 To: Steve Hole , Pete Resnick From: Ted Hardie Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:47 PM -0700 02/15/2004, Steve Hole wrote: > >The question is "why would you limit it"? I would make it any valid URI >scheme, with a mandatory to implement for the IMAP URL scheme. And the answer would be "because different access protocols have different security characteristics, uses of the network, and presumptions about change". "Any valid URI scheme" is clearly the wrong answer since that would include schemes like urn: and cid: which don't make any sense for this use. You'd have to limit it to "any access protocol commonly used for data retrieval", but there would remain a lot of slop in that bucket (would epp qualify, for example?). Even with that, you'd end up with very different characteristics for retrieval timing that would effect the deployment. > That way >you leave it up to the implementor to decide which they will support. >I'm not sure how you would advertise what was supported, but it might not >matter. > Any implementation worth it's salt would make such support >extensible (factory) oriented so that you can switch on the scheme and try >and find a suitable driver. And this foster interoperability how? Without a limited set of URI schemes, you're going to have to either add an advertisement capability or run the risk of getting a negative response after the SUBMIT server has parsed the data, which at best is going to add round trips we're trying to avoid. regards, Ted HArdie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 17 13:38:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25409 for ; Tue, 17 Feb 2004 13:38:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA6B-0006pl-35 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:37:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIbYRS026268 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:37:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA6A-0006pb-PT for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:37:34 -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 NAA25392 for ; Tue, 17 Feb 2004 13:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA68-0000nl-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:37:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA5G-0000iu-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:36:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtA4f-0000cY-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA4g-0006cv-F4; Tue, 17 Feb 2004 13: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 1AtA43-0006bu-3C for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 13:35: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 NAA25244 for ; Tue, 17 Feb 2004 13:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA41-0000an-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA38-0000X7-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:34:27 -0500 Received: from rembrandt.esys.ca ([198.161.92.131]) by ietf-mx with esmtp (Exim 4.12) id 1AtA2f-0000TB-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:33:58 -0500 Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i1HIXG501334; Tue, 17 Feb 2004 11:33:17 -0700 From: Steve Hole Date: Tue, 17 Feb 2004 11:33:41 -0700 To: Ted Hardie Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: Pete Resnick , lemonade@ietf.org In-Reply-To: References: Message-ID: Priority: NORMAL X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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 On Tue, 17 Feb 2004 10:09:42 -0800 Ted Hardie wrote= : > And this foster interoperability how? Without a limited set of URI > schemes, you're going to have to either add an advertisement capability > or run the risk of getting a negative response after the SUBMIT > server has parsed the data, which at best is going to add round > trips we're trying to avoid. So you get a negative response? Do you really think that that is going= =20 to happen all that often? If you are just doing good old email, then you would probably only ever=20 use one of file, http, or imap -- with imap being by far the most likely. If you are doing something specific (like a voice mail system) you might= =20 want some streaming access protocol. In the private use case, the "client= " and the "submit" server are pretty likely to agree. This is also the=20 case where external references really win for you. =20 If you want to promote interoperability over a wider range of=20 functionality then add more schemes to the set of mandatory to implement.= =20 The base specification can still specify a syntax that includes any URI=20 scheme. If you're keen, then add file and http. In any case, what I was talking about was providing a base from which=20 reasonable extension can be done -- most likely by something other than a= =20 traditional mail client.=20 Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 17 13:40:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25747 for ; Tue, 17 Feb 2004 13:40:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA8v-000770-Gu for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:40:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIeOwe027306 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:40:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA8q-000769-LJ for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:40:20 -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 NAA25551 for ; Tue, 17 Feb 2004 13:40:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA8o-0001DP-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:40:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA7T-0000yF-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:38:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtA6a-0000o4-01 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:38:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At9u6-0006C9-Q0 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9u4-0005oD-CD; Tue, 17 Feb 2004 13:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9tu-0005mZ-Ca for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 13:24: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 NAA24666 for ; Tue, 17 Feb 2004 13:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9ts-0007c3-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:24:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9sv-0007ST-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:23:53 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1At9rg-0007Hy-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:22:36 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1HIMWnp005543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2004 10:22:32 -0800 (PST) Received: from [205.214.163.53] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1HIMTvx014301; Tue, 17 Feb 2004 10:22:30 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Tue, 17 Feb 2004 10:22:37 -0800 To: Mark Crispin , Steve Hole From: Ted Hardie Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: Pete Resnick , lemonade@ietf.org 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=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 6:12 PM -0800 02/16/2004, Mark Crispin wrote: >On Sun, 15 Feb 2004, Steve Hole wrote: >>It is clear that you have to solve the issue of passing credentials for >>accessing the IMAP server from the Submit server. It is not clear that >>you could get around the inverse problem of passing credentials to the >>Submit server from the IMAP server by creating an authorization linkage >>between the IMAP server and the Submit server. As these things are quite >>likely running on separate machines, I think that you have the same >>problem no matter what you do. Any scheme that would require colocation >>of the Submit server and the IMAP server would be architecturally ill >>conceived. > >I believe that Push assumes that submit servers are either >co-located with the IMAP server or will promiscuously accept >anything from the IMAP server. As such, the claim is made that >there is no need for any credentials passing in the Push case. I don't agree that Push assumes that submit servers are co-located with the IMAP server. I also don't agree with "promiscuously accept anything from the IMAP server", but I do agree that many deployments would be able to accept the IMAP server's credentials as sufficient for injection into the SMTP stream, rather than needing to see the individual's credentials for itself. Think of it in terms of normal SMTP operation. You commonly have boxes arranged like this: ----- ---- ---- ---- | 1 |-----------| 2 |-----[internet]-------| 3 |----| 4 | ----- --- ---- ---- where 1 is inside enterprise A's firewall and 2 is in its DMZ, 3 is in enterprise B's DMZ and 4 is in its dmz. 2 never sees the end users' credentials; it is configured to allow 1 to transmit to it based on the server credentials. The "upstream" SMTP servers to the IMAP submit server might be configured to behave in the same way. As usual, speaking only for myself here, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 17 13:57:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26927 for ; Tue, 17 Feb 2004 13:57:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAPH-0000pt-Dj for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:57:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIvJTt003212 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 13:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAPH-0000pj-9o for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:57:19 -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 NAA26920 for ; Tue, 17 Feb 2004 13:57:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAPF-0002qq-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:57:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAOK-0002oG-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:56:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtAO1-0002lX-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 13:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAO1-0000Xq-Rf; Tue, 17 Feb 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtANQ-0000QE-WD for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 13:55:25 -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 NAA26849 for ; Tue, 17 Feb 2004 13:55:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtANO-0002kj-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:55:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAMb-0002gT-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:54:34 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx with esmtp (Exim 4.12) id 1AtALu-0002ag-00 for lemonade@ietf.org; Tue, 17 Feb 2004 13:53:50 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1HIrmnt009958; Tue, 17 Feb 2004 10:53:48 -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.11+UW04.02) with ESMTP id i1HIrlQa006818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Feb 2004 10:53:48 -0800 Date: Tue, 17 Feb 2004 10:53:48 -0800 (Pacific Standard Time) From: Mark Crispin To: Ted Hardie cc: Steve Hole , Pete Resnick , lemonade@ietf.org Subject: Re: [lemonade] Re: Can I offer you some lemonade? In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 17 Feb 2004, Ted Hardie wrote: > I also don't agree with "promiscuously accept anything > from the IMAP server", but I do agree that many deployments would > be able to accept the IMAP server's credentials as sufficient for > injection into the SMTP stream, rather than needing to see the individual's > credentials for itself. > Think of it in terms of normal SMTP operation. As I said in my previous message, you are presuming an architecture that is (IMHO) heading towards extinction. What may be "normal" today is not necessarily going to be "normal" for very much longer. Just as an enterprise inevitably outgrows Linksys NAT boxes and has to deploy real networking hardware, the time comes when the "SMTP server in the DMZ" architecture is outgrown. The proliferation of email-based viri makes that painfully clear if nothing else does. -- 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 Tue Feb 17 16:18:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06712 for ; Tue, 17 Feb 2004 16:18:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCbl-0000Y7-SO for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 16:18:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HLILF3002107 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 16:18:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCbl-0000Xt-FM for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 16:18: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 QAA06563 for ; Tue, 17 Feb 2004 16:18:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCbj-0006d3-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 16:18:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCaW-0006On-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 16:17:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtCZE-0006EG-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 16:15:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtCQo-0008BU-Se for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 16:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCQn-0007uD-El; Tue, 17 Feb 2004 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCPp-0007s8-0L for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 16:06: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 QAA05747 for ; Tue, 17 Feb 2004 16:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCPn-0005TL-00 for lemonade@ietf.org; Tue, 17 Feb 2004 16:05:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCOf-0005JR-00 for lemonade@ietf.org; Tue, 17 Feb 2004 16:04:50 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AtCNr-0005AQ-00 for lemonade@ietf.org; Tue, 17 Feb 2004 16:03:59 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 21162; Tue, 17 Feb 2004 16:04:16 -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: Tue, 17 Feb 2004 16:03:29 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB242EA@zoe.office.snowshore.com> Thread-Topic: Supplemental Page Thread-Index: AcP1mXqvvLvjjZfFQIGdkWjO3DsABw== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Supplemental Page 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: quoted-printable Content-Transfer-Encoding: quoted-printable I have updated the lemonade supplemental page,=20 http://flyingfox.snowshore.com/i-d/lemonade/ Please check for accuracy, omissions, gaffs, etc. Also, a quick note for I-D authors. Please review ID nits, = http://www.ietf.org/ietf/1id-guidelines.txt Your best bet to nearly guarantee RFC conformance is to use RFC2629, = a.k.a. xml2rfc. ftp://ftp.rfc-editor.org/in-notes/rfc2629.txt http://xml.resource.org _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 17 20:09:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21085 for ; Tue, 17 Feb 2004 20:09: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 1AtGCV-0003Vm-D5 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 20:08:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I18Vjs013494 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 20:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGCV-0003VZ-6y for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 20:08: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 UAA21079 for ; Tue, 17 Feb 2004 20:08:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtGCT-0002OI-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 20:08:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtGBd-0002LT-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 20:07:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtGB3-0002HX-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 20:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGB3-00035X-08; Tue, 17 Feb 2004 20:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGAV-000347-OJ for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 20:06: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 UAA20983 for ; Tue, 17 Feb 2004 20:06:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtGAT-0002F5-00 for lemonade@ietf.org; Tue, 17 Feb 2004 20:06:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtG9d-0002BC-00 for lemonade@ietf.org; Tue, 17 Feb 2004 20:05:34 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AtG8p-00027m-00 for lemonade@ietf.org; Tue, 17 Feb 2004 20:04:43 -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 i1I14gnp000718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2004 17:04:42 -0800 (PST) Received: from [192.168.1.13] (loud.qualcomm.com [129.46.74.63]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1I14YVK014842; Tue, 17 Feb 2004 17:04:35 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v6.1a Date: Tue, 17 Feb 2004 17:00:03 -0800 To: Ted Hardie , Steve Hole , Pete Resnick From: Randall Gellens Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org 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 At 10:09 AM -0800 2/17/04, Ted Hardie wrote: > At 10:47 PM -0700 02/15/2004, Steve Hole wrote: >> >> The question is "why would you limit it"? I would make it any valid URI >> scheme, with a mandatory to implement for the IMAP URL scheme. > > And the answer would be "because different access protocols have > different security characteristics, uses of the network, and presumptions > about change". I'd support an initial limitation to IMAP URL, since that solves our immediate problem, and leaves the protocol in a state that can be easily extended. > Without a limited set of URI > schemes, you're going to have to either add an advertisement capability > or run the risk of getting a negative response after the SUBMIT > server has parsed the data, which at best is going to add round > trips we're trying to avoid. Since we're talking about Submit here, it seems pretty easy to add an advertisement capability. We can leave that door open in the initial version. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The nice thing about standards is that there are so many of them to choose from. --Andrew S. Tanenbaum _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Tue Feb 17 21:15:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23440 for ; Tue, 17 Feb 2004 21:15: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 1AtHEZ-0000E4-Up for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 21:14:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I2EhS6000864 for lemonade-archive@odin.ietf.org; Tue, 17 Feb 2004 21:14:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtHEZ-0000Dr-NW for lemonade-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 21:14: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 VAA23430 for ; Tue, 17 Feb 2004 21:14:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtHEX-0006pJ-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 21:14:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtHDn-0006kV-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 21:13:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtHCv-0006eX-00 for lemonade-web-archive@ietf.org; Tue, 17 Feb 2004 21:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtHCu-00007N-Pt; Tue, 17 Feb 2004 21: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 1AtHCA-00005z-Lz for lemonade@optimus.ietf.org; Tue, 17 Feb 2004 21:12:14 -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 VAA23299 for ; Tue, 17 Feb 2004 21:12:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtHC7-0006Vr-00 for lemonade@ietf.org; Tue, 17 Feb 2004 21:12:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtHB4-0006KK-00 for lemonade@ietf.org; Tue, 17 Feb 2004 21:11:06 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx with esmtp (Exim 4.12) id 1AtH9c-00064J-00 for lemonade@ietf.org; Tue, 17 Feb 2004 21:09:36 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1I29Z4O021956; Tue, 17 Feb 2004 18:09:36 -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.11+UW04.02) with ESMTP id i1I29Zsa008595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Feb 2004 18:09:35 -0800 Date: Tue, 17 Feb 2004 18:09:35 -0800 (Pacific Standard Time) From: Mark Crispin To: Randall Gellens cc: Ted Hardie , Steve Hole , Pete Resnick , lemonade@ietf.org Subject: Re: [lemonade] Re: Can I offer you some lemonade? In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 17 Feb 2004, Randall Gellens wrote: > I'd support an initial limitation to IMAP URL, since that solves our > immediate problem, and leaves the protocol in a state that can be easily > extended. I would support it as well, and for the same reasons. Although I believe that this limitation will soon be overturned (sooner than some people think), that is a task for some other WG. Lemonade will have done its duty by (1) solving its tasks and (2) not making the future WG's job needlessly harder. -- 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 Wed Feb 18 09:40:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13857 for ; Wed, 18 Feb 2004 09:40:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSrS-00041F-Fv for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 09:39:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IEdcxp015448 for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 09:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSrS-000415-9q for lemonade-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 09:39:38 -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 JAA13742 for ; Wed, 18 Feb 2004 09:39:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSrQ-0003Dm-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 09:39:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSq4-0002wj-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 09:38:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtSo1-0002Zo-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 09:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSny-0003H7-KY; Wed, 18 Feb 2004 09: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 1AtSmy-000376-VS for lemonade@optimus.ietf.org; Wed, 18 Feb 2004 09:35:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12833; Wed, 18 Feb 2004 09:34:57 -0500 (EST) Message-Id: <200402181434.JAA12833@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: Wed, 18 Feb 2004 09:34:57 -0500 Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-goals-02.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.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. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Goals for Internet Messaging to Support Diverse Service Environments Author(s) : J. Wong Filename : draft-ietf-lemonade-goals-02.txt Pages : 34 Date : 2004-2-18 The mission of LEMONADE -- Internet Messaging to support diverse service environments -- is to provide a set of enhancements and profiles to Internet email to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. The enhanced mail service must continue to support conventional environments seamlessly. The primary driver for this effort is, by making Internet mail protocols richer and more media and environment-savvy, to allow their use over the mobile Internet. Stressing the needs of wireless handheld devices, a discussion is given of what is required of Internet messaging protocols to enable the support of multimedia messaging on limited capability messaging clients in diverse service environments. Also included is a list of general principles to guide the design of the enhanced messaging protocols. Finally, some issues around providing seamless service between enhanced Internet email and the existing separate mobile messaging infrastructure are briefly listed. Discussion of this and related drafts are on the LEMONADE WG email list. To subscribe, send the message 'subscribe' to lemonade-request@ietf.org. The public archive is in the directory at: ftp://ftp.ietf.org/ietf-mailing-lists/lemonade/ A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-goals-02.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-goals-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-goals-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-goals-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-goals-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094738.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 Feb 18 14:10:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09974 for ; Wed, 18 Feb 2004 14:10:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtX5X-0008Em-Kj for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 14:10:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IJARPg031656 for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 14:10:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtX5X-0008EU-Ez for lemonade-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 14:10: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 OAA09845 for ; Wed, 18 Feb 2004 14:10:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtX5V-00031z-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:10:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtX3G-0002XR-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:08:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtX1x-0002LN-05 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:06:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtWwT-0001pH-8I for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWwQ-0007ZR-Ok; Wed, 18 Feb 2004 14:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWvj-0007RM-I8 for lemonade@optimus.ietf.org; Wed, 18 Feb 2004 14:00:19 -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 OAA09172 for ; Wed, 18 Feb 2004 14:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWvh-0001oP-00 for lemonade@ietf.org; Wed, 18 Feb 2004 14:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWuo-0001iK-00 for lemonade@ietf.org; Wed, 18 Feb 2004 13:59:23 -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 1AtWu0-0001X0-00 for lemonade@ietf.org; Wed, 18 Feb 2004 13:58:32 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3); Wed, 18 Feb 2004 12:58:01 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a13] Date: Wed, 18 Feb 2004 12:57:59 -0600 To: Steve Hole From: Pete Resnick Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/15/04 at 10:47 PM -0700, Steve Hole wrote: >On Sat, 14 Feb 2004 11:12:43 -0600 Pete Resnick >wrote: > >>Would your opinion of this change if the mechanism we come up with >>does *not* do the composition work on the PULL server? That is, one >>of the proposals is to do all of the composition work on the IMAP >>server and then PULL only completed messages from there. (Some of >>the reasons for this are that it provides one solution to the "save >>a copy of the sent message" problem and it simplifies the protocol >>down to handing off a single URI.) I personally like this >>mechanism, for either PUSH or PULL. (I did write the draft on it, >>so it is close to my heart. :-) ). But it does limit the >>flexibility of the mechanism, since it would require PULL-ing only >>completed messages, and that's not something you're likely to find >>today via HTTP, for example. >> >>Would you still be in favor of PULL if it didn't provide the >>composition facility on the PULL server? > >The question is "why would you limit it"? I would make it any >valid URI scheme, with a mandatory to implement for the IMAP URL >scheme. That way you leave it up to the implementor to decide >which they will support. I'm not sure how you would advertise what >was supported, but it might not matter. Any implementation worth >it's salt would make such support extensible (factory) oriented so >that you can switch on the scheme and try >and find a suitable driver. No, that wasn't the question I was asking. In your implementation, you hand the submit server a template in XML that has pointers to the things to collect. That's different than what's being proposed here. The pull mechanism envisioned here is that the client issues effectively a special DATA command where it can say, "Here's some message headers" followed by "here's a URI to some data to insert here", followed by more text or more URIs. I'm not asking about limiting it to one URI scheme. I'm asking what you would think if we limited it to a single URI per command, with no surrounding text. That is, what would you think if composition was always done elsewhere and the submit server was only ever handed a single URI to a completed message? 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 Wed Feb 18 14:50:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14479 for ; Wed, 18 Feb 2004 14:50:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXhr-0003ir-PO for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 14:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IJo3ew014301 for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 14: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 1AtXhr-0003iW-FP for lemonade-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 14:50: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 OAA14400 for ; Wed, 18 Feb 2004 14:50:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXho-00012G-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:50:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXgq-0000vU-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:49:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtXfs-0000nP-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 14:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXft-0003Yd-Nm; Wed, 18 Feb 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXfG-0003Up-FT for lemonade@optimus.ietf.org; Wed, 18 Feb 2004 14:47: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 OAA14172 for ; Wed, 18 Feb 2004 14:47:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXfD-0000iq-00 for lemonade@ietf.org; Wed, 18 Feb 2004 14:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXeP-0000bJ-00 for lemonade@ietf.org; Wed, 18 Feb 2004 14:46:29 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx with esmtp (Exim 4.12) id 1AtXdM-0000Uc-00 for lemonade@ietf.org; Wed, 18 Feb 2004 14:45:24 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1IJjNwa031024; Wed, 18 Feb 2004 11:45:23 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i1IJjNA2024941; Wed, 18 Feb 2004 11:45:23 -0800 Date: Wed, 18 Feb 2004 11:45:23 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Steve Hole , lemonade@ietf.org Subject: Re: [lemonade] Re: Can I offer you some lemonade? In-Reply-To: Message-ID: References: MIME-Version: 1.0 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=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, 18 Feb 2004, Pete Resnick wrote: > In your implementation, you hand the submit server a template in XML that has > pointers to the things to collect. That's different than what's being proposed > here. The pull mechanism envisioned here is that the client issues effectively > a special DATA command where it can say, "Here's some message headers" followed > by "here's a URI to some data to insert here", followed by more text or more > URIs. Not necessarily. It is possible to dispense with BURL entirely and go to a Embedded URL only mechanism such as what Steve did. Doing so is not particularly draft or fcc friendly, which is why I didn't include that possibility in the Pull draft; nor did I hear much of a constituency for this type of solution prior to Steve's message. I wouldn't object to it though if that's the way the wind ended up. > I'm not asking about limiting it to one URI scheme. I'm asking what you > would think if we limited it to a single URI per command, with no surrounding > text. That is, what would you think if composition was always done elsewhere > and the submit server was only ever handed a single URI to a completed message? That's the CATENATE/BURL variant of Pull, and it is described in the Pull draft. There are benefits to that variant, but also severe deficiencies. I don't think that we should talk about restrictions that force that variant without first considering the other variants. -- 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 Wed Feb 18 15:09:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15792 for ; Wed, 18 Feb 2004 15:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtY0M-0003QK-IS for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 15:09:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IK9AOK013154 for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 15:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtY0M-0003Q5-CK for lemonade-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 15:09: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 PAA15695 for ; Wed, 18 Feb 2004 15:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtY0J-0002Pg-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 15:09:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXzH-0002IQ-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 15:08:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtXyH-0002Bj-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 15:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXyI-00024i-OO; Wed, 18 Feb 2004 15:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXxU-0001ZO-Ca for lemonade@optimus.ietf.org; Wed, 18 Feb 2004 15:06: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 PAA15292 for ; Wed, 18 Feb 2004 15:06:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXxR-00026j-00 for lemonade@ietf.org; Wed, 18 Feb 2004 15:06:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXwb-00023O-00 for lemonade@ietf.org; Wed, 18 Feb 2004 15:05:17 -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 1AtXw2-0001zh-00 for lemonade@ietf.org; Wed, 18 Feb 2004 15:04:42 -0500 Received: from [216.43.25.67] (10.50.16.33) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3); Wed, 18 Feb 2004 14:04:11 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a13] Date: Wed, 18 Feb 2004 14:04:07 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: Steve Hole , lemonade@ietf.org 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=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/18/04 at 11:45 AM -0800, Mark Crispin wrote: >On Wed, 18 Feb 2004, Pete Resnick wrote: >>In your implementation, you hand the submit server a template in >>XML that has pointers to the things to collect. That's different >>than what's being proposed here. > >Not necessarily. It is possible to dispense with BURL entirely and >go to a Embedded URL only mechanism such as what Steve did. I didn't intend to (nor do I think I did) say that it wasn't possible. Only that it wasn't currently being proposed. >Doing so is not particularly draft or fcc friendly, which is why I >didn't include that possibility in the Pull draft; nor did I hear >much of a constituency for this type of solution prior to Steve's >message. I think there was actually some earlier opposition to it due to complexity. It is of course compatible with push as well. >>I'm not asking about limiting it to one URI scheme. I'm asking what >>you would think if we limited it to a single URI per command, with >>no surrounding text. That is, what would you think if composition >>was always done elsewhere and the submit server was only ever >>handed a single URI to a completed message? > >That's the CATENATE/BURL variant of Pull, and it is described in the >Pull draft. Right. That's what I was asking for an opinion of. >There are benefits to that variant, but also severe deficiencies. I >don't think that we should talk about restrictions that force that >variant without first considering the other variants. I'm not asking anyone to disregard the other variants. I am asking for an opinion on that particular variant. If Steve (or others) responded, "That variant makes me feel even more strongly that pull is the way to go for such and so reasons", or alternatively, "Eeek! If that were the only variant left on the table, I'd rather go with push", I think that would be interesting information to know. 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 Wed Feb 18 16:19:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21531 for ; Wed, 18 Feb 2004 16:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ5z-0006vh-G9 for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 16:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILJ39W026636 for lemonade-archive@odin.ietf.org; Wed, 18 Feb 2004 16:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ5z-0006vX-Am for lemonade-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 16:19: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 QAA21447 for ; Wed, 18 Feb 2004 16:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ5x-0000oj-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 16:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZ4N-0000Xf-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 16:17:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ37-0000Kz-00 for lemonade-web-archive@ietf.org; Wed, 18 Feb 2004 16:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ34-0005lC-Kf; Wed, 18 Feb 2004 16: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 1AtZ2s-0005k4-CH for lemonade@optimus.ietf.org; Wed, 18 Feb 2004 16: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 QAA21021 for ; Wed, 18 Feb 2004 16:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ2q-0000Id-00 for lemonade@ietf.org; Wed, 18 Feb 2004 16:15:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZ1s-000092-00 for lemonade@ietf.org; Wed, 18 Feb 2004 16:14:48 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AtZ0v-00001o-01 for lemonade@ietf.org; Wed, 18 Feb 2004 16:13:52 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 10736; Wed, 18 Feb 2004 16:14:03 -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, 18 Feb 2004 16:13:18 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1AC@zoe.office.snowshore.com> Thread-Topic: Call for Scribes Thread-Index: AcP2Y/grs0ypB6twTMadIZUC21KY7A== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Call for Scribes 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: quoted-printable Content-Transfer-Encoding: quoted-printable We need two volunteers. One is for taking minutes, the other is for a = Jabber scribe. This is an excellent opportunity for you to get your name published in = IETF Proceedings. It is a great job for one of our many lurkers -- you = get "paid" to stay focused on the discussion. Since a great many contributors to lemonade are in Europe and North = America and may not have multicast access, Jabber is more important than = ever for this meeting. Please respond to me OFF LIST if you are interested. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Thu Feb 19 00:16:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13811 for ; Thu, 19 Feb 2004 00:16:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgXa-0005BF-Ry for lemonade-archive@odin.ietf.org; Thu, 19 Feb 2004 00:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J5G2LX019907 for lemonade-archive@odin.ietf.org; Thu, 19 Feb 2004 00: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 1AtgXa-0005B0-MX for lemonade-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 00:16: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 AAA13790 for ; Thu, 19 Feb 2004 00:15:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgXY-0002ai-00 for lemonade-web-archive@ietf.org; Thu, 19 Feb 2004 00:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgWb-0002X2-00 for lemonade-web-archive@ietf.org; Thu, 19 Feb 2004 00:15:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtgVc-0002Th-00 for lemonade-web-archive@ietf.org; Thu, 19 Feb 2004 00:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgVc-00054a-TA; Thu, 19 Feb 2004 00:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgUj-00052b-IH for lemonade@optimus.ietf.org; Thu, 19 Feb 2004 00:13:05 -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 AAA13661 for ; Thu, 19 Feb 2004 00:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgUh-0002Pp-00 for lemonade@ietf.org; Thu, 19 Feb 2004 00:13:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgTo-0002MN-00 for lemonade@ietf.org; Thu, 19 Feb 2004 00:12:09 -0500 Received: from rembrandt.esys.ca ([198.161.92.131]) by ietf-mx with esmtp (Exim 4.12) id 1AtgTC-0002Ic-00 for lemonade@ietf.org; Thu, 19 Feb 2004 00:11:30 -0500 Received: from kepler.esys.ca (h24-66-6-197.ed.shawcable.net [24.66.6.197]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i1J5Aw522313; Wed, 18 Feb 2004 22:10:58 -0700 From: Steve Hole Date: Wed, 18 Feb 2004 22:11:23 -0700 To: Pete Resnick Subject: Re: [lemonade] Re: Can I offer you some lemonade? Cc: lemonade@ietf.org In-Reply-To: References: Message-ID: Priority: NORMAL X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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 On Wed, 18 Feb 2004 12:57:59 -0600 Pete Resnick =20 wrote: > No, that wasn't the question I was asking. >=20 > In your implementation, you hand the submit server a template in XML=20 > that has pointers to the things to collect. That's different than=20 > what's being proposed here. The pull mechanism envisioned here is=20 > that the client issues effectively a special DATA command where it=20 > can say, "Here's some message headers" followed by "here's a URI to=20 > some data to insert here", followed by more text or more URIs. I'm=20 > not asking about limiting it to one URI scheme.=20 Ah! In my implementation the submit server (or moral equivalent) actually=20 interprets the MIME structure (as expressed by the XML specification). I= t builds the message from the inline data and the "pulled" external content= . I wasn't able to find the BURL draft so I wasn't sure how you were going= =20 to do it in the submit server. I mistakenly assumed that the submit=20 server would be MIME smart and would expand URI references within the MIM= E body structure (within a Content-{mumble} header) to insert external=20 content. What you have described is simpler in that the submit server doesn't have= =20 to know anything about MIME and you don't require any extensions to the=20 MIME format to represent the insert data. The submitting MUA has to writ= e out the data with the appropriate breaks for external inserts -- which=20 would be somewhat awkward in the MIME dumpers (formatters) that I've=20 worked with, but not impossible. It's certainly easier than adding MIME= =20 smarts into the submit agent. > I'm asking what you=20 > would think if we limited it to a single URI per command, with no=20 > surrounding text. That is, what would you think if composition was=20 > always done elsewhere and the submit server was only ever handed a=20 > single URI to a completed message? Well, it just seems like you then have to have composition knowledge in=20 three applications (MUA->COMPOSER->SUBMIT) rather than just (MUA->SUBMIT)= . I'm not sure why you would want to do that.=20 So, once again, I don't see why you would want to limit it. I suspect=20 it's because most MIME formatters dump a complete serialized message into= =20 a temporary buffer (memory or file) and then just blast it out. Breakin= g that into pieces will mean changing existing implementations. I don't=20 think it's any worse (and likely easier) than adding MIME dumper smarts t= o=20 an IMAP server. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 23 01:01:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25870 for ; Mon, 23 Feb 2004 01:01: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 1Av99I-0008CP-Es for lemonade-archive@odin.ietf.org; Mon, 23 Feb 2004 01:01:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N610sX031517 for lemonade-archive@odin.ietf.org; Mon, 23 Feb 2004 01:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av99I-0008CG-9C for lemonade-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 01:01:00 -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 BAA25859 for ; Mon, 23 Feb 2004 01:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av99F-0003dv-00 for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 01:00:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av98G-0003an-00 for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 00:59:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av97O-0003YL-00 for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 00:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av97M-00087k-IB; Mon, 23 Feb 2004 00:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av96O-00087O-1i for lemonade@optimus.ietf.org; Mon, 23 Feb 2004 00:58:00 -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 AAA25795 for ; Mon, 23 Feb 2004 00:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av96L-0003UI-00 for lemonade@ietf.org; Mon, 23 Feb 2004 00:57:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av95O-0003RY-00 for lemonade@ietf.org; Mon, 23 Feb 2004 00:56:59 -0500 Received: from inet-mail4.oracle.com ([148.87.2.204]) by ietf-mx with esmtp (Exim 4.12) id 1Av952-0003Ox-00 for lemonade@ietf.org; Mon, 23 Feb 2004 00:56:36 -0500 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i1N5snYA012050 for ; Sun, 22 Feb 2004 21:54:49 -0800 (PST) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i1N5twb08519 for ; Sun, 22 Feb 2004 22:55:58 -0700 (MST) Received: from oracle-8qdrvd34 (dhcp-amer-vpn-gw2-east-141-144-81-177.vpn.oracle.com [141.144.81.177]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i1N5twb08510 for ; Sun, 22 Feb 2004 22:55:58 -0700 (MST) Message-Id: <200402230555.i1N5twb08510@rgmgw4.us.oracle.com> From: "Stephane H. Maes" To: lemonade@ietf.org Date: Sun, 22 Feb 2004 21:55:40 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [lemonade] RE: Submission of an I-D to Lemonade 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=1.6 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Re-sending... Draft can be found at http://www.ietf.org/internet-drafts/draft-maes-lemona= de-p-imap-00.txt. Thanks Stephane -----Original Message----- From: Stephane H. Maes [mailto:stephane.maes@oracle.com] = Sent: Wednesday, February 18, 2004 5:07 PM To: lemonade@ietf.org Cc: e.burger@ieee.org; gparsons@nortelnetworks.com; Eric Burger Subject: Submission of an I-D to Lemonade We have submitted an internet draft that discusses optimizing the use of IM= APv4 rev1 for mobile e-mail and in particular to support push e-mail. I was= expecting to see it sent to the group and waited to send this. However I h= ave not seen anything yet... So here it goes. We would appreciate if could = be considered by Lemonade. = In the submitted draft, we attempt to share some of the experiences that we= have acquired in deploying secure end-to-end solutions for mobile access t= o e-mail and the feedback that we have received from numerous partners who = have reviewed, debugged and validated the approach. Our work is largely ins= pired by some of the discussions that have taken place in fora like IETF/Le= monade, OMA, 3GPP and 3GPP2. In the present draft, we focus on the secure exchanges between an IMAP e-ma= il corporate server (or a proxy in front of it) and a mobile terminal, in o= rder to support the use cases listed below (non-exhaustive list): - An e-mail arrives at the corporate server of a mobile worker. The client= on the terminal is as soon as possible securely notified of the new e-mail= . Based on the preferences of the user, the notification is made available = to the user or the client securely fetches the new e-mail or portions of it= (e.g. header, few first kB, whole body without attachment or whole e-mail)= .= - An e-mail is composed by a mobile worker. Upon selecting to send the e-m= ail, it is immediately securely sent from the corporate e-mail server of th= e user (and not another server). - Changes performed by the mobile worker in his e-mail client (e.g. deleti= ng and e-mail or moving it from one e-mail folder to another) are immediate= ly reflected to the corporate server, if prescribed by the user or his or h= er preferences (e.g. a deleted e-mail may or may not have to be deleted on = the server; the change from un-read to read may be systematically reflected= in the mail server etc.). - While mobile, a user sets and change filtering rules that specify when a= new e-mail arriving at the corporate e-mail must be reflected in the mobil= e client. - Depending on the network / service provider available to the mobile work= er (e.g. underlying network technology, roaming, cost etc.), he or she can = change behaviour of the mobile e-mail and appropriately provision for : - Secure notification of all or filtered new e-mails (and possibly other = events) through separate messaging mechanisms (e.g. SMS, MMS, Push) followe= d by: - Automated secure retrieval in a data session - Manual secure retrieval in a data session - Secure browsing access (e.g. WAP, Web, Voice) - An always on connection with notification of all or filtered new e-mail= s (and possibly other events) followed by automated or manual retrieval wit= hin the same session. - etc... - The mobile user can at any time synchronize his e-mail either over the a= ir as mobile e-mail (with the corporate server) or over cradle (e.g. over T= CP/IP or other synchronization via cradle, bluetooth, IRDA, ...) with a lap= top. = If appropriate, we would like this to be discussed in Seoul. = We hope that this contribution will be found useful by the Lemonade group. Thanks Stephane _____ = Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporatio= n. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Mon Feb 23 14:42:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15016 for ; Mon, 23 Feb 2004 14:42:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLxP-0002z7-E3 for lemonade-archive@odin.ietf.org; Mon, 23 Feb 2004 14:41:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJfZMS011469 for lemonade-archive@odin.ietf.org; Mon, 23 Feb 2004 14:41:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLxO-0002yu-TD for lemonade-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 14:41:34 -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 OAA14969 for ; Mon, 23 Feb 2004 14:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLxM-0004x6-00 for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 14:41:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLwV-0004sh-00 for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 14:40:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvLvv-0004np-00 for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 14:40:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvLvv-0002g6-Ii for lemonade-web-archive@ietf.org; Mon, 23 Feb 2004 14:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLvt-0002tA-P2; Mon, 23 Feb 2004 14:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLvJ-0002jc-2j for lemonade@optimus.ietf.org; Mon, 23 Feb 2004 14:39:25 -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 OAA14801 for ; Mon, 23 Feb 2004 14:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLvG-0004lf-00 for lemonade@ietf.org; Mon, 23 Feb 2004 14:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLuJ-0004hE-00 for lemonade@ietf.org; Mon, 23 Feb 2004 14:38:24 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AvLtN-0004ZL-00 for lemonade@ietf.org; Mon, 23 Feb 2004 14:37:25 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 23566; Mon, 23 Feb 2004 14:37:20 -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: Mon, 23 Feb 2004 14:36:54 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D8428D4@zoe.office.snowshore.com> Thread-Topic: Draft agenda Thread-Index: AcP6RF79/y25BIuHT3G+KUwrDhQs/w== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Draft agenda 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: quoted-printable Content-Transfer-Encoding: quoted-printable Any comments? If you have a burning desire to "present" a Draft or = Position, please contact me off-list. I will post the formal agenda tomorrow. Document status: 5min - ietf-lemonade-goals - wglc?=20 - shveidel-mediasize - status=20 - vaudreuil-futuredelivery - wg review?=20 - ietf-lemonade-imap-channel - hold for push/pull?=20 Chair issue: 30sec - Get agreement NOT to extend charter=20 Open issues:=20 Server-to-Server Notification (10 min) Push v. Pull (2+ hours) - crispin-lemonade-pull=20 - crispin-imap-urlauth=20 - newman-lemonade-compose=20 - ietf-lemonade-catenate-01.txt=20 - ietf-lemonade-submit=20 - gellens-lemonade-push=20 - maes-lemonade-p-imap=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Sun Feb 29 20:53:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22858 for ; Sun, 29 Feb 2004 20:53:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcbl-0001nA-82 for lemonade-archive@odin.ietf.org; Sun, 29 Feb 2004 20:52:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211qbiw006882 for lemonade-archive@odin.ietf.org; Sun, 29 Feb 2004 20:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcbl-0001mv-0Y for lemonade-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:52:37 -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 UAA22777 for ; Sun, 29 Feb 2004 20:52:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axcbi-0003oU-00 for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 20:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcaR-0003VA-00 for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 20:51:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxcYX-000365-00 for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 20:49:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxcYX-0007Z4-RQ for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 20:49:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcYL-00018B-LQ; Sun, 29 Feb 2004 20:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcXx-00012p-JV for lemonade@optimus.ietf.org; Sun, 29 Feb 2004 20:48: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 UAA22218 for ; Sun, 29 Feb 2004 20:48:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcXv-0002yp-00 for lemonade@ietf.org; Sun, 29 Feb 2004 20:48:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcWT-0002aE-00 for lemonade@ietf.org; Sun, 29 Feb 2004 20:47:10 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AxcUM-000260-00 for lemonade@ietf.org; Sun, 29 Feb 2004 20:44:58 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 25888; Sun, 29 Feb 2004 20:44:31 -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: Sun, 29 Feb 2004 20:44:29 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A208@zoe.office.snowshore.com> Thread-Topic: Presentations Thread-Index: AcP/LnMLhTtObEg0RmaJVd2tCDe3/w== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Presentations 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: quoted-printable Content-Transfer-Encoding: quoted-printable If you are planning on giving a presentation at IETF 59 for lemonade, = please sent it to me by 5pm tomorrow, Korea time. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From exim@www1.ietf.org Sun Feb 29 21:06:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23600 for ; Sun, 29 Feb 2004 21:06:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcoK-0002pt-Lw for lemonade-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2125aU3010900 for lemonade-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcoK-0002pj-HH for lemonade-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:05: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 VAA23431 for ; Sun, 29 Feb 2004 21:05:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcoI-0005Bs-00 for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 21:05:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcnT-00051B-00 for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 21:04:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axcml-0004tO-05 for lemonade-web-archive@ietf.org; Sun, 29 Feb 2004 21:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axciy-0002X4-G2; Sun, 29 Feb 2004 21:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcP1-0008NV-Cu for lemonade@optimus.ietf.org; Sun, 29 Feb 2004 20: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 UAA21460 for ; Sun, 29 Feb 2004 20:39:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcOz-0001WB-00 for lemonade@ietf.org; Sun, 29 Feb 2004 20:39:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcOC-0001QC-00 for lemonade@ietf.org; Sun, 29 Feb 2004 20:38:37 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AxcNd-0001HK-00 for lemonade@ietf.org; Sun, 29 Feb 2004 20:38:01 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i211bPs09450 for ; Sun, 29 Feb 2004 20:37:25 -0500 (EST) Received: from zcard031.ca.nortel.com ([47.129.242.121]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3DA3HK; Sun, 29 Feb 2004 20:37:25 -0500 Received: from nortelnetworks.com (acart269.ca.nortel.com [47.130.17.138]) by zcard031.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 12CGP0N6; Sun, 29 Feb 2004 20:37:24 -0500 Message-ID: <404293D2.5418C007@nortelnetworks.com> Date: Sun, 29 Feb 2004 20:37:22 -0500 From: "Marcus D. Leech" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: lemonade@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [lemonade] Comments on PUSH and PULL drafts 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: 7bit Content-Transfer-Encoding: 7bit I've had a look at these two drafts, and I find that from a security point of view, I'm uncomfortable with the PULL concept. It (I think unnecessarily) creates what I call "trust inflation"--the IMAP server must trust some other party to ask for chunks of e-mail messages to be forwarded onwards. Making this work "right" requires a bunch of new security technology that is likely to be a fruitful spawning ground for security bugs. From an initial look at these documents, my feeling is that PUSH represents a safer path. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-2754 +1 613 763 2754 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade