[httpmail] Query for two clarifications

Marcin Bazydło <marcin.bazydlo@gmail.com> Tue, 31 March 2009 11:50 UTC

Return-Path: <marcin.bazydlo@gmail.com>
X-Original-To: httpmail@core3.amsl.com
Delivered-To: httpmail@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C78803A687C for <httpmail@core3.amsl.com>; Tue, 31 Mar 2009 04:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.191
X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5ogzoinFLAbR for <httpmail@core3.amsl.com>; Tue, 31 Mar 2009 04:50:20 -0700 (PDT)
Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com []) by core3.amsl.com (Postfix) with ESMTP id A7A0B3A680D for <httpmail@ietf.org>; Tue, 31 Mar 2009 04:50:16 -0700 (PDT)
Received: by fxm2 with SMTP id 2so2393220fxm.37 for <httpmail@ietf.org>; Tue, 31 Mar 2009 04:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=hqOYW2vUnCvlE8uBM8hwCrjBmmJ4XXEXs0AVlWIBOPI=; b=gc14XOc33GFxcxKgf3sXvuCPiwY9x4aIUvvDLY4xyfXDyTXX6KnNaMEvWuFrhJ9Y04 6DxvRH/6LJ1qN8UFkSMauzjHSoovZb0RZAr1LlUOceJgS+Cs50pjBpi6tDIeQqjySfbg 4hBVUQ+fgTHVhRYm8CV6GdRzJNOtwE1jrUtSA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=vcqapGIk8UI7DbyAlsx7HgPHKNITr38UkzZiB57dPL3kylsxt9Zj+q2AQ8ooa+EsFo xd8KUk0xyvZ9H4iJpnyE3MxOsszJe8ycxa5HwVKDRyQjtkYUSVFVpok+bC1zUXCpQuuT XZXakPNDNsEDogIMdpKVocP/24U0NSdaARkZ0=
Received: by with SMTP id u8mr2224145mul.12.1238500275113; Tue, 31 Mar 2009 04:51:15 -0700 (PDT)
Received: from ? (77-253-18-100.adsl.inetia.pl []) by mx.google.com with ESMTPS id 12sm10890731muq.35.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Mar 2009 04:51:14 -0700 (PDT)
Message-ID: <49D203AD.9070807@gmail.com>
Date: Tue, 31 Mar 2009 13:51:09 +0200
From: Marcin Bazydło <marcin.bazydlo@gmail.com>
User-Agent: Thunderbird (X11/20090319)
MIME-Version: 1.0
To: httpmail@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [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 11:59:40 -0000

Dear all,

I am using this draft as a help for implementation of a little different 
mail service done restfully.
I see some assumptions made in this work which are not completly clear 
if anyone can present thei opinion on this issues I would be glad.

1. I have already prepared structure of uri's and planned to have 
directory like structure which is natural for most users. Important 
feature of directory like structure is that directory can contain both 
directories and messages.

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?

 From my point of view if I would like to be consistent with 
specification and check for changes in any directory it will need to 
queries from client - one for messages and other for directories. It 
will also request server to have two separate uri's for each.

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.

Best regards,
Marcin Bazydło
Poznań University of Technology