W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2007

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

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 16 Jul 2007 10:27:30 -0700
Message-Id: <4EBF6745-C9F3-4110-A5C8-AA20C5ED348F@osafoundation.org>
Cc: Cyrus Daboo <cyrus@daboo.name>, "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>, w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
To: Julian Reschke <julian.reschke@gmx.de>

On Jul 16, 2007, at 9:44 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
> 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.

I've worked on some synch stuff and it would be even nicer to make  
replication general, not specific to CalDAV.  So I agree, and I'm  
happy Cyrus is doing some work on that.

>> 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.

Fair enough.

>> 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).

Sounds intriguing.

Received on Monday, 16 July 2007 17:27:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC