On 5 February 2016 at 16:14, XMPP Extensions Editor <[email protected]> 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.
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
