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,
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-st
dding, 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-
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
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
Se
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 dr
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 widel
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
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 e
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 sa
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
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
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
13 matches
Mail list logo
