From apps-discuss-bounces@ietf.org Wed Dec 3 10:45:32 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62AA3A6B53; Wed, 3 Dec 2008 10:45:32 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8623A6B53 for ; Wed, 3 Dec 2008 10:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw8tgfhD+PRO for ; Wed, 3 Dec 2008 10:45:31 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 0989D3A6B23 for ; Wed, 3 Dec 2008 10:45:31 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3882431wfd.31 for ; Wed, 03 Dec 2008 10:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=Z1XdvzgDJyycStVz0GmOqeReggDM5vFGS2HUCll+JEA=; b=mwHuKb8CwjRY6JznTyzdEKGKxJ+Lw5E8X9T//3g9Jh+4/XqevqMCr3XnOTQpuMb2pj E5E5rB8qFVWhjQdusp/c0VPnIT5fD7uKV4X76ZBmySL/xBsx0cAkvNtgahg9OY3+YWX9 rw3p2q6gvVQRtgEGRwuyQkTxv0R0MiHbASfJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=eS3hPHbz0yu0yBfDCMzPPDKb/9qcVKuflRBUwqjRtENY3Lfsx4nC+L1636JyxFL2j1 pX9wZtGhXuJjG4oe2XQcqdFczxjegVJWiS4wHUFE6q0t9dO4go9kJ8Ir1VlRLseavB0k Eqak0n2Fl1NmzLd8Wp/JIIoB8KdUJulWzlRRE= Received: by 10.141.141.3 with SMTP id t3mr6448286rvn.106.1228329926310; Wed, 03 Dec 2008 10:45:26 -0800 (PST) Received: by 10.141.201.10 with HTTP; Wed, 3 Dec 2008 10:45:26 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2008 10:45:26 -0800 From: "Lisa Dusseault" To: discuss@ietf.org Subject: Fwd: Your new mailing list: httpmail In-Reply-To: <001501c948e8$6cf11040$46d330c0$@com> MIME-Version: 1.0 References: <001501c948e8$6cf11040$46d330c0$@com> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242305018==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1242305018== Content-Type: multipart/alternative; boundary="----=_Part_113280_21746872.1228329926316" ------=_Part_113280_21746872.1228329926316 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I created a new mailing list to discuss HTTPMail ( http://tools.ietf.org/html/draft-dusseault-httpmail-00): https://www.ietf.org/mailman/listinfo/httpmail I have been thinking about this for a while, but delayed because I wasn't sure there was really enough demand for a new client access protocol. But I've started thinking of it as foremost a remote 3rd-party interface to an email store, which is a rather different niche. It would be good for email to have the same interconnectivity opportunities as the Web has (or better). Lisa ------=_Part_113280_21746872.1228329926316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I created a new mailing list to discuss HTTPMail (http://tools.ietf.org/html/draft-dusseault-httpmail-00):

   https://www.ietf.org/mailman/listinfo/httpmail

I have been thinking about this for a while, but delayed because I wasn't sure there was really enough demand for a new client access protocol.  But I've started thinking of it as foremost a remote 3rd-party interface to an email store, which is a rather different niche.  It would be good for email to have the same interconnectivity opportunities as the Web has (or better).

Lisa

