XEP-0144

来自Jabber/XMPP中文翻译计划
（版本间的差异）
跳转到： 导航, 搜索
小 (→商业规则)
小 (→服务查询)
 
（未显示1个用户的12个中间版本）
第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]'''
第28行： 第28行：
 
==绪论==
 
==绪论==
  
−
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'名字空间名字。更多的规范将定义如何使用这里定义的协议来解决共享组和名册同步的问题.
+
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' 名字空间名字。更多的规范将定义如何使用这里定义的协议来解决共享组和名册同步的问题.
  
 
==需求==
 
==需求==
第79行： 第79行：
 
===建议名册条目删除===
 
===建议名册条目删除===
  
−
为了程序化地建议接收实体应该从它的名册删除一个或多个条目, 发送实体必须发送一个包含由'http://jabber.org/protocol/rosterx'命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个必须拥有一个值为"delete"的'action'属性, 必须拥有一个'jid'属性来指定要被删除的条目的JabberID, 可以拥有一个'name'属性来为该条目指定一个自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来为该条目指定名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这是一个例子:
+
为了程序化地建议接收实体应该从它的名册删除一个或多个条目, 发送实体必须发送一个包含由 'http://jabber.org/protocol/rosterx' 命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个必须拥有一个值为"delete"的'action'属性, 必须拥有一个'jid'属性来指定要被删除的条目的JabberID, 可以拥有一个'name'属性来为该条目指定一个自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来为该条目指定名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这是一个例子:
  
 
'''例子 2. Suggesting Deletion'''
 
'''例子 2. Suggesting Deletion'''
第110行： 第110行：
 
===建议名册条目修改===
 
===建议名册条目修改===
  
−
为了程序化地建议接收实体应该从它的名册中修改一个或多个条目, 发送实体必须发送一个包含由'http://jabber.org/protocol/rosterx'命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个都应该拥有一个值为"modify"的'action'属性, 必须拥有一个'jid'属性来指定被修改的条目的JabberID, 可以拥有一个'name'属性来指定一个用于该条目的自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来指定存放该条目的名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这里是例子:
+
为了程序化地建议接收实体应该从它的名册中修改一个或多个条目, 发送实体必须发送一个包含由 'http://jabber.org/protocol/rosterx' 命名空间限定的<x/>元素的<message/>或<iq/>节; 相应的该<x/>元素必须包含一个或多个<item/>子元素, 每个都应该拥有一个值为"modify"的'action'属性, 必须拥有一个'jid'属性来指定被修改的条目的JabberID, 可以拥有一个'name'属性来指定一个用于该条目的自然语言名称或昵称, 并且可以包含一个或多个<group/>元素来指定存放该条目的名册组. 如果一个<message/>节被发送了, 它可以包含一个<body/>元素但不应该(SHOULD NOT)包含任何子元素. 这里是例子:
  
 
'''例子 3. 建议修改'''
 
'''例子 3. 建议修改'''
第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请求:
+
为了确定是否一个接收实体支持这里定义的协议, 发送实体应该使用[[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. 发送实体查询支持'''
 
'''例子 4. 发送实体查询支持'''
第171行： 第171行：
 
   </query>
 
   </query>
 
</iq>
 
</iq>
−
</source>
+
</source>
  
 
==推荐的节类型==
 
==推荐的节类型==
第204行： 第204行：
 
==发送实体的类型==
 
==发送实体的类型==
  
 +
前述的协议描述只讲了"发送实体们"而没有区分不同类型的发送实体. 无论如何, 设想中名册条目将由三种不同的发送者发送给接收者:
  
 +
:# Jabber客户端用户.
 +
:# 客户端代理网关.
 +
:# 共享组服务.
  
−
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个不同的种发件人：
+
完整描述如下.
  
 +
===Jabber用户===
  
 +
