Another KEP proposal: On IMAP-metadata (annotations)

[Gunnar Wrobel]

Quoting "Florian v. Samson" <florian.samson at bsi.bund.de>:

> Hello all,
>
> IMO the Kolab format MUST reference the correct specification for the
> IMAP-metadata (annotations) to use.

+1

>
> Hence I propose this mini-KEP for the Kolab-format specification:
>
> Kolab-clients and -servers MUST support IMAP-metadata (annotations)
> specified in RFC5464 [1].
>
> I see two major "pros":
> - Implementers of client-side IMAP-libraries know what to implement / expect
> from the Kolab-server.  (Specifically it took us quite a while to analyse
> this an come to a concise conclusion in the evolution-kolab project: [2])
> - When adapting an existing PIM-client for the use with Kolab, it is very
> hard to convince the maintainers of the IMAP-implementation of that client
> to integrate an IMAP-metadata (annotations) extension which is based on a
> long outdated RFC-draft, which is quite incompatible to the final RFC5464.
>
> I also see a "con":
> - The Kolab-community will have to provide patches to the IMAP-server(s)
> used in the Kolab-server (Cyrus and/or Dovecot), again.

I think both already support the final RFC.

>  Still, as on the
> client-side, these patches supposedly will be received much more welcome
> upstream than those implementing a long outdated RFC-draft, which is quite
> incompatible to the final RFC5464.

If it would be done *right now* we would also need to adapt the  
c-client and PHP patch on the Kolab server as this one only supports  
the old version. But no PHP developer that I know still wants to use  
the c-client PHP extension and Horde 4 already moved away from it. So  
these patches could be dropped in the long run anyway.

Cheers,

Gunnar

>
> I also propose enhancing the *current* Kolab format specification with a
> concise statement, which is absolutely missing, currently:
>
> Kolab-clients and -servers MUST support IMAP-metadata (annotations)
> according to the "IMAP ANNOTATEMORE Extension"-draft-05 [3].
>
> It took us (when doing evolution-kolab) quite a while to research which
> version of the draft is implemented in the Cyrus-IMAPd as of Kolab 2.2.4,
> as this is not noted or even hinted anywhere.  We fiercely hope that we got
> that analysis right.
>
> Cheers
> 	Florian
>
> References:
> [1]: <http://tools.ietf.org/html/rfc5464>
> [2]: <http://sourceforge.net/apps/trac/evolution-kolab/wiki/RFCReference>
> [3]: <http://tools.ietf.org/html/draft-daboo-imap-annotatemore-05>
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de