This is an overview of Unsolicited File Transfer (UFT) protocol.

UFT Primary Control Verbs

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)
(wait for acknowledgement from server)
DATA 12345
(send 12345 bytes and wait for acknowledgement)
(wait for acknowledgement from server)

That transaction uses 6 primary commands and does not require any meta commands nor secondary commands. Simplicity is the first objective.

UFT Supplemental Commands

These are optional and not widely implemented. CPQ and MSG are specifically for emulating IBM NJE networking.

UFT Meta Verbs

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.

Response Codes

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  

UFT File Types (canonicalizations)

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)