this version: D1 [2001-12-10 12:51]

This is the second in a series of messages intended to break down
im2000 discussion into bite-sized pieces.

I think we can take for granted that the user may choose their program
for editing messages.  (This message is powered by vi.)

After that, however, they will need to provide their IM2000 with a copy
of the message, and pertinent data to send notifications and allow
retrieval. 

This is accomplished with IMTP, the Internet Mail Transfer Protocol.

(a) Protocol
	Presumably, IMTP should be TCP-based.  Messages will be (often, if not
	always) signed and encrypted, and data-loss is not an option.  Further,
	if users wish to send messages in batches, a TCP-based system will
	allow them to do so over one connection.

(b) Authentication
	When senders are responsible for storage of their mail, it becomes
	even more important that no one else be able to send mail in their
	name.  How should IMTP servers authenticate senders? 
	I would imagine a public-key system will integrate nicely with the
	encryption/signing of messages, but because built-in security
	often seems pathetic a few years after inception, the actual
	methods of securing servers should be modular.  After all, once
	everyone's cellphone is capable of using 65536-bit keys, why
	shouldn't they?  (Especially when pocket calculators can break
	4096-bit keys.)

(c) Relaying
	Should an IM2000 implementation be allowed to receive messages on
	one system/interface and serve them on another?  If IMTP only handles
	receiving mail from senders, will IM2000 allow this transaction:
		bob   -imtp-> a.im   : here is a message
		a.im  ------> b.im   : serve this message
		b.im  -imnp-> alice  : you've got mail
		alice -imrp-> b.im   : give me my mail
	While this looks good for netadmins, who can now distribute the load
	across many systems and through firewalls, it introduces the concept
	of relayed message;  many of us will cringe at the thought of
	continuing mail relaying, but it might not be an evil, if it's
	implemented properly.
	Further, if relaying is allowed, will servers speak IMTP to one another,
	or something else?

(d) Meta-data
	SMTP and RFC822 allow for nearly unlimited meta-data about a message
	to be stored.  With X-Headers (such as those in this message), one
	can use messages to store arbitrary structured data.
	IM2000 messages must more clearly define some message headers (the
	message envelope and to/from fields, especially).  Beyond that, though,
	to what extent should meta-data be covered by protocol (that is,
	formatted into the IM2000 message format) and to what extent should
	it simple be a function of processing the body?

I'm sure there are other IMTP issues that aren't springing to mind.

--
rjbs