headers
Lyndon Nerenberg | 8 Feb 2012 19:33
Picon

Metadata (5654) Implementation Limits


[I didn't get much response from the imap-protocol list, so I'm trying here, too.]

I'm curious to know what the implementation limits are on servers that support the Metadata extension.  I
would appreciate it if the server authors out there could take a minute to fill out this survey.

I will send a summary to the list once the responses trickle off. (If you want your results to be anonymous,
say so in the comments.)

Thanks,

--lyndon

Implementation name and version:
Do you support /private?:
Do you support /private/vendor?:
Do you support unsolicited Metadata responses without values?:
Do you support unsolicited Metadata responses with values?:
Maximum number of annotations per mailbox:
Maximum size of an <entry>:
Maximum size of a <value>:
Maximum depth supported in <entries>:
Other comments:
Permalink | Reply | 1 comment |
headers
Greg Banks | 8 Feb 2012 21:18
Gravatar

Re: Metadata (5654) Implementation Limits


On 09/02/2012, at 5:33, Lyndon Nerenberg <lyndon <at> orthanc.ca> wrote:

>
> [I didn't get much response from the imap-protocol list, so I'm  
> trying here, too.]
>
> I'm curious to know what the implementation limits are on servers  
> that support the Metadata extension.  I would appreciate it if the  
> server authors out there could take a minute to fill out this survey.
>
> I will send a summary to the list once the responses trickle off.  
> (If you want your results to be anonymous, say so in the comments.)
>
> Thanks,
>
> --lyndon
>
> Implementation name and version:

Cyrus (METADATA support rewritten and ANNOTATE support added to future  
2.5 release).

> Do you support /private?:

Yes

> Do you support /private/vendor?:

Yes, with a subset of that space reserved for the server itself. Users
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrien de Croy | 9 Feb 2012 09:05
Favicon

Re: [imap5] Designing a new replacement protocol for IMAP


Whilst HTTP could certainly be used to put together an email system, I 
don't think it would perform well enough to replace existing protocols 
on desktops.

The main issues I see are:

* updates.  Would need to poll or use long polling to get real-time 
updates (e.g. notification of incoming mail).
* slow.  Gut feel based on 17 years writing http proxies is that it 
would be too slow
* complex.  In order to reduce round-trips, you'd have to do many things 
in a single transaction, which would create complexity issues in the 
server and client
* protocol bloat.  if you think IMAP is bloated, try HTTP.
* fundamentally an off-line style protocol for mail, which has strong 
incentives to be online (esp for in-office use).

I think it would also be very problematic in the wild, since any http 
intermediary would feel entitled to mess with traffic.  E.g. heuristic 
caching, intercepting proxies etc.

It's almost too ubiquitous.  Everyone and their dog thinks they know how 
http works.  It's not strictly-enough defined, and has a LOT of optional 
features which aren't relevant for mail (e.g. content negotiation).  
Interop in http is already problematic, but start getting people writing 
mail servers in php etc, and see what starts to happen.  I think it 
would be a nightmare.

Adrien
(Continue reading)

Permalink | Reply | 193 comments |
headers
Timo Sirainen | 13 Feb 2012 01:45
Picon
Picon
Favicon

ANNOTATE-EXPERIMENT-1


I was thinking about finally implementing METADATA + per-mail annotations to Dovecot so I read through the
RFCs. There are mainly two things I'd do differently in ANNOTATE-EXPERIMENT-2:

1. METADATA has case-insensitive entry names, ANNOTATE has case-sensitive. Probably better to keep them
case-insensitive in both.

2. SORT (ANNOTATION) - is this really worth the trouble? There's really no good way for servers to implement
this in an efficient way. It would pretty much require building and maintaining an index for every single
annotation entry name.

And other things I wondered about:

 - If APPEND has annotations, and annotation limits are reached, the whole APPEND fails with
TOOBIG/TOOMANY error? I guess it has to, although that's a bit annoying.

 - ANNOTATE doesn't specify what happens if STORE can change only some of the entries. Should it rollback the
changes to all the previous entries as well? Including changes to previous messages if multiple messages
were specified? Would have been simpler if both METADATA and ANNOTATE supported changing only one
annotation at a time.

 - TOOBIG/TOOMANY doesn't map very nicely if I want to have global "max. annotation size" and "max.
annotation count". Perhaps a global max. count shouldn't exist, since the number of mails/mailboxes
could be limited instead, but a global size similar to mail quota should exist. I guess when that global
size is reached it just fails with TOOBIG until some annotations are deleted.
Permalink | Reply | 6 comments |
headers
Arnt Gulbrandsen | 13 Feb 2012 10:19
Picon
Favicon
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On 02/13/2012 01:45 AM, Timo Sirainen wrote:
> 
> I was thinking about finally implementing METADATA + per-mail annotations to Dovecot so I read through
the RFCs. There are mainly two things I'd do differently in ANNOTATE-EXPERIMENT-2:
> 
> 1. METADATA has case-insensitive entry names, ANNOTATE has case-sensitive. Probably better to keep
them case-insensitive in both.

I wouldn't mind.

> 2. SORT (ANNOTATION) - is this really worth the trouble? There's really no good way for servers to
implement this in an efficient way. It would pretty much require building and maintaining an index for
every single annotation entry name.

