Another KEP proposal: On IMAP-metadata (annotations)
Florian v. Samson
florian.samson at bsi.bund.de
Fri Jul 15 13:48:10 CEST 2011
Hi Jeroen,
Am Freitag, 15. Juli 2011 um 11:01:57 schrieb Jeroen van Meeuwen (Kolab
Systems):
> Florian v. Samson wrote:
> >
> > ...
> >
> > 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.
> > 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.
>
> Speaking as the release engineer for Cyrus IMAP upstream, Cyrus IMAP 2.4
> and beyond are fully compatible with RFC5464.
I was not aware of that (some of my knowledge of the technical details of
Kolab are a bit historic, from then I was the technical lead for the
contracting side of the original Kolab2 project): Thanks for the info,
which Gunnar provided as well.
So this is a non-issue for future Kolab-releases based on Cyrus 2.4 and,
according to Gunnar, Dovecot as well.
> I do not see Cyrus IMAP
> 2.3.x not being fully RFC5464 compatible as a disadvantage, however.
IMO nobody stated or addressed that; Rather the opposite.
> ...
>
> > 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].
>
> I'm not sure what the implications are here, and I do not want to speak
> out of turn, but if one or more client-/server- implementations need
> significant work in order to gain compliancy with said draft, ...
Jeroen, in our opinion this simply correctly specifies the current state,
which is already enduring for half a decade. I order to be specific: The
original Kolab-Patches seem to be based on that very "IMAP ANNOTATEMORE
Extension"-draft-05 [3].
> then perhaps a more efficient approach is to cut-through and do the
> work towards RFC 5464 (instead).
*This* is definitely *not* an option for the current spec.
The intention is just to concisely specify, what has been unspecified, but
implicitly demanded by the way all Kolab 2 servers have handled
IMAP-annotations.
> > 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.
>
> You can always ask, as I'm supposed to know this from the top of my head
> -or at least be able to assist you in the quest for such information ;-)
O.K.: Do all Kolab 2 servers releases (2.0.0 to 2.3.2 currently) implement
IMAP-annotations as of the "IMAP ANNOTATEMORE Extension"-draft-05 [3]?
If so, why not stating that explicitly in the current Kolab-format
specification?
Cheers
Florian
[3]: <http://tools.ietf.org/html/draft-daboo-imap-annotatemore-05>
More information about the format
mailing list