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

Julian Reschke wrote:
> Mr. Demeanour wrote:
> 
>> This all feels a bit theoretical, though; to make all 
>> CalDAV/CardDAV content become instead grade-A properties would be a
>>  pretty fundamental change in approach, affecting five or six 
>> different RFCs, and I hesitate to suggest anything that radical 
>> (without working it through properly first!).
> 
> Sorry? It would only affect a single RFC (RFC4791), no?

Yes, you're quite right; my mistake.

There are other places in the RFCs where there is a confusion as to the
true nature of WebDAV properties; ACL is maybe the most obvious example.
That's what led me to make that remark.

I note Lisa's contribution:

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

If ETag is "true metadata", and CalDAV content is "real" data, then what
is the status of a WebDAV/CalDAV property such as <calendar-timezone>?
In iCalendar terms, a VTIMEZONE is an object with status equivalent to
(for example) a VEVENT - but not in CalDAV.

Yes, there are multiple terminological confusions regarding what is and
what is not a property, and what is data. If this subject could be
cleared up properly, I think that would be enormously beneficial.

I'd better finish (and publish) my project, and then sit back for a few
months' reflection. I think these are hard questions, and I'm a bit too
close to it to be able to see it clearly at the moment.

-- 
Jack.