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:

a)	Abbreviationsb)	Notification Reason Codesc)	Termsd)	Object Identifierse)	ASN.1 macrosf)	ASN.1 modulesg)	Information itemsh)	ASN.1 typesi)	Upper Boundsj)	ASN.1 values