[Ietf-caldav] Alternative to splitting out components

Helge Hess helge.hess at opengroupware.org
Sat Aug 21 09:38:03 PDT 2004

On Aug 21, 2004, at 18:18, Cyrus Daboo wrote:
>> No, its not fuzzy at all. Its just a different concept and one which 
>> is
>> even gaining popularity in mail applications. There are few mail
>> applications now which do not support query folders (or virtual 
>> folders
>> or smart folders, whatever they are called ;-)
> The virtual/smart/query folder support right quite happily gets by 
> with the ACL per-mailbox model not the ACL per-message model.

Well, I guess this is getting off topic. With query folders the user 
looses the association of an object with its folder ACL because storage 
locations gets irrelevant for the user. So even if its internally 
implemented as per-folder ACLs it needs to be shown as ACLs attached to 
the object in the UI.
If you want we can continue this discussion in private mail, I don't 
think it belongs here ;-)

Lets get back on track by realizing that there all four variants are 
used in practice: no ACL, ACL per folder, ACL per object or both. To be 
interoperable, CalDAV needs to take this into account.
I don't think this should be about explaining any vendor how he is 
supposed to do things.

> Well I have been focused on users sharing mailboxes in IMAP for a long 
> time - I suspect a lot of other IMAP vendors would say the same.

OK. No offense was intended and the topic isn't IMAP4 anyway. (my main 
point was that emails are a very different kind of object not 
comparable to an event - we may or may not agree on that, not worth 
discussion in either case ;-)

> One of the things I would like to propose is the equivalent of IMAP's 
> NAMESPACE command - basically a WebDAV report that would return base 
> URLs for private, shared and public calendar hierarchies on the 
> server.

Why do I need a report for that, isn't that already covered by a DASL 
query on the collection type?


More information about the Ietf-caldav mailing list