[Standards] Proposed XMPP Extension: PubSub Namespaces

Dave Cridland dave at cridland.net
Sat Jan 8 22:09:44 UTC 2022

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer <jonas at wielicki.name> wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: PubSub Namespaces
> Abstract:
> This extension defines a new PubSub node attribute to specify the type
> of payload.
Oh no it doesn't!

> URL: https://xmpp.org/extensions/inbox/pubsub-ns.html

What this extension appears to be trying to do, based on the (entirely
unreferenced and unmentioned on this list) Github discussion, is to define
the pubsub node *semantics*. That's a different thing to a namespace, and
certainly different from the "type of payload".

The canonical example given was microblogging with Atom, where you don't
just want random Atom payloads - the node might require Atom to work, but
it has additional semantics around it that can be expected. IOW, the need
is to know it's a microblog node, and not just an Atom node. So this isn't
really about payload formats, it's about node semantics, and that's a
radically different thing. And definitely not a "namespace".

The pubsub#type form field we already have (and rarely use) is stipulated
as being the "type of node data, usually specified by the namespace of the
payload (if any)". I think this covers what's needed here, whereas this
specification as written actually doesn't - and isn't any clearer than

This specification is also unimplementable as written, due to the
requirement in 5.1.1 to have realtime access to the registry, but that's
really a non-issue - the specification isn't clear enough to even know what
the intent is. Once we understand the intent, we can then compare it with
pubsub#type, and decide if it'd be better to make better use of that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220108/67cf29c4/attachment.html>

More information about the Standards mailing list