ISO/IEC 10021-9:1995

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
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.
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

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
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
@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
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))
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
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
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
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.
ISO/IEC 10021-9 : 1995 (E) OISO/IEC
91 . Common fields
The Common Fields are defined and described below.
CommonFields ::= SEQUENCE (
subject-edim [l] SubjectEDIMField,
edin-originator [2] EDINOriginatorField,
first-recipient [3] FirstRecipientField OPTIONAL,
notification-time [4] NotificationTimeField,
notification-security-elements [5] SecurityElementsField OPTIONAL,
edin-initiator [6] EDINInitiatorField,
notifications-extensions [7] NotificationExtensionsField OPTIONAL )
NOTE - The Common Fields appear in tlhe Positive Notification, Negative Notification and Forwarded Notification fields
defined below.
Common field n
.
.
’ .
. .
.
. .
.
. .
.
. .
.
.
(ifNN).,*OdR ,H~~“--.~
- - . (if PN)
#
.
. .
(if FN) ’
.
.
.
.
/
t
Forwarded field 1 Positive field 1
Negative field 1
Forwarded field 2 Positive field 2
Negative field 2
TO708040-93
Figure 3 - ED1 notification structure
9.1.1 Subject EDIM
The Subject EDIM Identifier is the EDIM Identifier either passed in the EDIN Receiver field, if Responsibility has
been forwarded, or the This EDIM field, if not.
: :=
SubjectEDIMField EDIMIdentifier
EDIM Identifier is defined in 7.1. Subject EDIM is defined in clause 9.
NOTE -
9.1.2 ED1 notification originator
The ED1 Notification Originator contains the OR-name of the UA constructing the notification.
EDINOriginatorField ::= ORName
NOTE - OR-name is defined in 8.5.5 of ISO/IEC 10021-4 I CCITT Recommendation X.41 1, and ORName is defined in
figure 2 of ISO/IEC 10021-4 I CCITT Recommendation X.41 1.
ISO/IEC 10021-9 : 1995 (E)
OISO/IEC
First recipient
9.1.3
The First Recipient field contains the OR-name of the first recipient in a forwarding chain. This field, together with
other fields, is used by the recipient of the notification to correlate the notification and the original message.
FirstRecipientField ::= ORName
NOTE - OR-name is defined in 8.55 of ISO/IEC 10021-4 I CCITT Recommendation X.411, and ORName is defined in
figure 2 of ISO/IEC 10021-4 I CCITI’ Recommendation X.41 1.
If the originator of the EDIN is not the recipient specified by the original originator, then the First Recipient Field
shall be present in the EDIN (see 17.3 and more specifically 17.3.1.1).
9.1.4 Notification time
Notification Time contains the date and time, in UTC format, at which the notification for the subject EDIM was
generated.
NotificationTimeField ::= UTCTime
9.1.5 Security elements
The Security Elements field is used to provide “proof/non repudiation of content received”, “ED1 application security”
services.
SecurityElementsField ::= SEQUENCE {
original-content [0] Content OPTIONAL,
original-content-integrity-check [l] ContentIntegrityCheck OPTIONAL,
edi-application-security-elements [Z] EDIApplicationSecurityElementsField OPTIONAL,
security-extensions [33 SecurityExtensionsField OPTIONAL }
SET OF SecurityExtensionsSubField
SecurityExtensionsField ::=
SecurityExtensionsSubField ::= ExtensionField
NOTE - The ED1 Application Security Elements Field is defined in 8.2.11. Content and Content Integrity Check are defined
in, respectively, subclauses 8.2.1.1.1.37 and 8.2.1.1.1.28 (and figure 2) of ISO/IEC 10021-4 I CCITT
Recommendation X.41 1. Security services are available only if the MTS supports secure messaging.
Subclause 17.1.3 specifies how these fields are filled in.
EDIN initiator
9.1.6
The EDIN Initiator field can take one of the following values:
“internal-UA” means that the UA generated the EDIN either for local reasons or because the generation
a)
had been delegated to it by the user;
“internal-MS” means that the MS generated the EDIN either for local reasons or because the generation
b)
had been delegated to it by the user;
“external-UA” means that the generation of the EDIN was requested by the user via the abstract
C)
operation Originate EDIN (see 17.1.3).
EDINInitiatorField ::= ENUMERATED {
internal-ua (0),
external-ua (1) ,
internal-ms (2) }
Origination of a Positive Notification implies that Responsibility has been accepted, regardless of the value of this
field.
The value of this field shall be consistent with the choice (UA/MS, user, PDAU) of the Reason Code field for NNs and
FNs.
NOTE - Physical delivery access unit (PDAU) is defined in 15.4.
ISO/IEC 10021-9 : 1995 (E)
OISO/IEC
Notification extensions
9.1.7
The Notification Extensions allows for future extensions to the EDIN.
NotificationExtensionsField ::=
SET OF NotificationExtensionsSubField
NotificationExtensionsSubField ::= ExtensionField
There are no extensions to the EDIN defined in this part of ISO/IEC 10021.
Extensions shall not be critical in EDINs.
92 . Positive notifications
A Positive Notification (PN) is sent by the recipient UA, if and only if the originator has requested one, when
Responsibility for the EDIM has been accepted by the UA.
The exact procedures which constitute acceptance of Responsibility are a local matter; for example, the UA may
construct the PN as soon as it passes the message to the user, or the UA may wait for an external stimulus from the
user that the message has been accepted and therefore the requested PN can be sent.
Positive Notification Fields are defined and described below.
PositiveNotificationFields ::= SEQUENCE {
pn-common-fields [0] CommonFields,
pn-supplementary-information [l] EDISupplementaryInfomation OPTIONAL,
pn-extensions [2] PNExtensionsField OPTIONAL }
PN supplementary information
9.2.1
The PN Supplementary Information field may be used to return further information to the EDIN recipient to clarify the
Positive Notification.
ED1 Supplementary Information field is defined in 8.3.2.
NOTE -
9.2.2 Positive notification extensions
The Positive Notification Extensions allows for future extensions to the PN.
PNExtensionsField ::= SET OF PNExtensionsSubField
PNExtensionsSubField ::= ExtensionField
There are no extensions to the PN defined in this part of ISO/IEC 10021.
Extensions shall not be critical in PNs.
Negative notifications
93 .
A Negative Notification (NN) is sent by a UA, if and only if the originator has requested one, when it determines that
it can neither accept Responsibility, nor forward the EDIM and the ED1 Notification Request contained in the EDIM to
another UA.
Negative Notification Fields are defined and described below.
NegativeNotificationFields ::= SEQUENCE {
[0] CommonFields,
nn-common-fields
[1] NNReasonCodeField,
nn-reason-code
nn-supplementary-information [2] EDISupplementaryInfomation OPTIONAL,
nn-extensions [3] NNExtensionsField OPTIONAL }
9.3.1 Negative notification reason
The Negative Notification Reason indicates why the subject EDIM could not be passed to the user by the UA
originating the EDIN. Additional information may be carried in any combination of a diagnostic field or the
NN Supplementary Information field. Depending on the security policy in force, the security error diagnostic code
may or may not be present.
01s0/IEc ISO/IEC 10021=9:1995(E)
The value "unspecified(O)" is provided for usein any basic code field when other code values do not apply.
NOTE -
NNReasonCodeField ::= CHOICE {
nn-ua-Ins-reason-code [0] NNUAMSReasonCodeField,
nn-user-reason-code
[l] NNUserReasonCodeField,
nn-pdau-reason-code [2] NNPDAUReasonCodeField )
--
Negative Notification Reason Codes from an EDI-UA or EDI-MS
NNUAMSReasonCodeField ::= SEQUENCE {
nn-ua-ms-basic-code [0] NNUAMSBasicCodeField,
nn-ua-ms-diagnostic [l] NNUAMSDiagnosticField OPTIONAL }
--
Negative Notification Basic Reason Codes from an EDI-UA or EDI-MS. These codes are
--
those specified in annex B of ISO/IEC 10021-8 I CCITT Recommendation F.435
--
for the element of service "EDI Notification Request".
NNUAMSBasicCodeField ::= INTEGER {
unspecified (0),
cannot-deliver-to-user (l),
--
the EDI Interchange can not be passed on to the user
delivery-timeout (2),
--
the EDI Interchange could not be passed on to the user within
--
a specified time limit
message-discarded (3),
--
the UA/MS discarded the message before handoff to user
subscription-terminated (4),
--
recipient's subscription terminated after delivery but before
-- handoff to user
forwarding-error (5),
--
EDI Forwarding was attempted, but failed
security-error (6)
--
security error
--
physical delivery errors indicated by "cannot-deliver-to-user"
} (O.ub-reason-code)
--
Negative Notification Diagnostic Codes from an EDI-UA or EDI-MS
NNUAMSDiagnosticField ::= INTEGER {
--
This field may be used to further specify the error signalled in nn-ua-ms basic-
--
code. Additional information may be indicated in nn-supplementary-information
--
general diagnostic codes
--
protocol-violation (l), used if the UA detects a protocol error
edim-originator-unknown (2),
edim-recipient-unknown (3),
edim-recipient-ambiguous (4), -- used if the EDIM recipients or
--
originator are not vaiid
action-request-not-supported (5),
--
used when the action requested by the recipient is not performed
edim-expired (6)1
--
used when the expiry date of the received EDIM occurred before the subject EDIM
--
was successfully passed to the user or forwarded by the EDI-UA
edim-obsoleted (7),
--
used when the EDIM Identifier of the received EDIM was contained in the
--
Obsoleted EDIM field of a previously received EDIM
duplicate-edim (8),
--
used when the same EDIM is received more than once from the same originator.
unsupported-extension (9),
--
used if the EDIM contains an extension which is not supported by the UA.
incomplete-copy-rejected (lo), -- used if the EDI-UA does not accept
--
EDIMs with the Incomplete Copy Indication true.
edim-too-large-for-application (ll),
--
used if the EDIM cannot be delivered to the user due to length constraints,
--
forwarding error diagnostic codes
forwarded-edim-not-delivered (12),
--
used when an Non-Delivery Report is received for forwarded EDIM.
forwarded-edim-delivery-time-out (13),
--
used when no Delivery Report is received within a given period.
ISO/IEC 10021-9 : 1995 (E)
OISO/IEC
forwarding-loop-detected (149,
--
used if the UA receives an EDIM which contains a previously forwarded EDIM.
unable-to-accept-responsibility (15),
--
used if the EDI-UA cannot accept or forward responsibility.
-- INTERCHANGE HEADER DIAGNOSTIC CODES
interchange-sender-unknown (169, -- used when the UA does not
--
recognize the interchange-sender of the EDI interchange.
interchange-recipient-unknown (179, -- used when the UA cannot find
--
a valid interchange recipient in the Recipient Specifier.
invalid-heading-field (189,
invalid-bodypart-type (199,
invalid-message-type (209,
invalid-syntax-id (219,
-- SECURITY ERROR DIAGNOSTIC CODES
message-integrity-failure (22),
forwarded-message-integrity-failure (23)#
unsupported-algorithm (249,
decryption-failed (259,
token-error (269,
unable-to-sign-notification (279,
unable-to-sign-message-receipt (289,
authentication-failure (299,
security-context-failure (309,
message-sequence-failure (319,
message-security-labelling-failure (329,
repudiation-failure (339,
proof-service-failure (34)
} (l.ub-reason-code)
Negative Notification Reason Codes from a user
NNUserReasonCodeField ::= SEQUENCE {
nn-user-basic-code [O] NNUserBasicCodeField,
nn-user-diagnostic
[l] NNUserDiagnosticField OPTIONAL }
Negative Notification Basic Reason Codes from a user
NNUserBasicCodeField ::= INTEGER {
unspecified (09,
syntax-error (19, -- used when the user discovers a syntax error
--
within the EDI interchange
interchange-sender-unknown (29,
interchange-recipient-unknown (39, -- used when the UA cannot find a valid
--
interchange recipient in the Recipient Specifier
invalid-heading-field (49,
invalid-bodypart-type (59,
invalid-message-type (69,
functional-group-not-supported (79,
subscription-terminated (89, -- unknown to EDIMS-User service
no-bilateral-agreement (99,
user-defined-reason (10)
} (O.ub-reason-code)
Negative Notification Diagnostic Codes from a user
NNUserDiagnosticField ::= INTEGER (l.ub-reason-code)
-- Contains reason passed by user when the value of nn-user-basic-code is
--
user-defined-reason.
Additional information may be indicated in
--
nn-supplementary-information
Negative Notification Reason Codes from a PDAU
NNPDAUReasonCodeField ::= SEQUENCE {
nn-pdau-basic-code [0] NNPDAUBasicCodeField,
nn-pdau-diagnostic [l] NNPDAUDiagnosticField OPTIONAL }
OISO/IEC ISO/IEC 10021-9 : 1995 (E)
--
Negative Notification Basic Reason Codes from a PDAU
NNPDAUBasicCodeField ::= INTEGER {
unspecified (09,
--
undeliverable-mail (19, used if the PDAU determines that it cannot
--
perform physical delivery of the EDIM
physical-rendition-not-performed (2) -- used if the PDAU cannot perform
--
the physical rendition of the EDIM
) (O.ub-reason-code)
Negative Notification Diagnostic Codes from a PDAU
NNPDAUDiagnosticField ::= INTEGER {
--
This field may be used to further specify the error signalled in
--
nn-pdau-basic-code.
Additional information may be indicated in the
--
nn-supplementary-information.
undeliverable-mail-physical-delivery-address-incorrect (32),
undeliverable-mail-physical-delivery-office-incorrect-or-invalid (33),
unde1iverable-mai1-physical-delivery-address-incomplete (34),
undeliverable-mail-recipient-unknown (35),
undeliverable-mail-recipient-deceased (36),
undeliverable-mail-organization-expired (379,
undeliverable-mail-recipient-refused-to-accept (38),
undeliverable-mail-recipient-did-not-claim (39),
undeliverable-mail-recipient-changed-address-permanently (409,
undeliverable-mail-recipient-changed-address-temporarily (4l),
undeliverable-mail-recipient-changed-temporary-address (42),
undeliverable-mail-new-address-unknown (43),
undeliverable-mail-recipient-did-not-want-forwarding (449,
undeliverable-mail-originator-prohibited-forwarding (45),
physical-rendition-attributes-not-supported (31)
} (l.ub-reason-code)
NN supplementary information
9.3.2
The NN Supplementary Information field may be used to return further information to the EDIN recipient to clarify
the Negative Notification.
ED1 Supplementary Information is defined in 8.3.2.
NOTE -
Negative notification extensions
9.3.3
The Negative Notification Extensions allows for future extensions to the NN.
NNExtensionsField ::= SET OF NNExtensionsSubField
NNExtensionsSubField ::= ExtensionField
There are no extensions to the NN defmed in this part of ISO/IEC 10021.
Extensions shall not be critical in NNs.
Forwarded notifications
94 .
A Forwarded Notification (FN) is sent by a UA, if and only if the originator has requested one, when it determines that
it
...