kael | 25 Jul 2012 20:14
Favicon
Gravatar

RFC 5464 IMAP METADATA Extension Errata

Hello,

Two errata were published for RFC 5464 
<http://www.rfc-editor.org/errata_search.php?rfc=5464>, and apparently 
Cyrus implementation of the METADATA extension is buggy in the regard to 
these errata.

- ErratumID 2785 :

a GETMETADATA (MAXSIZE 1024) "INBOX" (/shared/comment /private/comment)
a BAD missing value to metadata option

- ErratumID 2786 :

a GETMETADATA (DEPTH 1) "INBOX" (/private/filters/values)
a BAD Missing annotation attribute

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.

--

-- 
kael

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
(Continue reading)

kael | 25 Jul 2012 20:17
Favicon
Gravatar

Re: RFC 5464 IMAP METADATA Extension Errata

On 07/25/2012 08:14 PM, kael wrote:
> Two errata were published for RFC 5464
> <http://www.rfc-editor.org/errata_search.php?rfc=5464>, and apparently
> Cyrus implementation of the METADATA extension is buggy in the regard to
> these errata.

Tested on FastMail.fm.

--

-- 
kael

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Bron Gondwana | 26 Jul 2012 07:28
Gravatar

Re: RFC 5464 IMAP METADATA Extension Errata

On Wed, Jul 25, 2012, at 08:14 PM, kael wrote:
> Two errata were published for RFC 5464 
> <http://www.rfc-editor.org/errata_search.php?rfc=5464>, and apparently 
> Cyrus implementation of the METADATA extension is buggy in the regard to 
> these errata.

https://bugzilla.cyrusimap.org/show_bug.cgi?id=3723

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

Thanks,

Bron.
--

-- 
  Bron Gondwana
  brong <at> fastmail.fm

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

(Continue reading)

kael | 29 Jul 2012 23:20
Favicon
Gravatar

Re: RFC 5464 IMAP METADATA Extension Errata

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 ;
(Continue reading)

Greg Banks | 30 Jul 2012 01:36
Gravatar

Re: RFC 5464 IMAP METADATA Extension Errata

G'day,

On 30/07/2012, at 7:20, kael <ka-el <at> laposte.net> wrote:

> On 07/26/2012 07:28 AM, Bron Gondwana wrote:
>> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3723
> 
> 
> Implementing unsolicited METADATA responses at the same time would be 
> awesome, though.

Sheesh, give 'em an inch...

When I was doing the last round of annotation code rewrites, I deliberately avoided implementing
unsolicited responses, because it's hard to do properly with the existing database structure. We'd need
to store something like a modseq per annotation. The old format stored a timestamp because one of the early
annotatemore drafts said that clients could access a modified time per annotation. That draft is
obsolete now and we don't store modtimes anymore. In any case using timestamps to report changes is
problematical, which is why modseqs are used to do that job for messages. Unfortunately, there's no
single modseq-like counter in Cyrus which works for per-server, per-mailbox and per-message annotations.

But if there's a good use case for it, we could implement such a thing.

Greg.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

(Continue reading)

Greg Banks | 30 Jul 2012 03:07
Gravatar

Re: RFC 5464 IMAP METADATA Extension Errata


On Mon, Jul 30, 2012, at 09:36 AM, Greg Banks wrote:
> G'day,
> 
> On 30/07/2012, at 7:20, kael <ka-el <at> laposte.net> wrote:
> 
> > On 07/26/2012 07:28 AM, Bron Gondwana wrote:
> >> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3723
> > 
> > 
> > Implementing unsolicited METADATA responses at the same time would be 
> > awesome, though.
> [...]
> 
> But if there's a good use case for it, we could implement such a thing.

I should mention also that Bron has been talking for some time now about
storing modseqs on per-message annotations as a way to make replication
more efficient.  I think this is an excellent idea and is easy enough to
do, because we have a good modseq counter with sensible semantics for
the mailbox and could store it in the db in a semi backwards compatible
manner, and the CONDSTORE rfc allows for servers to keep separate
modseqs on any kind of per-message data.  Once we do that, it would be
relatively easy to emit unsolicited ANNOTATION responses.

It might be feasible to do similar things for per-mailbox annotations. 
But per-server annotations are...less obvious.

--

-- 
Greg.
(Continue reading)

kael | 9 Aug 2012 21:48
Favicon
Gravatar

Re: RFC 5464 IMAP METADATA Extension Errata

On 07/30/2012 03:07 AM, Greg Banks wrote:
> I should mention also that Bron has been talking for some time now about
> storing modseqs on per-message annotations as a way to make replication
> more efficient.  I think this is an excellent idea and is easy enough to
> do, because we have a good modseq counter with sensible semantics for
> the mailbox and could store it in the db in a semi backwards compatible
> manner, and the CONDSTORE rfc allows for servers to keep separate
> modseqs on any kind of per-message data.  Once we do that, it would be
> relatively easy to emit unsolicited ANNOTATION responses.
>
> It might be feasible to do similar things for per-mailbox annotations.
> But per-server annotations are...less obvious.

Well, at first glance and without knowing the Cyrus code and 
architecture, I'd say per-server METADATA could be treated as a mailbox 
ones, except the mailbox ID would be constructed with forbidden IMAP 
characters. But I may have missed something.

--

-- 
kael

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Gmane