Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

Cyrus Daboo <> Mon, 16 July 2007 16:16 UTC

Return-Path: <>
Received: from ( []) by (Postfix) with ESMTP id BF88C8053B for <>; Mon, 16 Jul 2007 09:16:21 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 804A714220F for <>; Mon, 16 Jul 2007 09:15:25 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at
X-Spam-Score: -2.212
X-Spam-Status: No, score=-2.212 tagged_above=-50 required=4 tests=[AWL=0.189, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0GCD4gqX0cpv for <>; Mon, 16 Jul 2007 09:15:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 39BD014220A for <>; Mon, 16 Jul 2007 09:15:25 -0700 (PDT)
Received: from TENCOSERVER.TencoAssembliesInc.local ( []) (authenticated bits=0) by ( with ESMTP id l6GGFETg023844; Mon, 16 Jul 2007 16:15:16 GMT
Received: from TENCOSERVER.TencoAssembliesInc.local ([]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Jul 2007 12:15:14 -0400
Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07162007-121511-11776.MMD@TencoAssembliesInc.local; Mon, 16 Jul 2007 12:15:11 -0400
X-From_: Mon Jul 16 16:04:15 2007
Received: from ( []) by ( with ESMTP id l6GG4E8d029825 for <>; Mon, 16 Jul 2007 16:04:15 GMT
Received: from lists by with local (Exim 4.50) id 1IAT2c-0000TK-Lj for; Mon, 16 Jul 2007 16:03:18 +0000
Received: from ([]) by with esmtp (Exim 4.50) id 1IAT2b-0000S6-8O for; Mon, 16 Jul 2007 16:03:17 +0000
Received: from ([] by with esmtp (Exim 4.63) (envelope-from <>) id 1IAT2a-0005On-4P for; Mon, 16 Jul 2007 16:03:16 +0000
Received: from ([]) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id l6GG31YK026799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 12:03:04 -0400
Date: Mon, 16 Jul 2007 12:02:56 -0400
From: Cyrus Daboo <>
To: "Mr. Demeanour" <>,,
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received-SPF: none
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: 1IAT2a-0005On-4P 815d88b0d27187a110b01902875aae65
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
X-Mailing-List: <> archive/latest/12728
Precedence: list
Resent-Message-Id: <>
Resent-Date: Mon, 16 Jul 2007 16:03:18 +0000
X-Antivirus: Scanned by F-Prot Antivirus (
X-OriginalArrivalTime: 16 Jul 2007 16:15:14.0717 (UTC) FILETIME=[7E243CD0:01C7C7C4]
X-Mailman-Version: 2.1.5
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jul 2007 16:16:22 -0000

Hi Mr.,

--On July 16, 2007 4:41:22 PM +0100 "Mr. Demeanour" 
<> wrote:

>> Hi Mr.,
> Perhaps I should have signed up using a less silly email address! My
> name is Jack Cleaver. I shall alter my list registration details "soon".

Sorry, my email client has an option to auto-generate the "Hi xxx" line by 
trying to extract the first name from the From email address. Doesn't 
always work well...

>> Returning partial data is important for "low capacity" devices such
>> as mobile devices, who arguably benefit the most from multiget as
>> well.
> OK, I appreciate that. IME the amount of data in a single CalDAV
> resource is generally under about 3K, unless there is an essay in the
> <description> field. But I take the point.

iCalendar data for large recurrence sets with lots of overridden instances 
can grow large. Also, attachments can be included inline with iCalendar 
data so those can get (very) big.

In terms of vCard, PHOTO or SOUND properties are defined, so those can add 
a lot of data.

>> Note that parsing the data is an implementation issue, e.g. servers
>> that store the data in a database can simply implement the the
>> "partial data" aspect by doing a query for only the requested
>> parameters etc.
> OK; I'm aware that the majority of CalDAV servers (perhaps the majority
> of DAV servers) rely on a database, and that as a consequence, data and
> properties are all implemented as columns in a RDB, and are therefore
> logically more-or-less equivalent. But that shouldn't colour the
> approach taken by spec-writers; otherwise we will end up with specs that
> place pressure on implementors to use a RDBMS. In the extreme, we'll end
> up with specs that implicitly mandate a RDBMS.

I agree...see below.

> Declaration of interest:
> my own project is to implement a CalDAV server that has no DBMS
> dependency - it's a servlet that uses exclusively the filesystem for
> storing data. I have repeatedly run into details in the specs that would
> have been *much* easier to implement had a database been my underlying
> store; typically these details relate to the blurred distinction between
> data and properties.

Actually I have worked on several CalDAV servers to date (something like 
three) and all had slightly different approaches to storing/indexing data. 
In one case it was a pure filesystem store and all queries, partial fetches 
had to go through an iCalendar parser etc - certainly did not perform great 
but was OK for low volume personal use. Another used a pure database 
backend, that was better but still had issues. Another uses the filesystem, 
but augments that with index files for handling queries.

So I think CalDAV and CardDAV do provide the flexibility that is needed - 
but performance will be affected by choice of backend - obviously.

Cyrus Daboo