ce it will allow EDI types between software that supports one type or the other. processes to obtain both ORAddresses of EDI applications on The 1988 P protocol provides an X.400 message specifically for trading partners machines and the specific attributes and capabilities EDI: the EDIM. envelope is still used but it has a content type of those applications. This will ensure (if the directory is accurate!) called the 'EDI message type'. X.435 defines a user agent for that data can be sent in an appropriate format to an address that is EDIMs. In contrast to IPM an X.435 user agent does not have a known to be able to handle it. human user but the 'EDI user' is another process, i.e. the computer The structure of X.500 is similar to X.400 in as much as it consists systems that generate or use EDI data. of two key elements: the directory services agent (DSA) and the The concept of EDI notifications is also supported in 1988 P edi' as directory user agent (DUA). A DUA and a DSA converse in a in Figure 38.5. defined protocol called directory access protocol (DAP). A typical implementation in the EDI scenario is that the DUA will run in the same machine as the EDI UA and requests for information will be passed from the EDI UA to the DUA. The DUA will then ORIGINATOR RECIPIENT extract the information using DAP from a remote directory, perhaps maintained centrally by a VAN (in X.500 terms an ADDMD FIELDS FROM Envelope P1 EDI INTERCHANGE administrative directory management domain). The DUA will then HEADER pass the information back to the EDI UA which can then format and NOTIFICATION HEADING address the message correctly. REQUESTS CONTENT EDI INTERCHANGE TYPE PEDI 38.7 Security OTHER BODY PART$ Security is a major consideration in EDI since much of the data e.g. DRAWING (OPTIONAL) moved using EDI can be termed 'mission critical' Security is used as a blanket term to cover many different needs according to the type of data and use to which it is being put. Three types of security are available with Pedi These can be Figure 