TABLE I.1

Additions to Table 7 of Recommendation X.402
Services	UA	UA	MS	UA	MTA	MTA	MTA	MS
	UA	MS	MTA	MTA	MS	MTA	UA	UA
Origin Authentication		(as defined in Recommendation X.402)
EDIM Responsibility Authentication
Proof of EDI Notification	X	-	-	-	-	-	-	-
Proof of Retrieval	-	X	-	-	-	-	-	-
Proof of Transfer	-	-	-	-	-	X	-
Secure Access Management		(as defined in Recommendation X.402)
Data Confidentiality		(as defined in Recommendation X.402)
Data Integrity		(as defined in Recommendation X.402)
Non-repudiation		(as defined in Recommendation X.402)
Non-repudiation of EDIM Responsibility
Non-repudiation of EDI Notification	X	-	-	-	-	-	-	-
Non-repudiation of Retrieval	-	X	-	-	-	-	-	-
Non-repudiation of Transfer	-	-	-	-	-	X	-	-
Non-repudiation of Content	X	-	-	-	-	-	-	-
Message Security Labelling		(as defined in Recommendation X.402)
Security Management Services		(as defined in Recommendation X.402)

NOTE - In the above table UA means EDI-UA and MS means EDI-MS.  The column headings in the above table correspond to those of Recommendation X.402 (except that typographical errors in Recommendation X.402 are not reproduced in the above table).  Rows shown in bold typeface indicate classes of security services.
ANNEX J

Directory Object Classes and Attributes

(This annex forms an integral part of this Recommendation.)
J.1	Introduction
Several Directory object class attributes and attribute syntaxes are specific for an EDI user.  These are defined in Annex H of this Recommendation.  In this annex, EDI user refers to a generic EDI user that is not bound to a communication mechanism or any named entity, such as country or organization.  The term EDI user is used in this annex to mean a generic EDI user.  EDI user is not to be confused with the terms "EDI messaging system user" and "user" defined in the main text of this Recommendation.
J.2	Object Classes
The object classes specific to EDI use of the Directory are:
-	EDI User object class
-	EDI User Agent object class
-	EDI Message Store object class
J.2.1	EDI User Object Class
The EDI User object class defines the characteristics of an EDI user. The attributes in its definition identify the EDI user's name and, to the extent that they are present, identify the EDI user's capabilities.
NOTE - The definition of the EDI User object class is generic and is formally outside the scope of MHS.  However, no other group has provided a definition and therefore the present definition is provided.
J.2.2	EDI User Agent Object Class
An EDI User Agent object class defines an Application Entity that is able to realize an EDI-UA. The attributes in its definition, to the extent that they are present, define the capabilities of the EDI-UA, identify the EDI-UA's owner, its deliverable content length, content types and EITs, and its OR Address.  Some of these attributes are derived from the MHS User Agent object class defined in Recommendation X.402.
J.2.3	EDI Message Store Object Class
An EDI Message Store object class defines an Application Entity that is able to realize an EDI-MS.  The attributes in its definition, to the extent that they are present, describe the EDI-MS, identify its owner, specify its capabilities and enumerate the optional attributes, auto actions and content types it supports.  Some of these attributes are derived from the MHS Message Store object class defined in Recommendation X.402.
J.3	Attributes
The attributes specific to EDI use of the Directory are:
-	EDI Name attribute
-	EDI Routing Address attribute
-	EDI Capabilities attribute
J.3.1	EDI Name Attribute
The EDI Name attribute identifies the EDI user.  The EDI Name attribute corresponds to the Sender identification code of the Interchange sender (or Recipient identification code of the Interchange recipient) fields of the EDI Interchange header segment.
J.3.2	EDI Routing Address Attribute
The EDI Routing Address attribute further qualifies the name of an EDI user.  It corresponds to the Routing Address sub-field of the Interchange Recipient field defined in the EDIM Heading field.
J.3.3	EDI Capabilities Attribute
The EDI Capabilities attribute defines the capabilities of an EDI user. These capabilities include the support of EDI documents and EDI Interchange types.
The EDI Interchange types are represented by object identifiers.
J.4	Attribute Syntaxes
The attribute syntax specific to EDI use of the Directory is identified as EDI Capabilities attribute syntax.
The EDI Capabilities attribute syntax describes an attribute each of whose values identifies two components:
-	supported EDI Interchange types (EDI Bodypart Types Syntax)
-	EDI documents processable by the EDI user
Only equality matching rules apply for this attribute.
J.4.1	EDI Bodypart Type Syntax
The EDI Bodypart Type syntax identifies the EDI standard (EDIFACT, ANSIX12, UNTDI or Private), and character set and/or encoding that EDI user is able to handle. It is characterized by an object identifier. Annex A of this Recommendation defines a set of object identifiers that may be used as a value for this attribute.
J.4.2	EDI Processable Document Syntax
An EDI Processable Document syntax, depending on its type, identifies an EDI document by:
a)	Standard Version: the value identifies the version of the Standard.
b)	Standard Syntax Identifier: the value identifies the syntax version of the standard. Note: For example, for EDIFACT, this identifies which syntax level is supported (Level A or B).
c)	Document Type: the value identifies the structure of the document.
d)	Document Version: the value identifies the version of the Document Type.
e)	Document Release: the value identifies the release of the Document Type.
f)	Controlling Agency: this value identifies the agency that ratified the definition of the standard document.
g)	Association Assigned Code: this identifies who developed the definition of the document.
ANNEX K

