XEP-0144

来自Jabber/XMPP中文翻译计划
2013年7月26日 (五) 06:24Admin (讨论 | 贡献)的版本
跳转到： 导航, 搜索


本文的英文原文来自XEP-0144

XEP-0144 ：名册条目交换

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

作者: Peter Saint-Andre

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

状态: 草案

类型: 标准跟踪

版本: 1.0

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

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

目录

绪论

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

需求

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

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

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

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

用例

建议名册条目添加

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

例子 1. 建议添加 

<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>

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

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

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

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

建议名册条目删除

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

例子 2. Suggesting Deletion 

<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>

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

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

如果该条目被删除了, 该接收应用应该从名册移除该条目，通过发送一个'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. 建议修改 

<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>

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

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


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

服务查询

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

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

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

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

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

<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>

推荐的节类型

如果发送实体拥有关于接收实体在线和可用的信息(例如, 通过出席信息或一个活跃的聊天交谈), 它应该: 8

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

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

IQ语义

如果发送实体使用<iq/>节来和通讯它的名册条目交换建议, 接收实体必须遵循XMPP核心 9定义的IQ语义. 特别是:

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

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


商业规则

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

发送实体的类型

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

  1. Jabber客户端用户.
  2. 客户端代理网关.
  3. 共享组服务.

完整描述如下.

Jabber用户

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

网关

客户端代理网关(即, 服务查询类别为"gateway"的实体)的情况在网关交互 11中定义的更完整. 这里我们描述这类网关应该如何使用名册条目交换, 以及接收应用将如何看待从这类网关收到的名册条目.

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

组服务

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

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

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

安全事项

信任的实体

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

拒绝服务

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

声明支持

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

IANA事项

本文不需要和互联网编号分配授权机构(IANA) 14有任何互动。

XMPP注册处事项

协议命名空间

XMPP注册处 15 已经把'http://jabber.org/protocol/rosterx'包含在它的协议命名空间的注册项中.

服务查询标识符

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

XML Schema

<?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>

附录

附录A:文档信息

系列：XEP

序号：0144

发布者：XMPP标准基金会

状态：草案

类型：标准跟踪

版本：1.0

最后更新：2005-08-26

批准机构：XMPP理事会

依赖标准：XMPP Core, XMPP IM

替代标准：XEP-0093

被替代标准：无

缩略名：rosterx

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

原文控制： HTML

本文的其它格式： XML PDF

附录B:作者信息

Peter Saint-Andre

Email: stpeter@jabber.org

JabberID: stpeter@jabber.org

URI: https://stpeter.im/

附录C:法律通告

版权

XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.

权限

特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。

免责声明'

## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##

责任限制

在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。

知识产权的一致性

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

附录D:和XMPP的关系

可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.

附录E:讨论地点

主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.

在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .

勘误表可以发送邮件到 <editor@xmpp.org>.

附录F:需求一致性

以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


附录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)

结束

来自“http://wiki.jabbercn.org/index.php?title=XEP-0144&oldid=3273”
个人工具