Re: [httpmail] Query for two clarifications

Lisa Dusseault <lisa.dusseault@gmail.com> Tue, 31 March 2009 14:42 UTC

Return-Path: <lisa.dusseault@gmail.com>
X-Original-To: httpmail@core3.amsl.com
Delivered-To: httpmail@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183F43A6D5A for <httpmail@core3.amsl.com>; Tue, 31 Mar 2009 07:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.861
X-Spam-Level:
X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 nr1+OSl8fcxa for <httpmail@core3.amsl.com>; Tue, 31 Mar 2009 07:42:47 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 388063A6D43 for <httpmail@ietf.org>; Tue, 31 Mar 2009 07:42:47 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so2559390qwb.31 for <httpmail@ietf.org>; Tue, 31 Mar 2009 07:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a5g19f1Zu142XQdVzOFZp+LK2wv04iii5yFA1XhChho=; b=EaBGvNuqtNIhJNBLDMRZDNdkqIibfZmXqlWLj/4Aqot/ss6C4oiX6PLhK5wmq6ClRi Lhx7V7i7ZKsR8Q3uJpmCUM+jwjuaoJ+422LFJ1VUbJSF3ZCRTHBVmkdQLYvYmgHxCbB8 ve3sdBG8oFeSbRAvGjmHiVDvocLtxNIZSl3/4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v3d28yMAOwAQo774RdOGKhw4c961WZrZ4jvkxmkzZQxAJXVLAOzkMD+n1s+08BpJ8J D2IS0Yn5/ZtvfgUTx1N+x3N+qRxJG1zruHMK/yAebgpPpC/3m1BScF4tNy6efIJq6yek LPKDMsrXTS7U44dzN8v+MH6zYdubi1WGWjzM4=
MIME-Version: 1.0
Received: by 10.220.96.139 with SMTP id h11mr2194493vcn.23.1238510626105; Tue, 31 Mar 2009 07:43:46 -0700 (PDT)
In-Reply-To: <49D203AD.9070807@gmail.com>
References: <49D203AD.9070807@gmail.com>
Date: Tue, 31 Mar 2009 07:43:45 -0700
Message-ID: <ca722a9e0903310743r6513df5cm64245a0af8bb5809@mail.gmail.com>
From: Lisa Dusseault <lisa.dusseault@gmail.com>
To: =?ISO-8859-2?Q?Marcin_Bazyd=B3o?= <marcin.bazydlo@gmail.com>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Cc: httpmail@ietf.org
Subject: Re: [httpmail] Query for two clarifications
X-BeenThere: httpmail@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of email store access via HTTP <httpmail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpmail>, <mailto:httpmail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpmail>
List-Post: <mailto:httpmail@ietf.org>
List-Help: <mailto:httpmail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpmail>, <mailto:httpmail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 14:42:48 -0000

Hi Marcin,

Thanks for reviewing the draft.

2009/3/31 Marcin Bazydło <marcin.bazydlo@gmail.com>om>:
> As far as I understood this draft it proposes representations for both list
> of directories and list of messages but it is impossible to have single feed
> containing both. Is there any reason for such separation?

One of the goals of the draft is to define something that an IMAP
server can support while still supporting IMAP clients.  But, to be
honest, I'm not sure if the separation of listing directories and
listing messages is necessary for that or not.

The next thing I'd consider would probably be use cases.  A lot of
clients display lists of directories in separate frames from lists of
messages, so it would make sense for those to be separate listings.
But there may be use cases that were overlooked.

>
> 2. Is access to message in rfc822 format really fitting this specification.
> As for finding mailboxes and listing directory contents sepcification leaves
> no option as to use atom protocol any client which is using this
> specification needs to implement parsing atom entries. Therefore it seems
> strange to leave for backwards compatibility access to old message format. I
> propose changing this format to recommended one not necessary.
> Old format shall be recommended because I can imagine that there exists some
> code base prepared for parsing rfc822 format which may lead to easier
> implementation in some cases (like addons to mail clients), but still I
> think most thin clients will prefer sticking to atom.
>

I am not aware of any other standard formats for the headers of a mail
message.  There would need to be a standard for converting a message
-- including MIME bodies, multipart, attachments and so on -- into a
more Atom-friendly format, and perhaps that's been done already, but
not to my knowledge.

Thanks!
Lisa