Comparision of terms of EDI syntaxes

(This annex does not form an integral part of this Recommendation.)
The purpose of this annex is to facilitate comparison between the terms used in different EDI standards.
The heading fields of an EDIM are described in .  These descriptions, in many cases, reflect the terminology of the EDIFACT syntax (ISO 9735). Where another EDI syntax standard is used (as reflected in the EDI Body Part Type field in the header ), the terminology will not be fully compatible.
Thus, the following table outlines the comparable fields (data elements) in the United Nations Trade Data Interchange (UNTDI) and the American National Standards Institute X12 (ANSIX12) standards.
The following definitions from Annex A of ISO 9735 are included in order to aid understanding of the material in this annex:
-	Interchange: communication between partners in the form of a structured set of messages and service segments starting with an interchange control header and ending with an interchange control trailer.
-	Segment: a predefined and identified set of functionally related data element values which are identified by their sequential position within the set.  A segment starts with a segment tag and ends with a segment terminator.  It can be a service segment or a user data segment.
-	Data element: a unit of data for which the identification, description and value representation have been specified.
Table K.1 lists the EDIM Heading fields which are related to EDI Interchange header segments and shows the corresponding EDIFACT, UNTDI and ANSIX12 data elements present in, respectively, the UNA plus UNB, STX and ISA segments.
TABLE K.1

Comparison of terms for EDI Interchange header fields
X.435 Fields	EDIFACT	UNTDI	ANSIX12
Heading	(UNA and UNB)	(STX)	(ISA)

Service String Advice	Service string advice	-----	1.Data Element Separat.
			2.Segment Terminator
			3.Subelement Separator

Syntax Identifier	Syntax identifier	Syntax rules identifier	1.Interchange
			Standard Identifier
			2. Interchange
			Version ID

Interchange Sender	Interchange sender	Transmission sender	Interchange Sender ID

Interchange Recipient	Interchange recipient	Transmission recipient	Interchange Receiver ID

Date And Time	Date/time	Date and time	1.Interchange Date
Of Preparation	of preparation	of transmission	2.Interchange Time

Interchange Control	Interchange control	Sender's transmission	Interchange Control
Reference	reference	reference	Number

Recipient Reference	Recipients reference,	Recipient's transmission	Security Information
	password	reference/password

Application Reference	Application reference	Application reference	-----

Processing Priority Code	Processing priority code	Transmission 	-----
		priority code

Acknowledgment	Acknowledgment	-----	Acknowledgment
Request	request		Requested

Communications	Communications	-----	-----
Agreement ID	agreement ID

Test Indicator	Test indicator	-----	Test Indicator

Authorization	-----	-----	Authorization
Information			Information