Added optional support for delivery of notifications via XMPP IQ stanzas.
Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.
Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.
+
Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the <default/> element (also added the <default/> element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).
@@ -381,7 +383,7 @@ And by opposing end them?
]]>
-
So that is the "pub" part of publish-subscribe.
+
So that is the "pub" part of pubsub.
Now the pubsub service notifies all the subscribers about the new blog entry:
@@ -455,7 +457,7 @@ And by opposing end them?
Owner
The manager of a node, of which there may be more than one; often but not necessarily the node creator.
Payload
The full data associated with an event rather than just the event notification itself.
Open Access Model
A node access model under which any entity may subscribe and retrieve items without approval.
-
Paylod
The XML data that is contained within the <item/> element of a publication request or a notification event. A given payload is defined by an XML namespace and associated schema. A document that defines a payload format SHOULD specify whether the payload can be used only for a NodeID whose value is the same as the XML namespace, or whether the payload can be used for any NodeID. Such a document also SHOULD specify whether it is suggested that node at which such payloads are published are best configured as Singleton Nodes.
+
Payload
The XML data that is contained within the <item/> element of a publication request or a notification event. A given payload is defined by an XML namespace and associated schema. A document that defines a payload format SHOULD specify whether the payload can be used only for a NodeID whose value is the same as the XML namespace, or whether the payload can be used for any NodeID. Such a document also SHOULD specify whether it is suggested that node at which such payloads are published are best configured as Singleton Nodes.
Personal Eventing
A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see &xep0163;.
Presence Access Model
A node access model under which any entity that is subscribed to the owner's presence with a subscription of type "from" or "both" (see &rfc3921;) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.
Publisher
An entity that is allowed to publish items to a node.
@@ -474,7 +476,7 @@ And by opposing end them?
An entity MUST be able to publish events to a service such that all subscribers to a node receive notification of the event. See Publish an Item to a Node.
An entity MUST be able to subscribe to a node (or be informed that subscription is not allowed). See Subscribe to a Node.
-
An entity MUST be allowed to be affiliated with a node. Allowable affiliations are owner, publisher, none, and outcast. Implementations MUST support affiliations of owner and none, and MAY support affiliations of outcast, publisher, and publish-only. See Affiliations.
+
An entity MUST be allowed to be affiliated with a node. Allowable affiliations are member, none, outcast, owner, publish-only, and publisher. Implementations MUST support affiliations of none and owner, and MAY support affiliations of member, outcast, publisher, and publish-only. See Affiliations.
An entity MUST be allowed to query the pubsub service (or a specific node) to determine what optional features of this specification the service (or node) implements. This query MUST use the Service Discovery (disco#info) protocol. See Discover Node Information.
@@ -884,7 +886,7 @@ And by opposing end them?
]]>
-
+
The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.
Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.
Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.
Much of the meta-data provided about a node maps directly to selected &DUBLINCORE; meta-data attributes; specifically:
-
-
Pubsub Field
Dublin Core Meta-Data Attribute
+
+
Pubsub Field
Dublin Core Metadata Attribute
pubsub#creation_date
Date The value SHOULD be a DateTime as defined in XEP-0082, and MUST conform to one of the profiles defined therein.
pubsub#creator
Creator
pubsub#description
Description
@@ -1078,7 +1080,7 @@ And by opposing end them?
]]>
If the service returns a list of affiliations, it MUST return all affiliations for all JIDs that match the bare JID &BAREJID; portion of the 'from' attribute on the request.
-
For each affiliation, an <affiliation/> element is returned containing the NodeID and the affiliation state (owner, publisher, or outcast).
+
For each affiliation, an <affiliation/> element is returned containing the NodeID and the affiliation state (owner, publisher, publish-only, member, or outcast).
-
An entity may want to request information about the default subscription configuration. Support for this feature is OPTIONAL.
+
An entity might want to request information about the default subscription configuration. Support for this feature is OPTIONAL.
-
To get the default subscription options, the entity MUST send an empty <default/> element to the node (not the service); in response, the node SHOULD return the default subscription options.
+
To get the default subscription options for a node, the entity MUST send an empty <default/> element to the node; in response, the node SHOULD return the default subscription options.
]]>
Note: Here the namespace is 'http://jabber.org/protocol/pubsub' (not 'http://jabber.org/protocol/pubsub#owner' as for retrieval of the default node configuration options).
+
The service itself MAY also have default subscription configuration options. To get the default subscription configuration options all (leaf) nodes at a service, the entity MUST send an empty <default/> element but not specifiy a node; in response, the service SHOULD return the default subscription options.
+
+
+
+
+
+ ]]>
+
The process for retrieving the default subscription configuration options for collection nodes is described in XEP-0248.
If no error occurs, the node MUST return the default subscription configuration options.
@@ -3566,6 +3580,7 @@ And by opposing end them?
to='hamlet@denmark.lit/elsinore'
id='config2'/>
]]>
+
Note: If the node type was changed from leaf to collection and there are items associated with the node, the service MUST purge the node of all items (with or without notification).
If the requested node configuration change cannot be processed (e.g., because the node owner has attempted to change the configuration so that there are no node owners), the service MUST return a ¬acceptable; error to the owner.
@@ -4432,7 +4447,7 @@ And by opposing end them?
]]>
-
If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "publisher", "publish-only", or "outcast" (it MUST NOT return entities whose affiliation is "none").
+
If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "member", "publisher", "publish-only", or "outcast" (it MUST NOT return entities whose affiliation is "none").
Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.
Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.
Configuration of a node using the 'http://jabber.org/protocol/pubsub#node_config' namespace.
-
Setting of meta-data information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.
+
Setting of metadata information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.
The registry submissions associated with these namespaces are defined below.
Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of XEP-0068, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.
@@ -6012,7 +6027,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
http://jabber.org/protocol/pubsub#meta-dataXEP-0060
- Forms enabling setting of meta-data information about pubsub nodes
+ Forms enabling setting of metadata information about pubsub nodes
@@ -6381,6 +6396,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
+
@@ -6440,6 +6456,26 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+