GB T 16651-1996 消息处理系统 电子数据交换消息处理系统.pdf

上传人:ideacase155 文档编号:219458 上传时间:2019-07-13 格式:PDF 页数:114 大小:11.30MB
下载 相关 举报
GB T 16651-1996 消息处理系统 电子数据交换消息处理系统.pdf_第1页
第1页 / 共114页
GB T 16651-1996 消息处理系统 电子数据交换消息处理系统.pdf_第2页
第2页 / 共114页
GB T 16651-1996 消息处理系统 电子数据交换消息处理系统.pdf_第3页
第3页 / 共114页
GB T 16651-1996 消息处理系统 电子数据交换消息处理系统.pdf_第4页
第4页 / 共114页
GB T 16651-1996 消息处理系统 电子数据交换消息处理系统.pdf_第5页
第5页 / 共114页
亲,该文档总共114页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、中华人民共和国国家标准消息处理系统电子数据交换消息处理系统发布实施国家技术监督局发布前言本标准等同采用国际电报电话咨询委员会现国际电信联盟制定的建议消息处理电子数据交换消息处理系统编写格式遵循了标准化工作导则第单元标准的起草与表述规则第部分标准编写的基本规定的规定保留了国际建议的前言同时增加了前言本标准主要包括下列内容信息客体主次客体类型抽象操作主次端口类型用户代理操作消息存储操作消息内容端口的实现一致性本标准的附录至附录为标准的附录附录至附录为提示的附录本标准由中华人民共和国邮电部提出本标准由邮电部电信科学研究规划院归口本标准由邮电部数据通信技术研究所负责起草本标准主要负责人陈淑仪前言国际电

2、报电话咨询委员会负责研究技术的操作的和资费的问题并且为了实现全世界电信标准化对上述问题发布建议每年召开一次的全体会议确定研究课题并批准由各研究组起草的建议在两次全体会议之前的成员可按第号决议年订于墨尔本拟定的程序批准建议建议由第研究组起草并根据第号决议的程序于年月日被批准中华人民共和国国家标准消息处理系统电子数据交换消息处理系统国家技术监督局批准实施范围本标准是有关消息处理对应于的一组标准中的一个这一组标准为由任意个合作的开放系统所实现的消息处理系统提供了一个综合性的规范的目的是让用户在存储转发的基础上交换消息代表一个用户即始发者提交一份消息由消息传送系统运送然后投送到一个或多个用户的代理即接

3、受者访问单元把连接到其他类型的通信系统例如邮政系统用户代理帮助用户制备存储和显示消息作为选用消息存储帮助用户存储消息由若干个消息传送代理组成共同实现存储转发的消息传送功能本标准规定了称为消息的消息处理应用适用于电子数据交换信息交换的一种消息处理的形式和称为的新的消息内容类型和所联系过程设计满足了的用户和其他公共使用的系统用户的要求本标准是有关一系列消息处理标准中的一个建议对该系列作了介绍并标识在该系列中的其他文件消息处理的体系结构的基础和依据在其他标准中定义建议也指明了这些文件引用标准抽象语法记法一的规范信息处理系统开放系统互连抽象语法记法一规范补篇抽象语法记法一的基本编码规则的规范消息处理系

4、统开放系统互连抽象语法记法一的基本编码规则规范消息处理系统与服务综述信息处理系统文本通信面向消息的文本交换系统和业务综述消息处理系统总体结构面向消息的文本交换系统总体结构消息处理系统抽象服务定义的约定面向消息的文本交换系统消息传送系统抽象服务定义与规程消息处理系统编码信息类型的变换规则消息处理系统消息传送系统抽象服务定义与规程面向消息的文本交换系统消息传送系统抽象服务定义与规程消息处理系统消息存储抽象服务定义面向消息的文本交换消息的存储抽象服务定义消息处理系统协议规范面向消息的文本交换协议规范消息处理系统人际消息系统面向消息的文本交换人际消息号码簿概念模型和服务概述信息处理系统开放系统互连号码

5、簿概念模型和服务概述号码簿模型号码簿模型号码簿抽象服务定义号码簿抽象服务定义号码簿分布式操作规程号码簿分布式操作规程号码簿协议规范号码簿协议规范号码簿已选的属性类型号码簿已选的属性类型号码簿已选的客体类别号码簿已选的客体类别号码簿鉴别框架号码簿鉴别框架消息处理系统电子数据交换消息处理业务消息处理电子数据交换消息处理业务电子数据交换用于行政商业和运输业应用级的语法规则定义公用的定义本标准采用了建议和规定的下列术语访问单元信体内容分发表编码信息类型信封消息处理系统面向消息的文本交换系统消息存储消息传送代理消息传送系统物理投递访问单元接受者提交标识符提交时间提要远程信息处理代理用户电报访问单元用户用

