This is not a theoretical use case, I am using the below with a transport that I am implementing right now.
Strawman proposal: new XEP that allows XEP-0077 iq results to return a new set of fields and/or data form. Supporting clients see this form in the result and display to the user as per usual. Non-supporting clients report "success" because they ignore the form, and the user can re-initiate registration with the entity to resume mid-flow.
Example flow for transport registration use case with SMS verification: == Entity Requests Registration Fields from Host == <iq type='get' id='reg1' to='sms.shakespeare.lit'> <query xmlns='jabber:iq:register'/> </iq> == Host Returns Registration Fields to Entity == <iq type='result' id='reg1'> <query xmlns='jabber:iq:register'> <instructions> We will send you a code to verify your phone number. </instructions> <phone/> </query> </iq> == Entity Provides Required Information == <iq type='set' id='reg2'> <query xmlns='jabber:iq:register'> <phone>15550000</phone> </query> </iq> == Host Informs Entity of More Fields Needed == <iq type='result' id='reg2'> <query xmlns='jabber:iq:register'> <instructions> Enter the code you received via SMS </instructions> <password/> </query> </iq> == Entity Provies Further Information == <iq type='set' id='reg3'> <query xmlns='jabber:iq:register'> <password>123456</password> </query> </iq> == Host Informs Entity of Successful Registration == <iq type='result' id='reg3'/> -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________