名册条目交换是在早期的Jabber社区被开发出来的并且被记录在XEP-0093中，它被用于从一个用户发送一个名册条目到另一个用户, 在某种程度上它比简单地在聊天窗口中键入一个第三方的JID更加结构化. 这一用途仍然是被鼓励的. 无论如何, 如果发送者是一个自然人用户 和/或 发送应用 的主要的 '''服务查询''' 类别是 "client" (例如, 一个机器人) [[XEP-0144#附录G:备注|10]], 该发送应用不应该(SHOULD NOT)指定一个"add"之外的'action'属性, 接收应用可以忽略"add"之外的'action'属性值, 并且接收应用必须提示一个自然人用户是否添加建议的条目或条目们到该用户的名册.
  
−
  1. Users of Jabber clients.用户的Jabber客户端。
+
===网关===
  
−
  2. Client proxy gateways.客户端代理网关。
+
客户端代理网关(即, 服务查询类别为"gateway"的实体)的情况在[http://xmpp.org/extensions/xep-0100.html 网关交互] [[XEP-0144#附录G:备注|11]]中定义的更完整. 这里我们描述这类网关应该如何使用名册条目交换, 以及接收应用将如何看待从这类网关收到的名册条目.
  
−
  3. Shared group services.共享组服务。
+
为了使用一个网关的协议翻译服务, 一个用户必须首先注册到该网关. 如果该网关声明支持一个服务查询特性'http://jabber.org/protocol/rosterx', 那么该用户的客户端应该期望他可能从该网关收到名册条目建议. 为了维护该用户在外部IM服务上的联系人列表和该用户的Jabber名册之间的同步, 该网关应该发送带有适当的值为"add", "delete", 或 "modify" 'action'属性的名册条目, 而且接收应用应该处理这类名册条目建议. 这样的处理可能自动发生(即, 每个名册条目或一批名册条目不需要该用户的批准) ，当且仅当该接收应用显式地通知该用户它将自动处理来自该网关的名册条目的时候. 进一步的, 该接收应用应该让该用户定期检查自动处理(例如, 每此该网关发送名册条目建议给该用户的会话的时候检查一次).
  
 +
===组服务===
  
 +
第三中可以发起名册条目交换的实体类型, 我们称为"group service"并且通过一个"directory"的服务查询类别和"group"的类型来标识它. 组服务允许一个管理员集中地定义和管理名册组，使得它们能以一个组织化的方式在一个用户群体中共享. 这样一个服务在企业环境[[XEP-0144#附录G:备注|12]]很有用，不并且其他设置对于跨越个人(例如, 学校, 社交网络应用, 消费者IM服务, 以及其他用户建立和管理很重要的小社区)的同步名册很有益.
  
−
These are described more completely below.这些都是描述更完整地下面。
+
在一些上下文中, 一个IM服务器可能就是作为组服务使用(例如, 如果在一个小公司的内部网中部署的单一服务器); 在另外一些上下文中, 可能要花更大的经历来部署一个独立的组服务(例如, 在一个更大的或更错杂的环境，用户位于多台服务器上). 两种情况下, 组服务都必须声明一个服务查询标识"directory/group"并且应该在这里指定通讯对相关的共享组的变更("add", "delete", 和 "modify"); 另外, 一个用户必须首先注册到该服务(要么在Jabber上通过[[XEP-0077|带内注册]] [[XEP-0144#附录G:备注|13]] 要么走带外, 例如, 通过web)或另有办法在从该服务接受名册条目建议之前使用该服务(例如, 通过一个系统管理员).
  
−
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 网关
+
一个发送实体能有效地对接收实体进行拒绝服务攻击，通过快速和重复地发送 (1) 交替的 add 和 delete 建议 或 (2) modify 建议, 所以接收实体的服务器被强制调用扼杀机制. 接收应用应该通过监控从每个发送实体接收到的名册条目交换来压制它并且拒绝或忽略来自问题实体的名册条目交换(例如, 把这类实体加到一个不信任实体列表中).
  
 +
===声明支持===
  
 +
一个接收应用可以拒绝向那些 (1) 未显式地信任 或 (2) 显式地不信任 的实体声明它对名册条目交换协议的支持(见本文的[[XEP-0144#服务查询|服务查询]]章节).
  
−
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.我们在此描述了如何这样的网关应使用名册的项目交流，以及如何接受申请要善待名册项目收到了这样的网关。
+
==IANA事项==
  
 +
本文不需要和[http://www.iana.org/ 互联网编号分配授权机构(IANA)] [[XEP-0114#附录G:备注|14]]有任何互动。
  
 +
==XMPP注册处事项==
 +
===协议命名空间===
  
−
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).此外，接收的应用应定期验证的自动处理与用户（例如，每一次会议在该网关发送名册项目的建议，向用户） 。
+
[http://xmpp.org/registrar/ XMPP注册处] [[XEP-0144#附录G:备注|15]] 已经把'http://jabber.org/protocol/rosterx'包含在它的协议命名空间的注册项中.
  
−
7.3 Group Services 7.3 组服务
+
===服务查询标识符===
  
 +
XMPP注册处在它的服务查询标识符的注册项的"directory"类别下包含了一个'''服务查询'''类型"group".
  
 +
==XML Schema==
  
−
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 ]和其他设置的地方，这是有利于同步名册全国个人（例如，学校，社会网络的应用，消费者的即时通讯服务，和其他地方，这是重要的建设和管理小社区用户） 。
+
<source lang="xml">
−
 
+
<?xml version='1.0' encoding='UTF-8'?>
−
 
+
−
 
+
−
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 > 。
+
  
 +
<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>
  
−
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 > 。
+
  <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>
  
−
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 > 。
+
==附录==
  
 +
===附录A:文档信息===
  
 +
系列：[http://xmpp.org/extensions/ XEP]
  
−
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/ > 。
+
序号：0144
  
 +
发布者：[http://xmpp.org/xsf/ XMPP标准基金会]
  
 +
状态：[http://xmpp.org/extensions/xep-0001.html#states-Draft 草案]
  
−
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".默认值'行动'的属性是“新增” ;因此，如果'行动'的属性是未列入或接收的应用不明白'行动'的属性，接收应用程序必须处理的项目，犹如值分别为“添加” 。
+
类型：[http://www.xmpp.org/extensions/xep-0001.html#types-Standards%20Track 标准跟踪]
  
 +
版本：1.0
  
 +
最后更新：2005-08-26
  
−
6 . 6 。 XEP-0030: Service Discovery < http://www.xmpp.org/extensions/xep-0030.html >. xep - 0030 ：服务发现< http://www.xmpp.org/extensions/xep-0030.html > 。
+
批准机构：[http://xmpp.org/council/ XMPP理事会]
  
 +
依赖标准：XMPP Core, XMPP IM
  
 +
替代标准：XEP-0093
  
−
7 . 7 。 XEP-0115: Entity Capabilities < http://www.xmpp.org/extensions/xep-0115.html >. xep - 0115 ：实体的能力， < http://www.xmpp.org/extensions/xep-0115.html > 。
+
被替代标准：无
  
 +
缩略名：rosterx
  
 +
Schema: <http://www.xmpp.org/schemas/rosterx.xsd>
  
−
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).如果接收实体有一个以上的可用的资源，传送的应用，应沟通“最可用的”资源根据其最佳估计（例如，资源与最高优先级） 。
+
原文控制： [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:作者信息===
  
−
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 > 。
+
'''Peter Saint-Andre'''
  
 +
Email: [mailto:stpeter@jabber.org stpeter@jabber.org]
  
 +
JabberID: stpeter@jabber.org
  
−
10 . 10 。 See < http://www.xmpp.org/registrar/disco-categories.html#client >.见< http://www.xmpp.org/registrar/disco-categories.html ＃客户端 > 。
+
URI: https://stpeter.im/
  
 +
{{Template:XEP附录CDEF}}
  
 +
===附录G:备注===
  
−
11 . 11 。 XEP-0100: Gateway Interaction < http://www.xmpp.org/extensions/xep-0100.html >. xep - 0100 ：网关的互动< http://www.xmpp.org/extensions/xep-0100.html > 。
+
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>.
  
−
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在物流得到发射，它是有道理的，他消失从名册其他所有人，在物流服务署。
+
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>.
  
−
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 > 。
+
7. XEP-0115: 实体能力 <http://xmpp.org/extensions/xep-0115.html>.
  
 +
8. 如果接收实体有多个可用资源, 发送的应用应该与"最可用的"资源通讯，根据它的最佳估计(例如, 有最高优先级的资源).
  
 +
9. RFC 6120: 可扩展的消息和出席信息协议 (XMPP): 核心 <http://tools.ietf.org/html/rfc6120>.
  
−
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/ >.
+
10. 见 <http://www.xmpp.org/registrar/disco-categories.html#client>.
  
 +
11. XEP-0100: 网关交互 <http://xmpp.org/extensions/xep-0100.html>.
  
 +
12. 例如, 当Alice被一个大公司的市场部雇用, 意味着她第一次登陆的时候在她的名册中自动有了市场部的其他成员, 并且一旦她的帐号被设置好，市场部的其他人的名册中就有了Alice. 类似的, 当Bob被物流部开除了, 意味着他从物流部每个其他人的名册中消失.
  
−
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/ >.
+
13. XEP-0077: 带内注册 <http://xmpp.org/extensions/xep-0077.html>.
  
−
Revision History
+
14. 互联网号码分配机构(IANA)是为互联网协议分配唯一性的参数值的中间协调者, 类似端口号码和 URI schemes. 更多信息参见 <http://www.iana.org/>.
  
−
Version 1.0 (2005-08-26)
+
15. XMPP注册处维护一个保留的协议命名空间的列表和在XMPP标准基金会批准的XMPP扩展协议的上下文中使用的参数的注册项的列表. 更多信息见 <http://xmpp.org/registrar/>.
  
−
Per a vote of the Jabber Council, advanced status to Draft. (psa)
+
===附录H:修订历史===
  
−
Version 0.6 (2005-07-28)
+
注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用
  
−
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 1.0 (2005-08-26)'''
  
−
Version 0.5 (2005-07-26)
+
::Per a vote of the Jabber Council, advanced status to Draft. (psa)
  
−
Reverted roster item deletion changes. (psa)
+
:'''Version 0.6 (2005-07-28)'''
  
−
Version 0.4 (2005-07-21)
+
::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)
  
−
Simplified processing of roster item deletions. (psa)
+
:'''Version 0.5 (2005-07-26)'''
  
−
Version 0.3 (2004-10-27)
+
::Reverted roster item deletion changes. (psa)
  
−
Clarified the nature of sending entities (users, gateways, and group services); specified "directory/group" service discovery identity for shared group services. (psa)
+
:'''Version 0.4 (2005-07-21)'''
  
−
Version 0.2 (2004-10-04)
+
::Simplified processing of roster item deletions. (psa)
  
−
Further defined the nature of trusted entities. (psa)
+
:'''Version 0.3 (2004-10-27)'''
  
−
Version 0.1 (2004-09-29)
+
::Clarified the nature of sending entities (users, gateways, and group services); specified "directory/group" service discovery identity for shared group services. (psa)
  
−
Initial version. (psa)
+
:'''Version 0.2 (2004-10-04)'''
  
−
Version 0.0.2 (2004-09-22)
+
::Further defined the nature of trusted entities. (psa)
  
−
To address Council feedback, added text about service discovery and choice of stanza type (message or IQ). (psa)
+
:'''Version 0.1 (2004-09-29)'''
  
−
Version 0.0.1 (2004-09-16)
+
::Initial version. (psa)
  
−
Forked XEP-0093 by adding the action attribute, defining requirements and use cases, specifying processing rules, and detailing security considerations. (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)'''
  
−
END
+
::Forked XEP-0093 by adding the action attribute, defining requirements and use cases, specifying processing rules, and detailing security considerations. (psa)
  
−
"
+
--------------------------------------------
 +
结束

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”
个人工具