GBT16520-2011消息处理业务电子数据交换消息处理业务.pdf 51页

'ICS35．240．30M19a雪中华人民共和国国家标准GB／T16520—2011代替GB／T16520--1996消息处理业务电子数据交换消息处理业务Messagehandlingservices--Electronicdatainterchangemessagingservice2011-07-29发布(ITU—TF．435：1999，IDT)201I-11—01实施宰瞀髁紫瓣警糌瞥星发布中国国家标准化管理委员会仪“。 目次前言⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯引言⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯1范围⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一2规范性引用文件⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一3术语和定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”4缩略语⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”5约定⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯--6EDI消息处理业务⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯“6．1引言⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯-6．2EDI消息处理⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”6．3EDI消息处理环境⋯⋯⋯⋯⋯⋯⋯⋯一6．4EDI消息处理用户⋯⋯⋯⋯⋯⋯⋯⋯一7EDI消息处理系统⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”7．1引言⋯····⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯7．2EDIMS中的信息流⋯⋯⋯⋯⋯⋯⋯⋯“7．3EDI消息处理业务的功能模型⋯⋯⋯··7．4EDI消息的结构⋯⋯⋯⋯⋯⋯⋯⋯⋯--7．5EDI通知⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．8EDIM责任与转发⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”8．1引言⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”8．2转发和二次分发⋯⋯⋯⋯⋯⋯⋯⋯⋯--8．3情况1：无转发⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”8．4情况z：内容不改变和转发EDIM责任8．5情况3：不转发EDIM责任⋯⋯⋯⋯⋯9EDI命名、寻址和号码簿的使用10EDI安全⋯⋯⋯⋯⋯⋯⋯⋯-11与物理投递业务的互通⋯⋯-11．1引言⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”11．2投递和通知⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯··11．3EDIM责任的传递⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯11．4物理再现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯12为EDI使用的消息存储⋯⋯⋯⋯⋯⋯⋯--13服务要素⋯·⋯····⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯14服务要素的分类⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一GB／T16520—2011·⋯⋯⋯⋯⋯⋯⋯⋯⋯Ⅲ⋯⋯⋯⋯⋯⋯⋯·⋯·一Ⅳ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯1⋯⋯⋯⋯⋯⋯⋯·⋯--·一2⋯⋯⋯⋯⋯⋯⋯---⋯-一2⋯⋯⋯·⋯⋯⋯⋯⋯⋯～3⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯3⋯····⋯·⋯⋯⋯⋯⋯⋯·3··⋯⋯·⋯⋯⋯⋯-⋯⋯一4⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯4···⋯⋯⋯⋯⋯·⋯⋯⋯··4··-···-··---··········----·-··4⋯⋯-⋯··⋯·······⋯⋯一4·⋯⋯--⋯⋯·--··-·---⋯一5······························6·--···---⋯⋯⋯⋯⋯⋯⋯7········-⋯⋯-------⋯⋯一8⋯····⋯·····--·---⋯⋯⋯8---------------⋯-⋯⋯⋯一8·····-··⋯⋯⋯⋯⋯⋯·⋯9⋯⋯⋯⋯-⋯⋯⋯⋯--·--9····⋯⋯⋯⋯⋯⋯⋯⋯10⋯⋯⋯⋯⋯⋯⋯⋯⋯·12⋯⋯．．．⋯．．．．．．⋯⋯j．．．生⋯．．．⋯⋯．．．．141514．1基本的EDI消息处理业务⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯···⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯17I“¨坫¨¨"" GB／T16520--201114．2EDI消息处理业务的可选用户设施⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15业务质量⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15．1EDI消息状态⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15．2EDI业务提供者的支持⋯⋯·⋯···⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一15．3投递和通知时间的模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15．4EDI消息投递时间的目标值⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15．5EDI通知时间的目标⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15．6差错保护⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15．7业务的可用性⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯附录A(规范性附录)术语的词汇表⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯附录B(规范性附录)服务要素的定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯附录C(规范性附录)安全综述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯附录D(规范性附录)EDI命名、寻址和号码簿的使用⋯⋯⋯⋯⋯⋯⋯⋯⋯附录E(规范性附录)交叉参考的综述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯ⅡM如加n孔n毖毖鸵拈盯弘∞蛎 前言GB／T16520--2011本标准按照GB／T1．1—2009给出的规则起草。本标准代替GB／T16520--1996《消息处理电子数据交换消息处理业务》。本标准与GB／T16520--1996相比主要变化如下：——标准名称由《消息处理电子数据交换消息处理业务》改为《消息处理业务电子数据交换消息处理业务》；——修改了第1章“范围”的内容；——将第2章“引用标准”改为“规范性引用文件”，将所有引用标准的版本更新，并去掉ISO／IEC10021-1(1988)、ISO／IEC10021—2(1988)、ISO／IEC10021-5(1988)、ISO／IEC10021-n、ISO／IEC9594—2(1988)、ISO／iEC9594-8(1988)、ISO／IEC9594—7(1988)；——将第3章“定义”改为“术语和定义”；——增加了四个服务要素，分别是EDI消息的自动证实、B．3EDI消息的自动相关、B．4EDI通知的自动证实、B．33合并存储消息的EDI消息的提交，全文相关文字作修改；——附录B中增加四节，分别是B．2EDI消息的自动证实、B．3EDI消息的自动相关、B．4EDI通知的自动证实、B．33合并存储消息的EDI消息的提交；——本标准修订肘将GB／T16520--1996的附录C、附录D、附录E由“提示的附录”改为“规范性附录”。本标准使用翻译法等同采用ITU．·TF．435：1999《消息处理业务电子数据交换消息处理业务》(英文版)。本标准由中华人民共和国工业和信息化部提出。本标准由中国通信标准化协会归口。本标准起草单位：工业和信息化部电信研究院、上海贝尔股份有限公司。本标准主要起草人：吴英桦、杨洁。本标准于1996年首次发布，本次是第一次修订。Ⅲ GB／T16520—20T1引言本标准是有关消息处理的一组标准之一。这一组标准为由任意个合作开放系统组成的消息处理提供了一个综合性的规范。消息处理系统和服务能使用户在存储转发的基础上交换消息。由某个用户(始发者)提交的一份消息，由消息传送系统(MTS)(即一个较大型消息处理系统(MHS)的基本组成部分)加以运送，然后投递给一个或多个其他用户(消息接受者)。一个MHs是由各种各样的互连功能实体组成的。消息传送代理(MTA)合作完成存储转发式的消息传送功能。消息存储(Ms)为消息提供存储功能，并提交、检索和管理这些消息。用户代理(uA)帮助用户访问MHS。访问单元(Au)提供接至其他通信系统的和各种类型的服务，例如，其他远程信息处理业务和邮政业务的连接。本标准规定了称为EDI消息处理的消息处理应用的总的系统与业务说明。本版本规定了新的业务要素(EOs)，这些EOS可以提供与用于消息存储关联和服务的IPM消息存储功能类似的EDI消息存储。Ⅳ 1范围消息处理业务电子数据交换消息处理业务GB／T16520--2011本标准规定了EDI消息处理的总系统与业务。在其他标准中，规定了消息处理系统与业务的其他方面。消息处理系统和业务相关标准均在ITU-TF．400／x．400的表1中列出。ITu-TF．400系列标准规定了在MHS上构成的公用业务，以及公用业务对MHs间的相互访问。ITU_TX．400系列标准规定了MHS技术方面的内容，在ITu—TX．402／IsO／IEC10021—2中规定了MHS总的系统结构。在ITU-TX．435／ISO／IEC10021-9中规定了EDI消息处理技术方面的内容。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。ISO／IECl0021-1信息技术消息处理系统(MHS)第1部分：系统和服务概述(Informationtechnology--MessageHandlingSystems(MHS)Part1：Systemandserviceoverview)ITU-TF．400／x．400消息处理系统与业务综述(Messagehandlingservices：Messagehandlingsystemandserviceoverview)ITU_TF．401消息处理业务共用消息处理业务的命名与寻址(Messagehandlingservices：Na—mingandaddressingforpublicmessagehandlingservices)ITU．TF．415消息处理业务与公用物理投递业务的互通(Messagehandlingservices：Inter—communicationwithpublicphysicaldeliveryservices)ITU_TX．402(1999)lIS0／IEC10021—2：1999消息处理系统总体结构(Informationtechnolo—gy--MessageHandlingSystems(MHS)：Overallarchitecture)ITu—Tx．413(1999)lIs0／IEc10021—5：1999消息处理系统消息存储抽象服务定义(Infor—mationtechnology--MessageHandlingSystems(MHS)：Messagestore--Abstractservicedefinition)ITU-TX．435(1999)IISO／IEC10021—9消息处理系统电子数据交换消息处理系统(Informa—tiontechnology--MessageHandlingSystems(MHS)：Electronicdatainterchangemessagingsystem)lTU_TX．501(1997)1IsO／IEc9594—2：1998信息技术开放系统互连号码簿：模型(Infor—mariontechnology--OpenSystemsInterconnection--TheDirectory：Models)ITU-Tx．509(1997)lIsO／IEc9594—8：1998信息技术开放系统互连号码簿：公钥和属性鉴别框架(Informationtechnology--Opensystemsinterconneetion--Thq．Directory：Public-keyandat—tributecertificateframeworks)ITu—TX．521(1997)IISO／IEC9594—7：1998信息技术开放系统互连号码簿已选的客体类别(InIormationtechnology--OpenSystemsInterconnection--TheDirectory：Selectedobjectelas—ses)】 GB／T16520—20113术语和定义下列术语和定义以及附录A中的术语和定义适用于本文件。本标准的附录B中包含有适用于EDI消息处理的服务要素的定义。在本标准中提出了适用于消息传送业务和由EDI消息处理所用的服务要素。但其定义则放在ITu—TF．400的附录B中。3．1EDI转发EDIforwarding将收到的EDIM向前传送给由进行转发的EDI用户代理／消息存储决定的一个还是多个接受者。在已投递到某个EDI用户代理或EDI消息存储的EDI消息，向前转发给另一个EDI用户代理或EDI消息存储时发生EDI转发。3．2EDI消息EDImessage在EDI消息处理用户间传送电子形式的信息。EDI消息在EDI消息处理用户问运送的主信息客体类别的成员。参见ITU-TX．435的第5章。3．3EDI消息处理用户EDImessagingu∞r参与EDI消息处理的用户。EDI消息处理用户始发、接收或既始发又接收EDI消息。EDI消息处理环境包含任意数目的EDI消息处理用户。EDI消息处理用户可以是人，也可以是计算机进程。EDI消息处理用户可通过访问单元访问EDI消息处理系统。3．4EDI通知EDInotification次信息客体类别的成员，它给EDI消息的始发者指出EDI消息的EDIM责任的安排。3．5EDI消息责任EDImessageresponsibilityEDI消息责任指出某个特定的用户是否已通过它的EDI用户代理／消息存储提供可用的主题EDI消息。EDI消息责任在本标准和ITu—TX．435建议中不具有法定意义。4缩略语下列缩略语适用于本标准。ANSI美国国家标准协会AU访问单元DIT号码簿信息树DL分发表DuA号码簿用户代理EDI电子数据交换EDIFACT电子数据交换用于行政、商业和运输EDIMEDI消息2AmericanNationaIStandardsInstituteACCCSSunitDirectoryinformationtreeDistributionlistDirectoryuseragentElectronicdatainLerchangeElectronicdatainterchangefOrAdministrationcommerceandtransportEDImessage EDIMEEDIMGEDIMSEDI-AUEDI-IⅥSEDI-UAEDINFNIDMDMHMHSMSMTMTAMTSNDNNNO／RPDPDAUPDSPNPRMDTLMAUAUNTDIUTC5约定EDI消息处理环境EDI消息处理EDI消息处理系统EDI访问单元EDI消息存储EDI用户代理EDI通知已转发通知标识符管理域消息处理消息处理系统消息存储消息传送消息传送代理消息传送系统未投递通知否定通知始发者／接受者物理投递物理投递访问单元物理投递系统肯定通知专用管理域远程信息处理代理用户代理联合国贸易数据交换协调通用时间GB／T16520--2011EDImessagingenvironmentEDImessagingEDImessagingsystemEDIaccessunitEDImessagestoreEDIuseragentEDInotificationForwardednotificationIdentifierManagementdomainMessagehandlingMessagehandlingsystemMessagestoreMessagetransferMessagetransferagentMessagetransfersystemNon-deliverynotificationNegativenotificationOriginator／RecipientPhysicaldeliveryPhysicaldeliveryaccessunitPhysicaldeliverysystemPositivenotificationPrivatemanagementdomainTelematicagentUseragentUnitedNations，tradedatainterchangeCoordinateduniversaltime在第2章中，引用的是ISO／IEC取得一致的标准·使用大写字母时，尽可能地使用通用语言习惯·6EDI消息处理业务EDI消息处理业务给EDI消息处理用户提供一些特性，以便有助于与其他EDI消息处理用户尊苎处理。在大多数情况下，EDI消息处理用户是计算机进程。EDI消息处理业务利用消息传送业务的能 GB／T16520--2011力(见ITu—TF．410)发送和接收EDI消息。描述EDI消息处理业务特性的服务要素在附录B中定义，并在第14章中进行分类。EDI(电子数据交换)，可描述为计算机与计算机之问结构化的事务数据交换，例如发票和购货单。在某些情况下，EDI消息处理业务可用来将一次EDI互换发送到物理呈现系统，例如物理投递系统或传真机。EDI消息处理业务由EDI消息处理提供。6．2EDI消息处理EDI消息处理(EDIMG)由EDI消息(EDIM)的交换和EDI通知(EDIN)组成。这些消息和通知均是在IT【卜TX．435中规定的信息客体。6．3ED|消息处理环境EDI消息处理产生的环境可以被模型化为以下称为EDI消息处理环境(EDIME)的功能客体。细分(按功能分解)时，EDIME可以着作是由称为EDI消息处理主客体的更小客体组成的。这种主客体包括单个中心客体、EDI消息处理系统(EDIMS)和若干个称为EDI消息处理系统用户(EDIMG用户)的外国客体。EDI消息处理环境结构见图1。圈1EDI消息处理环境6．4EDI消息处理用户EDI消息处理用户(EDIMG用户)是参与EDI消息处理的用户。EDIMG用户可以始发、接收或者既始发又接收EDIMS。EDIMG可包含任意数目的EDIMG用户。EDIMG用户可以是人，也可以是计算机进程。EDIMG用户通过访问单元访问EDIMS。7EDI消息处理系统7．1引言EDI消息处理系统(EDIMS)是所有EDMIG用户都通过EDIMS相互进行EDI消息处理的功能客体。EDIMS可被模型化为由更小的相互作用的功能客体组成。这些更小的功能客体称为EDI消息处理的次客体。它们包括单个中央客体，即消息传送系统(MTS)和三个种娄的若干个外围客体：EDI用户代理(EDI—uA)、EDI消息存储(EDI-MS)和EDI访问单元(EDI_Au)。EDIMS结构见图2，EDI—UA、EDI-MS和EDI—AU是EDIMS用来给EDIMG用户提供业务的客体。 GB／T16520—20”图2EDI消息处理系统7．1．1EDI用户代理EDI用户代理(EDI_uA)是定制成更适用于单个EDIMG用户参与EDI消息处理的用户代理。它帮助EDIMG用户始发和接收含有EDIM的消息。EDIM包含任意数目的EDI-UA。注：EDIUA和EDIMG用户间的边界的确切定义已超出本标准范围。7．1．2EDI消息存储EDI消息存储(EDI-MS)是定制成更适用于单个EDI-UA参与EDI消息处理的消息存储。它帮助EDI-UA提交、投递、存储和检索含有EDIM的消息。7．1．3消息传送系统在目前的情况下，消息传送系统(MTS)在EDI-UA间或在EDI—UA与访问单元问运送EDIM或EDI通知(EDIN)。EDIM包含有单个MTS。7．1．4EDI访问单元EDIMG用户可以通过访问单元(AU)访问EDIMS或接受EDIMS的访问。其中一种类型的访问单元是物理投递访问单元(PDAu)。在EDIMG中，物理投递访问单元通过物理投递系统(PDS)向EDIMG接受者提供发送消息的能力。7．2EDIMS中的信息流图3是对图2的扩展并示出EDI消息处理中的主信息流。 GB／T16520—2011图3EDI消息处理信息流程7．3EDI消息处理业务的功能模型图4中指出EDI消息处理业务的功能模型。EDI消息处理业务中所用的uA由一类特定类别的合作的uA组成。任选的PDAU准许EDIMG用户发送消息给EDI消息处理环境外的间接用户。EDI消息处理业务中所用的消息存储，具有专用的EDI相关功能，并可由EDIMG用户任选地用来代表它们自己投递消息。图4中所示的远程信息处理代理(TLMA)准许访问远程信息处理业务。 GB／T16520—20117．4EDI消息的结构图4EDI消息处理业务的功能模型EDI类的UA创建含有EDI消息处理业务特定内容的消息。从一个EDI-uA发送给另一个EDI-UA的特定内容是始发者的结果。这个始发者通常是一个应用进程，它组成并发送消息，该消息称为EDI消息(EDIM)。EDIM携带EDI交换信息，并可选用地携带EDI交换有关的其他信息。在一个EDI中只包含一个EDI交换。每个EDIM在始发EDIM时应包含一个EDI交换的信体部分。转发EDIM时，除已转发信体部分不能被移出外，任何后续的信体部分都可以被移出(全部移出，而不是部分移出)。转发时，用位置留用区代替被移出的信体部分，以指出何种类型的信体部分被移出。转发EDIM时，EDIM的标题是不应被移出的。EDIM结构，当它与MHS基本消息结构有关时，示于图5。当通过MTs传送时，EDIM是用信封传送。基本的消息结构EDI洧息图5EDI消息结构 GB／T16520—201图6中所示的典型的EDI交换与相应的EDI消息结构问的映射。EDI交换可以全部映射到称为主信体的信体部分内，EDI交换可以是EDIFACT、ANSIXl2、UNTDI或专门定义的EDI交换。其他信体部分可以用来运送与该EDI交换相关的信息，例如图或解说性文本等。EDIM标题包含各种信息字段，有些信息字段可以出现在EDIFACT交换头部字段中(或是对应ANSIX125UNTDI的ISA或STX段)，其他的信息字段包含来自始发者的业务请求。标题和信体部分形成EDIM。EDIFACT交换图6一个典型的EDI交易的消息结构7．5EDI通知EDIMG用户可请求接受者返回一个EDI通知(EDIN)，指明收到的EDI消息的安排。该通知由始发EDI-UA提出请求并由接受者EDI-UA、EDI-MS或AU生成。请求和报告有三种可能的状态，导致生成肯定通知(PN)、否定通知(NN)或已转发通知(FN)。收到的EDI消息可原样转发，响应通知请求的责任也有可能转发给被转发EDI消息的接受者或中间接受者，中间接受者则应有责任对消息的原始发者进行响应。始发EDI-UA可请求告知响应通知请求的责任是否已转发。在这种情况下，转发EDIM的EDI-UA或EDI-MS应给始发EDI-UA发送EDI已转发通知(FN)。在所有情况下，包括已被转发EDIM的EDI-UA发送的通知，都应包含由原始发者所指定的接受者的O／R名。始发EDI．uA可向任意组合的发送EDIM接受者请求若干个任意组合的EDIN。若始发者没有请求通知，则接受者什么也不应发送。8EDIM责任与转发8．1引言EDIMs包括一种称为EDIM责任的概念。这种概念是下面描述EDIN和转发的关键。为简化下8 GB／T16520--2011面文本的描述起见，所示的所有转发由EDIoUA来完成。应当注意的是，这里描述同样适用于EDI-MS完成的转发。引入EDIM责任概念的目的，主要是在EDI-UA之间提供一种运送消息证实的方法。在某种情况下，EDIM责任可适用于访问单元。EDIM责任的概念描述如下：EDIM责任指出接收EDI-UA所收到的EDIM可为EDING用户所用。当转发时，不论EDI—UA增加还是移出信体部分，EDIM责任总应当被接受。EDIM不能离开EDIMS，除非EDIM责任已被接受(投递到PDAU是一种特殊情况)。若始发EDI-UA请求这样做，则接受者EDI-UA以及可能是中间EDI—UA(若请求)，应给始发EDI—UA发送EDIN。EDI-UA接收EDIM时，若被请求有EDIN，它应发送适当的EDIN，通知始发EDI-UA，接受者EDI—uA已接受或拒绝EDIM责任。若请求通知，则当EDI-UA接受、拒绝或转发EDIM责任时，它应发送适当的EDIN给始发者，若转发，它应在已转发EDIM创建适当的标题字段。这些操作的详细情况在ITU_TX．435中描述。被转发的信体部分无论如何是不能被修改的。若EDIM责任被转发，被转发的EDIM无论如何也是不能被修改的。若EDIM责任被接受，则在创建已转发的EDIM时，信体部分可从始发EDIM移出，也可以加到始发EDIM上。转发时被移出的信体部分可用位置留用区代替，以指出何种类型的信体部分被移出。EDIM责任转发的接受者只限于一个。EDIMG包括转发时防止环路的机制。8．2转发和二次分发在EDIMG中，可能希望由中央的EDI用户代替接收EDI消息，然后再转发给最终的EDI用户代理。例如，这种做法，使大型的组织能对进入该组织的全部EDI消息业务量执行例如日志、审计等集中的功能。在这些功能执行后，消息处理业务量可分配给为接受者EDI应用服务的EDI用户代理。同样，增值网络的业务提供者也可代表它的用户操作一个类似的中间步骤。下面描述了如何将EDIoUA用作这个中问步骤。中间的EDI-UA通常不是最终的EDI-UA，因此在EDIMG中，需要对EDIM提供EDIM责任接受端对端的证实。“EDI通知请求”服务要素，准许始发者从每个接受者请求发回肯定、否定和已转发通知。“EDI通知请求”允许中间的EDI-UA用已转发消息和ITu—TX．435所定义的协议要素指出是否已接受EDIM责任。这些方法准许EDIM责任接受推迟到EDIM到达最终的EDI-UA，并提供一个指示表明哪一个EDI-UA将给原始发者返回一个通知。为了说明EDIoUA作为中间步骤的使用情况，下面描述三种情况。无论在哪种情况下，EDIM都始发于EDI-UA和终结于EDI-UA3。EDI-UA2是中间EDI-UA。在情况1和情况2中，假设EDIM是内容不改变的转发。在所有三种情况下，均假设EDI-uAl已请求通知。注：下列表中所描述的事件都不必接表1中所给出的顺序严格执行。8．3情况1：无转发EDI-UAl制备的EDIM寻址到EDI-UA3。EDIM提交给MTAl，然后传送给MTA3，再投递给EDI-UA3，最后由EDIMG用户3检索。Ⅱ)I_UA3用EDIN响应，拒绝ED田Vl责任(即PN)。若EDI-UA3已决定EDIMG用户3不能检索消息，EDI-UA3用EDIN响应，拒绝EDIM责任(即NN)。信息流按图7中所示。EDIM和EDIN的顺序在表1中列出。 GB／T16520—2011一一EDIN传送的方向．一ED嘴送的方向。围7情况1：无转发表1情况1：无转发事件EDIMEDIN1EDI-UAl提交EDIM至MTAl2MTAl传送EDIM至MTA33MTA3投递EDIM至EDI-UA34EDI-UA3提交PN／NN至MTA35MTA3传送PN／NN至MTAl6MTAl投递PN／NN至EDI-UAl8．4情况2：内容不改变和转发EDIM责任在这种情况下，中间EDI-UA将消息从EDI-UAl转发到EDI-UA3。最终的接受者是EDI-UA3，EDI-UA2执行转发操作，将EDIM责任转发给EDI-UA3。由EDI-uAl制备的EDIM寻址到EDI-UA2。EDIM投递给EDI-UA2时，根据EDI-UA2已知道的选择准则，EDI-UA2把它不改变地转发给EDI-UA3。EDIM责任处理如下：EDI-UA2转发EDIM责任时，它应创建已转发EDIM，使EDI-UAl接收请求的EDⅨ(详见ITU-TX．435)。这样就可发送下列EDIN。a)若EDI-UAl请求转发EDIM责任通知，EDI-UA2就给EDI-UAl发送已转发通知FN。EDI-UA2成功地将EDIM提交给MTA2时，就可发送EDIN。b)若EDI-UA2从MTA3(经MTA2)接收未投递通知，它可给EDI-UAl发送否定通知(NN)。注意，在这种情况下，EDI-UA2可以选择发送或不发送EDIN。不可以请求或发送其他的EDIN。例如，EDI-UA2不能向ED卜uA3请求通知，EDI-UA3也10 GB／T16520—20”不能给EDI．UA2发送EDIN。在未投递的情况下，EDI—UA2可试图重新提交EDIM给指定的接受者。在这种情况下，只有当EDI_uA2决定不再试图重新提交EDIM给EDI_uA3时，才发送NN给ED卜uAl。c)若转发成功，EDI_uA3应发送适当的EDIN给EDI-UAl，接受或拒绝EDIM责任。图8中表明上述情况2所描述的信息流。EDIM和EDIN可能的顺序解释在表2中解释。事件(8、11、13和t5)和(10、12、14和16)是相互排斥的。一—-EDIN和EDN传送的方向一EDIM传送的方向。圈8情况2：EDLM责任转发表2情况2：EDIM责任转发事件EDIMED矾NDN未投递通告lEDI-UAl提交I／DIM至MTAl2MTAl传送EDIM至MTA23MTA2投递EDIM至EDI-UA24若请求，EDI-UA2提交FN至MTAl25EDI-UA2把要转发EDIM提交至MTA26MTA2传送FN至MTAl7MTA2传送EDIM至MTA38MTA2发送NDN至EDI-UA29MTAl投递FN至EDI-UAl。lOMTA3投递EDIM至EDI-UA311EDI-UA2提交NN至MTA2 GB／T16520—2011表2(续)事件EDIMEDINNDN未投递通告12EDI-UA3提交PN／NN至MTA313MTA2传送NN至MTAl14MTA3传送PN／NN至MTAl15MTAl投递NN至EDI-UAl16MTAl投递PN／NN至EDI-UAl应注意下列事项：a)若EDI-UAl请求FN(已转发通知)，它通常会接收到若干个EDIN；b)EDI-UAl可不按创建时的顺序来接收EDINc)无论EDI-UAl是否请求了FN，EDI—UAl也有可能接收不到EDIN。(例如，MTA2将EDIM投递给EDI-UA2后，EDI-UA2发生了灾难性的故障。)由EDI-UAl正确处理以上三项。例如，通过跟踪下列内容对第一项进行处理。a)EDIMIDlb)原接受者；c)提交时间；d)预期的EDI通知。可以使用在EDIN中包含的UTC时间(EDIN创建时间)来对第二项进行处理。第三项可用EDI-UAl的超时机制来处理。处理以上三项的机制是属于本地的实施事宜，因而超出本标准的范围。8．5情况3：不转发EDIM责任这种情况是EDI-UAl制备的EDIM寻址到EDI-UA2，EDI-UA2先接受消息的EDIM责任，再转发给EDI-UA3。例如，若EDI-UA2在转发(改变内容)时增加或移出信体部分，则就会出现这种情况。在接受EDIM责任时，EDI—UA2发送EDIN给始发者(即PN)，并创建已转发EDIM，这样EDI-UAl(始发者)就不能再接收更多的EDIN(详见X．435建议)。同情况2一样，EDI-UAl将EDIM寻址到EDI_UA2。与前述的两种情况一样，EDI-UA3表示最终目的地。检索到EDIMJF，EDI—UA2给EDI-UAl返回一个适当的通知。于是该消息转发给EDI-UA3。由于现在已接受了初始EDIM责任，EDI—UA2可根据需要，自由地请求或不请求EDIM责任。若请求，其结果是EDIM责任的关系只在EDI-uA3和EDI—UA2问应用，与前面的情况不同，不是端对端的。这里描述的前提是，假设已被请求EDIM责任，从而EDI-UA3用适当的通知来响应EDI-UA2。图9和图10给出了情况3的信息流。EDIM和EDIN的顺序解释都在表3中解释。 GB／T16520—2011一一EDIN传送的方向一EDIM传送的方向圈9情况3：不转发EDIM责任，第一部分一一EDIN传送的方向：一EDIM传送的方向。图10情况3：不转发EDIM责任，第二部分13 GB／T16520--2011表3情况3：不转发责任事件蟹9图10lEDI-UAl提交EDIM至MTAl2MTAl传送EDIM至MTA23MTA2投递EDIM至EDI-UA24EDI-UA2提交PN至MTA25EDI-UA2把要转发EDIM提交至MTA26MTA2传送PN至MTAl7MTA2传送EDIM至MTA38MTAl投递PN至EDI-UAl9MTA3投递EDIM至EDI-UA310EDI-UA3提交PN／NN至MTA311MTA3传送PN／NN至MTA212MTA2投递PN／NN至EDI-UA29EDI命名、寻址和号码簿的使用ITU-TF．400／X．400的第13章对号码簿规定的MHS使用是用来提供EDI消息处理所需的号码簿的业务。每个管理域都应给它的EDIMG用户提供号码簿业务。EDI消息处理、命名和寻址及后来的号码簿业务要求概述于本标准的附录D。10EDI安全ITU_TF．400／X．400的第15章中规定的MHS安全能力，也适用于EDI消息处理。另外，对ITU-TF．400／X．400的15．4提供了下列扩展。EDIMG扩展的安全能力的概述如下(见表4)：EDI通知证明：使EDIM的接受者能创建一个EDIN，EDIN的接受者可用此EDIN来鉴别EDIN的始发者。EDI通知不可否认：给EDIN的接受者提供了源EDIN的证明，防止EDIN的始发者再有任何试图否认发送了EDIN。接收内容证明：使EDIM的始发者能验证接受者所收到的消息内容与始发者始发的消息内容相同。始发内容不可否认：给EDIM的始发者提供所收到的消息内容与始发的消息内容有相同的证明。这就防止始发者再有任何试图否认始发的消息内容。接收内容不可否认：给EDIM的始发者提供所收到的消息内容与始发的消息内容有相同的证明。这就防止接受者再有任何试图否认所收到的EDIM内容。 衰4MHS部件提供和使用的安全消息传输的服务要素GB／T16520—2011服务要素EDIM始发者MTSEDIM接受者EDI通知证明EDI通知不可否认接收内容证明始发内容不可否认接收内容不可否认P——服务提供者。U——服务用户。附录c描述EDIMS脆弱性，并详细介绍各种脆弱性的克服方法。ITU_TX．435的附录A描述了EDIMS所需的对ITU—T建议X．402安全模型的增强(增强型安全服务)。ITU-TX．435描述了安全服务的操作和规程。1与物理投递业务的互通11．1引言与ITU_-TF．415所规定的一样，MH／PD互通是消息传送业务的类属能力。若要使用这种能力，始发者在提交时可采用邮政O／R地址，或者在提交时若采用号码簿名，则要选择物理投递作为“请求的投递方法”，并要从MH／PD服务要素中(ITU_TF．435表1中)选择某些所需要的选项。始发者按ITU-TF．401规定的接受者地址提供邮政O／R地址。这可以通过号码簿来实现。11．2投递和通知在EDIM从最终的MTA传递到PDAU(MTA到EDI-Au)时，发生了到访问单元的投递。如图11所示，与物理投递应用有关的投递通知EDI通知按ITu-TF．415中的规定，并增加了EDIN。这些通知由被认为是共置的MTA／PDAU系统部件产生。ITU_TF．415提供“T”时间的定义；“Tedi”可定义为：Tedi=EDIN的生成和投递。注1：起始时间对应于生成EDIN的时间。注2：结束时间对应于EDIMG用户可用的EDIN的时间。11．3EDIM责任的传递直到PDAU将发送给它的EDIM去物理再现并接着投递时，PDAU决不能为EDIM接受EDIM责任。若要求“EDI通知请求”，则PDAU存在两种可能性。若PDAU决定它能为物理投递再现EDIM时，则它应给EDIM的始发者返回一个FN。然而，若PDAU决定它不能再现或投递EDIM时，则它应给EDIM的始发者返回一个NN。11．4物理再现ITu-TF．415的附录B规定的基本物理再现的细节应作为基础，主要用于路由和投递信息的呈现，例如地址块、相对于窗口的页面位置等。15 GB／T16520—20”对于专用于EDI的硬拷贝特理呈现，标识有三种方法：a)标准化的再现}b)专用定义的呈现；c)再现的伴随信息。另外，若可能的话，假定接受者能用该信息通过其他的手段提供的指导或消息工作，若没有可用的再现规则时，EDIM则可简单地“按原样打印”。巨三卜_囡—丑{王}猷D创建洧息一一一一一一一一—lD，，吵Tedl●T3姻投递通知投递消息姻通知生成婚ED!通知生成囤物理再现围物理运输一姻一竺苎竺塑⋯⋯愆圈⋯⋯⋯一一盎蒜瓣D蝌件囝螂件12为EDI使用的消息存储图11MH／PD投递和通知的时间模型接受者消自存储特性可用于EDI消息处理。通用的MS服务要素，“存储消息提取”、存储消息列表“、存储消息概要”、“存储消息删除”和。存储消息提醒”都适用于EDI消息处理。。ITU-TX．413描述了一般的MS属性和自动动作。ITU_TX．435描述了EDI专用的MS属性和自动动作。一个EDI专用的MS服务要素，“存储EDI消息自动转发”，为EDI消息处理提供适当的一个MS自动转发通力。16 安全政策可限制消息存储服务要素的使用。13服务要素GB／T16520—2011服务要素是MHS的特有特性、功能或能力。适用于EDI消息处理的服务要素由MT服务要素和EDI消息处理服务要素组成。EDI消息处理用的MT服务要素在本标准的表5～表7中列出，在rrU—TF．400／X．400的附录B中对其进行了规定。专用EDI消息处理服务要素的规定列于表5～表7，其定义在附录B中。适用于EDI消息处理的所有服务要素的实现方法在ITL卜TF．400／X．400系列的其他标准中描述。14服务要素的分类14．1基本的EDI消息处理业务使用MT服务的基本的EDI消息处理业务，使EDIMG用户能发送和接收EDI消息。EDIMG用户借助EDI用户代理(EDI-UA)制备EDI消息。EDI-UA相互合作，帮助相应的EDIMG用户问进行消息处理。要发送EDI消息时，始发EDIMG用户将消息提交给它的EDI-UA，指定该EDI消息接受者的O／R名。具有标识码的EDI消息被始发者的EDI-UA通过消息传送服务发送给接收者EDI-UA／MS。在成功地投递到接受者EDI-UA之后，EDI消息可供接受者使用。为了方便实现有意义的消息处理，接受者可以它允许投递给EDI—uA的EDI消息中，规定编码信息类型以及它愿意接受的EDI消息的最大长度。给每份投递的消息都提供有原编码信息类型及指明是否已完成转换的指示和最终编码信息类型。另外，给每份EDI消息还提供有提交时间和投递时间。基本的MT服务提供有未投递通知。属于基本的EDI消息处理服务的服务要素在表5中列出。裹5属于基本EDI消息处理业务的服务要素服务要素参考访问管理B．1内容类型指示B．12已转换指示B．15投递时戳指示B．22EDI消息标识EDI．8消息标识B．41未投递通知B．47原编码信息类型指示＆54提交时戳指示B．89类型化信体EDI．30用户／UA能力登记R93注：B参考是对应ITU_TF．400／X．400的附录B，EDI参考是对应本标准的附录B。 GB／T16520—2011T4．2ED[消息处理业务的可选用户设施EDI消息处理业务的一组服务要素都是可选的用户设施、EDI消息处理业务可选的用户设施，可以每份消息为基础选用，也可以商定的合同时间内选用，分别在表6和表7中列出。以每份消息为基础选用的EDI消息处理业务的用户可选设施，由EDFUA分为始发和接收两类。若管理域为EDFUA提供始发用的用户可选设施，则EDIMG用户根据相关服务要素规定的过程创建并发送DI消息。若管理域为EDI-UA／Ms／AU提供接收用的用户可选设施，则接由EDI-UA／MS／AU就应能接由和识别相关服务要素的指示，并能将请求可选用户设施通知给EDIMG用户。可从两个方面为EDFUA／MS／AU的每个可选用户设施分类为附加的(A)和基本的(E)。表6以每份消息为基础EDI消息处理可选用户设施服务要素始发接收参考附加物理再现AR2允许替换接受者ER3应用安全要素AEDI．1基本物理再现AEB．7字符集EEDI．2内容机密性AB．10内容完整性AB．11转换禁止EB．13丢失信息情况下的转换禁止AB．14营业处收集AEB．16具有通知的营业处由集A＆17交叉参考信息AEEDL3延迟投递EN／AB．19延迟投递取消EN／AB．20投递通知EN／AB．21经公众传真业务的投递AB．23由号码簿名指定的接受者AN／AB．24公开其他接受者EB．25分发表扩展历程的指示N／AEB．26禁止分发表扩展AN／AB．27EDI转发AN／AEDL4EDI消息类型EEDL5EDI通知请求EEDL6EDI标准指示EE∞L7允许EDIM责任转发指示EEDL9EDIM接收方AEEDLl0EMS(特快专递业务)AEB．28日期／时间到期指示AEEDLll显式转换AN／AB．30投递选择等级EB．32不完整拷贝指示AEEDLl2交换头EEDLl3最迟投递的指定AN／AB．3918 囊6(续)GB／T16520—2011服务要素始发接收参考消息流机密性AN／AR40消息源鉴别AR42消息安全标记AR43消息顺序完整性AR44多址投递EN／AR45多部分信体AEEDLl4始发内容不可否认AEDI．15接收内容不可否认AEDLl6接收内容不可否认请求AEDLl7投递不可否认A&49EDI通知不可否认AEDLl8EDI通知不可否认请求AEDI．19源不可否认AR50提交不可否认A＆51废弃指示AEEDL20普通邮件AER53始发者指示EEDI．Zl始发者请求的替换接受者AN／A＆56MHS进行的物理投递通知AR57PDS进行的物理投递通知AE’＆58允许物理转发AE。B．59禁止物理转发AE。R60防止未投递通知AN／A＆61探查AN／AB．63探查源鉴别AN／A＆64接收内容证明AEDI．22接收内容证明请求AEDI．23投递证明A＆65EDI通知证明AEDL24EDI通知证明请求AEDI．25提交证明AN／AR66接受者指示EEDL26始发者不允许改投AN／AB．68挂号邮件AB．70给个人的挂号邮件AB．71相关消息AEEDI．27报告源鉴别AB．74转发地址请求AB．75请求投递方法EN／AB．76业务指示AEDI．28特种投递‘AE。R81存储消息删除N／AE。。R84存储消息提取N／AE’‘&8519 GB／T16520—2011裹6(续)服务要素始发接收参考存储消息列表N／AE。。B．86存储消息概要N／AE。。B．87带有返回物理消息的不可投递邮件AE。B．91分发表的使用AN／AB．92E——就提供可选基本用户设施；E‘——只适用于PDAu的基本可选用户设施；E～——只适用于Ms的基本可选用户设施；A——可提供的附加可选用户设施，N／A——不适用。1PADu和相关PDs至少应能支持EMS或特种投递。注1：若由EDI-UA接由归纳为。A”类服务要素，则需要对方协议。注2：B参考对应ITU-TF．40Q／X．400的附录B，EDI参考对应本标准的附录B。裹7在商定的合同时间内EDI消息处理可选用户设施服务要素分类参考EDI消息的自动证实AEDI．31EDI消息的自动相关AEDL32EDI通知的自动相关AEDL33普换接受者的指定AB．4保持投递AR33隐式转换A＆34MS登记AB．nn-人消息改投AR69有限制的投递AB．77安全访问管理AR79存储EDI消息自动转发AEDI．29存储消息提醒A＆82存储消息自动转发A＆83b合并存储消息的EDI消息的提交AEDI．34注：B参考对应ITU-TF．400／X．400的附录B，EDI参考对应本标准的附录B。‘该服务要素将在ITU-TF．400／X．400的下一个版本中定义并指定为。B”号码。所描述的能力在ITU．TX．413中支持，但在ITU-TF．400／X．400中未描述。。对于EDI消息处理，不鼓威使用这个一般MS能力的服务要素。“存储EDI消息自动转发”是EDI专用的MS能力，可提供一种合适的替代者。15业务质量15．1EDI消息状态每份EDI消息的唯一的标识，使系统能提供例如与一份EDI消息状态有关的信息。20 GB／T16520—2011在系统出故障时，所有收到的和未投递的EDI消息都应是可跟踪的。若EDI消息不能投递，则应通过“未投递通知”。15．2EDI业务提供者的支持就涉及的系统组成部分而言，若在预定的时间内没有收到未投递通知，则业务提供者应给用户提供帮助。对消息状态和跟踪提供的附加支持，属本国的责任范围。15．3投递和通知时间的模型投递和通知时间的模型见图12。臣》创建EDIMT1D提交。“D一一一一一一一!兰：D—IM一一—D投J目IEDIM投递通知《■快递生产通知一gEDI通知生成EDl理知投递T1——投递时间，注1；Tl的起始时间对应于提交时藏指示所标明的时间。注2：T1的结束时间对应于投递时戳指示所标明的时间。T2——通知投递时间；洼1：T2的起始时间对应于投递时戳指示所标明的时间。注2：T2的结束时间对应于EDIMG用户通过EDI-UA或EDI-MS可以获得投递通知的时间。Tedi——EDI的通知生成和投递时间。注1：Tedi的起动时间对应于生成EDIN的时间。注2：Tedi的结束对应于EDIMG用户可以获得EDIN的时间。围12投递和通知时间的模型15．4EDI消息投递时间的目标值投递时间(包括传送时间)的目标值取决于消息传送系统、中转域的数目和消息的长度。这个值比IPM业务目前所规定的目标值要小得多。若EDI消息在提交后的z小时内(或是延期投递所指出的日期和时间之前)还未投递，接受者EDI-UA的管理域应强制发出未投递通知，z的值取决于始发者请求的投递等级。2】～一二一～—f￡ GB／T16520一20”15．5EDI通知时间的目标EDI通知投递时间的目标值取决于本地的安排。当接受方EDI_uA发起EDIN时，EDIN的时间目标值与导致EDIN产生的EDI消息有相同的时间目标值。裹8EDIN时间的目标值投递等级在下述时间之前9s％被投递加急15rain普通60rain慢件4h注1：与PRMD互通不包括在时间目标计算内，注2：这些值是暂定的，可根据成熟的经验进行修改。注3：物理投递的业务质量见本标准的第12章。15．6差错保护传输中的差错保护由MHs提供并服从在EDI业务规定中所提供的下层协议。15．7业务的可用性原则上EDI业务应是连续可用的。EDI-UA或EDI-MS应能连续用以提交和投递(除非调用保持投递)。在EDI-UA不能连续用于投递的情况下，应使用EDI—Ms。 附录A(规范性附录)术语的词汇表GB／T16520--2011注：下面给出的说明未必是严格的定义。参见附录B中的定义和ITU-TF．400中的词汇表，以及其他的ITu—Tx．400系列标准(尤其是ITU_Tx435)中所定义的术语。这些术语不是来自一个出处，要槐其来源而定。A．1EDI应用(EDIapplication)创建与／或处理EDI消息的一个计算机进程。参见A．13。A．2EDI交换(EDIinterchange)参与方之间按有一定消息和服务段的结构化组的形式进行的消息处理，这个组以交换控制头开始，并以交换控制尾结束。(见ISO9735)A．3EDI消息(EDIM)见本标准第3章中的定义。A．4EDI消息存储(EDI-MS)见ITU—TX．435中3．5的定义。A．5EDI消息处理(EDIME)EDI消息处理包括EDI消息和EDI通知的交换以及相关的规程，这些都是ITu·Tx．435中规定的信息客体。A．6EDI消息处理环境(EDlME)在EDI消息处理所发生的环境可以模型化为称之EDI消息处理环境的功能客体。当细分(即按功能划分)时，则EDI消息处理环境可以看成是由更小的称之为EDI消息处理的主客体组成。它们包括单个中央客体(EDI消息处理系统)和许多称为EDI消息处理用户的外围客体。A．7EDI消息处理业务(EDImessagingservice)把一些特征提供某个EDI消息处理用户有助于与其他EDI消息|处理用户进行通信的一种业务。在许多情况下，EDI消息处理用户都是计算机进程。EDI消息处理业务使用消息传送业务能力，发送和接收EDI消息。描述EDI消息处理业务特性的某些服务要素在附录B中定义，并在本标准的第15章中进行分类。23 GB／T16520--2011A．8EDI消息处理系统(EDIMS)EDI消息处理系统是功能客体，用户通过它在EDI消息处理中进行相互通信。EDI消息处理系统可模型化为相互作用的更小的功能客体组成。这些功能客体称之为EDI消息处理的次客体。它们包括单个中央客体(消息传送系统)三个为数众多的外围客体，即EDI用户体理、EDI消息存储和EDI访问单元。A．9EDI消息处理用户(EDIMGuser)见3．3中的定义。注：在ITU-TX435的情况下．为了简化起见，术语“用户”具有“EDIMG用户”的含义。参见A．13。A．10EDI通知(EDIN)见3．4中的定义。在EDI消息处理中，EDIMG用户可以表求接受者返回一个EDI通知，指出它对收到的EDI消息的安排信息。该通知由发EDI用户代理请求，并由接受者EDI用户代理／消息存储或访问单元生成。可能请求并报告的情况有三种：导致生成肯定通知(PN)、否定通知(NN)或已经转发通知(FN)。这个通知服务用于携带肯定通知、否定通知或转发通知。有可能收到一份不加改变地转发的EDI消息，并把响应通知职责转发给请求的转发接受者或中间接受者，然后接受者对原始发者进行响应。始发uA可请求给予通知，响应通知请求的责任是否已经被转发。在这种情况下，转发EDI消息的uA或MS应给始发UA发送一个EDI已转发通知。在所有情况下，包括EDI消息已经转发到的uA所发送的这类通知，都应包含原始发者规定的接受者O／R名。始发uA可请求来自EDI消息已发送到任意组合的接受者的任意组合的EDI通知。若始发者未请求通知，则接受者什么也不应发送。EDI通知不能被转发，也不能为EDI通知请求EDI通知。A．11EDI消息责任(EDImessageresponsibility)见3．5中的定义。注：EDIM责任是一种连续跟踪手段，用于证实和跟踪EDI用户代理和EDI消息存储中的EDI消息所经过的路线。乱12EDI安全(EDIsecurity)ITU-TF．400／X．400第15章和ITU--TX．402中第10章所规定的MHS的安全能力，这些能力为EDI消息处理系统提供安全特性。EDI消息处理系统的脆弱性及其对策，概述在附录C中。A．13EDI用户(EDIuser)见ITU—TX．435。 GB／T16520—2011EDI用户是一个不一定属于EDI消息处理环境的客体。在消息处理的行文中，很大程度上和EDI消息处理用户等同。A．14EDI用户处理(EDI-UA)见ITU_TX．435中3．5的定义。洼：EDI-UA和EDI消息处理用户两者的界限的确切定义已超出本标准的范围。A．15电子数据交换(EDI)EDI可以定义为计算机对计算机间结构化事务数据(例如发票和购货单)的交换。在ITu—TF．400／X．400系列标准的行文中，EDI指的是采用ITU—TF．435的协议手段和本标准概括的业务来完成交换的标准化方法。A．16GS功能组头。在ANSIX．12中的段名。A．17IEA交换尾。在ANSIX．12中的段名。A．18交换见A．2中的EDI交换。A．19珏A交换头。在ANSIX．12中的段名。A．20MHD消息头。在UNTDI中的段名。A．21sT交易集头。在ANSIX．12中的段名。 (；B／T16520--2011A．22STX在UNTDI中的规定。A．23UNA服务串通知。EDIFACT中的规定。A．24UNB交换头。在EDIFACTK中的段名。A．25UNG功能组头。在EDIFACT中的段名。A．26UNH消息头。在EDIFACT中的段名。A．27UNT消息尾。在EDIFACT中的段名。A．28UNZ交换尾。在EDIFACT中的段名。 附录B(规范性附录)服务要素的定义GB／T16520--2011本附录包含只有EDI消息处理才有的服务要素的定义。在附录不包含适用于EDI消息处理的MT业务的服务要素的定义。这些服务要素的定义包含在ITU—TF．400／x．400的附录B中。标题行中的缩写词PR指的是该服务要素可用于在每个接受者的基础上使用。为了方便查阅，并与消息传送和IPM服务要素区分开，EDI服务要素的编号采用缩写词“EDI．n”B．1应用安全要素EDI．1该服务要素准许始发者和接受者在EDI标题中指出应用安全信息，以支持端对端的安全服务。B．2EDI消息的自动证实EDI．31对于每个投递到某个EDI-MS的请求得到PN的EDIM，EDI-MS用户可以利用该服务要素通知该EDI—MS自动产生一个肯定通知。当EDI-MS用户检索了整个EDIM时，或当用户向EDI-MS指明他认为消息已经被检索时，发送PN消息。该EoS的使用意味着每当自动证实发生时责任将被接受。B．3EDI消息的自动相关EDI．32该服务要素使MS用户可以根据各种相关的EDI消息之间的相关性，检索MS自动产生的信息。下列类型的消息可以是相关的：a)转发(或自动转发)一个EDI消息的EDI消息；b)被接收或被提交的废止一个EDI消息的EDI消息；c)被接收或被提交的交叉引用一个EDI消息的EDI消息；d)被接收或被提交的与一个EDI消息相关的EDI消息。B．4EDI通知的自动相关EDI．33对于以前提交的EDI消息，在收到了作为消息的响应的EDI通知的情况下，MS用户可以使用该服务要素检索MS自动生成的信息。当MS用户或MS为了响应一个被投递的EDI消息而发送了EDI通知时，也可以检索信息。对于一个特定的被提交或被投递的EDI消息，MS对与其相关的每个EDI通知(肯定的、否定的或转发的)进行识别，并且对于被提交的消息，还提供一个接收EDI通知的摘要。B．5字符集EDI．2该服务要素准许始发者在EDI消息的标题中指出EDI信体所用的字符集。B．6交叉参与信息EDI．3该服务要素准许始发者在EDI消息的标题中，指出在一次EDI交换内和该EDI消息或其他EDI27 GB／T16520—2011消息的信体的部分指定的应用参考ID之间所用的交叉参考的信息。B．7EDI转发EDI．4该服务要素使EDI．uA能够有所改变地或不加改变地转发收到的EDIM，并EDI-MS能不加改变地转发到的EDIM。转发时仍需要“EDIN接收方”服务要素的支持。B．8EDI消息类型EDI．5该服务要素准许始发者在EDI消息标题中指出在EDI交换中所包含的EDI消息的类型(例如，发票和购货单等)。B．9EDI通知请求EDI．6该服务要素准许始发EDI—uA请求某个接受者是接受、拒绝还是转发EDIM责任通知给它，对携带这种通知请求消息可以任何组合。始发EDI-UA运送这个请求给接受者EDI-uA／Ms／Au。如果接受者EDI-UA／MS接受该消息的EDIM责任，则它就回送一个肯定通知(PN)，并不再向该消息的始发者返回其他通知。当接受者EDI-UA／MS不接受EDIM责任，并且成功转发内容未加改变的消息时，则转发接受UA／MS，或任一个中间UA／MS，就响应这个请求而言，与第一个接受uA／Ms有相同的责任，并且这个响应应由这个消息的原始发者引起的，给始发者返回一个转发通知(FN)。如果接受者EDI-uA／Ms／Au拒绝该消息中的EDIM责任，或者不能成功转发该消息，它就回发一个带有指出原因的否定通知(NN)给消息的始发者。拒绝消息的EDIM责任的原因如下：a)EDI交换不能传递到EDIMG用户；b)EDI交换不能在规定的时限内传递给EDIMG用户；c)消息在处理前已经废弃；d)在投递后但在响应前已经终止接受者预约；e)尝试EDI转发和EDIM责任转发，但未成功；f)PDAU不能再现消息；g)安全出错；h)未规定的本地原因。在物理投递访问单元中，PN是无意义的。因此返回一个已经转发通知(FN)给始发者以取代PN。否定通知指出该消息将不会到达EDIMG用户，并意指EDIM将不会被EDI应用所处理。因安全政策的关系，消息存储的能力可能受到限制，例如，在请求安全通知时，就不准消息存储生成PN。B．10EDI标准指出EDI．7该服务要素使始发EDI-UA能在一份消息的标题中指出在该EDI消息中正在使用的EDI标准类型(例如，EDIFACT等)。B．11EDI消息标识EDI．8该服务要素使合作的EDI—UA能为每一个已发送或收到的EDI消息运送一个全球唯一的标识符。 CB／T16520—2011该EDI消息标识符由始发者的O／R名和就其名称是唯一的标识符构成。EDI-UA和EDIMG用户使用这种标识符作为前面已发送的或收到的EDI消息的参考(例如，在EDI通知中)。B．12标准EDIM责任转发指示EDI．9该服务要素准许始发EDI-UA指出，可由接受者EDI-UA转发该EDI消息的EDIM责任。B．13EDIM接收方EDI．10该服务要素准许始发者或转发EDI-UA／MS，给接受者指出请求通知应返回到这个O／R地址。B．14日期／时间到期指出EDI．11该服务要素准许始发者给接受者指出始发者认为EDI消息无效的日期和时间。该服务要素的目的是要说明始发者对当前EDI消息可用性的评价。未规定接受者或接受者EDI-UA的特定的动作。可能的动作是在传递的日期到期后存档或删除该EDI消息。B．15不完整拷贝指出EDI．12该服务要素准许一个转发EDI-UA指出转发的EDI消息是一份与始发消息具有同样的EDI消息标识符的不完整拷贝。在不完整的拷贝中，缺少始发EDI消息的一个或多个信体部分。B．16交换头EDI．13该服务要素使始EDI-UA能将EDI交换头的数据要素放人EDIM相应的字段中。B．17多部分信体EDI．14该服务要素准许始发者给接受者发送由几个部分组成的EDI消息信体。每个信体部的特性和属性或者类型，都与信体部分一起运送。B．18始发内容不可否认EDI．15该服务要素使始发EDI-UA能为接受者EDI-UA提供一个不可取消的证明，用此证明是对消息提交到MH环境时的内容确实性和完整性。视现行的安全政策，可用两种方式提供相应的证明数据：a)采用用始发消息“源不可否认”的安全服务}b)采用公证机制。注：使用的公证机制不反映在协议要素中，但服从于双方协定。B．19接收内窖不可否认EDI．16该服务要素使始发EDI-UA能从接受者EDI-UA那里得到一个不可取消的证明，用以证明始发主29 GB／T16520—2011题消息内容已经被接受者EDI-UA接受，且EDIM责任已经被接受、转发或拒绝。该服务提供不可取消的证明，用以证明所接收内容的完整性和消息接受者的确实性。该服务应防止接受者任何尝试否认后续收到的消息内容。因此，该服务强于“接受内容证明”服务。视现行的安全政策，可用两种方式提供相应的证明数据。a)通过返回“EDI通知”的“源不可否认”，它应与下列内容紧密结合：——始发者的“源不可否认”变元(若存在)；——如果不存在“源不可否认”变元的话，则是完整的始发消息内容。b)通过公证机制。注；使用的公证机制不反映在协议要素中，但服从于双方协定。B．20接由内容不可否认请求EDI．17该服务要素使始发EDI-UA能够请求接受者EDI—uA，借助于EDI通知提供给它一个接收消息内容不可取消的证明。注：该服务要素也要求存在“EDI通知请求”。B．21EDl通知不可否认EDI．18该服务要素给消息始发者提供不可取消的证明，用以证明接受者EDI—uA收到主题消息和EDIM责任的接受、转发或拒绝。该服务应防止接受者EDI-UA任何尝试否认后续收到的消息和已按指示那样接受的该消息EDIM责任。该服务要素给始发者提供不可取消的“EDI通知证明”的证明。目前在ITu—TX．402的10．2．5．1中规定的，借助于“源不可否认”安全服务所提供的这种证明，适用于通知。该服务强于“EDI通知证明”服务。B．22EDI通知不可否认请求EDI．19该服务要素与“EDI通知请求”一起使用，使始发EDI-UA能够请求响应EDI-UA提供给它以源通知不可取消的证明。注：该服务要素替代“EDI通知请求证明”，并假定已有“EDI通知请求”。B．23废弃指示EDI．20该服务要素准许始发者给接受者指出，始发者先前发送的一个或多个EDI消息已经废弃。携带该指示的EDI消息替代废弃的EDI消息。接受者或接受者的EDI-UA采取的这种行动是本地的应用。其目的是准许EDI．uA或接受者，例如，去移出或归档一个废弃消息。B．24始发者指示EDI．21该服务要素准许将始发者的身份运送给接受者。 B．25接收内容证明EDI．22GB／T16520—2011该服务要素准许始发EDI-UA能从接受者EDI-UA得到证明，证实始发主题消息内容已被接受者EDI-UA接收，且EDIM责任已被接受、转发或拒绝。相应的证明是通过返回EDI通知的源地址证明获得的，证明包含始发者消息源鉴别和／或内容完整性变元(若有的话)，否则就包含完整的源消息内容。B．26接收内容证明请求EDI．23该服务要素使始发EDI-UA能请求接受者EDI-UA，通地EDI通知提供消息内容已经被接收的证明。注；该服务要素也要求存在“EDI通知请求”。B．27EDI通知的证明EDI．24该服务要素准许消息的始发者获得确证的手段，确切证实主题消息已被接受者EDI-UA接收，EDI-IM责任已被接受、转发或拒绝。借助于“消息源鉴别”安全服务所提供的这种证明，目前在ITU．TX．402的10．2．1．1．1中规定，适用于EDI通知。B．28EDI通知证明请求EDI．25该服务要素与“EDI通知请求”一起使用，使始发EDI-UA给请求响应的EDI-UA提供一个EDI通知源证实。注：该服务要素假定已存在“EDI通知请求”。B．29接受者指示EDI．26该服务要素准许始发者给指定EDI消息的接受者，提供一个或多个EDIMG用户名和DL名。此外，有可能对每个接受者规定动作请求限定符，例如：a)采取行动；b)拷贝；c)其他，按双方规定。注：该限定符表示始发者方面对于EDIM的意图，但接受者不必受这个意图的约束。B．30相关信息EDI．27该服务要素准许始发者将共享同一标识空间(例如IP消息)的一份或多份其他多个消息的全球唯一的标识符与正被发送的EDI消息联系起来。该接受者的EDI-UA，例如，能够从存储器中恢复一个参考消息的拷贝。B．31服务指示EDI．28该服务要素准许始发者在EDI消息标题中给那些双方含义都超出本标准的服务提供者指出各种31 GB／T16520—2011服务的请求。B．32存储EDI消息自动转发EDI．29该服务要素准许EDI-MS用户在接受或不接受EDIM责任的情况下，消息存储拥有自动执行EDI转发通力。EDI-MS用户通过使用“MS登记”服务要素建立选择EDIM的标准，完整的EDIM，同从始发者接收一样，可以不加改变地转发，如果有请求，可由EDI-MS产生一个适当的EDIN。EDIM责任转发只限于一个接受者。转发时，仍需要支持“EDIN接收方”的服务要素。鉴于现行的安全政策的要求，消息存储的能力可能受到限制，例如，在请求安全通知时就不准许消息存储生成PN。B．33合并存储消息的EDI消息的提交EDI．34该服务要素使MS用户可以通知EDI-MS将一个或多个被存储消息部分合并为一个被提交EDI消息的消息体部分。被提交EDI消息也可以包含EDI-MS用户的提交信息中提供的消息体部分。主要的消息体部分将包含一个EDI互换或转发EDIM。作为一个消息体部分的源的被存储消息可以是被投递、被提交或起草的消息。单独的消息体部分或被存储消息的整个内容可以被合并。EDI-MS可以选择性地支持非EDI消息的消息体部分的转发。B．34类型化信体验生活EDI．30该服务要素准许把EDI信体的性质和特性与信体一起运送。可容许的信体部分类型有EDI信体、转发的EDIM信体和外部定义的信体部分。 C．1引言附录C(规范性附录)安全综述GB／T16520—2011本附录详细描述EDIME内标识的各种脆弱性和克服这种脆弱性需要的各种安全服务。本附录基于这样的假设，即EDIME可以使ITu—TF．400／X．400规定的各种安全消息处理服务。对现有的MHS安全服务不能有效克服各种脆弱性的情况，但是ITU-TX．435规定了附加的EDIME安全服务。对EDIME规定的某些安全服务是通用的消息处理特性，其余的则是专为EDIME规定的。对ED-IME规定的安全服务是专用于EDIMG的，全部在ITu—TX．435中规定。c．2脆弱性下面标识的绝大多数范围中也有各种脆弱性及EDI应用级(即EDIMG用户)相应的服务设想。本文提出的安全模型的假设，这种设想超出本标准考虑的内容。EDIMG安全模型假设EDIMG用户能为EDI就用的操作提供足够的安全和可信的功能，足以满足用户对安全政策的要求。注：实际上可能需要EDI应用和EDI-UA共置，除非建立适合两种部件的安全环境。下面对各种脆弱性的描述是以ITu—TX．402附录D中对威胁下的规定为依据的。此外，有必要考虑检查与消息顺序无关的消息丢失和信息修改，同时还有必要考虑ITU_TX．402目前未标识出的各种EDIMG脆弱性。ITU--TX．402内的安全模型未考虑到的EDI环境中的一个重要方面，是在MHS环境中消息通路的每一个阶段消息EDIM责任的概念。在EDI情况中，商业服务提供者有可能要增加若干个，这或许要求明确标识出EDIM责任的转发，无论是对终端用户，还是对这种服务提供者，都要保证提供进一步的保护。因此，需要建立EDIM责任域的概念，这又涉及有关法律问题的其他考虑。EDIME可按下列的一种可能划分EDIM责任域：——EDIMG用户环境加EDI_uA；——MTS管理域；——EDI消息存储(如果与上述两者之一没有共置)。C．2．1假冒按ITU"TX．402附录D的规定。C．2．2消息顺序按ITU—TX．402附录D的规定。用户不应假定EDIMS以正确的顺序投递。只要MHS提供保护，防止消息在MHS环境中信息被修改，EDI应用就应能从消息重复和失序中恢复。C．2．3消息丢失消息丢失脆弱性在EDIMG环境中认为是很严重的。33 GB／T16520—20”两种消息丢失的区别：——灾难性的EDI-UA、EDI-MS或MTA故障；——单个消息的丢失。EDIME用户和服务提供者可能需要更加周密地考虑EDIM责任域问的消息传送问题——来自始发EDI-UA用户域；——中继的各域问；——至接受者ED卜UA用户域。c．2．4信息改变遵循ITU_一TX．402附录D的规定。c．2．5拒绝服务遵循ITU-TX．402附录D的规定。C．2．6否认遵循ITU-TX．402附录D的规定。EDIME环境中的这种否认弱点被认为是很严重的。使用某些MHS服务(倒如，自动转发和改向)时这种弱点还会增加。c．2．7信息的泄漏遵循ITu—TX．402附录D的规定。c．2．8EDIMG用户对信息的处置EDI共同体还附带地标识了另外的一种脆弱性，消息内容的完整性在EDI交换之后被修改(即由始发者EDI-UA和或接受者EDI-UA修改)。这种脆弱性包括的提交不可否认后，始发者本地存储中的消息内容的处理和／或投递的不可否认后接受者存储中的消息内容的处理。C．2．9其他脆弱性ITU_TX．402规定的其他脆弱性认为是很重要的，例如——错误路由的选择；——错误投递(在改向的情况下尤其重要)}——内部威胁；——接受了EDI应用不准备的数据。C．3脆弱性的克服ITL卜TX．402的第10章为消息传送提供了一种抽象的安全模型。这种安全模型提供了一种描述安全服务的框架，这些服务可用于克服MTS内和MTS用户至MTS用户问潜在的脆弱性。还可用ITU—TX．402现有模型之外的安全服务来克服EDIMG脆弱性。下面的章节描述如何使用ITU．。TX．402的安全服务、ITU-TX．435规定的增强型安全服务和本标准规定的各种普遍性机制来克服EDIM脆弱性。C．3．1假冒能克服这种脆弱性现有的MHS安全服务是34 GB／T16520--2011——消息源鉴别；——安全访问管理；——安全标记；——投递证明；——提交证明。由于EDI-UA／MS在MHs结构中被看成是属于一个用户的，所以对EDI-MS可能执行的各种操作都提供选择性的访问控制认为是不合适的。但需要进行安全审计跟踪来记录在EDIMG用户的活动。在本标准中，这种安全审计跟踪可作为普遍性机制来实现。C．3．2消息顺序能克服这种脆弱性现有的MHS安全服务是：——消息顺序的完整性。这种安全服务以始发EDI-uA提供的整数为依据而不保证唯一性或连续性，因此它的作用是有限的。考虑到MHS环境不应要求保证消息顺序的完整性，但应支持顺序完整性故障的检测(通过提供附加的审计日志设施和／或提供第三方公证人服务)。在本标准中考虑从顺序差错和消息拷贝中恢复是EDIMG用户的责任。C．3．3消息丢失消息丢失可能潜在发生在端对端的消息传输链路上(例如，故意破坏活动)或由于任何MHS部件(EDI-UA、EDI-MS和MTA)的故障或不正确的行为(有意无意的)所致。区别下列消息类型的丢失：一灾难性消息丢失(即某部件出故障)；——EDI_Ms中单个消息的丢失无论是有意的还是无意的；——MTs消息丢失。c．3．3．1灾难性故障EDI—UA故障超出本标准的范围。EDI-MS故障可能是灾难性的，需要某种保护，至少需要检测。这要求提供脱机存档来保存提交和投递的全部消息。在本标准中，使用这种存档机制检测并恢复消息丢失是本地的应用。MTS中任何部件出故障也同样可能是灾难性的，这同样可以脱机存档加以保护。至于使用MTS存档机制来存储消息检测并恢复消息丢失是本地的事情，超出本标准的范围。C．3．3．2EDI-MS特定的消息丢失在消息存储中单个消息的丢失(不管是有意无意的)都要求提供安全审计跟踪准许这种丢失进行检测。EDIMG用户和EDI-MS管理需要提供此种服务。在本标准中，安全EDI-MS审计跟踪可作为普遍性机制来实现，并且是本地应用。C．3．3．3MTS特定的消息丢失在MTS中单个消息的丢失(不管是有意无意的)，也都应要求提供安全审计跟踪，对这种丢失进行检测。该机制视现行的安全政策，需以每个MTA和每个MD提供。MTA／MTS审计跟踪可作为一种普遍性机制来实现，并且是本地应用。35 GB／v16520--20llC．3．3．4端对端消息丢失下面的描述假设EDI-uA(包括实现这种功能的有关部件——例如，加密装置)的功能是可信的。现有的“消息顺序完整性”服务不保证检测出消息丢失，因为它信赖于由始发EDI-UA提供的一个整数值。实际上，该服务的有效操作可通过EDIMG用户间的实际通用代码来获得，它超出本标准的范围。因此，可提供消息丢失指示的MHS服务仅限于向始发EDIMG用户提供服务。尽管有的“提交和投递证明”服务提供了某种可信度，若消息没有丢失，则它们不进行端对端操作。尤其是，它们不考虑接受者EDI-UA和EDI．1讧s不是共置的情况。因此，仍需要接受(即通过接受者EDI-UA)服务的证明。用户请求可能安全的EDI通知就可实现，这种能力是由可获得一个EDI通知请求的用户实现的。指出所接受、转发或拒绝的EDIM责任要素的EDI通知包括各种状态，这种要素将通知与主题消息联系起来。在EDIMG环境中，使用现有的MTS安全要素签发EDI通知服务就可提供接受证明。尤其是在EDI通知提交给MTS时，可用EDI—UA到EDI-UA的“消息源鉴别”安全服务来签发EDI通知。在本标准中，EDIMG环境中一种可信形式的EDI通知可提供接受证明。注：该服务在EDIMG中，视提供机制的强度，被称为“EDI通知证明”和“EDI通知不可否认”。在消息提交时，提供该服务的MTS机制在ITU_TX．411的8．2．1．1．1．28“内容完整性检测”中是作为MTS提交抽象操作来定义的。在这种情况下，消息内容是EDI通知。主题消息和回复EDI通知间联系的证明，由主题消息EDI标识符提供。若包括在主题消息中，则有消息内容完整性检验变元。c．3．4信息的修改能克服这种脆弱性现有的MHS安全服务是：——连接完整性；——内容完整性。这些安全服务提供的保护措施足以防止消息内容被修改。还需注意的是，使用双信封(即在外信封上使用加密检验和)可提供附加的保护措施。注：EDI-UA在内容完整性方面是可信的实体。c．3．5拒绝服务对EDIMG用户来讲，这是一种极严重的脆弱性，但超出本标准的范围。C．3．6否认提供保护而防止在EDIMG环境中出现否认现象的各种服务，主要涉及EDIM责任转发的模型。ITU-TX．402规定的安全服务是：——源的不可否认；——提交的不可否认；——投递的不可否认。这些安全服务只涉及EDIM责任域间与传送的某些范围，它在EDIMG环境中是重要的(图c．1所示)。本标准规定的各种服务和／或普遍性机制包括：——传送不可否认证明；——检索不可否认证明；——EDI通知不可否认证明；——内容不可否认证明。36 提交证明EDIM始发者可信的功能性EDIM接受者可信的功能性CB／T16520—201’检索证明EDM责任的传递分界：一安全服务：一一作为本地事宜由普追性机制提供．图c．1EDIM责任传送传送不可否认／证明可反击MTA和／或管理域间责任否认的这种脆弱性。EDIMG环境可提供一种使用附加普遍性机制的服务，例如在MTA和／或MTS界内的安全登录和存档。这些普遍性机制可提供“安全审计跟踪”，记录消息细节和跟踪信息。“检索不可否认／证明”可反击UA和MS间消息否认责任的这种脆弱性。EDIMG环境可提供一种使用附加普遍性机制的服务，例如在EDI-MS内的安全登录和存档。这些普遍性机制可以提供“安全EDI-MS审计跟踪”，EDIMG用户在EDI消息存储中的活动。“EDI通知不可否认／证明”可反击EDI-UA与EDI-UA间EDI通知否认的这种脆弱性。这种服务专用于EDIMG，本标准提供了一种完整的解决办法。除了投递给不可信的EDI消息存储的情况外，在EDI转发和改向等情况下，这种脆弱性特别突出。已为EDI通知不可否认规定了两种机制，第一种机制使用了上述可信的EDI通知，第二种机制使用外部公证系统。本标准只对可信的EDI通知作了全面规定。外部公证系统可能是将来标准化的课题。“内容不可否认／证明”可克服EDI-UA接收消息后EDIMG用户处置信息的这种泄漏。尽管这种泄漏超出MHS环境，但MHS环境有助于指定返回可靠的内容和公证化服务。现有几种方式使用基于1988年提供的安全服务的安全消息处理环境来支持这种要求：第一，始发EDI-UA内容不可否认可由现有的“源不可否认”安全服务提供。第二，通过在EDI通知内返回主题内容，并采用“源不可否认”安全服务将EDI通知提交给MTs，可提供给接受者EDI-UA内容的不可否认。第三，采用公证化服务，通过相互信任的第三方公证人(即采用现有的MHS安全服务)转发消息就可获得这种服务。所有的这三种方法都不需要修改基于现有的MHS建议的安全消息处理环境。注：不可否认的服务(可能涉及第三方)可认为强于“证明”服务。37 GB／T16520—2011c．3．7信息的泄漏能克服这种脆弱性现有的MHS安全服务是：——连接机密性；——内容机密性；——安全访问管理；——消息流机密性。这些安全服务提供充分防止消息内容泄漏的保护措施。还注意到，使用双信封能够提供防止某些业务量分析的保护措施。业务量截获超出这个工作领域的范囝。注：就内容和消息流机密性而盲，UA是可信的实体。C．3．8EDIMG用户对信息的处置使用“内容不可否认”的安全服务可以反击EDIMG用户处置信息。c．3．9其他脆弱性使用“安全访问管理”和“安全标记”可反击其他所有的脆弱性。它也适用于EDIMG环境。此外，还需要审计和记账能力，至少需要“安全审计跟踪”，这可作为普遍性机制，它是本地的事宜。c．3．10其他EDI应用脆弱性在EDIMG环境内，EDI应用本身就可能受到安全威胁的破坏。为了反击这些脆弱性，EDI应用期望产生它自身的安全服务和机制(例如，EDI应用至EDI应用的签名)。这些EDI应用安全服务都是在EDIMS安全字段传送，纯粹作为EDIMG环境内的服务传送要素的信息，并可用于若干的包括消息恢复和不可否认的服务端对端业务。如何使用EDI应用安全服务是本地的事宜。C．3．11概要本附录标识了各种EDIMG脆弱性和使用1988年有关MHS规范克服这些脆弱性需要各种安全服务，还规定了需要的相关服务要素。EDIMG可提供下列附加的普遍性机制：——安全的EDI_I讧S审计跟踪；——安全的MT审计跟踪；——EDI—MS存档；——MTA管理和路由信息的安全性。目前本标准准许使用标准的对称权标和标准的非对称权标。使用可信的公证人系统可能是将来标准化的课题。C．4附加的普遍性机制C．4．1安全的EDI-MS审计跟踪这路设施能监视并记录在消息存储动作上的EDI-UA。它也提供对“检索证明”的支持。本标准极力主张使用安全链或本地的其他安全设施来控制“安全EDI-MS审计跟踪”。在本标准中，“安全EDI-MS审计跟踪”只能作为普遍性机制来实现。上述各种普遍性机制可能是将来标准化的课题。38 GB／T16520—20”C．4．2安全MT审计跟踪该设施能监视并记录所有MTA活动还能提供对“提交证明”、“传送证明”、“投递证明”和MTA安全管理附加的支持。在本标准中，安全MT审计跟踪可以作为普遍性机制来实现。C．4．3EDI-MS存档该机制可用于恢复MS故障，即对所有已提交和投递的全部消息进行安全的脱机存档是潜在有用的。使用该存档机制检测并恢复消息丢失是本地的应用。C．4．4MT存档该机制可用于恢复MTA故障，即对全部消息进行安全的脱机存档。使用该项存档机制检测并恢复消息丢失是本地的应用。 GB／T16520—2011附录D(规范性附录)EDI命名、寻址和号码簿的使用本附录描述的是EDI消息处理业务使用号码簿的情况。虽然任何EDI用户都可以使用号码簿，但本附录只限于EDIMG用户对号码簿的使用。D．1引言本附录描述了EDIMG用户可从号码簿获得功能的情况(如果号码簿可用于EDIMG用户)。如果号码簿不可用，完成本附录所描述的这些功能可看作是本地的应用。本附录包括下列课题：a)在D．2中的EDI命名；b)在D．3中对EDI建议的DIT结构；c)在D．4中的名分析；d)在D．5中的鉴别}e)在D．6中的能力评估。D．2EDI命名EDI用户(贸易伙伴)之间通过实质上是一个任意字母数字字符串的“名”来相互标识。在本附录中，就给EDl名定义成这样一个字母数字字符串。EDI标准机构(例如EDIFACT和ANSIX．12)规定了具体的EDl名的实例。EDl名在一个特定的EDI共同体内通常是唯一的，但在全球范围内，就可能不是唯一的。EDI共同体可有下列三者：a)工业集团(例如CEFIC，EDIFICE)；b)成为一个大公司的专门贸易集团；c)第三方的EDI业务提供者。上述任一个共同体所使用EDl名可采用下列的形式之一：a)由国际公认命名授权机构(例如，DUNS、EAN、SIRET)颁布的形式化名，它是全球唯一的；b)由多国公司发布的形式化名，该名在公司的贸易共同体内是唯一的，多国公司在这个集团内就作为命名授权机构；c)由贸易伙伴自身指定的自由形式化名，仅服从起到命名授权作用的团体的组织和操作者作唯一性的检查。洼：目前，所有这些名字形式，EDIMG用户，都将维持一段时间，最终将向便于的唯一的命名过渡。EDI标准准许有一个限定符合EDl名一起使用。限定符标识了指定和签发字母数字字符串的命名权威机构。使用EDl名和适当的限定符代码可以获得全球唯一的EDl名。在EDl名中不含诸如营运国家的地理成分。EDIMG用户尽可能少地发送带有地址信息的EDI交换。EDl名是一个长期存在的表态实体，不像地址那样可以随时改变。 D．3对EDI建议的DIT结构GB／T16520--2011ITU·TX．521附录B推荐了一些公用命名的惯例和DIT的结构，在DIT结构中，地区、国家和根可以直接位于客体类别组织登录项之上。直接位于根之下的组织表明量个国际组织。在D．2中标识的共同体进行国际间的工作，因此，这些共同体的多数都被归类为国际组织。所建议的号码簿结构是把每个持有EDl名的团体置于某组织之下进行分组，该组织是这些团体(如公司、工业集团和服务提供者)的授权命名机构。在这种情况下，与每个EDl名相关的登录项是一个别名登录项。EDIMG用户的真正登录项在DIT的各个位置上，如D．4中所述。图D．1举例说明一个能适应EDI共同体要求的DIT结构。产生了一个新的类属客体类别“EDI用户”。它的登录项的属性标识了EDIMG用户名、它们存在的范围、EDIMG用户的能力以及按ITU-TX．402中规定的信息处理用户的属性。注：圈n1说明按照ITU_TX．435附录J规定的客体类别EDI用户所表示的信息树D1T。D．4名分析图D．1EDI要求的DIT结构EDIMG用户可以利用号码簿，获得与另一个EDIMG用户相对应的EDI-UA的消息处理的O／R名地址。在ITU-·TX．402的第22章中将此进程规定为“名分析”。为了获得与拥有号码簿名的EDIMG用户相应的EDI-UA的消息处理O／R地址，该EDIMG用户41 GB／T16520—201需把它的号簿名呈现给号码簿，并从号码簿属性中得到消息处理O／R地址。为成功地做到这点，EDIMG用户需向号码簿证实自己，并有权访问所需要的信息。号码簿名可包括相对识别的，EDl名。按ITu·TX．501的附录E的E．1中的规定，可把EDl名认为是“用户友好名”。图D．2与图E．1相类似，说明了EDl名的一个例子。无论何时，EDI-UA需要访问一个EDIMG用户的号码簿登录项时，需要使用DUA业务，它将构建登录项的识别名。该识别名应包括EDl名，发布EDl名组织名或命名的授权机构的组织，如果需要，还包括这些组织所属的国家名。EDIMG用户如何获得EDl名，是本地的应用。EDIMG用户将EDl名传递给EDI-uA，再从EDI_uA应传给DUA。当EDl名是全球唯一时，可从EDl名的限定符中引出组织名，如需要，引出国家名。当EDl名不是全球唯一时，EDIMG用户或EDI-UA应得到组织名，如需要，可通过其他方法得到国家名。围D．2一个别名例子可用别名直接检索一个特定的登录项，例如，为了提取消息处理的O／R地址，用带有组织名和EDl名进入号码簿。图D．2所示，用名(O—Multinational，EU=Inuoicing)标识EDI-UA。也可以用(c=US，0=TcomEDI和EU=Invoicing)标识EDI-UA。两上EDIMG用户名归结为同一消息处理O／R地址(C—US，A=SomeADMD，P—Telco，0一TelecomEDI和CN—Invoices)。图D．3说明，如果此组织不是国际组织，那么使用EDIMG用户也可用名字成分中的国家名来访问。42 D．5鉴别图D．3一个面向国家的别名例子GB／T16520--20¨EDIMG用户可以利用存储在号码簿中的信息完成鉴别。在ITu—TF．400／X．400和ITu—TX．500中规定了其用法。D．6能力评估一个EDIMG用户可以通过号码簿对另一个EDIMG用户的能力进行评估。例如，能力评估准许EDIMG用户决定其他EDIMG用户是否能处理一个特定的版本或发行一份EDI文件。号码簿的下列属性表示了在消息传输业务中的EDI能力。a)标准；b)标准版本；c)标准语法标识符；d)文件类型；e)文件版本；f)文件发行；g)控制代理；h)相关分配码；43 GB／T16520—2011i)EDI字符集。为了评估拥有号码簿名的EDIMG用户的特定能力，该EDIMG用户就要将它的名字呈现给号码簿，并从号码簿属性中请求EDI能力。为成功地做到这点，EDIMG用户应首先向号码簿证实自身，并对请求信息具有访问权。44 GB／T16520—201附录E(规范性附录)交叉参考的综述EDIMG用户需要参考EDI交换内的其他信体部分。例如，EDI购货单可能涉及EDIM或另一消息内另一信体部分包含的附图。服务要素“交叉参考信息”可以用来满足这种要求。该服务要素相当于专门用来设计包含参考信息的EDIM标题字段。EDI用户可任意选择应用交叉参考ID。EDI-UA然后使用EDIMG用户提供的信息将交叉参考ID与全球唯一的信体部分ID配对，并将这两者存人交叉参考标题字段中。信体部分的标识符可以采用不同的形式。如果信体部分包含在EDIM内，它可以是EDIM内信体部分的顺序号。如果信体部分包含在某个其他的EDIM或IP消息内，它将有关EDI消息ID或IP消息ID和信体部分编号拼接起来形成的全球的标识符。EDIMG用户希望信体部分能在与EDI交换中的应用交叉参考互相联系起来，这样它就能使用应用交叉参考ID来对交叉参考信息进行查阅。它找出数据中相应的信体部分ID，并用它来定位并摘取该信体部分。当EDIM用户请求EDI-UA产生EDIM时，就要给EDI-UA提供为创建交叉参考所需的信息。同样，在处理收到的EDIM时，EDIMG用户也可以使用交叉参考数据。为了便于参考，图E．1示出了所提出的机制。在这个例子中，包含附图信体部分2是从主信体部分中EDI交换内引用的，这样就能使购货单中的特定的行项与工程图纸互相联系起来。这里的应用参考ID是“12345”。若EDIM不加改变地或不增加信体部分的转发，则所有的交叉参考信息者有效，最后的接受者EDI-UA可以采取适当的动作。 GB／T16520—20”EDIFACT交换图E．1在EDI消息处理中的交叉参考'