查看源代码

[[Category:XMPP扩展]]
[[Category:翻译中]]

'''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0144.html XEP-0144]'''

'''XEP-0144 ：名册条目交换'''

摘要: 本协议定义了一个XMPP协议扩展, 这个规范定义了一个协议的扩展，用于交换联系人列表条目，包括以下能力,建议条目是否要被添加，删除或在接收者的联系人列表中修改，以及建议该条目所在的名册组。

作者: Peter Saint-Andre

版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见[[XEP-0144#附录C:法律通告|法律通告]]. 

状态: 草案 

类型: 标准跟踪 

版本: 1.0

最后更新日期: 2005-08-26

--------------------------------------------------------------------------------

注意: 这里定义的协议是XMPP标准化基金会的一个'''草案标准'''.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
 
--------------------------------------------------------------------------------

==绪论==

Jabber协议早有一种方法，将名册条目从一个实体发送到另一个，使用'jabber:x:roster'命名空间。因为这个协议扩展对[http://tools.ietf.org/html/rfc2779 RFC 2779] [[XEP-0144#附录G:备注|1]]不是必需的，它被移出了[[RFC6121|XMPP IM]] [[XEP-0144#附录G:备注|2]], 并且出于历史原因记录在[http://xmpp.org/extensions/xep-0093.html Roster Item Exchange] [[XEP-0144#附录G:备注|3]]中。 无论如何，那次在[http://mail.jabber.org/mailman/listinfo/standards/  Standards SIG] [[XEP-0144#附录G:备注|4]]中的讨论展现出使用名册条目交换有助于解决"共享组"（例如，在用于一个组织的预定义名册组）方面的问题以及名册同步（例如，保持一个Jabber名册和位于外部IM服务上的一个联系人列表同步）方面的问题。这些领域的问题，要求一种比XEP-0093中记录的方法更加精密些的名册条目交换，特别是指示一个名册项目是否要被添加，删除或修改的能力。因此，本文重定义了名册条目交换以一种向后兼容现有实现的方式来提供此功能，虽然使用了一个现代的命名空间的URI 'http://jabber.org/protocol/rosterx'，而不是旧的'Jabber：x：roster'名字空间名字。更多的规范将定义如何使用这里定义的协议来解决共享组和名册同步的问题.

==需求==

XEP-0093未定义名册条目交换的需求. 本章纠正了那个疏忽.

名册条目交换满足以下要求:

:# 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议把那个名册条目(们)加入到接收者的名册.
:# 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议把那个名册条目(们)从接收者的名册中删除.
:# 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议在接收者的名册中修改那个名册条目(们).

本文故意讲到名册和名册条目, 而不是出席信息订阅. 尽管名册和订阅是紧密连接的(如'''RFC 3921'''解释的), 它们不是同一的. 这里定义的协议允许一个实体建议另一个实体只添加, 删除, 或修改名册条目, 而不指示和那些名册条目相关的建议的出席信息订阅状态.

==用例==
===建议名册条目添加===

为了程序化地建议接收实体应该添加一个或多个条目到它的名册中, 发送实体必须发送一个包含由'http://jabber.org/protocol/rosterx'命名空间限定的<x/>元素的<message/>或<iq/>节(关于什么时候使用<message/>什么时候使用<iq/>，见[[XEP-0144#推荐的节类型|推荐的节类型]]); 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个都应该拥有一个值为"add"的'action'属性 [[XEP-0144#附录G:备注|5]], 必须拥有一个'jid'属性来指定被添加的条目的JabberID, 可以拥有一个'name'属性来指定一个用于该条目的自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来指定存放该条目的名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这里是例子:

'''例子 1. 建议添加'''

<source lang="xml">
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
  <body>Some visitors, m'lord!</body>
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action='add'
          jid='rosencrantz@denmark.lit'
          name='Rosencrantz'>
      <group>Visitors</group>
    </item>
    <item action='add'
          jid='guildenstern@denmark.lit'
          name='Guildenstern'>
      <group>Visitors</group>
    </item>
  </x>
</message>
</source>    

在确定如何处理任何给定的'action'属性值为"add"(要么显式地要么作为缺省值)的名册条目时, 接收的应用应该处理如下:

:# 如果该条目已经存在于名册中并且该条目在指定的组中(或没有指定组), 该接收应用不能(MUST NOT)提示一个自然人用户批准那个条目并且不能(MUST NOT)添加那个条目到名册.
:# 如果该条目不在名册中, 该接收应用应该提示一个自然人用户批准那个条目, 并且，如果批准被授权, 必须添加该条目到名册中.
:# 如果该条目已经在名册中但是不在指定的组中, 该接收应用可以提示该用户批准并且应该编辑现有的条目使得它也将属于该指定组(如果有现有的组，就在现有的组的基础上额外加上).

如果该名册条目添加节将导致添加该条目到名册, 该接收应用必须(要么由一个自然人用户批准要么自动遵循配置)发送一个包含新条目的如'''RFC 3921'''所述的roster set给该用户的服务器. 完成该roster set之后, 该接收应用也应该发送一个类型为"subscribe"的<presence/>节给该新条目的JID.

对于当一个名册条目添加节实际导致编辑一个现有的名册条目的时候，推荐的应用程序行为, 参考本文的[[XEP-0144#建议名册条目修改|建议名册条目修改]].

===建议名册条目删除===

为了程序化地建议接收实体应该从它的名册删除一个或多个条目, 发送实体必须发送一个包含由'http://jabber.org/protocol/rosterx'命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个必须拥有一个值为"delete"的'action'属性, 必须拥有一个'jid'属性来指定要被删除的条目的JabberID, 可以拥有一个'name'属性来为该条目指定一个自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来为该条目指定名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这是一个例子:

'''例子 2. Suggesting Deletion'''

<source lang="xml">
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action='delete'
          jid='rosencrantz@denmark'
          name='Rosencrantz'>   
       <group>Visitors</group>   
     </item>     
     <item action='delete'       
           jid='guildenstern@denmark'    
           name='Guildenstern'>          
       <group>Visitors</group>   
     </item>
  </x>
</message>
</source>    

在确定如何处理任何给定的'action'属性值为"delete"的名册条目时, 接收应用应该处理如下:

:# 如果该条目不存在于名册中, 该接收应用不能(MUST NOT)提示一个自然人用户批准关于那个条目并且不能(MUST NOT)从名册删除那个条目.
:# 如果该条目存在于名册中但是不指定的组中, 该接收应用不能(MUST NOT)提示该用户批准并且不能(MUST NOT)删除该现有的条目.
:# 如果该条目存在于名册中并且同时存在于指定的组和另一个组中, 该接收应用可以提示该用户批准并且编辑现有的条目使得它不再属于指定的组.

如果该条目被删除了, 该接收应用应该从名册移除该条目，通过发送一个'subscription'属性值设为"remove"的如'''RFC 3921'''所述的roster set给该用户的服务器, 因为这导致该用户的服务器生成适当的<presence/>节.

===建议名册条目修改===

为了程序化地建议接收实体应该从它的名册中修改一个或多个条目, 发送实体必须发送一个包含由'http://jabber.org/protocol/rosterx'命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个都应该拥有一个值为"modify"的'action'属性, 必须拥有一个'jid'属性来指定被修改的条目的JabberID, 可以拥有一个'name'属性来指定一个用于该条目的自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来指定存放该条目的名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这里是例子:

'''例子 3. 建议修改'''

<source lang="xml">
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action='modify'
          jid='rosencrantz@denmark.lit'
          name='Rosencrantz'>
      <group>Retinue</group>
    </item>
    <item action='modify'
          jid='guildenstern@denmark.lit'
          name='Guildenstern'>
      <group>Retinue</group>
    </item>
  </x>
</message>
</source>    

在确定如何处理任何给定的'action'属性值为"modify"的名册条目时, 接收的应用应该处理如下:

:# 如果该条目不在名册中, 该接收应用不能(MUST NOT)提示一个自然人用户批准那个条目, 并且不能(MUST NOT)添加该添加该条目到名册中.
:# 如果该条目已经存在于名册中并且该修改将只导致组的变更, 该接收应用可以提示该用户批准并且应该把该条目移动到指定的组.
:# 如果该条目已经存在于名册中并且该修改将导致再添加该条目到一个（在它现有的组以外的）新组, 该接收应用可以该用户批准并且应该添加那个条目到指定的组.
:# 如果该条目已经存在于名册中并且该修改将只导致名称的变更, 该接收应用可以提示该用户批准并且应该把该条目改成修改建议中指定的名称.


如果一个名册条目添加，删除，或修改节将导致编辑一个名册中已有的条目, 该接收应用必须(要么由一个自然人用户批准要么自动遵循配置)发送一个roster set给该用户的服务器, 其'subscription'属性不变, 'name'改为适当的值，或者携带<group/>子元素（们），如'''RFC3921'''所述.

==服务查询==

为了确定是否一个接收实体支持这里定义的协议, 发送实体应该使用[[XEP-0030|服务查询]] [[XEP-0144#附录G:备注|6]] 但可以依赖[[XEP-0115|实体能力]] [[XEP-0144#附录G:备注|7]]定义的服务查询的"profile". 如果一个实体支持名册条目交换, 它必须(遵循如[[XEP-0144#声明支持|声明支持]]所述的适当的安全事项)在它对对 disco#info 查询的应答中包含 <feature var='http://jabber.org/protocol/rosterx'/>. 于是一个发送实体能查询是否一个接收实体支持这里定义的协议，通过发送一个如下格式的IQ请求:

'''例子 4. 发送实体查询支持'''

<source lang="xml">
<iq from='horatio@denmark.lit/castle'
    to='hamlet@denmark.lit/throne'
    type='get'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
</source>  

接收实体接着表示它的支持:

'''例子 5. 接收实体声明支持'''

<source lang="xml">
<iq from='hamlet@denmark.lit/throne'
    to='horatio@denmark.lit/castle'
    type='get'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/rosterx'/>
    ...
  </query>
</iq>
</source>  

==推荐的节类型==

如果发送实体拥有关于接收实体在线和可用的信息(例如, 通过出席信息或一个活跃的聊天交谈), 它应该: [[XEP-0144#附录G:备注|8]]

:# 查询是否接收实体支持这里定义的协议(参见本文的[[XEP-0144#服务查询|服务查询]]章节).
:# 如果支持, 发送它的名册条目交换节给接收实体的一个特定资源(user@host/resource)，使用<iq/>节而不是<message/>节.

如果发送实体不知道接收实体在线和可用, 它必须发送一个<message/>节给接收实体的"纯JID" (user@host)而不是发送<iq/>节给一个特定的资源.

===IQ语义===

如果发送实体使用<iq/>节来和通讯它的名册条目交换建议, 接收实体必须遵循[[RFC6120|XMPP核心]] [[XEP-0144#附录G:备注|9]]定义的IQ语义. 特别是:

:# 如果接收实体成功地处理了该建议动作(这可能包括忽略特定的建议), 该接收实体必须返回一个空的IQ result给发送实体.
:# 如果接收实体不理解名册交换命名空间, 该接收实体必须返回一个错误给发送实体, 这个错误应该是<service-unavailable/>.
:# 如果接收实体不处理建议的动作(们)是因为该接收实体没有注册到发送实体, 该接收实体必须返回一个错误给发送实体, 这个错误应该是<registration-required/>.
:# 如果接收实体不处理建议的动作(们)是因为发送实体不在接收实体的名册中, 该接收实体必须返回一个错误给发送实体,这个错误应该是<not-authorized/>.
:# 如果接收实体不处理建议的动作(们)是因为发送实体不被信任(见[[XEP-0144#信任的实体|信任的实体]]), 该接收实体必须返回一个错误给发送实体, 这个错误应该是<forbidden/>.

当然, 可能其他IQ错误是更合适的; 无论如何, 如果接收实体将不会或不能处理建议的动作(们), 它必须返回一个错误给发送实体.


==商业规则==

:# 发送实体或发送应用不能(MUST NOT)在同一个<x/>元素和<message/>或 <iq/>节中发送additions, deletions, 和 modifications; 反之, 它应该为additions, deletions, 和 modifications分别发送单独的节.
:# 如果必须或建议批准多个由发送实体建议的条目, 接收实体应该在同一时间或在同一界面展示所有的条目来批准.
:# 如果发送实体是所谓"被信任的"(见[[XEP-0144#信任的实体|信任的实体]]), 那么该接收应用可以跳过上述的批准步骤.
:# 同一时间内接收的应用不应该(SHOULD NOT)从任何一个发送实体接受不合理数量的名册条目. 不幸的是, 很难确定多大的名册条目数量是"不合理的". 例如, 当一个用户注册到一个网关, 名册条目的初始设置可能是非常大量的(无论如何, 注意大多数现有的消费者IM服务把他们的联系人列表限制在100到150个条目). 在一个服务器上新注册或被创建(例如, 在一个组织内)的用户也可能接收到一大票初始名册条目，为了同步服务器上建立的共享组. 无论如何, 在这类初始化之后, 随后的名册条目设置应该小很多. 在任何情况下, 超过150或200的名册条目设置应该值得怀疑, 并且重复发送这类设置的实体不应该（SHOULD NOT）被信任.

==发送实体的类型==

前述的协议描述只讲了"发送实体们"而没有区分不同类型的发送实体. 无论如何, 设想中名册条目将由三种不同的发送者发送给接收者:

:# Jabber客户端用户.
:# 客户端代理网关.
:# 共享组服务.

完整描述如下.

===Jabber用户===

名册条目交换是在早期的Jabber社区被开发出来的并且被记录在XEP-0093中，它被用于从一个用户发送一个名册条目到另一个用户, 在某种程度上它比简单地在聊天窗口中键入一个第三方的JID更加结构化. 这一用途仍然是被鼓励的. 无论如何, 如果发送者是一个自然人用户 和/或 发送应用 的主要的 '''服务查询''' 类别是 "client" (例如, 一个机器人) [[XEP-0144#附录G:备注|10]], 该发送应用不应该(SHOULD NOT)指定一个"add"之外的'action'属性, 接收应用可以忽略"add"之外的'action'属性值, 并且接收应用必须提示一个自然人用户是否添加建议的条目或条目们到该用户的名册.

===网关===

客户端代理网关(即, 服务查询类别为"gateway"的实体)的情况在[http://xmpp.org/extensions/xep-0100.html 网关交互] [[XEP-0144#附录G:备注|11]]中定义的更完整. 这里我们描述这类网关应该如何使用名册条目交换, 以及接收应用将如何看待从这类网关收到的名册条目.

为了使用一个网关的协议翻译服务, 一个用户必须首先注册到该网关. 如果该网关声明支持一个服务查询特性'http://jabber.org/protocol/rosterx', 那么该用户的客户端应该期望他可能从该网关收到名册条目建议. 为了维护该用户在外部IM服务上的联系人列表和该用户的Jabber名册之间的同步, 该网关应该发送带有适当的值为"add", "delete", 或 "modify" 'action'属性的名册条目, 而且接收应用应该处理这类名册条目建议. 这样的处理可能自动发生(即, 每个名册条目或一批名册条目不需要该用户的批准) ，当且仅当该接收应用显式地通知该用户它将自动处理来自该网关的名册条目的时候. 进一步的, 该接收应用应该让该用户定期检查自动处理(例如, 每此该网关发送名册条目建议给该用户的会话的时候检查一次).

===组服务===

第三中可以发起名册条目交换的实体类型, 我们称为"group service"并且通过一个"directory"的服务查询类别和"group"的类型来标识它. 组服务允许一个管理员集中地定义和管理名册组，使得它们能以一个组织化的方式在一个用户群体中共享. 这样一个服务在企业环境[[XEP-0144#附录G:备注|12]]很有用，不并且其他设置对于跨越个人(例如, 学校, 社交网络应用, 消费者IM服务, 以及其他用户建立和管理很重要的小社区)的同步名册很有益.

在一些上下文中, 一个IM服务器可能就是作为组服务使用(例如, 如果在一个小公司的内部网中部署的单一服务器); 在另外一些上下文中, 可能要花更大的经历来部署一个独立的组服务(例如, 在一个更大的或更错杂的环境，用户位于多台服务器上). 两种情况下, 组服务都必须声明一个服务查询标识"directory/group"并且应该在这里指定通讯对相关的共享组的变更("add", "delete", 和 "modify"); 另外, 一个用户必须首先注册到该服务(要么在Jabber上通过[[XEP-0077|带内注册]] [[XEP-0144#附录G:备注|13]] 要么走带外, 例如, 通过web)或另有办法在从该服务接受名册条目建议之前使用该服务(例如, 通过一个系统管理员).

如果该用户已经注册到一个组服务或另有办法使用一个组服务, 该接收应用应该处理从该服务收到的名册条目建议. 这个处理可以是自动发生的(即, 每个名册条目或一批名册条目不需要该用户的批准), 当且仅当该接收应用显式地通知该用户它将自动处理来自该服务的名册条目的时候. 进一步的, 该接收应用应该让该用户定期检查自动处理(例如, 每此该服务发送名册条目建议给该用户的会话的时候检查一次).

==安全事项==
===信任的实体===

一个当事人(用户)或接收应用可以建立一个信任实体的列表，从这个列表的实体来的名册条目交换被自动处理, 即, 不用一个自然人用户显式地批准. 为了防止名册的腐败, 强烈推荐这类信任的实体限于上面定义的网关和组服务. 另外, 接收实体应该让当事人定期检查这类自动处理, 例如, 每次被信任的实体发送名册条目建议给该用户的会话的时候.

===拒绝服务===

一个发送实体能有效地对接收实体进行拒绝服务攻击，通过快速和重复地发送 (1) 交替的 add 和 delete 建议 或 (2) modify 建议, 所以接收实体的服务器被强制调用扼杀机制. 接收应用应该通过监控从每个发送实体接收到的名册条目交换来压制它并且拒绝或忽略来自问题实体的名册条目交换(例如, 把这类实体加到一个不信任实体列表中).

===声明支持===

一个接收应用可以拒绝向那些 (1) 未显式地信任 或 (2) 显式地不信任 的实体声明它对名册条目交换协议的支持(见本文的[[XEP-0144#服务查询|服务查询]]章节).

==IANA事项==

本文不需要和[http://www.iana.org/ 互联网编号分配授权机构(IANA)] [[XEP-0114#附录G:备注|14]]有任何互动。

==XMPP注册处事项==
===协议命名空间===

[http://xmpp.org/registrar/ XMPP注册处] [[XEP-0144#附录G:备注|15]] 已经把'http://jabber.org/protocol/rosterx'包含在它的协议命名空间的注册项中.

===服务查询标识符===

XMPP注册处在它的服务查询标识符的注册项的"directory"类别下包含了一个'''服务查询'''类型"group".

==XML Schema==

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/rosterx'
    xmlns='http://jabber.org/protocol/rosterx'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0144: http://www.xmpp.org/extensions/xep-0144.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='x'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='group' type='xs:string' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='action' use='optional' default='add'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='add'/>
            <xs:enumeration value='delete'/>
            <xs:enumeration value='modify'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name='jid' type='xs:string' use='required'/>
      <xs:attribute name='name' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

</xs:schema>
</source>

==附录==

===附录A:文档信息===

系列：[http://xmpp.org/extensions/ XEP]

序号：0144

发布者：[http://xmpp.org/xsf/ XMPP标准基金会]

状态：[http://xmpp.org/extensions/xep-0001.html#states-Draft 草案]

类型：[http://www.xmpp.org/extensions/xep-0001.html#types-Standards%20Track 标准跟踪]

版本：1.0

最后更新：2005-08-26

批准机构：[http://xmpp.org/council/ XMPP理事会]

依赖标准：XMPP Core, XMPP IM

替代标准：XEP-0093

被替代标准：无

缩略名：rosterx

Schema: <http://www.xmpp.org/schemas/rosterx.xsd>

原文控制： [http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0144.xml HTML]

本文的其它格式： [http://xmpp.org/extensions/xep-0144.xml XML] [http://xmpp.org/extensions/xep-0144.pdf PDF]

===附录B:作者信息===

'''Peter Saint-Andre'''

Email: [mailto:stpeter@jabber.org stpeter@jabber.org]

JabberID: stpeter@jabber.org

URI: https://stpeter.im/

{{Template:XEP附录CDEF}}

===附录G:备注===

1. RFC 2779: 一个用于出席信息和即时消息的模型 <http://tools.ietf.org/html/rfc2779>.

2. RFC 6121: 可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息 <http://tools.ietf.org/html/rfc6121>.

3. XEP-0093: 名册条目交换 <http://xmpp.org/extensions/xep-0093.html>.

4. 标准SIG是一个代表特别兴趣的组，致力于XMPP扩展协议开发. 这个标准SIG的讨论组是XMPP协议扩展讨论的主要场所, 同时用于XMPP扩展和XMPP注册项的声明. 要订阅这个列表或查看该列表的归档文件, 请访问 <http://mail.jabber.org/mailman/listinfo/standards/>.

5. 'action'属性的缺省值是"add"; 所以, 如果'action'属性未被包含或接收应用不理解该'action'属性, 该接收实体必须把该条目的值视为"add".

6. XEP-0030: 服务查询 <http://xmpp.org/extensions/xep-0030.html>.

7. XEP-0115: 实体能力 <http://xmpp.org/extensions/xep-0115.html>.

8. 如果接收实体有多个可用资源, 发送的应用应该与"最可用的"资源通讯，根据它的最佳估计(例如, 有最高优先级的资源).

9. RFC 6120: 可扩展的消息和出席信息协议 (XMPP): 核心 <http://tools.ietf.org/html/rfc6120>.

10. 见 <http://www.xmpp.org/registrar/disco-categories.html#client>.

11. XEP-0100: 网关交互 <http://xmpp.org/extensions/xep-0100.html>.

12. 例如, 当Alice被一个大公司的市场部雇用, 意味着她第一次登陆的时候在她的名册中自动有了市场部的其他成员, 并且一旦她的帐号被设置好，市场部的其他人的名册中就有了Alice. 类似的, 当Bob被物流部开除了, 意味着他从物流部每个其他人的名册中消失.

13. XEP-0077: 带内注册 <http://xmpp.org/extensions/xep-0077.html>.

14. 互联网号码分配机构(IANA)是为互联网协议分配唯一性的参数值的中间协调者, 类似端口号码和 URI schemes. 更多信息参见 <http://www.iana.org/>.

15. XMPP注册处维护一个保留的协议命名空间的列表和在XMPP标准基金会批准的XMPP扩展协议的上下文中使用的参数的注册项的列表. 更多信息见 <http://xmpp.org/registrar/>.

===附录H:修订历史===

注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用

:'''Version 1.0 (2005-08-26)'''

::Per a vote of the Jabber Council, advanced status to Draft. (psa)

:'''Version 0.6 (2005-07-28)'''

::Incorporated Council feedback: specified that a body MAY be included when sending a message stanza; changed prohibition on mixing of additions, deletions, and modifications from SHOULD NOT to MUST NOT; clarified status of bots as sending entities. (psa)

:'''Version 0.5 (2005-07-26)'''

::Reverted roster item deletion changes. (psa)

:'''Version 0.4 (2005-07-21)'''

::Simplified processing of roster item deletions. (psa)

:'''Version 0.3 (2004-10-27)'''

::Clarified the nature of sending entities (users, gateways, and group services); specified "directory/group" service discovery identity for shared group services. (psa)

:'''Version 0.2 (2004-10-04)'''

::Further defined the nature of trusted entities. (psa)

:'''Version 0.1 (2004-09-29)'''

::Initial version. (psa)

:'''Version 0.0.2 (2004-09-22)'''

::To address Council feedback, added text about service discovery and choice of stanza type (message or IQ). (psa)

:'''Version 0.0.1 (2004-09-16)'''

::Forked XEP-0093 by adding the action attribute, defining requirements and use cases, specifying processing rules, and detailing security considerations. (psa)

--------------------------------------------
结束