6、户代理公用的抽象语法记法一定义本标准采用了所规定的抽象语法一的全部内容服务定义本标准采用了建议所规定的下列术语转发消息通知用户责任其他定义以下列出的术语可与引用标准中的含义有所差别行政商业和运输业的本标准采用了所定义的下列术语确认请求反向路由地址应用参考通信协定成分数据元分隔符数据元分隔符制备的日期时间十进制记法功能组头标识码标识码限定符交换控制参考交换头交换接受者交换发送者消息头处理优先码接受者标识码接受者参考限定符接受者参考口令释放指示符路由地址段终止符发送者标识符服务串通知语法标识符语法版本测试指示符段段段联合国贸易数据交换本标准采用了联合国贸易数据交换语法规则由早期语法建议发展起来的所

7、定义的术语该语法规则是在年月联合国欧洲经济共同体第四工作组一致同意接受的应用参考传输的日期和时间消息头段接受者参考口令传输开始传输优先码传输接受者传输发送者美国国家标准协会定义本标准采用了美国国家标准协会的标准所定义的下列术语授权信息限定符授权信息功能组头交换日期交换头交换接受者标识符交换发送者标识符交换时间段测试指示符交易集头段消息系统定义对本标准而言使用下列定义消息存储消息存储是为通信而设置的专用的消息存储消息系统消息系统在消息时所有用户通过消息处理系统进行相互通信的功能客体用户代理用户代理是为消息处理而设置的专用的用户代理缩略语美国国家标准协会访问单元分发表电子数据交换消息存储用户代理用

8、于行政商业和运输业的电子数据交换消息消息环境消息处理消息用户消息系统通知编码信息类型已转发通知管理域消息处理系统面向消息的文本交换系统消息存储消息传送代理消息传送系统否定通知物理投递访问单元物理投递系统肯定通知远程信息处理代理用户代理联合国贸易数据交换约定术语贯穿本标准的其余部分有关类型的术语都用在类型中的所有字母的大写字母书写例如名定义在主要正文和附录中都出现正文中出现的定义与作为本标准整体的一部分的附录中所出现的定义不一致时应采用附录中的定义记法在建议中定义为了指示的目的本标准采用下列基于的描述约定定义消息的信息客体所有种类的其他数据类型和值自身定义消息的功能客体建议的和宏定义消息的抽象服

9、务建议的和操作以及宏定义协议扩展本标准的宏定义扩展的信体部分类型建议的宏定义自动动作建议的宏定义属性建议的宏标记是隐含贯穿于任何附录中定义的模块在这方面模块是确定的注使用描述一类或一项信息本身并不意味着在开放系统间传送该信息根据描述和的基本编码规则的信息这一事实对它所拥有的具体的传送语法可能是不重要的在系统间实际传送的信息是由一个应用协议中它所包含的信息所指定的表中属性类型的约定本标准采用了下列抽象服务的属性类型定义的约定标有单多值的列可能存在下列值单值的多值的标有由和所支持级的列此处仅指访问的可能存在下列值必备的任选的标有在已投递中存在在中存在在中存在和在中存在的列用下列的其中一个值来描述存

10、在的每个属性类型在登录项中总是存在因为它由生成是强制性的或者在相关抽象操作中是强制性的或是默认的参数在登录项中有条件地存在因为它由支持并由用户签署且曾出现在相关操作中的可选的参数内否则总不存在标有可用于列表提醒和可用于综述的列可能出现下列值非是表中属性类型的约定本标准采用下列抽象服务的属性类型定义中的约定标有由生成的源的列可能出现下列值消息投递的抽象操作消息存储报告投递的抽象操作信息客体在消息中有两类用户交换的信息客体消息和通知注消息用户用户通常是一个应用或计算机进程而不是人为简洁起见贯穿本标准的其余部分术语用户具有用户的含义公用数据类型几种信息项在消息和通知中都出现这些公用项的定义如下标识符

11、标识符是无二义性全球性和永久地唯一标识的信息项它由一个名和一个字符串组成这个字符串可包含例如一个时间或一个序列号或者其它使这个具有唯一性的足够信息注名按在建议的中定义标识符与建议定义的标识符共享同一个数值集合因此能处理和能力的用户代理或消息存储需确保和两者的本地参考是唯一性的标识符具有下列成分用户标识起始的用户用户中的一个相关用户标识符为无二义性的标识将始发用户成分所标识的用户与所有其它的用户区分开这是一个从零到规定字符数目的可打印字符串见附录不鼓励使用长度为零的字符串扩展提供允许将来对本标准扩展的机理一个扩展字段对可接受的责任能被标记为关键性的置成或非关键性的置成对责任标记为非关键的扩展可以

