Re: im2000 prototype, spam

"clemens fischer" <[email protected]>:

> 1.  im2000 prototype

3.  migration from SMTP to im2000
---------------------------------

i forgot the migration issue.  seen from SMTP, (my) im2000 can have
two types of headers: im2000 service requests and possibly the
customary RFC822 headers that are part of the user data.  thus there
is no way to simply upgrade SMTP servers to handle im2000 messages
without trickery, because SMTP only has envelopes and IP numbers.
aside from technical topics, it should be noted that the larger
capabilities of this im2000 proposal might be what ISPs need to offer
to future clients for that "competitive edge".

dan bernstein uses special MX distances to make his QMTP protocol
available, an alternative would be special SRV resource records in
DNS as another source for the extra information needed in im2000.

note that this extra information is not really that much: service
indicators don't specify IPv4 dotted addresses (32 bits), but instead
types of services backed by potentially many offerings.  in addition
to this, which might be a smallish integer, we need space for
operators and fixed values, plus identifiers for keys, and there will
be path-IDs shared between hops.  completed services also have
version-IDs used for various purposes related to cooperational server
behaviour, cache management and the like.

all this can grow to kilobyte values (i think) and varies, so im2000
servers must be prepared to take this info in before user data.  they
are also not supposed to inspect user data, at least not when
receiving it.

to make this short: im2000 servers must somehow advertise their
backends capabilities (via MX distances or DNS SRV RRs) and also in
the "helo phase" (just to make sure).  then they will slurp up not
only MAIL FROM, RCPT TO, DATA, AUTH etc., which might be needed for
compatibility, but also "HEADER ..." and "RELEASE ..." commands.  if
path- and release-IDs aren't part of HEADER/RELEASE commands (or all
of this unified under HEADER), count in "PATHID ..." etc.

if the more transport oriented stuff goes with SIP/SDP
<URL:http://www.ietf.org/rfc/rfc3264.txt>, there could even be a lot
more headers much as seen in HTTP, but with fixed meanings.

after that, with appropriate choices in these formulas, an im2000
dispatcher will be able to handle SMTP connections, but it may not
enter them into im2000 as regular messages, because SMTP doesn't
specify end-to-end authentication etc.

  clemens

-----BEGIN PGP SIGNATURE-----

iD8DBQE+kFBZpdlrZyFBkK8RAnA1AJ4/tnqIhlrH++LZBs8004I/sK8cdgCfdEZI
XNLYJm7lMp/UCOM+8q+4k4Y=
=lAKh
-----END PGP SIGNATURE-----