Hi,
Section 8.5.4 provides a summary of earlier sections. It uses the term
"active resource" twice. This term is not used in any of the earlier
sections.
Conversely, the earlier sections use the term "Connected Resource" a couple
of times. A "Connected Resource" is defined by RFC6121/6120 as "[has] bound
a resource to the stream"
Although the term "Connected Resource" is used in section 8.5, none of the
specifications therein seem to apply to Connected Resources.
The usage of the term "active resource" in section 8.5.4 could be an
artifact of RFC3921/3920, which defines an "active resource" as: "Upon
establishing a session, a connected resource (in the terminology of
[XMPP-CORE]) is said to be an "active resource."
Although section 8.5 advertises that it will define how stanzas related to
connected resources are to be processed ("If there is at least one
available resource or connected resource, how the stanza is processed
depends on the stanza type.") it does not seem to do that. All definitions
seem to depend on having at least one available resource (which is defined
as a connected resource that has sent initial presence), leaving scenarios
in which only connected resources are present, undefined.
Am I misinterpreting this? If not, is this something that should be cleared
up (or explicitly be left undefined)?
As a practical example of a question that I believe is left unanswered: How
should a server process a message stanza of type 'normal', addressed to a
bare JID that represents a local user (the scenario of section 8.5.2.1.1 of
RFC 6121) if the corresponding user only has one or more Connected
Resources (but not any Available Resources)? I believe that there are many
possible variations on this question, I'm limiting it to one to illustrate
the larger issue that I described in this email.
For additional context: this was discussed in the XSF's Discussion MUC
earlier. Logs of that conversation can be found at
https://logs.xmpp.org/xsf/2025-05-28#2025-05-28-a5d887bd6428222c
Kind regards,
Guus
Version 0.1.1 of XEP-0498 (Pubsub File Sharing) has been released.
Abstract:
This specification explains how to share files and optionally include
directory structures similar to filesystems over XMPP Pubsub. It
leverages XMPP Pubsub to enable notifications about file changes and
manage permissions, providing users with real-time updates and control
mechanisms. An optional mechanism is also specified for managing
uploaded files.
Changelog:
Fix wrong shortname and add tags. (jp)
URL: https://xmpp.org/extensions/xep-0498.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.1.1 of XEP-0485 (PubSub Server Information) has been
released.
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.
Changelog:
* Fixed references to XEP identifier. (gdk)
URL: https://xmpp.org/extensions/xep-0485.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 1.0.3 of XEP-0388 (Extensible SASL Profile) has been released.
Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
Changelog:
* Add missing minOccurs='0' to additional-data in <continue/> in XML
schema. (lnj)
URL: https://xmpp.org/extensions/xep-0388.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.9.0 of XEP-0384 (OMEMO Encryption) has been released.
Abstract:
This specification defines a protocol for end-to-end encryption in
one-to-one chats, as well as group chats where each participant may
have multiple clients per account.
Changelog:
Device labels must be signed
Allow empty device list in XML schema
Reworded security consideration that could be interpreted as
forbidding trust mechanisms like BTBV/TOFU
Added section about dealing with lack of presence subscription
Removed reference to omemo-session-healing (th)
URL: https://xmpp.org/extensions/xep-0384.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Good evening.
I am working on a Python script which generates an Atom Syndication
Format XML feed from XMPP DOAP files. I will further add to it an XSLT
stylesheet to transform it to XHTML.
I have attached that script, for those who are inqusitive about it.
Problems
--------
However, I did notice, that some DOAP files are not updated, and some
are missing information.
Proposal
--------
I would suggest to add attributes for types of links (i.e. Gemini,
HTTP, PubSub, etc.), because in near future, resources such as
homepage, bug-database, developer-forum, developer-support, etc. will
be hosted on PubSub services over XMPP, instead of HTTP.
Question
--------
Is there an automated DOAP generator software or service?
Conclusion
----------
If there is no automated service yet, then I would create an XHTML
software with forms that would do so. Afterwards, I would also create
an XMPP service with Data Forms for that purpose.
Please advise.
Kindly,
Schimon
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.
Please create "development" (or "jdev") and "general" (or "talk")
mailing-lists.
I sense that these are required.
DEVELOPMENT
-----------
I have many questions about XMPP development and concerns that are
indirectly related to XMPP.
I urgently need to have a mailing-list for development, as most of my
questions aer not directly related to standard.
GENERAL
-------
A general mailing-list be useful to converse of any other concern,
including welcoming people who have interest in XMPP, of any sort.
Kind regards,
Schimon
Good evening.
I intend to create a ptivate publishing system (i.e. journal) which is
based upon Atom Over XMPP (XEP-0277 and XEP-0472), and which would
interact with Libervia and Movim.
I usually utilize FastAPI, yet I would want to know of other possible
frameworks which you think that might be more preferable for that task.
Reference: https://git.xmpp-it.net/sch/Rivista
Kind regards,
Schimon.