ISO/IEC 10021-8:1999

INTERNATIONAL ISO/IEC
STANDARD 10021-8
Second edition
1999-12-15
Information technology — Message
Handling Systems (MHS) —
Part 8:
Electronic Data Interchange Messaging
Service
Technologies de l’information — Systèmes de messagerie (MHS) —
Partie 8: Service de messagerie avec échange de données informatisé
Reference number
©
ISO/IEC 1999
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Published by ISO in 2000
Printed in Switzerland
ii © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
Contents Page
Foreword.v
Introduction.vi
1 Scope .1
2 Normative references.1
3 Definitions .2
3.1 Terms defined in this part of ISO/IEC 10021 .2
3.1.1 EDI forwarding .2
3.1.2 EDI message.2
3.1.3 EDI messaging user.2
3.1.4 EDI notification.2
3.1.5 EDI message responsibility .2
3.2 Terms imported from ISO 9735.2
3.3 Terms imported from ANSI X12 .3
4 Abbreviations.3
5 Conventions.4
6 EDI messaging service .4
6.1 Introduction.4
6.2 EDI messaging .4
6.3 EDI messaging environment .5
6.4 EDI messaging user.5
7 EDI messaging system.5
7.1 Introduction.5
7.1.1 EDI user agents .6
7.1.2 EDI message store.6
7.1.3 Message transfer system.6
7.1.4 EDI access units .6
7.2 Information flow in the EDIMS.6
7.3 EDI messaging service functional model.7
7.4 Structure of EDI messages .7
7.5 EDI notification.9
8 EDIM responsibility and forwarding.10
8.1 Introduction.10
8.2 Forwarding and secondary distribution.10
8.3 Case 1: No forwarding .10
8.4 Case 2: Content not changed and EDIM responsibility forwarded .11
8.5 Case 3: EDIM responsibility not forwarded.13
9 EDI naming, addressing and use of directory.15
10 EDI security.15
11 Intercommunication with physical delivery services.16
11.1 Introduction.16
11.2 Delivery and notifications .16
11.3 Transfer of EDIM responsibility.16
11.4 Physical rendition.17
12 Use of message store for EDI .18
13 Elements of service.18
14 Classification of elements of service .18
14.1 Basic EDI messaging service .18
14.2 EDI messaging service optional user facilities.19
15 Quality of service.21
15.1 EDI message status .21
15.2 Support by providers of EDI service.22
15.3 Model of delivery and notification times .22
15.4 EDI message delivery time targets.23
15.5 EDI notification time targets.23
15.6 Error protection.23
15.7 Availability of service.23
© ISO/IEC 1999 – All rights reserved iii

ISO/IEC 10021-8: 1999 (E)
Annexes
A – Glossary of terms.24
B – Definitions of elements of service .27
C – Security overview.32
D – EDI naming, addressing, and use of directory.39
E – Cross referencing overview .43
Tables
1 – Case 1: No forwarding .11
2 – Case 2: EDIM responsibility forwarded.13
3 – Case 3: EDIM responsibility not forwarded.15
4 – Provision and use of secure messaging elements of service by MHS components.16
5 – Elements of service belonging to the basic EDI messaging service.18
6 – EDI messaging optional user facilities selectable on a per-message basis.19
7 – EDI messaging service optional user facilities agreed for a contractual period of time.21
8 – EDIN time targets.23
Figures
1 – EDI messaging environment .5
2 – EDI messaging system .6
3 – Information flow in EDI messaging system.7
4 – EDI messaging service functional mode .8
5 – EDI message structure.8
6 – EDI message structure for a typical EDI transaction.9
7 – Case 1: No forwarding .11
8 – Case 2: EDIM responsibility forwarded.12
9 – Case 3: EDIM responsibility not forwarded, Part 1 .14
10 – Case 3: EDIM responsibility not forwarded, Part 2 .14
11 – M/PD delivery and notification times model .17
12 – Notification time model.22
C-1 – EDIM Responsibility transfer.36
D-1 – DIT structure for EDI requirements .40
D-2 – An aliasing example.41
D-3 – A country oriented aliasing example.42
E-1 – Cross referencing in EDI messaging .43
iv © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the
ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint
technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this part of
ISO/IEC 10021 may be the subject of patent rights. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
International Standard ISO/IEC 10021-8 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6,
Telecommunications and information exchange between systems, in collaboration
with ITU-T.
This second edition cancels and replaces the first edition (ISO/IEC 10021-8:1995),
which has been technically revised.
ISO/IEC 10021 consists of the following parts, under the general title Information
technology — Message Handling Systems (MHS):
� Part 1: System and Service Overview
� Part 2: Overall architecture
� Part 4: Message transfer system: Abstract service definition and procedures
� Part 5: Message store: Abstract service definition
� Part 6: Protocol specifications
� Part 7: Interpersonal messaging system
� Part 8: Electronic Data Interchange Messaging Service
� Part 9: Electronic Data Interchange Messaging System
� Part 10: MHS routing
Annexes A and B form a normative part of this part of ISO/IEC 10021. Annexes C, D,
and E are for information only.
© ISO/IEC 1999 – All rights reserved v

