[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Annotate



Some comments:

   Clients MUST NOT use annotations in lieu of equivalent IMAP base
   specification facilities.  For example, use of a "seen" flag in the
   vendor namespace together with ".PEEK" in fetches.  Such behaviour
   would significantly reduce IMAP interoperability.

I don't understand the example. What does .PEEK fetches have to do with \Seen flag, except without it the \Seen flag might change?

   If a server supports annotations, then it MUST store all annotation
   data permanently, i.e.  there is no concept of 'session only'
   annotations that would correspond to the behaviour of 'session' flags
   as defined in the IMAP base specification.  The exception to this is
   IMAP flags (which are accessible directly through annotations) which
   may be 'session only' as determined by the FLAGS and PERMANENTFLAGS
   responses to a SELECT or EXAMINE command.

Since IMAP flags can no longer be modified with ANNOTATE, the exception should probably be removed.

   The 'm' right controls both read and write access to .priv annotation
   values.  When it is on, access to .priv annotations is allowed, when
   it is off, access to .priv annotations is disallowed.

Is this really needed? I think private annotations should work the same way as private flags. You can always read them, and you can write them if it's possible to permanently save flags.

   /flags
      Defines the top-level of entries for flags associated with an
      entire message.  The "value" attribute of each of the entries
      described below must be either "1", "0" or NIL.  "1" corresponds
      to the flag being set.

NIL isn't defined here. Does it mean "not set"? For example:

/flags/\Seen.shared = 1
/flags/\Seen.private = NIL
 -> private \Seen flag set

/flags/\Seen.shared = 1
/flags/\Seen.private = 0
 -> private \Seen flag not set

Or should server do this internally and always return 1/0 seen flag? So NIL would only be useful for shared? Or should it also there default to 1/0?

   Clients that need to implement shared and private 'flags' can create
   their own annotation entries for those, completely bypassing the base
   IMAP flag/keyword behaviour.

I thought clients weren't allowed to make up their own annotation entry names? Or what does this mean?

Attachment: PGP.sig
Description: This is a digitally signed message part