XEP-0144

来自Jabber/XMPP中文翻译计划

（版本间的差异）

跳转到：导航, 搜索

2013年7月25日 (四) 09:02的版本

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

XEP-0144 ：名册条目交换

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

作者: Peter Saint-Andre

状态: 草案

类型: 标准跟踪

版本: 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未定义名册条目交换的需求. 本章纠正了那个疏忽.

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

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

本文故意讲到名册和名册条目, 而不是出席信息订阅. 尽管名册和订阅是紧密连接的(如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"(要么显式地要么作为缺省值)的名册条目时, 接收的应用应该处理如下:

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

如果该名册条目添加节将导致添加该条目到名册, 该接收应用必须(要么由一个自然人用户批准要么自动遵循配置)发送一个包含新条目的如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"的名册条目时, 接收应用应该处理如下:

如果该条目不存在于名册中, 该接收应用不能(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. 建议修改

<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"的名册条目时, 接收的应用应该处理如下:

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

如果一个名册条目添加，删除，或修改节将导致编辑一个名册中已有的条目, 该接收应用必须(要么由一个自然人用户批准要么自动遵循配置)发送一个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>

商业规则

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

发送实体的类型

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

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

完整描述如下.

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有任何互动。

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

来自“http://wiki.jabbercn.org/index.php?title=XEP-0144&oldid=3253”

2个分类:

@@ 第233行： / 第233行： @@
 ===信任的实体===
+一个当事人(用户)或接收应用可以建立一个信任实体的列表，从这个列表的实体来的名册条目交换被自动处理, 即, 不用一个自然人用户显式地批准. 为了防止名册的腐败, 强烈推荐这类信任的实体限于上面定义的网关和组服务. 另外, 接收实体应该让当事人定期检查这类自动处理, 例如, 每次被信任的实体发送名册条目建议给该用户的会话的时候.
+===拒绝服务===
-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.此外，该接收的应用，应定期核查，如自动处理与校长，例如，每一次会议中，受信任的实体发送名册项目的建议，给使用者。
+一个发送实体能有效地对接收实体进行拒绝服务攻击，通过快速和重复地发送 (1) 交替的 add 和 delete 建议 或 (2) modify 建议, 所以接收实体的服务器被强制调用扼杀机制. 接收应用应该通过监控从每个发送实体接收到的名册条目交换来压制它并且拒绝或忽略来自问题实体的名册条目交换(例如, 把这类实体加到一个不信任实体列表中).
-.2 Denial of Service 8.2 拒绝服务
+===声明支持===
+一个接收应用可以拒绝向那些 (1) 未显式地信任 或 (2) 显式地不信任 的实体声明它对名册条目交换协议的支持(见本文的[[XEP-0144#服务查询|服务查询]]章节).
+==IANA事项==
-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).接收的应用，应防止这种情况监测名册项目的交流，收到每一个发送实体和拒绝或无视名册项目交流会得罪实体（如，加入这样的实体名单不信任实体） 。
+本文不需要和[http://www.iana.org/ 互联网编号分配授权机构(IANA)] [[XEP-0114#附录G:备注|14]]有任何互动。
-.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 ）明确不信任。
-. IANA Considerations 9 。 iana考虑
-This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [ 14 ].本文件无需作出任何的互动与互联网的人数分派管理局（ iana ） [ 14 ] 。
 . XMPP Registrar Considerations 10 。 XMPP协议书记官长考虑