Jeroen van Meeuwen (Kolab Systems) wrote: > I think the RFC for SPECIAL-USE lacks the suffix '.default' we currently > use in /vendor/kolab/folder-type (example value 'event.default') to > indicate which folder is the default folder to save new messages that have > a calendar event XML object attached to it. > > I'm not sure the extension options listed in the RFC allow the addition of > '.default' without providing additional requirements, recommendations and > rationale. > > Also, suppose we were to propose \Calendar[.default], I'm not sure that > appropriately indicates in what format the folder contents are expected to > be in. Perhaps a \calendar[.kolab[.default]] is justified, where the Cyrus > IMAP CalDAV folder could have a \calendar.ical -or somesuch. >
Continuing my line of thought, naturally there has not to be a divider such as a '.'; one can set multiple SPECIAL-USE attributes to a folder, such that: - A Cyrus IMAP CalDAV folder containing iCalendar data could have SPECIAL-USE attributes: \Calendar \iCal [\Default] \iCal could be the defined default for a folder marked with SPECIAL-USE attribute \Calendar. - A Kolab Groupware calendar folder could have SPECIAL-USE attributes: \Calendar \KolabXML [\Default] I suppose the requirements and guidelines for combinations of SPECIAL-USE attributes and client implementations are something significant enough to consider, though I'm not sure I can find the section in the RFC that allows requesting new entries the list SPECIAL-USE attributes. Would this new proposition, if we can form some consensus on the topic, be a new RFC to extend 6154? Can somebody more familiar with IETF processes help me out here? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
