XEP-0144

来自Jabber/XMPP中文翻译计划
（版本间的差异）
跳转到： 导航, 搜索
小
小 (→服务查询)
 
（未显示1个用户的20个中间版本）
第1行： 第1行：
 
[[Category:XMPP扩展]]
 
[[Category:XMPP扩展]]
−
[[Category:翻译中]]
+
[[Category:已翻译]]
  
 
'''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0144.html XEP-0144]'''
 
'''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0144.html XEP-0144]'''
  
−
'''XEP-0144 ：名册条目交流'''
+
'''XEP-0144 ：名册条目交换'''
  
−
这个规范定义了一个协议的扩展，用于交流联络人清单项目，包括以下能力,建议项目是否要添加，删除或修改在连络人清单中的收件人，以及该条目的建议所在的名册组。
+
摘要: 本协议定义了一个XMPP协议扩展, 这个规范定义了一个协议的扩展，用于交换联系人列表条目，包括以下能力,建议条目是否要被添加，删除或在接收者的联系人列表中修改，以及建议该条目所在的名册组。
  
−
注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于部署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
+
作者: Peter Saint-Andre
  
−
'''文档信息'''
+
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见[[XEP-0144#附录C:法律通告|法律通告]].
  
−
系列：XEP
+
状态: 草案
  
−
编号： 0144
+
类型: 标准跟踪
  
−
出版商：[[XMPP标准基金会]]
+
版本: 1.0
  
−
状态： 草案
+
最后更新日期: 2005-08-26
  
−
类型： 标准轨道
+
--------------------------------------------------------------------------------
  
−
版本： 1.0
+
注意: 这里定义的协议是XMPP标准化基金会的一个'''草案标准'''.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
 +
 +
--------------------------------------------------------------------------------
  
−
上次更新时间： 2005年8月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' 名字空间名字。更多的规范将定义如何使用这里定义的协议来解决共享组和名册同步的问题.
  
−
相依：[[RFC3920|XMPP Core]]，[[RFC3921|XMPP IM]]
+
==需求==
  
−
取代：XEP - 0093
+
XEP-0093未定义名册条目交换的需求. 本章纠正了那个疏忽.
  
−
被取代：无
+
名册条目交换满足以下要求:
  
−
短名称： rosterx
+
:# 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议把那个名册条目(们)加入到接收者的名册.
 +
:# 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议把那个名册条目(们)从接收者的名册中删除.
 +
:# 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议在接收者的名册中修改那个名册条目(们).
  
−
架构：< http://www.xmpp.org/schemas/rosterx.xsd >
+
本文故意讲到名册和名册条目, 而不是出席信息订阅. 尽管名册和订阅是紧密连接的(如'''RFC 3921'''解释的), 它们不是同一的. 这里定义的协议允许一个实体建议另一个实体只添加, 删除, 或修改名册条目, 而不指示和那些名册条目相关的建议的出席信息订阅状态.
  
−
Wiki页： <http://wiki.jabber.org/index.php/Roster Item Exchange (XEP-0144)>
+
==用例==
 +
===建议名册条目添加===
  
−
'''作者信息'''
+
为了程序化地建议接收实体应该添加一个或多个条目到它的名册中, 发送实体必须发送一个包含由'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. 建议添加'''
  
−
:JID: [xmpp:stpeter@jabber.org stpeter@jabber.org]
+
<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>   
  
−
:URI: <https://stpeter.im/>
+
在确定如何处理任何给定的'action'属性值为"add"(要么显式地要么作为缺省值)的名册条目时, 接收的应用应该处理如下:
  
−
'''法律公告'''
+
:# 如果该条目已经存在于名册中并且该条目在指定的组中(或没有指定组), 该接收应用不能(MUST NOT)提示一个自然人用户批准那个条目并且不能(MUST NOT)添加那个条目到名册.
 +
:# 如果该条目不在名册中, 该接收应用应该提示一个自然人用户批准那个条目, 并且，如果批准被授权, 必须添加该条目到名册中.
 +
:# 如果该条目已经在名册中但是不在指定的组中, 该接收应用可以提示该用户批准并且应该编辑现有的条目使得它也将属于该指定组(如果有现有的组，就在现有的组的基础上额外加上).
  
−
'''版权'''
+
如果该名册条目添加节将导致添加该条目到名册, 该接收应用必须(要么由一个自然人用户批准要么自动遵循配置)发送一个包含新条目的如'''RFC 3921'''所述的roster set给该用户的服务器. 完成该roster set之后, 该接收应用也应该发送一个类型为"subscribe"的<presence/>节给该新条目的JID.
  
−
这XMPP协议延长议定书是版权所有（ C ） 1999 -2008年该XMPP协议标准基金会(XSF）。
+
对于当一个名册条目添加节实际导致编辑一个现有的名册条目的时候，推荐的应用程序行为, 参考本文的[[XEP-0144#建议名册条目修改|建议名册条目修改]].
  
−
'''权限'''
+
===建议名册条目删除===
  
−
许可特此批出，免费的，任何人取得的副本，此规格（ “规格” ），尽量使用规范，不受任何限制，包括但不限于权利的落实规范的一个软件程序，部署规格在一个网络服务，以及进行复制，修改，合并，出版，翻译，分发，转授，或出售的副本规格，并允许人向谁提供的规格是这样做的，受条件，即前述版权声明和本许可声明须包括在所有的副本或实质性部分的规格。除非单独的许可是理所当然的，改良工程，是重新分配，不得含有误导性资料，关于作者，标题，编号，或出版者的规格，并不得宣称通过改良工程，由作者，任何组织或项目，其中属于作者，或XMPP协议标准的基础。
+
为了程序化地建议接收实体应该从它的名册删除一个或多个条目, 发送实体必须发送一个包含由 'http://jabber.org/protocol/rosterx' 命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个必须拥有一个值为"delete"的'action'属性, 必须拥有一个'jid'属性来指定要被删除的条目的JabberID, 可以拥有一个'name'属性来为该条目指定一个自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来为该条目指定名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这是一个例子:
  
−
'''担保免责声明'''
+
'''例子 2. Suggesting Deletion'''
  
−
注：此规格是对所提供的“原样”的基础上，没有担保或条件的任何形式的，明示或暗示，包括，但不限于任何担保或条件的名称，非侵权性，适销性或适用性于某一特定用途。在任何情况不得XMPP协议标准的基础或作者此规格承担任何责任索赔，损害赔偿，或其他责任，无论是在一项行动的合同，侵权，或否则，所产生的，运出，或在他涉嫌与规格或执行，部署或以其它方式使用规格。 \##
+
<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"的名册条目时, 接收应用应该处理如下:
  
−
在任何情况下，没有任何法律理论，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或同意以书面形式，不得XMPP协议标准的基础或任何作者本规格承担所造成的损失，包括任何直接，间接，特殊，偶发，或相应的损害赔偿的任何字符利用所产生的或不能使用的规格（包括但不限于损失的善意，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP协议标准的基础，或如作者已被告知此类损害的可能性。
+
:# 如果该条目不存在于名册中, 该接收应用不能(MUST NOT)提示一个自然人用户批准关于那个条目并且不能(MUST NOT)从名册删除那个条目.
 +
:# 如果该条目存在于名册中但是不指定的组中, 该接收应用不能(MUST NOT)提示该用户批准并且不能(MUST NOT)删除该现有的条目.
 +
:# 如果该条目存在于名册中并且同时存在于指定的组和另一个组中, 该接收应用可以提示该用户批准并且编辑现有的条目使得它不再属于指定的组.
  
−
'''知识产权的一致性'''
+
如果该条目被删除了, 该接收应用应该从名册移除该条目，通过发送一个'subscription'属性值设为"remove"的如'''RFC 3921'''所述的roster set给该用户的服务器, 因为这导致该用户的服务器生成适当的<presence/>节.
  
−
这XMPP协议延长议定书已作出贡献，在充分的一致性与xsf的知识产权政策（副本，其中可能会发现在< http://www.xmpp.org/extensions/ipr-policy.shtml >或取得以书面xsf ，邮政信箱1641年，丹佛，合作80201美国） 。
+
===建议名册条目修改===
  
−
'''讨论会场'''
+
为了程序化地建议接收实体应该从它的名册中修改一个或多个条目, 发送实体必须发送一个包含由 'http://jabber.org/protocol/rosterx' 命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个都应该拥有一个值为"modify"的'action'属性, 必须拥有一个'jid'属性来指定被修改的条目的JabberID, 可以拥有一个'name'属性来指定一个用于该条目的自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来指定存放该条目的名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这里是例子:
  
−
首选地点，讨论这个文件是标准的讨论名单： < http://mail.jabber.org/mailman/listinfo/standards > 。
+
'''例子 3. 建议修改'''
  
−
勘误表可以将意见发送至< editor@xmpp.org > 。
+
<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>  
  
−
'''有关XMPP协议'''
+
在确定如何处理任何给定的'action'属性值为"modify"的名册条目时, 接收的应用应该处理如下:
  
−
可扩展消息和存在协议（ XMPP协议）的定义是，在XMPP协议为核心的文档（ RFC 3920 ）和XMPP协议即时通讯文档（ RFC 3921 ）规格的贡献由XMPP协议标准的基础上的Internet标准的过程中，这是由管理的Internet Engineering Task Force ，按照与2026年的RFC 。任何议定书的定义，本文件已被发达国家以外的Internet标准进程，并应被理解为扩展XMPP协议，而不是作为一个演变，发展，或修改， XMPP协议本身。
+
:# 如果该条目不在名册中, 该接收应用不能(MUST NOT)提示一个自然人用户批准那个条目, 并且不能(MUST NOT)添加该添加该条目到名册中.
 +
:# 如果该条目已经存在于名册中并且该修改将只导致组的变更, 该接收应用可以提示该用户批准并且应该把该条目移动到指定的组.
 +
:# 如果该条目已经存在于名册中并且该修改将导致再添加该条目到一个（在它现有的组以外的）新组, 该接收应用可以该用户批准并且应该添加那个条目到指定的组.
 +
:# 如果该条目已经存在于名册中并且该修改将只导致名称的变更, 该接收应用可以提示该用户批准并且应该把该条目改成修改建议中指定的名称.
  
−
'''一致性条款'''
 
  
−
以下关键词中使用的这份文件是被解释为描述在RFC 2119 ： “必须” ， “应” ， “需要” ， “绝不能” ， “不得” ， “应该” ， “建议” ， “应没有“ ， ”不建议“ ， ”可能“ ， ”任择“ 。
+
如果一个名册条目添加，删除，或修改节将导致编辑一个名册中已有的条目, 该接收应用必须(要么由一个自然人用户批准要么自动遵循配置)发送一个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请求:
  
−
\1. [简介|XMPP文档列表/XMPP扩展/XEP-0144#简介]
+
'''例子 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> 
  
 +
接收实体接着表示它的支持:
  
−
2. [要求|XMPP文档列表/XMPP扩展/XEP-0144#要求]
+
'''例子 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>
  
 +
==推荐的节类型==
  
−
3. [使用案例|XMPP文档列表/XMPP扩展/XEP-0144#使用案例]
+
如果发送实体拥有关于接收实体在线和可用的信息(例如, 通过出席信息或一个活跃的聊天交谈), 它应该: [[XEP-0144#附录G:备注|8]]
  
 +
:# 查询是否接收实体支持这里定义的协议(参见本文的[[XEP-0144#服务查询|服务查询]]章节).
 +
:# 如果支持, 发送它的名册条目交换节给接收实体的一个特定资源(user@host/resource)，使用<iq/>节而不是<message/>节.
  
 +
如果发送实体不知道接收实体在线和可用, 它必须发送一个<message/>节给接收实体的"纯JID" (user@host)而不是发送<iq/>节给一个特定的资源.
  
−
3.1. [名册项目建议新增|XMPP文档列表/XMPP扩展/XEP-0144#名册项目建议新增]
+
===IQ语义===
  
 +
如果发送实体使用<iq/>节来和通讯它的名册条目交换建议, 接收实体必须遵循[[RFC6120|XMPP核心]] [[XEP-0144#附录G:备注|9]]定义的IQ语义. 特别是:
  
 +
:# 如果接收实体成功地处理了该建议动作(这可能包括忽略特定的建议), 该接收实体必须返回一个空的IQ result给发送实体.
 +
:# 如果接收实体不理解名册交换命名空间, 该接收实体必须返回一个错误给发送实体, 这个错误应该是<service-unavailable/>.
 +
:# 如果接收实体不处理建议的动作(们)是因为该接收实体没有注册到发送实体, 该接收实体必须返回一个错误给发送实体, 这个错误应该是<registration-required/>.
 +
:# 如果接收实体不处理建议的动作(们)是因为发送实体不在接收实体的名册中, 该接收实体必须返回一个错误给发送实体,这个错误应该是<not-authorized/>.
 +
:# 如果接收实体不处理建议的动作(们)是因为发送实体不被信任(见[[XEP-0144#信任的实体|信任的实体]]), 该接收实体必须返回一个错误给发送实体, 这个错误应该是<forbidden/>.
  
−
3.2. [名册项目建议删除|XMPP文档列表/XMPP扩展/XEP-0144#名册项目建议删除]
+
当然, 可能其他IQ错误是更合适的; 无论如何, 如果接收实体将不会或不能处理建议的动作(们), 它必须返回一个错误给发送实体.
  
  
 +
==商业规则==
  
−
3.3. [名册项目建议修改|XMPP文档列表/XMPP扩展/XEP-0144#名册项目建议修改]
+
:# 发送实体或发送应用不能(MUST NOT)在同一个<x/>元素和<message/>或 <iq/>节中发送additions, deletions, 和 modifications; 反之, 它应该为additions, deletions, 和 modifications分别发送单独的节.
 +
:# 如果必须或建议批准多个由发送实体建议的条目, 接收实体应该在同一时间或在同一界面展示所有的条目来批准.
 +
:# 如果发送实体是所谓"被信任的"(见[[XEP-0144#信任的实体|信任的实体]]), 那么该接收应用可以跳过上述的批准步骤.
 +
:# 同一时间内接收的应用不应该(SHOULD NOT)从任何一个发送实体接受不合理数量的名册条目. 不幸的是, 很难确定多大的名册条目数量是"不合理的". 例如, 当一个用户注册到一个网关, 名册条目的初始设置可能是非常大量的(无论如何, 注意大多数现有的消费者IM服务把他们的联系人列表限制在100到150个条目). 在一个服务器上新注册或被创建(例如, 在一个组织内)的用户也可能接收到一大票初始名册条目，为了同步服务器上建立的共享组. 无论如何, 在这类初始化之后, 随后的名册条目设置应该小很多. 在任何情况下, 超过150或200的名册条目设置应该值得怀疑, 并且重复发送这类设置的实体不应该（SHOULD NOT）被信任.
  
 +
==发送实体的类型==
  
 +
前述的协议描述只讲了"发送实体们"而没有区分不同类型的发送实体. 无论如何, 设想中名册条目将由三种不同的发送者发送给接收者:
  
−
4. [服务发现|XMPP文档列表/XMPP扩展/XEP-0144#服务发现]
+
:# Jabber客户端用户.
 +
:# 客户端代理网关.
 +
:# 共享组服务.
  
 +
完整描述如下.
  
 +
===Jabber用户===
  
−
5. [建议stanza类型|XMPP文档列表/XMPP扩展/XEP-0144#建议stanza类型]
+
名册条目交换是在早期的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]]中定义的更完整. 这里我们描述这类网关应该如何使用名册条目交换, 以及接收应用将如何看待从这类网关收到的名册条目.
  
−
5.1. [IQ语义|XMPP文档列表/XMPP扩展/XEP-0144#IQ语义]
+
为了使用一个网关的协议翻译服务, 一个用户必须首先注册到该网关. 如果该网关声明支持一个服务查询特性'http://jabber.org/protocol/rosterx', 那么该用户的客户端应该期望他可能从该网关收到名册条目建议. 为了维护该用户在外部IM服务上的联系人列表和该用户的Jabber名册之间的同步, 该网关应该发送带有适当的值为"add", "delete", 或 "modify" 'action'属性的名册条目, 而且接收应用应该处理这类名册条目建议. 这样的处理可能自动发生(即, 每个名册条目或一批名册条目不需要该用户的批准) ，当且仅当该接收应用显式地通知该用户它将自动处理来自该网关的名册条目的时候. 进一步的, 该接收应用应该让该用户定期检查自动处理(例如, 每此该网关发送名册条目建议给该用户的会话的时候检查一次).
  
 +
===组服务===
  
 +
第三中可以发起名册条目交换的实体类型, 我们称为"group service"并且通过一个"directory"的服务查询类别和"group"的类型来标识它. 组服务允许一个管理员集中地定义和管理名册组，使得它们能以一个组织化的方式在一个用户群体中共享. 这样一个服务在企业环境[[XEP-0144#附录G:备注|12]]很有用，不并且其他设置对于跨越个人(例如, 学校, 社交网络应用, 消费者IM服务, 以及其他用户建立和管理很重要的小社区)的同步名册很有益.
  
−
6. [业务规则|XMPP文档列表/XMPP扩展/XEP-0144#业务规则]
+
在一些上下文中, 一个IM服务器可能就是作为组服务使用(例如, 如果在一个小公司的内部网中部署的单一服务器); 在另外一些上下文中, 可能要花更大的经历来部署一个独立的组服务(例如, 在一个更大的或更错杂的环境，用户位于多台服务器上). 两种情况下, 组服务都必须声明一个服务查询标识"directory/group"并且应该在这里指定通讯对相关的共享组的变更("add", "delete", 和 "modify"); 另外, 一个用户必须首先注册到该服务(要么在Jabber上通过[[XEP-0077|带内注册]] [[XEP-0144#附录G:备注|13]] 要么走带外, 例如, 通过web)或另有办法在从该服务接受名册条目建议之前使用该服务(例如, 通过一个系统管理员).
  
 +
如果该用户已经注册到一个组服务或另有办法使用一个组服务, 该接收应用应该处理从该服务收到的名册条目建议. 这个处理可以是自动发生的(即, 每个名册条目或一批名册条目不需要该用户的批准), 当且仅当该接收应用显式地通知该用户它将自动处理来自该服务的名册条目的时候. 进一步的, 该接收应用应该让该用户定期检查自动处理(例如, 每此该服务发送名册条目建议给该用户的会话的时候检查一次).
  
 +
==安全事项==
 +
===信任的实体===
  
−
7. [发送实体的类型|XMPP文档列表/XMPP扩展/XEP-0144#发送实体的类型]
+
一个当事人(用户)或接收应用可以建立一个信任实体的列表，从这个列表的实体来的名册条目交换被自动处理, 即, 不用一个自然人用户显式地批准. 为了防止名册的腐败, 强烈推荐这类信任的实体限于上面定义的网关和组服务. 另外, 接收实体应该让当事人定期检查这类自动处理, 例如, 每次被信任的实体发送名册条目建议给该用户的会话的时候.
  
 +
===拒绝服务===
  
 +
一个发送实体能有效地对接收实体进行拒绝服务攻击，通过快速和重复地发送 (1) 交替的 add 和 delete 建议 或 (2) modify 建议, 所以接收实体的服务器被强制调用扼杀机制. 接收应用应该通过监控从每个发送实体接收到的名册条目交换来压制它并且拒绝或忽略来自问题实体的名册条目交换(例如, 把这类实体加到一个不信任实体列表中).
  
−
7.1. [Jabber用户|XMPP文档列表/XMPP扩展/XEP-0144#Jabber用户]
+
===声明支持===
  
 +
一个接收应用可以拒绝向那些 (1) 未显式地信任 或 (2) 显式地不信任 的实体声明它对名册条目交换协议的支持(见本文的[[XEP-0144#服务查询|服务查询]]章节).
  
 +
==IANA事项==
  
−
7.2. [网关|XMPP文档列表/XMPP扩展/XEP-0144#网关]
+
本文不需要和[http://www.iana.org/ 互联网编号分配授权机构(IANA)] [[XEP-0114#附录G:备注|14]]有任何互动。
  
 +
==XMPP注册处事项==
 +
===协议命名空间===
  
 +
[http://xmpp.org/registrar/ XMPP注册处] [[XEP-0144#附录G:备注|15]] 已经把'http://jabber.org/protocol/rosterx'包含在它的协议命名空间的注册项中.
  
−
7.3. [组服务|XMPP文档列表/XMPP扩展/XEP-0144#组服务]
+
===服务查询标识符===
  
 +
XMPP注册处在它的服务查询标识符的注册项的"directory"类别下包含了一个'''服务查询'''类型"group".
  
 +
==XML Schema==
  
−
8. [安全方面的考虑|XMPP文档列表/XMPP扩展/XEP-0144#安全方面的考虑]
+
<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>
  
−
8.1. [信任的实体|XMPP文档列表/XMPP扩展/XEP-0144#信任的实体]
+
  <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>
  
−
8.2. [拒绝服务|XMPP文档列表/XMPP扩展/XEP-0144#拒绝服务]
+
==附录==
  
 +
===附录A:文档信息===
  
 +
系列：[http://xmpp.org/extensions/ XEP]
  
−
8.3. [广告支持|XMPP文档列表/XMPP扩展/XEP-0144#广告支持]
+
序号：0144
  
 +
发布者：[http://xmpp.org/xsf/ XMPP标准基金会]
  
 +
状态：[http://xmpp.org/extensions/xep-0001.html#states-Draft 草案]
  
−
9. [IANA考虑|XMPP文档列表/XMPP扩展/XEP-0144#IANA考虑]
+
类型：[http://www.xmpp.org/extensions/xep-0001.html#types-Standards%20Track 标准跟踪]
  
 +
版本：1.0
  
 +
最后更新：2005-08-26
  
−
10. [XMPP Registrar考虑|XMPP文档列表/XMPP扩展/XEP-0144#XMPP Registrar考虑]
+
批准机构：[http://xmpp.org/council/ XMPP理事会]
  
 +
依赖标准：XMPP Core, XMPP IM
  
 +
替代标准：XEP-0093
  
−
10.1. [协议命名空间|XMPP文档列表/XMPP扩展/XEP-0144#协议命名空间]
+
被替代标准：无
  
 +
缩略名：rosterx
  
 +
Schema: <http://www.xmpp.org/schemas/rosterx.xsd>
  
−
10.2. [服务发现身份|XMPP文档列表/XMPP扩展/XEP-0144#服务发现身份]
+
原文控制： [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:作者信息===
  
−
\11. [XML架构|XMPP文档列表/XMPP扩展/XEP-0144#XML架构]
+
'''Peter Saint-Andre'''
  
 +
Email: [mailto:stpeter@jabber.org stpeter@jabber.org]
  
 +
JabberID: stpeter@jabber.org
  
−
[备注|XMPP文档列表/XMPP扩展/XEP-0144#备注]
+
URI: https://stpeter.im/
  
 +
{{Template:XEP附录CDEF}}
  
 +
===附录G:备注===
  
−
[修订历史|XMPP文档列表/XMPP扩展/XEP-0144#修订历史]__
+
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/>.
  
−
__\1. 简介__ {anchor:简介}
+
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>.
  
−
Jabber协议早有一种方法，将名册项目从一个实体发送到另一个，利用'jabber:x:roster' 名字空间。因为这个协议扩展没有被RFC 2779 \[1\]要求 ，它被移出了XMPP IM \[2\], 仅出于历史原因记录在 Roster Item Exchange \[3\] 。 However, since that time discussions in the Standards SIG [ 4 ] have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (eg, predefined roster groups used within an organization) and roster synchronization (eg, keeping a Jabber roster in sync with a contact list on a legacy IM service).不过，自那时以来的讨论中的标准SIG的 [ 4 ]人士透露，这将有助于使用名册的项目交流，问题空间“共同集团” （例如，预定义的名册集团利用在一个组织内）及名册同步（如，保持的Jabber名册，在同步与联络人清单上的遗产，即时通讯服务） 。 These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified.这些问题的空间，需要更精密的轻微种名册项目的交流比记录在xep - 0093 ，特别的能力，表明是否名册项目是要添加，删除或修改。 Therefore this document redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name.因此，本文件的定义名册项目的交流提供此功能，这样一种方式是向后兼容，与现有的实现，虽然使用现代名字空间的URI ' http://jabber.org/protocol/rosterx ' ，而不是旧'的Jabber ： x ：名册'名字空间的名字。 Further specifications will define how to solve the problems of shared groups and roster synchronization using the protocol defined herein.进一步规范将界定如何解决的问题，共享团体和名册同步使用该议定书的定义在这里。
+
8. 如果接收实体有多个可用资源, 发送的应用应该与"最可用的"资源通讯，根据它的最佳估计(例如, 有最高优先级的资源).
  
−
2. Requirements 2 。 要求
+
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>.
  
−
XEP-0093 did not define the requirements for roster item exchange. xep - 0093未界定的要求，名册项目的交流。 This section remedies that oversight.本节的补救措施，监督。
+
12. 例如, 当Alice被一个大公司的市场部雇用, 意味着她第一次登陆的时候在她的名册中自动有了市场部的其他成员, 并且一旦她的帐号被设置好，市场部的其他人的名册中就有了Alice. 类似的, 当Bob被物流部开除了, 意味着他从物流部每个其他人的名册中消失.
  
 +
13. XEP-0077: 带内注册 <http://xmpp.org/extensions/xep-0077.html>.
  
 +
14. 互联网号码分配机构(IANA)是为互联网协议分配唯一性的参数值的中间协调者, 类似端口号码和 URI schemes. 更多信息参见 <http://www.iana.org/>.
  
−
Roster item exchange meets the following requirements:名册项目外汇满足以下要求：
+
15. XMPP注册处维护一个保留的协议命名空间的列表和在XMPP标准基金会批准的XMPP扩展协议的上下文中使用的参数的注册项的列表. 更多信息见 <http://xmpp.org/registrar/>.
  
 +
===附录H:修订历史===
  
 +
注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用
  
−
  1. Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be added to the recipient's roster.使一个实体发送一个或多个项目名册给另一个实体，有人认为，名册（某些）项目被添加到收件人的名册。
+
:'''Version 1.0 (2005-08-26)'''
  
−
  2. Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be deleted from the recipient's roster.使一个实体发送一个或多个项目名册给另一个实体，有人认为，名册（某些）项目予以删除，从收件人的名册。
+
::Per a vote of the Jabber Council, advanced status to Draft. (psa)
  
−
  3. Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be modified in the recipient's roster.使一个实体发送一个或多个项目名册给另一个实体，有人认为，名册项目（ ）修改在收件人的名册。
+
:'''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)'''
  
−
This document deliberately speaks of rosters and roster items, not presence subscriptions.这份文件刻意谈到名册和名册的项目，而不是存在订阅。 Although rosters and subscriptions are closely connected (as explained in RFC 3921 ), they are not identical.虽然名册和订阅是紧密相连（如解释，在RFC 3921 ） ，他们是不相同的。 The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items.该议定书的定义，使这里的一个实体，以表明另一个实体可能要添加，删除或修改的项目，只有名册，并没有决定建议在场的订阅相关的国家与那些名册项目。 This is intentional.这是故意的。
+
::Reverted roster item deletion changes. (psa)
  
−
3. Use Cases 3 。 使用案例
+
:'''Version 0.4 (2005-07-21)'''
  
−
3.1 Suggesting Roster Item Addition 3.1 建议名册的项目，除了
+
::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)
  
−
In order to programatically suggest that the receiving entity should add one or more items to its roster, the sending entity MUST send a <message/> or <iq/> stanza containing an <x/> element qualified by the 'http://jabber.org/protocol/rosterx' namespace (see Recommended Stanza Type regarding when to use <message/> and when to use <iq/>); the <x/> element in turn MUST contain one or more <item/> child elements, each of which SHOULD possess an 'action' attribute whose value is "add" [ 5 ], MUST possess a 'jid' attribute that specifies the JabberID of the item to be added, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups into which to place the item.在以programatically表明，接收实体应添加一个或多个项目，其名册，发送实体必须发出一个 <message/>或<iq/> stanza载有一<x/>元素合格的由'的http:// jabber.org /协议/ rosterx '名字空间（见建议stanza类型就何时使用<message/>和何时使用<iq/> ） ; <x/>元素，又必须包含一个或多个<item/>儿童元素，其中每一个应具备的'行动'的属性，其价值是“添加” [ 5 ] ，必须具备' jid '的属性，指定jabberid该项目要补充说，可能具有的'名称'属性指定自然语言的姓名或昵称项目，并可能包含一个或更多<group/>元素指定名册群体融入其中地方项目。 If a <message/> stanza is sent, it MAY contain a <body/> element but SHOULD NOT contain any other child elements.如果<message/> stanza发送，它可能包含一个<body/>元，但不应包含任何其他子元素。 Here is an example:下面是一个例子：
+
:'''Version 0.2 (2004-10-04)'''
  
 +
::Further defined the nature of trusted entities. (psa)
  
 +
:'''Version 0.1 (2004-09-29)'''
  
−
Example 1.例如1 。 Suggesting Addition建议除了
+
::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)
  
−
<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>了<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>的<body>一些游客， m'lord ！ < /机构> < x xmlns = ' http://jabber.org/protocol/ rosterx “ > <item action='add' jid='rosencrantz@denmark.lit' name='rosencrantz'> <group>旅客< /组> < /项目> <项目的行动= '添加' jid = ' guildenstern @丹麦。点亮姓名= ' guildenstern “ > <group>旅客< /组> < /项目> < / x > < /消息>
+
:'''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)
  
−
 
+
--------------------------------------------
−
In determining how to handle any given roster item whose 'action' attribute has a value of "add" (either explicitly or as the default value), the receiving application SHOULD proceed as follows:在决定如何处理任何特定名册的项目'行动'的属性有一个价值的“添加” （不论是明示或作为默认值） ，接收的应用，应进行如下：
+
结束
−
 
+
−
 
+
−
 
+
−
  1. If the item already exists in the roster and the item is in the specified group (or no group is specified), the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.如果该项目已经存在于名册和该项目是在指定的组（或任何集团所指定的） ，接收应用程序必须不提示人类用户批准关于该项目的，决不能补充说，项目名册。
+
−
 
+
−
  2. If the item does not already exist in the roster, the receiving application SHOULD prompt a human user for approval regarding that item and, if approval is granted, MUST add that item to the roster.如果该项目不存在，在名册上，接收的应用，应促使人类用户批准关于该项目的，如果批准，是理所当然的，必须补充一点的项目名册。
+
−
 
+
−
  3. If the item already exists in the roster but not in the specified group, the receiving application MAY prompt the user for approval and SHOULD edit the existing item so that will also belong to the specified group (in addition to the existing group, if any).如果该项目已经存在，在名册上，而不是在指定的组，接收应用程序可能会提示用户批准，并应修改现有的项目，所以这也将属于指定的组（除现有的集团，如有的话） 。
+
−
 
+
−
 
+
−
 
+
−
If the roster item addition stanza will result in adding the item to the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server containing the new item as described in RFC 3921 .如果名册的项目，除了stanza将导致在加入该项目名册，接收应用程序必须（要么批准，由一个人的用户或自动受配置）发送一份名册设置为用户的服务器上载有新项目描述在RFC 3921 。 After completing the roster set, the receiving application SHOULD also send a <presence/> stanza of type "subscribe" to the JID of the new item.完成后，名册设置，接收的应用也应该派遣一个<presence/> stanza型“订阅”向jid的新项目。
+
−
 
+
−
 
+
−
 
+
−
For a description of the recommended application behavior when a roster item addition stanza actually results in editing of an existing roster item, refer to the Suggesting Roster Item Modification section of this document.为说明所建议的应用行为时，名册项目除了stanza ，其实结果在编辑一个现有的名册上项目，是指该建议名册项目改性节本文件。
+
−
 
+
−
3.2 Suggesting Roster Item Deletion 3.2 建议名册项目删除
+
−
 
+
−
 
+
−
 
+
−
In order to programatically suggest that the receiving entity should delete one or more items from its roster, the sending entity MUST send a <message/> or <iq/> stanza containing an <x/> element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the <x/> element in turn MUST contain one or more <item/> child elements, each of which MUST possess an 'action' attribute whose value is "delete", MUST possess a 'jid' attribute that specifies the JabberID of the item to be deleted, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups for the item.在以programatically表明，接收实体应删除一个或多个项目，从它的名册，发送实体必须发出一个<message/>或<iq/> stanza载有一<x/>元素合格的由'的http:// jabber.org /协议/ rosterx '名字空间; <x/>元素，又必须包含一个或多个<item/>子元素，其中每一项都必须具备一'行动'的属性，其价值是“删除” ，必须具备一' jid '的属性，指定jabberid该项目被删除，可能具有的'名称'的属性，指定了一个自然语言的姓名或昵称项目，并可能包含一个或更多< group/>元素指定名册团体该项目。 If a <message/> stanza is sent, it MAY contain a <body/> element but SHOULD NOT contain any other child elements.如果<message/> stanza发送，它可能包含一个<body/>元，但不应包含任何其他子元素。 Here is an example:下面是一个例子：
+
−
 
+
−
 
+
−
 
+
−
Example 2.例如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>了<message from='horatio@denmark.lit' to='hamlet@denmark.lit'> <x xmlns='http://jabber.org/protocol/rosterx'> <项目的行动= '删除' jid = ' rosencrantz @丹麦的姓名= ' rosencrantz “ > <group>旅客< /组> < /项目> <item action='delete' jid='guildenstern@denmark' name='guildenstern'> <group>旅客< /组> < /项目> < / x > < /消息>
+
−
 
+
−
 
+
−
 
+
−
In determining how to handle any given roster item whose 'action' attribute has a value of "delete", the receiving application SHOULD proceed as follows:在决定如何处理任何特定名册的项目'行动'属性值为“删除” ，接收的应用，应进行如下：
+
−
 
+
−
 
+
−
 
+
−
  1. If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT delete that item from the roster.如果该项目不存在，在名册上，接收应用程序必须不提示人类用户批准关于该项目的，决不能删除该项目从名册中。
+
−
 
+
−
  2. If the item exists in the roster but not in the specified group, the receiving application MUST NOT prompt the user for approval and MUST NOT delete the existing item.如果该项目存在在名册上，而不是在指定的组，接收应用程序必须不提示用户的批准，决不能删除现有的项目。
+
−
 
+
−
  3. If the item exists in the roster and is in both the specified group and another group, the receiving application MAY prompt the user for approval and SHOULD edit the existing item so that it no longer belongs to the specified group.如果该项目存在的名册，并在双方指定的组和另一组，接收应用程序可能会提示用户批准，并应修改现有的项目，使其不再属于指定的组。
+
−
 
+
−
 
+
−
 
+
−
If the item is to be deleted, the receiving application SHOULD remove the item from the roster by sending a roster set to the user's server with the 'subscription' attribute set to a value of "remove" as described in RFC 3921 , since this results in generation of the appropriate <presence/> stanzas by the user's server.如果该项目是要被删除，接收的应用，应删除该项目从名册中通过发送名册设置为用户的服务器与'认购'的属性设置为一个价值的“删除”形容在RFC 3921 ，因为这结果在一代的适当<presence/> stanzas由用户的服务器上。
+
−
 
+
−
3.3 Suggesting Roster Item Modification 3.3 建议名册项目改造
+
−
 
+
−
 
+
−
 
+
−
In order to programatically suggest that the receiving entity should modify one or more items from its roster, the sending entity MUST send a <message/> or <iq/> stanza containing an <x/> element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the <x/> element in turn MUST contain one or more <item/> child elements, each of which MUST possess an 'action' attribute whose value is "modify", MUST possess a 'jid' attribute that specifies the JabberID of the item to be modified, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups into which to place the item.在以programatically表明，接收实体应修改的一个或多个项目，从它的名册，发送实体必须发出一个<message/>或<iq/> stanza载有一<x/>元素合格的由'的http:// jabber.org /协议/ rosterx '名字空间; <x/>元素，又必须包含一个或多个<item/>子元素，其中每一项都必须具备一'行动'的属性，其价值是“修改” ，必须具备一' jid '的属性，指定jabberid该项目要修改，可能具有的'名称'的属性，指定了一个自然语言的姓名或昵称项目，并可能包含一个或更多< group/>元素指定名册群体融入其中地方项目。 If a <message/> stanza is sent, it MAY contain a <body/> element but SHOULD NOT contain any other child elements.如果<message/> stanza发送，它可能包含一个<body/>元，但不应包含任何其他子元素。 Here is an example:下面是一个例子：
+
−
 
+
−
 
+
−
 
+
−
Example 3.例如3 。 Suggesting Modification建议修改
+
−
 
+
−
 
+
−
 
+
−
<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>了<message from='horatio@denmark.lit' to='hamlet@denmark.lit'> <x xmlns='http://jabber.org/protocol/rosterx'> <项目的行动= '修改' jid = ' rosencrantz @ denmark.lit姓名= ' rosencrantz “ > <group> retinue < /组> < /项目> <item action='modify' jid='guildenstern@denmark.lit' name='guildenstern'> <group> retinue < /组> < /项目> < / x > < /消息>
+
−
 
+
−
 
+
−
 
+
−
In determining how to handle any given roster item whose 'action' attribute has a value of "modify", the receiving application SHOULD proceed as follows:在决定如何处理任何特定名册的项目'行动'属性值“修改” ，接收的应用，应进行如下：
+
−
 
+
−
 
+
−
 
+
−
  1. If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.如果该项目不存在，在名册上，接收应用程序必须不提示人类用户批准关于该项目的，决不能补充说，项目名册。
+
−
 
+
−
  2. If the item exists in the roster and the modification results in a change of group only, the receiving application MAY prompt the user for approval and SHOULD move the item to the specified group.如果该项目存在的名册和修改的结果在改变组只，接收应用程序可能会提示用户批准，并应提出项目到指定的组。
+
−
 
+
−
  3. If the item exists in the roster and the modification results in adding the item to a new group in addition to its existing group, the receiving application MAY prompt the user for approval and SHOULD add the item to the specified group.如果该项目存在的名册和修改的结果，在加入该项目，以一个新的小组，除了它的现有组，接收应用程序可能会提示用户批准，并应添加项目到指定的组。
+
−
 
+
−
  4. If the item exists in the roster and the modification results in a change of name only, the receiving application MAY prompt the user for approval and SHOULD modify the name to that specified in the modification suggestion.如果该项目存在的名册和修改的结果在一个名称的改变只，接收应用程序可能会提示用户批准，并应修改名称所指定的修改建议。
+
−
 
+
−
 
+
−
 
+
−
If a roster item addition, deletion, or modification stanza will result in editing of an existing item in the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server with no changes to the 'subscription' attribute but rather with appropriate changes to the value of 'name' attribute or the <group/> child element or elements, as described in RFC 3921 .如果名册项目的增列，删除，或修改stanza将导致在编辑现有的项目在名册上，接收应用程序必须（要么批准，由一个人的用户或自动受配置）发送一份名册设置为用户的服务器没有改变， '认购'的属性，而是适当地修改的价值'名称'的属性，或<group/>子元素或元素，描述在RFC 3921 。
+
−
 
+
−
4. Service Discovery 4 。 服务发现
+
−
 
+
−
 
+
−
 
+
−
In order to determine whether a receiving entity supports the protocol defined herein, the sending entity SHOULD use Service Discovery [ 6 ] but MAY depend on the "profile" of Service Discovery defined in Entity Capabilities [ 7 ].以确定是否接收实体支持该议定书的定义在这里，发送实体应使用服务发现 [ 6 ] ，但可能取决于“个人资料”服务发现的定义， 实体的能力 [ 7 ] 。 If an entity supports roster item exchange, it MUST (subject to appropriate security considerations as described under Advertising Support ) include <feature var='http://jabber.org/protocol/rosterx'/> in its responses to disco#info queries.如果一个实体的支持名册项目外汇，它必须（遵守适当的安全方面的考虑下，所描述的广告支持 ） ，包括<feature var='http://jabber.org/protocol/rosterx'/>在其反应迪斯科＃信息查询。 Thus a sending entity can discover if a receiving entity supports the protocol defined herein by sending an IQ request of the following form:因此，一个发送实体可以发现，如果接收实体支持该议定书的定义在这里发送的智商的要求，采用以下形式：
+
−
 
+
−
 
+
−
 
+
−
Example 4.例如4 。 Sending Entity Queries for Support发送实体的查询支持
+
−
 
+
−
 
+
−
 
+
−
<iq from='horatio@denmark.lit/castle'    to='hamlet@denmark.lit/throne'    type='get'    id='disco1'>  <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> <iq from='horatio@denmark.lit/castle' to='hamlet@denmark.lit/throne' type='get' id='disco1'> <查询xmlns = ' http://jabber.org/protocol/迪斯科＃信息' / > < /智商>
+
−
 
+
−
 
+
−
 
+
−
The receiving entity then indicates its support:接收实体，然后表明其支持：
+
−
 
+
−
 
+
−
 
+
−
Example 5.例如5 。 Receiving Entity Advertises Support接收实体广告，支持
+
−
 
+
−
 
+
−
 
+
−
<iq from='hamlet@denmark.lit/throne'    to='horatio@denmark.lit/castle'    type='get'    id='disco1'>  <query xmlns='http://jabber.org/protocol/disco#info'>    ... <iq from='hamlet@denmark.lit/throne' to='horatio@denmark.lit/castle' type='get' id='disco1'> <查询xmlns = ' http://jabber.org/protocol/迪斯科＃信息“ > ... <feature var='http://jabber.org/protocol/rosterx'/>    ... <feature var='http://jabber.org/protocol/rosterx'/> ... </query> </iq> < /查询> < /智商>
+
−
 
+
−
 
+
−
 
+
−
5. Recommended Stanza Type 5 。 建议stanza类型
+
−
 
+
−
 
+
−
 
+
−
If the sending entity has knowledge (eg, via presence or an active chat conversation) that the receiving entity is online and available, it SHOULD: [ 8 ]如果发送实体的知识（例如，通过的存在或积极聊天会话）表示，接收实体在线并有空，它应： [ 8 ]
+
−
 
+
−
 
+
−
 
+
−
  1. Discover if the receiving entity supports the protocol defined herein (see the Service Discovery section of this document).发现如果接收实体支持该议定书的定义在此（见服务发现一节本文件） 。
+
−
 
+
−
  2. If so, send its roster item exchange stanza to a particular resource (user@host/resource) of the receiving entity using an <iq/> stanza rather than a <message/> stanza.如果是的话，派遣名册项目外汇stanza某一资源（用户@主机/资源）的接收实体使用<iq/> stanza而非<message/> stanza 。
+
−
 
+
−
 
+
−
 
+
−
If the sending entity does not know that the receiving entity is online and available, it MUST send a <message/> stanza to the receiving entity's "bare JID" (user@host) rather than an <iq/> stanza to a particular resource.如果派遣实体不知道接收实体在线并有空，它必须发出一个<message/> stanza到接收实体的“裸jid ” （用户@主机） ，而不是一个<iq/> stanza某一资源。
+
−
 
+
−
5.1 IQ Semantics 5.1 智商语义
+
−
 
+
−
 
+
−
 
+
−
If the sending entity uses <iq/> stanzas to communicate its roster item exchange suggestions, the receiving entity MUST adhere to the IQ semantics defined in XMPP Core [ 9 ].如果发送的实体使用<iq/> stanzas沟通，其名册项目交换意见，接收实体必须坚持以智商语义界定的XMPP协议的核心 [ 9 ] 。 Specifically:具体来说：
+
−
 
+
−
 
+
−
 
+
−
  1. If the receiving entity successfully processes the suggested action(s) (which may include ignoring certain suggestions), the receiving entity MUST return an empty IQ result to the sending entity.如果接收实体，成功地处理了所建议的行动（ ） （其中可能包括无视一些建议） ，接收实体必须返回一个空的智商结果传送实体。
+
−
 
+
−
  2. If the receiving entity does not understand the roster item exchange namespace, the receiving entity MUST return an error to the sending entity, which error SHOULD be <service-unavailable/>.如果接收实体不明白名册项目外汇名字空间，接收实体必须返回一个错误给发送实体，其中的错误，应该<service-unavailable/> 。
+
−
 
+
−
  3. If the receiving entity will not process the suggested action(s) because the receiving entity is not registered with the sending entity, the receiving entity MUST return an error to the sending entity, which error SHOULD be <registration-required/>.如果接收实体将不会过程中建议采取的行动（ ） ，因为接收实体是没有登记与发送实体，接收实体必须返回一个错误给发送实体，其中的错误，应该<registration-required/> 。
+
−
 
+
−
  4. If the receiving entity will not process the suggested action(s) because the sending entity is not in the receiving entity's roster, the receiving entity MUST return an error to the sending entity, which error SHOULD be <not-authorized/>.如果接收实体将不会过程中建议采取的行动（ ） ，因为发送的实体是不是在接收实体的名册，接收实体必须返回一个错误给发送实体，其中的错误，应该<not-authorized/> 。
+
−
 
+
−
  5. If the receiving entity will not process the suggested action(s) because the sending entity is not trusted (see Trusted Entities ), the receiving entity MUST return an error to the sending entity, which error SHOULD be <forbidden/>.如果接收实体将不会过程中建议采取的行动（ ） ，因为发送的实体是不信任（见信任的实体 ） ，接收实体必须返回一个错误给发送实体，其中的错误，应该<forbidden/> 。
+
−
 
+
−
 
+
−
 
+
−
Naturally, other IQ errors may be more appropriate; however, if the receiving entity will not or cannot process the suggested action(s), it MUST return an error to the sending entity.当然，其他的智商错误，可能更为合适;不过，如果接收实体将不会或不能过程中所建议的行动（ s ）款，它必须返回一个错误给发送实体。
+
−
 
+
−
6. Business Rules 6 。 业务规则
+
−
 
+
−
 
+
−
 
+
−
  1.
+
−
 
+
−
 
+
−
 
+
−
      The sending entity or sending application MUST NOT send additions, deletions, and modifications in the same <x/> element and <message/> or <iq/> stanza; instead, it SHOULD send separate stanzas for the additions, deletions, and modifications.发送实体或传送的应用绝不能发送添加，删除和修改，在相同的<x/>元素和<message/>或<iq/> stanza ;相反，它应该发送单独的stanzas为新增，删除和修改。
+
−
 
+
−
  2.
+
−
 
+
−
 
+
−
 
+
−
      If approval is required or recommended regarding more than one item suggested by the sending entity, the receiving entity SHOULD present all of the items for approval at the same time or in the same interface.如果批准要求或建议的就不止一个项目所提出的实体发送，接收实体应目前的所有项目审批，在同一时间，或在同一界面上。
+
−
 
+
−
  3.
+
−
 
+
−
 
+
−
 
+
−
      If the sending entity is in some sense "trusted" (see Trusted Entities ), then the receiving application MAY skip the approval steps described above.如果派遣实体，是在一定意义上的“信任” （见信任的实体 ） ，然后接收应用程序可能会跳过批准的步骤，上文所述。
+
−
 
+
−
  4.
+
−
 
+
−
 
+
−
 
+
−
      The receiving application SHOULD NOT accept an unreasonable number of roster items from any one sending entity at one time.接收应用程式都不应该接受一个不合理的数目，名册项目从任何一个发送实体在同一时间。 Unfortunately, it can be difficult to determine how many roster items count as "unreasonable".不幸的是，它可以很难确定有多少项目名册计数作为“不合理” 。 For example, when a user registers with a gateway, it is possible that the initial set of roster items may be quite large (however, note that most existing consumer IM services enforce a limit of 100 to 150 items in their contact lists).举例来说，当用户登记的门户，它可能是一套初步名册项目的可能非常大（不过，请注意，大多数现有的消费者即时通讯服务执行的限制从100到150项，在他们的联系人名单） 。 Users who have newly registered with or been newly created on a server (eg, within an organization) may also receive a large set of initial roster items in order to sync up with shared groups established on the server.用户谁有新的注册人或已新创建的服务器上（例如，在一个组织内） ，也可能会收到大量的一套初步名册的项目，以同步与共享的团体建立了在服务器上。 However, after such initialization, the subsequent roster item sets should be much smaller.不过，经过这样的初始化，随后名册项目集应该要小得多。 In any case, sets of more than 150 or 200 roster items SHOULD be treated with suspicion, and entities that repeatedly send such sets SHOULD NOT be trusted.在任何情况下，套以上的150或200名册项目的待遇应与猜疑，和实体反复发送这样的套不应该是不可信的。
+
−
 
+
−
 
+
−
 
+
−
7. Types of Sending Entities 7 。 类型的传送实体
+
−
 
+
−
 
+
−
 
+
−
The foregoing protocol description speaks only of "sending entities" and does not differentiate between different types of sending entities.前述议定书描述说，只有“发送实体”和不区分不同类型的传送实体。 However, it is envisioned that roster items will be sent to receiving entities by three different kinds of senders:不过，这是设想，名册上项目将被发送到接收实体由3个不同的种发件人：
+
−
 
+
−
 
+
−
 
+
−
  1. Users of Jabber clients.用户的Jabber客户端。
+
−
 
+
−
  2. Client proxy gateways.客户端代理网关。
+
−
 
+
−
  3. Shared group services.共享组服务。
+
−
 
+
−
 
+
−
 
+
−
These are described more completely below.这些都是描述更完整地下面。
+
−
 
+
−
7.1 Jabber Users 7.1 的Jabber用户
+
−
 
+
−
 
+
−
 
+
−
Roster item exchange as developed within the early Jabber community and documented in XEP-0093 was used to send a roster item from one user to another in a manner more structured than simply typing a third party's JID in a chat window.名册项目外汇作为开发的早期的Jabber社区和记载的xep - 0093被用来发送一份名册上项目，从一个用户到另一个在一个更有条理的方式，比单纯输入第三党的jid在一个聊天窗口。 This usage is still encouraged.这使用仍然是鼓励的。 However, if the sender is a human user and/or the sending application has a primary Service Discovery category of "client" (eg, a bot) [ 10 ], the sending application SHOULD NOT specify an 'action' attribute other than "add", the receiving application MAY ignore values of the 'action' attribute other than "add", and the receiving application MUST prompt a human user regarding whether to add the suggested item or items to the user's roster.然而，如果发件人是一项人权，用户和/或传送的应用设有一所小学服务发现类“客户端” （例如，建造，营运及移交） [ 10 ] ，传送的应用不应该指定一个'行动'的属性以外的“添加“ ，接收应用程序可能会忽略的价值观'行动'的属性以外的”添加“ ，并接受申请者必须提示用户一个人就是否加入建议的项目或项目到用户的名册。
+
−
 
+
−
7.2 Gateways 7.2 网关
+
−
 
+
−
 
+
−
 
+
−
The nature of client proxy gateways (ie, entities with a service discovery category of "gateway") is specified more fully in Gateway Interaction [ 11 ].的性质，客户端代理网关（即，实体与服务发现被归类为“网关” ）是指定的更充分地在网关的互动 [ 11 ] 。 Herein we describe how such gateways should use roster item exchange, and how receiving applications should treat roster items received from such gateways.我们在此描述了如何这样的网关应使用名册的项目交流，以及如何接受申请要善待名册项目收到了这样的网关。
+
−
 
+
−
 
+
−
 
+
−
In order to make use of a gateway's protocol translation service, a user MUST first register with the gateway.在为了使使用一个网关的协议翻译服务，使用者必须先登记的门户。 If the gateway advertises support for a service discovery feature of 'http://jabber.org/protocol/rosterx', then the user's client SHOULD expect that it may receive roster item suggestions from the gateway.如果网关宣传支持服务发现功能' http://jabber.org/protocol/rosterx ' ，然后用户的客户端应该期望它可能会收到名册的项目建议，从网关。 In order to maintain synchronization between the user's contact list on a legacy IM service and the user's Jabber roster, the gateway SHOULD send roster items with an 'action' attribute of "add", "delete", or "modify" as appropriate, and the receiving application SHOULD process such roster item suggestions.在为了保持同步之间的用户的联络人清单上的遗产，即时通讯服务和用户的的Jabber名册，网关应发送名册项目一'行动'的属性“添加” ， “删除” ，或“修改”适当的，接受申请的过程中应名册等项目的建议。 Such processing MAY occur automatically (ie, without the user's approval of each roster item or batch of roster items) if and only if the receiving application has explicitly informed the user that it will automatically process roster items from the gateway.这样的处理，可能会出现自动（即，如果没有用户的批准，每个名册项目或一批项目名册）当且仅当接收的应用已明确告知用户，它会自动的过程名册项目从网关。 Furthermore, the receiving application SHOULD periodically verify automatic processing with the user (eg, once per session in which the gateway sends roster item suggestions to the user).此外，接收的应用应定期验证的自动处理与用户（例如，每一次会议在该网关发送名册项目的建议，向用户） 。
+
−
 
+
−
7.3 Group Services 7.3 组服务
+
−
 
+
−
 
+
−
 
+
−
There is a third category of entities that might initiate roster item exchanges, which we label a "group service" and identify by a Service Discovery category of "directory" and type of "group".有一个第三类的实体可能发起名册项目的交流，这是我们的标签“集团服务” ，并确定由一个服务发现类“目录”和类型的“集团” 。 A group service enables an administrator to centrally define and administer roster groups so that they can be shared among a user population in an organized fashion.一组服务，可让管理员集中定义和管理名册群体，使他们能够共享用户的人口在一个有组织的时装。 Such a service could prove useful in enterprise environments [ 12 ] and other settings where it is beneficial to synchronize rosters across individuals (eg, schools, social networking applications, consumer IM services, and anywhere else that it is important to build and manage small communities of users).这种服务可以证明是有用的在企业环境中[ 12 ]和其他设置的地方，这是有利于同步名册全国个人（例如，学校，社会网络的应用，消费者的即时通讯服务，和其他地方，这是重要的建设和管理小社区用户） 。
+
−
 
+
−
 
+
−
 
+
−
In some contexts, an IM server could function as a group service (eg, if there is a single server deployed on a small company intranet); in other contexts, it may make more sense to deploy a standalone group service (eg, in a larger or more heterogeneous environment with users on multiple servers).在一些背景下，一个IM服务器的功能，可以作为一个集团服务（例如，如果有一台服务器上部署了一个小公司Intranet ） ;在其他情况下，它可能会使更多的意义上部署一个独立的组服务（例如，在一个规模较大或更多的异构环境与用户在多个服务器上） 。 In both cases, the group service MUST advertise a service discovery identity of "directory/group" and SHOULD use the protocol specified herein to communicate changes ("add", "delete", and "modify") to the relevant shared groups; in addition, a user MUST first register with the service (either over Jabber via In-Band Registration [ 13 ] or out of band, eg, via the web) or be otherwise provisioned to use the service (eg, by a system administrator) before accepting roster item suggestions from the service.在这两种情况下，该集团的服务，必须宣传服务发现的身份“目录/组” ，并应使用该议定书指定在此沟通的变化（ “添加” ， “删除”和“修改” ） ，向有关的团体共享;此外，使用者必须先登记与服务（以上的Jabber通过在波段注册 [ 13 ]或走出波段，例如，通过网络）或否则provisioned使用服务（例如，由系统管理员）之前，接受名册项目的建议，从服务。
+
−
 
+
−
 
+
−
 
+
−
If the user has registered with a group service or been otherwise provisioned to use a group service, the receiving application SHOULD process roster item suggestions received from the service.如果用户已注册的一组服务或以其他方式provisioned使用一组服务，接收的应用过程中应名册项目的建议，收到来自服务。 Such processing MAY occur automatically (ie, without the user's approval of each roster item or batch of roster items) if and only if the receiving application has explicitly informed the user that it will automatically process roster items from the service.这样的处理，可能会出现自动（即，如果没有用户的批准，每个名册项目或一批项目名册）当且仅当接收的应用已明确告知用户，它会自动的过程名册项目从服务。 Furthermore, the receiving application SHOULD periodically verify automatic processing with the user (eg, once per session in which the service sends roster item suggestions to the user).此外，接收的应用应定期验证的自动处理与用户（例如，每一次会议在该服务发送名册项目的建议，向用户） 。
+
−
 
+
−
8. Security Considerations 8 。 安全方面的考虑
+
−
 
+
−
8.1 Trusted Entities 8.1 信任的实体
+
−
 
+
−
 
+
−
 
+
−
A principal (user) or receiving application MAY establish a list of trusted entities from which roster item exchanges are processed automatically, ie, without explicit approval by a human user.主要（用户）或接收应用程序可能会建立一个名单，值得信赖的实体从哪个名册项目的交流是自动处理，即没有明确的批准，由一个人的用户。 In order to avoid corruption of the roster, it is STRONGLY RECOMMENDED that such trusted entities be limited to gateways and group services as defined above.在为了避免腐败的名册，这是强烈建议，这种信任的实体限于网关和小组服务，如上所确定的。 In addition, the receiving application SHOULD periodically verify such automatic processing with the principal, eg, once per session in which the trusted entity sends roster item suggestions to the user.此外，该接收的应用，应定期核查，如自动处理与校长，例如，每一次会议中，受信任的实体发送名册项目的建议，给使用者。
+
−
 
+
−
8.2 Denial of Service 8.2 拒绝服务
+
−
 
+
−
 
+
−
 
+
−
A sending entity could effectively deny service to the receiving entity by rapidly and repeatedly sending (1) alternating add and delete suggestions or (2) modify suggestions, thus invoking throttling mechanisms enforced by the receiving entity's server.传送实体可以有效地否认服务，接收实体迅速，并多次派（ 1 ）交替添加和删除的建议，或（ 2 ）修改的建议，从而援引节流机制所执行的接收实体的服务器上。 The receiving application SHOULD guard against this by monitoring roster item exchanges received from each sending entity and refusing or ignoring roster item exchanges from offending entities (eg, by adding such entities to a list of distrusted entities).接收的应用，应防止这种情况监测名册项目的交流，收到每一个发送实体和拒绝或无视名册项目交流会得罪实体（如，加入这样的实体名单不信任实体） 。
+
−
 
+
−
8.3 Advertising Support 8.3 广告支持
+
−
 
+
−
 
+
−
 
+
−
A receiving application MAY refuse to advertise its support for the roster item exchange protocol (see the Service Discovery section of this document) to entities that that are (1) not explicitly trusted or (2) explicitly distrusted.接收应用程序可能会拒绝刊登广告，支持名册项目交换协议（见服务发现一节本文件）的实体，这是（ 1 ）没有明确的信任或（ 2 ）明确不信任。
+
−
 
+
−
9. IANA Considerations 9 。 iana考虑
+
−
 
+
−
 
+
−
 
+
−
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [ 14 ].本文件无需作出任何的互动与互联网的人数分派管理局（ iana ） [ 14 ] 。
+
−
 
+
−
10. XMPP Registrar Considerations 10 。 XMPP协议书记官长考虑
+
−
 
+
−
10.1 Protocol Namespaces 10.1 议定书命名空间
+
−
 
+
−
 
+
−
 
+
−
The XMPP Registrar [ 15 ] includes 'http://jabber.org/protocol/rosterx' in its registry of protocol namespaces.该XMPP协议书记官长 [ 15 ] ，包括' http://jabber.org/protocol/rosterx '在其境内注册的议定书的命名空间。
+
−
 
+
−
10.2 Service Discovery Identities 10.2 服务发现身份
+
−
 
+
−
 
+
−
 
+
−
The XMPP Registrar includes a Service Discovery type of "group" under the "directory" category in its registry of service discovery identities.该XMPP协议书记官长包括服务发现类型的“组”下的“目录”类在其境内注册的服务发现的身份。
+
−
 
+
−
11. XML Schema 11 。 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'/>        <xs:simpleType>          <xs:restriction base='xs:NCName' default='add'>            <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> < ？ XML版本= '1 .0 '编码= ' -8 ' ？ > < XS的：架构xmlns ： XS的= ' http://www.w3.org/2001/xmlschema ' targetnamespace = ' http://jabber.org /协议/ rosterx ' xmlns = ' http://jabber.org/protocol/rosterx ' elementformdefault = '合格“ > <xs:annotation> <xs:documentation>议定书所记录的此架构的定义是在xep - 0144 ： HTTP的： / / www.xmpp.org/extensions/xep-0144.html < / XS的：文件> < / XS的：注释> <xs:element name='x'> <xs:complextype> <xs:sequence> < XS的：元素号= '项目' minoccurs = '1 ' maxoccurs = '无界' / > < / XS的：序> < / XS的： complextype > < / XS的：元素> <xs:element name='item'> < XS的： complextype > <xs:sequence> <xs:element name='group' type='xs:string' minoccurs='0' maxoccurs='unbounded'/> < / XS的：序> < XS的：属性名称= '行动'使用= '可选' / > <xs:simpletype> <xs:restriction base='xs:ncname' default='add'> <xs:enumeration value='add'/> < XS的：列举值= '删除' / > <xs:enumeration value='modify'/> < / XS的：限制> < / XS的： simpletype > < / XS的：属性> < XS的：属性名称= ' jid '型= ' XS的：字符串'使用= '所需的' / > <xs:attribute name='name' type='xs:string' use='optional'/> < / XS的： complextype > < / XS的：元素> < / XS的：架构>
+
−
 
+
−
 
+
−
 
+
−
Notes债券
+
−
 
+
−
 
+
−
 
+
−
1 . 1 。 RFC 2779: A Model for Presence and Instant Messaging < http://tools.ietf.org/html/rfc2779 >.符合RFC 2779 ：一个模式的存在和即时通讯< http://tools.ietf.org/html/rfc2779 > 。
+
−
 
+
−
 
+
−
 
+
−
2 . 2 。 RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence < http://tools.ietf.org/html/rfc3921 >.符合RFC 3921 ：可扩展消息和存在协议（ XMPP协议） ：即时通讯和存在的< http://tools.ietf.org/html/rfc3921 > 。
+
−
 
+
−
 
+
−
 
+
−
3 . 3 。 XEP-0093: Roster Item Exchange < http://www.xmpp.org/extensions/xep-0093.html >. xep - 0093 ：名册项目外汇< http://www.xmpp.org/extensions/xep-0093.html > 。
+
−
 
+
−
 
+
−
 
+
−
4 . 4 。 The Standards SIG is a standing Special Interest Group devoted to development of XMPP Extension Protocols.标准SIG的是一个常设的特殊利益集团致力于发展XMPP协议延长议定书。 The discussion list of the Standards SIG is the primary venue for discussion of XMPP protocol extensions, as well as for announcements by the XMPP Extensions Editor and XMPP Registrar.讨论名单的标准SIG的是小学的场地，讨论协议的扩展，以及为公告由XMPP协议的扩展编辑和XMPP协议注册处处长。 To subscribe to the list or view the list archives, visit < http://mail.jabber.org/mailman/listinfo/standards/ >.订阅名单或检视清单档案，请访问< http://mail.jabber.org/mailman/listinfo/standards/ > 。
+
−
 
+
−
 
+
−
 
+
−
5 . 5 。 The default value of the 'action' attribute is "add"; therefore, if the 'action' attribute is not included or the receiving application does not understand the 'action' attribute, the receiving application MUST treat the item as if the value were "add".默认值'行动'的属性是“新增” ;因此，如果'行动'的属性是未列入或接收的应用不明白'行动'的属性，接收应用程序必须处理的项目，犹如值分别为“添加” 。
+
−
 
+
−
 
+
−
 
+
−
6 . 6 。 XEP-0030: Service Discovery < http://www.xmpp.org/extensions/xep-0030.html >. xep - 0030 ：服务发现< http://www.xmpp.org/extensions/xep-0030.html > 。
+
−
 
+
−
 
+
−
 
+
−
7 . 7 。 XEP-0115: Entity Capabilities < http://www.xmpp.org/extensions/xep-0115.html >. xep - 0115 ：实体的能力， < http://www.xmpp.org/extensions/xep-0115.html > 。
+
−
 
+
−
 
+
−
 
+
−
8 . 8 。 If the receiving entity has more than one available resource, the sending application SHOULD communicate with the "most available" resource according its best estimation (eg, the resource with the highest priority).如果接收实体有一个以上的可用的资源，传送的应用，应沟通“最可用的”资源根据其最佳估计（例如，资源与最高优先级） 。
+
−
 
+
−
 
+
−
 
+
−
9 . 9 。 RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core < http://tools.ietf.org/html/rfc3920 >.符合RFC 3920 ：可扩展消息和存在协议（ XMPP协议） ：核心< http://tools.ietf.org/html/rfc3920 > 。
+
−
 
+
−
 
+
−
 
+
−
10 . 10 。 See < http://www.xmpp.org/registrar/disco-categories.html#client >.见< http://www.xmpp.org/registrar/disco-categories.html ＃客户端 > 。
+
−
 
+
−
 
+
−
 
+
−
11 . 11 。 XEP-0100: Gateway Interaction < http://www.xmpp.org/extensions/xep-0100.html >. xep - 0100 ：网关的互动< http://www.xmpp.org/extensions/xep-0100.html > 。
+
−
 
+
−
 
+
−
 
+
−
12 . 12 。 For example, when Alice is hired by the marketing department of Big Company Enterprises, it makes sense for her to automatically have the other members of the marketing department in her roster the first time she logs in, and for the rest of the marketing department to have Alice in their rosters as soon as her account has been set up.举例来说，当Alice是聘请的营销部门的大公司，企业，它是有道理的，她自动具有其他成员的市场营销部在她的名册上的第一时间，她在日志中，至于其余的营销部门以有李翘如在他们的名册尽快她的帐户已成立。 Similarly, when Bob in logistics gets fired, it makes sense for him to disappear from the rosters of everyone else in the logistics department.同样地，当Bob在物流得到发射，它是有道理的，他消失从名册其他所有人，在物流服务署。
+
−
 
+
−
 
+
−
 
+
−
13 . 13 。 XEP-0077: In-Band Registration < http://www.xmpp.org/extensions/xep-0077.html >. xep - 0077 ：在波段注册< http://www.xmpp.org/extensions/xep-0077.html > 。
+
−
 
+
−
 
+
−
 
+
−
14 . 14 。 The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see < http://www.iana.org/ >.
+
−
 
+
−
 
+
−
 
+
−
15 . The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see < http://www.xmpp.org/registrar/ >.
+
−
 
+
−
Revision History
+
−
 
+
−
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)
+
−
 
+
−
 
+
−
 
+
−
END
+
−
 
+
−
"
+

2013年7月26日 (五) 06:26的最后版本


本文的英文原文来自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=3276”
个人工具