XEP-0144
小 |
小 |
||
| 第4行： | 第4行： | ||
'''本文的英文原文来自[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协议扩展, 这个规范定义了一个协议的扩展，用于交换联系人列表条目，包括以下能力,建议条目是否要被添加，删除或在接收者的联系人列表中修改，以及建议该条目所在的名册组。 | |
| − | + | 作者: Peter Saint-Andre | |
| − | + | 版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见[[XEP-0144#附录C:法律通告|法律通告]]. | |
| − | + | 状态: 草案 | |
| − | + | 类型: 标准跟踪 | |
| − | + | 版本: 1.0 | |
| − | + | 最后更新日期: 2005-08-26 | |
| − | + | -------------------------------------------------------------------------------- | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | 注意: 这里定义的协议是XMPP标准化基金会的一个'''草案标准'''.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动. | ||
| + | |||
| + | -------------------------------------------------------------------------------- | ||
\1. [简介|XMPP文档列表/XMPP扩展/XEP-0144#简介] | \1. [简介|XMPP文档列表/XMPP扩展/XEP-0144#简介] | ||
2013年7月25日 (四) 02:58的版本
本文的英文原文来自XEP-0144
XEP-0144 ：名册条目交换
摘要: 本协议定义了一个XMPP协议扩展, 这个规范定义了一个协议的扩展，用于交换联系人列表条目，包括以下能力,建议条目是否要被添加，删除或在接收者的联系人列表中修改，以及建议该条目所在的名册组。
作者: Peter Saint-Andre
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.
状态: 草案
类型: 标准跟踪
版本: 1.0
最后更新日期: 2005-08-26
注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
\1. [简介|XMPP文档列表/XMPP扩展/XEP-0144#简介]
2. [要求|XMPP文档列表/XMPP扩展/XEP-0144#要求]
3. [使用案例|XMPP文档列表/XMPP扩展/XEP-0144#使用案例]
3.1. [名册项目建议新增|XMPP文档列表/XMPP扩展/XEP-0144#名册项目建议新增]
3.2. [名册项目建议删除|XMPP文档列表/XMPP扩展/XEP-0144#名册项目建议删除]
3.3. [名册项目建议修改|XMPP文档列表/XMPP扩展/XEP-0144#名册项目建议修改]
4. [服务发现|XMPP文档列表/XMPP扩展/XEP-0144#服务发现]
5. [建议stanza类型|XMPP文档列表/XMPP扩展/XEP-0144#建议stanza类型]
5.1. [IQ语义|XMPP文档列表/XMPP扩展/XEP-0144#IQ语义]
6. [业务规则|XMPP文档列表/XMPP扩展/XEP-0144#业务规则]
7. [发送实体的类型|XMPP文档列表/XMPP扩展/XEP-0144#发送实体的类型]
7.1. [Jabber用户|XMPP文档列表/XMPP扩展/XEP-0144#Jabber用户]
7.2. [网关|XMPP文档列表/XMPP扩展/XEP-0144#网关]
7.3. [组服务|XMPP文档列表/XMPP扩展/XEP-0144#组服务]
8. [安全方面的考虑|XMPP文档列表/XMPP扩展/XEP-0144#安全方面的考虑]
8.1. [信任的实体|XMPP文档列表/XMPP扩展/XEP-0144#信任的实体]
8.2. [拒绝服务|XMPP文档列表/XMPP扩展/XEP-0144#拒绝服务]
8.3. [广告支持|XMPP文档列表/XMPP扩展/XEP-0144#广告支持]
9. [IANA考虑|XMPP文档列表/XMPP扩展/XEP-0144#IANA考虑]
10. [XMPP Registrar考虑|XMPP文档列表/XMPP扩展/XEP-0144#XMPP Registrar考虑]
10.1. [协议命名空间|XMPP文档列表/XMPP扩展/XEP-0144#协议命名空间]
10.2. [服务发现身份|XMPP文档列表/XMPP扩展/XEP-0144#服务发现身份]
\11. [XML架构|XMPP文档列表/XMPP扩展/XEP-0144#XML架构]
[备注|XMPP文档列表/XMPP扩展/XEP-0144#备注]
[修订历史|XMPP文档列表/XMPP扩展/XEP-0144#修订历史]__
__\1. 简介__ {anchor:简介}
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.进一步规范将界定如何解决的问题，共享团体和名册同步使用该议定书的定义在这里。
2. Requirements 2 。 要求
XEP-0093 did not define the requirements for roster item exchange. xep - 0093未界定的要求，名册项目的交流。 This section remedies that oversight.本节的补救措施，监督。
Roster item exchange meets the following requirements:名册项目外汇满足以下要求：
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.使一个实体发送一个或多个项目名册给另一个实体，有人认为，名册（某些）项目被添加到收件人的名册。
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.使一个实体发送一个或多个项目名册给另一个实体，有人认为，名册（某些）项目予以删除，从收件人的名册。
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.使一个实体发送一个或多个项目名册给另一个实体，有人认为，名册项目（ ）修改在收件人的名册。
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.这是故意的。
3. Use Cases 3 。 使用案例
3.1 Suggesting Roster Item Addition 3.1 建议名册的项目，除了
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:下面是一个例子：
Example 1.例如1 。 Suggesting Addition建议除了
<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 > < /消息>
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
"
