CalDAV clients SHOULD support downloading of external attachments referenced by arbitrary URI schemes, by either processing them directly, or by passing the attachment URI to a suitable "helper application" for processing, if such an application exists. CalDAV clients MUST support downloading of external attachments referenced by the "http" or "https" URI schemes. An external attachment could be:
o In a collection in the calendar collection containing the calendar object resource;
o Somewhere else in the same repository that hosts the calendar collection; or
o On an HTTP or FTP server elsewhere.
CalDAV servers MAY provide support for child collections in calendar collections. CalDAV servers MAY allow the MKCOL method to create child collections in calendar collections. Child collections of calendar collections MAY contain any type of resource except calendar collections that they MUST NOT contain. Some CalDAV servers won't allow child collections in calendar collections, and it may be possible on such a server to discover other locations where attachments can be stored.
Clients are entirely responsible for maintaining reference consistency with calendar components that link to external attachments. A client deleting a calendar component with an external attachment might therefore also delete the attachment if that's appropriate; however, appropriateness can be very hard to determine. A new component might easily reference some pre-existing Web resource that is intended to have independent existence from the calendar component (the "attachment" could be a major proposal to be discussed in a meeting, for instance). Best practices will probably emerge and should probably be documented, but for now, clients should be wary of engaging in aggressive "cleanup" of external attachments. A client could involve the user in making decisions about removing unreferenced documents, or a client could be conservative in only deleting attachments it had created.
Also, clients are responsible for consistency of permissions when using external attachments. One reason for servers to support the storage of attachments within child collections of calendar collections is that ACL inheritance might make it easier to grant the same permissions to attachments that are granted on the calendar collection. Otherwise, it can be very difficult to keep permissions synchronized. With attachments stored on separate repositories, it can be impossible to keep permissions consistent -- the two repositories may not support the same permissions or have the same set of principals. Some systems have used tickets or other anonymous access control mechanisms to provide partially satisfactory solutions to these kinds of problems.