ISO/IEC 10021-8 : 1999 (E)
Introduction
This part of ISO/IEC 10021 is one of a number of parts of ISO/IEC 10021
(Information technology - Message Handling Systems (MHS)).
Message handling systems and services enables user to exchange of messages on a
store-and-forward basis. A message submitted by one user (the originator)is
conveyed by the message transfer system (MTS), the principal component of a
larger message handling system (MHS), and is subsequently delivered to one or
more other users, the message's recipients. A user may interact directly with the
MTS, or indirectly via a message store (MS).
The MTS comprises a variety of interconnected functional entities called
message transfer agents (MTAs). MTAs cooperate to transfer messages and deliver
them to their intended recipients. Message stores (MSs) provide storage for
messages and enable their submission, retrieval and management. User agents
(UAs) help users access MHS. Access units (AUs) provide links to other
communication systems and services of various kinds (e.g., other telematic
services, postal services).
This part of ISO/IEC 10021 was initially developed and published by the ITU-T in
1991. The current ITU-T version is published as ITU-T Recommendation F.435
(1999).
This part of ISO/IEC 10021 defines the overall system and service description of
the message handling application called EDI Messaging.
ISO/IEC NOTE
As stated in the ITU-T version of this part of ISO/IEC 10021 [i.e., F.435 (1999)],
the expression “Administration” is used for conciseness to indicate both a
telecommunication Administration and recognized private operating agency.
vi © ISO/IEC 1999 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 10021-8 : 1999 (E)
Information technology - Message Handling
Systems (MHS) –
Part 8 :
Electronic Data Interchange Messaging Service
1Scope
This part of ISO/IEC 10021 defines the overall system and service of EDI messaging.
Other aspects of message handling systems and services are defined in other parts of ISO/IEC 10021. The layout of
Standards | Recommendations defining the message handling system and services is shown in table 1 of ISO/IEC
10021-1 | ITU-T Recommendation X/F.400. The public services built on MHS, as well as access to and from the MHS
for public services are defined in the ITU-T's F.400-Series of Recommendations.
The technical aspects of MHS are defined in the multi part series numbered ISO/IEC 10021 and ITU-T's X.400-Series
of Recommendations. The overall system architecture of MHS is defined in ISO/IEC 10021-2 | ITU-T
Recommendation X.402. The technical aspects of EDI messaging are defined in ISO/IEC 10021-9 | ITU-T
Recommendation X.435.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 10021. For dated references, subsequent amendments to, or revisions of, any of these publications
do not apply. However, parties to agreements based on this part of ISO/IEC 10021 are encouraged to investigate the
possibility of applying the most recent editions of the normative documents indicated below. For undated references,
the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of
currently valid International Standards.
– ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2: 1998, Information technology – Open Systems
Interconnection – The Directory: Models.
– ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8: 1998, Information technology – Open Systems
Interconnection – The Directory: Authentication framework.
– ITU-T Recommendation X.521 (1997) | ISO/IEC 9594-7: 1998, Information technology – Open Systems
Interconnection – The Directory: Selected object classes.
– ISO 9735:1988, Electronic data interchange for administration, commerce, and transport (EDIFACT) -
Application level syntax rules.
– ITU-T Recommendation F.400/X.400 (1999), Information technology – Message handling services: Message
handling system and service overview.
ISO/IEC 10021-1:1999, Information technology – Message Handling Systems (MHS) – Part 1: System and
Service Overview.
– ITU-T Recommendation X.402 (1999) | ISO/IEC 10021-2: 1999, Information technology – Message Handling
Systems (MHS): Overall Architecture.
© ISO/IEC 1999 – All rights reserved 1

ISO/IEC 10021-8 : 1999 (E)
– ITU-T Recommendation X.413 (1999) | ISO/IEC 10021-5: 1999, Information technology – Message Handling
Systems (MHS): Message Store: Abstract Service Definition.
– ITU-T Recommendation X.420 (1999) | ISO/IEC 10021-7: 1999, Information technology – Message Handling
Systems (MHS): Interpersonal Messaging System.
– ITU-T Recommendation X.435 (1999) | ISO/IEC 10021-9: 1999, Information technology – Message Handling
Systems (MHS): Electronic Data Interchange Messaging System.
3 Definitions
For the purpose of this part of ISO/IEC 10021, the following definitions, and those defined in annex A apply.
Definitions of the elements of service applicable to EDI messaging are contained in annex B of this part of
ISO/IEC 10021. The elements of service applicable to the Message Transfer service, and used by EDI messaging, are
called out in this part of ISO/IEC 10021, however their definitions are contained in ISO/IEC 10021-1 | ITU-T
Recommendation F.400, annex B.
3.1 Terms defined in this part of ISO/IEC 10021
3.1.1 EDI forwarding: Onward transfer of a received EDIM to one or more recipients determined by the
forwarding EDI user agent/message store.
EDI forwarding takes place when an EDI message having been delivered to an EDI user agent or EDI message store is
forwarded onward to another EDI user agent or EDI message store.
3.1.2 EDI message: Information in electronic form that is transferred between EDI messaging users. An EDI
message is a member of the primary class of information objects conveyed between EDI messaging users.
See also ISO/IEC 10021-9 | ITU-T Recommendation X.435 clause 8.
3.1.3 EDI messaging user: User that engages in EDI messaging. An EDI messaging user originates, receives, or
both originates and receives EDI messages. The EDI messaging environment contains any number of EDI messaging
users. An EDI messaging user may be a person or a computer process. An EDI messaging user may access the EDI
messaging system through an access unit.
3.1.4 EDI notification: Member of the secondary class of information objects that indicates to the originator of an
EDI message the disposition of EDIM responsibility for the EDI message.
3.1.5 EDI message responsibility: EDI message responsibility indicates whether the subject EDI message has been
made available to a specific user by its EDI user agent/message store. EDI message responsibility carries no legal
significance within this part of ISO/IEC 10021 and ISO/IEC 10021-9 | ITU-T Recommendation X.435.
3.2 Terms imported from ISO 9735
� Acknowledgment request
� Application reference
� Communication agreement ID
� Date/time of preparation
� Functional group header
� Interchage control reference
� Interchange header
� Interchange recipient
� Interchange sender
� Message header
2 © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
� Processing priority code
� Recipients reference, password
� Service string advice
� Syntax identifier
� Test indicator
� UNA
� UNB
� UNG
� UNH
� UNT
� UNZ
NOTE – These terms are further expanded in annex A of this part of ISO/IEC 10021 and annex K of ISO/IEC 10021-9 | ITU-T
Recommendation X.435.
3.3 Terms imported from ANSI X12
� Application reference
� Date and Time of Transmission
� GS
� Interchange header
� Functional group header
� Transaction set header
� ISA
� IEA
� Recipient;s transmission reference/password
� ST
� Transmission sender
� Transmission recipient
� Transmission priority code
NOTE – These terms are further expanded in annex A of this part of ISO/IEC 10021 and annex K of ISO/IEC 10021-9 | ITU-T
Recommendation X.435.
4 Abbreviations
ANSI American National Standards Institute
AU Access unit
DIT Directory information tree
DL Distribution list
DUA Directory user agent
EDI Electronic data interchange
EDIFACT Electronic data interchange for Administration, commerce and transport
EDIM EDI message
EDIME EDI messaging environment
© ISO/IEC 1999 – All rights reserved 3

ISO/IEC 10021-8 : 1999 (E)
EDIMG EDI messaging
EDIMS EDI messaging system
EDI-AU EDI access unit
EDI-MS EDI message store
EDI-UA EDI user agent
EDIN EDI notification
FN Forwarded notification
ID Identifier
IPM Interpersonal messaging
MD Management domain
MH Message handling
MHS Message handling system
MS Message store
MT Message transfer
MTA Message transfer agent
MTS Message transfer system
NDN Non-delivery notification
NN Negative notification
O/R Originator/Recipient
PD Physical delivery
PDAU Physical delivery access unit
PDS Physical delivery system
PN Positive notification
PRMD Private management domain
TLMA Telematic agent
UA User agent
UNTDI United Nations, trade data interchange
UTC Coordinated universal time
5 Conventions
In clause 2, ITU-T aligned standards are cited.
Common language practices have been applied as far as possible in the use of capitalization of words.
6 EDI messaging service
6.1 Introduction
The EDI messaging service provides an EDI messaging user with features to assist in communicating with other EDI
messaging users. EDI messaging users are in many cases computer processes. The EDI messaging service uses the
capabilities of the Message Transfer service (see also Recommendation F.410) for sending and receiving EDI
messages. The elements of service describing the features of the EDI messaging service are defined in annex B, and
classified in clause 14.
EDI, electronic data interchange, can be described as computer to computer exchange of structured business data, such
as invoices and purchase orders. In some cases the EDI messaging service can be used to transmit an EDI interchange
to a physical rendition system, such as a physical delivery system, or facsimile.
The EDI messaging service is provided by EDI messaging.
6.2 EDI messaging
EDI messaging (EDIMG) consists of the exchange of EDI messages (EDIMs), and EDI notifications (EDINs), which
are information objects specified in ISO/IEC 10021-9 | ITU-T Recommendation X.435.
4 © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
6.3 EDI messaging environment
The environment in which EDI messaging takes place can be modelled as a functional object which is hereafter
referred to as the EDI messaging environment (EDIME). When refined (i.e., functionally decomposed), the EDIME
can be seen to comprise lesser objects referred to as the primary objects of EDI messaging. They include a single
central object, the EDI messaging system (EDIMS), and numerous peripheral objects called EDI messaging users
(EDIMG users).
The structure of the EDIME is depicted in figure 1.
EDI messaging
environment
EDIMG
user
EDIMS
EDIMG
user
T0101260-93
Figure 1 – EDI messaging environment
6.4 EDI messaging user
An EDI messaging user (EDIMG user) is a user that engages in EDI messaging. An EDIMG user originates, receives,
or both originates and receives EDIMs. The EDIME contains any number of EDIMG users.
An EDIMG user may be a person or a computer process. An EDIMG user may access the EDIMS through an
access unit.
7 EDI messaging system
7.1 Introduction
The EDI messaging system (EDIMS) is the functional object by means of which all EDIMG users communicate with
one another in EDI messaging.
The EDIMS can be modelled as comprising lesser functional objects which interact with one another. These lesser
objects are referred to as the secondary objects of EDI messaging. They include a single, central object, the message
transfer system (MTS), and numerous peripheral objects of three kinds: EDI user agents (EDI-UAs), EDI message
stores (EDI-MSs), and EDI access units (EDI-AUs).
The structure of the EDIMS is depicted in figure 2. As shown in figure 2, EDI-UAs, EDI-MSs, and EDI-AUs are the
objects by which the EDIMS provides service to EDIMG users.
© ISO/IEC 1999 – All rights reserved 5

