On Friday, July 4, 2014 2:42:51 PM CEST, NSS Ltd wrote:
The call is made from SOGo through SOPE and specifically the imap 4
handler which does the setannotate and getannotate commands.
Looking at those plus the existing annotation support, my (albeit brief)
reading of store/fetch suggests there is handling for :
STORE ANNOTATION
FETCH ANNOTATION
and these have the feel of being equivalent to SETANNOTATION and
GETANNOTATION already.
They are, sort of.
STORE ANNOTATION stores an annotation in a message. SETANNOTATION stores an
annotation on something else, typically a mailbox.
These two commands also seem to be custom versions added to SOPE for
SOGo (the code from trunk at
http://sope.opengroupware.org/en/source/index.html differs from the code
from http://www.sogo.nu/downloads/backend.html).
Now,
http://tools.ietf.org/html/draft-daboo-imap-annotatemore-00#section-7.1
suggests the SOGo commands are in-spec but
http://www.melnikov.ca/mel/Drafts/draft-ietf-imapext-annotate-09.txt
suggests Archiveopteryx is in spec. Since these are drafts, I suspect
there is a final (which I've not found in a quick google search) and for
whatever reason, each approach has used a different version of the specs.
The final for annotatemore is 5464, the final for annotate is 5267.
Do we have a situation where both are equivalent ? Would it be a fix to
configure a patch to treat SET & GET as a STORE & FETCH and re-use the
code which is there ?
Metadata looks extremely similar but possibly something else; before
making this too complex, I want to ask the question about using
annotation first.
They are parallel, never equivalent. One is for storing variables on the
the inbox itself, the other is for storing variables on a particular
message in the inbox.
It should be possible to implement 5464 by copying code from the 5267
implementation. FWIW I wouldn't mind dropping 5267 entirely; I think that
RFC has failed.
Arnt
