[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
- [Ietf-carddav] presentations today and other "wg"… Marc Blanchet
- [Ietf-carddav] charter comments Marc Blanchet
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Wilfredo Sánchez Vega
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Cyrus Daboo
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Wilfredo Sánchez Vega
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Cyrus Daboo
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Cyrus Daboo
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Cyrus Daboo
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Cyrus Daboo
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Julian Reschke
- Re: [Ietf-carddav] Comments on draft-daboo-cardda… Cyrus Daboo
- [Ietf-carddav] Comments on draft-daboo-carddav-02 Julian Reschke