Hi all, TL;DR - This is why I might reject a ProtoXEP. Feel free to talk to me about it.
Since I was discussing it privately, I thought stating my current criteria for accepting ProtoXEPs might be useful. I've made a conscious effort to try and minimize vetoing new XEPs, in order to try and address the concerns of people who understandably felt that we needed to prepend an additional stage. Instead, I'll be trying to apply greater scrutiny to Draft and Final stages, as well as trying to get documents there. This is not intended as a binding list on me or anyone else, and Council members can of course veto for excessive use of the letter "e" should they wish, but I'd personally like to operate both transparently and based on general principles rather than particular cases, so I would welcome feedback on these. My criteria are broadly divided into two: 1) Correct Before Publication While technically a veto, my intent is that these are trivial to work around, and could quite reasonably be applied by the Editor. a) XML Namespaces I believe we need to be careful about publishing specifications that use namespaces outside of the XSF's control, and therefore will generally veto private namespaces or use of ones in the IETF space. This should be trivial to correct by simply changing (or adding) the namespace used, and if we had a mechanism that mandated the Editor changed it prior to publication, I'd use that instead of a veto. b) Other broad syntax violations More difficult to explain, but I can imagine other sufficiently flagrant syntax violations would cause problems. That said, I'm trying to be especially lenient here since these can usually be changed early in Experimental (and therefore within our IPR). Also, it's hard to objectively distinguish between "This stinks", and "This is actively wrong", and I'm trying hard to avoid the former as a reason for veto. In general unless it's a trivial correction I'd rather fix things in Experimental. 2) Process and Scope violations. a) Willingness to change Submitting a ProtoXEP for Experimental is gifting it to the community, both in the moral sense that a XEP is ours, as a community, and in the legal sense of our IPR policy. Once given to us, I firmly believe the community should be able to change that document at the whim of consensus and through our process. So if a ProtoXEP isn't presented in good faith, such that change control is handed to the XSF, I don't think this is the right place for it. That's not to say these things should not be published at all - but your own website might be sufficient. b) Not our remit I used to simply block things well outside our expertise, but I'm reconsidering that stance. Instead, while I believe that we're often better off putting such things through other venues better able to offer the expertise we're trying to capture in the document, sometimes that doesn't work out - and sometimes the expertise comes to us. Equally, I'd encourage the XMPP community to spread out in the standards world and engage with relevant working groups in the IETF, for example. So I'm trying to encourage authors to take the document elsewhere (and I'll try where I can to support that beyond mere encouragement), but I won't veto on the assumption that the author will act in good faith and retract the document if a more suitable venue takes it up. That's not always possible - I doubt we could get a new SASL mechanism right, for example - so this criteria remains in place, though I'll try to be as flexible as I can here. Unlike others, I have little against the XSF publishing documents that have UI/UX recommendations. Not everyone needs to follow them - we're not the protocol police - but UX recommendations can have important effects on security and usability of software. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
