Re: IM2000 over XMPP

* Wes Morgan:

> Hi all. I'm new to this list, so I have no idea what has been
> discussed before (is there an archive? -- I tried im2000-get.1-10,
> to no avail).

??  this should work, me thinks.  ah!  [email protected] is no ezmlm-index
list, it's plain ezmlm.  you would have to send three messages to
im2000-get.i@list... with i = {1 2 3} to retrieve the first three
messages.

then there's <URL:http://news.gmane.org/gmane.mail.im2000>, but i
don't know if old messages have been included.

> Anyway, I was reading some of djb's questions about IM2000 and
> thinking to myself that many of the issues would be (nearly) solved
> if the XMPP (a.k.a.  Jabber) protocol was used.

this is the second proposal for im2000s protocol base.  the other is
the one used for telephony over IP:
<URL:http://www.ietf.org/rfc/rfc3264.txt>.  this protocol suite would
allow im2000 to be the future all-in-one protocol, which makes things
unneccesary complicated for very simple emails, whereas XMPP looks
like a good compromise (i haven't looked at this in detail yet,
though).

could you summarize jabbers approach to authentication and encryption,
please?  note that im2000 must be able to handle one-to-many emails
with a central, possibly mirrored repository for mailinglists in
addition to the customary one-to-one emails.  the former can be
signed, the latter must also allow encryption.  note also that one of
the merits of im2000 must be spam-resistance, covered well assuming
that senders will have to provide storage facilities.  we will have
more and more roaming users, and their communication partners might
not want large binary atachments like pictures or presentations:  the
protocol must allow a certain degree of negotiation, and the
negotiation must at least be partly automatic, steered by recipients
preferences!

> Here's the scenario I'm envisioning:

> Both email clients (sender and receiver) are logged on to XMPP
> servers at their respective ISPs. Now, XMPP IDs are already very
> similar to email addresses (they only add a 'resource' on the end,
> so [email protected] is a valid XMPP ID, but [email protected]/Resource is the
> complete ID. This allows multiple clients to log on to the same
> server w/ the same auth credentials. This actually works well here
> because we could have an IM2000 resource that keeps all mail traffic
> separate from any IM or other presence/messaging traffic).  So, the
> sender ([email protected]) composes a message to the receiver
> ([email protected]) and clicks Send. The sender's email client then
> sends a presence packet to [email protected]/IM2000 notifying it
> that it has a message waiting in [email protected]'s outgoing
> queue. If [email protected] is offline, the message will be stored
> by the XMPP server until they log in.

this XMPP server would be the senders email-ISP, and it would only
accept authenticated "posts"?  your description sounds good, but it
may happen that authenticated access will be made mandatory.  there
might be email transports and im2000 transports, where the latter only
allow authenticated traffic.  then there are countries - and even
companies - not allowing encrypted emails, this must be accounted for
in the XML namespace used.

> If we assume this is an unknown sender, the receiver can now decide,
> based on the limited information sent in the 'new mail notification'
> packet, whether to download the message or 'delete' (ignore) it.

i don't think recipients should be able to delete messages on the
senders side, so "ignore" is the better term.

> Popular XMPP clients already have TLS and GPG integration for
> ensuring transaction privacy and could also be used w/ signing to
> ensure that senders are who they say they are.

btw, are there unix XMPP (jabber?) commandline clients?  without or
with optional GUI?

> Am I off base here? Has this already been discussed?

no, not off base, not at all.  we have discussed quite a lot, finding
some issues needing clarification.  unfortunately, we don't have a
reliable wiki right now, which we used to keep our respective
proposals HTML/HTTP accessible.

a little rundown of XMPP/jabber would be nice.

  clemens