[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
quickly.

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
human-driven.

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
standpoint.

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

Dave.
-------------- 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