This is an overly terse summary of the UFT protocol.
It will make sense to the highly technical bit-snapper, but may be completely obscure to a normal human being.
|TYPE A||"ASCII" (plain text, ala NVT)|
|TYPE I||"IMAGE" (binary)|
|TYPE V||record oriented (any of several vendors)|
|TYPE N||"NETDATA" (an IBM format)|
|TYPE E||EBCDIC (IBM mainframe plain text)|
|TYPE M||"mail" (implies an RFC 822 message)|
These are canonicalizations, not a comprehensive list of all types of files. Proper types should be layered on the above list to get clean file transport. XML, for example, should be sent as &sp; TYPE A, &sp; plain text.
TYPE M &sp; (mail) &sp; is included to facilitate server operation, so that UFT servers which handle "mail" specially need not resort to ad-hoc methods.
TYPE N &sp (NETDATA) &sp; is included to facilitate interoperation with NJE networks. It is easily decoded by off-the-net sample code from a variety of sources. Transmitting agents (clients) need not implemented it. Receiving agents (servers and de-spooling programs) should implemented it if they are to be run on final destination hosts which might receive files in NETDATA format from IBM hosts.
Clearly not all file structure is yet represented. This is an open specification. As more is needed, it can be added.
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.
For more information, see the UFT home page.