Re: The issue of mime parsing

Stefan Karrmann <[email protected]>:

> Right. Since IM2000 should not be an universal storage system, it
> should not look into the message body. If you really want to provide
> alternatives of the real-body you can put the links into the message
> body and every receiver can download what he prefers.
>
> The data of an ISP-IM2000 for a message should be similar to
>
> list of
>    addressee                     (mandatory)
>    ISP of addressee              (mandatory)
>    public key of addressee       (optional)  -\
>    public key of addressee's ISP (optional)  --+-- one of both is recommended
>    list of                       (optional)
>       cash descriptor               (mandatory, e.g. hashcash, etc.)
>       cash value                    (optional, maybe by challenge response)
>
> sender                        (mandatory on the sender's ISP to report success)
> char notice [NOTICELEN]       (global fixed length, e.g. NOTICELEN=256)
> body_size                     (mandatory, unlimited)
> body                          (mandatory)
> deadline                   (mandatory, tai-label, cf. <http://cr.yp.to/proto/utctai.html>)

i have a problem with this:  let's assume A has a key not signed by
any party B trusts.  then its MTA (today this is his MUAs task, but
im2000 will be different here) will have to search for the
certificates of other signers, maybe even contact A again for another
key.  your data structure would need additional, independant messages
for this, but i'd like this agreement procedure to take place without
independant communications.  after all, what if Bs message gets
lost?  then the communication fails, propably without both parties
ever knowning why.

i like the concretness of this data structure, but it may fall short
of what's needed.  my "big" proposals provide a larger framework,
which i think also contains that competitive edge everybody could see
as real advantages over SMTP.

but maybe you think my proposals are too big?  is that an issue?

  clemens