On 2022/01/09, Dave Cridland wrote: > On Sat, 8 Jan 2022 at 23:04, Maxime Buquet <p...@bouah.net> wrote: > Therefore, I would: > > * Replace the new field with the existing one. > * Strike section 5.2 (pubsub node, no longer needed)
Maybe only just §5.2.2. §5.2.1 could be moved up in §5.1.
> * 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.
Will do.
> > 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.
I was going to say that an extension would “just” need to fill in that
field with whatever value. Because I did want the field set in any case.
But then I remembered Eventual Consistency, and made up my mind. If a
client doesn't fill the field then they won't benefit from the
features. Too bad.
Note that this same line of thought had me wondering if we really wanted
to reuse pubsub#type, because it's already empty in many places.
Anyway. The requirements on the registrar in §5.1.1 were mostly for
backward compatibility. To help servers / client transition
progressively. We're happy to relax the requirements.
With this out of the way, the registrar in itself isn't necessary
anymore, it's just an easy way for devs to lookup existing standard
values (in XEPs).
What we will do though in a later stage, is to go through existing specs
and update them to fill in this foo field (e.g., microblog{,-comments},
omemo-{devicelist,bundles}, bookmarks, user mood).
Agreed it's less crucial on PEP where node name equals our foo field,
but it does open up new features that the spec (and/or futher specs)
could bring.
I guess this requirement of setting the field will apply when a service
decides for some reason to use an allow/block list. I would also still
want to give a way for servers to force setting a value here if they so
choose, (for the same arbitrary reasons they'd choose to allow/block).
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
