Re: The issue of mime parsing

Stefan Karrmann:
> IM2000 should use 8bit MIME encoding and support mainly/only MIME
> multipart.

On this level, the idea we are currently discussing is to allow only
MIME *external-body* multipart messages and to make the MIME-message
itself equal to "the notification".


Rickard:
>> ... only a subset of MIME is allowed for im2000 'manifests'.

Andrew Rutherford:
> Yup, I consider a subset fine. What I was objecting to was
> something different, as it helps if programmers can use their
> existing MIME-handling tools and libraries *if they wish to*.

This is a main arguent supporting MIME manifests. The main argument
against MIME manifests is that a dedicated format can be made a lot
easier to parse => new implementations can be written in less lines
of code and have less bugs. I suggest leaving this question open
until we know if a new dynamic field-based format is needed anyway
(for something else within the im2000 framework). Lets continue the
discussion assuming MIME-style manifests, as that at least provides a
syntax powerful enough to describe the ideas.


> Rickard:
>>>> [is it] possible to just keep a crypto signature of the manifest
>>>> file?
>> I don't think this is nessecary if there is a hash for each part
>> inside the notification file, and the notification file itself is
>> signed by the sender.

clemens:
> if [the receiver] insisted on both the notification she was
> presented [...] _and_ the contents to be signed and encrypted,
> then, i'm afraid, it has to have its own signature.

Somehow I don't think we have a mutual understanding of this. If the
notification file is signed, and it contains cryptographic hash:es of
all parts of the message, in effect, the parts are also signed!
(Or am I missing something here?)


//Rickard