Re: [imap5] Designing a new replacement protocol for IMAP

Dave McMurtrie <dave64@andrew.cmu.edu> Thu, 16 February 2012 11:37 UTC

Return-Path: <dave64@andrew.cmu.edu>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0520C21F875C for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 03:37:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaCYzJYTu6k8 for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 03:37:26 -0800 (PST)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.96]) by ietfa.amsl.com (Postfix) with ESMTP id 5989221F875B for <imap5@ietf.org>; Thu, 16 Feb 2012 03:37:26 -0800 (PST)
Received: from administrators-macbook-pro-2.local (c-98-219-195-113.hsd1.pa.comcast.net [98.219.195.113]) (user=dave64 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id q1GBbOfJ008161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for <imap5@ietf.org>; Thu, 16 Feb 2012 06:37:25 -0500
Message-ID: <4F3CEA74.80807@andrew.cmu.edu>
Date: Thu, 16 Feb 2012 06:37:24 -0500
From: Dave McMurtrie <dave64@andrew.cmu.edu>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14
MIME-Version: 1.0
To: imap5@ietf.org
References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <alpine.LSU.2.00.1202151405550.30682@hermes-2.csi.cam.ac.uk> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <CABa8R6uoG_B1WWe1oHVOJVp-WzFrqCbVQ0pjbtpS7Y2sjROvww@mail.gmail.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com>
In-Reply-To: <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.9.4220
X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, BODY_SIZE_1400_1499 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, TO_NO_NAME 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_BROADBAND_5 0, __RDNS_POOLED_11 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 10%
X-Scanned-By: MIMEDefang 2.60 on 128.2.11.96
Subject: Re: [imap5] Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 11:37:27 -0000

On 2/16/12 4:59 AM, Adrien de Croy wrote:
>
>
> On 16/02/2012 10:07 p.m., Michel Sébastien wrote:
>>> On 16/02/2012 1:26 p.m., Brandon Long wrote:
>>>> This is the second time I've heard about concern that proxies would
>>>> break access to my mail data over http.
>>> layering other protocols over HTTP is currently an arms-race between
>>> client-software developers who want to do this, and proxy developers
>>> who want to provide the tools their customers (sys admins) ask for to
>>> allow them to prevent it.
>>>
>>> the harder it gets to block something intelligently, the more likely
>>> admins will resort to over-blocking. We see it every day.
>>>
>>> Developing a new protocol for mail designed ONLY to layer over HTTP
>>> is therefore extremely foolhardy. Sure by all means have options.
>> I'm not really convinced, does it means that CalDAV and CardDAV are on
>> the wrong way ? I think not, even if they are not supported by all
>> mobile platforms
>
> well, deploying CalDAV to a corporate environment has all sorts of
> issues. You want to run your CalDAV server on a computer running a web
> server? Port conflict. Or you need to wedge it into your web server
> somehow.

The Cyrus Project aims to include CalDAV support as part of the Cyrus 
IMAP server, which would make CalDAV deployment much simpler for any 
sites that are already running Cyrus.

Dave