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

Michel Sébastien <Sebastien.Michel@atos.net> Thu, 16 February 2012 09:07 UTC

Return-Path: <sebastien.michel@atos.net>
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 33BAC21F8497 for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 01:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level:
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 jaa01DeyC1ML for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 01:07:28 -0800 (PST)
Received: from smtp1.mail.atosorigin.com (smtp1.mail.atosorigin.com [160.92.103.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA89221F8712 for <imap5@ietf.org>; Thu, 16 Feb 2012 01:07:23 -0800 (PST)
Received: from filter.atosorigin.com (localhost [127.0.0.1]) by mxfed001 (Postfix) with ESMTP id 8626620001A5; Thu, 16 Feb 2012 10:07:20 +0100 (CET)
Received: from mail.awl.fr.atosorigin.com (serv-smtp-wse02.fr.atosworldline.com [160.92.103.181]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "mail.awl.fr.atosorigin.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by mxfed001 (Postfix) with ESMTP id 7FD9C20000B2; Thu, 16 Feb 2012 10:07:20 +0100 (CET)
Received: from frspx302.fr01.awl.atosorigin.net (10.24.253.187) by frspx402.priv.atos.fr (10.24.220.8) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 10:07:19 +0100
Received: from FRSPX100.fr01.awl.atosorigin.net ([10.24.253.184]) by frspx302.fr01.awl.atosorigin.net ([10.24.253.187]) with mapi; Thu, 16 Feb 2012 10:07:20 +0100
From: Michel Sébastien <Sebastien.Michel@atos.net>
To: Adrien de Croy <adrien@qbik.com>, Brandon Long <blong@google.com>
Date: Thu, 16 Feb 2012 10:07:18 +0100
Thread-Topic: [imap5] Designing a new replacement protocol for IMAP
Thread-Index: AczsRBoKf2dW8UGuRTKChTDcs3cNBAARZRpQ
Message-ID: <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net>
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>
In-Reply-To: <4F3C514F.1010602@qbik.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
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 09:07:31 -0000

>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


Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.