[Standards] Proposed XMPP Extension: PubSub Namespaces

Dave Cridland dave at cridland.net
Sun Jan 9 11:35:43 UTC 2022

On Sat, 8 Jan 2022 at 23:04, Maxime Buquet <pep at bouah.net> wrote:

> On 2022/01/08, Dave Cridland wrote:
> > 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".
> Indeed, this is based off a PR[0] that I made a while back on 277, that
> got somewhat-rejected-but-not-really by one of its authors (stpeter). I
> got asked to go to standards but I thought that would get no interest as
> pubsub stuff usually does and we would redo the same discussion just the
> two of us. So I gave up, until this.
> > 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".
> Yes! I think you captured very well what we wanted to say! We do want
> a way to express semantics.
> “Payload” may not be the word, then we'll change it. “Namespace” annoys
> people, we're also happy to change it. Suggestions welcome for a
> field(?) name, and also another XEP name!
> If that is the meaning that is generally given to (payload) “type” (a
> very generic word), then I understand stpeter's resentment to accept the
> PR.
> > 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
> > pubsub#type.
> Suggestions on how to make the document clearer is also very welcome. As
> you can see edhelas and I are not particularly great at writing,
> especially in english.
Si j'ai écri en francais je ne peut pas etre tres claire aussi! Mais un
"namespace", ca veut dire une place du noms, comme les rues dans un cité -
c'est un protection contre avez plusiers rues avec le meme nom dans autre

(And also, apologies for not being able to type accents properly on this
machine - I should have just given up and used on online translator)

Translation to English: If I wrote in French I couldn't be very clear
either! But a "namespace" means a place of names, like the streets in a
city. It's a protection against multiple streets with the same name in
other cities.

So "type", while as you note very generic and horribly overloaded, is
closer to what you're aiming for I think.

> I do want to say though that some more words on pubsub#type would be
> great. I am definitely not the only one to be confused.
I think pubsub#type is sufficiently underspecified that using it for node
semantics seems fine to me. Usefully, it is *not* specified as being the
type of the payload, just noted as being "usually" the same as the payload
namespace - again, I think that fits your requirements. If I were on
Council, I'd want to understand very clearly why it does not before
accepting the XEP.

However, your specification here contains more functionality than just an
opaque-to-the-service label for the node semantics, so itself may not be
superfluous, but I think the additional field is - and the advantage of
reusing the existing field is that you can roll it out immediately.

Therefore, I would:

* Replace the new field with the existing one.
* Strike section 5.2 (pubsub node, no longer needed)
* Make 5.3 and 5.1 operate on the pubsub#type field.
* Also: Put in a PR against XEP-0060 (sorry Ralph/Peter) to indicate that
the pubsub#type means a label for the node semantics, and while it is often
the same as the payload namespace it can also be any other URN.

> > 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.
> I guess we'll fast-forward to the time the XSF has a working registry.
> I'm not sure that should prevent a spec from getting in.

Well, impossible isn't a reason not to work on fixing it, for sure.

I'd be inclined to downgrade the MUSTs in that section to MAYs and move on,

I like the registry, but I don't actually think we want to block private
extensions with MUSTs here in any case.

> Thanks for the feedback!
> [0]: https://github.com/xsf/xeps/pull/986
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220109/b0b5112a/attachment.html>

More information about the Standards mailing list