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 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: CCITT Draft Rec. X.435 page1