There are a few major principles that underpin the design of IM2000 and these proposals:
The fundamental problem with SMTP electronic mail and unsolicited bulk mail is that it is cheap for senders to make copies of and to transmit messages, putting senders at an advantage with respect to recipients. The SMTP mail architecture is confounded by this.
It is interesting to note that the SMTP electronic mail architecture inherits this weakness from the postal mail architecture, and that were copying and transmission as cheap for postal mail as they are for SMTP electronic mail the postal mail system would also suffer from the very same problem of unsolicited bulk mail.
(Indeed, it is worth noting that when computer telecommunications are used to distribute the cost of generating and transmitting postal mail across large numbers of senders, effectively reducing the costs to the same levels as with SMTP electronic mail, this very problem is readily demonstrable with postal mail, as Alan Ralsky found out .)
By contrast, the IM2000 mail architecture takes advantage of the fact that senders have low copying and transmission costs, by having an architecture where messages are sent to recipients from message stores on demand, and where message notifications to recipients are discardable.
Some IM2000 proposals contain the assumption that everyone will want their message stores and their recipient notification agents to be run by the same company that provides their IP connectivity. Such assumptions have knock-on design consequences that make public mailing lists unfeasible. They also prevent both the existence of "roaming" users and the possibility of users shopping around amongst multiple service providers to get the best services, by locking people into their ISPs.
These proposals contain no such assumption, allowing for "third party" message store hosting and recipient notification agent hosting services.
Some IM2000 proposals have recipient notifications carrying all sorts of stuff that is specified by the message originator, such as the message subjects and other headers. This provides a trivial covert channel for the senders of unsolicited bulk mail to subvert the system, by (for example) simply moving the entire message into the subject.
In these proposals, nothing in the recipient notification that reaches the recipient MUA is directly specified as part of the message by the message originator.
To achieve the same ends that the other proposals attempt to achieve by their inclusion of message headers in recipient notifications, these proposals provide a mechanism for recipient MUAs to fetch only the "summary" headers for a message from message stores.
(Collusion between message stores and malicious originators to send all of a message anyway, when only summary headers are requested, can only waste bandwidth, since good recipient MUAs will only process the "summary" headers and ignore any others sent, and will only do so where recipients actually decide to find out more about the message from the message store in the first place, which will not occur often for malicious message stores given that the the primary weapon against them is to have recipient notification agents ostracise them.)
Computers speak protocols, not humans. Humans use tools to translate protocols to human-readable form. The IM2000 protocols are designed to be simple and unambiguous for computers to parse.
The design of SMTP was influenced by the concept of using the TELNET program as an SMTP client. This lead to such mistakes as the help and quit verbs, and the initial greetings banner. Also, the protocol was specified in terms of human-readable commands and responses, leading to such problems as
TELNET is not intended to be a client for any of the IM2000 protocols. The protocols are designed primarily to be machine-readable, using encoding rules designed for simple, flexible, and unambiguous binary protocols.
If it's good enough for the DNS protocol and LDAP, it's good enough for IM2000.
IM2000 changes the ways that messages are hosted and transported, and what is in their accompanying envelopes. It doesn't change the actual message format. There's no reason to.
IM2000 treats messages as unformatted octet streams transported with explicit length indicators. In principle, it is neutral with respect to choice of message format.
Originator MUAs and recipient MUAs for Internet expect messages to be in the same Internet message format as used by SMTP-based Internet mail.