[Ietf-caldav] Alternative to splitting out components
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
>> even gaining popularity in mail applications. There are few mail
>> applications now which do not support query folders (or virtual
>> 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
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