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

Julian Reschke <julian.reschke@gmx.de> Sun, 15 July 2007 10:31 UTC

Return-Path: <julian.reschke@gmx.de>
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 DECC880746 for <ietf-carddav@osafoundation.org>; Sun, 15 Jul 2007 03:31:04 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D020C14220A for <ietf-carddav@osafoundation.org>; Sun, 15 Jul 2007 03:30:09 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-50 required=4 tests=[AWL=1.050, BAYES_00=-2.599, 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 DuED6vgDSsHm for <ietf-carddav@osafoundation.org>; Sun, 15 Jul 2007 03:30:09 -0700 (PDT)
Received: from mail2526.carrierzone.com (mail2526.carrierzone.com [64.29.147.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6936B142207 for <ietf-carddav@osafoundation.org>; Sun, 15 Jul 2007 03:30:09 -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 mail2526.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6FAU4VZ022854; Sun, 15 Jul 2007 10:30:05 GMT
Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Sun, 15 Jul 2007 06:30:03 -0400
Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07152007-063002-11472.MMD@TencoAssembliesInc.local; Sun, 15 Jul 2007 06:30:02 -0400
X-From_: w3c-dist-auth-request@frink.w3.org Sun Jul 15 10:24:42 2007
X-Envelope-From: w3c-dist-auth-request@frink.w3.org
Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by mail223c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6FAOdSK014973 for <JTentilucci@tencoassemblies.com>; Sun, 15 Jul 2007 10:24:40 GMT
Received: from lists by frink.w3.org with local (Exim 4.50) id 1IA1Ef-0003RY-3Q for w3c-dist-auth-dist@listhub.w3.org; Sun, 15 Jul 2007 10:21:53 +0000
Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1IA1Ed-0003Qu-8x for w3c-dist-auth@listhub.w3.org; Sun, 15 Jul 2007 10:21:51 +0000
Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from <julian.reschke@gmx.de>) id 1IA1EZ-0001L2-H8 for w3c-dist-auth@w3.org; Sun, 15 Jul 2007 10:21:50 +0000
Received: (qmail invoked by alias); 15 Jul 2007 10:21:36 -0000
Received: from p508FB563.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.181.99] by mail.gmx.net (mp051) with SMTP; 15 Jul 2007 12:21:36 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19dgis2z8JdWv42HWHVy1uuzimbtxtG3O6pJkOiNP yIuSLGnFkXtPjw
Message-ID: <4699F52B.10101@gmx.de>
Date: Sun, 15 Jul 2007 12:21:31 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: ietf-carddav@osafoundation.org, WebDAV <w3c-dist-auth@w3.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1IA1EZ-0001L2-H8 3f005ddd381ae77f3a45d22e7d231787
X-Original-To: w3c-dist-auth@w3.org
X-Archived-At: http://www.w3.org/mid/4699F52B.10101@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/12717
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: <E1IA1Ef-0003RY-3Q@frink.w3.org>
Resent-Date: Sun, 15 Jul 2007 10:21:53 +0000
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-OriginalArrivalTime: 15 Jul 2007 10:30:03.0529 (UTC) FILETIME=[1AE5FF90:01C7C6CB]
Subject: [Ietf-carddav] Comments on draft-daboo-carddav-02
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: Sun, 15 Jul 2007 10:31:05 -0000

Below are some high-level comments on draft-daboo-carddav-02 
(<http://tools.ietf.org/html/draft-daboo-carddav-02>). I'm cross-posting 
this to the WebDAV and Carddav mailing lists, but will send a separate 
mail going into some other details of CardDAV just to the CardDAV 
mailing list.



The CardDAV design essentially is the same as for CalDAV, which has 
recently been approved by the IESG and been published as RFC4791. So it 
must be good, right?

Although I do agree that CalDAV solves an interesting problem, and that 
it is likely going to work in practice, it made several design decisions 
that I think hurt it with respect to acceptance, performance and 
generality. I understand that it's very tempting to just copy over the 
design; but I think it would be really good to reconsider the points below.


Overall design / new methods

Both specs use standard MIME types, and expose data through HTTP. This 
is a good thing. They also define new subclasses of WebDAV collections, 
which add some new constraints on their contents. I'm not entirely 
convinced that this is really needed, but in this case I'll trust the 
domain knowledge from the calendaring people. I'm not sure though 
whether the constraints for address books really require this.

The introduction of new DAV:resourcetypes however has lead to the 
introduction of new HTTP methods, with the single purpose of creating a 
WebDAV collection with a certain set of properties. I think this is an 
extremely bad idea.

Now I do *not* belong to the group of people with "new method angst". 
Defining new methods that have general applicability is completely ok 
IMHO. Good examples are COPY/MOVE, some of the versioning methods, BIND 
and so on. The difference to MKCALENDAR and MKADDRESSBOOK is that these 
ones are restricted to a single application use case. So what's next? 
MKPHOTOCOLLECTION? MKMUSIKCOLLECTION?

Instead, I'd suggest defining what MKCALENDAR and MKADDRESSBOOK have in 
common, and come up with a single solution to that. For instance, such 
as MKCOL using a request body that carries a set of properties, 
including the WebDAV resource type.


Use of Reports

Everytime a new REPORT is introduced, a new set of information is made 
hard to cache. In some cases that may be harmless (such as when it's 
something like a query, line in some RFC3744 reports).

However, defining a "multiget" really seems to be a bad idea, and now 
there are even two of those! Please take this out until it can be shown 
that just sending a bunch of GET requests (which can take advantage of 
caching) is not sufficient.


Property model

The specs avoid exposing the content of their data objects as WebDAV 
properties. This leads to lots of workarounds, such as introducing 
"pseudo-properties" containing the actual content 
(CARDDAV:addressbook-data), and abuse of DAV:prop for something that is 
not a WebDAV property. Don't do this, it requires generic WebDAV servers 
to use lots of special cases. (WebDAV SEARCH started with pseudo 
properties but got successfully rid of them, so this can be done).


Best regards, Julian