[Standards] Proposed XMPP Extension: PubSub Namespaces

Maxime Buquet pep at bouah.net
Sat Jan 8 23:02:22 UTC 2022


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.

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.

> 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.

Thanks for the feedback!

[0]: https://github.com/xsf/xeps/pull/986
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220109/fea7dfb5/attachment.sig>


More information about the Standards mailing list