Sorting at read time isn't bad, considering the very low number of
annotations used.

But I don't mind dropping that in the least. AFAIK noone has actually
wanted to sort by an annotation.

> And other things I wondered about:
> 
>  - If APPEND has annotations, and annotation limits are reached, the whole APPEND fails with
TOOBIG/TOOMANY error? I guess it has to, although that's a bit annoying.

Append is transactional. I agree it can be annoying sometimes, such as
when ten-thousand-message multiappends break. But IMAP already has
enough funny little exceptions, please don't try to add a rule such as
"append is transactional except in regard to annotations".
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bron Gondwana | 13 Feb 2012 10:32
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On Mon, Feb 13, 2012, at 10:19 AM, Arnt Gulbrandsen wrote:
> 
> On 02/13/2012 01:45 AM, Timo Sirainen wrote:
> > 
> > I was thinking about finally implementing METADATA + per-mail annotations to Dovecot so I read through
the RFCs. There are mainly two things I'd do differently in ANNOTATE-EXPERIMENT-2:
> > 
> > 1. METADATA has case-insensitive entry names, ANNOTATE has case-sensitive. Probably better to keep
them case-insensitive in both.
> 
> I wouldn't mind.

Keywords are already case insensitive.  Which is going to be a pig in poke if we try to make UTF8 keywords.

> > 2. SORT (ANNOTATION) - is this really worth the trouble? There's really no good way for servers to
implement this in an efficient way. It would pretty much require building and maintaining an index for
every single annotation entry name.
> 
> Sorting at read time isn't bad, considering the very low number of
> annotations used.
> 
> But I don't mind dropping that in the least. AFAIK noone has actually
> wanted to sort by an annotation.

If nobody wants it, it doesn't matter if it's inefficient, right?

If people do want it, then you can track the annotations they are actually
using to sort by and index those... at least that's the theory behind having
adaptive indexing.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Arnt Gulbrandsen | 13 Feb 2012 10:49
Picon
Favicon
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On 02/13/2012 10:32 AM, Bron Gondwana wrote:
> Keywords are already case insensitive.  Which is going to be a pig in poke if we try to make UTF8 keywords.

Unicode case insensitivity isn't so bad.

One rule for Turkish, one rule of the rest of the world, and anyone who
can define i to be equal to ı can sidestep the difference. In IMAP's
case, these two commands could be defined to be equivalent:

  a store +flags 1 istanbul
  b store +flags 1 ıstanbul

Not pretty but also not the end of the world.

(Neat: This spell checker, which I must find out how to turn off btw,
thinks istanbul is wrong and ıstanbul right.)

>> But I don't mind dropping that in the least. AFAIK noone has actually
>> wanted to sort by an annotation.
> 
> If nobody wants it, it doesn't matter if it's inefficient, right?

Mostly, but not quite.

A fetch item that noone ever calls can still require copy and append to
do extra work.

>> Why would store be able to change only some entries?
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bron Gondwana | 13 Feb 2012 14:04
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On Mon, Feb 13, 2012, at 10:49 AM, Arnt Gulbrandsen wrote:
> On 02/13/2012 10:32 AM, Bron Gondwana wrote:
> > Keywords are already case insensitive.  Which is going to be a pig in poke if we try to make UTF8 keywords.
> 
> Unicode case insensitivity isn't so bad.
> 
> One rule for Turkish, one rule of the rest of the world, and anyone who
> can define i to be equal to ı can sidestep the difference. In IMAP's
> case, these two commands could be defined to be equivalent:
> 
>   a store +flags 1 istanbul
>   b store +flags 1 ıstanbul
> 
> Not pretty but also not the end of the world.
> 
> (Neat: This spell checker, which I must find out how to turn off btw,
> thinks istanbul is wrong and ıstanbul right.)

And of course there's normalisation as well.  I really don't know as much
about this area as I should.  I guess the obvious is "require best practice
as defined <over there>".

> >> But I don't mind dropping that in the least. AFAIK noone has actually
> >> wanted to sort by an annotation.
> > 
> > If nobody wants it, it doesn't matter if it's inefficient, right?
> 
> Mostly, but not quite.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 13 Feb 2012 14:21
Picon
Favicon
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On 02/13/2012 02:04 PM, Bron Gondwana wrote:
> And of course there's normalisation as well.

Normalisation doesn't affect meaning at all. It's just changes such as
"o umlaut-above-previous-letter" into "o-with-umlaut" or the other way.
Useful for text processing.

Arnt
Permalink | Reply | 1 comment |
headers
Bron Gondwana | 13 Feb 2012 14:30
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On Mon, Feb 13, 2012, at 02:21 PM, Arnt Gulbrandsen wrote:
> On 02/13/2012 02:04 PM, Bron Gondwana wrote:
> > And of course there's normalisation as well.
> 
> Normalisation doesn't affect meaning at all. It's just changes such as
> "o umlaut-above-previous-letter" into "o-with-umlaut" or the other way.
> Useful for text processing.

Also useful for checking if a particular keyword is already set, and merging
the various forms together into a single keyword.

Bron.
--

-- 
  Bron Gondwana
  brong <at> fastmail.fm
Permalink | Reply | 0 comments |

Gmane