mail-ng
[Top] [All Lists]

Re: New and better email

2004-01-30 11:17:12

On Fri, 30 Jan 2004 16:44:31 +0100 
Iljitsch van Beijnum <iljitsch(_at_)muada(_dot_)com> 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.
claw(_at_)kanga(_dot_)nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.


<Prev in Thread] Current Thread [Next in Thread>