Re: Annotate

[Dave Cridland <dave@xxxxxxxxxxxx>]

On Mon Nov  8 15:17:11 2004, Cyrus Daboo wrote:
> --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov 
> <Alexey.Melnikov@xxxxxxxxx> wrote:
> > > > I'd personally suggest that if the server supports read-write
> > > > annotations, it MUST support creation of arbitrary, 
> > > > non-operational
> > > > attributes.
> > > Is a server that only supports preconfigured namespaces an active 
> > > danger
> > > to interoperability?  If not, then I think "MUST" is 
> > > inappropriate.
> > Unfortunately, there is no way to distinguish a read-write ANNOTATE
> > server that supports reconfigured namespaces from a full read-write
> > server. So yes, this might be a problem. At least it makes writing 
> > client
> > more difficult.
> I think servers SHOULD allow clients to create and use arbitrary 
> annotation entries be they in the vendor namespace or elsewhere 
> (the later being e.g. new standard annotations that have been 
> defined since the server was deployed). However, as with everything 
> in IMAP, the client MUST be prepared to handle the server saying NO.
>
> So I think what we say is: 'servers SHOULD allow creation and use 
> of arbitrary annotation entries in the vendor namespace or 
> elsewhere, but client MUST handle the case where a server prevents 
> that and responds with a NO response', or something to that effect.

I'll certainly agree, of course, that any STORE to annotation may 
result in a NO, and of course, a client has to handle this.

To my mind, not allowing arbitrary attributes ranks at near the same 
level as not having persistent UIDs for a mailbox. It's something a 
client has to cope with, but shouldn't ever have to experience in the 
field. I'll concede that even this makes a MUST too strong, but 
perhaps a SHOULD with a note?

Philip used the phrase "active danger to interoperability" - a server 
which does not support storage of arbitrary attributes against a 
message in a mailbox for which the client has the rights required 
isn't actively endangering interoperability because, of course, it's 
acting so close to a server which doesn't support ANNOTATE at all.

What it is doing is missing out on a golden opportunity to provide a 
method for new features - such as, maybe, a resent-to attribute - to 
be created by one client, used by another, and standardized quickly 
and rapidly based on real operational experience. That's hurting 
interoperability badly, in my opinion.

As well as that, it's losing the ability to transfer mailboxes from 
one IMAP server to another without losing potentially highly valuable 
metadata, especially in the case where multiple clients are used.

If persistent UIDs aren't available, then the message store is badly 
designed for use with IMAP. If arbitrary annotations aren't 
supported, then the message store is badly designed for use with 
ANNOTATE.

Dave.