Re: New and better email

On Fri, 30 Jan 2004 16:44:31 +0100 
Iljitsch van Beijnum <[email protected]> wrote:

> Next order of business: separation of data and signalling. SMTP
> suffers from a problem that's very similar to what we see in
> telephony: the data follows the path that depends on where the
> decisions are made. For email this makes sense historically because it
> is a store and forward network: first determining the path through the
> network and then actually following this path would slow down the flow
> of mail way too much and not lead to better or cheaper
> paths. Originally, I wanted to write "ditch store and forward", but in
> some situations store and forward is useful. However, even if a
> message has to travel through several hops, this doesn't have to take
> all that much time: think in the order of minutes. This means that for
> many messages it is advantageous to first send the header and maybe a
> kind of "cover sheet" and keep the acutal content at the source or the
> next hop after the source. Then when the destination decides that it
> want the content and how it wants it, it goes back to the source (or
> close) and do the actual content transfer. In many situations this
> could happen using direct communication, but it could also be done
> using store and forward. (Note that to some degree email already works
> somewhat like this as embeded images are often retrieved from an HTTP
> server.

If we look at this from a policy level the transactions becomes:

  -> May I send you a message with >these< properties?

  <- Yes | No

  -> Sends message or not.

This breaks down when the rate of negative replies (refused messages) is
insufficiently high to outweigh the expense of transmitting the original
message in the first place.  As such I doubt it has a core role in
mail-ng.  However such an ack-based system can have another use:
requesting and establishing long term consent relationships:

  -> I'd like to start a relationship with you like XYZ.

  <- Okay (provides appropriate data) | Rejected.

  -> Sends subsequent messages in a way that allows them to be
  recognised as subject to that specific relationship.

Socially this is akin to knocking on the door and announcing yourself.

> Then there is the whole issue of large binary files, which alone would
> be worthy of a new protocol. It's ridiculous that we have to use a
> hack like base64.

Following Chuq's comments on XML, binary files can be encoded inline via
bas64, or cited via URIs that refer to other blobs in the payload or to
data sets that available via other means (eg HHTP).

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email protected]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.