12、被省略或废弃而对一个的可接受的责任标记为关键性的扩展必须被知道和被执行注术语责任按建议的中定义贯穿本文的术语责任指的是建议定义的术语而不是指日常所用的词作为支持扩展的将来定义的记法定义消息消息是在消息中用户间运送主信息客体类的一个成员注贯穿本标准其余部分的术语消息是在上下文允许的情况下与消息同义消息由下列成分组成标题一套标题字段或一套字段每个信息项都给出消息的一个特性信体一个或多个信体部分的序列注外部定义的信体部分按中定义信体部分按中定义信体部分按中定义信体有一个包含有信息客体的主信体部分这个信体部分既可以是交换的本身也可以是已转发信息客体的类型实例是电子数据交换用于行政商业和运输业联合国贸易

13、数据交换和美国国家标准局定义的交换注信息客体类型的范围是相当大的可包括例如专用定义的类型为简洁起见贯穿本标准其余各部分术语交换意指交换下列规则遵守在建议的中陈述的要求首次创建时主信体部分应包含有一个信体部分转发时它的结构应遵守中给出的规则在消息中可以出现与主信体部分有关但与主信体部分类型不同的其它信体部分相关信体部分的范例可以是连同该交换的正文信息话音注释或图形消息的结构描述在图中图消息结构标题字段的成分类型在整个标题中出现若干类型信息项这些公用项在下文中定义在以下正文中为段和数据元作出了参考附录阐明与和的关系从数据元复制并以串表示的值与用于和形成的数据元字符在语义上是等价的交换接受者发送者交

14、换接受者的字段和交换发送者的字段有几种公用的数据类型它们的定义如下标识码标识码能标识一次交换的发送者接受者它和段的交换发送者接受者的发送者标识接受者标识成分在语义上是等同的标识码限定符若存在标识码限定符则是发送者接受者的标识码的限定符它和段的交换发送者接受者的标识码限定符成分在语义上是等同的路由地址若存在路由地址这是一个对标识码中所规定的发送者接受者进行路由选择的地址它和段的交换发送者接受者的用于反向路由路由地址的地址成分在语义上是等同的标题字段可出现在标题中的字段的定义和描述如下注从标准推出的标题字段名称直接取自相关的标准参见附录本本字段能标识该它包含一个标识符该标识符为提供了一个全球性和永

15、久性的唯一标识注标识符在中定义始发者标识的始发者它包含一个名若接收时在标题字段中不存在始发者字段则投递信封的始发者名被用来确定的始发者见建议的注名在建议的中定义接受者接受者字段能标识优选接收者的一个或多个用户和分发表它包含一组接受者子字段每个接受者有一个接受者子字段若在接收时在标题字段中不存在接受者字段则投递信封的这个接受者名被用来确定的接受者见建议的注消息能被改投或转发的事实反映在上述的优选一词中接受者子字段是一个信息项它能标识的接受者并可查明接受者的请求接受者子字段具有下列成分接受者接受者能标识所述的那个优选接受者它包含一个名注名在建议的中定义动作请求动作请求指明起始者向接受者请求的是什么

16、动作它的值是一个客体标识符下列标准值具有在本标准中定义的客体标识符动作拷贝无该字段应解释为默认值设置为注这个字段的附加值能由任何有关的参与方作出定义通知请求通知请求成分默认无通知无通知安全和无接收安全可通过接受者字段查明标注优选接受者的要求注消息能被改投或转发的事实反映在上述优选一词中通知请求字段由三个选用的位串序列组成第一个位串选择通知的类型第二个位串选择对这个通知应提供何种安全功能第三个位串可查明接受者对这个的证明或不可否认接收作出某些安全要求若不请求通知就不应请求通知安全和接收安全通知请求位串可假设同时有下列任何值按第章中规定的环境中请求可接受责任的通知按第章中规定的环境中请求消息责任的

17、拒绝通知按第章中规定的环境中请求已转发通知无通知请求位串意味着未作通知请求通知安全位串可假设同时有下列任何值为响应通知请求提交一个后随这些值中的每一个值的设置要求按下面指出证明把提交给时按建议的中的定义在消息提交变元中应请求内容完整性检验不可否认把提交给时按建议的中的定义在消息提交变元中应请求内容完整性检验并带有不可否认证明无通知安全位串意味着未作通知安全请求接收安全位串含义不作通知安全请求接收安全位串可假设同时有下列任何值为响应通知请求提交一个后随这些值中的每一个值的设置要求按如下指出证明把提交给时应请求内容完整性检验可能在消息权标中或消息源鉴别检验视现行的安全政策通知应包含安全要素并签名提

18、交给采用消息变元中内容完整性检验可能在消息权标中或消息源鉴别检验视现行的安全政策按建议的和中的定义不可否认把提交给时应请求不可否认内容完整性检验可能在消息权码中或消息源鉴别检验视现行的安全政策通知应包含安全要素并签名提交给采用消息提交变元中不可否认内容完整性检验可能在消息权码中或消息源鉴别检验视现行的安全政策按建议的和中的定义无接收安全字段意味着未作接收安全请求注只有在支持保密消息时安全服务才是有效的允许责任传递允许责任传递字段指出若这个字段被置为则允许转发责任无该字段应解释为值允许责任传递字段置为的消息接受者应按请求始发并不应有转发责任若允许责任最多可被转发给一个接受者交换接受者交换接受者能

