XEP-0144
小 (→建议名册条目修改) |
小 (→服务查询) |
||
| 第143行： | 第143行： | ||
==服务查询== | ==服务查询== | ||
| + | 为了确定是否一个接收实体支持这里定义的协议, 发送实体应该使用[[XEP-0030|服务查询]] [[XEP-0144#附录G:备注|6]] 但可以依赖[[XEP-0115|实体能力]] [[XEP-0144#附录G:备注|7]]定义的服务查询的"profile". 如果一个实体支持名册条目交换, 它必须(遵循如[[XEP-0144#声明支持|声明支持]]所述的适当的安全事项)在它对对 disco#info 查询的应答中包含 <feature var='http://jabber.org/protocol/rosterx'/>. 于是一个发送实体能查询是否一个接收实体支持这里定义的协议，通过发送一个如下格式的IQ请求: | ||
| − | + | '''例子 4. 发送实体查询支持''' | |
| + | <source lang="xml"> | ||
| + | <iq from='horatio@denmark.lit/castle' | ||
| + | to='hamlet@denmark.lit/throne' | ||
| + | type='get' | ||
| + | id='disco1'> | ||
| + | <query xmlns='http://jabber.org/protocol/disco#info'/> | ||
| + | </iq> | ||
| + | </source> | ||
| + | 接收实体接着表示它的支持: | ||
| − | + | '''例子 5. 接收实体声明支持''' | |
| + | <source lang="xml"> | ||
| + | <iq from='hamlet@denmark.lit/throne' | ||
| + | to='horatio@denmark.lit/castle' | ||
| + | type='get' | ||
| + | id='disco1'> | ||
| + | <query xmlns='http://jabber.org/protocol/disco#info'> | ||
| + | ... | ||
| + | <feature var='http://jabber.org/protocol/rosterx'/> | ||
| + | ... | ||
| + | </query> | ||
| + | </iq> | ||
| + | </source> | ||
| − | + | ==推荐的节类型== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
2013年7月25日 (四) 07:10的版本
本文的英文原文来自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未定义名册条目交换的需求. 本章纠正了那个疏忽.
名册条目交换满足以下要求:
- 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议把那个名册条目(们)加入到接收者的名册.
- 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议把那个名册条目(们)从接收者的名册中删除.
- 允许一个实体发送一个或多个名册条目给另一个实体, 以及建议在接收者的名册中修改那个名册条目(们).
本文故意讲到名册和名册条目, 而不是出席信息订阅. 尽管名册和订阅是紧密连接的(如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>
推荐的节类型
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
"
