RFC 5464 IMAP METADATA Extension Errata
ka-el at laposte.net
Sun Jul 29 17:20:00 EDT 2012
On 07/26/2012 07:28 AM, Bron Gondwana wrote:
>> If these bugs are confirmed, it'd be great to have them fixed before
>> this extension is widely adopted (there are lots of potential, imo),
>> otherwise client implementations might be based on the current Cyrus
>> version which is the de facto normative implementation, and the examples
>> from the RFC would overrule the ABNF.
> Agree, have made P1.
Implementing unsolicited METADATA responses at the same time would be
Actually, I came across a discussion on the "tb-planning" list about
syncing Thunderbird and Gaïa <http://goo.gl/Q0tG1>. Someone says that
there's no sync capability with IMAP, but that's not true.
IMAP METADATA can be used as a remote storage mechanism, in the ACAP
spirit, although some old-school IMAPers might strongly disagree.
Stored data would be related to client configuration mainly, the
address-book could be stored there as well, but pointing to an URI
(LDAP, CalDAV) might be better. But I see several problems :
- lack of selective notifications : a client might not be interested
into receiving some classes of METADATA events, and I don't think the
NOTIFY extension would solve the problem there ;
- lack of diff-like mechanism at reconnection : a client might be
interested into fetching metadata it doesn't know about (new, modified
and deleted ones) ;
- potential difficulty, although not insurmountable, to create standard
All that to say that I believe the IMAP METADATA extension has a real
and useful potential. Perhaps a collaboration between Cyrus, Fastmail,
Mozilla (Tb & B2G) and other vendors and providers might favor its use.
More information about the Info-cyrus