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

This is the third in a series of messages intended to break the current
IM2000 discussion into bite-sized morsels.

Under IM2000, when Alice sends her message to Bob, it lives on Alice's
local IM2000 server.  The server then sends messages to Bob via the Internet
Mail Notification Protocol, IMNP. 

IMNP has, so far, caused the most frowning on the IM2000 list.  Much of this
due to the suggestion that IMNP use UDP and provides as much vulnerability
to spamming and more to DoS as exists under SMTP.

(a) Protocol
	I originally suggested that IMNP live on UDP, but it may well be that
	TCP will prove more suited to this application, as long as IMNP
	conversations are kept as terse as possible.  The key is that
	notifications continue until acknowledged received, or even until
	the relevant message is retrieved.  While UDP is great insofar as
	messages can be discarded (because we know they will be repeated),
	it's harder to respond to UDP messages, harder to trace them, and
	harder to prevent DoS.
	TCP allows servers on the recipient's end to immediately react to
	IMNP messages.  The IMNP can always deal with failing to connect by
	queuing the message for later sending.
(b) Responding Immediately
	IMNP-receiving servers (WYWO (While You Were Out) Servers) can process
	IMNP messages however they see fit.  They may choose to send a pop-up
	to users (while they are in), store them for later retrieval (via
	WYWO, a POP-like protocol), file them as tickets to existing messages
	(an IMAP-like protocol), and may process them for immediate retrieval,
	rejection, or response.  (procmail2000)
(c) Backwards Compatibility
	Several people have suggested that IM2000 should come in the form
	of SMTP, QMTP, POP, and the other existing mail protocols.  I think
	we'll do much better off by starting with those as examples, not
	platforms from which to develop. 
	While it's a noble goal to allow old technology to used while new
	technology is new, that's not the same thing as requiring that the
	new technology is compatible.  Even QMTP doesn't try to process SMTP.
	Instead, specifications demand that all MXs speak SMTP. 
	How many of us would prefer that HTTP was built on top of and
	compatible with gopher?
(c) IMNP Scope
	Should IMNP messages inform the recipient of just one message each,
	or many?  Or, alternately, should they merely indicate that a given
	mailstore has some unknown amount of mail.
	I don't know if I have an opinion on IMNP sending in bulk, but it
	should communicate more than just 'you have mail.'  I would suggest
	that some minimal amount of message information is communicated via
	the IMNP message.  Perhaps { Subject, Sender, Urgency, Size }.  This
	allows automatic processing based on something other than the location
	of the message.

Assuming that not every message sent is retrieved, IMNP will be responsible=

for the most IM2000 traffic beyond the local ISP.  We have to pay attention
to detail here.  I'm sure there are plenty of details I've ignored or
forgotten.

--
rjbs