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

Cyrus Daboo <cyrus@daboo.name> Mon, 16 July 2007 16:16 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: ietf-carddav@osafoundation.org
Delivered-To: ietf-carddav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BF88C8053B for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 09:16:21 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 804A714220F for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 09:15:25 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.212
X-Spam-Level:
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 laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GCD4gqX0cpv for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 09:15:25 -0700 (PDT)
Received: from mail206c25.carrierzone.com (mail206c25.carrierzone.com [64.29.147.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 39BD014220A for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 09:15:25 -0700 (PDT)
X-Authenticated-User: master.tencoassemblies.com
Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail206c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6GGFETg023844; Mon, 16 Jul 2007 16:15:16 GMT
Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) 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_: w3c-dist-auth-request@frink.w3.org Mon Jul 16 16:04:15 2007
X-Envelope-From: w3c-dist-auth-request@frink.w3.org
Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by mail224c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6GG4E8d029825 for <JTentilucci@tencoassemblies.com>; Mon, 16 Jul 2007 16:04:15 GMT
Received: from lists by frink.w3.org with local (Exim 4.50) id 1IAT2c-0000TK-Lj for w3c-dist-auth-dist@listhub.w3.org; Mon, 16 Jul 2007 16:03:18 +0000
Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1IAT2b-0000S6-8O for w3c-dist-auth@listhub.w3.org; Mon, 16 Jul 2007 16:03:17 +0000
Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from <cyrus@daboo.name>) id 1IAT2a-0005On-4P for w3c-dist-auth@w3.org; Mon, 16 Jul 2007 16:03:16 +0000
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (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 <cyrus@daboo.name>
To: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>, w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
Message-ID: <39B02F60A891FA23662E5955@caldav.corp.apple.com>
In-Reply-To: <469B91A2.5000002@jackpot.uk.net>
References: <4699F52B.10101@gmx.de> <DA70918551A4706E579F3829@caldav.corp.apple.com> <469B8976.9040402@jackpot.uk.net> <C4E535EC204E5BF24F6076F0@caldav.corp.apple.com> <469B91A2.5000002@jackpot.uk.net>
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: maggie.w3.org 1IAT2a-0005On-4P 815d88b0d27187a110b01902875aae65
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
X-Archived-At: http://www.w3.org/mid/39B02F60A891FA23662E5955@caldav.corp.apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/12728
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Resent-Message-Id: <E1IAT2c-0000TK-Lj@frink.w3.org>
Resent-Date: Mon, 16 Jul 2007 16:03:18 +0000
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-OriginalArrivalTime: 16 Jul 2007 16:15:14.0717 (UTC) FILETIME=[7E243CD0:01C7C7C4]
X-BeenThere: ietf-carddav@osafoundation.org
X-Mailman-Version: 2.1.5
List-Id: ietf-carddav.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-carddav>
List-Post: <mailto:ietf-carddav@osafoundation.org>
List-Help: <mailto:ietf-carddav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=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" 
<mrdemeanour@jackpot.uk.net>; 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