[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Thomas Brüderli]

Jeroen van Meeuwen wrote:
> On Thursday, March 28, 2013 05:52:30 PM Georg C. F. Greve wrote:
>> On 2013-03-28 17:23, Thomas Brüderli wrote:
>>> But let's wait for a final word from our system architect before we
>>> nail this down in a KEP.
>> Indeed. He'll be back next week - plus we'll all be in Berne together,
>> I am sure we'll work out the details.
> 
> So, if I understand correctly:
> 
> - *DAV clients expect to be able to refer to any given collection (=> 
> Calendar) by UID (=> /shared/vendor/kolab/dav-uid).

Right.
> 
>   This applies to CardDAV as well, I suppose?

Yep.
> 
> - As the DAV client creates the collection, supposedly it uses either 
> DAV:displayname in the MKCALENDAR command, or issues a PROPPATCH to change the 
> DAV:displayname property;

A client submits a DAV:displayname with the MKCALENDAR command while the
URI contains the actual collection UID.

When looking at Apple's iCal application, it sends the MKCALENDAR
command with displayname "Untitled" already while the user still enters
the actual name of the new calendar. Once the user submits the dialog, a
PROPPATCH command with the final display name, color and description is
sent.
> 
> - First creating a event.default sub-folder with the UID as the base name, to 
> then rename that folder to match the desired DAV:displayname does not seem an 
> unreasonable scenario to me 

That was my idea, too.

> (or, of course, keep the entire transaction 
> pending and create the IMAP folder only after the desired DAV:displayname has 
> been received).

That might be a bit harder because this is asynchronous and no state is
maintained between the individual requests from a DAV client.

> I suppose for existing calendars the IMAP folder base name can 
> be used as the initial DAV:displayname property to a collection resource, 
> until the user decides to set it to anything else.

That's the plan, yes.

For the "emulated" display name, we can follow the rules suggested here:
http://wiki.kolab.org/UI-Concepts/Folder-Listing
So for example, the folder /user/aguy/work/admin/financial will get the
displayname "(aguy) work/admin/financial".
> 
> - A client changing the display name of a calendar (collection resource) would 
> then basically have two options: 1) Rename the IMAP folder (from 
> Calendar/Personal to Calendar/Personal Calendar, possibly repositioning the 
> folder in the IMAP folder hierarchy?), or 2) set a different 
> /vendor/kolab/displayname metadata value.

With a dedicated Kolab client such as Roundcube we might even show two
fields to the user and let him adjust these separately.
> 
> There's ambiguity in there, I don't think can be simply addressed by stating 
> the usual MUSTs and SHOULDs in a KEP. I think perhaps it is best to use the 
> IMAP folder base name ("Personal" for "Calendar/Personal"), and have the IMAP 
> folder be renamed upon a change of this "title" (for admins).

That's fine for the web client (actually we have that already) but it's
not that simple for DAV clients which don't support hierarchical lists
of collections. Example: two calendar folders in my personal namespace
are Calendar/Home/Personal and Calendar/Work/Personal which would both
translate into "Personal". That will make them indistinguishable in a
DAV client. On the other hand, if we represent the full path in the
display name, what should if I rename "Calendar/Home/Personal" to "My
Home Calendar"? The new name cannot properly be translated into an IMAP
folder hierarchy anymore. Of course we can just rename the folder to
that name and having it placed on top level of my personal namespace in
IMAP. Thus we're back at the question, when to use (and change) the real
IMAP name and when the displayname metadata.

> I would then 
> suggest the use of a /vendor/kolab/displayname metadata entry as an 
> internationalization feature (I say 日历, you say Kalender), which happens to 
> serve the DAV:displayname as well (IMAP folder rename for admins, 
> /private/vendor/kolab/displayname for mortals).

Agreed.
> 
> A "description" for a CalDAV calendar collection resource could indeed go to 
> /comment.

Agreed.
> 
> The CalDAV UID required could indeed go to /vendor/kolab/dav-uid (/shared 
> only, I reckon).

Preferably shared but for existing folders, I suppose the UID is
generated on the first access through DAV. If one uses a CalDAV client
to access a shared folder with read-only permission, the only option to
save the UID would be /private/vendor/kolab/dav-uid.

~Thomas