[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
cités.

(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,
though.

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