Hi again. On Monday 26 July 2010 Christian Hilberg wrote: > while I suspect the answer will most likely be "no", just to be sure I'd > like to put the question here anyway (if only for the record): > Does the Camel IMAPX implementation comply with RFC5464 "The IMAP METADATA > Extension" [1] ? > [...] > [1] http://www.faqs.org/rfcs/rfc5464.html After taking a closer look at the IMAPX implementation (and since there was no veto here), it seems clear that the 2.30 IMAPX does not support the RFC5464 IMAP protocol extension. Now, we need this functionality in our evolution-kolab plugin to avoid ugly workarounds (like scanning all folder contents in order to find out the folder type) when working with Kolab IMAP (PIM) Folders. We could patch the IMAPX implementation to add RFC5464 functionality. This would mean that IMAPX needed to be extended by two new IMAP commands (SETMETADATA and GETMETADATA), and one new response (METADATA). The GETMETADATA command has two options, MAXSIZE and DEPTH. The METADATA response may carry values. For further details, please see RFC5464. In all, it does not seem to be overly complicated. However, apart from implementing the protocol extension itself, it would mean to also extend the IMAPX API. This should be possible to implement just as an extension to the existing API so we would not break anything, right? Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? As an alternative, would anyone like to implement RFC5464 in the current upstream IMAPX so we could try and backport the changes into 2.30? Best regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.