This is my first draft of a standard for the trasmission of arcmail over
internet email. I welcome any comment.

FAIP
FTN Arcmail Incapsulation Protocol

This is the description of a transport method for arcmail packets (FTS-1) over
a 7 bit unreliable carrier like RFC 822 Internet email.

A FAIP-compliant message contains one or more pseudo headers, one per line
and without any blank line in the middle. Some headers (like Begin-Packet)
can have additional data in the following lines.
A blank line must be interpreted by the recipient as the end of message.
Any unrecognized header must be ignored (or logged) by the recipent.

Every header must start at the beginning of the line. The header and the value
must be separed by a colon and blank space (one or more spaces and/or tabs).

The required headers for a basic implementation are:
FAIP-begin: 1
		This must be the first header. The recipient must search for
		it in the first 20 lines of the incoming message. An eventual
		new and not backward compatible release of this protocol will
		use a different revision number.

Begin-packet:   [confirm]
		This header specifies the beginning of an encoded file. The
		encoded file will start from the following line and other
		headers, if any, will start after the last line of the
		encoded data.
		 is the encoding used. Some encodings are defined at
		the end of this document. Support for the uue encoding is 
		mandatory.
		 is an identification string that must be unique forever.
		A suggested format is {at}, where hostname
		is the FTN address or internet domain (if unique of the
		system).
		The optional "confirm" string requests a confirmation of the
		reception of the file. If no confirmation is received after
		an user defineable time the file must be sent again. The
		implementation of this feature is not mandatory.
		The recipient must ignore any unrecognised string after .

Optional headers are:
Confirm: 				(multiple copies per message allowed)
		Confirms the reception of the packet .
Auth:  []
		This header specifies the authorization method. Some suggested
		methods are:
		pwd - the password specified after  must match the one
		stored on the recipient's system. This method does not offers
		any protection against man-in-the-middle attacks.
		PGP - the whole body of the message is clearsigned with PGP,
		using the key of the sender system.
Crypt: 	This header specifies the encryption used. Every file will be
		encrypted with the specified cypher using a secret previously
		exchanged by the systems. The "PGP" type is special: the
		files will be encrypted with PGP using the public keys of the
		recipient(s).

Encodings:
uue	the classical uuencoding. The file name is stored in the "begin" line
	of the encoding.
base64	the encoding specified in RFC 2045. The first line has the format
	" ".  is the number of
lines of encoded data
	that will follow.

Last words:
Why there is no support for MIME? Because it's an overkill. Implementing a
complete MIME parser is a difficult task and this protocol does not needs
any of the advanced features of MIME.

Author:
Marco d'Itri
2:332/206.10
2:335/680.666
md{at}linux.it

[This is just a draft. English is not my first language, someone should 
rewrite this document in a better form, or at least correct mistakes.
Maybe it should be formalized with BNF definitions.]


-- 
ciao,
Marco

--- ifmail v.2.12-tx8.6