Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Maxime Buquet]

On 2022/01/12, Maxime Buquet wrote:
> On 2022/01/09, Dave Cridland wrote:
> > * 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.

https://github.com/xsf/xeps/pull/1148


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Kim Alvefur]

On Tue, Jan 04, 2022 at 05:55:01PM -, Jonas Schäfer 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.

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

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.


My thoughts on this:

- The `pubsub#type` node config setting? (Already mentioned by others)
- I see no reason the server couldn't enforce type checks or schemas on
its own, possibly influenced by `pubsub#type`.
- Advertising that such validation is enforced may or may not be useful,
but could just as well be an error condition (`bad-request` or such).

--
Regards,
Kim "Zash" Alvefur


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Maxime Buquet]

On 2022/01/09, Dave Cridland wrote:
> On Sat, 8 Jan 2022 at 23:04, Maxime Buquet  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
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Jonas Schäfer]

Hi pep., list,

On Sonntag, 9. Januar 2022 00:02:22 CET Maxime Buquet wrote:
> On 2022/01/08, Dave Cridland wrote:
> > 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!

To join the bikeshedding, for the XEP name I'd suggest "PubSub Node Semantics 
Information" or similar. That would be descriptive and clearer than 
Namespaces.

I concur with Dave that this should just reuse the #type field, it seems to 
fit the definition neatly enough.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Dave Cridland]

On Sat, 8 Jan 2022 at 23:04, Maxime Buquet  wrote:

> On 2022/01/08, Dave Cridland wrote:
> > On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  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

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Peter Saint-Andre]

On 1/8/22 4:02 PM, Maxime Buquet wrote:

On 2022/01/08, Dave Cridland wrote:

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  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.


Yes, that's what I was trying to say in the GitHub thread.

Peter
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Maxime Buquet]

On 2022/01/08, Dave Cridland wrote:
> On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  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


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Dave Cridland]

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  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
pubsub#type.

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.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Peter Saint-Andre]

On 1/5/22 5:41 AM, Ralph Meijer wrote:

On 04/01/2022 18.55, Jonas Schäfer (XSF Editor) 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.

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


I am particularly interested in answers this question in section 9:

 > People seem not to want to use |pubsub#type| for this but why?!

Creating a new node config field with the same semantics doesn't seem 
like the right approach. 


+1

/psa
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Ralph Meijer]

On 04/01/2022 18.55, Jonas Schäfer (XSF Editor) 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.

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


I am particularly interested in answers this question in section 9:

> People seem not to want to use |pubsub#type| for this but why?!

Creating a new node config field with the same semantics doesn't seem 
like the right approach. Also, it is referenced in other specifications, 
like RFC 8600 , though I have 
no idea on how widespread its use is.


--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: PubSub Namespaces

[XSF Editor]

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.

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

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___