[Ietf-caldav] CalDAV Notes
helge.hess at opengroupware.org
Fri May 13 14:48:27 PDT 2005
pretty old issues ;-) Anyway, I try to give some ideas from my
On 13. Mai 2005, at 21:21 Uhr, Lisa Dusseault wrote:
>> - do we need this for minimum compliance?
> When the CALSCH working group was working on CAP, the access
> control -- although a difficult piece of functionality to define
> and agree on -- was generally agreed to be required.
Yes, access control is required for "full" operation in an office
like environment (aka "groupware" ...).
But it is not necessarily required for minimum compliance. Eg the
popular iCalendar-over-HTTP sharing gets along quite well without
(protocol level) ACLs. The same goes for WebDAV - few clients support
ACLs, nevertheless its quite useful.
> With WebDAV to build on, most of the work of defining ACL is
> already done so now we consider mostly the implementation difficulty.
Unfortunately my in-memory-knowledge on WebDAV ACLs is a bit limited.
I remember that in the GroupDAV list we discussed to support a
minimalistic subset which only covers "readonly" information. (AFAIK
the only info which is supported by Kontact)
> Who else plans to implement or would have difficulty implementing
> or considers it a required use case?
Without knowing the details, I'm pretty sure that we would also
implement WebDAV ACLs. I have the impression its the only option
which makes sense.
> the question is whether a client that expected full ACL support
> would typically degrade gracefully if this was all the server offered.
=> exactly. I find it hard to imagine how a client can usefully
implement an interface to a permission system in a generic way. In
practice access-control is something which is very different between
Of course the whole set of "new" servers which are in development can
target for CalDAV /ACLwhich leaves the question whether CalDAV should/
needs-to work well with existing servers.
Summary: IMO WebDAV ACLs should be an optional feature. If the server
supports it, the client should offer ACL panels. If it doesn't,
access control could be implemented with server specific plugins.
> On the issue of how an existing server's data model works and
> whether calendars are just queries or whether per object ACLs
> exist... well, this is something that just must be upgraded to
> support CalDAV.
OK, thats basically an answer to my above question. CalDAV is not
supposed to work well with existing servers and will potentially
require major modifications for full compliance.
Unrelated [UID <-> URL mapping]:
> for example servers that do not have client-settable paths to
> calendar components (servers which may be implemented on databases
> and always use the UID) have an extra barrier to support PUT where
> the client chooses the URL to the new component. To implement this
> they have to upgrade their back-end store to include a table
> mapping client-selected URLs to back-end IDs.
I think I posted this question in a different mail, I wonder how this
is intended to work. If I remember right we have the requirement that
there is a 1:1 mapping between UID and resource in a given collection.
Who is responsible for ensuring that this is a 1:1 mapping? What
happens if two clients try to insert an event in a shared collection
(eg the same meeting proposal received by mail) - with the same UID
under different URLs?
There should be information on this situation in the spec.
IMO: the thing which probably calls for least trouble is to specify
that the UID is to be used as the URL (with .ics extension ;-).
Obviously this would give issues with "generic clients", but those
couldn't handle 1:1 errors either.
>> - you specify collection types as a complex XML property, eg:
>> <resourcetype xmlns="DAV">
>> I "predict" that this will give issues ;-) because a lot of servers
>> will map properties to simple key/stringvalue hashtables (eg
>> resourcetype=collection) (although of course XML content is
>> valid in
>> WebDAV properties, I think few are actually prepared for this)
> I don't understand this issue -- I agree servers will map
> properties like this to simple booleans in their back-end store,
> but since this is a read-only property, how is that a problem?
Its not really a server specific issue. A lot of implementations are
rather simplistic and use simple key/value tables instead of full DOM-
like tres to store property sets, which works well in most cases but
obviously breaks with more advanced uses of WebDAV.
Summary: I think clients/servers need to deal with this to implement
CalDAV. The resource typing as done by CalDAV makes sense.
>> - "Calendars MUST NOT contain other calendars"
>> - hm, why? I think this breaks the common Outlook model also
>> uses in
>> Evolution where you can nest object folders arbitary
> Is the Outlook/Evolution model confirmed?
I think starting with v2.0 Evolution doesn't support hierarchies
anymore (at least the UI doesn't). Kontact and Apple iCal also do not
support hierarchies at all.
Outlook/Exchange do support arbitary hierarchies of folders and so do
a lot of other servers (eg Kolab to name but one), mostly because
they are focused on serving Outlook.
> Is there some way to map that model to the CalDAV model -- e.g.
> declare only the deepest-nested of the collections a "calendar"?
Certainly you can find some hack, but it wouldn't be very natural.
> Our thinking when restricting this, was that making calendars one-
> level-only made it easier for a client to know how to display. We
> didn't have to worry about what it "meant" to have a calendar
> nested inside another calendar -- whether the events should be
> included in the parent calendar or not; whether to display them
Yes, someone else explained that before. Maybe this is an issue
though I personally would expect the WebDAV calendar hierarchy to be
self contained (no different to generic WebDAV collections). Not sure
why one would expect a special meaning for the containment.
Just thoughts on this, I'm fine with the current state. Personally I
don't need to have calendars below calendars.
>> 'For optimum interoperability with existing HTTP clients, CalDAV
>> clients and servers MUST use the file extension ".ics"'
> It will just make it easier to synchronize (perhaps with a generic
> sync application) to a local file system in a way that works -- and
> it's easy to do.
I can't see how, but anyway. No strong oposition against .ics though
such a MUST is certainly not how HTTP is supposed to work (it MUST
return a proper content-type, nothing else) ...
Its somewhat inconsistent to your other argumentation to allow for
such "hacks" in CalDAV.
> I agree that the use of report is one of those decisions that could
> be argued a number of ways, but I don't want to introduce another
> dependency (on XML-RPC or SOAP) when there's a workable WebDAV way
> to do this. Since SEARCH is now not required for CalDAV support, I
> think that falling back to DASL is no longer an option.
I had this discussion with Julian a while back and for me the
convincing point is that REPORT is already a standardized while
SEARCH is just a draft.
Waiting for the new draft :-)
More information about the Ietf-caldav