Re: The issue of mime parsing

Rickard Armiento (Mon, Mar 31, 2003 at 11:30:12AM +0200):
> 
> Stefan Karrmann:
> > 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.
> 
> If you intend to use MIME/multipart for the message body anyway, why
> not allow for MIME:s external-body feature for providing such links?

You are free to put a MIME message with external-body parts into the
body of the IM2k-message. But IMHO IM2k should not inspect the message
body.

> Stefan Karrmann:
> > The data of an ISP-IM2000 for a message should be similar to
> > [...some field details removed...]
> > body_size                     (mandatory, unlimited)
> > body                          (mandatory)
> > [...some field details removed...]
> 
> I guess you mean for the body to use MIME format to allow multipart
> messages. This thread was started as I suggested there are advantages
> to always handle body parts as external binary files. (The primary
> advantage being simplifed handling of partial message download for
> clients on low bandwith connections.) Are there reasons to why you
> would like to avoid that approach?

I prefer to keep IM2k simple (and correctly working, cf. sendmail).
If the IM2k-message is MIME/multipart with MIME/external-body contents
it will be small and the MUA can download the external bodies as the
recipient likes it.

clemens fischer (Mon, Mar 31, 2003 at 11:34:52AM +0200):
> Stefan Karrmann <[email protected]>:
> 
> > 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.

The upper data shows (parts of) the information the sender's ISP keep to
deliver the message. The public keys are optional. They can be provided
by the sender or filled by its ISP. In any case the ISP must report the
final delivery status (e.g. deadline reached, deliverd, only cash
delivered, etc.).

If the sender's ISP (AI) contact the addressee's ISP (BI) it should
transmit either
(1) a session key
(2) AI's public key

Then BI or (later on) the addressee can get the message securely. IM2k
should not require that every message is authenticated. This should be
the addressee's choice.

> 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.

Not all needed flags are listed above. You also need a different but
similiar structure at the addressee's ISP, the addresse and the sender.
E.g. the addressee's ISP should store the preferences of the addresse,
e.g. accept only authenticated messages, denial the addressee, forward
the notifies, etc.

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

Yes. One reason for the success of UN*X were small programs.

> > 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)
>         ^^^^
> i have also a big problem with this:  i do not believe that
> communication should be anything but the cheapest resource available
> to the human race. [...]

Please note that the list of alternative cash kinds is optional. And a
kind of cash may be hashcash, i.e. you may have only to spend some spare
cpu-cycles. If IM2k supports a challenge response cash system you need
only to spend it if its required by the addresse (or drop your message).

-- 
Stefan Karrmann