XEP-0060 - 版本历史

2013年8月9日 (五) 03:09 Admin

2013-08-09T03:09:36Z

Admin: /* 附录H:修订历史 */

2013-08-09T03:08:56Z

附录H:修订历史

显示差异

Admin: /* 附录G:备注 */

2013-08-09T02:58:04Z

附录G:备注

Admin: /* 作者备注 */

2013-08-08T18:18:32Z

作者备注

显示差异

Admin: /* http://jabber.org/protocol/pubsub#owner */

2013-08-08T18:07:22Z

http://jabber.org/protocol/pubsub#owner

Admin: /* PubSub URIs */

2013-08-08T18:00:44Z

PubSub URIs

显示差异

Admin: /* PubSub URIs */

2013-08-08T17:56:55Z

PubSub URIs

Admin: /* 包含SHIM头 */

2013-08-08T17:48:45Z

包含SHIM头

显示差异

Admin: /* 包含SHIM头 */

2013-08-08T08:26:44Z

包含SHIM头

Admin: /* 自动订阅的所有者和发布者 */

2013-08-08T04:07:30Z

自动订阅的所有者和发布者

@@ 第1行： / 第1行： @@
 '''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0060.html XEP-0060]
@@ 第7,035行： / 第7,032行： @@
 --------------------------------------------
 结束

@@ 第6,732行： / 第6,732行： @@
 . XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.
-. These nodes are equivalent to those used in XEP-0030: Service Discovery.
+. 这些节点等同于那些 XEP-0030: Service Discovery 中使用的节点.
-. This rule does not apply to the root collection node, if any.
+. 这个规则不适用于根集合节点, 如果有的话.
 . XEP-0055: Jabber Search <http://xmpp.org/extensions/xep-0055.html>.
@@ 第6,746行： / 第6,746行： @@
 . XEP-0203: Delayed Delivery <http://xmpp.org/extensions/xep-0203.html>.
-. In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.
+. 根据 '''XML Schema Part 2: Datatypes''' 的3.2.2.1节, xs:boolean datatype 允许的词汇表达是字符 "0" 和 "false" 用于概念 '假' 而字符 "1" 和 "true" 用于概念 '真'; 实现必须同时支持两种词汇表达方式.
 . XEP-0059: Result Set Management <http://xmpp.org/extensions/xep-0059.html>.
-. The inclusion of more than one <item/> element is no longer allowed, given the removal of batch publishing from version 1.13 of this specification.
+. 不再允许包含多个<item/>元素了, 从本协议的版本1.13给出了批量发布的移除功能.
-. It is not necessary for a publication request to include a payload or even an <item/> element in order to trigger an event notification. For example, the result of publishing to a transient, notification-only node will be an event notification that does not include even an <item/> element. However, for the sake of convenience we refer to the act of publication as "publishing an item" (rather than, say, "triggering an event notification") even though a publication request will not always contain an <item/> element.
+. 对一个发布请求来说，要触发一个事件通知，包含一个载荷或甚至一个<item/>元素不是必要的. 例如, 发布到一个临时的，仅通知的节点的结果将是一个甚至不包含一个<item/>元素的事件通知. 无论如何, 为了方便讨论，我们参考发布行为 "发布一个条目" (而不是, 说, "触发一个事件通知") ，尽管一个发布请求不总是包含一个<item/>元素.
 . XEP-0131: Stanza Headers and Internet Metadata <http://xmpp.org/extensions/xep-0131.html>.
-. In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.
+. 根据 '''XML Schema Part 2: Datatypes''' 的3.2.2.1节, xs:boolean datatype 允许的词汇表达是字符 "0" 和 "false" 用于概念 '假' 而字符 "1" 和 "true" 用于概念 '真'; 实现必须同时支持两种词汇表达方式.
 . XEP-0050: Ad-Hoc Commands <http://xmpp.org/extensions/xep-0050.html>.
@@ 第6,766行： / 第6,766行： @@
 . XEP-0108: User Activity <http://xmpp.org/extensions/xep-0108.html>.
-. Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in XEP-0080, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation, where the NodeID is the same as the geolocation namespace 'http://jabber.org/protocol/geoloc' (in this case there is a one-to-one correspondence between the namespace name and the NodeID).
+. 包含的, 假如说, 'http://jabber.org/protocol/geoloc' NodeID 表示该客户端理解'''XEP-0080''' 所述的地理位置命名空间, 而包含 'http://jabber.org/protocol/geoloc+notify' 命名空间表示该客户端理想接收和地理位置相关的通知, 这里的NodeID和地理位置命名空间 'http://jabber.org/protocol/geoloc' 是一样的(这种情况下，在命名空间名称和NodeID之间是一对一对应的).
 . XEP-0086: Error Condition Mappings <http://xmpp.org/extensions/xep-0086.html>.
@@ 第6,778行： / 第6,778行： @@
 . XEP-0082: XMPP Date and Time Profiles <http://xmpp.org/extensions/xep-0082.html>.
-. Another way to implement content-based subscriptions is to host one node per keyword or other filter; however, this is likely to require an extremely large number of nodes.
+. 另一个实现基于内容的订阅的方法是给每个关键或其他过滤器提供一个节点; 无论如何, 这相当于要求非常大量的节点.
 . RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc5122>.
-. 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/>.
+. 互联网号码分配机构(IANA)是为互联网协议分配唯一性的参数值的中间协调者, 类似端口号码和 URI schemes. 更多信息参见 <http://www.iana.org/>.
-. 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://xmpp.org/registrar/>.
+. XMPP注册处维护一个保留的协议命名空间的列表和在XMPP标准基金会批准的XMPP扩展协议的上下文中使用的参数的注册项的列表. 更多信息见 <http://xmpp.org/registrar/>.
-. Prior to version 1.5 of XEP-0060, this type was called "generic".
+. 在XEP-0060的版本1.5之前, 这个类型被称为 "generic".
 . XEP-0147: XMPP URI Query Components <http://xmpp.org/extensions/xep-0147.html>.

←上一版本		2013年8月8日 (四) 18:07的版本
第6,645行：		第6,645行：
	</xs:schema>		</xs:schema>
	</source>		</source>
		+
		+	==致谢==
		+
		+	感谢 Kirk Bateman, Robin Collier, Blaine Cook, Ovidiu Craciun, Brian Cully, Dave Cridland, Guillaume Desmottes, Gaston Dombiak, William Edney, Seth Fitzsimmons, Fabio Forno, Nathan Fritz, Julien Genestoux, Anastasia Gornostaeva, Joe Hildebrand, Curtis King, Tuomas Koski, Petri Liimatta, Tobias Markmann, Pedro Melo, Dirk Meyer, Tory Patnoe, Peter Petrov, Sonny Piers, Christophe Romain, Pavel Šimerda, Andy Skelton, Kevin Smith, Chris Teegarden, Simon Tennant, Matt Tucker, Matthew Wild, Bob Wyman, Matus Zamborsky, and Brett Zamir 的反馈.
		+
		+	==作者备注==
		+
		+	Peter Millard, 本协议从版本0.1到版本1.7的主要作者, 去世于 April 26, 2006. 其他的联合作者对它多年来在发布-订阅技术方面的工作深表感谢.

@@ 第5,958行： / 第5,958行： @@
 '''例子 225. XMPP URI 用于节点'''
-<source lang="html">
+<source lang="html4strict">
 xmpp:pubsub.shakespeare.lit?;node=princely_musings
 </source>
-The following URI identifies a specific item at a node.
+'''例子 226. XMPP URI 用于一个pubsub条目'''
-−
-Example 226. XMPP URI for a pubsub item
 xmpp:pubsub.shakespeare.lit?;node=princely_musings;item=ae890ac52d0df67ed7cfdf51b644e901
-The following URI defines how to subscribe to a node (for details, see the URI Query Types section of this document).
+'''例子 227. URI 用于订阅一个pubsub节点'''
-−
-Example 227. URI for subscribing to a pubsub node
 xmpp:pubsub.shakespeare.lit?pubsub;action=subscribe;node=princely_musings
-The following URI defines how to retrieve a specific item from a node.
+'''例子 228. URI 用于获取一个pubsub条目'''
-−
-Example 228. URI for retrieving a pubsub item
 xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae890ac52d0df67ed7cfdf51b644e901

@@ 第5,587行： / 第5,587行： @@
 ===包含SHIM头===
-When SubIDs are used, Stanza Headers and Internet Metadata (SHIM) headers are to be included in order to differentiate notifications sent regarding a particular subscription. The relevant use cases and scenarios are:
+当使用了SubIDs的时候, '''节头和互联网元数据(SHIM)''' 头被包含在里面以区分被发送的关联到特定订阅的不同通知. 相关用例和场景为:
-    Sending notifications regarding newly-published items as described in the Publish an Item to a Node use case.
+:* 发送关于新发布条目的通知，如[[XEP-0060#发布条目到节点|发布条目到节点]]用例.
-    Sending notifications regarding deleted items as described in the Delete an Item from a Node use case.
+:* 发送关于删除条目的通知，如[[XEP-0060#从节点删除条目|从节点删除条目]]用例.
 The SHIM headers are generated by the node to which the subscriber has a subscription, which may be either a leaf node or a collection node (refer to XEP-0248).

@@ 第5,525行： / 第5,525行： @@
 ===自动订阅的所有者和发布者===
-A service MUST allow owners and publishers to subscribe to a node, and to retrieve items from a node even if they are not subscribed. A service MAY auto-subscribe owners and publishers if they are not already subscribed, in which case it SHOULD generate a subscription ID if necessary for the subscription and SHOULD send a notification of successful subscription as described in the Notification of Subscription State Changes section of this document.
+一个服务必须允许所有者和发布者订阅一个节点, 以及从一个节点获取条目，即使他们没有订阅. 服务可以自动订阅所有者和发布者，如果他们未曾订阅, 在这种情况下如果对订阅是必要的话它应该生成一个订阅ID，并且应该发送一个成功订阅的通知，如本文的[[XEP-0060#订阅状态变更通知|订阅状态变更通知]]所述.
-.12 Authorizing Subscription Requests (Pending Subscribers)
-How subscription requests are sent to node owners is a matter of implementation. Possibilities include:
+===授权订阅请求(未决订阅者)===
-    Send requests to all owners (these may be placed in offline storage as described in XEP-0160) and first approval wins.
+订阅请求如何被发送给节点所有者是一个实现的问题. 可能包括:
-    The service could subscribe to owner presence, and send only to the owners that are online.
-    All owners vote on the new subscriber.
-    Any owner is allowed to veto the subscriber.
-An implementation MAY use any of these methods, or some other method not defined herein.
+:* 发送请求给全部所有者(这些可以被放到离线存储中，如 '''XEP-0160''' 所述)并且第一个批准的人做主.
-.13 Notification of Subscription State Changes
+:* 服务将订阅所有者的出席信息, 且只发送给在线的所有者.
-Various actions and events may result in changes to a subscription state:
+一个实现可以使用这些方法中的任何一个, 或一些这里没定义的方法.
-    Approval or denial of a subscription request as described in the Manage Subscription Requests use case
+===订阅状态变更通知===
-    Cancellation of an existing subscription, for which many "triggers" are possible:
+各种动作和事件可以导致一个订阅状态的变更:
-        The entity simply unsubscribes from the node
-        The node is of type "presence" and the underlying presence subscription is cancelled
-        The node is of type "roster" and the entity is moved to an unauthorized roster group
-When a subscription state change occurs, a service SHOULD send a message to the (new, former, or denied) subscriber informing it of the change, where the message contains an <event/> element with a single <subscription/> child that specifies the node, JID, and subscription state. The notification MAY contain a <body/> element specifying natural-language text regarding the subscription change. The JID to which the service sends the notification is the address that was set in the 'jid' attribute of the subscription request. Examples are shown below.
+:* 批准或拒绝一个订阅请求，如[[XEP-0060#管理订阅请求|管理订阅请求]]用例所述
-Example 216. Subscription approval notification
+:* 撤销一个现有的订阅, 它有很多可能的触发器 "triggers" :
 <message
      from='pubsub.shakespeare.lit'
@@ 第5,559行： / 第5,562行： @@
    </event>
 </message>
-Example 217. Subscription cancellation / denial notification
+<source lang="xml">
-−
 <message
      from='pubsub.shakespeare.lit'
@@ 第5,571行： / 第5,575行： @@
    </event>
 </message>
-If the service has knowledge of the (former or denied) subscriber's presence, it SHOULD send the message to all of the subscriber's resources; if not, it MUST send the message to the subscriber's affiliated JID.
+===NodeID语义===
-If a service or node supports this feature, it MUST return a feature of "subscription-notifications" in its response to service discovery information requests.
+NodeIDs在pubsub的特定的范本,实现,或部署中可以有语义. 无论如何, 强烈建议这类语义不被用于封装节点的层次结构; 反之, 节点层次应该使用集合节点和它们的关联子节点来封装，如 '''XEP-0248''' 所述.
-.14 NodeID Semantics
-NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in XEP-0248.
+===包含SHIM头===
-.15 Inclusion of SHIM Headers
 When SubIDs are used, Stanza Headers and Internet Metadata (SHIM) headers are to be included in order to differentiate notifications sent regarding a particular subscription. The relevant use cases and scenarios are: