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.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
