Hey hey,
Boring incoming:
https://github.com/xsf/xeps/pull/1407
This is draft to avoid the XSF Board accidentally approving it before the
community has had a chance to discuss.
The main change is the paragraph added in Section 6 (Discussion Process),
covering changes to the XEP during Experimental:
The XEP author incorporates the feedback by creating source control patches
> (such as Pull Requests), in line with the preferred method in &xep0143;.
> Direct changes to an Experimental XEP, such as a contributor providing a
> patch (or Pull Request on GitHub), are still the responsibility of the XEP
> author, and are only applied if the XEP author agrees. If a XEP has
> multiple authors, while agreement is sought from all authors, only those
> opinions from responsive authors are considered. If the Approving Body
> feels that the XEP author is not responsive, another author may be added
> unilaterally by the Approving Body.
This is trying to do two things:
1) Document the existing practice that the XMPP Council has followed,
whereby changes to Experimental XEPs need "agreement" (PR approval, or
similar) from the XEP Author.
2) Document the existing practice that the XMPP Council has followed.
whereby if a XEP Author isn't responsive (ie, doesn't respond to emails,
etc) the XMPP Council can add a new XEP Author.
3) Document the *new practice* that if a contribution isn't a PR, it's the
XEP Author who is responsible to turn it into one.
The rest of the changes surface and restate existing process/policy/URLs
and aren't that interesting (well, even less interesting).
There is one additional possible process deviation we should document (or
call the Process Police out, or something). Submission of a XEP, as per
XEP-0143, occurs via email tot he Editor. Is this really still the case? Or
are these now by PR? That'll need changing in XEP-0143, which I'm happy to
do if that's the case. It'd be nice to have a non-PR variant of the process
(post here?)
Dave.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: PubSub Server Information
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.
URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Good day, to one and all.
I am considering to utilize a PubSub service as a public discussion
board; and, as a public discussion board, it should be free for all.
I was wondering whether an approval or other type of moderation
mechanism is specified for PubSub.
Kind regards,
Schimon
Hi all,
This follows a discussion the XSF's Standards Discussion MUC. Logs start at
https://logs.xmpp.org/xsf/2025-05-18 (and continue into the next days).
XEP-0115: Entity Capabilities describes how capabilities from the
"generating entity" can be discovered by a "requesting entity" in section
6.2. To do this, the "requesting entity" sends a disco#info request (that
MUST include a disco 'node' attribute for backwards-compatibility).
The 'node' attribute value is generated in a way that results in an
application-specific value that will be specific to the application that
generated the string as well as the capabilities that are currently
advertised by that application.
What the XEP does not describe, is what is to happen when the requesting
entity uses in their request a 'node' attribute value that is different
from what the generating entity would produce (given its current
configuration). Since providing the value, the generating entity could have
undergone configuration changes making available a different set of
capabilities, thus making the original value outdated.
The XEP is improved by explicitly describing this scenario, by defining
what should happen when a requesting entity uses a conflicting 'node'
attribute value.
I can think of a number of options:
1. If the 'node' attribute value sent by the requesting entity is
recognized by the generating entity as a valid value in some context (eg: a
value that represents an earlier state of offered capabilities), the
generating entity could respond with the corresponding capabilities.
Downsides: the requesting entity may take this as an indication that this
represents the _current_ capabilities of the requesting entity, when that
may not be the case. This approach can't be used if the generating entity
does not recognize the value
2. The request could be answered with an error (eg: item-not-found).
Downside: the requesting entity, that only performs this request because
it's interested in the current capabilities of the generating entity, needs
to do another round trip to get the answers it is looking for.
3. The request could be answered with a response in which the generating
entity uses the new/up-to-date 'node' attribute value (it explicitly does
not echo back the value that was in the request). Downside: there is a
potential backwards compatibility issue for existing implementations that
currently use another approach. They may end up mismatching 'node'
attribute values and associated capabilities.
Given the wording in section 6.2, specifically the definition that the
requesting entity is to include the 'node' attribute for backwards
compatibility, seems to suggest that the responding entity may not have a
need for this value. That, to me, suggests that option 3 is most
appropriate.
I suggest that section 6.2 of XEP-0115 is modified to include an explicit
description of option 3. The backwards-incompatibility issues are arguably
existing only because of unspecified behavior. I do not see how such issues
would be significantly affecting functionality. As the XEP is currently in
state Stable, backwards incompatible changes are allowable.
Thoughts?
Kind regards,
Guus