From b8e0a198f9be087f196281802933271a4171ddf5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Wed, 22 Mar 2023 12:49:16 +0100 Subject: [PATCH] XEP-0060: Add pubsub#publish_node_full MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0060.xml | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 2 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index e35b5635..a264731e 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -57,6 +57,7 @@

  • Add data model informational text in Implementation Notes.

    • +

  • Provide a way for a PubSub service to tell a client when a node is full.

  • Fix spec approver

 @@ -2806,7 +2807,6 @@ And by opposing end them?

Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST overwrite the old item with the new item and then proceed as follows.

The pubsub service MUST then send one event notification to each entity that meets the criteria for receiving an event notification (typically to each approved subscriber, although there are other contexts in which an entity may receive an event notification as summarized under Notification Triggers). Each &MESSAGE; stanza generated by a pubsub service SHOULD possess an 'id' attribute with a unique value so that the service can properly track any notification-related errors that may occur (see the Handling Notification-Related Errors section of this document). Depending on the node configuration, the event notification either will or will not contain the payload, as shown below.

Note: In order to facilitate authorization for item removal as described in the Delete an Item from a Node section of this document, implementations that support persistent items SHOULD store the item (if the node is so configured) and maintain a record of the publisher.

-

Note: If the service or node is configured so that there is a maximum number of items cached at the node and the maximum is reached when an item is published, the service MUST delete one of the existing items. It is RECOMMENDED for the service to follow the "first in, first out" rule and delete the oldest item. Depending on node configuration, deletion of an existing item MAY result in sending of a delete notification to the subscribers.

If the node is configured to include payloads, the subscribers will receive payloads with the event notifications.

]]> + +

If the service or node is configured so that there is a maximum number of items cached at the node and the maximum is reached when an item is published, the service MUST delete one of the existing items.

+

The behaviour of the service is reflected through the "pubsub#publish_node_full" option which may take multiple values: "retract-oldest", "discard-oldest", or "reject".

+

The "retract-oldest" option is the default one and SHOULD be implemented even if this configuration isn't supported.

+

It is RECOMMENDED for the service to follow the "first in, first out" rule and retract the oldest item. Depending on node configuration, deletion of an existing item MAY result in sending of a retract notification to the subscribers.

+

When configured as "discard-oldest", a service MUST discard the oldest item.

+

The "reject" option for this configuration is described in Node is full publishing errors.

+

There are several reasons why the publish request might fail:

@@ -3000,6 +3008,7 @@ And by opposing end them?
  • The requesting entity does not have sufficient privileges to publish.
  • The node does not support item publication.
  • The node does not exist.
    • +
  • The node is full (max_items exceeded).
  • The payload size exceeds a service-defined limit.
  • The item contains more than one payload element or the namespace of the root payload element does not match the configured namespace for the node.
  • The request does not match the node configuration.
    • @@ -3046,6 +3055,20 @@ And by opposing end them? ]]> + +

    If the requesting entity attempts to publish an item to a node that has reached its maximum number of items, visible via pubsub#max_items, the service MUST return a &conflict; error, which SHOULD also include a pubsub-specific error condition of <node-full/>, if pubsub#publish_node_full exists and is set to "reject".

    + + + + + + ]]> +

    If the payload size exceeds a service-defined limit, the service MUST return a ¬acceptable; error, which SHOULD also include a pubsub-specific error condition of <payload-too-big/>.

    RECOMMENDED Affiliations + + publish-node-full + Specified behaviour may happen when publishing on a full node. + OPTIONAL + Retracting an item and Rejecting an item. + purge-nodes Purging of nodes is supported. @@ -5424,7 +5453,7 @@ And by opposing end them? &conflict; - The node already exists. + The node already exists, or is full. See pubsub#publish_node_full. &feature; @@ -5463,6 +5492,7 @@ And by opposing end them?

    When implementing this protocol, it is often helpful to consider the data model behind it. Note that this section describes such a conceptual model for informational purposes only and does not define any requirements about how, where or in what format an implementation actually stores data.

    A persistent pubsub node may be viewed as an ordered key-value store, where the ItemIDs are the keys, and the item payloads are the values.

    The order of items is publication order, such that the most recently published is the “newest”. This holds true even if publishing with an ItemID that already exists on the node: the older item is dropped to preserve uniqueness of keys. This is sometimes referred to as “overwriting” in this document.

    +

    The order is of most importance when the max_items option is used to limit the number of items on the node. When the limit is reached, the oldest item may be dropped from the node according to the configured policy (see the publish_node_full option).

    If published ItemIDs are always unique, a persistent node may also be viewed as a kind of “first in, first out” (FIFO) queue.

    @@ -6269,6 +6299,11 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae The publisher affiliation is supported. XEP-0060 + + http://jabber.org/protocol/pubsub#publish-node-full + Specified behaviour may happen when publishing on a full node. + XEP-0060 + http://jabber.org/protocol/pubsub#purge-nodes Purging of nodes is supported. @@ -6627,6 +6662,19 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae open + + + + +