ImageVerifierCode 换一换
格式:PDF , 页数:127 ,大小:7.31MB ,
资源ID:437126      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-437126.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ANSI ISO IEC 10021-9-1995 Information technology - Message Handling Systems (MHS) - Part 9 Electronic Data Interchange Messaging System Adopted by INCITS《信息技术.电文处理系统(MHS).第9部分 INCI.pdf)为本站会员(cleanass300)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ANSI ISO IEC 10021-9-1995 Information technology - Message Handling Systems (MHS) - Part 9 Electronic Data Interchange Messaging System Adopted by INCITS《信息技术.电文处理系统(MHS).第9部分 INCI.pdf

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1