Re: DIME Use Case?

Mitch Denny <[email protected]> writes:
> While DIME and MIME attempt to solve similar problems (encoding data
> for transmission over the wire), DIME has a few things in it which
> make it easier to just open up a socket and push binary data down
> through it. DIME is substantially easier to implement without a
> supporting library whereas MIME is really quite painful, this
> is mainly due to the work you have to do to recognise and act
> accordingly with MIME's encoding schemes. With DIME its simple,
> binary binary binary.
Hmm... I suppose this is true, but you could probably get most of
this value by doing a MIME profile that specified binary transport.

Even if DIME is simpler to implement than such a profiled MIME,
it seems that this simplicity is mitigated by two factors:

(1) Many DIME implementations will also implement MIME, in which case
even a very simple DIME represents additional implementation
complexity over MIME.

(2) There's a lot of MIME infrastructure already in place that will
need to be replicated to have a DIME. In particular, if you want to
have message security you'll need some S/MIME or OpenPGP analog [0]
(S/DIME?) In general, I don't think it's worth adding a lot of new
protocol infrastructure to avoid a little implementation complexity.

-Ekr

[0] Of course, it's possible to simply to wrap DIME instead of S/MIME,
doing this means you need an S/MIME implementation, so you have
to implement MIME anyway.

--
[Eric Rescorla                                   [email protected]]
                http://www.rtfm.com/