------=_Part_113280_21746872.1228329926316-- --===============1242305018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1242305018==-- From apps-discuss-bounces@ietf.org Wed Dec 3 12:26:47 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B349D3A6820; Wed, 3 Dec 2008 12:26:47 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08D43A6820 for ; Wed, 3 Dec 2008 12:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPusuGd9ixSp for ; Wed, 3 Dec 2008 12:26:46 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 95E173A67ED for ; Wed, 3 Dec 2008 12:26:45 -0800 (PST) Received: from [192.168.0.3] (adsl-67-124-148-132.dsl.pltn13.pacbell.net [67.124.148.132]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id mB3KQcPO002158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 12:26:39 -0800 Message-ID: <4936EB85.3050800@dcrocker.net> Date: Wed, 03 Dec 2008 12:26:45 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Fwd: Your new mailing list: httpmail References: <001501c948e8$6cf11040$46d330c0$@com> In-Reply-To: X-Virus-Scanned: ClamAV 0.92/8718/Wed Dec 3 05:29:03 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 03 Dec 2008 12:26:39 -0800 (PST) Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Lisa, From an architectural standpoint, how is this different from replicating (a subset of) IMAP functionality but running it over HTTP? Not surprisingly, I'd particularly like to see a reference to the line segment(s) in: that the spec targets. Stated differently, what functionality does this supply that is not already provided by existing email protocols? I've looked over your discussion in the draft but am not yet understanding these motivating points. One obvious possibility is that it is IMAP that can more easily get through a firewall. I'm guessing you have something more substantial in mind. Can you clarify? (And yes, I think it useful to do it on this mailing list, first, rather than the new one.) Thanks. d/ ps. Lisa Dusseault wrote: > I created a new mailing list to discuss HTTPMail > (http://tools.ietf.org/html/draft-dusseault-httpmail-00): > > https://www.ietf.org/mailman/listinfo/httpmail > > I have been thinking about this for a while, but delayed because I > wasn't sure there was really enough demand for a new client access > protocol. But I've started thinking of it as foremost a remote > 3rd-party interface to an email store, which is a rather different > niche. It would be good for email to have the same interconnectivity > opportunities as the Web has (or better). -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Wed Dec 3 14:51:15 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819ED3A6A2D; Wed, 3 Dec 2008 14:51:15 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690EA3A6A69 for ; Wed, 3 Dec 2008 14:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0DT7QHlflaR for ; Wed, 3 Dec 2008 14:51:13 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id DF8753A67DA for ; Wed, 3 Dec 2008 14:50:49 -0800 (PST) Received: from gateout02 (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id F18F04BCE6F; Wed, 3 Dec 2008 22:50:44 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02 via smtad (C8.MAIN.3.45U) with ESMTP id XID909mLcwYt0698Xo2; Wed, 03 Dec 2008 22:50:44 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID909mLcwYt0698Xo2 Received: from [10.1.1.130] ([157.22.41.236]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 15:50:44 -0700 Message-Id: From: Lisa Dusseault To: Lisa Dusseault's Chairs , Apps Discuss Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Lisa's Apps Area Activity Report for Nov 2008 Date: Wed, 3 Dec 2008 14:50:42 -0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 03 Dec 2008 22:50:44.0732 (UTC) FILETIME=[935AABC0:01C95599] Cc: Philippe Bossut , Allan Schiffman , Robert Sayre X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411960581==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1411960581== Content-Type: multipart/alternative; boundary=Apple-Mail-2-929339337 --Apple-Mail-2-929339337 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit News, updates ALTO is now a WG and its mailing list moved to alto@ietf.org. Chairs are Vijay Gurbani, Enrico Marocco and Jon Peterson. OAUTH BOF was encouraging but not conclusive; new mailing list oauth@ietf.org . Document Status and Progress Active Documents: my action - draft-montemurro-gsma-imei-urn (Info): need to review new version - draft-ietf-sieve-mime-loop (PS): AD Evaluation - draft-ietf-calsify-rfc2445bis (PS): Cleaning up last issues after IETF Last Call with chairs and authors - draft-kucherawy-sender-auth-header (PS): Just finished IETF Last Call and new version quickly posted. I need to review this new version. Stalled, in review, waiting on other: - draft-freed-sieve-ihave (PS): In IETF Last Call - draft-irtf-asrg-dnsbl (Info): This went back to the IRTF when we found there wasn't consensus for an IETF Proposed Standard as it stands. Instead, I'm now just shepherding this to make sure it passes the IESG check of "does this conflict with IETF work". - draft-ietf-calsify-rfc2446bis (PS): Waiting for issues from another review to be addressed. I requested IETF Last Call prematurely. - draft-ietf-sieve-notify-mailto (PS): Scheduled for IESG Evaluation Dec 4. - draft-snell-atompub-bidi (PS): A couple changes needed after IESG Evaluation. - draft-ietf-usefor-usepro (PS): Finished IETF Last Call. Authors and chairs need to decide whether/what changes to make. - draft-wilde-sms-uri (PS): IESG Evaluation found a number of issues. Author needs to revise or respond. Finished Processing -- new in RFC Ed queue and new RFCs - draft-ietf-lemonade-msgevent (PS): DISCUSS cleared, now in RFC Ed queue. - draft-ietf-sieve-refuse-reject (PS): Now in RFC Ed queue. - draft-sanchez-webdav-current-principal (PS): Now in RFC Ed queue. WG Status CALSIFY: Plugging away on issues. HTTPBIS: Plugging away on issues. IDNABIS: Still discussing philosophical approach but also still making progress on doc organization. SIEVE: Finishing up several docs. USEFOR: No action since last report. --Apple-Mail-2-929339337 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
alto@ietf.org. =  Chairs are Vijay Gurbani, Enrico Marocco and Jon = Peterson.
OAUTH BOF was encouraging but not conclusive; new mailing = list oauth@ietf.org.

Document = Status and Progress

Active Documents: my = action
 - draft-montemurro-gsma-imei-urn (Info): need to = review new version
 - draft-ietf-sieve-mime-loop = (PS): AD Evaluation
 - draft-ietf-calsify-rfc2445bis (PS): =  Cleaning up last issues after IETF Last Call with chairs and = authors
 - draft-kucherawy-sender-auth-header (PS): Just = finished IETF Last Call and new version quickly posted.  I need to = review this new version.

Stalled, in = review, waiting on other:
 - draft-freed-sieve-ihave = (PS): In IETF Last Call
 - draft-irtf-asrg-dnsbl (Info): This = went back to the IRTF when we found there wasn't consensus for an IETF = Proposed Standard as it stands.  Instead, I'm now just shepherding = this to make sure it passes the IESG check of "does this conflict with = IETF work".
 - draft-ietf-calsify-rfc2446bis (PS): Waiting for = issues from another review to be addressed.  I requested IETF Last = Call prematurely.
 - draft-ietf-sieve-notify-mailto (PS): =  Scheduled for IESG Evaluation Dec 4.
 - = draft-snell-atompub-bidi (PS): A couple changes needed after IESG = Evaluation.
 - draft-ietf-usefor-usepro (PS): Finished IETF Last = Call.  Authors and chairs need to decide whether/what changes to = make.
 - draft-wilde-sms-uri (PS): IESG Evaluation found a = number of issues. Author needs to revise or respond.

Finished = Processing -- new in RFC Ed queue and new RFCs
 - = draft-ietf-lemonade-msgevent (PS): DISCUSS cleared, now in RFC Ed = queue.
 - draft-ietf-sieve-refuse-reject (PS):  Now in RFC = Ed queue.
 - draft-sanchez-webdav-current-principal (PS): Now in = RFC Ed queue.

WG Status
CALSIFY: = Plugging away on issues.
HTTPBIS:   Plugging away on = issues.
IDNABIS:  Still discussing philosophical approach but = also still making progress on doc organization.
SIEVE: Finishing up = several docs. 
USEFOR:  No action since last = report.
= --Apple-Mail-2-929339337-- --===============1411960581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1411960581==-- From apps-discuss-bounces@ietf.org Fri Dec 5 07:14:53 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1793A6C7E; Fri, 5 Dec 2008 07:14:53 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C605D28C15F for ; Fri, 5 Dec 2008 07:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYCa4Y-h8UCK for ; Fri, 5 Dec 2008 07:14:51 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id BAD603A6C7F for ; Fri, 5 Dec 2008 07:14:51 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB5FED9o000353 for ; Fri, 5 Dec 2008 10:14:13 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5FEcL41265700 for ; Fri, 5 Dec 2008 10:14:38 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5FEb3H004293 for ; Fri, 5 Dec 2008 08:14:37 -0700 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB5FEb9j004281; Fri, 5 Dec 2008 08:14:37 -0700 Received: from Uranus-009002090249.watson.ibm.com ([9.2.90.249]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1228490077.3136; Fri, 05 Dec 2008 10:14:37 -0400 Date: Fri, 05 Dec 2008 10:14:34 -0500 From: Barry Leiba To: dcrocker@bbiw.net Subject: Re: Fwd: Your new mailing list: httpmail Message-ID: In-Reply-To: <4936EB85.3050800@dcrocker.net> References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > Stated differently, what functionality does this supply that is not already > provided by existing email protocols? The point here is exactly that it defines a standard way to run this stuff over HTTP, so that a web browser (or other HTTP client) can do this without having to implement IMAP or POP. The spec says that it's not meant to replace the email protocols, but to provide an alternative. In particular: - It defines how to discover mailboxes. - It defines how to represent mailbox contents in Atom. That lets any feed reader (or browser that can read feeds) display a mailbox. - It recommends permalinks for email messages, allowing browsers to cache them. The main motivating point is the desire to access mail stores using HTTP. If you don't think there's a need for that, then clearly you won't see the point of Lisa's draft. Barry _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Dec 5 09:23:13 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1F928C1C7; Fri, 5 Dec 2008 09:23:13 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03253A6AFD for ; Fri, 5 Dec 2008 09:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCBclVmVBRhP for ; Fri, 5 Dec 2008 09:23:10 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 20C073A6825 for ; Fri, 5 Dec 2008 09:23:09 -0800 (PST) Received: from [192.168.0.3] (adsl-67-124-148-132.dsl.pltn13.pacbell.net [67.124.148.132]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id mB5HN2RY010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 09:23:02 -0800 Message-ID: <49396375.7000008@bbiw.net> Date: Fri, 05 Dec 2008 09:23:01 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Barry Leiba Subject: Re: Fwd: Your new mailing list: httpmail References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> In-Reply-To: X-Virus-Scanned: ClamAV 0.92/8728/Fri Dec 5 07:44:27 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Dec 2008 09:23:03 -0800 (PST) Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Barry Leiba wrote: >> Stated differently, what functionality does this supply that is not >> already provided by existing email protocols? > > The point here is exactly that it defines a standard way to run this > stuff over HTTP, so that a web browser (or other HTTP client) can do > this without having to implement IMAP or POP. From what I can tell, the proposed protocol works between what is really a mail user agent (MAU) and what is really a message store (MS). If I have that wrong, please clarify. So a comparison between this protocol and the obvious existing ones is natural. And that's a key beginning point: You are still proposling implementing *some* protocol. So my question is why is it appropriate to invent a new protocol, rather than re-home an existing one to use HTTP (rather than, say, TCP) as its transport? There can be any number of very good reasons. For example, it might be that HTTP has characteristics that are so different from TCP, it isn't practical to re-use an existing one. It might be that the existing ones do not match the desired functionality. It might be that the existing ones are much too complicated. It's difficult to imagine claiming that IMAP is too complicated, but gosh, maybe it is... And so on. Personally, I'm a fan of protocol competition. (In contrast, the IETF in recent years has tended to eschew competitive, or even related, protocol efforts.) Competition gave us SNMP rather than CMIP. SMTP/822/MIME rather than X.400. TCP rather than TP*. And so on. In each case, the dominant political preference tended to be for the protocol that, in the long run, lost. And I believe in each case, the winner triumphed on its technical merits. But I think it important to consider the competitive differences that are significant. For example, the mere fact that the transport layer is different doesn't automatically justify inventing a new protocol. New protocols are hugely expensive, in terms of time, effort and dollars. That's why we so often re-purpose existing ones. For example, one could imagine taking a query service designed to map between a name and an address and instead using it for obtaining encryption keys. All of the underlying query technology, infrastructure deployment and operational skills for re-using that technology, would therefor be saved, when compared against deploying a new key query infrastructure... Similarly, there is a vast base of code and experience with existing MUA/MS protocols. Why not re-use it? To repeat: I'm not saying the work shouldn't be done. Rather I'm saying that being clear about what work is actually needed is important before starting a process that will take years and spend many millions of dollars. (I think that you and everyone else recognizes that that is what it takes to deploy a new protocol.) Make vs. buy is always an extremely strategic choice. So it helps to make it carefully. The spec says that it's > not meant to replace the email protocols, but to provide an alternative. > > In particular: > - It defines how to discover mailboxes. OK. New function. Why not add it to IMAP? (One could argue that POP already contains it.) > - It defines how to represent mailbox contents in Atom. That lets any > feed reader (or browser that can read feeds) display a mailbox. I didn't see this discussed, as such, in the draft, but it sounds interesting. Basically it seems to create a competitive choice between re-using existing IMAP mailbox constructs versus Atom mailbox constructs. Exploring that choice in terms of software, ops, and experience strikes me a potentially enlightening. > - It recommends permalinks for email messages, allowing browsers to > cache them. A new construct, but one that comes from long debate, including recently within the IMAP community, I believe. > The main motivating point is the desire to access mail stores using > HTTP. If you don't think there's a need for that, then clearly you > won't see the point of Lisa's draft. I hope that, from my above comments, you now understand that I'm not trying to challenge the goal of HTTP-based access -- although I think it worth gaining community consensus about why such a goal is anything other than an attempt to end-run firewall protection -- but rather to note that achieving that goal does not obviously preclude using existing protocols by re-homing them on the new 'transport' layer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Dec 5 11:26:18 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CCB28C11A; Fri, 5 Dec 2008 11:26:18 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6449F3A6B4C for ; Fri, 5 Dec 2008 11:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kabgiYhjBgH for ; Fri, 5 Dec 2008 11:26:16 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 8A8713A6B35 for ; Fri, 5 Dec 2008 11:26:16 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id mB5JQ0ks020441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Dec 2008 11:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1228505170; x=1228591570; bh=vLEdzHsrJw+M+YTEKpt9tDw1VgU9su7BXk9artBVal4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=isy/VM9lIz3INpFN7lY0M5tBt63s75goFRBa2sJMKlnVDXaxeZcKtMh1IRN/RWZfw k5KXtENLQ+sXUDyhZsjpe8DLyEgvdyL4guMYKujon1AOWuVU8n2XllHFc1ZApRjRQ6 GnMpCrh8D4iCJgxHZcba3lTbFt2sYWyn8ZlgJEjM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=yLUxOcbfIBLTYbFfu4R2+E9jHWNqRpFAzCUD4aJlhWgjMy4+XbX8Oi9+1KxhNfgcV 50yEMW04oYrxfcw3MokPqMejkknMaP20bkDpsykLbCGWYDtUgFScCN2feZ5wQvqpp0w U23y3qVpB0/hpZKQKC/RhYdQTZuY/d+FhZHry88= Message-Id: <6.2.5.6.2.20081205102410.03012658@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 Dec 2008 11:23:21 -0800 To: discuss@ietf.org From: SM Subject: Re: Fwd: Your new mailing list: httpmail In-Reply-To: <49396375.7000008@bbiw.net> References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> <49396375.7000008@bbiw.net> Mime-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At 09:23 05-12-2008, Dave CROCKER wrote: > From what I can tell, the proposed protocol works between what is > really a mail user agent (MAU) and what is really a message store > (MS). If I have that wrong, please clarify. As I see it, the proposed protocol is not between a mail user agent and a message store. It can extend the concept of message access beyond what we generally see in mail user agents. As far as I'm aware, we don't have mashup functionality in mail user agents. That alone opens new avenues to how messages can be presented. >I hope that, from my above comments, you now understand that I'm not >trying to challenge the goal of HTTP-based access -- although I >think it worth gaining community consensus about why such a goal is >anything other than an attempt to end-run firewall protection -- but >rather to note that achieving that goal does not obviously preclude >using existing protocols by re-homing them on the new 'transport' layer. We could view the access as a way to get around firewall protection. Or we could see it as a way to access messages with a browser. Whether we like it or not, the browser is a driver when it comes to presenting information. What this proposal brings us is also a layer of simplicity. There's still the question of complexity when it comes to message/rfc822 parsing but that's a separate issue. The applicability goes beyond what is mentioned in the draft. Regards, -sm _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Dec 5 15:31:29 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3BB3A6836; Fri, 5 Dec 2008 15:31:29 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D34D3A6403 for ; Fri, 5 Dec 2008 15:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWynr4YKXVvC for ; Fri, 5 Dec 2008 15:31:27 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 6FC513A6836 for ; Fri, 5 Dec 2008 15:31:27 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so214510rvf.49 for ; Fri, 05 Dec 2008 15:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=LSCnZNDNRkGUu5D6pMWOS2Na3ZNXB/OlyczCUTsEcWs=; b=q2HFtJtSptJTItDXJLSPb7jYPOoPYQrZdc3XTH+3L+BgEddggR/V2ROzbRon7HTJrd Nu75mAYpfVHVvTpX4i9W3txH6cjYVsLnWIunvz6C8YLmKnPZRjMf+WbBd+G/Fn/GuCCh bNzqGOUJ+p9QSp0voOxaMEzWjXS8edVtLYzEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=cWiqIrUuwN1QuAYeqO2TbCr2Ul6r2ZvHfWPyU9TJWwB/vgPvm3uIQOVRPTz6MnaMMr BQ6ZoA3R1Tx6APMi8PDXAkAC8+zgAMVHAH5iDhPyMtknqb5EjQyQ2DY/nrHDpaFuQ1T3 P5gQov6DQcmFTNr4mkWSqFN5Fkf649k4rlRCc= Received: by 10.141.201.1 with SMTP id d1mr232766rvq.293.1228519881790; Fri, 05 Dec 2008 15:31:21 -0800 (PST) Received: by 10.141.201.10 with HTTP; Fri, 5 Dec 2008 15:31:21 -0800 (PST) Message-ID: Date: Fri, 5 Dec 2008 15:31:21 -0800 From: "Lisa Dusseault" To: "Dave CROCKER" Subject: Re: Fwd: Your new mailing list: httpmail In-Reply-To: <49396375.7000008@bbiw.net> MIME-Version: 1.0 References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> <49396375.7000008@bbiw.net> Cc: Barry Leiba , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0049283400==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0049283400== Content-Type: multipart/alternative; boundary="----=_Part_31571_4787333.1228519881768" ------=_Part_31571_4787333.1228519881768 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Dec 5, 2008 at 9:23 AM, Dave CROCKER wrote: > > > - It defines how to represent mailbox contents in Atom. That lets any feed >> reader (or browser that can read feeds) display a mailbox. >> > > I didn't see this discussed, as such, in the draft, but it sounds > interesting. > > Basically it seems to create a competitive choice between re-using existing > IMAP mailbox constructs versus Atom mailbox constructs. Exploring that > choice in terms of software, ops, and experience strikes me a potentially > enlightening. This is in fact pretty key to the proposal: a new set of tools, libraries and even approaches that can be looped in. I worked on this with Jeff Lindsay, and in the roughly three days we sat together and worked on it, I wrote the draft and he wrote this, heavily leaning on existing libraries: http://github.com/progrium/httpmail/tree/master It doesn't do everything, but it did work as a proxy between a native Atom newsreader and a native IMAP store. No changes were needed to the actual mail store or to the Atom newsreader. Lisa ------=_Part_31571_4787333.1228519881768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Dec 5, 2008 at 9:23 AM, Dave CROCKER <dcrocker@bbiw.net> wrote:


- It defines how to represent mailbox contents in Atom.  That lets any feed reader (or browser that can read feeds) display a mailbox.

I didn't see this discussed, as such, in the draft, but it sounds interesting.

Basically it seems to create a competitive choice between re-using existing IMAP mailbox constructs versus Atom mailbox constructs.  Exploring that choice in terms of software, ops, and experience strikes me a potentially enlightening.

This is in fact pretty key to the proposal: a new set of tools, libraries and even approaches that can be looped in.  I worked on this with Jeff Lindsay, and in the roughly three days we sat together and worked on it, I wrote the draft and he wrote this, heavily leaning on existing libraries:

http://github.com/progrium/httpmail/tree/master

It doesn't do everything, but it did work as a proxy between a native Atom newsreader and a native IMAP store.   No changes were needed to the actual mail store or to the Atom newsreader.

Lisa


------=_Part_31571_4787333.1228519881768-- --===============0049283400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0049283400==-- From apps-discuss-bounces@ietf.org Fri Dec 5 18:45:38 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9709F3A6876; Fri, 5 Dec 2008 18:45:38 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253913A69A9 for ; Wed, 3 Dec 2008 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tfa+Rm2qETn for ; Wed, 3 Dec 2008 11:03:01 -0800 (PST) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 1E5DD3A6958 for ; Wed, 3 Dec 2008 11:03:01 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA02.westchester.pa.mail.comcast.net with comcast id mi7h1a00N0vyq2s52j2HDV; Wed, 03 Dec 2008 19:02:17 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA05.westchester.pa.mail.comcast.net with comcast id mj2W1a00Y1cMU3H3Rj2Yd0; Wed, 03 Dec 2008 19:02:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=tlkHy73vH0IxYQvppRYA:9 a=HF4cbGfBK0LOhQ0BrMkA:7 a=YUka7APVPqQBHmYG16fJdsfyizgA:4 a=lZB815dzVvQA:10 a=3SmO1NJXDBsA:10 Message-Id: <7625000C-DF32-4CF8-AF01-CA7E6B033317@lilacglade.org> From: Margaret Wasserman To: IETF Discussion , Internet Area , IPv6 Operations , "behave@ietf.org WG" , apps-discuss@ietf.org, Routing Research Group Mailing List , IESG IESG , IAB Mime-Version: 1.0 (Apple Message framework v929.2) Subject: New NAT66 Discussion List Date: Wed, 3 Dec 2008 14:02:29 -0500 X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Fri, 05 Dec 2008 18:45:36 -0800 Cc: nat66@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Hi Everyone, I am sending this message to several large groups of people with considerable overlap in an effort to reach everyone who has been participating (actively or passively) in the NAT66 discussions. PLEASE, PLEASE do not reply to this full list. Send any replies to the new nat66 discussion list (cc:ed) or to me privately. In response to concerns that have been raised about discussing IPv6-to- IPv6 NAT on the behave WG mailing list, we have started a new mailing list for the ongoing NAT66 discussion, nat66@ietf.org. The purpose of this list is to discuss the needs that may drive the adoption of IPv6- to-IPv6 NAT, and to discuss solutions to meet those needs, possibly including specification of an IPv6 NAT mechanism, that will work better and be less harmful to the Internet than direct ports of IPv4 NA(P)T functionality. Although we will see how the conversation evolves in the upcoming weeks, our current expectation is that we will hold a BOF at IETF 74 in San Francisco to discuss this topic and to determine if there is consensus that the IETF should pursue any work in this area. It is not our intention that this new list will be used for discuss of IPv4/IPv6 transition mechanisms, even those that involve translation. Discussion of the v4v6translation work will remain in the behave WG, where it is a chartered work item. If you would like to join the nat66 mailing list list or read the list archives, you can do so via the following URL: https://www.ietf.org/mailman/listinfo/nat66 If you would like to actively contribute to the discussion, I would suggest that you start by reading the following documents: - RFC 4864: Local Network Protection for IPv6 http://www.ietf.org/rfc/rfc4864.txt?number=4864 - Renumbering still needs work http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.txt - IPv6-to-IPv6 Network Address Translation (NAT66) -- now somewhat out- of-date http://www.ietf.org/rfc/rfc4864.txt?number=4864 - IETF 73 behave WG Presentation on NAT66 -- more up-to-date http://www.ietf.org/proceedings/08nov/slides/behave-14.pdf Then, come join the discussion on the nat66@ietf.org mailing list. Margaret _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Dec 6 08:05:10 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835103A67FC; Sat, 6 Dec 2008 08:05:10 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA7D3A67FC for ; Sat, 6 Dec 2008 08:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRW0OS92j2gv for ; Sat, 6 Dec 2008 08:05:08 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EFBE13A67E6 for ; Sat, 6 Dec 2008 08:05:07 -0800 (PST) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L8zeF-000PI8-Bq; Sat, 06 Dec 2008 11:04:51 -0500 Date: Sat, 06 Dec 2008 11:04:50 -0500 From: John C Klensin To: Dave CROCKER , Barry Leiba Subject: Re: Fwd: Your new mailing list: httpmail Message-ID: <22FC814D7799859053BFF232@p3.int.jck.com> In-Reply-To: <49396375.7000008@bbiw.net> References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> <49396375.7000008@bbiw.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At the risk of agreeing with Dave (or even appearing to do so) on an actual protocol matter... While I disagree with several of his specific examples, I think there is a related point to be considered. We really don't have a Mail Store -> Mail-reading-MUA protocol, partially because of the "Split UA" model that has been argued to be a fundamental part of the IMAP and POP architectures. But, from that point of view, the HTTP-based approach supplied here is just another kind of Split UA and Dave's "do we really have an adequate reason to invent a third one" question seems exactly right. I also note that we have never tried to standardize an interface or API for access to a mail store from an MUA running on the same system, although that is the classic model with its many variations. So, let me add a question to Dave's: if the desire for this work is such as to justify thinking about a new Split UA protocol to complement POP and IMAP, should we not, instead, finally be thinking about whether we know enough to standardize basic mail store primitives and access in a way that could support POP, IMAP, some sort of HTTP thing(s), _and_ local MUA systems? Obviously, it would be a larger piece of work, but it would have a lot more leverage on protocols and design development. It is possible that the often-asked, but rarely actually considered, question of what a minimal/ core/ primitive IMAP-ish protocol would look like if we designed it de novo today is equivalent to the question I'm trying to raise above. If so, maybe it is time. The answer may well be "no" to all of these questions but, as with Dave's questions, I think asking the questions carefully and being sure we have answers would considerable illuminate what actually needs to be done and how it would relate to what is out there already. john --On Friday, 05 December, 2008 09:23 -0800 Dave CROCKER wrote: > > > Barry Leiba wrote: >>> Stated differently, what functionality does this supply that >>> is not already provided by existing email protocols? >> >> The point here is exactly that it defines a standard way to >> run this stuff over HTTP, so that a web browser (or other >> HTTP client) can do this without having to implement IMAP or >> POP. > > From what I can tell, the proposed protocol works between > what is really a mail user agent (MAU) and what is really a > message store (MS). If I have that wrong, please clarify. > > So a comparison between this protocol and the obvious existing > ones is natural. >... _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Dec 6 16:35:39 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98AF3A68A4; Sat, 6 Dec 2008 16:35:38 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40FC3A68A4 for ; Sat, 6 Dec 2008 16:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJk8xdRicE6q for ; Sat, 6 Dec 2008 16:35:35 -0800 (PST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id 57FF53A67B3 for ; Sat, 6 Dec 2008 16:35:35 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39701) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1L97cA-0000Jr-Kv (Exim 4.70) (return-path ); Sun, 07 Dec 2008 00:35:14 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1L97cA-0004C3-Ez (Exim 4.67) (return-path ); Sun, 07 Dec 2008 00:35:14 +0000 Date: Sun, 7 Dec 2008 00:35:14 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: Fwd: Your new mailing list: httpmail In-Reply-To: <22FC814D7799859053BFF232@p3.int.jck.com> Message-ID: References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> <49396375.7000008@bbiw.net> <22FC814D7799859053BFF232@p3.int.jck.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: Barry Leiba , Dave CROCKER , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Sat, 6 Dec 2008, John C Klensin wrote: > > We really don't have a Mail Store -> Mail-reading-MUA protocol, > partially because of the "Split UA" model that has been argued > to be a fundamental part of the IMAP and POP architectures. What do you mean by "mail-reading-MUA"? Does it relate to one of the models described in RFC 1733? Why isn't IMAP this protocol? > It is possible that the often-asked, but rarely actually considered, > question of what a minimal/ core/ primitive IMAP-ish protocol would look > like if we designed it de novo today is equivalent to the question I'm > trying to raise above. If so, maybe it is time. There has been some discussion along these lines on the IMAP5 list. https://www.ietf.org/mailman/listinfo/imap5 Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH UTSIRE: NORTHWESTERLY BACKING SOUTHWESTERLY 4 OR 5. SLIGHT OR MODERATE. SHOWERS. GOOD. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Dec 6 16:59:40 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5331F3A69C0; Sat, 6 Dec 2008 16:59:40 -0800 (PST) X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5483A69B5 for ; Sat, 6 Dec 2008 16:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnWPW4n6Mhpq for ; Sat, 6 Dec 2008 16:59:38 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2524D3A6358 for ; Sat, 6 Dec 2008 16:59:38 -0800 (PST) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L97zY-0005Ls-82; Sat, 06 Dec 2008 19:59:24 -0500 Date: Sat, 06 Dec 2008 19:59:23 -0500 From: John C Klensin To: Tony Finch Subject: Re: Fwd: Your new mailing list: httpmail Message-ID: In-Reply-To: References: <001501c948e8$6cf11040$46d330c0$@com> <4936EB85.3050800@dcrocker.net> <49396375.7000008@bbiw.net> <22FC814D7799859053BFF232@p3.int.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: Barry Leiba , Dave CROCKER , discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --On Sunday, 07 December, 2008 00:35 +0000 Tony Finch wrote: > On Sat, 6 Dec 2008, John C Klensin wrote: >> >> We really don't have a Mail Store -> Mail-reading-MUA >> protocol, partially because of the "Split UA" model that has >> been argued to be a fundamental part of the IMAP and POP >> architectures. > > What do you mean by "mail-reading-MUA"? Does it relate to one > of the models described in RFC 1733? Why isn't IMAP this > protocol? :-) I was referring to such wonders of modern and advanced technology as the U**x "mail" command as well as more recent developments such as emacs mail mode, MH, XMH, and so on, i.e., mail-reading and composing programs that read information directly from the mail store on the same host (or that pretend, via NFS or its clones), to do so. Nothing so abstracted as IMAP. >> It is possible that the often-asked, but rarely actually >> considered, question of what a minimal/ core/ primitive >> IMAP-ish protocol would look like if we designed it de novo >> today is equivalent to the question I'm trying to raise >> above. If so, maybe it is time. > > There has been some discussion along these lines on the IMAP5 > list. https://www.ietf.org/mailman/listinfo/imap5 I am vaguely aware of that, and more aware of several other, more or less similar, discussions over the years. Collectively, they were what I was referring to as "often-asked, but rarely actually considered". My question, stated differently, is whether the suggested need for yet-another Split UA mail reading protocol might really be the indication that it is time to apply serious work to IMAP-core or IMAP--, or however one might want to model it instead (whether Lemonade has turned into IMAP++ but, as an intended set of profiles for IMAP4, never had the potential to do this work). john _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss