ISO/IEC 10021-9:1995
(Main)Information technology — Message Handling Systems (MHS) — Part 9: Electronic Data Interchange Messaging System
Information technology — Message Handling Systems (MHS) — Part 9: Electronic Data Interchange Messaging System
Technologies de l'information — Systèmes de messagerie (MHS) — Partie 9: Système de messagerie avec échange de données informatisé
General Information
Relations
Standards Content (Sample)
ISOlIEC 10021-9 : 1995 (E) OISO/IEC
acknowledgement-request [9] AcknowfedgementRequestFiePd DEFAULT FALSE,
communications-agreement-id IlO] CommunicationsAgreementIdFiePd OPTIONAL,
test-indicator [ll] TestIndicatorFiePd DEFAULT FALSE,
--
End Fields from EDIFACT UNB
--
Begin Fields from ANSIXl2 ISA
authorization-information AuthorizationInformationFiePd OPTIONAL,
WI
--
End Fields from ANSIX ISA
recipient-extensions [133 RecipientExtensionsFfePd OPTIONAL }
The Recipients subfield has the following components:
Recipient
8.2.3.1
A Recipient identifies the preferred recipient in question. It comprises an OR-name.
RecipientField ::= ORName
NOTE - OR-name is defined in 8.5.5 of ISO/IEC 10021-4 I CCITT Recommendation X.411 and ORName is defined in
figure 2 of ISO/IEC 10021-4 I CCI’IT Recommendation X.41 1.
8.2.3.2 Action request
An Action Request indicates what action the originator requests from the recipient. Its value is an object identifier.
ActionRequestField ::= OBJECT IDENTIFIER
The following standard values have object identifiers defined in this part of ISO/IEC 10021:
-
For Action,
- Copy.
The absence of this field shall be interpreted as having the default value set to For Action.
NOTE - Additional values for this field can be defined by any interested parties.
8.2.3.3 ED1 notification requests
The ED1 Notification Requests component (Default: no notifications, no notification security and no reception
security) may make certain requests of the preferred recipient denoted by the Recipient field.
NOTE 1 - The fact that a message can be redirected or forwarded is reflected in the word “preferred” above.
EDINotificationRequestsField ::= SEQUENCE {
[0] EDINotificationRequests DEFAULT {},
edi-notification-requests
[l] EDINotificationSecurity DEFAULT {},
edi-notification-security
edi-reception-security [2] EDIReceptionSecurity DEFAULT {) }
EDINotificationRequests ::= BIT STRING {
m(O) I
nn(l),
fn(2) } (SIZE (O.ub-bit-options))
EDINotificationSecurity ::= BIT STRING (
proof (0) I
non-repudiation (1) } (SIZE (O.,ub-bit-options))
EDIReceptionSecurity ::= BIT STRING {
proof (0) B
non-repudiation (1) ) (SIZE (O.ub-bit-options))
NOTE 2 - Only the following combinations of ED1 Notification Security and ED1 Reception Security bits have a defined
behaviour:
and ED1 Reception Security (proof(O));
ED1 Notification Security {proof(O))
ED1 Notification Security (non-repudiation( 1)) and ED1 Reception Security (non-repudiation( 1));
and EDI Reception Security ( };
ED1 Notification Security (proof(O)]
and ED1 Reception Security ( };
ED1 Notification Security (non-repudiation( 1))
and ED1 Reception Security ( ).
ED1 Notification Security { }
The ED1 Notification Requests field consists of a sequence of three optional bit strings of which the first selects the
type of notification, the second selects what security function should be applied to that notification, and the third may
12
---------------------- Page: 1 ----------------------
OISO/IEC ISO/lEC 10021-9 : 1995 (E)
make certain security requests for proof or non-repudiation of reception of this EDIM by the recipient.
EDI Notification Security and EDI Reception Security shall not be requested if EDI Notifications are not requested.
The ED1 Notification Requests bit string may assume any of the following values simultaneously.
a) PN: A notification of acceptance of Responsibility is requested in the circumstances prescribed in
clause 9.
NN: A notification of refusal of Responsibility for a message is requested
in the circumstances
b)
prescribed in clause 9.
c) FN: A forwarded notification is requested in the circumstances prescribed in clause 9.
The absence of the EDI Notification Requests bit string implies that no ED1 Notification requests are made.
The ED1 Notification Security bit string may assume any of the following values simultaneously. Each of these
values places requirements as indicated below on an EDI-UA submitting a subsequent EDIN in response to the
ED1 Notification Requests.
d) Pro& When submitting the EDIN to the MTS, content-integrity-check shall be requested in the
Message-submission-argument as defmed in 8.2.1.1.1.28 in ISO/IEC 10021-4 I CCITT
Recommendation X.4 11.
e) Non-repudiation: When submitting the EDIN to the MTS, content-integrity-check shall be requested in
the Message-submission-argument as defmed in 8.2.1.1.1.28 in ISO/IEC 10021-4 I CCITT
Recommendation X.4 11 with a non-repudiable certificate.
The absence of the ED1 Notification Security bit string implies that no ED1 Notification Security requests are made.
The ED1 Reception Security bit string may assume any of the following values simultaneously. Each of these values
places requirements as indicated below on an EDI-UA submitting a subsequent EDIN in response to the
ED1 Notification Requests.
f) Proofi When submitting the EDIN to the MTS, content-integrity-check (possibly in the message token),
or the message-origin-authentication-check (depending on the security policy in force) shall be
requested. A notification shall contain the security elements and shall be signed on submission to the
MTS, using content-integrity-check (possibly in the message token) or message-origin-authentication-
check (depending on the security policy in force) in the Message-submission-argument as defined in
8.2.1.1.1.26,8.2.1.1.1.28 and 8.2.1.1.1.29 of ISO/IEC 10021-4 I CCITT Recommendation X.41 1.
g) Non-repudiation: When submitting the EDIN to the MTS, a non-repudiable content-integrity-check
(possibly in the message token) or a message-origin-authentication-check (depending on the security
policy in force) shall be requested. A notification shall contain the security elements and shall be
signed on submission to the MTS, using non-repudiable content-integrity-check (possibly in the
message token) or message-origin-authentication-check (depending on the security policy in force) in
the Message-submission-argument as defined in 8.2.1.1.1.26, 8.2.1.1.1.28 and 8.2.1.1.1.29 of ISO/IEC
10021-4 I CCITT Recommendation X.4 11.
The absence of the ED1 Reception Security field implies that no ED1 Reception Security requests are made.
NOTE 3 - Security services are available only if the MTS supports secure messaging.
8.2.3.4 Responsibility passing allowed
The Responsibility Passing Allowed Field indicates that forwarding Responsibility is allowed if this field is set to
TRUE. Absence of the field shall be interpreted as the value FALSE.
A recipient of a message with the Responsibility Passing Allowed Field set to FALSE shall originate EDIN’s as
requested, and shah not forward Responsibility.
ResponsibilityPassingAllowedField : := BOOLEAN -- DefauPt FALSE
If allowed, Responsibility may be forwarded to at most one recipient.
13
---------------------- Page: 2 ----------------------
ISODEC 10021-9 : 1995 (E) 01s0/IEc
8.2.3.5 Interchange recipient
The Interchange Recipient identifies the EDI Interchange recipient.
This is semantically identical to the
“Interchange recipient” of the EDIFACT UNB segment.
InterchangeRecipientField ::= SEQUENCE {
recipient-identification [O] Identificationcode,
[l] IdentificationCodeQualifier OPTIONAL,
identification-code-qualifier
routing-address [2] RoutingAddress OPTIONAL }
NOTE - The above fields are defined in 8.1.1.
8.2.3.6 Recipient reference
The Recipient Reference identifies a reference meaningful to the recipient’s EDI application. This is semantically
identical to the “Recipient’s Reference, Password” of the EDIFACT UNB segment. It consists of two strings.
RecipientReferenceField ::= SEQUENCE (
recipient-reference [O] RecipientReference,
11.3 RecipientReferenceQualifier OPTIONAL )
recipient-reference-qualifier
RecipientReference ::= TeletexString (SIZE (1. ub-recipient-reference))
: :=
Recipi entRe ferenceQua1 i fier
reference-
Tele texstring ( S IZE (l.ub-recip ient- qualifier))
Interchange control reference
8.2.3.7
Indicates the Interchange Control Reference as assigned by the Interchange sender. This is semantically identical to
the “Interchange control reference” of the EDIFACT UNB segment.
Inte rchangecontr o1ReferenceFi eld ::=
TeletexSt ring (SIZE (1 .ub-interchang
Processing priority code
8.2.3.8
Indicates the ED1 application Processing Priority Code. This is semantically identical to the “Processing priority code”
in the EDIFACT UNB segment. It consists of a string.
ProcessingPriorityCodeField ::=
TeletexString (SIZE (1. ub-processing-priority-code))
Acknowledgement request
8.2.3.9
The Achowledgement Request indicates the request for EDI acknowledgement as indicated by the interchange
sender. This is semantically identical to the “Acknowledgement request” in the EDIFACT UNB segment. Its value is a
Boolean, where the value TRUE indicates a request for acknowledgement. Absence of this field shall be interpreted as
the vaIue FALSE.
AcknowledgementRequestField ::= BOOLEAN -- default FALSE
8.2.3.10 Communications agreement id
The Communications Agreement Id indicates the type of communications agreement controlling the interchange, e.g.
Customs or other agreement. This is semantically identical to the “Communications agreement id” in the EDIFACT
UNB segment.
,icat ionsAg r eernent1 dField : :=
C ommun
Tel etexSt ZE (1. ub-comxnunications-agreement-
r ing (SI id> >
8.2.3.11 Test indicator
Indicates that the ED1 Interchange is a test. This is semantically identical to the “test indicator” in the EDIFACT UNB
segment. It is a Boolean where the value TRUE indicates that the EDI Interchange is a test. Absence of this field shall
be interpreted as the value FALSE.
-- default FALSE
TestIndicatorField ::= BOOLEAIJ
---------------------- Page: 3 ----------------------
OISO/IEC ISO/IEC 10021-9~1995 (E)
8.2.3.12 Authorization information
The Authorization Information indicates who authorized the interchange. This is semantically identical to the
“Authorization information” in the ANSIX 12 Interchange.
AuthorizationInfonmationField ::= SEQUENCE {
authorization-information [O] AuthorizationInformation,
authorization-information-qualifier [l] AuthorizatfonInformatfonQualifier OPTIONAL
AuthorizationInformation ::= TeletexString (SIZE (l.ub-authorization-information))
AuthorizationInformationQualifier ::=
TeletexStrfng (SIZE (l.ub-authorization-information-qualifier))
NOTE - In the above text reference is made to ANSIX segments and data elements. Annex K explains this in relation to
UFJTDI and EDIFACT (IS0 9735), being the other two widely used syntaxes.
Recipient extensions
8.2.3.13
The Recipient Extensions contains extensions to the Recipients subfield.
RecipientExtensionsField ::= SET OF RecipientExtensionsSubField
RecipientExtensionsSubField ::= ExtensionField
There are no extensions defined in this part of ISO/IEC 10021.
8.2.4 EDIN receiver
Identifies the recipient to whom EDINs are to be sent. This is created by the originator of the EDIM when the
Recipient of a requested notification is different from the Originator of the message. It consists of a sequence of OR-
name, EDIM Identifier and First Recipient.
This field shall not be present if ED1 Notification Requests are not made.
This field shall be present in a forwarded message when the forwarding ED1 user agent (EDI-UA) or ED1
message store (EDI-MS) forwards Responsibility. This field may be present when the forwarding EDI-UA accepts
Responsibility. Rules related to the construction of this field are given in 17.3.3.4.
NOTE 1 - For brevity, the term user agent (UA) is used throughout the rest of this part of ISO/IEC 10021 with the meaning of
EDI-UA, and the term message store (MS) is used throughout the rest of this part of ISO/IEC 10021 with the meaning of EDI-
MS.
EDINReceiverField ::= SEQUENCE {
edin-receiver-name [0] ORName,
original-edim-identifier [I] EDIMIdentifier OPTIONAL,
first-recipient [2] FirstRecipientField OPTIONAL }
The “first-recipient” field shall not be present if more than one Recipents Subfield contains ED1 Notification Requests.
The “original-edim-identifier” and the “first-recipient” fields shall not be present when the Primary Body Part is an
ED1 Body Part (that is, when the original originator first creates the EDIT).
NOTE 2 - %he Original EDIM Identifier and First Recipient fields are included in order to allow the recipient to construct the
EDIN for a forwarded EDIM. See subclauses 9.1 (more specifically 9.1.3) and 17.3.1.1 for rules related to the construction
of an EDIN; see 17.3.3.4 for rules related to the First Recipient field when constructing a forwarded EDIM. OR-name is
defined in 8.5.5 of ISO/IEC 10021-4 I CCITI’ Recommendation X.411 and ORIVame is defined in figure 2 of ISO/IEC 10021-
4 I CCIlT Recommendation X.41 1. First Recipient Field is defined in 9.1.3.
Responsibility forwarded
8.2.5
The Responsibility Forwarded field is used to indicate whether Responsibility was forwarded. Absence of this field
shall be interpreted as the value FALSE.
ResponsibilityForwarded ::= BOOLEAN -- Default FALSE
15
---------------------- Page: 4 ----------------------
ISO/IEC 10021-9 : 1995 (E)
OISO/IEC
If this field has the value TRUE it indicates to a receiving UA that Responsibility was forwarded.
If this field has the
value FALSE (or is absent) it indicates to a receiving UA that the security elements of the inner envelope have been
checked.
Subject to the security policy in force, the security elements may have been checked when the message forwarded.
However, when Responsibility is accepted, the security elements shall be checked.
NOTE - Rules regarding the use of this field are contained in 17.3.3.1 and 17.3.3.2.
8.2.6 ED1 body part type
Indicates the ED1 standard and ED1 character sets used in the Primary Body Part. It is represented by a single object
identifier.
EDIBodyPartType ::= OBJECT IDENTIFIER -- default EDIFACFISO646
The following standard values have object identifiers defined in annex A of this part of ISO/IEC 10021:
-
EDIFACT: IS0646lCCITT Recommendation T61lIS08859lUNDEFINED OCTETS
-
ANSIX12: IS0646lCCITT Recommendation T61IEBCDICIUNDEFINED OCTETS
-
UNTDI: ISO646lCCI’IT Recommendation T61 IUNDEFINED OCTETS
-
PRIVATE: UNDEFINED OCTETS
-
UNDEFINED: UNDEFINED OCTETS
The absence of this field shall be interpreted as having the default value set to EDIFACT, ISO/IEC 646.
NOTES
l- The character set referred to by the object identifier is that in which both the ED1 Body Part, and those Heading fields
that are OCTET STRINGS and are derived from the ED1 Interchange are encoded, notwithstanding the fact that these types
are defined as OCTET STRING.
2 - The PRIVATE and UNDEFINED object identifiers are provided as an interim measure and rely on the existence of
bilateral agreements. The PRIVATE object identifier should be used in preference to the UNDEFINED, as it conveys a
semantic of being understood according to private arrangements between the communicating parties, i.e., the originator and
the intended recipient.
3- Instead of using one of the object identifiers listed above, a privately defined object identifier may be used indicatng a
provatly defined ED1 syntax and character set. Such an object identifier should be acquired from a local registration authority
and used in accordance with the practices and policies of that registation authority.
The object identifier root is defined in annex A of this part of ISO/IEC 10021 for EDIFACT body types whose character
repertoire is encoded as defined in ISO/IEC 8859. ISO/IEC 8859 is composed of several parts, where each part specifies a
specific character repertoire. The specific part number shall form the leaf value of the object identifier used in the EDIMG
protocol.
This is the same technique used for indicating character repertoires used in IPM’s General Text bodypart. For example, an
EDIFACT message encoded per ISO/IEC 8859-6 would be represented with the object identifier:
(-Joint-iso-ccitt mhs-motis(6) edims(7)
id-bp(11) id-bp-edifact-8859(U) iso-8859-6(6)},or
alternatively, 1 2 6 7 11 12 6 1.
The value of the ED1 Body Part Type field shall be used in the Encoded Information Types in the MTS abstract
operations (in accordance with 19.4). This enables a UA to signal to the MTS what type of EDI standard the EDIM’s
Primary Body Part complies with. The MTS makes use of this information, if the recipient UA has registered delivery
restrictions on Encoded Information Types, to decide if it can deliver the EDIM.
NOTE 4 - The term Encoded Information Type is defined in 8.1 of ISO/IEC 10021-2 I CCITI’ Recommendation X.402. See
also 8.2.1 .l .1.23 of ISO/IEC 10021-4 I CCITT Recommendation X.41 1 n
16
---------------------- Page: 5 ----------------------
@ISO/IEC ISO/IEC 10021-9 : 1995 (E)
8.2.7 Incomplete copy
‘Ihe Incomplete Copy field indicates that the forwarded EDIM is an incomplete copy of an EDIM. Its value is a
Boolean. This field shall have the value TRUE if body parts are removed when an EDIM is forwarded. The absence
of this field shall be interpreted as having the value FALSE.
IncompleteCopyField ::= BOOLEAN - - Default FALSE
NOTE - The term “forwarded EDIM” is defined in 17.3.3.
Expiry time
8.2.8
Indicates when the originator considers this EDIM loses its validity. It comprises a date and time (UTC).
ExpiryTimeField ::= UTCTime
8.2.9 Related messages
Identifies messages, EDIMs or other (for example IPMs), that the originator of this EDIM considers related to it. It
comprises a sequence of one or more message references, one for each related message.
RelatedMessagesField ::= SEQUENCE OF RelatedMessageReference
RelatedMessageReference ::= CHOICE {
edi-message-reference [0] EDIMIdentifier,
external-message-reference [l] ExternalMessageReference }
ExternalMessageReference ::= EXTERNAL
NOTES
l- If the related message identifies messages from other services the user component of the message identifier (EDIM
Identifier) must be present.
2- Message identifier values of the referenced message of other service types than EDIMG are carried in the
EDIM Identifier field.
8.2.10 Obsoleted EDIMs
The Obsoleted EDIMs Field identifies one or more EDIMs that the present EDIM obsoletes. It is a sequence of
subfields, each an EDIM Identifier.
ObsoletedEDIMsField ::= SEQUENCE OF ObsoletedEDIMsSubfield
ObsoletedEDIMsSubfield ::= EDIMIdentifier
8.2.11 ED1 application security elements
The ED1 Application Security Elements field allows an EDI application to exchange security elements having an
end-to-end significance.
EDIApp1icatfonSecurftyElernentsField ::= SEQUENCE {
edi-appUcation-security-element [O] EDIApplicationSecurftyElement OPTIONAL,
[l] BOOLEAN OPTIONAL,
edi-encrypted-primary-bodypart
edi-application-security-extensions [2] EDIApplicatfonSecurityExtensions OPTIONAL 1
* .=
tyE1ernent
EDIApplfcaQfonSecurf
ion- security-e1 event
BIT STRING (SIZE (0. .*ib-edi-applicat s))
: : = SET OF EDIApplicationSecurityExtension
EDIApplicationSecurityExtensions
. .=
ExtensionField
. .
EDIApplicationSecurityExtension
8.2.12 Cross referencing information
The Cross Referencing Information allows an ED1 application to reference individual body parts within the same
EDIM and within other EDIMs. It contains a set of cross reference data. Its usage is outside the scope of this part of
ISO/IEC 10021.
: g’
SET OF CrossReferencingInforrnationSubField
CrossReferencingInformationField
17
---------------------- Page: 6 ----------------------
ISO/IEC 10021-9 : 1995 (E)
oIso/IEc
CrossReferencingInformationSubField ::= SEQUENCE {
application-cross-reference [O] ApplicationCrossReference,
message-reference 8:1] MessageReference OPTIONAL,
body-part-reference [2] BodyPartReference )
* .=
ApplicationCrossReference b . OCTET STRING
: := EDIMIdentifier
MessageReference
If the Message Reference is absent, the message referred to is the current one.
NOTES
l- Body Part Reference is defined in 8.3.3.
2- The character set used in the Application Cross Reference field is indicated by the value of the field EDI
Body Part Type.
ED1 message type
8.2.13
Indicates the Message type(s) present in the ED1 Interchange. It consists of a set of distinct strings.
“Message” is to be understood as message types that are defined in ED1 standards and shall not be confused with
NOTE -
“message” used elsewhere in this part of ISO/IEC 10021.
EDIMessageTypeField ::= SET OF EDIMessageTypeFieldSubField
EDIMessageTypeFieldSubField ::= TeletexString (SIZE (l.ub-edi-message-type))
The values for this field shall be:
-
EDIFACT: Message Type from the UNH segment;
-
ANSIX12: Transaction Set ID from the ST segment;
-
UNTDI: Message Type from the MHD segment.
8.2.14 Service string advice
Indicates the Service String Advice of the ED1 Interchange. This is semantically identical to the “UNA,
Service string advice” of the EDIFACT Interchange.
ServiceStringAdviceField ::= SEQUENCE {
component-data-element-separator [0] ComponentDataElernentSeparator,
data-element-separator [1] DataElementSeparator,
decimal-notation [2] DecimalNotation,
release-indicator [3] ReleaseIndicator OPTIONAL,
reserved [4] Reserved OPTIONAL,
segment-terminator [S] SegmentTerminator }
ComponentDataElementSeparator : := OCTET STRING (SIZE (1))
: :=
DataElementSeparator OCTET STRING (SIZE (1))
: :=
DecimalNotation OCTET STRING (SIZE (1))
: :=
ReleaseIndicator OCTET STRING (SIZE (1))
Reserved : := OCTET STRING (SIZE (1))
SegmentTerminator ::= OCTET STRING (SIZE (1))
8.2.15 Syntax identifier
Indicates the syntax used. This is semantically identical to the “Syntax identifier” of the EDIFACT UNB segment.
It consists of a sequence of the Syntax Identifier and the Syntax Version.
SyntaxIdentifierField ::= SEQUENCE {
syntax-identifier SyntaxIdentifier,
syntax-version
SyntaxVersion )
SyntaxIdentifier ::= TeletexString (SIZE (1 .ub-syntax-identifier))
18
---------------------- Page: 7 ----------------------
OISO/IEC ISO/IEC 10021-9 : 1995 (E)
SyntaxVersion ::= PrintableString (SIZE (l,.ub-syntax-version))
8.2.16 Interchange sender
Indicates the sender of the ED1 Interchange. This is semantically identical to the “Interchange sender” of the
EDIFACT UN3 segment.
InterchangeSenderField ::= SEQUENCE (
sender-identification
[0] IdentificationCode,
identification-code-qualifier
[l] IdentificatfonCodeQualifier OPTIONAL,
address-for-reverse-routing [2] RoutingAddress OPTIONAL ) -- EDIFACT Routing
Information
The above fields are defined in 8.1.1.
NOTE -
8.2.17 Date and time of preparation
Indicates the Date/Time of preparation of the ED1 Interchange. This is in UTC Time and is derived from the “Date and
time of preparation” of the EDIFACT UNB segment. It comprises a UTC Time.
DateAndTimeOfPreparationField ::= UTCTime
8.2.18 Application reference
Provides a general reference to an application or function. This is semantically identical to the “Application reference”
segment of the EDIFACT UNB segment. It consists of a string.
ApplicationReferenceField ::= TeletexString (SIZE (1 .ub-application-reference))
8.2.19 Heading extensions
The Heading Extensions allows for future extensions to the Heading.
HeadingExtensionsField ::= SET OF HeadingExtensionsSubField
HeadingExtensionsSubField ::= ExtensionField
There is no extensions to the Heading defined in this part of ISO/IEC 10021.
The Heading Extensions may be used to implement the element of service
NOTE - “Services Indication” defined in
ISO/IEC 10021-8 I CCI’IT Recommendation F.435.
Body part types
83 0
The types of body parts that may appear in the Body of an EDIM are defined and described below.
ED1 body part
8.3.1
An ED1 Body Part carries a single ED1 Interchange.
EDIBodyPart ::= OCTET STRING
The reference definition of ED1 Interchange used is that used by EDIFACT (IS0 9735). Annex K describes equivalent
terms in other ED1 standards.
8.3.2 EDIM body part
An EDIM Body Part contains an EDIM, and optionally, its delivery envelope. It is used for forwarding of EDIMs.
When an EDIM is forwarded, its structure shall comply with the rules given in 17.3.3.2.
EDIMBodyPart ::= SEQUENCE (
parameters [O] MessageParameters OPTIONAL,
data [1] MessageData )
MessageParameters ::= SET {
[0] MessageDeliveryTime OPTIONAL,
delivery-time
delivery-envelope [l] OtherMessageDelfveryFields OPTIONAL,
other-parameters 123 EDISupplementaryInforxnatfon OPTIONAL 1
-- MessageDeliveryTime and OtherMessageDeliveryFields shall both be present or both
19
---------------------- Page: 8 ----------------------
ISO/IEC 10021-9 : 1995 (E) OISO/IEC
EDISupplementaryInformation is used in the case of ms-auto-actions,
-- be absent.
--
see subclause 18.6.
MessageData ::= SEQUENCE {
heading Heading,
BodyOrRemoved }
body
BodyOrRexnoved ::= SEQUENCE (
primary-or-removed PrimaryOrRernoved,
additional-body-partsAdditionalBodyParts OPTIONAL }
PrimaryOrRemoved ::= CHOICE {
removed-edi-body
WI NULL,
[1] EXPLICIT PrimaryBodyPart }
primary-body-part
AdditionalBodyParts ::= SEQUENCE OF CHOICE {
external-body-part [0] EDIM-ExternallyDefinedBodyPart,
[1] BodyPartPlaceHolder } -- This type is for Body Part Removal
place-holder
BodyPartPlaceHolder ::= EDIM-ExternallyDefinedBodyPart -- Only the data
--
portion of the Externally Defined Body shall be removed.
--
See text in 8.3.2.
EDISupplementaryInfomation ::=
(1. ub-supplementary-info-length))
TeletexString (SIZE
Primary Body Part is defined in clause 8. Body Part Reference is defined in 8.3.3. The data types
NOTE -
and Other Message Delivery Fields are defined in 8.3.1.1 (and figure 2) of ISO/IEC 10021-4 I
Message Delivery Time
CCITT Recommendation X.41 1.
it indicates a “removed-EDI-body” . It
The Body Part Place Holder shall only be used for removal of body parts, i.e.,
In the latter case, the
may consist of only the Body Part Reference, or a modified Externally Defined Body Part.
Object Identifier and Body Part Reference of the removed body part are preserved; from the parameter (if present)
and data portions of the removed body part, only the Object Identifier and the identifier octets of the “encoding” field
That is, the EXTERNAL type shall have an encoding field of zero length and
of the EXTERNAL are preserved.
hence no content.
The delivery envelope shall be present if security services are invoked.
The structure of an EDIM Body Part is depicted in figure 2.
I
I
Heading
,1
or
Body
or 1 Place holder1
or Place holder
I I
T0708030-93
Figure 2 - EDIM body part structure
20
---------------------- Page: 9 ----------------------
OISO/IEC ISO/IEC 10021-9 : 1995 (E)
Externally defined body parts
8.3.3
Additional body parts, that relate to the Primary Body Part, may be carried together with an ED1 Body Part. These
body parts shall not be or include ED1 Interchanges.
Additional body parts are externally defined and represent information objects whose semantics and abstract syntax
are denoted by an object identifier which the body part carries.
They have Parameters and Data components and
optionally a Body Part Reference that may be used for cross-referencing to a body part.
EDIM-ExternallyDefinedBodyPart ::= SEQUENCE {
body-part-reference
[0] BodyPartReference OPTIONAL,
external-body-part [l] ExternallyDefinedBodyPart -- from IPMS --}
BodyPartReference::= INTEGER -- is unique within a EDIM
Body-part-reference is assigned when the body part is created, and is not modified subsequently. Its value shall be
unique within an EDIM. It shall be present if the originator wishes to cross-reference the body part at creation or in the
future.
Some Externally Defined body part types are defined in 7.3.12 of ISO/IEC 10021-7 I CCITT Recommendation
NOTE -
X.420.
ED1 notifications
9
An ED1 Notification (EDIN) is a member of a secondary class of Information Object conveyed between users in
ED1 Messaging.
NOTE - The term notification is used throughout the rest of this part of ISO/IEC 10021 as a synonym for ED1 Notification.
EDIN ::= CHOICE {
positive-notification [0] PositiveNotificationFields,
[l] NegativeNotificationFields,
negative-notification
forwarded-notification [2] ForwardedNotificationFields }
a) Positive notification: An EDIN that reports its originator’s acceptance of Responsibility of an EDIM.
An EDIN that reports its originator’s refusal to accept Responsibility of an
b) Negative notification:
EDIM.
c) Forwarded notification: An EDIN that reports that Responsibility of an EDIM has been forwarded
together with the subject EDIM.
The EDIM to which an EDIN refers is called the subject EDIM (see also 17.3.3).
The recipient of the EDIN is the Originator of the subject EDIM, or, if present, the OR-name indicated in the
EDIN Receiver field. There shall be at most one recipient specified for an EDIN. There shall be at most one PN, NN
or FN originated for each subject EDIM by each recipient of whom notifications are requested (except that an NN may
be originated by the same UA subsequent to an FN, in accordance with c) of 17.3.3.1). One FN is originated, if and
only if requested, by each recipient that forwards an EDIM. In accordance with the provisions of 17.3.3, the original
originator shall receive at most one PN or NN for each recipient of whom notifications were requested, regardless of
how many times the EDIM is forwarded, and may receive multiple FNs.
An EDIN consists of Positive, Negative or Forwarded Notification fields. Each of these contains the Common Fields
which are described below.
The structure of an EDIN is depicted in figure 3.
21
---------------------- Page: 10 ----------------------
ISO/IEC 10021-9 : 1995 (E) OISO/IEC
91 . Common fields
The Common Fields are defined and described below
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.