THE PROBLEM

Once a program is distributed we wish to notify users that
a new version is available and what features can be found in the new
version.  In the future we may wish to provide an easy mechanism for
actually distributing the new version, but for now we will settle for
simply notifing the user that a new version exists.

THE PROPOSAL
We propose to achive this via a simple query/response transaction with
a "version server" for serveral reasons:

	1) simplicity 
	2) no protocol changes (e.g. Techmail need not change POP)
	3) we could build a generic version checker which walks a hard
disk checking for new versions of even non-network software

Version one of the protocol is designed to be as simple as possible in
an attempt to get this service working in time to be included in
Techmail V2.0.  The protocol basically consists of a client querying a
server (version-server.mit.edu) indicating the client application
name, its version, and date.  The response from the version server may
indicate that the client is up-to-date, or that the client is out of
rev.  In that case a text message is included for display to the end
user, and the status of the new version is also indicated (some
releases may be for intermediate versions, to fix specific problems,
not required for all users, while others may be required ... i.e.
phasing out support for an old version of POP).  The client is
expected to filter the message should the user not choose to update.

Note, the client software need not query the version server every time
it starts up.  

PROTOCOL

Strings are null terminated.  All shorts and longs are transmitted in
network byte order.

Packet format:

Type	Field

ushort	protocol version number
ushort	packet number
ushort	number of packets
ushort	operation
ushort	status of new version
ulong   sequence number (random for replay detection)
ulong	application date (released)
string	application name 
string	application version
string	message text

Client Application -> Version Server

protocol version number = 1
packet number = 1
number of packets = 1
operation = CHECK_VERSION
status of new version = 0
app date, name, version filled in appropriately
message text = NULL

Version Server -> Client Application

If up-to-date:

protocol version number = 1
packet number = 1
number of packets = 1
operation = VERSION_UP_TO_DATE
status of new version = 0
app date, name, version filled in appropriately
message text = NULL

If newer version (i.e. version != current version and version date <
last app date)

protocol version number = 1
packet number = 1
number of packets = sizeof(message) + / MTU
operation = NEW_VERSION
status of new version = REQUIRED or RECOMMENDED or OPTIONAL
app date, name, version filled in appropriately
message text = correct message.

If message is too large to fit in one packet, the client should send
another request with operation = GET_MESSAGE and packet number (2, 3,
...) until he receives the last packet (number of packets sent back in
the NEW_VERSION message).