19、标识交换接受者它和段的交换接受者在语义上是等同的注上述字段按中的定义接受者参考接受者参考能标识接受者的应用是一个有意义的参考它和段的接受者参考口令在语义上是等同的它由两个字符串组成交换控制参考指出交换控制参考按交换发送者指定它和段的交换控制参考在语义上是等同的处理优先码指明应用的处理优先码它和段中处理优先码在语义上是等同的它由一个字符串组成确认请求确认请求指出由交换发送者指明确认的请求它和段中确认请求在语义上是等同的确认请求的值是布尔型值指明对确认的请求无这个字段应解释为值通信协定标识符通信协定标识符指出控制交换通信协定的类型例如定制的或其他协定它和在段中通信协定标识符在语义上是等同的测试指示

20、符指出该交换是一次测试它和段中测试指示符在语义上是等同的测试指示符是布尔型值指明该交换是一次测试无这个字段应解释为值授权信息授权信息指出谁授权交换它和在交换中授权信息在语义上是等同的注在上述文本中参考是由段和数据元组成附录是关于其它两个正广泛使用的和语法的解释在应用交叉参考字段中所采用的字符集由信体部分类型的字段值指出接受者扩展接受者扩展包含接受者子字段的扩展在本标准中没有定义扩展接收方指出谁是被发送的接收方若请求通知的接受者与消息的始发者不同则由始发者创建该字段接受者由名标识符和首接受者的序列组成若未作通知请求则不应存在该字段当转发用户代理或消息存储转发责任时接受者字段应出现在已转发消息中当

21、转发接受责任则出现该字段与该字段结构有关的规则在中给出注为简洁起见贯穿本标准其余各部分用术语用户代理意指贯穿本标准其余各部分用术语消息存储意指若有一个以上的接受者子字段包含通知请求则不应存在首接受者字段当主信体部分是一个信体部分时即当原始发者首次创建时不应存在原始标识符和首接受者字段注为了允许接受者为已转发构建需包括原始标识符和首接受者字段有关结构的规则见更具体的情况见和构建已转发时有关首接受者字段的规则见名按建议的中的定义首接受者字段按中的定义已转发责任已转发责任字段用来指示责任是否已被转发无该字段应解释为值若这个字段值则指出接收的已转发责任若这个字段值为或是缺省则向接收的指出已检验内层信封

22、的安全要素根据现行的安全政策可在消息已被转发时安全要素可能已进行了检验而在接受责任时应检验安全要素注有关这个字段使用的规则包含在和中信体部分的类型指出在主信体部分中采用的标准和字符集信体部分的类型用单个客体标识符表示下列标准值具有在本标准中定义的客体标识符建议建议建议专用未定义无该字段应解释为默认值设置成注由客体标识符所指出的字符集无论是在信体部分中的和是以及从交换得出的标题字段中的都是被编码的而不管这些类型是作为定义的事实信体部分字段的值被用于抽象操作根据的编码信息类型中它可让给发信号报知的主信体部分遵守何种类型的标准若接受者已经在编码信息类型上登记投递限制则利用该信息确定它能否投递注术语编

23、码信息类型按建议的中的定义参见建议的不完全拷贝不完全拷贝字段指出已转发是的一个不完全拷贝它的值是布尔型当转发时若信体部分被去除则该字段具有值无该字段应解释为有值注术语已转发在中定义期满时间指示始发者认为本失去其有效性的时间它包含日期和时间协调通用时间相关消息能标识本的始发者认为与它相关的消息或其它例如它包含一个或多个消息参考序列每个相关消息有一个消息参考注若相关消息能标识取自其它业务的消息则必须出现消息标识符标符的用户成分在标识符字段中可携带与不同的其它业务类型的参考消息的消息标识符值废弃废弃字段能标识当前已废弃了一个或多个它是一个子字段序列每个子字段有一个标识符应用安全要素应用安全要素字段准

24、许一个应用得以交换有端对端意义的安全要素交叉参考信息交叉参考信息准许一个应用得以参考同一个内和其他内的单个信体部分它由一组交叉参考数据组成交叉参考信息的用途超出本标准范围若无消息参考则参考当前一个消息注信体部分参考按中定义消息类型指出在交换中所出现的消息类型它由一组独特字符串组成注消息是被理解为在标准中定义的消息类型不要与本标准其余各处用消息相混淆这个字段的值应是来自段的消息类型来自段的交易集标识符来自段的消息类型服务串通知指出交换的服务串通知它和交换的服务串通知在语义上是等同的语法标识符指出所用的语法它和段的语法标识符在语义上是等同的它由一个语法标识符和语法版本的序列组成交换发送者指出交换的

