PubSub Namespaces

%ents; ]>

PubSub Namespaces This extension defines a new PubSub node attribute to specify the type of payload. &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards Council XEP-0004 XEP-0030 XEP-0060 pubsub-ns Timothée Jaussoin edhelas@movim.eu edhelas@movim.eu Maxime Buquet pep@bouah.net pep@bouah.net 0.0.1 2021-12-25 mb

First draft.

The introduction of PubSub brought a lot of new extensions that are now extensively used across the whole XMPP network. However PubSub never specified a way to clearly identify which extension is actually used on a specific node.

This extension defines a new namespace attribute on a node helping clients and servers implementations to know exactly what kind of data is in a node and how it should be used, i.e., server doing validation, or clients adapting their UI/UX to the type of data.

Having access to this data also enables a new range of features to base on top of this extension, such as filtering, restrictions, etc.

PubSub Namespace introduces a new PubSub Node metadata (as defined in Discover Entity Metadata) called urn:xmpp:pubsub-ns:0#namespace.

Identity which PubSub based extension is used in a node.
Restrict the usage of extensions on a PubSub service.
Allow filtering of nodes by namespaces on PubSub services.

PubSub namespace: Identifier used to specify a set of rules and schemas that applies to a specify PubSub node
PubSub service: An entity serving PubSub nodes (e.g., a component, an account with PEP).

If a server supports the "Pubsub Namespaces" protocol, it MUST advertise the "urn:xmpp:pubsub-ns:0" feature (see Protocol Namespaces regarding issuance of one or more permanent namespaces) in response to a Service Discovery (XEP-0030) information request.

]]> … … ]]>

When a Pubsub service enables Pubsub namespaces all the node creation and configuration on this service MUST have a configured urn:xmpp:pubsub-ns:0#namespace with the namespace declared in the corresponding specification.

Existing clients and libraries that are not implementing PubSub Namespaces will not provide the urn:xmpp:pubsub-ns:0#namespace attribute when creating or configuring a PubSub node.

Therefore, if the server supports Pubsub Namespaces and if the client is creating a node where the nodeid is contained in the list of nodes available in the Pubsub Namespaces Registrar, the server MUST then set the corresponding namespace referring to the nodeid.

If a node is created or configured with an empty namespace and the server doesn't find any correspondence in the Registrar, it MUST then return an error of type modify containing a bad-request element in the urn:ietf:params:xml:ns:xmpp-stanzas namespace, alongside a namespace-required element of namespace urn:xmpp:pubsub-ns:errors:0.

]]>

Services MUST expose the list of currently used namespaces in the result of a disco#info in a jabber:x:data form with a FORM_TYPE of value urn:xmpp:pubsub-ns:0 and a used-namespaces text-multi type field containing the various namespaces.

... urn:xmpp:pubsub-ns:0 urn:xmpp:microblog:0 urn:xmpp:bookmark:0 urn:xmpp:bookmark:1 ... ]]>

The server can define, per service, a list of namespaces to allow or block. The service will then expose the urn:xmpp:pubsub-ns:restrict:0 feature in its disco#info, and return a jabber:x:data form with a FORM_TYPE of value urn:xmpp:pubsub-ns:0 and an allowed-namespaces or blocked-namespaces text-multi type field containing the various namespaces.

If a list of allowed namespaces is defined, only those namespaces are authorized by the server to be used when a node is created on it.
If a list of blocked namespaces is defined, all the namespaces are authorized except those in the list.
If both allowed and blocked lists are defined, only the allowed list is considered.

The resulting list of blocked or allowed namespaces is available by doing a disco#info on the service.

... urn:xmpp:pubsub-ns:0 urn:xmpp:microblog:0 urn:xmpp:bookmark:0 urn:xmpp:bookmark:1 ... ]]>

This will be returned alongside used namespaces results, in the same jabber:x:data form.

... urn:xmpp:pubsub-ns:0 urn:xmpp:stickers:0 urn:xmpp:bookmark:1 http://jabber.org/protocol/geoloc ... ]]>

TODO: iq/set interface to service for clients (perms implementation-defined) to set allowed / blocked namespaces? Which would justify the additional disco feature.

When a client sets the namespace of a node, during its creation (Create and Configure a Node), configuration (Configure a Node) or when publishing an item with a publish-options, the server MUST check the filled namespace against the blocked/allowed list defined on the service (See Restrict the list of allowed namespaces on a service).

http://jabber.org/protocol/pubsub#node_config urn:example:foo:0 ]]>

If the set namespace is forbidden by the service, it MUST return an error of type modify containing a bad-request element in the urn:ietf:params:xml:ns:xmpp-stanzas namespace, alongside a restricted-value element of namespace urn:xmpp:pubsub-ns:errors:0.

]]>

The node namespace is exposed as urn:xmpp:pubsub-ns:0#namespace in the node metadata (see Discover Node Metadata).

http://jabber.org/protocol/pubsub#meta-data urn:xmpp:microblog:0 ... ]]>

While requesting disco#items on a PubSub service, a client might want to only get nodes that are contained in certain namespaces. The client will then add a filter child of namespace urn:xmpp:pubsub-ns:0 to the query element, containing a jabber:x:data form with FORM_TYPE of value urn:xmpp:pubsub-ns:0 and an allowed-namespaces or blocked-namespaces text-multi type field containing the various namespaces it wants to filter.

In the same way as Restrict the list of allowed namespaces on a service, the blocked-namespaces value is ignored if both allowed and blocked fields are specified.

urn:xmpp:pubsub-ns:0 urn:xmpp:microblog:0 urn:xmpp:bookmark:0 urn:xmpp:bookmark:1 ]]>

The server will then return a list of nodes contained in the specified allowed-namespaces field, or a list of nodes excluding nodes contained in blocked-namespaces.

Filtering can be combined with XEP-0059 by adding the <set/> element alongside in the query, as a sibling.

urn:xmpp:pubsub-ns:0 urn:xmpp:microblog:0 urn:xmpp:bookmark:0 urn:xmpp:bookmark:1 20 ]]>

TODO

None.

The XMPP Registrar maintains a registry of values for PubSub Namespaces as defined in this XEP. See <https://xmpp.org/registrar/pubsub-namespaces.html>.

In order to submit new values to this registry, the registrant shall define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@xmpp.org>:


  the name of the namespace (all lower-case)
  a natural-language description of the namespace
  the document (e.g., XEP) in which this namespace is specified
    the PubSub node name attached to this namespace (optional)
]]>

The registrant may register more than one namespace at a time, each contained in a separate <namespace/> element.

People seem not to want to use pubsub#type for this but why?!



  
    
      The protocol documented by this schema is defined in
      XEP-XXXX: http://xmpp.org/extensions/xep-xxxx.html
    
  

  
    
      
        
      
    
  
]]>



  
    
      The protocol documented by this schema is defined in
      XEP-XXXX: http://xmpp.org/extensions/xep-xxxx.html
    
  

  
  

  
    
      
    
  
]]>