RFC3921
出自Jabber/XMPP中文翻译计划
跳转到: 导航, 搜索
本文的英文原文来自RFC 3921
网络工作组 | Saint-Andre, Ed. |
申请讨论: 3921 | Jabber软件基金会 |
类别: 标准跟踪 | 2004年10月 |
| |
可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息
关于本文的说明
本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD 1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。
版权声明
本文版权属于互联网社区 (C) The Internet Society (2004).
摘要
本文定义了可扩展消息和出席信息协议（XMPP）的核心功能的扩展和应用，XMPP提供了RFC 2779 定义的基本的即时消息和出席信息功能。
目录 [隐藏] ∙ 1 绪论 o 1.1 概览 o 1.2 需求 o 1.3 术语 ∙ 2 XML 节的语法 o 2.1 消息语法 ▪ 2.1.1 消息的类型 ▪ 2.1.2 子元素 ▪ 2.1.2.1 主题 ▪ 2.1.2.2 主体 ▪ 2.1.2.3 线索 o 2.2 出席信息语法 ▪ 2.2.1 出席信息的类型 ▪ 2.2.2 子元素 ▪ 2.2.2.1 展示 ▪ 2.2.2.2 状态 ▪ 2.2.2.3 优先权 o 2.3 IQ语法 o 2.4 扩展名字空间 ∙ 3 会话的建立 ∙ 4 交换消息 o 4.1 指明一个预定的接收者 o 4.2 指定一个消息类型 o 4.3 指定一个消息主体 o 4.4 指定一个消息主题 o 4.5 指定一个会话线索 ∙ 5 交换出席信息 o 5.1 客户端和服务器出席信息职责 ▪ 5.1.1 初始化出席信息 小白兔的资料▪ 5.1.2 出席信息广播 ▪ 5.1.3 出席信息调查 ▪ 5.1.4 直接出席信息 ▪ 5.1.5 不可用出席信息 ▪ 5.1.6 出席信息订阅 o 5.2 指明可用性状态 o 5.3 指明详细的可用性状态信息 o 5.4 指明出席信息优先级 o 5.5 出席信息例子 ∙ 6 管理订阅 o 6.1 请求一个订阅 o 6.2 处理一个订阅请求 描写家乡的作文o 6.3 从另一个实体取消一个订阅 o 6.4 取消对于另一个实体的出席信息的订阅 ∙ 7 名册管理 o 7.1 语法和语义 o 7.2 商业规则 o 7.3 登录时接收一个人的名册 o 7.4 增加一个名册条目 o 7.5 更新名册条目 o 7.6 删除一个名册条目 ∙ 8 名册条目和出席信息订阅的集成 o 8.1 概览 o 8.2 用户向联系人订阅 ▪ 8.2.1 替代流程: 联系人拒绝订阅请求 o 8.3 建立一个相互的订阅 ▪ 8.3.1 替代流程: 用户拒绝订阅请求 o 8.4 取消订阅 ▪ 8.4.1 情形 #1: 当订阅不是相互的时候取消订阅 ▪ 8.4.2 情形 #2: 当订阅是相互的时候取消订阅 o 8.5 取消一个订阅项 ▪ 8.5.1 情形 #1: 当订阅不是相互的时候取消订阅项 ▪ 8.5.2 情形 #2: 当订阅项是相互的时候取消 o 8.6 移除一个名册条目并取消所有订阅项 ∙ 9 订阅状态 o 9.1 已定义的状态 o 9.2 出站出席信息订阅节的服务器处理过程 o 9.3 入站出席信息订阅节的服务器处理过程 o 9.4 服务器递送和客户端承认订阅请求以及状态变更通知 ∙ 10 屏蔽通信 怕浪费婆婆 o 10.1 语法和语义 o 10.2 商业规则 o 10.3 接收某人的隐私列表 o 10.4 管理激活列表 o 10.5 管理缺省列表 o 10.6 编辑一个隐私列表 o 10.7 增加一个新的隐私列表 o 10.8 移除一个隐私列表 o 10.9 屏蔽消息 o 10.10 屏蔽入站出席信息通知 o 10.11 评比出站出席信息通知 经典成语故事100篇 o 10.12 屏蔽IQ节 o 10.13 屏蔽所有通信 o 10.14 已被屏蔽的实体尝试和用户通信 o 10.15 高级启发 ∙ 11 服务器处理XML节的规则 o 11.1 入站节 o 11.2 出站节 ∙ 12 即时消息和出席信息兼容性需求 o 12.1 服务器 o 12.2 客户端 ∙ 13 国际化事项 ∙ 14 安全性事项 ∙ 15 IANA事项 o 15.1 会话数据的XML名字空间名 o 15.2 即时消息SRV协议标签注册 o 15.3 出席信息SRV协议标签注册 ∙ 16 参考 o 16.1 标准参考 o 16.2 信息参考 ∙ 17 附录 A. vCards ∙ 18 附录 B. XML规划 o 18.1 B.1 jabber:client o 18.2 B.2 jabber:rver o 18.3 B.3 ssion o 拥挤18.4 B.4 jabber:iq:privacy o 18.5 B.5 jabber:iq:roster ∙ 19 附录 C. Jabber IM Prence协议和XMPP之间的不同 o 19.1 C.1 Session Establishment o 19.2 C.2 Privacy Lists ∙ 20 贡献者 ∙ 21 致谢 ∙ 22 作者地址 ∙ 23 完整的版权声明 ∙ 24 知识产权 ∙ 25 感谢 |
|
名片模板图片大全
绪论
概览
XMPP是一个流化XML[XML]元素的协议，用于准实时的交换消息和出席信息。XMPP的核心功能定义在Extensible Messaging and Prence Protocol (XMPP): Core [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 这些功能 -- 主要是 XML流, 使用 TLS和SASL,以及流的根元素之下的<message/>, <prence/>, 和 <iq/> 子元素 -- 为各种类型的准实时应用提供了一个构造基础, 它可以被放在核心的顶层，使用特定XML名字空间[XML-NAMES]发送特定的应用数据. 本文描述XMPP核心功能的扩展和应用，XMPP核心功能提供了RFC 2779 [IMP-REQS]定义的基本的即时消息和出席信息功能。
需求
为了达到本文的目的, 基本的即时消息和出席信息应用的需求定义在[IMP-REQS],它是一个高阶的规定,一个用户必须完成以下用例:
∙ 和其他用户交换消息
∙ 和其他用户交换出席信息
∙ 管理和其他用户之间的订阅和被订阅
∙ 管理联系人列表中的条目(在 XMPP 中这被称为 "roster")
∙ 屏蔽和特定的其他用户之间的通信（出或入）
这些功能领域的详细定义在[IMP-REQS]中, 感兴趣的用户可以直接阅读原文关于需求方面的内容。
[IMP-REQS]也规定出席信息服务必须从即时消息服务中分离; 例如, 它必须可能用这个协议来提供一个出席信息服务,一个即时消息服务,或同时提供两者. 尽管本文假定实现和部署希望提供统一的即时消息和出席信息服务, 但没有要求一个服务必须同时提供出席信息服务和即时消息服务, 并且协议也提供了把出席信息服务和即时消息服务分离成为独立服务的可能性.
注意: 虽然基于XMPP的即时消息和出席信息符合[IMP-REQS]的要求,但它不是特意为那个
协议设计的,因为基础协议是在RFC 2779成文之前通过Jabber开放源代码社区的一个开放的开发过程发展出来的. 也请注意尽管在Jabber社区发展的协议中定义了许多其他方面的功能,但是这些协议不包含在本文之中,因为它们不是[IMP-REQS]所要求的.
术语
本文继承了 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的术语.
大写关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 在本文中的含义定义在 BCP 14, RFC 2119 \[TERMS\].
XML 节的语法
符合'jabber:client'和'jabber:rver'名字空间的XML节的基本语义和通用属性已经在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义了. 无论如何, 这些名字空间也定义了yixie其他的子元素, 比如通用属性'type'的值, 对于即时消息和出席信息应用就是特殊的. 因而, 在选择用于这类应用的特定用例之前, 我们在这里需要先描述一下XML节的语
法, 用来补充[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中的讨论.
消息语法
符合'jabber:client' or 'jabber:rver'名字空间的消息节用于"推" 信息到另一个实体. 在即时消息应用中通常的用法是包含，一个单独的消息,在一个聊天会话中的消息，一个多用户聊天室的上下文中的消息，标题或其他警告和错误的消息,
消息的类型
一个消息节的'type' 属性是建议的(RECOMMENDED); 如果包含了它,它指明这个消息的会话上下文,从而提供一个关于表达的线索(例如, 在一个GUI中). 如果包含了它, 'type' 属性必须(MUST)是以下的值之一 :
∙ chat -- 消息是在一对一聊天会话的语境被发送. 一个兼容的客户端应该(SHOULD)在一个允许两个实体进行一对一聊天的界面中显示消息,包括适当的会话历史.
∙ error -- 发生了一个和上次发送者发送的消息有关的错误(关于节错误语法的详细信息, 参
考 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]). 一个兼容客户端应该(SHOULD)在一个适当的界面展示它以通知发送者这个错误的种类.
∙ groupchat -- 消息是在一个多用户聊天环境的语境下发送的(类似\[IRC\]). 一个兼容客户端应该(SHOULD)在允许多对多聊天的界面显示这个消息,包括, 包括这个聊天室的名册和适当的会话历史. 基于XMPP的群聊协议的完整定义超出了本文的范围.
∙ headline -- 一个消息可能是由一个递送或广播内容的自动化服务生成的(新闻, 体育, 市场信息, RSS feeds, 等等.). 这个消息是不需要回复的, 一个兼容客户端应该(SHOULD) 在一个适当的和单独消息,聊天会话,或群聊会话不同的界面显示这个消息(例如, 不给接收者提供回复能力).
锤子和镰刀∙ normal -- 这个消息是一个在一对一会话或群聊会话之外的单独消息, 并且它希望接收者能够回复.一个兼容客户端应该(SHOULD)在一个允许接收者回复的界面显示这个消息, 但不需要会话历史.
一个 IM 应用应该(SHOULD)支持所有前述的消息类型;如果一个应用接收了一个没有'type'
属性的消息或这个应用不理解'type'属性的值, 它必须(MUST)认为这个消息是一个 "normal" 类型(如,"normal" 是缺省的). "error"类型必须(MUST)仅仅在应答一个和从别的实体接收到的消息有关的错误时生成.
尽管'type'属性是可选的(OPTIONAL), 处于礼貌原因对于消息的任何回复总是和原来的消息同一类型;此外, 一些特殊的应用(例如, 一个多用户聊天服务) 可以(MAY)根据它们的判断强制特定消息类型的使用(例如, type='groupchat').
子元素
正如 扩展名字空间extended namespaces(第二章第四节)所述, 一个消息节可以(MAY)包含任何适当名字空间的子元素.
和缺省名字空间声明一致, 缺省消息节的名字空间是'jabber:client' 或 'jabber:rver', 定义了某几个允许的消息节的子元素. 如果消息节的类型是 "error", 它必须(MUST)包含一个<error/>子元素; 详细情况, 见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 否则, 消息节可以(MAY)包含以下子元素的任何一种并且无需显式地声明名字空间:
区分的英文
1. <subject/>
2. <body/>
3. <thread/>
主题
<subject/> 元素包含了人类可读的 XML 字符数据指明这个消息的主题. <subject/>元素不能(MUST NOT)拥有任何属性, 除了'xml:lang'属性. <subject/> 元素可以(MAY)包含多个实例用于为同一主题提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <subject/> 元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).
主体
<body/> 元素包含人类可读的XML字符数据表达消息的文本内容; 这个子元素通常会有但是是可选的(OPTIONAL). <body/>元素不能(MUST NOT)拥有任何属性, 除非是'xml:lang'属性.
<body/> 元素可以(MAY)包含多个实例用于为同一主体提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <body/>元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).
线索
<thread/> 元素包含非人类可读的XML字符数据表达一个标识符用于跟踪两个实体之间的一个会话线索(有时相当于一个"即时消息会话"). <thread/>元素的值是由发送者生成的并且应该(SHOULD)在任何回复中拷贝回来. 如果使用了它, 它必须(MUST)在这个流的会话线索中是唯一的并且必须(MUST)和那个会话相一致(一个从同一个全JID但不同线索ID接收到消息的客户端必须(MUST)假定这个有问题的消息存在于已有的会话线索之外. <thread/>元素的使用是可选的(OPTIONAL)并且不是用于标识独立的消息,而是标识会话. 一个消息节不能(MUST NOT)包含超过一个的<thread/>元素. <thread/>元素不能(MUST NOT)拥有任何属性. <thread/>属性的值必须(MUST)被实体处理成不透明的; 不能从它得到任何语义学上的含义,并且只能对它做精确的比较. <thread/>元素不能(MUST NOT)包含混合内容(定义在 [XML]第三章第二节第二小节).