25、发送者它和段的交换发送者在语义上是等同的注上述字段按中的定义制备的日期和时间指出制备的日期和时间它是以时间表示并可从段的制备的日期和时间得到的它包含一个时间应用参考为一个应用或功能提供一般参考它和段的应用参考在语义上是等同的它由一个字符串组成标题扩展标题扩展允许将来对标题的扩展在本标准中定义的标题没有扩展注标题扩展可用于实现在建议中定义的服务指示的服务要素信体部分类型可在信体中出现的信体部分的类型的定义和描述如下信体部分一个信体部分携带单个交换所用的交换的参考定义是所用的交换的参考定义附录描述了在其他标准中的同等术语信体部分信体部分包含一个和可选用的它的投递信封它被用于的转发当转发一个时信体部

26、分的结构应遵守在中给定的规则注主信体部分按第章中的定义信体部分参考按第章中的定义消息投递时间和其他消息投递字段按建议的中的定义信体部分位置保留区仅用于信体部分的去除信体部分可以仅由信体部分参考组成或是一个已修改的外部定义的信体部分在后者情况下保留客体标识符和已去除信体部分的信体部分参考对已去除信体部分的参数如存在和数据区而言仅保留客体标识符和的编码字段标识符的八位组即类型具有一个无内容长度为零的编码字段若调用安全服务则应出现投递信封信体部分的结构在图中描述图信体部分结构外部定义的信体部分与主信体部分有关的附加信体部分可以和信体部分一起传送附加信体部分不应是或不包括交换附加信体部分是由外部定义并

27、由信体部分携带的客体标识符所指明的语义和抽象语法来表示信息客体它们具有参数和数据成分并可选用为交叉参考信体部分而用的信体部分参考创建信体部分时指定信体部分参考并且以后不作修改若始发者在创建时或在将来想要有信体部分的交叉参考则应出现信体部分参考注某些外部定义的信体部分类型按建议的中的定义通知通知是在消息中用户间运送次信息客体类的一个成员注贯穿本标准的其余部分所用的术语通知为通知的同义词肯定通知报告的始发者可接受的责任的否定通知报告的始发者拒绝接受责任的已转发通知报告的责任已与主题一起被转发的和一个有关的被称为主题参见的接受者是主题的始发者或者若要存在的话则在接收方字段中指明名一个应最多规定一个接

28、受者请求通知的每个接受者为每个主题最多始发一个或除遵守的同一个在继后再始发一个之外当且仅当请求通知时由每个转发的接受者始发一个按照的规定不管可能被转发多少次原始发者对每个请求通知的接受者最多只能接收一个或但原始发者可以接收多个由肯定否定或已转发的通知字段组成每个通知字段包含以下描述的公用字段的结构在图中描述公用字段公用字段的定义和描述如下注在肯定通知否定通知或已转发通知字段中出现的公用字段在下面定义图通知结构主题主题标识符是在责任已被转发时接受者字段中传递的标识符或者是在责任未被转发时本字段中传递的标识符注标识符按中的定义主题按第章中的定义通知的始发者通知的始发者包含有构造通知的的名注名按建议

29、的中的定义首接受者首接受者字段包含有在转发链中首接受者的名首接受者字段与其他字段一起由通知接受者用来使通知与始发消息相互关联注名按建议的中的定义若的始发者不是原始发者规定的接受者则在中应出现首接受者字段见详见通知时间通知时间包含有以格式表示的日期和时间在这一时间生成主题通知安全要素安全要素字段用来提供接收内容的证明不可否认和应用安全服务注应用安全要素字段按中的定义内容和内容完整性检验分别按建议中的和中的定义只有当运行保密消息时安全服务才是有效的描述了这些字段是如何填写的发起者发起者字段可取下列值之一内部的意指生成的既可以是本地原因也可以由用户已委托给的生成内部的意指生成的既可以是本地原因也可以

30、已由用户已委托给的生成外部的意指用户通过始发抽象操作见请求的生成始发肯定通知意指不管该字段取何值已接受责任这个字段的值应与和的原因码字段的选择用户一致注物理投递访问单元在中的定义通知扩展通知扩展允许将来对的扩展在本标准中定义的没有扩展在中的扩展不应是关键性的肯定通知的责任已被接受时当且仅当始发者请求通知由接受者发送肯定通知构成可接受的响应的实际步骤是本地的事情例如可以在消息刚传递给用户时立即构成或可从用户处等待一个已接受到消息的外部激励后再发送肯定通知字段定义和描述如下补充信息补充信息字段给接受者返回进一步的信息以阐明肯定通知注补充信息字段在中的定义肯定通知扩展肯定通知扩展允许将来对扩展在本标

31、准中定义的没有扩展在中的扩展不应是关键性的否定通知确定它既不能接受责任也不能把和包含在中的通知请求转发给另外的时当且仅当始发者请求一个通知由发送否定通知否定通知字段的定义和描述如下否定通知的原因否定通知的原因指出主题不能由始发的传递给用户的理由可在任意组合的诊断字段或补充字段中携带附加信息是否出现安全差错诊断码视现行的安全政策而定来自或否定通知的原因码来自或否定通知的基本原因码这些代码是那些在建议的附录中为服务要素通知请求所规定的代码来自或否定通知的诊断码来自用户否认通知的原因码来自用户否定通知的基本原因码来自用户否定通知的诊断码来自否定通知的原因码来自否定通知的基本原因码来自否定通知的诊断码

