14 May
2026
14 May
'26
11:37 a.m.
Hi all,
Apologies for this being long.
Recent conversations have left me with two distinct impressions:
1) Some people within the XSF have a very different idea of what our
process is than I do, that in my view does not match what we have
documented.
2) A significant number of those that do share my understanding of the
process (and presumably all of those that don't) wish it were different.
Frankly, whether I agree with the second group is broadly immaterial - if
the consensus is that our process isn't currently what we want it to be, we
should change it to something that does have consensus. This message is to
try to come up with a set of proposals which can gain consensus, while not
totally rewriting the process.
As I've noted several times before, I hugely dislike process, and
documenting it, but I hate having a documented process that doesn't match
what we do (or want to do) even more. I cannot begin to describe how hugely
frustrating it is to enter the process in good faith only to discover
that's not the process people will enforce. And I'm an old hand, for
newcomers it must be even worse. So it's probably time to wade into
XEP-0001 once again. I do not have any special rights over XEP-0001, I'm
not on the Board or Council, and while I'm an XSF Member that gives no
authority over anyone else in the Standards SIG (ie, this list, basically).
So anything I say or suggest herein should not be considered final or
preferential in any way - you're all welcome (and encouraged) to debate it.
So, with that out of the way, here's what I think the rough consensus of
our red lines should be (noting I'm not using RFC 2119 language here!):
Point A - All specification development should be as open and accessible as
possible, operate within a well-documented process, and unequivocally
within our IPR policy.
Point B - As an organisation, progression along the lifecycle of XEPs
should give clear and unambigious signals as to the maturity of the
document.
Point C - We don't want to dilute Experimental XEPs with "slop", for want
of a better word.
My impression from people is that there is a concern that because
Experimental is very broad in terms of maturity levels it fails on Point B
above.
Experimental was, I believe, designed to be the rough equivalent to
Internet-Drafts in the IETF, which have absolutely no standing, although
the XSF "adopts" them as an IETF Working Group does. Over the years, we've
introduced technical (and social) changes that mean that specifications in
Experimental have become safer to implement and deploy.
Proposed currently is a short-lived state that we often ignore - it's from
Last Call up to Stable. This shouldn't last more than a couple of weeks,
normally. There's no documented quality gate for entering it, though there
is a Council vote - then a Last Call, then another Council vote.
As such the signal prior to Stable is very fuzzy, so to tighten it up there
are a few options.
First, we could "left shift" - and I think this is what's been happening.
By applying the requirements of Stable (and in some cases, Final) to
Experimental, we push things off the beginning of the XSF's process. That,
I feel very strongly, is wrong, since it violates Point A on all counts,
and in any case leaves no benefit or point to Stable or Final.
Second, we could try and refine Experimental. My proposal here - because I
do have a concrete proposal - is to attempt to address Point B by making
Experimental better defined, and expanding Proposed.
Proposal 1 : For Experimental, I propose that XEP-0001 makes it clear that
such documents are "works in progress" - it does this already - but also
that they may contain errors and ommissions, and may prove unimplementable.
This is not, in fact, a change from our current process.
Proposal 2 : For Proposed, I suggest we expand this with the quality gate
that we expect specifications be implementable, have strong interest from
the relevant subsection of the community in implementing, and consensus
that they address a problem. Specifications would then enter this as the
"final straight" to Stable, have *multiple* Last Calls (I know) and then
once the Author is satisfied a Council vote to advance to Stable (or
Rejected, or leave it where it is in Proposed). I suggest also introducing
a timer that after six months, if not advanced to Stable, they drop back to
Experimental. In summary, then, Proposed becomes a strong candidate for
Stable.
I think this addresses Point B without damage to Point A - that is,
Experimental XEPs are more formally "the wild west", and Proposed is
"We're
pretty sure this works and you should try it". I also think it raises the
bar for Stable, which is either a good thing, or a high risk that means we
don't have a use for Final. We might wish to note Stable is intended for
widespread deployment, rather than mere implementation, and that it's
feedback from this widespread deployment that might yet cause changes. I
think these are wording changes to match reality, though.
I anticipate that some specifications - mostly those that Council are
currently accepting - will spend little time in Experimental, and rapidly
move to Proposed. That seems like a good thing. Others will spend a lot of
time in Experimental, developing.
To address Point C, I noticed that in "the old days", we used to require 5%
of membership to trigger Council votes, and while I don't wish to "bind"
Council, this got me thinking down a line of increasing the signals
available to Council. While I'm not worried, personally, about Point C, I
do appreciate that others are, and I also note that "AI slop" in particular
is a growing problem.
Proposal 3 : I propose we introduce a new Call to the SIG (ie, Editor
questionnaire sent to the list), which asks for Expressions Of Interest for
submitted ProtoXEPs. This should give Council guidance on what documents
the community actually wants to work on. XEP-0001 should provide guidance
that Council should reject submissions without sufficient interest, and is
ordinarily expected to follow the consensus of the SIG. (Which SIG is an
interesting question; we normally only have one).
I think in the past, and still now on occasion, we've treated the ProtoXEP
announcements this way anyway. But formalizing this (and formalizing the
idea we're looking for Expressions Of Interest) seems like a good way to
gate slop nobody cares about. Presumably if people do care, it is by
definition not slop?
Proposal 4 : Further, I think it'd be useful to introduce additional
guidance as to what is expected of a ProtoXEP submission. First, a new
mandatory section of the Problem Statement, such that Council and the SIG a
better idea of what the author is hoping to solve, and second, that the
ProtoXEP should give a clear idea as to the general approach.
This is aimed at explicitly allowing XEPs which are not fully formed, while
still providing the kind of information that will let people (SIG and
Council) avoid letting in entirely vague slop.
Note that neither Proposals 3 or 4 place any limit on Council's veto, nor
any recourse/appeal, though it does shift to providing some guidance and
expectation. Ultimately, XSF Members just need to vote in sensible, trusted
people who follow the process.
Related to Proposal 3, there's also:
Proposal 5 : Finally I propose we document the Call questionnaires that the
Editor sends. This do form part of our process, and a significant part at
that. I propose these are documented together in a new XEP, so that they're
a little easier to change. Technically these would be Procedural and thus
Board approved, but we have historically placed the mechanics of how
XEP-0001 is implemented under Council control (see XEP-0143) and I'm
inclined to continue that if Board agrees.
I'm happy to commit to the time/effort to write these up (though Proposal 5
might be better done by the Editor), but I'd like to gauge interest from
the community first, and adjust the proposals as needed to get the best
consensus.
Once again, apologies for the length, and thanks for reading this far. I
owe you a drink, or something.
As a final note, I don't think my MUC ProtoXEP would get published under
these proposals - but I think I'd have a clearer idea on why - and how to
fix it.
Dave.
14 May
14 May
2:15 p.m.
On Thu, 14 May 2026 at 11:37, Dave Cridland <dave(a)cridland.net> wrote:
Hi all,
Apologies for this being long.
Recent conversations have left me with two distinct impressions:
1) Some people within the XSF have a very different idea of what our process is than I
do, that in my view does not match what we have documented.
2) A significant number of those that do share my understanding of the process (and
presumably all of those that don't) wish it were different.
I think the community has been divided over the process for many
years, it just happens that this particular Council leans in a
particular direction, so it has become noticeable.
And I understand both sides, such that it's hard to pick one.
Before going further, I want to note one aspect of this whole thing
which I think is important. A lot of our process, and how it is
perceived, derives from terminology that we use. An example of this
was when we switched from "Draft" to "Stable". I believe that was a
positive change for us to make, even though it didn't update our
process, just a single word. It helps to align everyone, both inside
and outside our core community. We may want to similarly revisit the
label "Experimental" if the definition has (or will be) shifted.
We often reference the IETF in process discussions, but our workflow
varies from theirs in a number of ways. I'm not saying that's
necessarily a bad thing - I don't think we always need to
automatically do what the IETF does, nor close any gaps. But it's
certainly helpful to look to them for inspiration when we have
problems.
Now, to get this out of the way - personally, I am not a fan of
assigning our official numbers to documents which still have lots of
"TODO" and "FIXME" comments. I don't think I've ever submitted
a
protoXEP with "TODO" comments. I don't think that a document
containing only a problem statement and some rough ideas is ready yet
- especially when someone might submit a competing document for the
same problem. Whether it's file transfer, multi-user A/V conferencing,
I think the XSF does the community a disservice by elevating competing
proposals for the same problem - it causes confusion and
fragmentation.
I think my concerns may be linked to what you (Dave) said about the
XSF implicitly adopting a document when it is accepted to
Experimental. The IETF doesn't hand out RFC numbers for I-Ds, so it's
a clear separation between rough proposals and more serious documents,
similarly they have a distinction between documents belonging to an
individual and to a working group. We just have one big pool of
documents, with statuses which don't always reflect reality and often
aren't respected as we would like.
Regardless of my personal opinions about the ideal process, it's clear
that the role of "Experimental" has traditionally been accepting of
rather rough documents. Many authors have submitted (and Councils have
accepted) documents containing TODO sections, even Peter back in the
day (the Hats XEP was submitted with three competing XML
representations of a hat, and it stayed that way for over 10 years).
Things have evolved with time, possibly partly due to the changing
role of Editor, which became more of a passive/reactive role than one
that is actively involved with improving and advancing documents. We
got to a point a few years ago where most of the functionality we used
in modern implementations was in Experimental. I think we all agree
that was a bad place to be in, and I really appreciate the work that
Daniel and the past few councils have done to clean that up. But a
consequence of that era is that it certainly became far more
acceptable to develop and ship software that used XEPs in Experimental
status. Experimental de-facto lost its role as a place where documents
are really in flux, and shifted more towards the "stable" end of the
continuum (hence my comment about potential terminology improvements
above - so that everyone has the same expectations of every stage of
the process).
It's entirely natural that this would result in a stronger defence
against things entering Experimental which are not (yet) ready for
widespread implementations. Whether we want this change or not, I
agree that our documentation almost certainly doesn't reflect this
accurately.
Point A - All specification development should be as
open and accessible as possible, operate within a well-documented process, and
unequivocally within our IPR policy.
Point B - As an organisation, progression along the lifecycle of XEPs should give clear
and unambigious signals as to the maturity of the document.
Point C - We don't want to dilute Experimental XEPs with "slop", for want
of a better word.
I find it funny how often you reference the IPR policy, which I barely
think about. It's necessary, and it's there. All our specifications
are already covered by the IPR policy. Unless you foresee that people
will be widely implementing specifications prior to their submission
(which I wouldn't recommend), I'm not sure how it factors much into
this discussion.
First, we could "left shift" - and I think
this is what's been happening. By applying the requirements of Stable (and in some
cases, Final) to Experimental, we push things off the beginning of the XSF's process.
That, I feel very strongly, is wrong, since it violates Point A on all counts, and in any
case leaves no benefit or point to Stable or Final.
I agree that there has been a shift (as described above). But I don't
think it's so extreme that we're applying the requirements of
Stable/Final to Experimental like you claim. XEPs are routinely
accepted without implementations, but I think you're confusing
"Council requires protoXEPs to have implementations" with "Council
believes this is a good protocol, with a good approach, that could be
implemented" (having an implementation is a good signal which I would
expect Council to use, but it's neither a strict requirement nor
proof). I expect MUC2 received additional scrutiny because it's in a
complex problem area and overlaps with a bunch of existing work over
recent years (and no, I'm not primarily referring to "GC3"). I'm not
on Council and am far from speaking for them, this is just my reading
of the situation based on the discussions I've followed.
Because I disagree with your reading of the situation, this proposal
of formalizing the shift feels like a straw man (even if not intended
that way). The situation is not as bad as it may seem.
I understand that you want a significantly lower bar - somewhere for
work-in-progress documents to get published without being challenged.
People have requested this in the past (I vaguely recall Florian
Schmaus argued for it on the lists quite some years ago). I'm not
against this necessarily, if it's made clear that such documents are
*not* endorsed by the XSF Council. I appreciate that, ironically, this
is already in the preamble text for Experimental XEPs. It's not enough
though - I don't think such documents should be called XEPs, nor
should they be assigned numbers from our XEP series, until they reach
a higher bar set by Council.
To me, such documents are already fine as a wiki page or whatever.
They are not suitable for implementing widely or in software which is
to be released to end users (as I think we agree this is what
"Experimental" has become), and the IPR agreement is therefore of
lesser concern for such documents. If anything, being outside the IPR
could be beneficial to discourage use beyond prototyping, a nice
feature Experimental doesn't afford.
Nevertheless, if we can build out the tooling, I don't see a problem
with formalizing a process for submitting and hosting these drafts on
xmpp.org.
Second, we could try and refine Experimental. My
proposal here - because I do have a concrete proposal - is to attempt to address Point B
by making Experimental better defined, and expanding Proposed.
Overall, if we want to lower the bar, I actually like a lot of your
ideas in this proposal (and some we might want to adopt either way). I
just don't think I want us to lower the bar for XEPs. But I do want to
encourage open and accessible collaboration. I think we can have both.
Regards,
Matthew
9:27 p.m.
On Thu, 14 May 2026 at 14:16, Matthew Wild <mwild1(a)gmail.com> wrote:
That's great if it's a small XEP. And, for that matter, if it's a
single-party XEP, like a client-only one, and the submitter is also a
client maintainer. But I have been told (twice!) that I
Harder for larger cases, and especially where we know even the general idea
is somewhat vaguer terms, like Spaces - but Spaces has both activity and
progress. It's a success case (at least, so far) and if it passed the bar
you've said is applied, then Council were wrong to do so because it's been
changed entirely in Experimental so far.
And, FWIW, I think Spaces is a *good case*.
Now, to get this out of the way - personally, I am not
a fan of
assigning our official numbers to documents which still have lots of
"TODO" and "FIXME" comments. I don't think I've ever
submitted a
protoXEP with "TODO" comments. I don't think that a document
containing only a problem statement and some rough ideas is ready yet
- especially when someone might submit a competing document for the
same problem. Whether it's file transfer, multi-user A/V conferencing,
I think the XSF does the community a disservice by elevating competing
proposals for the same problem - it causes confusion and
fragmentation.
There's a lot packed into one paragraph here.
I'm more of a fan of "TODO" and "FIXME" than I am of
specifications which
have the same problems but don't call them out, for one thing. I find the
"open questions" that some I-Ds have very useful on what to focus on.
I also don't think a problem statement and some rough ideas is enough (or
at the very least, I don't think that's the consensus). I do think a
problem statement and enough specification to understand the approach is
very useful.
I also believe that having multiple blessed solutions for the same problem
is bad, but having multiple approaches documented isn't bad - it's been
successful enough before, because in "Experimental", we can properly dig
into them. We've also rejected cases where the approaches are too similar.
And finally, saying we'll reject anything that addresses the same (or
overlapping) problems causes a lot of issues if we ever want to quite
deliberately replace other solutions. This is a whole thing I'm happy to
defer to Council on, but I hope that by explicitly calling for interest in
working on a spec, Council are better informed.
I think my concerns may be linked to what you (Dave)
said about the
XSF implicitly adopting a document when it is accepted to
Experimental. The IETF doesn't hand out RFC numbers for I-Ds, so it's
a clear separation between rough proposals and more serious documents,
similarly they have a distinction between documents belonging to an
individual and to a working group. We just have one big pool of
documents, with statuses which don't always reflect reality and often
aren't respected as we would like.
Right, also we list Experimental quite happily on /extensions/ - assuming
(for a brief moment) that we accept all my proposals as-is, then we could
default to not showing Experimental. I think that'd be a good change.
I think we need to provide every facility except numbers anyway, so I think
the tooling etc would benefit from just giving them a number too. But that
doesn't mean that we can't change their visibility; we don't have the same
problems with Deferred, for instance. User Browsing (what an idea!) isn't
referenced with the same concern that people place on publishing a new
Experimental.
Regardless of my personal opinions about the ideal
process, it's clear
that the role of "Experimental" has traditionally been accepting of
rather rough documents. Many authors have submitted (and Councils have
accepted) documents containing TODO sections, even Peter back in the
day (the Hats XEP was submitted with three competing XML
representations of a hat, and it stayed that way for over 10 years).
Right. I don't think that's a problem in itself. I think it's a
problem
that it's non-obvious what the difference is between an active, but rough,
specification and a specification that's getting solid implementation and
is broadly "there".
So by lowering the barrier to Experimental (though raising it, still,
compared to how it's documented), and pulling Proposed a little sooner, I
think we can have that distinction. I may be wrong, of course, but it's a
concrete proposal.
Things have evolved with time, possibly partly due to
the changing
role of Editor, which became more of a passive/reactive role than one
that is actively involved with improving and advancing documents. We
got to a point a few years ago where most of the functionality we used
in modern implementations was in Experimental. I think we all agree
that was a bad place to be in, and I really appreciate the work that
Daniel and the past few councils have done to clean that up. But a
consequence of that era is that it certainly became far more
acceptable to develop and ship software that used XEPs in Experimental
status. Experimental de-facto lost its role as a place where documents
are really in flux, and shifted more towards the "stable" end of the
continuum (hence my comment about potential terminology improvements
above - so that everyone has the same expectations of every stage of
the process).
Agreed with all of that.
It's entirely natural that this would result in a
stronger defence
against things entering Experimental which are not (yet) ready for
widespread implementations. Whether we want this change or not, I
agree that our documentation almost certainly doesn't reflect this
accurately.
Right, if you force an unofficial step prior to the process starting, you
have also moved the work outside of the IPR policy.
That's how it factors in.
Point A - All specification development should be
as open and accessible
as possible, operate within a well-documented process, and
unequivocally
within our IPR policy.
Point B - As an organisation, progression along
the lifecycle of XEPs
should give clear and unambigious signals as to the maturity
of the
document.
Point C - We don't want to dilute
Experimental XEPs with "slop", for
want of a better word.
I find it funny how often you reference the IPR policy, which I barely
think about. It's necessary, and it's there. All our specifications
are already covered by the IPR policy. Unless you foresee that people
will be widely implementing specifications prior to their submission
(which I wouldn't recommend), I'm not sure how it factors much into
this discussion.
First, we
could "left shift" - and I think this is what's been
happening. By
applying the requirements of Stable (and in some cases,
Final) to Experimental, we push things off the beginning of the XSF's
process. That, I feel very strongly, is wrong, since it violates Point A on
all counts, and in any case leaves no benefit or point to Stable or Final.
I agree that there has been a shift (as described above). But I don't
think it's so extreme that we're applying the requirements of
Stable/Final to Experimental like you claim. XEPs are routinely
accepted without implementations, but I think you're confusing
"Council requires protoXEPs to have implementations" with "Council
believes this is a good protocol, with a good approach, that could be
implemented" (having an implementation is a good signal which I would
expect Council to use, but it's neither a strict
requirement nor
proof). I expect MUC2 received additional scrutiny because it's in a
complex problem area and overlaps with a bunch of existing work over
recent years (and no, I'm not primarily referring to "GC3"). I'm not
on Council and am far from speaking for them, this is just my reading
of the situation based on the discussions I've followed.
That's possible, but also I have explicitly been told a list of
requirements and they match (or, indeed, quote) Stable.
I think my recent experience is such because in order to achieve the
requirements I've been given, I more or less have to write the entirety of
a MUC replacement outside the process, and also a set of implementations
(client and server), and that feels unwieldy. I don't want to design
something that size on my own, that seems insane. I want to work on it, for
sure, and draw on the other people, and keep the work in progress in a
formal place.
Because I disagree with your reading of the situation,
this proposal
of formalizing the shift feels like a straw man (even if not intended
that way). The situation is not as bad as it may seem.
I think it is, in as much as XEPs appear to be getting much smaller. I
don't know how we would create a XEP-0060 (or, indeed, a XEP-0045) these
days, and I think we should be able to within the process.
I understand that you want a significantly lower bar -
somewhere for
work-in-progress documents to get published without being challenged.
That is not what I want.
It is also not what I have proposed - what I have proposed *raises* the bar
from the documented level, plus extends Proposed so that the current (or
higher gate) can be placed there.
My proposals try to aim for a gate on Experimental that's based on interest
to work on the problem, rather than having to have a complete and full
specification.
People have requested this in the past (I vaguely
recall Florian
Schmaus argued for it on the lists quite some years ago). I'm not
against this necessarily, if it's made clear that such documents are
*not* endorsed by the XSF Council. I appreciate that, ironically, this
is already in the preamble text for Experimental XEPs. It's not enough
though - I don't think such documents should be called XEPs, nor
should they be assigned numbers from our XEP series, until they reach
a higher bar set by Council.
As I say, I'm not precious about numbers. Not calling them XEPs is an
interesting idea, though.
I did raise an eyebrow about endorsement by the "XSF Council" - I think
documents are endorsed, or not, by the XSF.
But anyway, firmly agree that we should make it very clear that
Experimental (in my proposed changes) is a work in progress, and so on. I'd
overall prefer that the URLs remain stable throughout publication, and that
implies they get a number and (at least) a filename including XEP. But
redirects are a thing, and if that's the price I can live with it.
To me, such documents are already fine as a wiki page
or whatever.
They are not suitable for implementing widely or in software which is
to be released to end users (as I think we agree this is what
"Experimental" has become), and the IPR agreement is therefore of
lesser concern for such documents. If anything, being outside the IPR
could be beneficial to discourage use beyond prototyping, a nice
feature Experimental doesn't afford.
Eeesh.
Our IPR policy is mostly (almost entirely) about copyright, which has
effects on whether we can make derived works (including republishing as a
XEP). You can implement a spec which isn't under our IPR policy, and it's
exactly the same - you fully own your implementation, and it's just as weak
with respect to patents because, honestly, our IPR policy only avoid
hand-waving because rainbow unicorns don't have hands.
But we might not be able to republish as a XEP, because the copyright
assignment might never come, either because the author refuses or (more
likely) because the author has drifted away and simply doesn't realise.
Also, there's legal as well as logistic problems with the assignment being
after the XSF is already publishing and managing, because assignments are
more secure in a contract and there'd be a strong argument there was no
consideration.
So no, that idea fills me with concern.
Also, having *a* gate into the system is useful, not least because time and
attention is a valuable resource.
Nevertheless, if we can build out the tooling, I
don't see a problem
with formalizing a process for submitting and hosting these drafts on
xmpp.org.
So your counter-proposal is something along the lines of Experimental
becomes unnumbered Non-XEPs, but otherwise is about the same?
Dave.
Second, we could try and refine Experimental. My
proposal here - because
I do have a concrete proposal - is to attempt to address
Point B by making
Experimental better defined, and expanding Proposed.
Overall, if we want to lower the bar, I actually like a lot of your
ideas in this proposal (and some we might want to adopt either way). I
just don't think I want us to lower the bar for XEPs. But I do want to
encourage open and accessible collaboration. I think we can have both.
15 May
15 May
2:15 a.m.
Having read what Dave and Matthew wrote, I think the best proposal would be to
not assign numbers to Experimental XEPs, but just a short name and publish
them under that short name (we alresdy assign short names to XEPs so that
should be a cheap one).
I'd also rename Experimental to Draft (or better: XMPP-Draft). Experimental
sounds more like "XEP ready, experimenting with implementations" rather than
"this is a draft we are working on".
Essential this would be a bit like I-D at the IETF and given what Matthew
wrote, imho this would be a good thing.
I think Dave's proposal to extend the Proposed state is a good idea, too. That
way this state would be a bit like the WG-adopted state of an I-D. I'd also
assign a XEP number at this state.
That way developers can determine the "ready for implementation / gathering of
implementational experience" state just by checking if the XEP has a number
rather than being an XMPP- Draft with only a short name assigned and listed in
an entirely different list/directory over at xmpp.org.
(Filtering software by XMPP-Drafts on https://xmpp.org/software would still be
beneficial, though.)
Once an XMPP-Draft becomes a XEP with a proper number, the old publish place
of the X-D could just redirect to the new XEP, I don't think this would be
problem.
And also what Dave said: an author writing a pre-XEP and then walking away
before it becomes a "proper XEP" would be a problem if the pre-XEP was just a
wiki page or something else without assigning copyright to the XSF: even if
someone wanted to work on the pre-XEP and advance it to a "proper XEP", that
wouldn't be possible unless the original author assigned copyright to the XSF,
but that may never happen.
Even though this legal aspect might in practice never be a problem (because
taking the pre-XEP and working on it anyways might never be called out in
court by the original author) , it would still be better to avoid it
completely.
I think the X-D proposal (which would include assigning the copyright for the
X-D to the XSF) would solve that legal aspect, too.
-tmolitor
Am Donnerstag, 14. Mai 2026, 22:27:13 CEST schrieb Dave Cridland:
On Thu, 14 May 2026 at 14:16, Matthew Wild
<mwild1(a)gmail.com> wrote:
That's great if it's a small XEP. And, for that matter, if it's a
single-party XEP, like a client-only one, and the submitter is also a
client maintainer. But I have been told (twice!) that I
Harder for larger cases, and especially where we know even the general idea
is somewhat vaguer terms, like Spaces - but Spaces has both activity and
progress. It's a success case (at least, so far) and if it passed the bar
you've said is applied, then Council were wrong to do so because it's been
changed entirely in Experimental so far.
And, FWIW, I think Spaces is a *good case*.
Now, to get this out of the way - personally, I
am not a fan of
assigning our official numbers to documents which still have lots of
"TODO" and "FIXME" comments. I don't think I've ever
submitted a
protoXEP with "TODO" comments. I don't think that a document
containing only a problem statement and some rough ideas is ready yet
- especially when someone might submit a competing document for the
same problem. Whether it's file transfer, multi-user A/V conferencing,
I think the XSF does the community a disservice by elevating competing
proposals for the same problem - it causes confusion and
fragmentation.
There's a lot packed into one paragraph here.
I'm more of a fan of "TODO" and "FIXME" than I am of
specifications which
have the same problems but don't call them out, for one thing. I find the
"open questions" that some I-Ds have very useful on what to focus on.
I also don't think a problem statement and some rough ideas is enough (or
at the very least, I don't think that's the consensus). I do think a
problem statement and enough specification to understand the approach is
very useful.
I also believe that having multiple blessed solutions for the same problem
is bad, but having multiple approaches documented isn't bad - it's been
successful enough before, because in "Experimental", we can properly dig
into them. We've also rejected cases where the approaches are too similar.
And finally, saying we'll reject anything that addresses the same (or
overlapping) problems causes a lot of issues if we ever want to quite
deliberately replace other solutions. This is a whole thing I'm happy to
defer to Council on, but I hope that by explicitly calling for interest in
working on a spec, Council are better informed.
I think my concerns may be linked to what you
(Dave) said about the
XSF implicitly adopting a document when it is accepted to
Experimental. The IETF doesn't hand out RFC numbers for I-Ds, so it's
a clear separation between rough proposals and more serious documents,
similarly they have a distinction between documents belonging to an
individual and to a working group. We just have one big pool of
documents, with statuses which don't always reflect reality and often
aren't respected as we would like.
Right, also we list Experimental quite happily on /extensions/ - assuming
(for a brief moment) that we accept all my proposals as-is, then we could
default to not showing Experimental. I think that'd be a good change.
I think we need to provide every facility except numbers anyway, so I think
the tooling etc would benefit from just giving them a number too. But that
doesn't mean that we can't change their visibility; we don't have the same
problems with Deferred, for instance. User Browsing (what an idea!) isn't
referenced with the same concern that people place on publishing a new
Experimental.
Regardless of my personal opinions about the
ideal process, it's clear
that the role of "Experimental" has traditionally been accepting of
rather rough documents. Many authors have submitted (and Councils have
accepted) documents containing TODO sections, even Peter back in the
day (the Hats XEP was submitted with three competing XML
representations of a hat, and it stayed that way for over 10 years).
Right. I don't think that's a problem in itself. I think it's a problem
that it's non-obvious what the difference is between an active, but rough,
specification and a specification that's getting solid implementation and
is broadly "there".
So by lowering the barrier to Experimental (though raising it, still,
compared to how it's documented), and pulling Proposed a little sooner, I
think we can have that distinction. I may be wrong, of course, but it's a
concrete proposal.
Things have evolved with time, possibly partly
due to the changing
role of Editor, which became more of a passive/reactive role than one
that is actively involved with improving and advancing documents. We
got to a point a few years ago where most of the functionality we used
in modern implementations was in Experimental. I think we all agree
that was a bad place to be in, and I really appreciate the work that
Daniel and the past few councils have done to clean that up. But a
consequence of that era is that it certainly became far more
acceptable to develop and ship software that used XEPs in Experimental
status. Experimental de-facto lost its role as a place where documents
are really in flux, and shifted more towards the "stable" end of the
continuum (hence my comment about potential terminology improvements
above - so that everyone has the same expectations of every stage of
the process).
Agreed with all of that.
It's entirely natural that this would result
in a stronger defence
against things entering Experimental which are not (yet) ready for
widespread implementations. Whether we want this change or not, I
agree that our documentation almost certainly doesn't reflect this
accurately.
Right, if you force an unofficial step prior to the process starting, you
have also moved the work outside of the IPR policy.
That's how it factors in.
Point A - All specification development should be
as open and accessible
as possible, operate within a well-documented process, and unequivocally
within our IPR policy.
Point B - As an organisation, progression along
the lifecycle of XEPs
should give clear and unambigious signals as to the maturity of the
document.
Point C - We don't want to dilute
Experimental XEPs with "slop", for
want of a better word.
I find it funny how often you reference the IPR policy, which I barely
think about. It's necessary, and it's there. All our specifications
are already covered by the IPR policy. Unless you foresee that people
will be widely implementing specifications prior to their submission
(which I wouldn't recommend), I'm not sure how it factors much into
this discussion. First, we
could "left shift" - and I think this is what's been
happening. By applying the requirements of Stable (and in some cases,
Final) to Experimental, we push things off the beginning of the XSF's
process. That, I feel very strongly, is wrong, since it violates Point A
on
all counts, and in any case leaves no benefit or point to Stable or Final.
I agree that there has been a shift (as described above). But I don't
think it's so extreme that we're applying the requirements of
Stable/Final to Experimental like you claim. XEPs are routinely
accepted without implementations, but I think you're confusing
"Council requires protoXEPs to have implementations" with "Council
believes this is a good protocol, with a good approach, that could be
implemented" (having an implementation is a good signal which I would expect Council to use, but it's neither a
strict requirement nor
proof). I expect MUC2 received additional scrutiny because it's in a
complex problem area and overlaps with a bunch of existing work over
recent years (and no, I'm not primarily referring to "GC3"). I'm not
on Council and am far from speaking for them, this is just my reading
of the situation based on the discussions I've followed.
That's possible, but also I have explicitly been told a list of
requirements and they match (or, indeed, quote) Stable.
I think my recent experience is such because in order to achieve the
requirements I've been given, I more or less have to write the entirety of
a MUC replacement outside the process, and also a set of implementations
(client and server), and that feels unwieldy. I don't want to design
something that size on my own, that seems insane. I want to work on it, for
sure, and draw on the other people, and keep the work in progress in a
formal place.
Because I disagree with your reading of the
situation, this proposal
of formalizing the shift feels like a straw man (even if not intended
that way). The situation is not as bad as it may seem.
I think it is, in as much as XEPs appear to be getting much smaller. I
don't know how we would create a XEP-0060 (or, indeed, a XEP-0045) these
days, and I think we should be able to within the process.
I understand that you want a significantly lower
bar - somewhere for
work-in-progress documents to get published without being challenged.
That is not what I want.
It is also not what I have proposed - what I have proposed *raises* the bar
from the documented level, plus extends Proposed so that the current (or
higher gate) can be placed there.
My proposals try to aim for a gate on Experimental that's based on interest
to work on the problem, rather than having to have a complete and full
specification.
People have requested this in the past (I vaguely
recall Florian
Schmaus argued for it on the lists quite some years ago). I'm not
against this necessarily, if it's made clear that such documents are
*not* endorsed by the XSF Council. I appreciate that, ironically, this
is already in the preamble text for Experimental XEPs. It's not enough
though - I don't think such documents should be called XEPs, nor
should they be assigned numbers from our XEP series, until they reach
a higher bar set by Council.
As I say, I'm not precious about numbers. Not calling them XEPs is an
interesting idea, though.
I did raise an eyebrow about endorsement by the "XSF Council" - I think
documents are endorsed, or not, by the XSF.
But anyway, firmly agree that we should make it very clear that
Experimental (in my proposed changes) is a work in progress, and so on. I'd
overall prefer that the URLs remain stable throughout publication, and that
implies they get a number and (at least) a filename including XEP. But
redirects are a thing, and if that's the price I can live with it.
To me, such documents are already fine as a wiki
page or whatever.
They are not suitable for implementing widely or in software which is
to be released to end users (as I think we agree this is what
"Experimental" has become), and the IPR agreement is therefore of
lesser concern for such documents. If anything, being outside the IPR
could be beneficial to discourage use beyond prototyping, a nice
feature Experimental doesn't afford.
Eeesh.
Our IPR policy is mostly (almost entirely) about copyright, which has
effects on whether we can make derived works (including republishing as a
XEP). You can implement a spec which isn't under our IPR policy, and it's
exactly the same - you fully own your implementation, and it's just as weak
with respect to patents because, honestly, our IPR policy only avoid
hand-waving because rainbow unicorns don't have hands.
But we might not be able to republish as a XEP, because the copyright
assignment might never come, either because the author refuses or (more
likely) because the author has drifted away and simply doesn't realise.
Also, there's legal as well as logistic problems with the assignment being
after the XSF is already publishing and managing, because assignments are
more secure in a contract and there'd be a strong argument there was no
consideration.
So no, that idea fills me with concern.
Also, having *a* gate into the system is useful, not least because time and
attention is a valuable resource.
Nevertheless, if we can build out the tooling, I
don't see a problem
with formalizing a process for submitting and hosting these drafts on
xmpp.org.
So your counter-proposal is something along the lines of Experimental
becomes unnumbered Non-XEPs, but otherwise is about the same?
Dave. Second, we could try and refine Experimental. My
proposal here - because
I do have a concrete proposal - is to attempt to address Point B by making
Experimental better defined, and expanding Proposed.
Overall, if we want to lower the bar, I actually like a lot of your
ideas in this proposal (and some we might want to adopt either way). I
just don't think I want us to lower the bar for XEPs. But I do want to
encourage open and accessible collaboration. I think we can have both. 
4:22 a.m.
Having read what Dave and Matthew wrote, I think the
best proposal would be to
not assign numbers to Experimental XEPs, but just a short name and publish
them under that short name (we alresdy assign short names to XEPs so that
should be a cheap one).
I'd also rename Experimental to Draft (or better: XMPP-Draft). Experimental
sounds more like "XEP ready, experimenting with implementations" rather than
"this is a draft we are working on".
I don't mind this, but I do think there can be a use for an Experimental in
between "early draft" and "previously draft now stable".
I would honestly suggest we use a dedicated section of the wiki to lower the
bar on "early draft" further. Other spec authoring groups have had good luck
with this in the past. Rather than getting council or editor involved or
making anyone push any buttons, just write stuff and collaborate (under the
IPR policy, sure) and when it's "ready" then submit for eyes, votes,
process, numbering, namespace versioning, etc. We can of course do this
without using a wiki and still force everything through github, but it's
more friction.
I'll say that, for myself as an implementor, when I want to do something my
first stop is always to find every XEP I can that is remotely related
sounding or looking, read them all, and bake that into my brain to try to
see how what I want to do could be accomplished using existing specs.
Sometimes I miss one, but I don't check the status when I do this. Deferred
is where all the good XEPs are after all, and why would I write a new spec
for something just because the last attempt is languishing?
Now maybe I'm doing it wrong and I should ignore Experimental/Deferred, but
then I would have ended up starting from scratch on several more things.
Maybe that would have been better, but I'm not sure. However you can see how
this contributes to wanting stuff in the XEP pool to be at least indicative
of "this is maybe a good idea" as an implementor vs "this is a document
that
says things".
10:42 a.m.
On Fri, 15 May 2026 at 04:23, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
I would honestly suggest we use a dedicated section of
the wiki to lower
the
bar on "early draft" further. Other spec authoring groups have had good
luck
with this in the past. Rather than getting council or editor involved or
making anyone push any buttons, just write stuff and collaborate (under
the
IPR policy, sure) and when it's "ready" then submit for eyes, votes,
process, numbering, namespace versioning, etc. We can of course do this
without using a wiki and still force everything through github, but it's
more friction.
I'm absolutely fine with a bar to entry, and my gut feeling is that a
formal point in the process where a ProtoXEP/pre-XEP enters the IPR policy
is cleaner. My personal choice of "bar to entry" would be that the XSF
feels the specification is worth working on. Low, but enough to avoid the
slop. I'm highly aware that other bodies (like the IETF) have problems with
AI-generated I-Ds in bulk, currently, and if you've followed the IPv8
stuff, you'll appreciate that anything published anywhere from the XSF, no
matter the name, will convince some people that it's definitely approved
universally by everyone.
I would also like stable URLs, and a wiki makes that hard - but inbox names
could easily enough generate a redirect, or we could stamp in a link to the
XEP.
So, I'm thinking the general idea would be to make inbox be what is now
Experimental, and assign a number at Proposed. Given Matt's concern with
even using the term Experimental given past implied meanings, I suggest we
ditch it and use Inbox.
Adding an additional step is exactly the "left shift" that I think is
problematic, so I wouldn't like to see "Inbox -> Experimental -> Proposed
-> Stable -> Final".
We should be able to get the button pushing to be minimal (perhaps even
non-existent) for inbox updates, but we'll need to list them on the
website, send emails to the SIG for updates, and so on. I think this is all
achievable with CI, I might try to see if I can write that in GHA.
If these sound sensible I'll update the proposals from my first email later
today so we have a concrete set to consider.
Dave.
11:48 a.m.
I feel the proposed use of Proposed is a little weird here. Right now,
Proposed only really means "Last Call issued". I know that we do have 5
XEPs in Proposed state right now (3 of which had their last call more
than a year ago) and those should probably either be moved to Stable or
back to Experimental soonish. I personally would rather get rid of this
state entirely, as it really isn't a state that has any meaning.
In my mind the current Experimental state is somewhat similar to a wg-
adopted I-D in IETF: it's no longer a personal endeavor of an
individual, but rather something we work on together to improve. I
don't support the notion of individual I-D being an Experimental XEP,
because we do give significant exposure to Experimental XEPs. I'm not
saying that everything that is Experimental right now meets this bar
and I would argue that is actually a problem: We do have a bunch of
"dead" XEPs where the author at some point wrote some stuff down
without hugely consulting if that's actually what people - including
themselves - want or need, and so they eventually abandon those XEPs
themselves - typically without officially retracting it. Those XEPs add
to the fact that people always complain about the hundreds of XEPs and
uncertainty what to actually implement.
So in line with your proposal, here's my suggestion:
- Make what is currently Inbox/ProtoXEP a proper own state:
- No requirements, no number assigned, but visible and published on
XSF websites if you know the link. Updates announced to standards list.
- Introduce also some rule for naming so that there is no collision
on names: like the IETF, have each inbox specification (file) name
prefixed with the author name.
- When a XEP is moved from inbox to regular and gets a number
assigned, keep a redirect in the inbox.
- XEPs are proposed to Council not by adding it to the Inbox, but by
explicit email
- Rename Experimental because the name is bad. I would suggest
something like "Adopted", but I leave that to a native speaker. We can
also reuse the term Proposed here, but given at has an entirely
different meaning, that seems odd.
- Maybe add some clarification wording that this means that both
Council and the author considers this XEP to be worth to work on by the
wider community (either by suggesting changes to the XEP or through
experimental implementations)
- Stop using the Proposed state completely OR be more rigid to move
XEPs back to Experimental if they are not moved to Stable.
- Lower the bar for Stable (doesn't strictly need to be fully
implemented if there is consensus that the stuff should work and be
fine)
- Move things to Final when we agree we don't want to do any changes to
it that are not backwards compatible and also the requirements from
XEP-0001 are fulfilled (2 implementations, 6 months without changes).
Does that make sense?
Marvin
Side note: I feel that IPR related concerns could be largely addressed
by a Note Well or other explicit wording that the Standards mailing
list and XSF Wiki are covered by the IPR policy and wouldn't strictly
need changes to the standards process, but I agree that having a
somewhat reasonable equivalent to IETFs individual I-D still makes
sense.
On Fri, 2026-05-15 at 10:42 +0100, Dave Cridland wrote:
On Fri, 15 May 2026 at 04:23, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
I would honestly suggest we use a dedicated
section of the wiki to
lower the
bar on "early draft" further. Other spec authoring groups have had
good luck
with this in the past. Rather than getting council or editor
involved or
making anyone push any buttons, just write stuff and collaborate
(under the
IPR policy, sure) and when it's "ready" then submit for eyes,
votes,
process, numbering, namespace versioning, etc. We can of course do
this
without using a wiki and still force everything through github, but
it's
more friction.
I'm absolutely fine with a bar to entry, and my gut feeling is that a
formal point in the process where a ProtoXEP/pre-XEP enters the IPR
policy is cleaner. My personal choice of "bar to entry" would be that
the XSF feels the specification is worth working on. Low, but enough
to avoid the slop. I'm highly aware that other bodies (like the IETF)
have problems with AI-generated I-Ds in bulk, currently, and if
you've followed the IPv8 stuff, you'll appreciate that anything
published anywhere from the XSF, no matter the name, will convince
some people that it's definitely approved universally by everyone.
I would also like stable URLs, and a wiki makes that hard - but inbox
names could easily enough generate a redirect, or we could stamp in a
link to the XEP.
So, I'm thinking the general idea would be to make inbox be what is
now Experimental, and assign a number at Proposed. Given Matt's
concern with even using the term Experimental given past implied
meanings, I suggest we ditch it and use Inbox.
Adding an additional step is exactly the "left shift" that I think is
problematic, so I wouldn't like to see "Inbox -> Experimental ->
Proposed -> Stable -> Final".
We should be able to get the button pushing to be minimal (perhaps
even non-existent) for inbox updates, but we'll need to list them on
the website, send emails to the SIG for updates, and so on. I think
this is all achievable with CI, I might try to see if I can write
that in GHA.
If these sound sensible I'll update the proposals from my first email
later today so we have a concrete set to consider.
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5:58 p.m.
On Fri, 15 May 2026 at 11:51, Marvin W. via Standards <standards(a)xmpp.org>
wrote:
I feel the proposed use of Proposed is a little weird
here. Right now,
Proposed only really means "Last Call issued". I know that we do have 5
XEPs in Proposed state right now (3 of which had their last call more than
a year ago) and those should probably either be moved to Stable or back to
Experimental soonish. I personally would rather get rid of this state
entirely, as it really isn't a state that has any meaning.
I've not actually changed Proposed as much as you might think. I still have
it entered as the XEP reaches its first Last Call, it can still bounce back
to Experimental or move to Stable.
The differences between my proposal and the current documented state are:
* A timer that flips it back to Experimental automatically, irrespective of
activity.
* A Last Call doesn't immediately lead to a Council vote to advance or
bounce back.
In practice, the latter part often happens anyway - I've known several XEPs
that get multiple Last Calls. It seems fine, especially when the Last Call
generated a reasonable amount of contention and resultant changes.
Codifying that seems like a positive move.
And the timer is to stop the stuck-state cases we see. If a XEP is stuck in
Proposed, it should - I feel - get bounced back to Experimental.
The other changes are in presentation, really. The Council vote on allowing
a Last Call always seemed to me to be a formality, whereas this gives it a
bit more meaning.
In my mind the current Experimental state is somewhat
similar to a
wg-adopted I-D in IETF: it's no longer a personal endeavor of an
individual, but rather something we work on together to improve. I don't
support the notion of individual I-D being an Experimental XEP, because we
do give significant exposure to Experimental XEPs. I'm not saying that
everything that is Experimental right now meets this bar and I would argue
that is actually a problem: We do have a bunch of "dead" XEPs where the
author at some point wrote some stuff down without hugely consulting if
that's actually what people - including themselves - want or need, and so
they eventually abandon those XEPs themselves - typically without
officially retracting it. Those XEPs add to the fact that people always
complain about the hundreds of XEPs and uncertainty what to actually
implement.
Yes, I also suggested not including Experimental in the "default list"
of
XEPs at https://www.xmpp.org/extensions/ - I think that also might get
encourage people to work to advance the stuff they care about.
So in line with your proposal, here's my
suggestion:
- Make what is currently Inbox/ProtoXEP a proper own state:
- No requirements, no number assigned, but visible and published on XSF
websites if you know the link. Updates announced to standards list.
- Introduce also some rule for naming so that there is no collision on
names: like the IETF, have each inbox specification (file) name prefixed
with the author name.
- When a XEP is moved from inbox to regular and gets a number assigned,
keep a redirect in the inbox.
- XEPs are proposed to Council not by adding it to the Inbox, but by
explicit email
I think there seems to be consensus around that - though I'd quite like a
list to be available, just not in the default list. But that may just be me.
- Rename Experimental because the name is bad. I would
suggest something
like "Adopted", but I leave that to a native speaker. We can also reuse the
term Proposed here, but given at has an entirely different meaning, that
seems odd.
- Maybe add some clarification wording that this means that both Council
and the author considers this XEP to be worth to work on by the wider
community (either by suggesting changes to the XEP or through experimental
implementations)
I worry this is a left shift. But also, that is very close what I was
trying to suggest as Experimental... The only difference is s/both Council
and the author considers/Council believes the community considers/ I think.
But I would put that as the Inbox/ProtoXEP gate, anyway. If you're going to
work on a XEP on your own, there's no point involving the XSF at all.
If you're going to work on a XEP with others, it ought to be within the
XSF's process (and IPR, etc).
Prevents the AI (and other) slop.
- Stop using the Proposed state completely OR be more
rigid to move XEPs
back to Experimental if they are not moved to Stable.
- Lower the bar for Stable (doesn't strictly need to be fully implemented
if there is consensus that the stuff should work and be fine)
That's not actually a change to Stable, according to the documentation, is
it?
- Move things to Final when we agree we don't want
to do any changes to it
that are not backwards compatible and also the requirements from XEP-0001
are fulfilled (2 implementations, 6 months without changes).
That's also no change, of course, but I think it's not intended to be.
Does that make sense?
Marvin
Side note: I feel that IPR related concerns could be largely addressed by
a Note Well or other explicit wording that the Standards mailing list and
XSF Wiki are covered by the IPR policy and wouldn't strictly need changes
to the standards process, but I agree that having a somewhat reasonable
equivalent to IETFs individual I-D still makes sense.
I have to admit I'm unclear on where a "click-through" copyright assignment
can work. I think it does work for ProtoXEP submission because there is a
clear quid pro quo (I give you the copyright in this exact doc, the XSF
agrees to publish it and make it available).
This isn't helped by the UK and US laws being quite different, here, to
those of most of Western Europe. (the UK and US *do* allow a click-through
copyright assignment of future work, I think, whereas Germany, Spain,
France and Italy seem not to)
Looking at the other thread, I think we might need something much firmer -
or, alternatively, we need to change our IPR policy to be licence and not
assignment.
Dave.
10:28 a.m.
On Fri, 15 May 2026 at 02:16, Thilo Molitor <thilo(a)eightysoft.de> wrote:
And also what Dave said: an author writing a pre-XEP
and then walking away
before it becomes a "proper XEP" would be a problem if the pre-XEP was
just a
wiki page or something else without assigning copyright to the XSF: even
if
someone wanted to work on the pre-XEP and advance it to a "proper XEP",
that
wouldn't be possible unless the original author assigned copyright to the
XSF,
but that may never happen.
I realised there's a much simpler case where keeping pre-XEPs outside the
IPR policy causes horror. If multiple people collaborate on a pre-XEP, then
they all have a claim on the copyright. It'd be slightly harder to move the
pre-XEP under the IPR policy than to relicense a typical open-source
project - you need to contact every author, etc.
Dave.
12:53 p.m.
Just some thoughts (without responding directly to particular points.)
My impression is that the original underlying issue stems from differences in opinion as
to what the 'Experimental' state should represent - for some, it's simply the
entry point to the XSF process, i.e. I'm working on this and invite community input;
for others, it's more a threshold for experimental implementations, i.e. this is
pretty much ready, though there may be some rough edges. Ultimately, Experimental has
historically covered both of these cases, as it's simply the progression from initial
submission to becoming Stable (previously Draft,) but maybe there is some benefit in
having a clear separation between the two; though, as always, there may be some
disagreement on where precisely to draw the boundary.
Some suggestions in this thread are for repurposing the names of 'Draft' and
'Proposed' - I would avoid this as it's more likely to create confusion, given
their historical meanings (and uses elsewhere.)
The 'Proposed' state is not really being used in practice and is more of a
paper-shuffling exercise than anything.
Given the above points, my thoughts lead to:
1. Separate Experimental into 'WIP' (work in progress) and 'Adopted;' I
think many of the suggestions ultimately amount to this, with minor differences on where
to put the boundary, whether to assign numbers, IPR agreement, etc. (My suggestions: IPR
agreement for WIP; number at Adoption.)
2. Remove Proposed, as it only acts as a temporary "in Last Call" flag, which is
already otherwise signalled.
3. Inbox remains as-is; the number of overall states remains the same.
3
days inactive
4
days old
9 comments
6 participants
participants (6)
-
Dave Cridland -
Marvin W. -
Matthew Wild -
Stephen Paul Weber -
Tedd Sterr -
Thilo Molitor