ISO/IEC 10021-8 : 1999 (E)
EDIMG
user
EDI messaging system
EDI-UA
Message
EDI-MS transfer
system
EDI-UA EDI-UA
EDIMG EDIMG
user user
T0101270-93
Figure 2 – EDI messaging system
7.1.1 EDI user agents
An EDI user agent (EDI-UA) is a user agent tailored so as to better assist a single EDIMG user to engage in EDI
messaging. It helps that EDIMG user originate and receive messages containing EDIMs. The EDIMS contains any
number of EDI-UAs.
NOTE – An exact definition of the boundary between the EDI-UA and the EDIMG user is beyond the scope of this part of
ISO/IEC 10021.
7.1.2 EDI message store
An EDI message store (EDI-MS) is a message store tailored so as to better assist a single EDI-UA engage in EDI
messaging. It helps that EDI-UA submit, take delivery of, store, and retrieve messages containing EDIMs.
7.1.3 Message transfer system
In the present context the message transfer system (MTS) conveys EDIMs or EDI notifications (EDINs) between
EDI-UAs, or between an EDI-UA and an access unit. The EDIMS contains a single MTS.
7.1.4 EDI access units
An EDIMG user may have access to/from the EDIMS through an access unit (AU). One type of access unit is the
physical delivery access unit (PDAU). In EDIMG, the physical delivery access unit provides the ability to send
messages to EDIMG recipients through a physical delivery system (PDS). Other types of EDI-AUs (e.g., facsimile
access units) may be the subject of future standardization.
7.2 Information flow in the EDIMS
Figure 3 expands on figure 2 and shows the principal information flows in EDI messaging.
NOTE – Figure 3 illustrates aspects of the EDI encoded data exchanged in this model, not the actual details.
6 © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
EDIMG user
(EDI application)
EDIFACT UNTDI
ANSI X12
UNA ISA STX
EDI interchange including
interchange control information
or or
(i.e., receiver ID. Etc.)
UNZ IEA END
EDI messaging system
- Generates EDI heading and submit envelope from interchange
control info plus other info in EDI Interchange (receiver ID maps
into X.400 O/R name)
- Places EDI heading + EDI interchange in submit envelope
EDI-UA
and submits to MTS
{
- On delivery from MTS extracts EDI interchange and passes
to EDI application
MTS
MTA
EDIMG EDIMG
EDI-UA
MTA MTA EDI-MS EDI-UA
user user
T0101280-93
NOTES
1 – For abbreviations and acronyms see 4 and annex A of this part of ISO/IEC 10021.
2 – The structure of the information exchanged between the EDIMG user and the EDI-UA is not defined by this
part of ISO/IEC 10021. In addition to the EDI interchange, the control information may comprise information
carried in the envelope, EDIM heading, interchange header, etc. The control information could also be extracted
from the EDI interchange and/or form other sources.
Figure 3 – Information flow in EDI messaging
7.3 EDI messaging service functional model
Figure 4 shows the functional model of the EDI messaging service. The UAs used in the EDI messaging service
comprise a specific class of cooperating UAs. The optional PDAU allows EDIMG users to send messages to indirect
users outside of the EDI messaging environment. The message stores used in the EDI messaging service have specific
EDI related functions and can optionally be used by EDIMG users to take delivery of messages on their behalf. The
telematic agent (TLMA) shown in figure 4 will allow access to telematic services and may be the subject of future
standardization.
7.4 Structure of EDI messages
The EDI class of UAs create messages containing a content specific to the EDI messaging service. The specific
content that is sent from one EDI-UA to another is a result of an originator, which is generally an application process,
composing and sending a message, called an EDI message (EDIM). The EDIM carries the EDI interchange and
optionally other information associated with the EDI interchange. Only one EDI interchange shall be present in an
EDIM. Every EDIM shall contain an EDI interchange body part on origination of the EDIM. Any of the body parts
can subsequently be removed (wholly, not partially) when forwarding an EDIM, except a forwarded body part, which
cannot be removed. Body parts that are removed when forwarding are replaced with place holders to indicate what
© ISO/IEC 1999 – All rights reserved 7

ISO/IEC 10021-8 : 1999 (E)
type of body part was removed. The heading of an EDIM shall not be removed when forwarding an EDIM. The
structure of an EDIM as it relates to the basic message structure of MHS is shown in figure 5. The EDIM is conveyed
with an envelope when being transferred through the MTS.
EDIMG
user
EDI-UA
EDI messaging
service
EDIMG EDIMG
MT service EDI-MS EDI-UA
EDI-UA EDI-MS
user user
TLMA
PDAU
EDI-UA
Physical
delivery
services
Recipient
T0101290-93
Figure 4 – EDI messaging service functional model
Basic message
structure
Envelope Envelope
Heading
E
D
I
Body
I
n
t
Body part
e
r
c
h
a
Content
n
g
e
Body part
T0101300-93
Figure 5 – EDI message structure
8 © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
EDIFACT
interchange
Field 1
UNA
Field 2
UNB
Field 3
UNH Heading
User
data
segments
Field n
UNT
UNZ Primary body part
Body
Body part n
Additional
Information
(e.g. drawings)
T0101310-93
Figure 6 – EDI message structure for a typical EDI transaction
Figure 6 shows a mapping between a typical EDI interchange, and the corresponding EDI message structure. The EDI
interchange is mapped entirely within one body part, called the primary body part, and may be an EDIFACT, ANSI
X12, UNTDI or privately defined EDI interchange. Other body parts are available to convey information associated
with the EDI interchange such as drawings, explanatory text, etc. The heading of the EDIM contains various fields of
information, some of which are present in the EDIFACT interchange header segments (or corresponding ISA or STX
segments for ANSI X12 and UNTDI), and others containing service requests from the originator. The heading and
body part(s) form the EDIM.
7.5 EDI notification
An EDIMG user can request that a recipient return an EDI notification (EDIN) indicating the disposition of the EDI
message received. This notification is requested by an originating EDI-UA, and is generated by a recipient EDI-UA,
EDI-MS, or AU. There are 3 possible conditions that can be requested and reported on, resulting in either the
generation of a positive notification (PN), a negative notification (NN), or a forwarded notification (FN). The implied
meanings of the responses PN, NN, and FN are described in subclause 8.1. It is possible to forward a received EDI
message unchanged and forward the obligation to respond to the notification request to the recipient to whom the EDI
message is forwarded, or intermediate recipients, who then shall respond to the original originator of the message. An
originating EDI-UA may request to be notified if the obligation to respond to the notification request has been
forwarded. In this case, the EDI-UA or EDI-MS that forwards the EDIM shall send to the originating EDI-UA an EDI
forwarded notification (FN).
In all cases, including notifications sent by EDI-UAs to whom the EDIM has been forwarded, the notifications shall
contain the OR-name of the recipient that was specified by the original originator.
The originating EDI-UA may request any combination of the several EDINs from any combination of the recipients to
whom the EDIM is sent. If no notifications are requested by an originator, none shall be sent by the recipient(s).
EDI notifications cannot be forwarded, and EDI notifications cannot be requested for EDINs.
© ISO/IEC 1999 – All rights reserved 9

ISO/IEC 10021-8 : 1999 (E)
8 EDIM responsibility and forwarding
8.1 Introduction
The EDIMS includes a concept called EDIM responsibility. This concept is key to the description below of EDINs and
forwarding. In order to simplify the descriptions in the text below, all forwarding is shown as performed by the EDI-
UA. It should be noted that the descriptions apply equally to forwarding performed by the EDI-MS.
The purpose for introducing the concept of EDIM responsibility is primarily to provide a method for confirming the
passing of messages amongst EDI-UAs. EDIM responsibility may apply to access units in certain cases. The concept
of EDIM responsibility is described as follows.
EDIM responsibility indicates that the EDIM is made available to the EDIMG user by the receiving EDI-UA. EDIM
responsibility shall always be accepted when the EDI-UA adds or removes body parts when forwarding. An EDIM
cannot leave the EDIMS unless EDIM responsibility has been accepted (delivery to a PDAU is a special case as
described in subclause 11.3). If requested to do so by the originating EDI-UA, the recipient EDI-UA, and possibly
intermediate EDI-UAs (if requested), shall send EDINs to the originating EDI-UA.
When an EDI-UA receives an EDIM it shall, if requested to do so, inform the originating EDI-UA that the recipient
EDI-UA has accepted or refused EDIM responsibility by sending an appropriate EDIN. Paragraph 8.2 below contains
a detailed description of the EDINs that are sent in various scenarios.
If notifications are requested, then when an EDI-UA accepts, refuses, or forwards EDIM responsibility, it shall send an
appropriate EDIN to the originator, and if forwarding, it shall create the appropriate heading fields in the forwarded
EDIM. The details of these operations are described in ISO/IEC 10021-9 | ITU-T Recommendation X.435.
Body parts that are forwarded cannot be changed in any way. If EDIM responsibility is forwarded, the forwarded
EDIM cannot be changed in any way. If EDIM responsibility is accepted, body parts may be removed from, or added
to the original EDIM when creating the forwarded EDIM. Body parts that are removed when forwarding are replaced
with place holders to indicate what type of body part was removed. EDIM responsibility forwarding is limited to only
one recipient.
EDIMG includes mechanisms to prevent looping when forwarding.
8.2 Forwarding and secondary distribution
In EDIMG it may be desirable to receive EDI messages at a central EDI user agent, with subsequent forwarding to the
final EDI user agents. Such a practice would, for example, enable a large organization to perform centralized functions
such as logging, auditing, etc., on all EDI message traffic entering that organization. After performance of these
functions the traffic would be distributed to the EDI user agents serving the recipient EDI applications. Similarly, a
value added network service provider might operate a similar intermediary stage on behalf of its customers. The
following text describes the use of an EDI-UA as such an intermediary stage.
Since an intermediate EDI-UA will generally not be the final EDI-UA, there is a need to provide end-to-end
confirmation of EDIM responsibility acceptance for an EDIM within EDIMG. The element of service "EDI
notification request" allows an originator to request from each recipient, positive, negative and forwarded notifications.
Together with protocol elements defined in ISO/IEC 10021-9 ITU-T Recommendation X.435, the "EDI notification
request" allows intermediate EDI-UAs to indicate, in a forwarded message, whether or not EDIM responsibility has
been accepted. These tools allow EDIM responsibility acceptance to be deferred until an EDIM reaches the final EDI-
UA, and provide an indication to that EDI-UA that a notification is to be returned to the original originator.
In order to illustrate the use of an EDI-UA as an intermediate stage, three cases are described below. In all cases, an
EDIM originates in EDI-UA1 and terminates in EDI-UA3. EDI-UA2 is the intermediate EDI-UA. In cases 1 and 2 it is
assumed that the EDIM is forwarded with content unchanged. In all three cases it is assumed that EDI-UA1 has
requested notifications.
NOTE – Events described in the following tables are not necessarily performed in the exact sequential order shown in the
tables.
8.3 Case 1: No forwarding
The EDIM prepared byEDI-UA1 is addressedtoEDI-UA3.The EDIM is submittedtoMTA1, transferredtoMTA3,
delivered to EDI-UA3 and retrieved by EDIMG user 3. EDI-UA3 will respond with an appropriate EDIN, accepting
10 © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
EDIM responsibility (i.e., PN). (If EDI-UA3 had determined that EDIMG user 3 could not retrieve the message, EDI-
UA3 would have responded with an EDIN refusing EDIM responsibility (i.e., NN)). Figure 7 illustrates the flow of
information. The sequence of EDIMs and EDINs is depicted in table 1.
EDIMG
user 2
EDI-UA2
MTA2
1 3
EDIMG 2 EDIMG
EDI-UA3
EDI-UA1 MTA1 MTA3
user 1 user 3
6 4
Message transfer system
(MTS)
EDI messaging system
(EDIMS)
EDI messaging environment
(EDIME)
T0101320-93
Direction of transfer EDIN
Direction of transfer EDIM
Figure 7 – Case 1: No forwarding
Table 1 – Case 1: No forwarding
Events EDIM EDIN
1 EDI-UA1 submits EDIM to MTA1
2 MTA1 transfers EDIM to MTA3
3 MTA3 delivers EDIM to EDI-UA3
4 EDI-UA3 submits PN/NN to MTA3
5 MTA3 transfers PN/NN to MTA1
6 MTA1 delivers PN/NN to EDI-UA1
8.4 Case 2: Content not changed and EDIM responsibility forwarded
In this case an intermediary EDI-UA forwards a message from EDI-UA1 to EDI-UA3. The final recipient is EDI-
UA3, and EDI-UA2 performs a forward operation, forwarding EDIM responsibility to EDI-UA3. The EDIM prepared
by EDI-UA1 is addressed to EDI-UA2. The EDIM is delivered to EDI-UA2, which forwards it unchanged to EDI-
UA3, based on selection criteria known to EDI-UA2.
EDIM responsibility is handled as follows:
When EDI-UA2 forwards EDIM responsibility, it shall create the forwarded EDIM so that requested
EDINs are received by EDI-UA1, (see ISO/IEC 10021-9 | ITU-T Recommendation X.435 for details).
The following EDINs may be sent.
© ISO/IEC 1999 – All rights reserved 11

ISO/IEC 10021-8 : 1999 (E)
a) If EDI-UA1 requested notification of forwarding of EDIM responsibility, EDI-UA2 shall send
forwarded notification - FN to EDI-UA1. This EDIN is sent when EDI-UA2 successfully submits
the EDIM to MTA2.
b) If EDI-UA2 receives a non-delivery notification from MTA3 (via MTA2) it may send negative
notification - NN to EDI-UA1.
NOTE – EDI-UA2 has the choice to send or not to send the EDIN in this case.
No other EDINs may be requested or sent. For example, EDI-UA2 cannot request notifications
from EDI-UA3, and EDI-UA3 cannot send EDINs to EDI-UA2.
In the case of non-delivery, EDI-UA2 may attempt to resubmit the EDIM to the intended recipient.
In this case, the NN to EDI-UA1 is sent only when EDI-UA2 determines that it shall no longer
attempt to resubmit the EDIM to EDI-UA3.
c) If forwarding succeeds, EDI-UA3 shall send an appropriate EDIN to EDI-UA1, accepting or
refusing EDIM responsibility.
Figure 8 illustrates the information flow described above for case 2. The sequence of possible EDIMs and EDINs is
explained in table 2. Events (8, 11, 13, 15 ) and (10, 12, 14, 16 ) are mutually exclusive.
EDIMG
user 2
EDI-UA2
MTA2
6, 13
EDIMG EDIMG
EDI-UA1 EDI-UA3
MTA1 MTA3
user 1 user 3
9, 15, 16
Message transfer system
(MTS)
EDI messaging system
(EDIMS)
EDI messaging environment
(EDIME)
T0101330-93
Direction of transfer EDIN, NDN
Direction of transfer EDIM
Figure 8 – Case 2: EDIM responsibility forwarded
12 © ISO/IEC 1999 – All rights reserved

ISO/IEC 10021-8 : 1999 (E)
Table 2 – Case 2: EDIM responsibility forwarded
Events EDIM EDIN NDN
1 EDI-UA1 submits EDIM to MTA1
2 MTA1 transfers EDIM to
...