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

Julian Reschke <> Mon, 16 July 2007 17:01 UTC

Return-Path: <>
Received: from ( []) by (Postfix) with ESMTP id F018C8058A for <>; Mon, 16 Jul 2007 10:01:20 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id E5B9C14220D for <>; Mon, 16 Jul 2007 10:00:25 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at
X-Spam-Score: -1.46
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zkm+0Ine5BUf for <>; Mon, 16 Jul 2007 10:00: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 D07F7142201 for <>; Mon, 16 Jul 2007 10:00:24 -0700 (PDT)
Received: from TENCOSERVER.TencoAssembliesInc.local ( []) (authenticated bits=0) by ( with ESMTP id l6GH0C5H021391; Mon, 16 Jul 2007 17:00:13 GMT
Received: from TENCOSERVER.TencoAssembliesInc.local ([]) 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_: Mon Jul 16 16:46:18 2007
Received: from ( []) by ( with ESMTP id l6GGkFIP020153 for <>; Mon, 16 Jul 2007 16:46:16 GMT
Received: from lists by with local (Exim 4.50) id 1IAThI-00067V-Na for; Mon, 16 Jul 2007 16:45:21 +0000
Received: from ([]) by with esmtp (Exim 4.50) id 1IAThF-000658-EJ for; Mon, 16 Jul 2007 16:45:18 +0000
Received: from ([]) by with smtp (Exim 4.63) (envelope-from <>) id 1IAThA-0002F9-Hi for; Mon, 16 Jul 2007 16:45:14 +0000
Received: (qmail invoked by alias); 16 Jul 2007 16:45:02 -0000
Received: from (EHLO []) [] by (mp017) with SMTP; 16 Jul 2007 18:45:02 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19KiihwRfRKQvfNnoM+SYN+PwMl/olThcUfaOgqC3 VJ/5SPEfTgfLuu
Message-ID: <>
Date: Mon, 16 Jul 2007 18:44:56 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20060516 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Lisa Dusseault <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
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: 1IAThA-0002F9-Hi 08f5c29b9192548fa42435a4956e470e
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
X-Mailing-List: <> archive/latest/12734
Precedence: list
Resent-Message-Id: <>
Resent-Date: Mon, 16 Jul 2007 16:45:20 +0000
X-Antivirus: Scanned by F-Prot Antivirus (
X-OriginalArrivalTime: 16 Jul 2007 17:00:12.0375 (UTC) FILETIME=[C6122E70:01C7C7CA]
Cc: "Mr. Demeanour" <>,,
X-Mailman-Version: 2.1.5
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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