archive-org.com » ORG » J » JABBERCN.ORG

Total: 303

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • 帮助:目录 - Jabber/XMPP中文翻译计划
    Hello World in PHP echo Hello World 支持的语言 Code Language abap ABAP actionscript ActionScript ada Ada apache Apache Configuration applescript AppleScript asm ASM asp Active Server Pages ASP autoit AutoIt bash Bash basic4gl Basic4GL bf Brainfuck blitzbasic Blitz BASIC bnf Backus Naur Form c C c mac C Mac caddcl AutoCAD DCL cadlisp AutoLISP cfdg CFDG cfm ColdFusion Markup Language cil Common Intermediate Language CIL cobol COBOL cpp qt C Qt toolkit cpp C csharp C css Cascading Style Sheets CSS d D delphi Delphi diff Diff div DIV dos DOS batch file dot DOT eiffel Eiffel fortran Fortran freebasic FreeBASIC genero Genero gettext GNU internationalization i18n library glsl OpenGL Shading Language GLSL gml Game Maker Language GML gnuplot gnuplot groovy Groovy haskell Haskell hq9plus HQ9 html4strict HTML idl Uno IDL ini INI inno Inno intercal INTERCAL io Io java Java java5 Java TM 2 Platform Standard Edition 5 0 javascript JavaScript kixtart KiXtart klonec Klone C klonecpp Klone C latex LaTeX lisp Lisp lolcode LOLCODE lotusscript LotusScript lua Lua Code Language m68k Motorola 68000 Assembler make make matlab MATLAB M mirc mIRC scripting language mxml MXML mpasm Microchip Assembler mysql MySQL nsis Nullsoft Scriptable Install System NSIS objc Objective C ocaml brief OCaml ocaml OCaml oobas OpenOffice org Basic oracle8 Oracle 8 SQL oracle11 Oracle 11 SQL pascal Pascal per per perl Perl php brief PHP php PHP pixelbender Pixel Bender plsql PL SQL povray Persistence of Vision Raytracer powershell Windows PowerShell progress OpenEdge Advanced Business Language prolog Prolog providex ProvideX python Python qbasic QBasic QuickBASIC rails Rails reg Windows Registry robots robots txt ruby Ruby rsplus R S sas SAS scala Scala scheme Scheme scilab Scilab sdlbasic SdlBasic smalltalk Smalltalk smarty Smarty sql SQL tcl Tcl teraterm Tera Term text Plain text thinbasic thinBasic tsql Transact SQL typoscript

    Original URL path: http://wiki.jabbercn.org/index.php?title=%E5%B8%AE%E5%8A%A9:%E7%9B%AE%E5%BD%95&oldid=3579 (2016-04-25)
    Open archived version from archive


  • 查看源代码 - Jabber/XMPP中文翻译计划
    91 E6 89 8B E5 86 8C 编辑手册 Template 已安装的扩展 Category 系统文件 该页面使用的模板 模板 已安装的扩展 查看源代码 保护 返回到 帮助 目录 来自 http wiki jabbercn org E5 B8 AE E5 8A A9 E7 9B AE E5 BD 95 查看 帮助页面 讨论

    Original URL path: http://wiki.jabbercn.org/index.php?title=%E5%B8%AE%E5%8A%A9:%E7%9B%AE%E5%BD%95&action=edit (2016-04-25)
    Open archived version from archive

  • “帮助:目录”的版本历史 - Jabber/XMPP中文翻译计划
    讨论 贡献 小 223字节 当前 先前 2010年6月2日 三 01 14 Admin 讨论 贡献 小 226字节 当前 先前 2010年6月2日 三 01 13 Admin 讨论 贡献 小 194字节 当前 先前 2010年6月2日 三 00 58 Admin 讨论 贡献 小 205字节 当前 先前 2010年6月1日 二 11 44 Admin 讨论 贡献 小 95字节 当前 先前 2010年6月1日 二 11 43 Admin 讨论 贡献 小 96字节 当前 先前 2010年6月1日 二 11 42 Admin 讨论 贡献 小 85字节

    Original URL path: http://wiki.jabbercn.org/index.php?title=%E5%B8%AE%E5%8A%A9:%E7%9B%AE%E5%BD%95&action=history (2016-04-25)
    Open archived version from archive

  • 登录/创建账户 - Jabber/XMPP中文翻译计划
    密码 您的域名 jabbercn org 在此浏览器上保留我的登录信息 最长30日 来自 http wiki jabbercn org E7 89 B9 E6 AE 8A E7 94 A8 E6 88 B7 E7 99 BB E5 BD 95 查看 特殊页面 个人工具 登录 创建账户 导航 首页 社区专页 新闻动态 最近更改 随机页面

    Original URL path: http://wiki.jabbercn.org/index.php?title=%E7%89%B9%E6%AE%8A:%E7%94%A8%E6%88%B7%E7%99%BB%E5%BD%95&returnto=%E5%B8%AE%E5%8A%A9%3A%E7%9B%AE%E5%BD%95 (2016-04-25)
    Open archived version from archive

  • 链接至“帮助:目录”的页面 - Jabber/XMPP中文翻译计划
    模板 模板讨论 帮助 帮助讨论 分类 分类讨论 过滤器 隐藏 包含 隐藏 链接 隐藏 重定向 下列页面链接至 帮助 目录 查看 上50个 下50个 20 50 100 250 500 首页 链入页面 查看 上50个 下50个 20 50 100 250 500 来自 http wiki jabbercn org E7 89 B9 E6 AE 8A E9 93 BE E5 85 A5 E9 A1 B5 E9 9D A2 E5 B8 AE E5 8A A9 E7 9B AE E5 BD 95 查看

    Original URL path: http://wiki.jabbercn.org/%E7%89%B9%E6%AE%8A:%E9%93%BE%E5%85%A5%E9%A1%B5%E9%9D%A2/%E5%B8%AE%E5%8A%A9:%E7%9B%AE%E5%BD%95 (2016-04-25)
    Open archived version from archive

  • 对于“帮助:目录”有关的链出更改 - Jabber/XMPP中文翻译计划
    次改动 隐藏 小编辑 显示 机器人的编辑 隐藏 匿名用户的编辑 隐藏 登录用户的编辑 隐藏 我的编辑 显示自 2016年4月25日 一 16 46 起的新更改 名字空间 全部 主要 讨论 用户 用户讨论 Jabber XMPP中文翻译计划 Jabber XMPP中文翻译计划讨论 文件 文件讨论 MediaWiki MediaWiki讨论 模板 模板讨论 帮助 帮助讨论 分类 分类讨论 反选 相关名字空间 页面名称 显示链到所给出的页面 在这一段时间中链接的页面并无更改 来自 http wiki jabbercn org E7 89 B9 E6 AE 8A E9 93 BE E5 87 BA E6 9B B4 E6 94 B9 E5 B8 AE E5 8A

    Original URL path: http://wiki.jabbercn.org/%E7%89%B9%E6%AE%8A:%E9%93%BE%E5%87%BA%E6%9B%B4%E6%94%B9/%E5%B8%AE%E5%8A%A9:%E7%9B%AE%E5%BD%95 (2016-04-25)
    Open archived version from archive

  • 帮助:目录 - Jabber/XMPP中文翻译计划
    Language abap ABAP actionscript ActionScript ada Ada apache Apache Configuration applescript AppleScript asm ASM asp Active Server Pages ASP autoit AutoIt bash Bash basic4gl Basic4GL bf Brainfuck blitzbasic Blitz BASIC bnf Backus Naur Form c C c mac C Mac caddcl AutoCAD DCL cadlisp AutoLISP cfdg CFDG cfm ColdFusion Markup Language cil Common Intermediate Language CIL cobol COBOL cpp qt C Qt toolkit cpp C csharp C css Cascading Style Sheets CSS d D delphi Delphi diff Diff div DIV dos DOS batch file dot DOT eiffel Eiffel fortran Fortran freebasic FreeBASIC genero Genero gettext GNU internationalization i18n library glsl OpenGL Shading Language GLSL gml Game Maker Language GML gnuplot gnuplot groovy Groovy haskell Haskell hq9plus HQ9 html4strict HTML idl Uno IDL ini INI inno Inno intercal INTERCAL io Io java Java java5 Java TM 2 Platform Standard Edition 5 0 javascript JavaScript kixtart KiXtart klonec Klone C klonecpp Klone C latex LaTeX lisp Lisp lolcode LOLCODE lotusscript LotusScript lua Lua Code Language m68k Motorola 68000 Assembler make make matlab MATLAB M mirc mIRC scripting language mxml MXML mpasm Microchip Assembler mysql MySQL nsis Nullsoft Scriptable Install System NSIS objc Objective C ocaml brief OCaml ocaml OCaml oobas OpenOffice org Basic oracle8 Oracle 8 SQL oracle11 Oracle 11 SQL pascal Pascal per per perl Perl php brief PHP php PHP pixelbender Pixel Bender plsql PL SQL povray Persistence of Vision Raytracer powershell Windows PowerShell progress OpenEdge Advanced Business Language prolog Prolog providex ProvideX python Python qbasic QBasic QuickBASIC rails Rails reg Windows Registry robots robots txt ruby Ruby rsplus R S sas SAS scala Scala scheme Scheme scilab Scilab sdlbasic SdlBasic smalltalk Smalltalk smarty Smarty sql SQL tcl Tcl teraterm Tera Term text Plain text thinbasic thinBasic tsql Transact SQL typoscript TypoScript vb Visual Basic vbnet Visual Basic NET verilog

    Original URL path: http://wiki.jabbercn.org/index.php?title=%E5%B8%AE%E5%8A%A9:%E7%9B%AE%E5%BD%95&printable=yes (2016-04-25)
    Open archived version from archive

  • RFC3920 - Jabber/XMPP中文翻译计划
    TLS 规范 如果 TLS 握手不成功 接收实体必须 MUST 终止 TCP 连接 如果 TLS 握手成功 初始化实体必须 MUST 发送给接收实体一个打开的XML流头信息来初始化一个新的流 先发送一个关闭标签 stream 是不必要的 因为接收实体和初始化实体必须 MUST 确保原来的流在TLS握手成功之后被关闭 在从初始化实体收到新的流头信息之后 接收实体必须 MUST 发送一个新的XML流头信息给初始化实体作为应答 其中应包含可用的特性但不包含STATRTTLS特性 客户端 服务器 示例 以下例子展示一个客户端使用STARTTLS保护数据流 注意 以下步骤举例说明协议中的失败案例 在这个例子中它们并不详尽并且也不是必须被数据传输触发的 步骤 1 客户端初始化流给服务器 stream stream xmlns jabber client xmlns stream http etherx jabber org streams to example com version 1 0 步骤 2 服务器发送一个流标签给客户端作为应答 stream stream xmlns jabber client xmlns stream http etherx jabber org streams id c2s 123 from example com version 1 0 步骤 3 服务器发送 STARTTLS 范围给客户端 包括验证机制和任何其他流特性 stream features starttls xmlns urn ietf params xml ns xmpp tls required starttls mechanisms xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 mechanism mechanism PLAIN mechanism mechanisms stream features 步骤 4 客户端发送 STARTTLS 命令给服务器 starttls xmlns urn ietf params xml ns xmpp tls 步骤 5 服务器通知客户端可以继续进行 proceed xmlns urn ietf params xml ns xmpp tls 步骤 5 或者 服务器通知客户端 TLS 握手失败并关闭流和TCP连接 failure xmlns urn ietf params xml ns xmpp tls stream stream 步骤 6 客户端和服务器尝试通过已有的TCP连接完成 TLS 握手 步骤 7 如果 TLS 握手成功 客户端初始化一个新的流给服务器 stream stream xmlns jabber client xmlns stream http etherx jabber org streams to example com version 1 0 步骤 7 或者 如果 TLS 握手不成功 服务器关闭 TCP 连接 步骤 8 服务器发送一个流头信息应答客户端 其中包括任何可用的流特性 stream stream xmlns jabber client xmlns stream http etherx jabber org streams from example com id c2s 234 version 1 0 stream features mechanisms xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 mechanism mechanism PLAIN mechanism mechanism EXTERNAL mechanism mechanisms stream features 步骤 9 客户端继续 SASL 握手 第六章 服务器 服务器示例 以下例子展示两个服务器之间使用STARTTLS保护数据流 注意 以下步骤举例说明协议中的失败案例 在这个例子中它们并不详尽并且也不是必须被数据传输触发的 步骤 1 Server1 初始化流给 Server2 stream stream xmlns jabber server xmlns stream http etherx jabber org streams to example com version 1 0 步骤 2 Server2 发送一个流标签给 Server1 作为应答 stream stream xmlns jabber server xmlns stream http etherx jabber org streams from example com id s2s 123 version 1 0 步骤 3 Server2 发送 STARTTLS 范围给 Server1 包括验证机制和任何其他流特性 stream features starttls xmlns urn ietf params xml ns xmpp tls required starttls mechanisms xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 mechanism mechanism KERBEROS V4 mechanism mechanisms stream features 步骤 4 Server1 发送 STARTTLS 命令给 Server2 starttls xmlns urn ietf params xml ns xmpp tls 步骤 5 Server2 通知 Server1 允许继续进行 proceed xmlns urn ietf params xml ns xmpp tls 步骤 5 或者 Server2 通知 Server1 TLS握手失败并关闭流 failure xmlns urn ietf params xml ns xmpp tls stream stream 步骤 6 Server1 和 Server2 尝试通过 TCP 完成 TLS 握手 步骤 7 如果 TLS 握手成功 Server1 初始化一个新的流给 Server2 stream stream xmlns jabber server xmlns stream http etherx jabber org streams to example com version 1 0 步骤 7 或者 如果 TLS 握手不成功 Server2 关闭 TCP 连接 步骤 8 Server2 发送一个包含任何可用流特性的流头信息给 Server1 stream stream xmlns jabber server xmlns stream http etherx jabber org streams from example com id s2s 234 version 1 0 stream features mechanisms xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 mechanism mechanism KERBEROS V4 mechanism mechanism EXTERNAL mechanism mechanisms stream features 步骤 9 Server1 继续进行 SASL 握手 第六章 SASL 的使用 概览 XMPP 有一个验证流的方法 即XMPP特定的SASL 简单验证和安全层 SASL SASL提供了一个通用的方法为基于连接的协议增加验证支持 而XMPP使用了一个普通的XML名字空间来满足SASL的需要 以下规则应用于 如果SASL协商发生在两台服务器之间 除非服务器宣称的DNS主机名得到解析 否则不能 MUST NOT 进行通信 参见 服务器间的通信 第十四章第四节 如果初始化实体有能力使用 SASL 协商 它必须 MUST 在初始化流的头信息中包含一个值为 1 0 的属性 version 如果接收实体有能力使用 SASL 协商 它必须 MUST 在应答从初始化实体收到的打开流标签时 如果打开的流标签包含一个值为 1 0 的 version 属性 通过 urn ietf params xml ns xmpp sasl 名字空间中的 mechanisms 元素声明一个或多个验证机制 当 SASL 协商时 一个实体不能 MUST NOT 在流的根元素中发送任何空格符号 匹配 production 3 content of XML 作为元素之间的分隔符 在以下的SASL例子中任何空格符号的出现仅仅是为了增加可读性 这条禁令帮助确保安全层字节的精确度 当SASL握手时 在XML元素中使用的任何 XML 字符数据必须被编码成 base64 编码遵循 RFC 3548 第三章的规定 如果一个 简单名字 simple username 规范被选定的SASL机制所支持 比如 这被 DIGEST MD5 和 CRAM MD5 机制支持但不被 EXTERNAL 和 GSSAPI 机制支持 验证的时候初始化实体应该 SHOULD 在服务器间通信时提供 简单名字 自身的发送域 IP地址或包含在一个域标识符中的域名全称 在客户端与服务器之间通信时提供注册用户名 包含在一个XMPP节点标识符中的用户或节点名 如果初始化实体希望以另一个实体的身份出现并且SASL机制支持授权ID的传输 初始化实体在SASL握手时必须 MUST 提供一个授权ID 如果初始化实体不希望以另一个实体的身份出现 初始化实体在SASL握手时不能 MUST NOT 提供一个授权ID 在 SASL 的定义中 除非授权ID不同于从验证ID 详见 SASL 中得到的缺省的授权ID 初始化实体不能 MUST NOT 提供授权ID 如果提供了 这个授权ID的值必须 MUST 是 domain 的格式 对于服务器来说 或 node domain 的格式 对于客户端来说 在成功进行包括安全层的SASL握手之后 接收实体必须 MUST 丢弃任何从初始化实体得到的而不是从SASL协商本身获得的信息 在成功进行包括安全层的SASL握手之后 初始化实体必须 MUST 丢弃任何从接收实体得到的而不是从SASL协商本身获得的信息 参看 强制执行的技术 第十四章第七节 了解关于必须 MUST 支持的机制 叙述 一个初始化实体使用SASL和接收实体做验证的步骤如下 初始化实体请求SASL验证 它发送一个打开的XML流头信息给接收实体 其 version 属性的值为 1 0 在发送一个XML流头回复之后 接收实体声明一个可用的SASL验证机制清单 每个机制作为一个 mechanism 元素 作为子元素包含在 mechanisms 容器元素 其名字空间为 urn ietf params xml ns xmpp sasl 中 而 mechanisms 则包含在流名字空间中的 features 元素中 如果在使用任何验证机制之前需要使用TLS 见第五章 接收实体不能 MUST NOT 在TLS握手之前提供可用的SASL验证机制清单 如果初始化实体在优先的TLS协商过程中呈现了一个合法的证书 接收实体应该 SHOULD 在SASL握手中提出一个SASL外部机制给初始化实体 尽管这个外部机制可以 MAY 在其它环境下提供 初始化实体发送一个符合 urn ietf params xml ns xmpp sasl 名字空间的 auth 元素 其中包含了适当的 mechanism 属性值 给接收实体 以选择一个机制 如果这个机制支持或需要 这个元素可以 MAY 包含XML字符数据 在SASL术语中 即 初始化应答 如果初始化实体需要发送一个零字节的初始化应答 它必须 MUST 传输一个单独的等号作为应答 这表示应答有效但不包含数据 如果必要 接收实体向初始化实体发送一个符合 urn ietf params xml ns xmpp sasl 名字空间的 challenge 元素来发出挑战 这个元素可以 MAY 包含XML字符数据 必须按照初始化实体选择的SASL机制进行一致性运算 初始化实体向接收实体发送符合 urn ietf params xml ns xmpp sasl 名字空间的 response 元素作为应答 这个元素可以 MAY 包含XML字符数据 必须按照初始化实体选择的SASL机制进行一致性运算 如果必要 接收实体发送更多的挑战给初始化实体 初始化实体发送更多的回应 这一系列的 挑战 应答 组 持续进行直到发生以下三件事中的一件为止 初始化实体向接收实体发送符合 urn ietf params xml ns xmpp sasl 名字空间的 abort 元素以中止握手 在接收到 abort 元素之后 接收实体应该 SHOULD 允许一个可配置的但是合理的重试次数 至少2次 然后它必须 MUST 终止TCP连接 这使得初始化实体 如一个最终用户客户端 能够容忍可能不正确的credentials 如密码输入错误 而不用强制重新连接 接收实体向初始化实体发送符合 urn ietf params xml ns xmpp sasl 名字空间的 failure 元素以报告握手失败 详细的失败原因应该在 failure 的一个适当的子元素中沟通 在第六章第四节中的SASL Errors中定义 如果失败的情况发生了 接收实体应该 SHOULD 允许一个可配置的但是合理的重试次数 至少2次 然后它必须 MUST 终止TCP连接 这使得初始化实体 如一个最终用户客户端 能够容忍可能不正确的credentials 如密码输入错误 而不用强制重新连接 接收实体向初始化实体发送符合 urn ietf params xml ns xmpp sasl 名字空间的 success 元素以报告握手成功 如果所选择的SASL机制要求 这个元素可以 MAY 包含XML字符数据 见SASL术语 成功的额外数据 接收到 success 元素之后 初始化实体必须 MUST 发送一个打开的XML流头信息给接收实体以发起一个新的的流 不需要先发送一个 stream 标签 因为在发送和接收到 success 元素之后 接收实体和初始化实体必须确认原来的流被关闭了 从初始化实体接收到新的流头信息之后 接收实体必须 MUST 发送一个新的流头信息给初始化实体作为回应 附上任何可用的特性 但不包括 STARTTLS 和 SASL 特性 或一个空的 features 元素 这表示没有更多的特性可用 任何没有在本文定义的附加特性必须 MUST 在XMPP的相关扩展中定义 SASL 定义 SASL 的必要条件要求通过协议定义来提供以下信息 service name 服务名 xmpp initiation sequence 开始序列 当初始化实体提供一个打开的XML流头信息并且接收实体善意回应之后 接收实体提供一个可接受的验证方法清单 初始化实体从这个清单中选择一个方法 把它作为 auth 元素的 mechanism 属性的值发送给接收实体 也可以选择发送一个初始化应答以避免循环 exchange sequence 交换序列 挑战和回应的交换 从接收实体发送给初始化实体的 challenge 元素和从初始化实体发送给接收实体的 response 元素信息 接收实体通过发送 failure 元素报告失败 发送 success 元素报告成功 初始化实体通过发送 abort 元素中止交换 成功的协商之后 两边都认为原来的XML流已经关闭并且都开始发送新的流头信息 security layer negotiation 安全层协商 安全层在接收实体发送 success 元素的关闭字符 之后立刻生效 在初始化实体发送 success 元素的关闭字符 之后也立刻生效 层的顺序是 TCP TLS 然后是 SASL 然后是 XMPP use of the authorization identity 授权ID的使用 授权ID可在xmpp中用于表示一个客户端的非缺省的 node domain 或一个服务器的 domain SASL 错误 SASL相关的错误条件定义如下 aborted 接收实体认可由初始化实体发送的 abort 元素 在回应一个 abort 元素时发送 incorrect encoding 由初始化实体提供的数据无法处理 因为 BASE64 编码不正确 例如 因为编码不符合 BASE64 的第三章 在回应一个包含初始化响应数据的 response 元素或 auth 元素时发送 invalid authzid 由初始化实体提供的授权id是非法的 因为它的格式不正确或初始化实体无权给那个ID授权 在回应一个包含初始化响应数据的 response 元素或 auth 元素时发送 invalid mechanism 初始化实体不能提供一个机制活 或请求一个不被接受实体支持的机制 在回应一个 auth 元素时发送 mechanism too weak 初始化实体请求的机制比服务器策略对它的要求弱 在回应一个包含初始化响应数据的 response 元素或 auth 元素时发送 not authorized 验证失败 因为初始化实体没有提供合法的credentials 这包括但不限于未知用户名等情形 在回应一个包含初始化响应数据的 response 元素或 auth 元素时发送 temporary auth failure 验证失败 因为接收实体出现了临时的错误 在回应一个 response 元素或 auth 元素时发送 客户端 服务器 示例 以下例子展示了一个客户端和一个服务器使用SASL作验证的数据流 通常是在成功的TLS握手之后 注意 以下显示的替代步骤仅用于举例说明协议的失败情形 它们不够详尽也不需要由例子中的数据传送来触发 步骤 1 客户端初始化流给服务器 stream stream xmlns jabber client xmlns stream http etherx jabber org streams to example com version 1 0 步骤 2 服务器向客户端发送流标签作为应答 stream stream xmlns jabber client xmlns stream http etherx jabber org streams id c2s 234 from example com version 1 0 步骤 3 服务器通知客户端可用的验证机制 stream features mechanisms xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 mechanism mechanism PLAIN mechanism mechanisms stream features 步骤 4 客户端选择一个验证机制 auth xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 步骤 5 服务器发送一个 BASE64 编码的挑战给客户端 challenge xmlns urn ietf params xml ns xmpp sasl cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg challenge 解码后的挑战信息是 realm somerealm nonce OA6MG9tEQGm2hh qop auth charset utf 8 algorithm md5 sess 步骤 5 替代 服务器返回一个错误给客户端 failure xmlns urn ietf params xml ns xmpp sasl incorrect encoding failure stream stream 步骤 6 客户端发送一个 BASE64 编码的回应这个挑战 response xmlns urn ietf params xml ns xmpp sasl dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo YXJzZXQ9dXRmLTgK response 解码后的回应信息是 username somenode realm somerealm nonce OA6MG9tEQGm2hh cnonce OA6MHXh6VqTrRk nc 00000001 qop auth digest uri xmpp example com response d388dad90d4bbd760a152321f2143af7 charset utf 8 步骤 7 服务器发送另一个 BASE64 编码的挑战给客户端 challenge xmlns urn ietf params xml ns xmpp sasl cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo challenge 解码后的挑战信息是 rspauth ea40f60335c427b5527b84dbabcdfffd 步骤 7 或者 服务器返回一个错误给客户端 failure xmlns urn ietf params xml ns xmpp sasl temporary auth failure failure stream stream 步骤 8 客户端应答这个挑战 response xmlns urn ietf params xml ns xmpp sasl 步骤 9 服务器通知客户端验证成功 success xmlns urn ietf params xml ns xmpp sasl 步骤 9 或者 服务器通知客户端验证失败 failure xmlns urn ietf params xml ns xmpp sasl temporary auth failure failure stream stream 步骤 10 客户端发起一个新的流给服务器 stream stream xmlns jabber client xmlns stream http etherx jabber org streams to example com version 1 0 步骤 11 服务器发送一个流头信息回应客户端 并附上任何可用的特性 或空的features元素 stream stream xmlns jabber client xmlns stream http etherx jabber org streams id c2s 345 from example com version 1 0 stream features bind xmlns urn ietf params xml ns xmpp bind session xmlns urn ietf params xml ns xmpp session stream features 服务器 服务器 示例 以下例子展示了一个服务器和另一个服务器使用SASL作验证的数据流 通常是在成功的TLS握手之后 注意 以下显示的替代步骤仅用于举例说明协议的失败情形 它们不够详尽也不需要由例子中的数据传送来触发 步骤 1 服务器1 发起一个流给 服务器2 stream stream xmlns jabber server xmlns stream http etherx jabber org streams to example com version 1 0 步骤 2 服务器2 回应一个流标签给 服务器1 stream stream xmlns jabber server xmlns stream http etherx jabber org streams from example com id s2s 234 version 1 0 步骤 3 服务器2 通知 服务器1 可用的验证机制 stream features mechanisms xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 mechanism mechanism KERBEROS V4 mechanism mechanisms stream features 步骤 4 服务器1 选择一个验证机制 auth xmlns urn ietf params xml ns xmpp sasl mechanism DIGEST MD5 步骤 5 服务器2 发送一个 BASE64 编码的挑战给 服务器1 challenge xmlns urn ietf params xml ns xmpp sasl cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz challenge 解码后的挑战信息是 realm somerealm nonce OA6MG9tEQGm2hh qop auth charset utf 8 algorithm md5 sess 步骤 5 替代 服务器2 返回一个错误给 服务器1 failure xmlns urn ietf params xml ns xmpp sasl incorrect encoding failure stream stream 步骤 6 服务器1 发送一个 BASE64 编码的回应这个挑战 response xmlns urn ietf params xml ns xmpp sasl dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3 LGNoYXJzZXQ9dXRmLTgK response 解码后的应答信息是 username example org realm somerealm nonce OA6MG9tEQGm2hh cnonce OA6MHXh6VqTrRk nc 00000001 qop auth digest uri xmpp example org response d388dad90d4bbd760a152321f2143af7 charset utf 8 步骤 7 服务器2 发送另外一个 BASE64 编码的挑战给 服务器1 challenge xmlns urn ietf params xml ns xmpp sasl cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo challenge 解码后的挑战信息是 rspauth ea40f60335c427b5527b84dbabcdfffd 步骤 7 或者 服务器2 返回一个错误给 服务器1 failure xmlns urn ietf params xml ns xmpp sasl invalid authzid failure stream stream 步骤 8 服务器1 回应挑战 response xmlns urn ietf params xml ns xmpp sasl 步骤 8 或者 服务器1 中止协商 abort xmlns urn ietf params xml ns xmpp sasl 步骤 9 服务器2 通知 服务器1 验证成功 success xmlns urn ietf params xml ns xmpp sasl 步骤 9 或者 服务器2 通知 服务器1 验证失败 failure xmlns urn ietf params xml ns xmpp sasl aborted failure stream stream 步骤 10 服务器1 重新发起一个新的流给 服务器2 stream stream xmlns jabber server xmlns stream http etherx jabber org streams to example com version 1 0 步骤 11 服务器2 发送一个流头信息应答 服务器1 并附上任何可用的特性 或一个空的features元素 stream stream xmlns jabber client xmlns stream http etherx jabber org streams from example com id s2s 345 version 1 0 stream features 资源绑定 在和接收实体完成 SASL 协商 第六章 之后 初始化实体可能 MAY 想要或者需要绑定一个特定的资源到流上 通常这仅适用于客户端 为了满足本文定义的寻址格式 第三章 和节传输规则 第十章 客户端 node domain 必须 MUST 拥有一个相关的资源ID 由服务器生成或由客户端程序提供 以确保在流上使用的地址是一个 全JID node domain resource 接收到一个成功的SASL握手之后 客户端必须 MUST 发送一个新的流头信息给服务器 服务器必须 MUST 返回一个包含可用的流特性列表的头信息 特别是 在成功的SASL握手之后如果服务器需要客户端绑定一个资源 它必须 MUST 在握手成功之后 而不是之前 发送给客户端的应答流特性中包含一个空的符合 urn ietf params xml ns xmpp bind 名字空间的 bind 元素 服务器向客户端声明资源绑定特性 stream stream xmlns jabber client xmlns stream http etherx jabber org streams id c2s 345 from example com version 1 0 stream features bind xmlns urn ietf params xml ns xmpp bind stream features 收到要求资源绑定的通知后 客户端必须 MUST 通过发送一个符合 urn ietf params xml ns xmpp bind 名字空间的 set 类型的IQ节 参见 IQ 语义 第九章第二节第三小节 给服务器来绑定一个资源到流中 如果客户端端希望允许服务器给自己生成一个资源ID 它可以发送一个包含空的 bind 元素的 set 类型的IQ节 客户端请求服务器绑定资源 iq type set id bind 1 bind xmlns urn ietf params xml ns xmpp bind iq 一个支持资源绑定的服务器必须 MUST 自动生成一个资源ID给客户端 一个由服务器生成的资源ID对于那个 node domain 必须 MUST 是唯一的 如果客户端希望指定资源ID 它发送一个包含期望资源ID的 set 类型的 IQ节 把资源ID作为 bind 元素下的 resource 子元素的XML字符数据 客户端绑定一个资源 iq type set id bind 2 bind xmlns urn ietf params xml ns xmpp bind resource someresource resource bind iq 一旦服务器为客户端生成了一个资源ID或接受了客户端自己提供的资源ID 它必须 MUST 返回一个 result 类型的 IQ 节给客户端 这个节必须包含一个指明全JID的 jid 子元素表示服务器决定连接的资源 服务器通知客户端资源绑定成功 iq type result id bind 2 bind xmlns urn ietf params xml ns xmpp bind jid somenode example com someresource jid bind iq 一个服务器应该 SHOULD 接受客户端提供的资源ID 但是可以 MAY 用服务器生成的资源ID覆盖它 在这种情况下 服务器不应该 SHOULD NOT 返回一个错误信息一个 如 forbidden 给客户端 而应该 SHOULD 在上文所述的 IQ result 中返回生成的资源ID 当一个客户端自行提供资源ID时 可能发生以下的节错误 参见 Stanza Errors 第九章第三节 提供的资源ID服务器无法处理 因为不符合资源字符规范Resourceprep 附录B 客户端不被允许绑定一个资源 如节点或用户已经达到允许连接的资源数限制 提供的资源ID已经被使用但是服务器不允许以同一个资源ID绑定多个连接 协议对这些错误条件规定如下 资源ID不能处理 iq type error id bind 2 bind xmlns urn ietf params xml ns xmpp bind resource someresource resource bind error type modify bad request xmlns urn ietf params xml ns xmpp stanzas error iq 客户端不允许绑定一个资源 iq type error id bind 2 bind xmlns urn ietf params xml ns xmpp bind resource someresource resource bind error type cancel not allowed xmlns urn ietf params xml ns xmpp stanzas error iq 资源ID已经在使用 iq type error id bind 2 bind xmlns urn ietf params xml ns xmpp bind resource someresource resource bind error type cancel conflict xmlns urn ietf params xml ns xmpp stanzas error iq 如果 在完成资源绑定步骤之前 客户端试图以符合 urn ietf params xml ns xmpp bind 名字空间的 bind 子元素发送一个非IQ类型的XML节 服务器不能 MUST NOT 处理这个节 而应该 SHOULD 返回一个 not authorized 节错误信息给客户端 服务器回拨 概览 Jabber协议接受的来自XMPP的包括 服务器回拨 方法 用于防治域名欺骗 使得欺骗XML节更为困难 服务器回拨不是一个安全机制 并且它的服务器身份认证结果很弱 参见服务器之间的通信 第十四章第四节 中关于这个方法的安全特性 需要健壮的安全性的域名应该 SHOULD 使用TLS或SASL 细节参见服务器间的通信 第十四章第四节 如果SASL用于服务器间通信 回拨就不需要用了 SHOULD NOT 本文描述回拨的好处在于向后兼容现存的实现和部署 服务器回拨方法由现存的DNS系统的存在而成为可能 因为一个服务器 通常 可以查询给定域的授权服务器 由于服务器回拨依赖于DNS 除非服务器宣称的DNS主机得到解析 域之间的通信无法进行 参见服务器间的通信 第十四章第四节 服务器回拨是单向性的 可在单一方向上对一个流进行 微弱的 身份验证 因为服务器回拨不是一个验证机制 通过回拨获得相互的认证是不可能的 因此 为了使得服务器之间的双向通信 服务器回拨必须 MUST 在每个方向上完成 在服务器回拨中生成和检验密钥的方法必须 MUST 考虑计算被使用的主机名 由接收服务器生成的流ID 和只有授权服务器网络才知道的秘密 在服务器回拨中流ID是安全性的关键所以必须 MUST 是不可预知的和不可重复的 见 RANDOM 中关于使用随机数获得安全性的建议 任何回拨协商过程中发生的错误必须 MUST 被当成一个流错误 并导致流以及相关的TCP连接的终止 可能发生的错误情况协议中描述如下 以下术语适用 发起服务器 尝试在两个域之间建立连接的那个服务器 接收服务器 尝试验证发起服务期声称的域名的那台服务器 授权 权威 Authoritative 服务器 回答发起服务器声称的DNS主机名的服务器 基本上这应该是那台发起服务器 但是它也可能是一个在发起服务器网络中独立的服务器 事件顺序 以下是回拨中的事件顺序的简介 发起服务器和接收服务器建立一个连接 发起服务器通过到连接发送一个 key 值给接收服务期 接收服务器建立一个连接到授权服务器 接收服务器发送一个相同的 key 值给授权服务器 授权服务器回答这个key是否合法 接收服务器通知发起服务器是否被验证通过 我们用用以下图形展示这个事件流程 见附件s2s png image img s2s 发起服务器 接收服务器 建立连接 发stream头 发stream头 发回拨key 授权服务器 建立连接 发stream头 发stream头 发验证请求 发验证响应 报告回拨结果 协议 服务器之间互动的细节协议如下 1 发起服务器和接受服务器建立TCP连接 2 发起服务器发送流头信息给接收服务器 stream stream xmlns stream http etherx jabber org streams xmlns jabber server xmlns db jabber server dialback 注意 to 和 from 属性在流的根元素是可选的 OPTIONAL 其中包含的xmlns db名字空间向接收服务器声明了发起服务器支持回拨 如果名字空间不正确 接收实体必须 MUST 生成一个 invalid namespace 流错误条件并且终止XML流和相应的TCP连接 3 接收服务器应该 SHOULD 回送一个流头信息给发起服务器 为这次交互生成一个唯一性的ID stream stream xmlns stream http etherx jabber org streams xmlns jabber server xmlns db jabber server dialback id 457F9224A0 注意 to 和 from 属性在流的根元素是可选的 OPTIONAL 如果名字空间不正确 发起服务器必须生成一个 invalid namespace 流错误条件并且终止XML流和相应的TCP连接 也要注意 在这里接收服务器应该 SHOULD 应答但是可以 MAY 出于安全策略考虑只是悄悄地终止XML流和TCP连接 无论如何 如果接收服务器希望继续 它必须 MUST 回送一个流头信息给发起服务器 4 发起服务器发送一个回拨密钥给接收服务器 db result to Receiving Server from Originating Server 98AF014EDC0 db result 注意 这个密钥不由接收服务器检查 因为接收服务器在会话之间 between sessions 不保存发起服务器的信息 这个由发起服务器生成的密钥必须 MUST 是基于接收服务器在上一步骤中提供的ID值 以及发起服务器与授权服务器共享的安全机制生成的 如果 to 地址的值和接收服务器知道的主机名不匹配 接收服务器必须 MUST 生成一个 host unknown 流错误条件并且终止XML流和相应的TCP连接 如果 from 地址和接收服务器已经建立的连接的域名相吻合 接收服务器必须 MUST 维护这个已经存在的连接 直到证明这个新的连接是合法的为止 另外 接收实体可以 MAY 选择生成一个 not authorized 流错误条件给这个新的连接并且终止和新连接申请相关的XML流及相应的TCP连接 5 接收服务器向发起服务器声明的那个域建立一个 TCP 连接 作为结果它连接到授权服务器 注意 为了优化性能 在这里一个实现可以 MAY 重用现有的连接 6 接收服务器发送一个流头信息给授权服务器 stream stream xmlns stream http etherx jabber org streams xmlns jabber server xmlns db jabber server dialback 注意 to 和 from 属性在流的根元素是可选的 OPTIONAL 如果名字空间不正确 授权服务器必须生成一个 invalid namespace 流错误条件并且终止XML流和相应的TCP连接 7 授权服务器发送流头信息给接收服务器 stream stream xmlns stream http etherx jabber org streams xmlns jabber server xmlns db jabber server dialback id 1251A342B 注意 如果名字空间不正确 接收服务器必须生成一个 invalid namespace 流错误条件并且终止它和授权服务器之间的XML流和相应的TCP连接 如果一个流错误发生在接收服务器和 授权服务器 之间 接收服务器必须 MUST 生成一个 remote connection failed 流错误条件并且终止它和 发起服务器 之间的XML流和相应的TCP连接 8 接收服务器发送一个密钥检查请求给授权服务器 db verify from Receiving Server to Originating Server id 457F9224A0 98AF014EDC0 db verify 注意 现在这里已经有了主机名 第三步中接收服务器发送给发起服务器的ID 第四步中发起服务器发送给接收服务器的密钥 基于这些信息 加上授权服务器网络共享的安全信息 这个密钥被证实了 任何可用于验证的办法都可以 MAY 用于生成密钥 如果 to 地址的值和授权服务器知道的主机名不匹配 授权服务器必须 MUST 生成一个 host unknown 流错误条件并且终止XML流和相应的TCP连接 打开这个连接时 如果 from 地址和接收服务器声明的主机名 或任何合法的域 如验证过的接收服务器的子域名或寄宿在接收服务器上的其他经过验证的域 不符 授权服务器必须 MUST 生成一个 invalid from 流错误条件并且终止XML流和相应的TCP连接 9 授权服务器检查密钥是否合法 db verify from Originating Server to Receiving Server type valid id 457F9224A0 或 db verify from Originating Server to Receiving Server type invalid id 457F9224A0 注意 如果 ID 和第三步中接收服务器提供的不符 接收服务器必须 MUST 生成一个 invalid id 流错误条件并且终止XML流和相应的TCP连接 如果 to 地址的值和接收服务器知道的主机名不匹配 接收服务器必须 MUST 生成一个 host unknown 流错误条件并且终止XML流和相应的TCP连接 打开这个连接时 如果 from 地址和发起服务器声明的主机名 或任何合法的域 如验证过的发起服务器的子域名或寄宿在发起服务器上的其他经过验证的域 不符 接收服务器必须 MUST 生成一个 invalid from 流错误条件并且终止XML流和相应的TCP连接 在返回验证信息给接收服务器之后 授权服务器应该 SHOULD 终止它们之间的流 10 接收服务器通知发起服务器结果 db result from Receiving Server to Originating Server type valid 注意 在这一个点上 连接已经由 type valid 确认验证是通过了 还是没通过 如果连接是非法的 接收服务器必须 MUST 终止XML流和相应的TCP连接 如果连接是合法的 数据可以从发起服务器发送由接收服务器读取 在此之前 所有发送给接收服务器的XML节应该 SHOULD 被丢弃 进一步的结果是 接收服务器已经验证了发起服务器的ID 所以通过初始化流 initial stream 例如从发起服务器到接收服务器的流 发起服务器可以发送 接收服务器可以接受XML节 为了使用应答流 response stream 例如从接收服务器到发起服务器的流 验证实体ID 回拨必须 MUST 在相对的两个方向上都完成 在成功的回拨协商之后 接收服务器应该 SHOULD 接受接下来发起服务器通过当前的合法连接发送的 db result 包 例如 发送给子域或其他寄宿在接收服务器上的主机名的验证请求 这在单一方向上激活了原始合法连接的 piggybacking 即使回拨协商成功了 服务器仍然必须 MUST 检查从其他服务器接收的所有XML节的 from 和 to 属性 如果一个节不符合这些限定 收到这些节的服务器必须 MUST 生成一个 improper addressing 流错误条件并终止XML流和相应的TCP连接 而且 一个服务器也必须 MUST 检查从其他的有合法域名的服务器的流中收到的节的 from 属性 如果一个节不符合这一限定 接收节的服务器必须 MUST 生成一个 invalid from 流错误条件并终止XML流和相应的TCP连接 所有这些检查都用来帮助防止特定的节伪造行为 XML节 在 TLS 协商 第五章 如果想要 SASL 协商 第六章 和资源绑定 第七章 如果需要 之后 XML节就可以通过流发送了 在 jabber client 和 jabber server 名字空间中定义了三种XML节 message presence 和 iq 另外 这三种节有五种通用的属性 这些通用属性 加上三种节的术语 在这里定义 更多关于和即时消息及出席信息应用相关的XML节语法详细信息在 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 中提供 通用属性 以下五种属性通用于 message presence 和 IQ 节 to to 属性表示节的预期接收者的JID 在 jabber client 名字空间中 一个节应该 SHOULD 处理一个 to 属性 尽管由服务器处理的从客户端发给服务器的节 如 发送给服务器用于广播给其他实体的出席信息 应该不 SHOULD NOT 处理 to 属性 在 jabber server 名字空间中 一个节必须 MUST 处理一个 to 属性 如果一个服务器收到一个不符合此限定的节 它必须 MUST 生成一个 improper addressing 流错误条件并终止和这个非法服务器的XML流和相应的TCP连接 如果 to 属性的值非法或无法联络 发现这个事实的实体 通常是发送者或接收者的服务器 必须 MUST 返回一个适当的错误给发送者 错误节的 from 属性设置成非法节的提供的 to 属性的值 from from 属性表示发送者的 JID 当一个服务器接收了一个符合 jabber client 名字空间的合法流的XML节 它必须 MUST 做以下步骤中的一步 验证客户端提供的 from 属性值就是那个相关实体连接的资源 为生成这个节的已连接的资源增加一个 from 地址 由服务器决定是纯JID或全JID 参见 地址的决定 Determination of Addresses 第三章第五节 如果一个客户端试图发送一个XML节 而它的 from 属性和这个实体已连接的资源不符 服务器应该 SHOULD 返回一个 invalid from 流错误条件给客户端 如果一个客户端试图通过一个尚未验证的流发送一个XML节 服务器应该 SHOULD 返回一个 not authorized 流错误条件给客户端 如果生成了 所有这些条件必须 MUST 导致流的关闭和相应的TCP连接的终止 这有助于防止不诚实的客户的拒绝服务攻击 当一个服务器从服务器自身生成一个节用于一个已连接的客户端的信息发布 例如 在服务器为客户端提供数据存储服务的情况下 这个节必须 MUST 1 不包含 from 属性 或 2 包含一个 from 属性 它的值是这个账号的纯 JID node domain 或 客户端的全 JID node domain resource 如果节不是由服务器自身生成的 那么一个服务器不能 MUST NOT 发送不带 from 属性的节 当一个客户端接收到一个不包含 from 属性的节 它必须 MUST 认为这个节是从客户端连接的服务器发来的 在 jabber server 名字空间 一个节必须 MUST 处理一个 from 属性 如果一个服务器接收到一个不符合此限定的节 它必须 MUST 生成一个 improper addressing 流错误条件 而且 from 属性的 JID值的域名ID部分必须 MUST 和以SASL协商连接或以回拨协商连接的发送服务器的主机名 或任何合法的域 如发送服务器主机名的合法子域 或其他寄宿在发送服务器上的合法域 吻合 如果一个服务器接收到的节不符合此限定 它必须 MUST 生成一个 invalid from 流错误条件 所有这些条件都必须 MUST 导致流的关闭和相应的TCP连接的终止 这有助于防止不诚实的客户端发起的拒绝服务攻击 id 可选的 id 属性可以 MAY 用于为节的内部跟踪发送实体 从IQ节 语义来讲 就是通过发送和接收这些节来跟踪 请求 应答 型的交互行为 这个可选的 OPTIONAL id 属性值在一个域或一个流中是全局唯一的 IQ节语义学中对此有附加限定 见IQ Semantics 第九章第二节第三小节 type type 属性指明消息 出席信息或IQ节的意图或上下文的详细信息 type 属性所允许的值依据节的类型是消息 出席信息还是IQ而有很大不同 用于消息和出席信息节的值定义在即时消息和出席信息应用中 所以在 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 中定义 反之用于IQ节的值定义了在一个 请求 应答 的 会话 中IQ节的角色 所以定义在IQ语义学中 第九章第二节第三小节 所有三种节的通用 type 值是 error 见Stanza Errors 第九章第三节 xml lang 如果一个节包含用于显示给人human user看的XML字符数据 在 RFC 2277 中有所解释 CHARSET internationalization is for humans 这个节应该 SHOULD 处理一个 xml lang 属性 定义在第二章第十二节 XML xml lang 属性的值指明任何一个人类可读的XML字符数据的缺省语言 它可以 MAY 被特定的子元素的 xml lang 值重载 如果一个节不处理一个 xml lang 属性 一个实现必须 MUST 认为缺省的语言就是流属性中定义的语言 第四章第四节 xml lang 属性值必须 MUST 是一个 NMTOKEN 并且必须 MUST 遵守 RFC 3066 LANGTAGS 中定义的格式 基本语义学 消息语义学 message 节类型可以被看作是一个 push 机制用于一个实体推送信息给另一个实体 类似发生在email系统中的通信 所有消息节应该 SHOULD 处理一个表明预定的消息接收者的 to 属性 接收了这样一个节之后 一个服务器应该 SHOULD 路由或递送它给预定的接收者 见 Server Rules for Handling XML Stanzas 第十章 的XML节相关的通用路由和递送规则 出席信息语义学 presence 元素可以被看作一个基本的广播或 出版 订阅 机制 用于多个实体接收某个已订阅的实体的信息 在这里 是网络可用性信息 通常 一个发行实体应该 SHOULD 不带 to 属性发送一个出席信息 这时这个实体所连接的服务器应该 SHOULD 广播或复用 multiplex 那个节给所有订阅的实体 无论如何 一个发行实体也可以 MAY 带 to 属性发送一个出席信息节 这时服务器应该 SHOULD 路由或递送这个节给预定的接收者 见 Server Rules for Handling XML Stanzas 第十章 的XML节相关的通用路由和递送规则 以及 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 中即时消息和出席信息应用中出席信息的特定规则 IQ语义学 信息 查询 Info Query 或曰IQ 是一个 请求 回应 机制 某些情况下类似 HTTP IQ语义学使一个实体能够向另一个实体做出请求并做出应答 请求和应答所包含的数据定义在IQ元素的一个直接的子元素的名字空间声明中 并且由请求实体用 id 属性来跟踪这一交互行为 因而 IQ交互伴随着一个结构化的数据交换的通用模式例如 get result 或 set result 尽管有时候会以一个错误信息应答某个请求 以下是IQ的流程图 参见附件iq png image img iq 请求实体 响应实体 iq type get id 1 iq type result id 1 iq type set id 2 iq type error id 2 为了强制执行这些语义学 要应用以下规则 1 对于IQ节来说 id 属性是必需的 REQUIRED 2 对于IQ节来说 type 属性是必需的 REQUIRED 它的值必须 MUST 是以下之一 get 这个节是一个对信息或需求的请求 set 这个节提供需要的数据 设置新的值 或取代现有的值 result 这个节是一个对一个成功的 get 或 set 请求的应答 error 发生了一个错误 关于处理或递送上次发送的 get 或 set的 参见 节错误 Stanza Errors 第九章第三节 3 一个接收到 get 或 set 类型的IQ请求的实体必须 MUST 回复一个 result 或 error 类型的IQ应答 这个应答必须 MUST 保留相关请求的 id 属性 4 一个接收到 result 或 error 类型的IQ节的实体不能 MUST NOT 再发送更多的 result 或 error 类型的IQ应答 无论如何 如上所述 请求实体可以 MAY 发送另一个请求 如 一个 set 类型的IQ 通过get result对提供查询 discovery 所需的信息 5 一个 get 或 set 类型的IQ节必须 MUST 包含并只包含一个子元素指明特定请求或应答的语义 6 一个 result 类型的IQ节必须 MUST 包含零或一个子元素 7 一个 error 类型的IQ节应该 SHOULD 包含和 get 或 set 相关联的那个子元素并且必须 MUST 包含一个 error 子元素 详细信息 见Stanza Errors 第九章第三节 节错误 节相关的错误的处理方式类似流错误 第四章第七节 无论如何 不像流错误 节错误是可恢复的 所以错误节包含了暗示原来的发送者可以采取什么行动来补救这个错误 规则 以下规则适用于节相关的错误 接收或处理实体察觉到一个节相关的错误条件时应该 MUST 返回给发送实体一个同类型的节 消息 出席信息 或IQ 这个节的 type 属性值则设置为 error 这里这样的节称之为 error stanza 生成一个错误节的实体应该 SHOULD 包含原来发送的XML 这样发送者可以检查它 并且如果必要 在尝试重新发送之前纠正它 一个错误节必须 MUST 包含一个 error 子元素 如果 type 属性值不是 error 或没有 type 属性 节不能 MUST NOT 包含一个 error 子元素 接收到一个错误节的实体不能 MUST NOT 应答这个节更多的错误节 这有助于防止死循环 语法 节相关错误的语法如下 stanza kind to sender type error RECOMMENDED to include sender XML here error type error type defined condition xmlns urn ietf params xml ns xmpp stanzas text xmlns urn ietf params xml ns xmpp stanzas xml lang langcode OPTIONAL descriptive text text OPTIONAL application specific condition element error stanza kind stanza kind 是 message presence 或 iq 中的一个 error 元素的 type 属性值必须 MUST 是以下之一 cancel 不重试 这个错误是不可恢复的 continue 继续进行 这个条件只是一个警告 modify 改变数据之后重试 auth 提供证书之后重试 wait 等待之后重试 错误是暂时的 error 元素 必须 MUST 包含一个子元素 符合以下定义的节错误条件之一 这个元素 MUST 符合 urn ietf params xml ns xmpp stanzas 名字空间 可以 MAY 包含一个 text 子元素容纳XML字符数据用来描述错误的更多细节 这个元素必须 MUST 符合 urn ietf params xml ns xmpp stanzas 名字空间并且应该 SHOULD 处理 xml lang 属性 可以 MAY 包含一个应用程序定义的错误条件子元素 这个元素必须 MUST 符合一个应用程序定义的名字空间 并且它的结构由这个名字空间定义 text 元素是可选的 OPTIONAL 如果包含它 它应该 SHOULD 仅用于提供描述或诊断信息以补充一个已定义的条件或应用程序定义的条件 它不应 SHOULD NOT 被应用程序认为是一个程序性的 它不应 SHOULD NOT 被用作向一个使用者展示的错误信息 但是可以 MAY 展示除条件元素 或元素们 相关的错误信息之外的信息 最后 为了维护向后兼容性 这个schema 定义在 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 允许可选的在 error 元素中包含一个 code 属性 已定义的条件 以下条件定义用于节错误 bad request 发送者发送的XML是不规范的或不能被处理 例如 一个IQ节包含了一个未被承认的 type 属性值 相关的错误类型应该 SHOULD 是 modify conflict 不同意访问 因为相同的名字或地址已存在一个资源或会话 相关的错误类型应该 SHOULD 是 cancel feature not implemented 请求的特性未被接收者或服务器实现所以不能处理 相关的错误类型应该 SHOULD 是 cancel forbidden 请求实体没有必需的许可来执行这一动作 相关的错误类型应该 SHOULD 是 auth gone 接收者或服务器无法再以这个地址进行联系 错误节可以 MAY 在 gone 元素的XML字符数据中包含一个新的地址 相关的错误类型应该 SHOULD 是 modify internal server error 服务器不能处理节 因为错误的配置或其他未定义的内部服务器错误 相关的错误类型应该 SHOULD 是 wait item not found JID地址或申请的条目无法找到 相关的错误类型应该 SHOULD 是 cancel jid malformed 发送的实体提供的XMPP地址或与之通信的某个XMPP地址 如一个 to 属性值 或这个XMPP地址中的一部分 如一个资源ID 不符合寻址方案的语法 第三章 相关的错误类型应该 SHOULD 是 modify not acceptable 接收者或服务器理解这个请求但是拒绝处理 因为它不符合某些接收者或服务器定义的标准 例如 一个关于消息中可接收的单词的本地策略 相关错误类型应该 SHOULD 是 modify not allowed 接收者或服务器不允许任何实体执行这个动作 相关错误类型应该 SHOULD 是 cancel not authorized 在被允许执行某个动作之前发送者必须提供适当的证书 或已提供了不正确的证书 相关错误类型应该 SHOULD 是 auth payment required 请求实体未被授权访问请求的服务 因为需要付费 相关错误类型应该 SHOULD 是 auth recipient unavailable 预定的接收者暂时不可用 相关错误类型应该 SHOULD 是 wait 注意 如果这样做会导致泄露预定接收者的网络可用性给一个未被授权了解此信息的实体 应用程序不应该 MUST NOT 返回这个错误 redirect 接收者或服务器重定向这个请求信息到另一个实体 通常是暂时的 这个错误节应该 SHOULD 在 redirect 元素的XML字符数据中包含一个预备的地址 它必须 MUST 是一个合法的JID 相关的错误类型应该 SHOULD 是 modify registration required 请求实体未被授权访问请求的服务 因为需要注册 相关错误类型应该 SHOULD 是 auth remote server not found 在预定的接收者的全部或部分JID中的一个远程服务器或服务不存在 相关错误类型应该 SHOULD 是 cancel remote server timeout 在预定的接收者 或需要完成的一个申请 的全部或部分JID中的一个远程服务器或服务无法在合理的时间内联系到 相关错误类型应该 SHOULD 是 wait resource constraint 服务器或接收者缺乏足够的系统资源来服务请求 相关错误类型应该 SHOULD 是 wait service unavailable 服务器或接收者目前无法提供被请求的服务 相关错误类型应该 SHOULD 是 cancel subscription required 请求实体未被授权访问能请求的服务 因为需要订阅 相关错误类型应该 SHOULD 是 auth undefined condition 错误条件不是本列表中定于的其他条件之一 任何错误类型可能和这个条件有关 并且它应该 SHOULD 仅用于关联一个应用程序定义的条件 unexpected request 接收者或服务器理解这个请求但是不希望是在这个时间 比如 请求的顺序颠倒 相关错误类型应该 SHOULD 是 wait 应用程序定义条件 大家知道 一个应用程序可以 MAY 通过在错误元素里包含一个适当名字空间的字元素来提供应用程序定义的节错误信息 应用程序定义的元素应该 SHOULD 补充或进一步限定一个已定义的元素 因而 error 元素将包含两个或三个子元素 iq type error id some id error type modify bad request xmlns urn ietf params xml ns xmpp stanzas too many parameters xmlns application ns error iq message type error id another id error type modify undefined condition xmlns urn ietf params xml ns xmpp stanzas text xml lang en xmlns urn ietf params xml ns xmpp stanzas Some special application diagnostic information text special application condition xmlns application ns error message 服务器处理XML节的规则 兼容的服务器实现必须 MUST 确保两个实体之间的XML节按次序处理 在按次序处理的需求之外 每个服务器实现将包含它自己的递送树 delivery tree 以处理它接收到的节 这个树决定一个节是否需要路由到其他域 在内部处理 还是递送到和一个已连接的节点相关的资源 以下规则适用 没有 to 地址 如果这个节没有 to 属性 服务器应该 SHOULD 为发送它的实体处理这个节 因为所有从其他服务器收到的节必须 MUST 拥有 to 属性 这个规则仅适用于从一个连接到这台服务器的已注册实体 如一个客户端 收到的节 如果这个服务器收到一个没有 to 属性的出席信息节 服务器应该 SHOULD 向那些订阅了这个发送实体的出席信息的所有实体广播它 如果可能的话 即时消息和出席信息应用程序中出席信息广播的语义定义在 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 如果服务器接收到一个类型为 get 或 set 的没有 to 属性的节并且它理解这个节的名字空间下的内容 它必须 MUST 为这个发送实体处理节 在这里 process 的含义是由相关的名字空间的语义所决定的 或返回一个错误给发送实体 外部域 如果 to 属性中的JID的域ID部分的主机名和服务器自身或其子域配置的主机名不匹配 服务器应该 SHOULD 路由这个节到外部域 取决于本地服务规定或安全策略关于域间通信的规定 有两种可能的情况 一个服务器之间的流已经存在于两个域之间 发送者的服务器通过这个已存在的流为这个外部域路由这个节到授权服务器 两个域之间不存在服务器间的流 发送者服务器 1 解析这个外部域的主机名 定义在服务器间的通信Server to Server Communications 第十四章第四节 2 在两个域之间进行服务器到服务器的流协商 定义在 Use of TLS 第五章 和 Use of SASL 第六章 然后 3 通过这个新建的流为外部域路由这个节到授权服务器 如果路由到接收者的服务器不成功 发送者的服务器必须 MUST 返回一个错误给发送者 如果接收者的服务器联系上了但是从接收者的服务器递送到接收者不成功 接收者服务器必须 MUST 通过发送者的服务器返回一个错误给发送者 子域 如果 to 属性中的JID的域ID部分的主机名和服务器自身配置的主机名的一个子域名匹配 服务器必须 MUST 自己处理这个节或路由这个节到专门负责这个子域的特定服务 如果子域被配置了 或者返回一个错误给发送者 如果子域没有配置 纯粹的域或特定的资源 如果 to 属性中的JID的域ID部分的主机名和服务器自身配置的主机名本身匹配 并且 to 属性中的JID类型是 domain 或 domain resource 服务器 或其中定于的资源 必须 MUST 根据节的类型适当的处理这个节或返回一个错误节给发送者 同一域中的节点 如果 to 属性中的JID的域ID部分的主机名和服务器自身配置的主机名本身匹配 并且 to 属性中的JID类型是 node domain 或 node domain resource 服务器应该 SHOULD 递送这个节到节的 to 属性中的JID所指明的预定的接收者 以下规则适用 如果这个JID包含一个资源ID 例如 格式是 node domain resource 并且存在一个连接的资源符合这个全JID 接收者服务器应该 SHOULD 递送这个节给正确符合这个资源ID的流或会话 如果这个JID包含一个资源ID 例如 格式是 node domain resource 并且不存在一个连接的资源符合这个全JID 接收者服务器应该 SHOULD 返回一个 service unavailable 节错误给发送者 如果这个JID的格式是 node domain 并且存在至少一个此节点的连接资源 接收服务器应该 SHOULD 递送这个节给至少其中一个已连接的资源 依据应用程序定义的规则 一系列即时消息和出席信息应用程序的递送规则定义在 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 XMPP中的XML用法 限制 XMPP是一个简单的流式XML元素的专用协议用于接近实时地交换结构化信息 因为XMPP不需要任意的解析和所有的XML文档 所以XMPP不需要支持 XML 的所有功能 特殊的 适用以下限制 关于XML生成 一个XMPP实现不能 MUST NOT 在XML流中注入以下任何东西 注释 第二章第五节 XML 处理指示 第二章第六节 同上 内部或外部的 DTD 子集 第二章第八节 同上 内部或外部的实体参考 第四章第二节 同上 除了预定实体以外 第四章第六节 同上 字符数据或属性值包含和预定实体列表中吻合的未逃逸的unescaped字符 第四章第六节 同上 这些字符必须 MUST 逃逸 关于XML处理 如果一个XMPP实现接收到这些受限的XML数据 它必须 MUST 忽略这些数据 XML 名字空间的名字和前缀 XML名字空间 XML NAMES 为所有XMPP兼容的XML建立数据所有权的严格界限 这个名字空间的基本功能是把结构上混合在一起的XML元素区分出不同的词汇 确保XMPP兼容的XML有名字空间的感知能力使得任何允许的XML可以被结构化的混合到任何XMPP数据元素中 XML名字空间的名字和前缀的规则在下一小节中 流名字空间 在所有的XML流头中必须声明一个流名字空间 流名字空间必须 MUST 是 http etherx jabber org streams 元素名 stream 和它的 features 和 error 子元素必须 MUST 在所有实例中符合这个流名字空间前缀 一个实现应该 SHOULD 只为这些元素生成 stream 前缀 并且由于历史原因可以 MAY 只接受 stream 前缀 缺省名字空间 在所有的XML流中必须声明一个缺省的流名字空间用于定义允许的流根元素的一级子元素 这个名字空间声明对于初始化流和应答流必须 MUST 是相同的使得双方的流都是合格一致的 缺省的名字空间声明适用于流和所有在流中发送的节 除非由流名字空间或回拨名字空间的前缀显式的符合另一个名字空间 一个服务器实现必须 MUST 支持以下两个缺省名字空间 由于历史原因 一些实现可能 MAY 只支持这两个缺省名字空间 jabber client 当流用于客户端和服务器的通信时声明这个缺省名字空间 jabber server 当流用于两个服务器间的通信时声明这个缺省名字空间 一个客户端实现必须 MUST 支持 jabber client 缺省名字空间 并且由于历史原因可以 MAY 只支持这个缺省名字空间 如果缺省名字空间是 jabber client 或 jabber server 一个实施不能 MUST NOT 在这个名字空间下为元素生成名字空间前缀 一个实现不应该 SHOULD NOT 按照元素的内容 可能和流相反 生成不同于 jabber client 和 jabber server 名字空间前缀 注意 jabber client 和 jabber server 名字空间接近于相同但是用于不同的上下文 客户端服务器通信用 jabber client 而服务器间通信用 jabber server 这两者之间仅有的不同在于在 jabber client 中被发送的节中 to 和 from 属性是可选的 OPTIONAL 而在 jabber server 中被发送的节中它们是必需的 REQUIRED 如果兼容的实施接受一个符合 jabber client 或 jabber server 名字空间的流 它必须 MUST 支持通用属性 第九章第一节 和三个核心节类型 message presence 和IQ 的基本语义 第九章第二节 回拨名字空间 所有用于服务器回拨的 第八章 元素都必须声明一个回拨名字空间 回拨名字空间的名字必须 MUST 是 jabber server dialback 所有符合此名字空间的元素必须 MUST 有前缀 一个实现应该 SHOULD 只为这些元素生成 db 前缀并且只可以 MAY 接受 db 前缀 确认 除了注意 jabber server 名字空间中关于节中 to 和 from 地址的规定 一个服务器不需要为转发到客户端或其他服务器负责检查XML元素 一个实现可以 MAY 选择仅提供有效数据元素但这是可选的 OPTIONAL 尽管一个实现不能 MUST NOT 接受不规范的XML 客户端不应该 SHOULD NOT 滥用发送不符合schema的数据的能力 并且应该 SHOULD 忽略接收到的XML流中任何和schema不一致的元素或属性值 XML流和节的有效性确认是可选的 OPTIONAL 并且在这里提到的schemas仅用于描述的用途 文本声明的包含 实现应该 SHOULD 在发送一个流头信息之前发送一个文本声明 应用程序必须 MUST 遵守 XML 中关于环境 那里对文本声明做了规定 的规则 字符编码 实现必须 MUST 支持通用字符集Universal Character Set ISO IEC 10646 1 UCS2 字符到UTF 8 RFC 3629 UTF 8 的转换 必须符合 RFC 2277 CHARSET 实现不能 MUST NOT 试图使用任何其他的编码 核心的兼容性要求 本章总结了可扩展的消息和出席信息协议中的某些方面 为了实施的兼容性 它们必须 MUST 被服务器和客户端支持 当然协议的其他方面也应该 SHOULD 被支持 为了兼容的目的 我们在核心协议 它必须 MUST 被任何服务器或客户端支持 无论是什么特定的应用 和即时消息协议 仅仅是在核心协议之上的即时消息和出席信息应用必须 MUST 支持它 之间划了一个级别 在本章中定义了所有服务器和客户端的兼容性要求 即时消息服务器和客户端的兼容性要求在 XMPP IM XMPP文档列表 XMPP正式RFC标准 RFC3921 的相关章节中定义 服务器 除了所有已定义的关于安全 XML使用 和国际化的要求之外 一个服务器还必须 MUST 支持以下核心协议以保证兼容性 在地址中应用 STRINGPREP 的 NAMEPREP Nodeprep 附录 A 和 Resourceprep 附录 B profiles 包括确保域ID是 IDNA 中定义的国际化域名 XML流 第四章 包括Use of TLS 第五章 Use of SASL 第六章 和Resource Binding 第七章 三个在stanza semantics 第九章第二节 中已定义的节类型 即 message presence 和 iq 的基本语义 生成错误的语法及相关的流 TLS SASL 和 XML节的语义 另外 一个服务器可以 MAY 支持以下核心协议 服务器回拨 第八章 客户端 一个客户端必须 MUST 支持以下核心协议以满足兼容性 XML流 第四章 包括Use of TLS 第五章 Use of SASL 第六章 和Resource Binding 第七章 三个在stanza semantics 第九章第二节 中已定义的节类型 即 message presence 和 iq 的基本语义 处理 并且 如果可能 生成 错误的语法及相关的流 TLS SASL 和 XML节的语义 另外 一个客户端应该 SHOULD 支持以下核心协议 地址的生成应用 STRINGPREP 的 NAMEPREP Nodeprep 附录 A 和 Resourceprep 附录 B profiles 国际化事项 XML流在Character Encoding 第十一章第五节 中定义为必须 MUST 被编码成UTF 8 在Stream Attributes 第四章第四节 中特别定义了 一个XML流应该 SHOULD 包含一个 xml lang 属性 它被认为是通过这个用于人类用户解读的流发送的任何XML字符数据的缺省语言 在 xml lang 第九章第一节第五小节 特别定义了 如果一个XML节是用来给人类用户解读 这个节应该 SHOULD 包含一个 xml lang 属性 服务器在为连接的实体路由或递送节的时候应该 SHOULD 应用缺省的 xml lang 属性 并且不能 MUST NOT 修改或删除它从其他实体收到的节的 xml lang 属性 安全性事项 高安全性 为了XMPP通信的目的 客户端 服务器 和 服务器 服务器 高安全性 条款谈的是相互验证和完整性检查安全性技术的使用 特别是 当使用基于证书的验证来提供高安全性 应该 SHOULD 建立一个带外的信任链 尽管一个共享签名证书可能允许以前不知道的证书在带内建立信任关系 参见以下第十四章第二节关于证书确认程序 实施必须 MUST 支持高安全性 服务提供者应该 SHOULD 基于本地安全策略使用高安全性 证书确认 当一个XMPP点和另一个XMPP点安全的地通信 它必须 MUST 确认对方终端的证书 有三种可能的情况 情形 1 点包含一个终端实体证书 以根证书的证书链中一环出现 见 X509 中的第六章第一节 情形 2 点的证书由一个对方不知道的证书授权 情形 3 点的证书由自己签名 在情形 1 确认方必须 MUST 做以下两条之一 根据 X509 的规则确认对方证书 然后证书应该 SHOULD 被对方接下来在 HTTP TLS 中描述的规则反向确认预期的身份 但如果 xmpp 是subjectAltName扩展类型 则必须 MUST 使用证书中的显示的身份 如果这两项检查之一失败 用户导向的客户端必须 MUST 通知用户 客户端可以 MAY 给用户机会继续连接 或以一个坏证书的错误终止连接 自动客户端应该 SHOULD 终止连接 以一个坏证书错误 并在适当的日志中记录这个错误 自动客户端可以 MAY 提供一个配置设置成禁止检查 但同时必须 MUST 提供一个激活检查的配置 点应该 SHOULD 出示证书给一个用户用于批准 包括完整的证书链 点必须 MUST 缓存这个证书 或一些其他不会忘记的表达方式比如一个哈希值 在将来的连接中 点必须 MUST 展示相同的证书并且如果改变了证书必须 MUST 通知用户 在情形 2 和情形 3 实现应该 SHOULD 执行上述第二条 客户端 服务器通信 一个兼容的客户端实现必须 MUST 支持TLS和SASL用于连接到服务器 用于加密XML流的TLS协议 在 Use of TLS 第五章 定义 提供可信的机制帮助确保机密性和实体之间数据交换的完整性 用于验证XML流的SASL协议 在 Use of SASL 第六章 定义 提供可靠的机制用于确认一个连接到服务器的客户端确实是它自己所声明的那个客户端 服务器宣称的DNS主机名被解析之前 客户端 服务器通信不能 MUST NOT 继续进行 应该首先尝试解析 SRV 记录 其服务名为 xmpp client 协议名为 tcp 整个资源记录类似 xmpp client tcp example com 使用字符 xmpp client 表示服务ID是经过IANA注册 如果SRV查找失败 退而求其次 将查找一个正规的IPv4 IPv6地址记录来决定IP地址 使用 xmpp client 端口5222 这个端口是在IANA注册了的 客户端的IP地址和访问方法不能 MUST NOT 被服务器公开 也不能被被任何原始服务器之外的服务器索取 这帮助保护客户端的服务器避免受到直接攻击 译者注 似乎应该是客户避免受到直接攻击 但原文如此 或被第三方知道它的身份 服务器 服务器通信 一个兼容的服务器实现必须 MUST 支持TLS和SASL 用于域间的通信 因为历史原因 一个兼容的实施也应该 SHOULD 支持服务器回拨 第八章 因为服务提供者是一个策略问题 对于任何给定域和其他域的通信中 它是可选的 OPTIONAL 服务器之间的通信可以 MAY 被任何特定部署的管理员禁止 如果一个特殊的域允许域间的通信 它应该 SHOULD 允许高安全性 管理员可能想在服务器间使用SASL来通信 以确保双方的验证和保密性 比如在机构的私有网络 兼容实施应该 SHOULD 为这个目的支持SASL 服务器宣称的DNS主机名被解析之前 服务器 服务器通信不能 MUST NOT 继续进行 应该首先尝试解析 SRV 记录 其服务名为 xmpp server 协议名为 tcp 整个资源记录类似 xmpp server tcp example com 使用字符 xmpp server 表示服务ID是经过IANA注册的 注意要用 xmpp server 取代以前用的 jabber 因为以前的用法不符合 SRV 标准 希望保持向后兼容的实现可以继续查找或应答 jabber 服务ID 如果SRV查找失败 退而求其次 将查找一个正规的IPv4 IPv6地址记录来决定IP地址 使用 xmpp server 端口5269 这个端口是在IANA注册了的 服务器回拨防止域欺骗 从而使得伪造XML节更为困难 它和SASL和TLS不一样 它不是一个用于验证 安全或加密服务器之间的流的机制 所以只是服务器身份的微弱确认而已 而且除非它使用了DNSSec DNSSEC 否则它 容易受到DNS中毒攻击 即使DNS信息是正确的 如果攻击者劫持了远程域 回拨也不能防止它的攻击 需要健壮的安全性的域应该 SHOULD 使用TLS和SASL 如果服务器间的验证使用了SASL 回拨就不应该 SHOULD NOT 使用了 因为它是多余的 层的次序 协议中的层的次序必须 MUST 如下堆积 TCP TLS SASL XMPP 这个次序的原理是 TCP 是基于连接的层 被所有使用 所以处于最上层 TLS 经常是由操作系统层提供 SASL 经常由应用程序层提供 XMPP则是应用程序本身 缺乏绑定到TLS的SASL通道 SASL构架不提供一个机制来绑定SASL验证到一个提供机密性和完整性保护的安全层 这一通道绑定 channel binding 的缺乏阻碍了SASL确认低层安全性所绑定的源和目标终端和SASL所验证的结果是否一致 如果终端不一致 低层安全性不能被信任用来保护SASL验证的实体之间的数据传输 在这种情况下 一个SASL安全层进行握手的时候应该有效的忽略低层安全性的存在 强制实现的技术 最低要求 所有实现必须 MUST 支持以下机制 对于验证 SASL DIGEST MD5 机制 对于机密性 TLS 使用 TLS RSA WITH 3DES EDE CBC SHA 密码 对于两者 TLS 加 SASL EXTERNAL 使用 TLS RSA WITH 3DES EDE CBC SHA 密码支持客户端证书 防火墙 使用XMPP通信通常是通过 TCP 连接到5222端口 客户端 服务器 或5269端口 服务器 服务器 正如在IANA注册的那样 见 IANA Considerations 第十五章 使用这些广为人知的端口允许管理员很容易的通过一般的防火墙来激活或禁止XMPP活动 在SASL中使用base64 客户端和服务器都必须 MUST 确认在SASL协商中收到的任何 BASE64 数据 一个实现必须 MUST 拒绝 不是忽略 任何非显式允许base64字母的字符串 这有助于预防建立隐蔽通道泄漏信息的行为 一个实现不能 MUST NOT 在非法输入处中断 如果那个 被包含在一些和最后的数据字符 如 AAA or BBBB CCC 不同的东西里面 必须 MUST 拒绝接下来的任何包含 的base64字符 这有助于防止对这个实现的缓存溢出攻击和其他攻击 Base 64编码从外表看隐藏了容易辨认的信息 例如密码 但是不提供任何算法机密性 Base 64编码必须 MUST 按照 RFC 3548 BASE64 第三章的定义执行 Stringprep Profiles 为了处理域ID XMPP使用了 STRINGPREP 中的 NAMEPREP profile 和Nameprep有关的安全性考虑 参考 NAMEPREP 中的相关章节 另外 XMPP 定义了两个 STRINGPREP 的 profiles 用于node identifiers的Nodeprep 附录 A 和用于resource identifiers的Resourceprep 附录 B Unicode 和 ISO IEC 10646 集有许多字符看起来相似 在许多时候 安全协议的使用者可能看起来吻合 比如当比较信任的第三方的名字的时候 因为没有很多上下文的时候不可能映射看起来相似的字符 比如知道所用的字符集 stringprep不匹配相似字符串 也不因为一些字符串象看起来象别的字符串而禁止它们 一个节点ID可能被作为一个实体的XMPP地址的一部分 一个通常的用途是作为一个即时消息用户的用户名 另一个用途是作为一个多用途聊天室的名字 很多其他种类的实体可能使用节点ID作为他们的地址的一部分 这些服务的安全性可能会受到国际化节点ID的不同表达的威胁 例如 一个用户键入一个单独的国际化的节点ID可能访问了另一个用户的帐号信息 或一个用户可能获得访问一个受限的聊天室或服务的访问权限 一个资源ID可能被作为一个实体的XMPP地址的一部分 一个通常的用户是即时消息用户所连接的资源 激活的会话 的名字 另一个是作为多用户聊天室的某用户的昵称 许多其他种类的实体可能使用资源ID作为他们地址的一部分 这些服务的安全性可能会受到国际化资源ID的不同表达的威胁 例如 一个用户可能尝试以同一个名字初始化多个会话 或一个用户可能发送一个消息给多用户聊天室的一个人但实际上发给了另外一个人 IANA 事项 用于TLS数据的XML名字空间名 XMPP中用于TLS相关数据的 URN 子名字空间定义如下 这个名字空间的名字遵守The IETF XML Registry XML REG 定义的格式 URI urn ietf params xml ns xmpp tls Specification RFC 3920 Description This is the XML namespace name for TLS related data in the Extensible Messaging and Presence Protocol XMPP as defined by RFC 3920 Registrant Contact IETF XMPP Working Group xmppwg jabber org 用于SASL数据的XML名字空间名 XMPP中用于SASL相关数据的 URN 子名字空间定义如下 这个名字空间的名字遵守The IETF XML Registry XML REG 定义的格式 URI urn ietf params xml ns xmpp sasl Specification RFC 3920 Description This is the XML namespace name for SASL related data in the Extensible Messaging and Presence Protocol XMPP as defined by RFC 3920 Registrant Contact IETF XMPP Working Group xmppwg jabber org 用于流错误的XML名字空间名 XMPP中用于流相关错误的 URN 子名字空间定义如下 这个名字空间的名字遵守The IETF XML Registry XML REG 定义的格式 URI urn ietf params xml ns xmpp streams Specification RFC 3920 Description This is the XML namespace name for stream related error data in the Extensible Messaging and Presence Protocol XMPP as defined by RFC 3920 Registrant Contact IETF XMPP Working Group xmppwg jabber org 用于资源绑定的XML名字空间名 XMPP中用于资源绑定的 URN 子名字空间定义如下 这个名字空间的名字遵守The IETF XML Registry XML REG 定义的格式 URI urn ietf params xml ns xmpp bind Specification RFC 3920 Description This is the XML namespace name for resource binding in the Extensible Messaging and Presence Protocol XMPP as defined by RFC 3920 Registrant Contact IETF XMPP Working Group xmppwg jabber org 用于节错误的XML名字空间名 XMPP中用于节相关错误数据的 URN 子名字空间定义如下 这个名字空间的名字遵守The IETF XML Registry XML REG 定义的格式 URI urn ietf params xml ns xmpp stanzas Specification RFC 3920 Description This is the XML namespace name for stanza related error data in the Extensible Messaging and Presence Protocol XMPP as defined by RFC 3920 Registrant Contact IETF XMPP Working Group xmppwg jabber org Nodeprep Profile of Stringprep The Nodeprep profile of stringprep是在Nodeprep 附录 A 定义的 IANA已经在stringprep profile registry中注册了 Nodeprep Name of this profile Nodeprep RFC in which the profile is defined RFC 3920 Indicator whether or not this is the newest version of the profile This is the first version of Nodeprep Resourceprep Profile of Stringprep The Resourceprep profile of stringprep是在Resourceprep 附录 B 定义的 IANA已经在stringprep profile registry中注册了Resourceprep Name of this profile Resourceprep RFC in which the profile is defined RFC 3920 Indicator whether or not this is the newest version of the profile This is the first version of Resourceprep GSSAPI 服务名 IANA已经注册了 xmpp 作为一个 GSSAPI GSS API 服务名 在SASL Definition 第六章第三节 定义了 端口号 IANA已经注册了 xmpp client 和 xmpp server 作为 TCP 端口号5222和5269的关键字 这些端口应该 SHOULD 用于客户端 服务器 和 服务器 服务器通信 但它们的使用是可选的 OPTIONAL 参考 标准化参考 ABNF Crocker D and P Overell Augmented BNF for Syntax Specifications ABNF RFC 2234 November 1997 BASE64 Josefsson S The Base16 Base32 and Base64 Data Encodings RFC 3548 July 2003 CHARSET Alvestrand H IETF Policy on Character Sets and Languages BCP 18 RFC 2277 January 1998 DIGEST MD5 Leach P and C Newman Using Digest Authentication as a SASL Mechanism RFC 2831 May 2000 DNS Mockapetris P Domain names implementation and specification STD 13 RFC 1035 November 1987 GSS API Linn J Generic Security Service Application Program Interface Version 2 Update 1 RFC 2743 January 2000 HTTP TLS Rescorla E HTTP Over TLS RFC 2818 May 2000 IDNA Faltstrom P Hoffman P and A Costello Internationalizing Domain Names in Applications IDNA RFC 3490 March 2003 IPv6 Hinden R and S Deering Internet Protocol Version 6 IPv6 Addressing Architecture RFC 3513 April 2003 LANGTAGS Alvestrand H Tags for the Identification of Languages BCP 47 RFC 3066 January 2001 NAMEPREP Hoffman P and M Blanchet Nameprep A Stringprep Profile for Internationalized Domain Names IDN RFC 3491 March 2003 RANDOM Eastlake 3rd D Crocker S and J Schiller Randomness Recommendations for Security RFC 1750 December 1994 SASL Myers J Simple Authentication and Security Layer SASL RFC 2222 October 1997 SRV Gulbrandsen A Vixie P and L Esibov A DNS RR for specifying the location of services DNS SRV RFC 2782 February 2000 STRINGPREP Hoffman P and M Blanchet Preparation of Internationalized Strings stringprep RFC 3454 December 2002 TCP Postel J Transmission Control Protocol STD 7 RFC 793 September 1981 TERMS Bradner S Key words for use in RFCs to Indicate Requirement Levels BCP 14 RFC 2119 March 1997 TLS Dierks T and C Allen The TLS Protocol Version 1 0 RFC 2246 January 1999 UCS2 International Organization for Standardization Information Technology Universal Multiple octet coded Character Set UCS Amendment 2 UCS Transformation Format 8 UTF 8 ISO Standard 10646 1 Addendum 2 October 1996 UTF 8 Yergeau F UTF 8 a transformation format of ISO 10646 STD 63 RFC 3629 November 2003 X509 Housley R Polk W Ford W and D Solo Internet X 509 Public Key Infrastructure Certificate and Certificate Revocation List CRL Profile RFC 3280 April 2002 XML Bray T Paoli J Sperberg McQueen C and E Maler Extensible Markup Language XML 1 0 2nd ed W3C REC xml October 2000 http www w3 org TR REC xml XML NAMES Bray T Hollander D and A Layman Namespaces in XML W3C REC xml names January 1999 http www w3 org TR REC xml names 信息参考 ACAP Newman C and J Myers ACAP Application Configuration Access Protocol RFC 2244 November 1997 ASN 1 CCITT Recommendation X 208 Specification of Abstract Syntax Notation One ASN 1 1988 DNSSEC Eastlake 3rd D Domain Name System Security Extensions RFC 2535 March 1999 HTTP Fielding R Gettys J Mogul J Frystyk H Masinter L Leach P and T Berners Lee Hypertext Transfer Protocol HTTP 1 1 RFC 2616 June 1999 IMAP Crispin M INTERNET MESSAGE ACCESS PROTOCOL VERSION 4rev1 RFC 3501 March 2003 IMP REQS Day M Aggarwal S Mohr G and J Vincent Instant Messaging Presence Protocol Requirements RFC 2779 February 2000 IRC Oikarinen J and D Reed Internet Relay Chat Protocol RFC 1459 May 1993 JEP 0029 Kaes C Definition of Jabber Identifiers JIDs JSF JEP 0029 October 2003 JEP 0078 Saint Andre P Non SASL Authentication JSF JEP 0078 July 2004 JEP 0086 Norris R and P Saint Andre Error Condition Mappings JSF JEP 0086 February 2004 JSF Jabber Software Foundation Jabber Software Foundation http www jabber org POP3 Myers J and M Rose Post Office Protocol Version 3 STD 53 RFC 1939 May 1996 SIMPLE SIMPLE Working Group SIMPLE WG http www ietf org html charters simple charter html SMTP Klensin J Simple Mail Transfer Protocol RFC 2821 April 2001 URI Berners Lee T Fielding R and L Masinter Uniform Resource Identifiers URI Generic Syntax RFC 2396 August 1998 USINGTLS Newman C Using TLS with IMAP POP3 and ACAP RFC 2595 June 1999 XML REG Mealling M The IETF XML Registry BCP 81 RFC 3688 January 2004 RFC3921 Saint Andre P Ed Extensible Messaging and Presence Protocol XMPP Instant Messaging and Presence RFC 3921 October 2004 附录 A Nodeprep A 1 介绍 这个附录定义了 Nodeprep profile of STRINGPREP 它定义了处理规则让用户能够在XMPP中输入国际化节点标识符并尽可能正确的获取正确的字符内容 一个XMPP节点标识符是XMPP地址的可选部分 它在域名标识符和那个 分隔符之前 它经常但不是专门用来关联一个即时消息用户名 这些处理规则仅仅适用于XMPP节点标识符但不适用于任意文本或任何XMPP的其他方面 这个脚本定义了以下这些 正如 STRINGPREP 要求的 脚本预期的适用性 XMPP的国际化节点标识符 用于stringprep的输入输出字符集 Unicode 3 2 定义在本附录的第二章 使用的映射 定义在第三章 Unicode正规化使用 定义在第四章 禁止输出的字符串 定义在第五章 双字节字符处理 定义在第六章 A 2 字符集 本脚本使用Unicode 3 2的未分配编码列表 指向 Table A 1 也定义在 STRINGPREP 的附录 A 中 A 3 映射 本脚本指定使用 STRINGPREP 的以下表 Table B 1 Table B 2 A 4 正规化 本脚本指定 Unicode正规化使用 form KC 定义在 STRINGPREP 中 A 5 禁止输出 本脚本指定使用以下的 STRINGPREP 表禁止输出 Table C 1 1 Table C 1 2 Table C 2 1 Table C 2 2 Table C 3 Table C 4 Table C 5 Table C 6 Table C 7 Table C 8 Table C 9 另外 以下Unicode字符也被禁止 x22 x26 x27 x2F x3A x3C x3E x40 A 6 双字节 本脚本指定按照 STRINGPREP 第六章检查双字节 附录 B Resourceprep B 1 介绍 这个附录定义了 Resourceprep profile of STRINGPREP 它定义了处理规则让用户能够在XMPP中输入国际化资源标识符并尽可能正确的获取正确的字符内容 一个XMPP资源标识符是XMPP地址的可选部分 它在域名标识符和 分隔符之后 它经常但不是专门用来关联一个即时消息会话名 这些处理规则仅仅适用于XMPP资源标识符但不适用于任意文本或任何XMPP的其他方面 这个脚本定义了以下这些 正如 STRINGPREP 要求的 脚本预期的适用性 XMPP的国际化节点标识符 用于stringprep的输入输出字符集 Unicode 3 2 定义在本附录的第二章 使用的映射 定义在第三章 Unicode正规化使用 定义在第四章 禁止输出的字符串 定义在第五章 双字节字符处理 定义在第六章 B 2 字符集 本脚本使用Unicode 3 2的未分配编码列表 指向 Table A 1 也定义在 STRINGPREP 的附录 B 3 映射 本脚本指定使用 STRINGPREP 的以下表 Table B 1 B 4 正规化 本脚本指定使用 Unicode normalization form KC 定义在 STRINGPREP 中 B 5 禁止输出 本脚本指定使用以下的 STRINGPREP 表禁止输出 Table C 1 2 Table C 2 1 Table C 2 2 Table C 3 Table

    Original URL path: http://wiki.jabbercn.org/RFC3920 (2016-04-25)
    Open archived version from archive



  •