Good day.
About
=====
I have recently suggested at project Movim to add navigational
instructions to Atom entries (i.e. posts).
I am still experimenting it, and it currently seems useful.
Technicality
============
The idea is realized in a similar fashion to the classification of
comments node with rel='replies' and title='comments'.
https://xmpp.org/extensions/xep-0277.xml#comments
Navigation
==========
I advise to enable navigational instructions with rel='navigation' and
title='previous' and title='proceed', and perhaps also title='index'.
At the bottom of this page there are proceed or previous links to
navigate and are generated from the instructions proposed above.
https://journal.woodpeckersnest.eu/posts/2024-11-05-xmpp-as-the-internet/
Advantages
==========
Navigational instructions would conveniently facilitate the creation of
a CMS even over a single PEP node, without a compulsory need of having
a PubSub service with multiple nodes to do so, by relating from post to
post from within each posts.
Navigational instructions would also incentivise the creation of
articles that are segmented into parts of a series of posts, and
portability thereof.
Kind regards,
Schimon
Thilo, sorry!
I had somehow missed that SASL2 mandates XEP-0440. It makes a lot of sense.
But...
Openfire currently doesn't support any channel bindings.
It is sometimes used in cases where there is no TLS at all. This is quite
deliberate and sensible in this case, please don't argue with this! This
means there will always be cases where there are no channel bindings
available (because there's no channel to bind to!).
The schema doesn't include a minOccurs, and that means minOccurs='1' by
default. This means at least one channel binding MUST be included. Is this
intentional?
I appreciate this is an oddball case (and I can support tls-server-endpoint
for most normal cases), but is this the intent here or was the expectation
that the minOccurs should be '0'?
(I know tls-server-endpoint MUST be implemented, but MTI is not MTD etc).
Dave.
This message constitutes notice of a Last Call for comments on
XEP-0440.
Title: SASL Channel-Binding Type Capability
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on
2025-10-28.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
Version 0.5.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
released.
Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.
Changelog:
* Add business rules describing client behavior
* Make clear that PLAIN still has to be pinned away, if not disabled
entirely (tm)
URL: https://xmpp.org/extensions/xep-0474.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.5 of XEP-0440 (SASL Channel-Binding Type Capability) has
been released.
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
Changelog:
* Address a possible MITM attack vector by making the tls-server-end-
point channel-binding mandatory to implement
* Remove the whole 'Interaction with SASL mechanisms' section and
replace it with 'Business Rules'
* Rework whole 'Security Considerations' section
* Some minor editorial changes
* Add Thilo Molitor as author (tm)
URL: https://xmpp.org/extensions/xep-0440.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.
This message constitutes notice of a Last Call for comments on
XEP-0440.
Title: SASL Channel-Binding Type Capability
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on
2024-05-20.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Jingle Content Category
Abstract:
This specification defines an XMPP extension to negotiate the use of
Session Description Protocol (SDP) media- level attribute 'content' as
defined by RFC 4796 with Jingle RTP sessions
URL: https://xmpp.org/extensions/inbox/jingle-content-category.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Forums
Abstract:
This specification describes how to implement XMPP-based discussion
forums.
URL: https://xmpp.org/extensions/inbox/forums.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 1.35.2 of XEP-0045 (Multi-User Chat) has been released.
Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to standard chatroom features such as room topics and
invitations, the protocol defines a strong room control model,
including the ability to kick and ban users, to name room moderators
and administrators, to require membership or passwords in order to
join the room, etc.
Changelog:
Fix inconsistency in 'roomconfig_roomsecret' data form field
definition. (gk)
URL: https://xmpp.org/extensions/xep-0045.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.
