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