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: [email protected] _______________________________________________
