UFT Protocol Overview
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.
UFT Commands
session initiators:
- "FILE" -- initiate a session to send a file
- "PIPE" -- initiate a session to send a stream of data
session control:
- "USER" -- indicate the user to receive it
- "TYPE" -- indicate the type of content (e.g., text or binary)
- "DATA" -- send a block of data
- "AUXDATA" -- send a block of extended attributes (such as the resource fork)
- "EOF" -- signal end-of-file or end-of-stream
- "ABORT" -- abort the transaction and discard any content already sent
- "QUIT" -- cleanly close the session
supplemental commands:
- "CPQ" -- special "query" command
- "MSG" -- deliver an interactive message
- "AGENT"
- "HELP" -- protocol help (from server, if available)
- "NOOP" -- do nothing, successfully (and return a "success" response)
metadata commands:
- [ "META" ] meta
- "NAME" -- name of file, if any
- "DATE" -- date stamp in human readable form
- "XDATE" -- date stamp as seconds since the epoch
- "OWNER" -- file owner, if applicable
- "GROUP" -- file group, if applicable
- "XPERM" -- file permissions, if applicable
- "VERSION" -- file version number, if applicable
- "RECFMT" -- record format, if file is record oriented
- "RECLEN" -- record length, if file is record oriented
- "CLASS" -- print or queue class (for printed output)
- "FORM" -- forms code (for printed output)
- "HOLD" -- hold flag (for printed output)
- "COPY" -- number of copies (for printed output)
- "FCB" -- forms control buffer (for printed output)
- "UCS" -- character set (for printed output)
- "DEST" -- destination code (e.g., print queue) for printed output
- "DIST" -- distribution code (e.g., mailstop) for printed output
- "TITLE" -- title for header sheet (for printed output)
- "SEQ"
Canonicalizations
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 TYPE A, plain text.
TYPE M (mail) is included to facilitate
server operation, so that UFT servers which handle "mail" specially
need not resort to ad-hoc methods.
TYPE N   (NETDATA) 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
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.
Response Codes
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.