Migration: T3P

[Francois-Rene Rideau]

Happy Tunesers,
   after having exchanged mail with Chris,
hereby is what I just added to the Migration page,
just before and at the beginning of the ToDo list.
Any taker is welcome, else, once again,
you'll have to wait for me to do it;
but then don't complain about "nothing concrete being done".
I'm real sorry not to produce actual code myself,
but believe me I'm *really* overworked by duties external to Tunes currently,
and in serious bureaucratic trouble.

------>8------>8------>8------>8------>8------>8------>8------>8------>8------
<LI><DT><H4>Protocol</H4>
<DD>
<UL>
<LI>We must develop some universal protocol to vehicle information
	on the loose unreliable network of world's computer.
<LI>That protocol must work on any media,
	but be particularly suited to the cheap unreliable ones,
	like e-mail, floppies, and serial line transfer,
	that are relatively cheap,
	but such a hassle to use currently,
	because there exist only inconsistent low-level tools
	to extract information from them.
<LI>This will be the T3P: Tunes Packet Publishing Protocol.
	Basically, packets are information contained in streams of raw data.
<LI>The protocol should thus stress on consistency:
	data integrity,
	object identification.
<LI>Because every medium has its own characteristics,
	the protocol should be modular,
	so that what signature method will be used
	to identify the message or its author,
	what error-detection and error-correction
	sub-protocol will be used,
	what compressed or depressed data encoding will be used, etc.
<LI>Contrarily to many other protocols,
	data interpretation will not be left undefined.
	Instead, every single object will be typed and/or tagged,
	so that it is not yet another system of inconsistent tools
	that the user must manually coordinate,
	but a consistent system of tools that hook into each-other,
	under control of the user.
<LI>Competing and intercommunicating agencies of well-known addresses
	will provide a directory of datahandlers
	according to their type/tags,
	so that anyone who finds an object one doesn't know
	can automagically download the right handler
	from whoever publishes it.
<LI>Of course, automagic downloaders
	will by default be configured with severe security requirements,
	anti-memory-overflow and other fool-proofing,
	queueing unsecure messages for manual handling.
<LI>Each kind of "raw data" will have its own version of the T3P.
<LI>Bytes will have their TB3P.
<LI>ASCII text will have the TA3P,
	that will use only the 95 standard ASCII characters,
	plus an undefined end-of-line sequence,
	limiting lines to 77 characters,
	and always being line-terminated.
	A good start for it might be MIME, if it's simple enough.
	Else, it should be started from scratch.
<LI>Every T3P variant will be self-identifying with some kind of
	"magic number" signature.
<LI>A T3P packet must be able to identify the end of the information stream
	independently from the underlying media.
<LI>Unreliable broadcast packets, such as those in e-mails and floppies,
	will have some (hopefully) uniquely identifying number.
<LI>Packet handlers may have an ID number database,
	so as to treat (or discard) packets according to
	what one already knows about these packets.
</UL>



<P><HR><P>
<A NAME="todo"></A>
<H3>To Do on this page</H3>
<LI>Implement and experiment the TA3P
	as a perl or scsh script,
	then hook mail to it (with procmail or whatever),
	as well as floppy-checkers, etc.
------>8------>8------>8------>8------>8------>8------>8------>8------>8------

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"