[Kolab-devel] Kolab 3.0: Mime Message Storage

[Jeroen van Meeuwen]

On Wednesday, May 16, 2012 04:30:13 PM Christian Mollekopf wrote:
> Hey,
> 

Hi Christian,

> I wrote down what I know or believe to know how kolab objects are supposed
> to be stored on an IMAP server:
> https://wiki.kolab.org/Kolab_3.0_Storage_Format
> 
> That is mostly the same as for Kolab v2, but with some additional
> specifications.
> 
> Tell me if you think something is wrong/under-/overspecified or should be
> changed otherwise.
> 

"""All folders MUST be annotated with an entry "/vendor/kolab/folder-type" 
containing the attribute (...)"""

The theory is fine, but in practice most mail folders are actually not 
annotated.

I suggest re-phrasing the entire section so that it is clear that;

- All folders with Kolab Groupware content MUST be annotated, while folders 
with mail contents MAY exist but without metadata, it is assumed folders 
without metadata are mail folders, and clients SHOULD set metadata for folders 
that have some special sort of mail (Drafts, Trash, Sent, etc...).

- the difference between ANNOTATEMORE (the draft) and METADATA (the RFC) 
doesn't matter for the verbiage of this part of the format definition,

- The shared namespace (/vendor/kolab/ value.shared in ANNOTATEMORE, 
/shared/vendor/kolab/ in METADATA) is good for groupware types, while sub-
types are usually best set in the private namespace,

"""All annotation MUST be set during the initial creation of a folder and 
cannot be altered afterwards"""

They MUST be set alright, but SHOULD NOT (or even MUST NOT) be altered 
afterwards. It's not like they "cannot be changed".

Also, consider that this would apply to the type only, and not (equally well) 
to the sub-type.

Folders without any metadata MUST (not SHOULD) be treated as (not assumed to 
be) mail folders.

===

"""All "default" Kolab-Folders MUST be located within the personal IMAP 
namespace. """

I don't think that MUST holds true, and I don't think we need to restrict 
'.default' sub-types to only ever be allowed in the personal IMAP namespace.

What must be considered is any personal IMAP namespace '.default' folder takes 
precendence over any other, and that there may only be one (or less, depending 
on opinions on the aforementioned) such personal IMAP namespace '.default' 
folder.

I would also consider adding that, if multiple .default folders exist, either 
"in the personal namespace" or "none in personal but multiple in the shared 
namespace" clients SHOULD pretend nothing has been marked as '.default' and 
behave accordingly (i.e. always pop up a "save to what folder?" type of 
dialog?).

===

"""TODO: we probably should have a bit a firmer specification how multiple 
folders SHOULD be interpreted for each type to get a consistent user 
experience."""

This remark doesn't make much sense, perhaps you care to elaborate?

===

"""* The XML describing the object. Content-Type: application/x-vnd.kolab.*"""

I would very much like to consider using the xcal and xcard content-type's for 
the appropriate objects.

===

As to the X-Kolab-* headers;

X-Kolab-Type is a duplicate of the Content-Type header to the attachment. I 
don't really see what purpose this serves, as in addition to the duplication, 
the object is also only supposed to be stored in a folder marked as containing 
rfc822 encapsulated payload of a particular type.

X-Kolab-Version is a duplicate of the version contained within the XML and 
should not be used.

X-Kolab-Conflict (I suppose) is depending on the outcome of the conflict 
resolution review and discussion...

===

"""The following headers/options MUST be used:"""

I made this a separate bullet point, and second, I see no reason to restrict 
the charset or encoding.

This brings me back to the bullet point just before this one, too. I suppose a 
localized version of said text could be allowed, as long as the English 
version is somewhere?

===

"""The following headers/options MUST be used:"""

I made this a separate bullet point, and second, again I see no reason to 
restrict the encoding to quoted-printable, nor a reason to restrict the 
filename to kolab.xml.

"""MIMETYPE MUST be one of (as specified in KEP #17):"""

I think this is inconsistent with the aforementioned x vnd kolab headers?

===

Attachments SHOULD be stored separately but MUST be referenced? Perhaps a 
little fine-tuning of the verbiage is justified... ;-)

===

The example is... large. For demonstrative sake, can we insert a "may remove 
carriage returns and superfluous whitespace", if not simply a "base64 encoding 
allowed" perhaps (even though it is kinda nice to be able to read as a human 
being) - just offering this one up for consideration.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120516/9611ab9c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120516/9611ab9c/attachment.sig>