Re: DIME Use Case?

Eric,

Valid points, I imagine discussion like this was going
around where when some of the most populare wire protocols
today were being envisaged.

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

Not necessarily true, there is not a functional link between
the two mechanisms. Where MIME finds itself mainly in use
in SMTP, NNTP and HTTP communications, DIME is enabled for
use in a more direct manner (on the wire).

Simplicity is king. I still get dizzy reading the MIME spec
whereas DIME functionality is really achieved by some simple
bit flipping. Folks are obviously having problems with MIME,
I read of a new encoding scheme that seems to be taking off
in newsgroups called yEnc, its main advantage isn't its
simplicity though (it is simple), it is its ability to
encode much more efficiently than say Base64 or Qouted Printable.

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

At the moment I think the Internet is going through a bit
of a transformation in terms of what it can deliver to its
audience. During this time there is destined to be a whole
raft of new ideas/technologies put on the table. You can
place DIME in that bucket, give it a chance. Security issues
will be ironed out, we should probably observe what is happening
in the GXA space and see if any of that is applicable.

----------------------------------------
- Mitch Denny
- [email protected]
- +61 (414) 610-141
-

-----Original Message-----
From: Discussion of DIME technology [mailto:[email protected]] On
Behalf Of Eric Rescorla
Sent: Sunday, 14 April 2002 03:48
To: [email protected]
Subject: Re: [DIME] 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/