Re: [Standards] Multi-stage registrations

[Peter Waher]

Hello Stephen
 
Correct, it's live updating of the form based on user input. This is what 
you're saying, i.e. user submits one form and then another. 
This is called post-back in XEP-0336. So, when a field that is marked for 
post-back has been edited, the form is sent back, and a new is
returned, exactly what you wanted.
 
If you explicitly want a button to press, then I think the easiest way it to 
define a button field type. As with any field type, the button could
be marked with a post-back flag, signalling the client that if the button is 
pressed, the form is returned. XEP-0336 then describes how the
new form is joined with the old. It can be an entirely new form.
 
Additional benefits of using XEP-0336, apart from post-back, which allows for a 
richer user experience and customized server-side validation of fields, is 
better error information per field, giving better feedback to the user why the 
value of a field is invalid, allowing enabling anddisabling of fields and 
flagging fields to be "unknown" or "undefined", as is the case when editing 
multiple objects at the same time, having different field values.
 
Best regards,
Peter Waher
 
 
> 
> > http://xmpp.org/extensions/xep-0336.html
> >
> > This XEP allows the server to respond to user actions in the form, 
> > including changing the form (adding, updating, removing fields) etc.
> 
> Hmm, this seems to solve a different purpose, that is, live updating of 
> a form based on user input.  In the multi-stage registration case, the user 
> submits one form and then another, it's not really a "dynamic form".
> 
> I'm willing to be convinced otherwise, but the two seem orthogonal.
> 


  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations (Stephen Paul Weber)

[Stephen Paul Weber]

http://xmpp.org/extensions/xep-0336.html

This XEP allows the server to respond to user actions in the form, 
including changing the form (adding, updating, removing fields) etc.


Hmm, this seems to solve a different purpose, that is, live updating of 
a form based on user input.  In the multi-stage registration case, the user 
submits one form and then another, it's not really a "dynamic form".


I'm willing to be convinced otherwise, but the two seem orthogonal.

--
Stephen Paul Weber, @singpolyma
See  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
___

[Standards] Multi-stage registrations (Stephen Paul Weber)

[Peter Waher]

Hello Stephen
 
We've used many multi-stage forms, which registrations is just an example. This 
is why the Dynamic Forms XEP (0336) was created:
http://xmpp.org/extensions/xep-0336.html
 
This XEP allows the server to respond to user actions in the form, including 
changing the form (adding, updating, removing fields) etc.
 
Best regards,
Peter Waher
 
> Date: Wed, 3 Feb 2016 10:32:53 -0500
> From: Stephen Paul Weber 
> To: standards@xmpp.org
> Subject: [Standards] Multi-stage registrations
> Message-ID: <20160203153253.GA3003@singpolyma-liberty>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
> 
> This is in the context of transports, but could apply to account 
> registration as well.  Sometimes one needs multiple steps in a registration 
> process, usually because of an out-of-band verification that needs to happen 
> (think: you give me phone number, I sms you a code, you give me the code.  
> I need your phone number in order to send you the code, but now you've 
> submitted the form already)
> 
> 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 ==
> 
> 
>
> 
> 
> == Host Returns Registration Fields to Entity ==
> 
> 
>
>  
>We will send you a code to verify your phone number.
>  
>  
>
> 
> 
> == Entity Provides Required Information ==
> 
> 
>
>  1555
>
> 
> 
> == Host Informs Entity of More Fields Needed ==
> 
> 
>
>  
>Enter the code you received via SMS
>  
>  
>
> 
> 
> == Entity Provies Further Information ==
> 
> 
>
>  123456
>
> 
> 
> == Host Informs Entity of Successful Registration ==
> 
> 
> 
  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Matthew Wild]

On 3 February 2016 at 18:11, Stephen Paul Weber
 wrote:
>> You're correct, a final standard cannot be changed in this way. A new
>> XEP is the way to go. Looking forward to it :)
>
>
> What's the right procedure, here?  Author XEP based on the HTML I see on
> existing XEP and then submit to mailing list for initial comment?

The procedure is described here (and follow the link to XEP-0143):
https://xmpp.org/about/standards-process.html

Have a read through, and if you have any questions, shout :)

Regards,
Matthew
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Stephen Paul Weber]

You're correct, a final standard cannot be changed in this way. A new
XEP is the way to go. Looking forward to it :)


What's the right procedure, here?  Author XEP based on the HTML I see on 
existing XEP and then submit to mailing list for initial comment?


--
Stephen Paul Weber, @singpolyma
See  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
___

Re: [Standards] Multi-stage registrations

[Matthew Wild]

On 3 February 2016 at 16:23, Stephen Paul Weber
 wrote:
>> Do you think producing a new version of XEP-0077 would be fine?
>
>
> I think a clarification in XEP-0077 would serve very well, but:
>
>> Is that possible by the way since it's a final standard (sorry I'm not
>> much of an expert on XEP drafting)?
>
>
> I'm not sure if a final standard, especially one so widely deployed and old,
> can really be changed easily.  Though, the data forms extension got added at
> some point -- was that before or after it became final?
>
> So this is a question for the rest of the mailing list that knows the
> process more: how should we proceed?

You're correct, a final standard cannot be changed in this way. A new
XEP is the way to go. Looking forward to it :)

Regards,
Matthew
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Stephen Paul Weber]

Do you think producing a new version of XEP-0077 would be fine?


I think a clarification in XEP-0077 would serve very well, but:

