[Standards] FYI: Personal Current ProtoXEP Criteria

Dave Cridland dave at cridland.net
Thu May 21 13:54:54 UTC 2020


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200521/10c2891b/attachment.html>


More information about the Standards mailing list