This is an overview of Unsolicited File Transfer (UFT) protocol.
A sample sequence might be ...
(client connects, wait for the herald from the server)
FILE size from auth
(wait for acknowledgement from server)
USER recipient
(wait for acknowledgement from server)
TYPE A
(wait for acknowledgement from server)
DATA 12345
(send 12345 bytes and wait for acknowledgement)
EOF
(wait for acknowledgement from server)
QUIT
That transaction uses 6 primary commands and does not require any meta commands nor secondary commands. Simplicity is the first objective.
These are optional and not widely implemented. CPQ and MSG are specifically for emulating IBM NJE networking.
All of the above were originally implemented without the META prefix so it can be helpful to allow them in near-term implementations. But ideally, they are "meta". Any new meta-data must be prefixed with META for clarity and for simplifying implementations.
UFT response code numbers are unique.
Any single response code can be mapped to a specific condition,
status,
or meaning and can thus be accurately mapped to human-readable text
in national language or regional dialect.
The response codes are very rough in this draft. They are intended to be unique to make one-for-one response mappings clear for internationalization.
Response code space has gaps. That is, there are places where response code numbers appear to have been skipped. This is okay.
100s range | a spontaneous response from the server, an "info" message |
200s range | acknowledgment (ACK) |
300s range | more input requried; the client must supply additional information |
400s range | temporary error (NAK), typically a client error |
500s range | permanent error (NAK), typically a server error |
600s range | a required response from the server; contrast with 100s range spontaneous responses |
These are canonicalizations.
The purpose is to preserve file integrity, so it is not an
exhaustive list of use-based "types" like you find in /etc/mime.types.
XML, for example, should be sent as TYPE A, plain text.
TYPE A | ASCII, plain textwith CR/LF delimited lines, (0x0D/0x0A, see NVT format) |
TYPE I | IMAGE, image (binary) |
above two types are in keeping with FTP semantics | |
TYPE N | NETDATA, an IBM encoding |
TYPE E | EBCDIC, IBM mainframe plain text with EBCDIC NL (0x15) delimited lines |
TYPE M | "mail" (implies an RFC 822 message) |