RFC 5464 IMAP METADATA Extension Errata

[kael]

On 07/26/2012 07:28 AM, Bron Gondwana wrote:
> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3723

Thanks.

>> 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 
awesome, though.

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 
interoperable schemes.

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.

-- 
kael