32、补充信息补充信息字段给接受者返回进一步的信息以阐明否定通知注补充信息在中定义否定通知的扩展否定通知的扩展允许将来对的扩展在本标准中定义的没有扩展在中的扩展不应是关键性的已转发通知确定它不能接受责任并决定转发且通知请求包含在该中时当且仅当始发者已请求一个通知则由发送已转发通知到另一个已转发通知字段的定义和描述如下已转发至已转发至字段指出已转发主题的新的接受者它的值是一个名注名按建议的中的定义已转发通知原因已转发原因码指出转发主题责任的理由可在任意组合的诊断字段或补充信息字段中携带附加信息来自或的转发通知原因码来自或的转发通知的基本原因码来自或的转发通知的诊断原因码来自或的转发通知的安全检验码可用

33、带有值的这个字段指明出现的所有的安全特性已有效或用带有值的这个字段指明安全特性已无效来自用户的转发通知的原因码来自用户的转发通知的基本原因码来自用户的转发通知诊断码来自的转发通知原因码来自的转发通知的基本原因码来自的转发通知的诊断码物理投递访问单元见只能生成和可省略通知的任何请求若请求通知并且始发者允许传递责任当确定它能为物理投递呈现时应生成具有相应已转发原因码为物理呈现和投递的已转发的若请求通知并且始发者不允许传递责任不能为物理投递呈现时则应对此要求生成补充信息补充信息字段可给的接受者返回进一步的信息以阐明已转发通知注补充信息字段在中的定义已转发通知的扩展已转发通知扩展允许将来对的扩展在本标

34、准中定义的没有扩展在中的扩展不应是关键性的主客体类型消息处理环境可被模型化为一个抽象客体今后把这种抽象客体称作消息处理环境再细分时即功能分解可被看成通过端口相互作用的更小客体组成更小客体被称为消息的主客体主客体包括单个的中央客体消息处理系统和多个称为消息系统用户用户的外围客体的结构在图中描述图消息环境主客体类型的定义和描述如下主客体类型之间的相互作用所使用的端口类型在第章中讨论消息用户消息用户用户是参与消息的一个典型计算机进程或应用这些进程或应用在本标准中称为术语用户用户始发接收或既发送又接收的信息客体类型在第章中定义由任意数目的用户组成注消息处理是信息处理系统间的一个典型活动它们被称为应用这

35、并不排除人与实现消息处理系统间相互作用的可能性即人类用户与更直接的相互作用的可能性对本标准内的术语用户和用户可视为与应用的同义为简洁起见贯穿本标准其余部分的术语用户都具有用户的含义消息处理系统消息处理系统是所有用户通过客体在消息处理中互相通信的客体只由一个组成主端口类型消息的主客体是通过端口彼此联系并相互作用提供的这些端口被称为消息处理的主端口下面定义了主端口的类型管理口的规范可服从于将来的标准注在后面的第章中可被分解为还要小的客体其中有事实是期望在这里抽象服务中包括某种能力始发口始发口是单个用户把包含在第章中定义的信息客体类型的消息运送到时所通过的使用的方法用户通过始发口始发消息和通知此外用

36、户也可通过这样的端口始发探查给每个用户提供一个始发口通过见服务的间接用户除外接收口接收口是把包含在第章中定义的信息客体类型的消息运送给单个用户时所通过的使用的方法通过接收口用户接收消息和通知此外用户也可通过这样的端口接收报告对每个用户提供一个接收口抽象操作下述情况定义了表示消息的特征的抽象服务并描述提供和使用这种服务的环境两者都采用了建议抽象服务定义的约定抽象服务是通过一个始发口和一个接收口提供给每个用户的能力的集合这些能力按照抽象操作模型化这些抽象操作调用时可能遭遇到抽象差错抽象服务定义的目的并非是描述用户和间的界面而是阐明第章中信息客体的含义和预期用法用户界面不必以一对一地对应于服务的抽象

37、操作方式提供命令确实也不需要服务所做的那样均匀分配用户和间的工作在始发口和接收口可用有效的抽象操作的定义和描述如下它们可能引起的抽象差错是第章的主题抽象服务调用既不包含有抽象合接操作也不包含有抽象分接操作给用户提供抽象服务之前对典型用户进行鉴别即确定身份用这种方法能核实用户例如用户是一个用户要求的鉴别在抽象服务定义中是隐式的而不是显式的注在后面的第章中可分解成多个客体其中有一个是此文本用它在抽象服务中包含各种定义的信息项来反映这个事实始发抽象操作用户调用在始发口可用的抽象操作并由执行始发探查始发探查的抽象操作对有关内容是的消息或其中某一类消息始发一个探查这个抽象操作具有下列变元信封探查提交的信

