The User Agent

A UA has the following functionality :

• When a user originates a message, the message is encoded into a format which the recipient's UA can interpret.
• It passes the P2 message along with the information needed for its transfer, to the MTA.
• A Recipient's UA interacts with the MTA and recievesfrom it the messages, along with transmission infomation related to the message, addressed to the user it serves.
• The UA decodes the messages it receives from the MTA and presents them to the recipient in a user- friendly format. In addition, upon decoding the message, the UA may take action or notify the user about elements related to the message, such as the originator's request that a reply is expected.

A UA is served by an MTA with which it is registered. It always submits messages to the same MTA, and messages addressed to a particular UA are always delivered to the UA by the same MTA.

Since a UA is the interface between the user and the Message Handling System, means that its functionaliy can be enhanced, if the messages it handles are adjusted to give maximum functionality to the user. Since the primary users of the MHS are human, the initial types of carried by the MHS are known as interpersonnel messaging(IPM). The User Agents that support interpersonnel messaging are called IPM-UAs. Other U.As can and are being developed to cater for particular types of messages for example an EDI-UA for EDI transfers. An MTA serving a particular UA ensures that the content of the message is of a type that can be understood by the particular UA.

Only U.As of the same type can exchange messages and interpret them. Thus an IPM-UA cannot communicate with an EDI-UA. This is useful at one level as IPM and EDI have very different requirements, but it does limit the possiblity of an implementer constructing a UA capable of acting as both an IPM-UA and as an EDI-UA.

When the User Agent concept was originally developed, two UA types were defined under X.400, they were: the collocated UA and the remote UA. A collocated UA is a UA which is implemented in the same "computer" as the MTA which serves it. A remote UA is located in a computer geographically separate from the MTA. In the case of the collacted UA, the UA-MTA interface is an implementation detail while in the remote UA, the UA-MTA link is prone to error or failure. The P3 protocol in X.411was developed to deal with these problems.

The Remote UA Approach

At the time it was designed at accomadating P.C.s. The thinking then was that an MTA serving a PC acting as a remote UA, would establish a connection to the PC and deliver messages addressed to that UA. This approach never materialised in actual implmentations. P.C.s, as genrally used are not available most of the time to receive connections, they often turned off after business hours, or used for other work. Some problems arise due to unavailability, and results in a high proportion of falure and timeouts. P.C.s acting as U.A.s and communicating with MTAs fall into two categories:

1. The PC acting as the UA is connected to a LAN, which contains a server acting as an MTA. In these cases it is not necessary to implement the P3 or MTS access protocol between UA and the MTA since it is already provided by the native file transfer protocol of the LAN.
2. The PC is used as an intelligent terminal and connects to a mail system providing UA functionality, using in effect a collocated UA.