[Kolab-devel] Kolab 3.0: Mime Message Storage

[Christian Mollekopf]

On Wednesday 16 May 2012 16.55:24 Jeroen van Meeuwen wrote:
> On Wednesday, May 16, 2012 04:30:13 PM Christian Mollekopf wrote:
> > Hey,
> 
> Hi Christian,
>
 
Hi Jeroen,

> > 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.
> 

Yes, that should have been kolab-folders...

> 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?).
> 

I changed the draft accordingly. If I understand correctly, that means the 
annotations are not really backwards compatible thought.
However, I agree that it makes sense to have the groupware type as shared 
annotations and the rest as private annotation, and now is the time to make 
the changes.

We might want to also allow all annotations (also default, inbox, draft, etc.) 
as shared annotations, with private annotations taking precedence over shared 
ones. This would allow for defaults in the folders in the shared namespace.

> ===
> 
> """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?
> 

I mean we should maybe give a better specification/guideline how folders should 
be interpreted.

In the Akonadi Resource it's not that interesting because akondi allows us to 
map the imap folders 1:1 to the calendar folders. (We can have subfolders for 
calendars, notes, and addressbooks, and we can even create calendar folders 
for journals only).

I don't know if that is possible for all systems, because an ical calendar is 
typically for events, todos and journals. So it might be that not all systems 
provide such fine-grained control (especially when it comes to mobile devices), 
and could make use of some guidline. e.g. display all folders containing 
calendar items as a single calendar and store new items to the folder  which 
was marked as default.

But since it is very straight forward for our main client, I suppose we don't 
really need to think about that now and can just tackle it when we are facing 
the issue.

> ===
> 
> """* 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.
> 

Yep, forgot to delete the content type from the old spec.
We do use the xcal and xcard content-types for the ones containing xcal/xcard. 
The note is a custom format and therefore uses: application/x-vnd.kolab.*

> ===
> 
> 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.
> 

The Content-Type header is the same for all xcal/xcard headers and doesn't 
give us this differentiation. And doing that by the xml is painful to say the 
least.

Since we have separate folders for the content types, it would be fairly easy 
to change our implementation, it could be a problem for other clients though, 
depending on how the code is written. If we remove the X-Kolab-Type header it 
is also no longer to automatically convert a single mime message (without the 
context of the folder), without specifying the type manually.

Generally I would rather keep it, as it IMO is a useful hint for client 
implementors which don't have the foldertype available right away and allows 
to double check the type. Also I'm not that fond of relying on the folder type 
to "guess" the kolab object type.

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

It is not IMO, as it specifies the format of the mime message format. I'm in 
favor of keeping it.

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

Yes, indeed.

> ===
> 
> """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?
> 

I thought that ascii-us is somewhat the industry standard for emails, I might 
be wrong though. In any case I'm ok with allowing also other charsets as it's 
not a functional but puerly informal part anyways. 

> ===
> 
> """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.
> 

IMO there is no reason to not enforce the encoding, and as every client must 
be able to read all supported encoding types, I'd rather just use one.
I don't really care about the filename, but see no reason not to just specify 
one, which keeps it at least consistent.

> """MIMETYPE MUST be one of (as specified in KEP #17):"""
> 
> I think this is inconsistent with the aforementioned x vnd kolab headers?
> 

No, respectively should be =)
The X-Kolab-Type specifies the exact Kolab Object type, where the Content-Type 
only specifies the mime-type of the format with which the xml object object is 
stored. That means if we have a v2 and a v3 event they have the same X-Kolab-
Type but different Content-Types.

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

Yes, I just copied a testfile to be honest. I

> 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.
> 

I don't follow here:
"may remove carriage returns and superfluous whitespace" where?

Regarding the base64, as I'm not in favor of allowing this, is there any 
specific reason to do so?

Thanks for the review,

Christian

> Kind regards,
> 
> Jeroen van Meeuwen
-------------- 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/8b541fb4/attachment.sig>