Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a whole
section of a spec, how can we be sure that it's not an existing specs for some
other place, possibly under copyright, that is copied or paraphrased? How can
an author guarantee that it's original work (hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table from
a human written section, to correct the formulation of a sentence, or to draft
an example. This is notably useful for non native English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about LLMs,
I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and there
opinions are highly divided, please express your opinion calmly. The fact is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
This message constitutes notice of a Last Call for comments on
XEP-0424.
Title: Message Retraction
Abstract:
This specification defines a method for indicating that a message
should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on
2025-01-06.
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.1.0 of XEP-0516 (XMPP Decentralized ID (XID)) has been
released.
Abstract:
XMPP Decentralized ID (XID) is a DNS independent XMPP entity
identifier. This specification describes how to generate, use, and
handle them.
Changelog:
Accepted as Experimental by council vote (XEP Editor (dg))
URL: https://xmpp.org/extensions/xep-0516.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.
|Thank you for the feedback. Could you please clarify the main objection
to the Jingle User Location proposal? I would like to understand what
should be changed before revising it. Is the objection about the use of
Jingle, the relation to XEP-0080, privacy/consent, emergency-use
wording, scope, or something else? I do not want to assume the reason.
If you can point to the specific part that is problematic, I can make
the next revision more focused.|
greetings,
Edward Tie .
Version 0.1.0 of XEP-0517 (Jingle Synchronized Real-Time Text) has
been released.
Abstract:
This specification defines a Jingle application extension for
negotiating real-time text as part of the same conversational session
as audio and video.
Changelog:
Accepted as Experimental by council vote (XEP Editor (dg))
URL: https://xmpp.org/extensions/xep-0517.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 Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, June 30
2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
• UPDATED: XEP-0420 (Stanza Content Encryption
• UPDATED: XEP-0514 (Emoji Markup)
• NEW: XEP-0515 (TLS Channel-Binding Downgrade Protection)
4) Items for voting
a) Proposed XMPP Extension: Payment Required
https://xmpp.org/extensions/inbox/payment-required.html
5) Pending votes
none
See the spreadsheet of doom:
https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh…
6) Date of Next
7) AOB
8) Close
Version 0.1.0 of XEP-0515 (TLS Channel-Binding Downgrade Protection)
has been released.
Abstract:
This specification provides a way to secure the SASL and SASL2 SCRAM
handshakes against channel-binding downgrades through TLS version
downgrades.
Changelog:
Accepted as Experimental by council vote (XEP Editor (dg))
URL: https://xmpp.org/extensions/xep-0515.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-0514 (Emoji Markup) has been released.
Abstract:
This specification leverages Message Markup (XEP-0394) and Stateless
file sharing (XEP-0447) (or Stateless Inline Media Sharing (XEP-0385))
to send custom emojis
Changelog:
Remove outdated reference to BoB (techmetx11)
URL: https://xmpp.org/extensions/xep-0514.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.0 of XEP-0420 (Stanza Content Encryption) has been
released.
Abstract:
The Stanza Content Encryption (SCE) protocol is intended as a way to
allow clients to securely exchange arbitrary extension elements using
different end-to-end encryption schemes.
Changelog:
The time affix uses the DateTime profile of XEP-0082
Longer rpads MUST NOT be rejected
Add a minimum size target for random padding to add resistance against
potential correlation attacks in case of short content and 0-length
rpad
Removed unhelpful Implementation Note warning about injection of
decrypted stanzas
Clarify fallback body policy
Fix descriptions to apply to all stanzas instead of just messages
Remove questionable SHOULD in the time affix handling and clarify the
affix'es verification
Request the registrar to provide a list of exclusively server-
processed elements
List XEP dependencies
Add XML schema (syndace)
URL: https://xmpp.org/extensions/xep-0420.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.
Hi all,
At the recent Summit, we had a long and nuanced discussion about the state
of the XMPP RFCs and whether there is value in updating parts of them,
potentially through the IETF, to better reflect how XMPP is actually
implemented and used today.
To be clear upfront: This is not a proposal to start an IETF working group,
nor a commitment to produce new RFCs. The discussion at the Summit surfaced
enough open questions that it seems worthwhile to first have a focused
scoping and feasibility discussion.
Some of the motivations that were raised:
- The current RFCs do not describe a baseline that results in
interoperable modern implementations
- Discoverability for new implementers is difficult (knowing which XEPs
are "essential")
- The IM landscape has changed significantly since the original RFCs
- External review and feedback could be valuable
- There may be marketing and positioning benefits, but these are
secondary
At the same time, many concerns were raised:
- The sheer amount of work required, and whether we realistically have
the manpower
- Risk of scope creep (e.g., baking too much into RFCs)
- Loss of flexibility compared to the XEP process
- Fear of starting something we cannot finish
- Unclear interaction with compliance suites and the "living standard"
nature of XMPP
- Potential pushback or distraction from other IETF efforts (e.g., MIMI)
Questions that seem worth discussing at this stage:
- Is it useful to think about updating some RFCs (e.g., core, IM), while
leaving the rest to XEPs?
- What would be clearly in-scope vs out-of-scope?
- Is there enough interest and capacity to justify exploring this
further?
- What would be a sensible first step that does not overcommit us?
If you were at the Summit and felt strongly one way or the other, it would
be great to hear your perspective here. If you weren't, fresh viewpoints
are equally welcome.
The goal of this thread is simply to assess whether this topic is worth
pursuing further, and if so, in what very limited and realistic form.
Kind regards,
Guus
