Hi all!
With XEP-0469: Bookmark Pinning and XEP-0492: Chat notification settings we now
have two XEPs that allow syncing pinning and notification settings across
clients on the same account using the <extensions/> element of XEP-0402: PEP
Native Bookmarks.
Unfortunately, this now means that normal 1:1 chats (that are synchronized as
roster items) lag behind.
I'm volunteering to write a XEP adding an <extensions/> element alongside the
<group/> element to allow arbitrary extensions for roster items. This would
bring 1:1 roster items on-par with bookmarks2 and immediately allow XEP-0492
and XEP-0469 to be applied to roster items as well.
But before I start I want to ask especially the server developers on this
list: would you consider implementing this?
If the answer is no or "some day far far in the future", it might be worth to
try to invent some other mechanism that could be deployed faster.
In my opinion, however, extending the roster items is by far the most elegant
and simplest solution.
What do you think?
-tmolitor
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!
This message constitutes notice of a Last Call for comments on
XEP-0485.
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/xep-0485.html
This Last Call begins today and shall end at the close of business on
2025-11-03.
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!