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 <[email protected]> wrote: > > 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. > > > > > 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. > > 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. > > > > 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 > > 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*. > > > 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. > > > > > 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. > > So your counter-proposal is something along the lines of Experimental > becomes unnumbered Non-XEPs, but otherwise is about the same? > > Dave.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