38、封补充了抽象服务定义提供除用户提供的下列信封成分外的全部信封成分所期望的每份消息在选项即每份消息指示符和扩展优选接受者的名和每份信封所期望的每个接受者任选项即始发者报告请求显式转换和扩展内容可投递性将被探查的哪一类的一个实例这个抽象操作有下列结果提交标识符对探查分配的探查提交标识符提交时间直接提交探查的日期和时间始发始发抽象操作始发一个内容是的消息这个抽象操作具有下列变元信封消息提交信封补充抽象服务定义提供除用户提供的下列信封成分外的全部信封成分所期望的每份消息任选项即优先权每份消息指示符延时投递的时间和扩展优选接受者的名和每份信封所期望的每个接受者任选项即始发者报告请求显式转换和扩展内容被始

39、发的若要求应用对应用安全服务则用户应提供应用安全要素字段值应具有中描述的结构这个抽象操作具有下列结果提交标识符对提交分配的消息提交标识符提交时间直接提交消息的日期和时间始发始发抽象操作始发一个内容是的消息若请求通知用户可以调用始发抽象操作指明对主题的接受拒绝或转发责任由内容变元确定生成的确切类型或仅由指向主题的实际接受者始发的它是借助于主题的接受者字段的通知请求字段来请求的用户可把生成的任务委托给在这种情况下这个抽象操作不出现在和用户抽象界面处即在始发口的操作是无用的此时作用与中描述一样这个抽象操作具有下列变元信封消息提交信封补充抽象定义提供除用户提供的下列信封成分外的全部信封成分所期望的每份

40、消息任选项即优先权每份消息指示符和扩展应禁止隐式转换和延期投递优先权应是主题期望的优选接受者的名和每个接受者任选项即显式转换和扩展的优选接受者是主题的始发者或者若存在的话则在接受者字段中指明名内容被始发的若要求应用对应用安全服务则用户应提供应用安全要素字段值应具有中描述的结构这个抽象操作具有下列结果提交标识符对提交分配的消息提交标识符提交时间直接提交消息的日期和时间接收抽象操作在接收口可用的抽象操作由调用并由用户执行按抽象定义对已接收消息不提供存储因为无论是否提供存储对一个特定用户与其他用户的消息用户能力没有影响因而提供存储的与否是本地的事情接收报告接收报告的抽象操作接收一个报告报告可涉及下列

41、任一个报告的接受者始发接收前的情况用始发抽象操作始发内容是一个的消息或者通过转发始发内容是一个内容的消息前面已接收消息的结果作为始发内容是一个的消息可以是或中的一个用始发探查抽象操作始发有关内容是一个消息的探查这个抽象操作具有下列变元信封报告投递信封补充抽象服务定义未投递客体处于正在被报告状态消息的内容它是一个或若报告是由调用早先的始发探查抽象操作引起的应无该条件的变元若报告是由调用早先的始发抽象操作引起的当且仅当要求返回内容时应存在该变元否则例如若报告由引起的应无该变元这个抽象操作没有结果接收接收抽象操作接收内容是一个的消息这个抽象操作具有下列变元信封消息的投递信封内容消息的内容是这个抽象操

42、作没有结果当已接收包含有一个信体部分即始发已被转发时它必须搜索若干个层的嵌套的标题字段以便为可选用的标题字段决定正确的始发值见的已转发的嵌套的结构和的有关标题字段的规则接收接收抽象操作接收内容是一个的消息是由始发抽象操作始发引起的这个抽象操作具有下列变元信封消息的投递信封内容消息的内容是这个抽象操作没有结果抽象差错下面定义和描写了可以报告抽象差错为响应在始发口和接收口可用的抽象操作调用或者把它们作为抽象服务定义的一部分下面表示的抽象差错的集合作为解释性的但不是详尽的接受者被不恰当的指定接受者被不恰当的指定的抽象差错报告了一个或多个名是无用的这些名是被提供作为执行被中断的抽象操作的变元或者它的变

43、元的成分这个抽象错误由抽象服务定义其他能力除上面定义的体现在抽象服务的能力外将对每个用户透明地扩充到具有下面指明的其他见建议和见建议的能力列举这些能力必定为事先处理第章中所陈述的事实和是处在的组成部分中的应提供下列附加能力提交未体现在抽象服务中的或提交口的能力例如若选择了延期投递就消除了前面始发内容是而不是的消息投递能力投递未体现在抽象服务中的的投递口的能力例如暂时地控制向用户的运送信息客体类的能力管理或的管理口的能力检索检索口的能力除上述的能力外作为本地的事情可给用户提供未在本标准中定义也不受本标准的限制的其它能力号码簿的能力也在其中注纯粹出于实用的理由上述所需能力被排除在抽象服务形式定义之

