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

Julian Reschke <julian.reschke@gmx.de> Mon, 16 July 2007 17:01 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 F018C8058A for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 10:01:20 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5B9C14220D for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 10:00:25 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.46
X-Spam-Level:
X-Spam-Status: No, score=-1.46 tagged_above=-50 required=4 tests=[AWL=0.941, 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 zkm+0Ine5BUf for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 10:00:25 -0700 (PDT)
Received: from mail2506.carrierzone.com (mail2506.carrierzone.com [64.29.147.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D07F7142201 for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 10:00:24 -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 mail2506.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6GH0C5H021391; Mon, 16 Jul 2007 17:00:13 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 13:00:12 -0400
Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07162007-130011-11805.MMD@TencoAssembliesInc.local; Mon, 16 Jul 2007 13:00:11 -0400
X-From_: w3c-dist-auth-request@frink.w3.org Mon Jul 16 16:46:18 2007
X-Envelope-From: w3c-dist-auth-request@frink.w3.org
Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by mail226c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6GGkFIP020153 for <JTentilucci@tencoassemblies.com>; Mon, 16 Jul 2007 16:46:16 GMT
Received: from lists by frink.w3.org with local (Exim 4.50) id 1IAThI-00067V-Na for w3c-dist-auth-dist@listhub.w3.org; Mon, 16 Jul 2007 16:45:21 +0000
Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1IAThF-000658-EJ for w3c-dist-auth@listhub.w3.org; Mon, 16 Jul 2007 16:45:18 +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 1IAThA-0002F9-Hi for w3c-dist-auth@w3.org; Mon, 16 Jul 2007 16:45:14 +0000
Received: (qmail invoked by alias); 16 Jul 2007 16:45:02 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 16 Jul 2007 18:45:02 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19KiihwRfRKQvfNnoM+SYN+PwMl/olThcUfaOgqC3 VJ/5SPEfTgfLuu
Message-ID: <469BA088.3060709@gmx.de>
Date: Mon, 16 Jul 2007 18:44:56 +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: Lisa Dusseault <lisa@osafoundation.org>
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> <469B9319.7090204@gmx.de> <6A114647AE869FB6B3252EDC@caldav.corp.apple.com> <9FCFEB85-5FCE-4F4A-8724-C2642E17943F@osafoundation.org>
In-Reply-To: <9FCFEB85-5FCE-4F4A-8724-C2642E17943F@osafoundation.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 1IAThA-0002F9-Hi 08f5c29b9192548fa42435a4956e470e
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/469BA088.3060709@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/12734
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: <E1IAThI-00067V-Na@frink.w3.org>
Resent-Date: Mon, 16 Jul 2007 16:45:20 +0000
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-OriginalArrivalTime: 16 Jul 2007 17:00:12.0375 (UTC) FILETIME=[C6122E70:01C7C7CA]
Cc: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>, w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
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 17:01:21 -0000

Lisa Dusseault wrote:
> 
> Synchronization for bodies is also better-defined than synchronization 
> for properties.  With the choice of CalDAV bodies plus multiget:
>  - clients can view just the ETags for a collection to see what bodies 
> have changed
>  - clients can ask for the bodies of the changed/new resources
>  - clients don't have to worry about synchronizing property values -- 
> property values are outside the calendaring domain, and the server's 
> business

Now wouldn't it be nice if a client could check for changed resources 
*and* get their content in a single request? That seems to be something 
obvious missing from the multiget report.

> Why not put the content or data in the body of the resource?   For 
> calendaring, that's the entire iCalendar object, even though some of the 
> iCalendar insides are structured that doesn't mean they're metadata -- 
> they *are* the data.  Non-Calendar stuff like ETag is true metadata.   
> It's a confusion in terminology (that WebDAV uses "property" for 
> metadata while iCalendar uses "property" for structured data) that 
> continually tempts us to use WebDAV metadata storage, instead of data 
> storage,  for iCalendar data.

I totally agree that the specs should treat calendar/address book 
objects as proper HTTP resources. What I was mainly complaining about 
was that the content (or parts of the content) are treated as 
"pseudo-properties" for some reports, instead of making them proper 
(computed) properties (or to change the marshalling in the report so 
that no pseudo-properties are introduced).

Everytime a spec defines a new name for a pseudo property (to be used 
where otherwise property names are allowed), that name becomes unusable 
for a true property anyway, so there's really no point at all not to 
expose that information in PROPFIND as well. Fewer special cases, please.

> We still don't have the ability to synchronize property values in 
> WebDAV.  We could start designing that, but there's not a strong call 
> to, unless we start getting confused and put data into the metadata.

That's a separate issue that should be solved. As a matter of fact, I 
think I've got a good idea to address this and other related things, but 
I didn't have time so far to write it down (famous last words, I know).

Best regards, Julian