Re: The issue of mime parsing

Stefan Karrmann <[email protected]>:

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

and i think im2k should require every message to be authentic(ated).
this is to have a system that can be used to create contracts holding
up in court as well as e-government.  don't think this is too far
fetched for a "bloody mail transfer protocol": im2k will only succeed
if it provides distinct features SMTP cannot offer.

also, for im2k at least i would leave SMTP without a tear.

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

X11 is the current standard of unix graphics.  the programs are big,
the libraries are big, but they have to get a big job done!  there's
no reason for using few big programs to make im2k, many small and
simple programs will make it robust and easy to understand.

regarding my proposal, it's actual implemented algorithm will be
quite small:  iterate over open headers to find servers offering the
requested services, forward released headers to receivers and do the
trust management.  you can make small programs for each of them, but
please don't loose the perspective and re-invent a bad SMTP/NNTP
combination with some unspecified "cash component" thrown in nobody
has been able to make sense of.

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

so do you think potential receivers should be able to reqire me to
participate in SETI@home, or do gene analysis?  well, i'd drop each
of those messages, because what seems SETI to me may just be some
specific encoding of some government agencies key cracker or attempt
to make better soldiers.  if you want to donate or make available
spare CPU cycles, from inside an email protocol, you will have to
provide a specification for it.  this is different from im2k and
should not be part of it.

at times like this i wish we could vote on the list: who of all the
im2000 list readers wants some form of cash management be part of the
im2000 protocol?  because i want to drop this idea entirely and shut
the case on it.  or let there be another working group for it.  with
the generic header management i proposed you can easily require
receivers to send you money if that's what you're after: just make a
header "< 0.02 cents US currency" and don't accept the message until
some server you trust sends you 2 cents.  deposit this message as
your main container for defaults with your ISP and wait.

  clemens