I'd like to propose that we close the Internet of Things Special
Interest Group, which as far as I can see has been inactive. This would
involve moving XEP-0381 to Deprecated or Obsolete (the interim step of
Deprecated in accordance with XEP-0001 seems unnecessary, but I'll leave
that to the Council should it decide to act on this proposal).
Peter
Hi all,
I was skimming XEP-0490, and the optimisation of injecting multiple
displayed elements into a message referencing different ids in different
namespaces made me spit my tea dramatically over my keyboard. Not really,
of course - tea is far too precious to waste on such things, but you get
the idea.
There's clearly no better alternative, because we have clients in the wild
which are quite painful about message ids, and will therefore break things
if we were to rely on their ids being unique.
This got me thinking: What could we do to - if not remove this wart
entirely, at least file it down so it was less of a nuisance. (I'm not sure
if warts do get filed down; I am not a doctor, do not try this at home)
In a perfect world, we might remove XEP-0359 entirely - not because it is,
in and of itself, a bad spec, but because it is essentially patching
problems elsewhere.
So, what can we do to ensure that some tuple of the stanza attributes
perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable
"enough", for both receivers and senders to rely on without having to
inject multiple ids?
Is this worth doing - it feels like it would clean up a lot of other
constructs, but some cases (MAM, perhaps?) might always need to inject
other identifiers. If we were to rely on clients using unique identifers,
could this be subverted in some way beneficial to an attacker?
My gut feeling is that even if we find that we're stuck with XEP-0359 in
all the same cases, we might produce an interesting document about the
security implications of the id attribute of stanzas, which feels like a
gap worth filling.
What do you all think?
Dave.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Extended Subscriptions
Abstract:
This specification extends the XMPP PubSub protocol by introducing
mechanisms for users to subscribe to an entire node hierarchy or to
receive notifications on node metadata updates.
URL: https://xmpp.org/extensions/inbox/pubsub-extended-
subscription.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 0.1.0 of XEP-0495 (Happy Eyeballs) has been released.
Abstract:
When a server's IPv4 path and protocol are working, but the server's
IPv6 path and protocol are not working, a dual-stack application that
initiates a connect experiences significant connection delay compared
to an IPv4-only application. This is undesirable because it causes the
dual-stack initiating entity to have a worse user experience. This XEP
defines how IETF's 'Happy Eyeballs' algorithm requirements that reduce
this user-visible delay are applied to XMPP.
Changelog:
* Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0495.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-0490.
Title: Message Displayed Synchronization
Abstract:
This specification allows multiple clients of the same user to
synchronize the displayed state of their chats.
URL: https://xmpp.org/extensions/xep-0490.html
This Last Call begins today and shall end at the close of business on
2024-10-31.
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!
Hi all,
The XSF infrastructure team is planning to move our mailman installation
from a dedicated machine to a cloud service. In preparation for doing
so, I have just deleted three lists that are no longer in use:
iot(a)xmpp.org
security(a)xmpp.org
server-developers(a)xmpp.org
If IOT or security topics arise, they can be discussed on this list or
in the xsf(a)muc.xmpp.org chatroom.
Peter
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Node Relationships
Abstract:
This specification describes how to establish links between pubsub
nodes, allowing for optional hierarchical organization.
URL: https://xmpp.org/extensions/inbox/pubsub-node-relationships.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Good morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, October 15
2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
* UPDATED: XEP-0198 (Stream Management)
* Proposed XMPP Extension: Pubsub Node Relationships
4) Items for voting
a) Proposed XMPP Extension: Pubsub Node Relationships
https://xmpp.org/extensions/inbox/pubsub-node-relationships.html
b) Issue Last Call on 'XEP-0490: Message Displayed Synchronization'
https://xmpp.org/extensions/xep-0490.html
5) Pending votes
* Travis on Happy Eyeballs
See the spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa…
6) Date of Next
7) AOB
8) Close
Version 1.6.2 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Clarify server enabling stream management without requested resume
functionality. (gk)
URL: https://xmpp.org/extensions/xep-0198.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.
