More on the annotation format

[Steinar Bang <sb@metis.no>]

>>>>> John Prevost <prevost@maya.com>:

> The other thing that's been itching at the back of my mind for some
> time while reading this thread is that no matter what the editing
> mechanism provided is, there needs to be another mechanism for doing
> some "fixes".

> The specific reason that comes to mind is the not insignificant
> number of read-only mailboxes I have on my server for mailing list
> archives and the like.  Since these are shared mailboxes, I don't
> even have the ability (on Cyrus, anyway) to add non-standard flags
> to messages.

> That being said, I do think it would be interesting if we could come
> up with some mechanism, maybe similar to the one below, for
> annotating messages with extra information.

If you're thinking of my suggestion, as outlined in
	<whsob02v8u.fsf@viffer.oslo.metis.no>
we now need to be able to annotate outside of the folders themselves
(in case of read-only folders), which means that the best solution
will probably be to put all "annotation messages" in a special
annotation folder, one message for each folder (I don't know how this
compares to having an annotation message in each folder, but for
simplicity's sake we should go for a single mechanism for all
folders). 

> Especially if it could be done in a manner both efficient and not
> requiring anything that IMAP clients aren't already required to
> understand.

Hm... I think we have the following design requirements:
 - should be able to annotate read-only folders as well as read/write
   folders 
 - should use MIME for storing the annotation information, because
   IMAP requires the servers to be able to parse MIME and list
   information about each part
 - as much as possible inside MIME headers since this will leverage
   the MIME parsing mechanisms for the information

I would also like to add a requirement that is in collision with the
last requirement above:
 - it should be easy to add new annotation information to the format.
   For now we can think of reparenting/rethreading and MIME type
   remapping, but new annotations should be easy to add.

Hm... I was thinking about possible solutions last afternoon.  Here's
one: 

If we have one "annotation message" per folder this message could
either be a multipart/mixed or a custom multipart,
eg. multipart/x-nnimap-folder-annotate (or something... I'm using x-
until we actually have MIME types registered).

Having a custom multipart subtype, allows us to have a "folder"
parameter, giving the name of the original folder.

Then each message part would be of type
	multipart/x-nnimap-message-annotate
with a parameter of "original-UID" giving the UID of the original
message in the folder given by the "folder" parameter of the top level 
type.

Since x-nnimap-message-annotate is a multipart, it can have parts like 
	application/x-nnimap-part-annotate

This type has no content, but the parameters
 "part-no" (giving the part number in the original message)
 "new-content-type" (holding the new MIME type with all parameters (how
                     would we do quoting of quotes...?))
 "new-cte" (is this neccessary?)
 "new-disposition" (same problem with quoting as for the content type)

Or maybe we should just put the new headers of the part here, and no
content for the part, and then replace the headers of the part with
the headers?

> If this could be done, it might even be possible to push it at the
> IETF as a propsed extension.

We could at least document it as an informative RFC.  Does anyone know
the procedure for this?

Any new subtypes should probably be registered with IANA, as well...?
	http://www.isi.edu/in-notes/iana/assignments/media-types/media-types