44、外特别是因为他们所包括的内容是相当丰富的因而也没有必要重新作出基于这些能力的和抽象操作的定义次客体类型可模型化成更小的客体它们彼此通过附加的端口相互作用这些更小客体被为称为消息处理的次客体次客体包括单个的中央客体和多个外围客体消息处理系统用户代理消息处理系统消息存储远程信息处理代理和物理投递访问单元协议的规范是将来标准化的课题的结构在图中描述如图所示和是借助于它们给用户提供抽象服务的工具图消息处理系统次客体类型的定义和描述如下次客体类型通过端口类型相互作用的它们在第章中讨论上述细化包括了所有可能的客体的所有可能的相互连接它不忽略特定的类型例如的客体可能不存在的情况和的具体逻辑配置后者在建议中标

45、识提供进口和出口然而由于这些端口不是作正式定义的在建议中因此进口和出口也不包括在上述正式细化中用户代理用户代理是一种剪裁成更适于单个用户参与消息处理的它帮助用户始发接收或既始发又接收消息该消息包含有在第章中定义的信息客体类型由任意多个组成注如上所注贯穿本标准用的术语用户代理意指消息存储消息存储是一种剪裁成更适于单个用户参与消息处理的它帮助提交提取投递及既提交又提取投递消息该消息包含在第章中定义的信息客体类型由任意多个组成注如上所注贯穿本标准用术语消息存储意指远程信息消息代理远程信息消息代理帮助单个间接用户从远程信息终端参与消息处理的这种终端和网络一起把两者连接帮助用户始发接收或既有始发又有接收

46、报文该消息包含在第章中定义的信息客体类型这个的协议规范是将来标准化的课题物理投递访问单元在本文中物理投递访问单元借助于物理投递系统帮助任意数目的间接用户参与消息处理它帮助间接用户接收而不是始发消息该消息包含的信息客体类型在第章中定义由任意数目的组成使用进口和出口然而由于这些端口没有正式定义在建议中因此进口和出口也不包括在上述正式定义的中若请求通知应生成下列中的一个若确定它能呈现和投递则应生成具有相应原因码的若确定它不能呈现和投递则应生成具有相应原因码的的使用应服从现行的安全政策的要求消息传送系统在本文中消息传送系统在和间运送的信息客体类型在第章中定义由一个单独的组成的使用受现行的安全政策的限制

47、次端口类型消息的次客体是通过端口彼此联系并相互作用由和提供的这些端口称为消息处理的次端口次端口具有下面标识的类型在一个提交口一个检索口和一个管理口所体现的能力构成抽象服务抽象服务在建议中定义在一个提交口一个投递口和一个管理口所体现的能力构成抽象服务抽象服务在建议中定义注借助于监视其端口的抽象合接操作或在给这个客体提供它的抽象服务前一般要鉴别另一个次客体提交口在本文中提交口是直接或间接地或直接地提交涉及在第章中所定义的信息客体模型的探查和包含在第章中所定义的信息客体类型的消息时所通过的端口给它的提供一个提交口给每个没有配置的和每个提供一个提交口投递口在本文中投递口是或提取投递涉及在第章中所定义的

48、信息客体类型的报告和包含在第章中所定义的信息客体类型的消息时所通过的端口给每个没有配置的或每个提供一个投递口检索口在本文中检索口是检索涉及在第章中所定义的信息客体类型的报告和包含在第章中所定义的信息客体类型的消息时所通过的端口给它的提供一个检索口管理口在本文中管理口是改变本身有关的信息或的用户用它的改变在文件上的信息时所通过的端口或者或通过该口用改变在文件上的此类信息时所通过的端口给它的提供一个管理口给没有配置的每个和每个提供一个管理口进口在本文中进口是输入涉及第章中所定义的信息客体类型的报告探查和包含在第章中定义的信息客体类型的消息时所通过的端口给每个提供一个进口出口在本文中出口是输出涉及第

49、章中所定义的信息客体类型的报告探查和包含在第章中所定义的信息客体类型的消息时所通过的端口给每个提供一个出口用户代理操作必需以特定的方式使用以便为的用户正确地提供抽象服务若用户配备有则由提供抽象服务因此服从于的相同规则指配和的操作规则是下述的课题的操作超出本标准的范围注下述的目的并非是对一个真实的实施作出不必要的规定或限制而是规定要达到的效果始发操作的执行应执行如下描述的抽象操作使其在的始发口有效在执行这些操作中调用抽象服务的下列抽象操作下述情况未对操作的源作出限制探查提交消息提交在这些抽象操作调用的响应中报告相应的抽象差错每个抽象差错应被报告准确环境的规定超出本标准的范围始发探查应通过调用具有下面指出变元的探查提交并把下面指出的结果返回给的用户执行始发探查的抽象操作探查提交的变元应按如下所述信封构成每个探查字段的这个变元的成分应按如下所述下面未明确提及的这些变元的成分应按始发探查的信封变元的规定始发者名用户的名内容类型

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 标准规范 > 国家标准

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