Is that possible by the way since it's a final standard (sorry I'm not 
much of an expert on XEP drafting)?


I'm not sure if a final standard, especially one so widely deployed and old, 
can really be changed easily.  Though, the data forms extension got added at 
some point -- was that before or after it became final?


So this is a question for the rest of the mailing list that knows the 
process more: how should we proceed?


--
Stephen Paul Weber, @singpolyma
See  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
___

Re: [Standards] Multi-stage registrations

[Daniele Ricci]

On Wed, Feb 3, 2016 at 5:07 PM, Stephen Paul Weber
 wrote:
> I'm only proposing that multi-stage be supported.  What fields are sent and
> how the server interprets them will of course depend on what sort of
> registration is being done, but that seems out of scope (and likely not
> needed in most cases).
>

Oh ok, sorry I got it now.

Do you think producing a new version of XEP-0077 would be fine? Is
that possible by the way since it's a final standard (sorry I'm not
much of an expert on XEP drafting)?

-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Stephen Paul Weber]

1. data form fields (as in field names and/or multi-stage registration
workflow?)
2. new top level elements (much like username and password <-- there
should be kept for backwards compatibility of course, but adding new
ones... I don't know)


Neither of the above is needed for my use case.  The existing standard 
fields cover me just fine in either case.



I have to say multi-stage registration is very unpredictable (e.g.
registration through SMS, OTP device, public key, and who knows what
else), so it would be hard to write a standard flexible enough IMO.


I'm only proposing that multi-stage be supported.  What fields are sent and 
how the server interprets them will of course depend on what sort of 
registration is being done, but that seems out of scope (and likely not 
needed in most cases).


--
Stephen Paul Weber, @singpolyma
See  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
___

Re: [Standards] Multi-stage registrations

[Daniele Ricci]

It depends on what we want to standardize:

1. data form fields (as in field names and/or multi-stage registration
workflow?)
2. new top level elements (much like username and password <-- there
should be kept for backwards compatibility of course, but adding new
ones... I don't know)

I have to say multi-stage registration is very unpredictable (e.g.
registration through SMS, OTP device, public key, and who knows what
else), so it would be hard to write a standard flexible enough IMO.
What do you suggest?



On Wed, Feb 3, 2016 at 4:53 PM, Stephen Paul Weber
 wrote:
>> https://github.com/kontalk/specs/blob/master/register.md
>
>
> This appears to be identical to my proposal, which gives me hope.  (Data
> forms are certainly supported by XEP-0077 already, and would of course be
> used more likely than the old fields on moders clients.  I think both should
> be supported by servers for compatability, but this is not really relevant
> to the particular issue of multi-stage support.)
>
> So it seems there is more need in the world than just mine, and two
> independently-developed but identical solutions.  Should we write up a
> "real" XEP?
>
>
> --
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph



-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Stephen Paul Weber]

https://github.com/kontalk/specs/blob/master/register.md


This appears to be identical to my proposal, which gives me hope.  (Data 
forms are certainly supported by XEP-0077 already, and would of course be 
used more likely than the old fields on moders clients.  I think both should 
be supported by servers for compatability, but this is not really relevant 
to the particular issue of multi-stage support.)


So it seems there is more need in the world than just mine, and two 
independently-developed but identical solutions.  Should we write up 
a "real" XEP?


--
Stephen Paul Weber, @singpolyma
See  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
___

Re: [Standards] Multi-stage registrations

[Daniele Ricci]

I've been using data forms for this [1] (sorry the spec doesn't
describe instruction forms, but you get the idea), IMHO I think it's
better than using hard-coded fields. I'd deprecate the hard-coded
field altogether.

[1] https://github.com/kontalk/specs/blob/master/register.md

On Wed, Feb 3, 2016 at 4:32 PM, Stephen Paul Weber
 wrote:
> This is in the context of transports, but could apply to account
> registration as well.  Sometimes one needs multiple steps in a registration
> process, usually because of an out-of-band verification that needs to happen
> (think: you give me phone number, I sms you a code, you give me the code.  I
> need your phone number in order to send you the code, but now you've
> submitted the form already)
>
> 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 ==
>
> 
>   
> 
>
> == Host Returns Registration Fields to Entity ==
>
> 
>   
> 
>   We will send you a code to verify your phone number.
> 
> 
>   
> 
>
> == Entity Provides Required Information ==
>
> 
>   
> 1555
>   
> 
>
> == Host Informs Entity of More Fields Needed ==
>
> 
>   
> 
>   Enter the code you received via SMS
> 
> 
>   
> 
>
> == Entity Provies Further Information ==
>
> 
>   
> 123456
>   
> 
>
> == Host Informs Entity of Successful Registration ==
>
> 
>
> --
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>



-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Multi-stage registrations

[Stephen Paul Weber]

This is in the context of transports, but could apply to account 
registration as well.  Sometimes one needs multiple steps in a registration 
process, usually because of an out-of-band verification that needs to happen 
(think: you give me phone number, I sms you a code, you give me the code.  
I need your phone number in order to send you the code, but now you've 
submitted the form already)


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 ==


  


== Host Returns Registration Fields to Entity ==


  

  We will send you a code to verify your phone number.


  


== Entity Provides Required Information ==


  
1555
  


== Host Informs Entity of More Fields Needed ==


  

  Enter the code you received via SMS


  


== Entity Provies Further Information ==


  
123456
  


== Host Informs Entity of Successful Registration ==



--
Stephen Paul Weber, @singpolyma
See  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
___