[Standards] Proposed XMPP Extension: Multi-stage IBR

Dave Cridland dave at cridland.net
Fri Feb 5 19:38:40 UTC 2016

On 5 February 2016 at 16:14, XMPP Extensions Editor <editor at xmpp.org> wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Multi-stage IBR
> Abstract: This specification defines an augmentation of In-Band
> Registration to allow for multiple stages of user input.
> URL: http://xmpp.org/extensions/inbox/multistage-ibr.html
> The XMPP Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
First, the good news:

This is important and necessary work, and it's great to see someone come to
the XSF with a solid idea and bring it through to a proposal for a XEP so

Now the critique...

Firstly, this is altering a Final XEP via the backdoor, by reusing the same
XML namespace for an altered protocol. This is trivial to fix - just use a
different namespace - but in its current form I'll have to veto it.

Secondly, I expect there to be resistance to using a hardcoded set of
elements rather than a form. I dislike using forms everywhere - I think
they're best used only when human interaction is expected, rather than as a
solution to every case of extensibility, but I think this is a case where
we are not only expecting, but ideally requiring, the process to be

Thirdly, my gut feeling is that once you swap the hardcoded element set
with forms, it'll look remarkably like XEP-0050. XEP-0050 works for *most*
cases where we use the old XEP-0077 protocol - registration for chatrooms
and gateways - but it won't work for account registration. This is because
you'd have to process ad-hoc commands in the pre-auth state, and any IQ
processing is already a scary proposition at that point from a security

Of course, maybe we don't need account registration anymore, or maybe we
can figure out a better pattern.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160205/df17ff8e/attachment.html>

More information about the Standards mailing list