The equivalents shown in the following table may also be found to be useful.  Table K.2 relates certain segments of EDIFACT, UNTDI and ANSIX12 in order to show the equivalent terms for each of the three EDI standards. 
TABLE K.2

Comparison of terms for EDI Interchange header segments
	EDIFACT	UNTDI	ANSIX12
	Interchange Header	Start of Transmission	Interchange Header
	(UNA and UNB)	(STX)	(ISA)

	Functional Group Header	-----	Functional Group Header
	(UNG)		(GS)

	Message Header	Message Header	Transation Set Header
	(UNH)	(MHD)	(ST)
ANNEX L

Comparison of terms in this Recommendation
and Recommendation F.435

(This annex does not form an integral part of this Recommendation.)
The purpose of this annex is to facilitate comparison between the terminology used in this Recommendation and that used in Recommendation F.435.
The following table shows how Elements of Service defined in Recommendation F.435 are realized with protocol elements in this Recommendation.  The Elements of Service appear in the order in which they are defined in Annex B of Recommendation F.435.  For this Recommendation, reference is made to the title of the divisions which define the protocol elements.
TABLE L.1

Comparison of terms in this Recommendation
and Recommendation F.435
	Recommendation F.435	This Recommendation
	Application Security Element	EDI Application Security Element
	Character Set	EDI Body Part Type
	Cross Reference Information	Cross Referencing Information
	EDI Forwarding	EDI Forwarding
	EDI Message Type(s)	EDI Message Type
	EDI Notification Request 	EDI Notification Requests
	EDI Standard Indication	EDI Body Part Type
	EDI-message Identification	EDIM Identifier
	EDIM Responsibility Forwarding Allowed Indication	Responsibility Passing Allowed
	EDIN Receiver	EDIN Receiver
	Expiry Date/Time Indication	Expiry Time
	Incomplete Copy Indication	Incomplete Copy
	Interchange Header	Heading Fields from Interchange Header
	Multi-part Body	EDI Messages
	Non-repudiation of Content Originated	Originate EDIM
	Non-repudiation of Content Received	Originate EDIN and Internal Procedures
	Non-repudiation of Content Received Request	Originate EDIN and Internal Procedures
	Non-repudiation of EDI Notification	Originate EDIN and Internal Procedures
	Non-repudiation of EDI Notification Request	EDI Notification Requests
	Obsoleting Indication	Obsoleted EDIMs
	Originator Indication	Originator
	Proof of Content Received	Originate EDIN and Internal Procedures
	Proof of Content Received Request	Originate EDIN and Internal Procedures
	Proof of EDI Notification	Originate EDIN and Internal Procedures
	Proof of EDI Notification Request	EDI Notification Requests
	Recipient Indication	Recipients
	Related Message(s)	Related Messages
	Services Indication	Heading Extensions
	Stored EDI Message Auto-forward	Auto Action Types
	Typed Body	EDI Messages
ANNEX M

Realization of an EDIMG User in the Directory

(This annex does not form an integral part of this Recommendation.)
An EDIMG User object class that a Directory administrator can realize contains a set of characteristics that define its application, communication mechanism, depending entity, and naming. The following text describes how such an EDIMG User object class, for use with EDI messaging, can be realized from the generic EDI User object class and suggests a manner in which it can be defined.
This need can be rationalized from the following observations:
a)	The description of the EDI User object class in Annex J of this Recommendation is that of a generic EDI user. That is, a description that does not presuppose a notion of a specific communication mechanism such as MHS. EDI users may desire to use other communication mechanisms.
b)	The definition of the MHS User object class in Recommendation X.402 is of a generic MHS User. It does not presuppose that a MHS User is associated with any particular kind of "named" entity, such as country, or organization. Also, its definition does not limit the MHS User to the Interpersonal Messaging Service.
c)	The selected object classes in Recommendation X.521 define the characteristics for a set of "independent" entities, such as country and organization, and their name forms. These entities are generic in the sense that they are not bound to any particular kind of user application.
d)	Recommendation X.521, Annex B, suggests a set of relationships among these entities. These relationships form the DIT structure, and thus the naming of the entities. As in point b above, the notion of an application or how applications are used in a communication mechanism is open ended.
e)	The Directory recommendations do not prescribe a "binding" mechanism that will allow the formation of composite objects from generic objects. 
To realize a Directory entry for an EDIMG user requires that a new unregistered object class be defined. This new object class forms a composite of the characteristics from each desired generic object class, for example, by combining the EDI User object class and MHS User object class into a new unregistered object class. In ASN.1 this may be expressed as:
edimg-user OBJECT CLASS  ::=  SUBCLASS OF edi-user, mhs-user
NOTE - An Unregistered Object Class is discussed in 9.4.1 of Recommendation X.501, as an object class without an assigned object identifier. It is intended for local use as a means of conveniently adding new attribute types to a pre-defined superclass.
In this example, the edimg-user is a type identifier specified by the defining Directory administration. Additionally, the administration may include private attributes by adding the MUST CONTAIN and MAY CONTAIN statements to the unregistered object class definition.
In addition to the definition of the content of Directory entries by use of the object class notation, a naming policy for these entires is also required.  For example, using the approach of Annex B of Recommendation X.521 it may be specified that for entries of the EDI User object class, the EDI Name attribute is used for naming; entries of this object class may be immediately subordinate to entries of for example, Organization object class or Organizational Unit object class.
To provide an alternative name for an EDIMG user requires that another unregistered object class be defined. This new object class forms a composite of the characteristics from the alias object class and the desired EDI user naming attribute. In ASN.1, this may be expressed as:
edimg-user-alias OBJECT CLASS  ::=  SUBCLASS OF alias  MUST CONTAIN {edi-name}
The alias may contain only naming attributes. Its allowed relationships within the DIT shall be specified, as described above, for the naming policy of the unregistered EDIMG User object class.

Index	
This annex indexes this Recommendation. It gives the number(s) of the page(s) on which each item in each of several categories is defined. Its coverage of each category is exhaustive.
This annex indexes items (if any) in the following categories:
a)	Abbreviationsb)	Notification Reason Codesc)	Termsd)	Object Identifierse)	ASN.1 macrosf)	ASN.1 modulesg)	Information itemsh)	ASN.1 typesi)	Upper Boundsj)	ASN.1 values