XEP-0114

本文的英文原文来自[1]

XEP-0114: Jabber组件协议

摘要：本文档定义了jabber网络上的Servers与外部组件之间的通讯。

作者: Peter Saint-Andre

版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.

现状: 活跃

类型: 历史

版本: 1.5

最后更新: 2005-03-03

注意：这个历史的规范提供了目前在Jabber/XMPP社区中使用的一个协议.本文不是XMPP标准化基金会标准跟踪过程中的标准跟踪协议,不过,将来它可能被转化为标准跟踪,也可能被一个更新的协议取代。

简介

很久之前jabber网络就包含了使受信任的外部组件能够连接到jabber服务器的协议框架。虽然这些组件协议很简单而且可能在某个时刻被更全面的组件协议替代，但是现有的协议文档还是对开发组件和服务器很有帮助。本规范提供了这样的文档。

概念

传统上有两种完全不同的服务器端组件类型：内部组件（即在过去特别是jabberd[1]那样， 利用服务器的内部API提供服务）和外部组件（组件在一个协议框架上与服务器联系，因此不依赖任何特定的服务器实现）. 目前使用的组件协议框架使得一个外部组件能够连接到一个服务器（通过适当的配置和验证）并能通过服务器发送和接收XML节。有两种连接方法：“accept”和“connect”。使用“accept”方法时，服务器等待并接受被组件初始化的连接。使用“connect”方法时，由服务器初始化到组件的连接。目前“accept”方法最常用，但是这两者方法在文档都会被提及。（从前还有一种针对外部组件的连接方法“execute”，当时已经过时，因此在文档中不会提及。） 外部组件被称作“trusted”因为使用证书包含一个共享密钥与服务器进行认证，这个被服务器和组件使用的密钥通常在配置文件中指定，但是 可以运行时通过命令行提供或从数据库提取。外部组件是被普遍信任的，能做一些客户端不能做的事情，，如写‘from’地址为服务器的域名(S).也有些服务器允许组件使用内部协议发送数据包（例如，jabberd 1.x系列中的<log/>和<xdb/>数据包），但是这些内部协议超出了本文的范围。

处理流程

 jabber : component : *   命名空间与    jabber ：client   和   jabber ：server  命名空间的主要不同在于认证。外部组件不使用过时的 Non-SASL认证协议（例如： jabber ： iq ：auth   命名空间），也还没有使用在XMPP核心中定义的SASL认证（虽然组件协议未来可能会使用SASL）。相反，他们使用一种特殊的<handshake/>元素的XML字符数据指定为组件与服务器的会话凭证。使用 jabber：component：accept的流协商认证处理流程如下：

例1.组件发送流头到服务器

<stream:stream
    xmlns='jabber:component:accept'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='plays.shakespeare.lit'>

注意：在'jabber：component：accept'命名空间，'to'地址的值是组建的名字,不是服务器的名字; 这使得服务器能够确认该名称对应的提供服务的组件（例如，基于服务器的配置或其他特定的实现机制）。如果是这样，服务器必须（MUST）响应一个流头（stream header）。

例2,服务响应流头，包含一个流ID

<stream:stream
    xmlns:stream='http://etherx.jabber.org/streams'
    xmlns='jabber:component:accept'
    from='plays.shakespeare.lit'
    id='3BF96D32'>

如果服务器在流头（stream header）的‘to’属性中的组件名没有提供服务，服务器必须（MUST）返回一个错误流（例如，<conflict/> 或 <host-unknown/>）.如果服务器不识别或支持流头（stream header）指定的命名空间（例如，不支持‘jabber:component:accept’命名空间中的流），服务器必须（MUST）返回一个<invalid-namespace/>错误流。对于与流头（stream header）相关的所有错误，服务器必须（MUST）按照XMPP核心的4.7.1节中规定的返回一个开放的流标签，错误流元素，和流关闭标签，而不仅仅是一个流错误元素（详细信息参看RFC 3920）。

当收到服务器发回的流头（stream header），组件必须（MUST）发送带上适当内容的<handshake/>元素。

例3,组件发送handshake元素'

<handshake>aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e</handshake>

handshake元素中带的XML字符串信息根据以下算法生成： 1,将流ID与从服务器收到的共享密钥连接（如果有必要，字符串映射到预定义的XML实体必须根据XML规范4.6节中的规则进行转义，并且任何非ACSII字符必须根据XMPP核心中指定的XML流编码规则进行编码，例如RFC3269中指定的UTF-8）。 2,根据连接的字符串使用SHA1算法进行哈希，例如，SHA1（concat(sid,password)）. 3,确保哈希输出16进制格式，而不是二进制或Base64。 4,将哈希输出都转换为小写。

如果由发起人提供的凭据无效，接收者必须（MUST）关闭流和底层TCP连接，并应该（SHOULD）返回<not-authorized/>错误流。

如果凭据被接受，接收应用（在这里是服务器）必须（MUST）返回一个空的<handshake/>元素。