1、INTERNATIONAL STANDARD ISO/IEC 10021-9 First edition 1995-08-01 Information technology - Message Handling Systems (MHS) - Part 9: Electronic Data Interchange Messaging System Technologies de /information - Systkmes de messagerie (Ml-i.3 - Partie 9: Systeme de messagerie avec bchange de don b) to def
2、ine the functional objects of EDI Messaging, the OBJECT and REFINE macros of ISO/lEC 10021-3 I CCIIT Recommendation X.407; c) to define the abstract service of ED1 Messaging, the PORT and ABSTRACT-operation and ERROR macros of ISO/lEC 10021-3 I CCITT Recommendation X.407; d) to define the protocol e
3、xtensions, the EDIM-EXTENSION macro of this part of ISO/IEC 10021; Copyright American National Standards Institute Provided by IHS under license with ANSINot for ResaleNo reproduction or networking permitted without license from IHS-,-,-OISO/IEC ISO/IEC 10021-9 : 1995 Q e) to define extended body pa
4、rt types, the EXTENDED-BODY-PART-TYPE macro of ISO/lEC 10021-7 I CCIIT Recommendation X.420; f) to define MS Auto-actions, the AUTO-ACTION macro of ISO/lEC 10021-5 I CCITT Recommendation X.4 13; g) to define MS attributes, the ATTRIBUTE macro of ISO/IEC 9594-2 I CCITI Recommendation X.501. ASN.l tag
5、s are IMPLICIT throughout the ASN.l modules defined in any annex; the module is deftitive in that respect. NOTE - The use of ASN.1 to describe a class or piece of information does not in itself imply that information is transported between open systems. The fact that the information, by virtue of it
6、s description in ASN.l and of ASN.ls basic encoding rules, has a concrete transfer syntax may be immaterial. Information actually conveyed between systems is designated as such by its inclusion in an application protocol. 5.3 Conventions for Attribute Types in Table 1 This part of ISO/IEC 10021 uses
7、 the conventions listed below in its definition of attribute types for the MS abstract services. For the columns headed “Single/Multi-valued” the following values can occur: - S: single-valued, - M: multi-valued. For the columns headed “Support level by MS and UA” (where UA refers only to a UA that
8、accesses an MS) the following values can occur: - M: mandatory, - 0: optional. For the columns headed “Presence in delivered EDIM”, “Presence in delivered PN”, “Presence in delivered NN” and “Presence in delivered FN”, the presence of each attribute type is described by one of the following values:
9、- p: “always present” in the entry because it is mandatory for generation by the MS or it is a mandatory or defaulted parameter in the relevant abstract operation. - c: “conditionally present” in the entry. It will be present because it is supported by the MS and subscribed to by the user and it was
10、 present in an optional parameter in the relevant abstract operation. - - ahyphen (-) indicates “always absent”, otherwise. For the columns headed “Available for list, alert” and “Available for summarize”, the following values can occur: - N: No - Y: Yes 5.4 Conventions for Attribute Types iu Table
11、2 This part of ISO/IEC 10021 uses the conventions listed below in its definition of attribute types for the MS abstract services. For the columns headed “Source generated by”, the following values can occur: - MD: Message Delivery abstract-operation - MS: Message Store - RD: Report Delivery abstract
12、-operation 6 Information objects The information objects that users exchange in ED1 messaging are of two hinds: EDImessages (EDIM), and ED1 notifications (EDIN). 7 Copyright American National Standards Institute Provided by IHS under license with ANSINot for ResaleNo reproduction or networking permi
13、tted without license from IHS-,-,-ISO/IEC 10021-9 : 1995 (E) OISO/IEC NOTE - The ED1 messaging user (EDMG Lcser) is normally an ED1 application or computer process, not a person. For brevity, the term user is used throughout the rest of this part of ISO/IEC 10021 with the meaning of EDIMG user. Info
14、rmationObject := CHOICE edim O EDIM, edin l EDIN ) 7 Common data types Information items of several kinds appears both in ED1 messages and ED1 notifications. These common items are defined below. 7.1 EDIM identifier An EDIM Identifier is an information item that unambiguously, globally and forever u
15、niquely identifies an EDIM. It comprises an OR-name and a string which may for example contain a time or sequence number or other sufficient information to make this EDIM unique. EDIMIdentifier := SET ( u0er O ORName, user-relative-identifier l LocalReference ) NOTE- OR-name is defined in 8.55 of IS
16、O/IEC 10021-4 I CCIIT Recommendation X.411 and ORName is defined in figure 2 of ISO/IEC! 10021-4 I CCITT Recommendation X.411. The EDIM Identifier shares the same value set with the IPM Identifier defined in ISO/lEC 10021-7 I CCIIT Recommendation X.420. Therefore, an ED1 user agent or ED1 message st
17、ore that is capable of handling both IPM and EDIM shall make sure that the Local Reference is unique both for IPMs and EDIMs. An EDIM Identifier has the following components: a) User: Identifies the user who originates the EDIM. One of the users OR-names. b) User-relative-identifier: Unambiguously i
18、dentifies the EDIM, distinguishing it from all other EDIMs that the user who is identified by the User component originates. Its syntax is that of Local Reference, a Rrintable String of from zero to a prescribed number of characters (see annex G). A length of zero is 1) discouraged. LocalReference :
19、= PrintableString (SIZE (Oub-local-reference 7.2 Extensions A mechanism is provided which allows for future extensions to this part of ISO/lEC 1002 1. ExtensionField := SEQUENCE type 0 EDIM-EXTENSION, criticality I Criticality DEFAULT FALSE, value 2 ANY DEFINED BY type DEFAULT NULL NULL An Extension
20、 Field can be marked critical (Criticality set to TRUE) or non-critical (Criticality set to FALSE) for acceptance of Responsibility. An extension marked as non-critical for Responsibility may be ignored or discarded, while an extension marked as critical must be known and performed for acceptance of
21、 Responsibility of an EDIM. NOTE - The term EDIT Responsibility is defined in 3.5 of ISO/IEC 10021-8 I CCIIT Recommendation F.435. Throughout this document, the term “Responsibility” refers to the term defined in ISO/IEC 10021-8 I CCITT Recommendation F.435, and not to the everyday use of the word.
22、Criticality := BOOLEAN As a notation support for future definitions of extensions, a MACRO is defined. EDIM-EXTENSION MACRO := BEGIN TYPE NOTATION := DataType Critical I empty VALUE NOTATION := value(VALUE OBJECT IDENTIFIER) Copyright American National Standards Institute Provided by IHS under licen
23、se with ANSINot for ResaleNo reproduction or networking permitted without license from IHS-,-,-OISO/IEC ISO/IEC10021-9:1995(E) DataType : := type (X) Default Default := “DEFAULT“ value (X) I empty Critical : := “CRITICAL” I empty END - of extension 8 ED1 message An ED1 Message (EDIM) is a member of
24、the primary class of information objects conveyed between users in ED1 messaging. NOTE 1 - The term message when used throughout the rest of this part of ISO/IEC 10021 is a synonym for ED1 Message where the context admits. EDIM := SEQUENCE ( heading Heading, body Body ? Au ED1 Message consists of th
25、e following components: a) Heading: A set of Heading Fields (or Fields), each an information item that gives a characteristic of the ED1 Message. b) Body: A sequence of one or more body parts. Body := SEQUENCE ( primary-body-part PrimaryBodyPart, additional-body-partaOtherBodyParte OPTIONAL ) Primar
26、yBodyPart := CHOICE ( edi-body-part 0 EDIBodyPart, forwarded-EDIM l EDIMBodyPart ) OtherBodyParte := SEQUENCE OF EDIM-ExternallyDefinedBodyPart NOTE? 2 - EDIWExternally Defined Body Part is defined in 8.3.3. ED1 Body Part is defined in 8.3.1. EDIM Body Part is defined in 8.3.2. The Body has one Prim
27、ary Body Part that contains an EDI information object. This body part is either an ED1 interchange itself or a forwarded EDIM. Examples of types of ED1 information objects are ED1 Interchanges defined by IS0 9735, Electronic data interchange for administration, commerce and transport (EDIFACT), by U
28、nited Nations trade data interchange (UNTDI) and by American National Standards Institute Committee Xl2 (ANSIX12). NOTE 3 - The scope of an ED1 information object type is rather large and includes for example privately Defined types. For brevity, the term interchange is used throughout the rest of t
29、his part of ISO/IEC 10021 with the meaning of ED1 Interchange. The following rules comply with the requirements stated in 7.4 of ISO/IEC 10021-8 I CCIIT Recommendation F.435: c) When an EDIM is first created, the Primary Body Part shall contain one ED1 Body Part. d) When an EDIM is forwarded, its st
30、ructure shall comply with the rules given in 17.3.3.2. Other body parts may be present in a message related to the Primary Body Part but of a different type. Examples of related body parts might be textual information, voice annotation or graphics to be used in conjunction with the interchange. The
31、structure of an ED1 Message is depicted in figure 1. 9 Copyright American National Standards Institute Provided by IHS under license with ANSINot for ResaleNo reproduction or networking permitted without license from IHS-,-,-ISO/IEC 10021-9 : 1995 (E) 01s0/IEc - - Field 1 El Field 2 rxzG-j el “ Enve
32、lope 1 Body wfi2 Other lBodypartn1 body parts - - - - - - To7- Figure 1 - ED1 message structure 8.1 Heading field component types Information items of several kinds appear throughout the Heading. These common items are defined below. In the text that follows, reference is made to EDIFACT segments an
33、d data elements. Annex K explains this in relation to UNTDI and ANSIX12. Values copied from ED1 data elements and represented as T.61 Strings are semantically equivalent to the characters used to form the ED1 data elements in EDIFACT, UNTDI and ANSIX12. 8.1.1 Interchange recipient/sender The Interch
34、ange Recipient and Interchange Sender fields have some data types in common. They are defined below. 8.1.1.1 Identification code The Identification Code identifies a sender/recipient of an interchange. This is semantically identical to the “Sender identification / recipient identification” component
35、 of the Interchange sender/recipient of the EDIFACT UNE3 segment. IdentificationCode := TeletexString (SIZE (lub-identification-code) 8.1.1.2 Identification code qualifier The Identification Code Qualifier, if present, is a qualifier to the Identification Code of a sender/recipient. This is semantic
36、ally identical to the “Identification code qualifier” component of the Interchange sender/recipient of the EDIFACT UNB segment. IdentificationCodeQualifier := TeletexString (SIZE (1 ub-identification-code-qualifier) 8.1.1.3 Routing address The Routing Address, if present, is an address for routing t
37、o the sender/recipient specified in the Identification Code. This is semantically identical to the “Address for reverse routing / Routing address” component of the Interchange sender/recipient of the EDIFACT UNB segment. RoutingAddress z:= TeletexString (SIZE (lub-routing-address) 8.2 Heading fields
38、 The fields that may appear in the Heading of an EDIM are defmed and described below. 10 Copyright American National Standards Institute Provided by IHS under license with ANSINot for ResaleNo reproduction or networking permitted without license from IHS-,-,-OISO/IEC ISOlIEC 10021-9 : 1995 Q Heading
39、 := SEQUENCE ( this-EDIM 11 ThfsEDIMFfeld, originator 2 OriginatorField OPTIONAL, recipients 3 RecipientsField OPTIONAL, edin-receiver 4 EDINReceiverField OPTIONAL, responsibility-forwarded 5 ResponsibilityForwarded DEFAULT FALSE, edi-bodypart-type 6 EDIBodyPartType DEFAULT (id-bp-edifact-IS0646, in
40、complete-copy 7 IncompleteCopyField DEFAULT FALSE, expiry-time S ExpiryTimeField OPTIONAL, related-messages 9 RelatedMessagesField OPTIONAL, obsoleted-EDIMs lOI ObaoletedEDIMeField OPTIONAL, edi-application-security-elements ll EDIApplicationSecurityElementsField OPTIONAL, cross-referencing-informat
41、ion 1121 CrossReferencingInformationField OPTIONAL, - Begin Fields from EDIFACT Interchange edi-message-type 13 EDIMeesageTypeField OPTIONAL, service- ED1 Notification Security non-repudiation( 1) and ED1 Reception Security non-repudiation(l); ED1 Notification Security proof(O) and ED1 Reception Sec
42、urity ( ; ED1 Notification Security non-repudiation( 1) and ED1 Reception Security ( ; ED1 Notification Security ( and ED1 Reception 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
43、 selects what security function should be applied to that notification, and the third may 12 Copyright American National Standards Institute Provided by IHS under license with ANSINot for ResaleNo reproduction or networking permitted without license from IHS-,-,-OISO/IEC ISOLEC 10021-9 : 1995 (E) ma
44、ke certain security requests for proof or non-repudiation of reception of this EDIM by the recipient. ED1 Notification Security and ED1 Reception Security shall not be requested if ED1 Notifications are not requested. The ED1 Notification Requests bit string may assume any of the following values si
45、multaneously. a) PN: A notification of acceptance of Responsibility is requested in the circumstances prescribed in clause 9. b) NN: A notification of refusal of Responsibility for a message is requested in the circumstances prescribed in clause 9. c) FN: A forwarded notification is requested in the
46、 circumstances prescribed in clause 9. The absence of the ED1 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 bel
47、ow on an EDI-UA submitting a subsequent EDIN in response to the ED1 Notification Requests. d) Proof: When submitting the EDIN to the MTS, content-integrity-check shall be requested in the Message-submission-argument as defined in 8.2.1.1.1.28 in ISO/lEC 10021-4 I CCIlT Recommendation X.4 11. e) Non-
48、repudiation: When submitting the EDIN to the MTS, content-integrity-check shall be requested in the Message-submission-argument as defined in 8.2.1.1.1.28 in ISOjIEC 10021-4 I CCIIT Recommendation X.4 11 with a non-repudiable certificate. The absence of the ED1 Notification Security bit string impli
49、es 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) Proof: When submitting the EDIN to the MTS, content-integrity-check (possibly
