FAIP
"FTN protocol without a good name"

This is the description of a transport method for transmitting binary files
over a 7 bit unreliable carrier (like RFC 822 Internet email) in lieu of
an FTS-0001 session for FTN networks. It is equally suitable for uncompressed
PKT files, Arcmail bundles, TIC files, and so on.

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 followed by 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. Any future new and not
	backward compatible release of this protocol will use a different
	revision number.


Begin-File:  [; confirm][; ...]	(multiple copies p. m. allowed)
	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 a blank line 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 in the
	whole network.
	A suggested format is .{at}, where hostname
	is the FTN address or internet domain (if unique of the system)
	and pid is a process ID, when applicable.
	Implementation of optional keywords is not mandatory.
	The recipient must ignore any unrecognised keyword.

	After  follows an optional list of keywords separated by the
"; "
	characters.
	The optional "confirm" keyword 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 optional "crc32 " keyword can be used to transmit the crc32
	of the file.
	The optional "split /" keyword means that this
file is part
	 of a file splitted in  chunks.


Optional headers are:
Confirm:  []		(multiple copies per message allowed)
	Confirms the reception of segment  of 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 (before being encoded) 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 system(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 file name is stored in an
	optional keyword "filename" of the Begin-File header.

Last words:
Use of both Confirm and Begin-File headers in the same message is allowed.

Implementations should support a per system configuration option to define
the maximum number of files to be sent in a single message.

The envelope sender of the RFC 822 message should be different from the
incoming mailbox for FAIP and should be forwarded to a human.

The Subject header of RFC 822 messages must begin with the string
"FAIP packet" to allow filtering by nodes without a separate
inbox for FAIP.

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.
It should be formalized with BNF definitions. It also needs a name.]


-- 
ciao,
Marco

--- ifmail v.2.13-tx8.7