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

[Julian Reschke <[e-mail]>]

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