On 21 Feb 2018, at 18:42, Georg Lukas <ge...@op-co.de> wrote: > > * Jonas Wielicki <jo...@wielicki.name> [2018-01-25 15:57]: >>> However, then we need to define how the client can determine whether >>> this Data Form is a PREAUTH compatible form, and whether the user is >>> still required to add more content. >> >> This can easily be done. Just specify the field @var. If the form has a >> field >> with that specified @var, hide it from the UI and insert the preauth token >> automatically on submit. > > This is not overly complex logic, but it requires a full data forms > display in the client,
This is required anyway, though, as there might be additional fields to fill in for registration. > and then manipulation of the form before display, Does it need manipulation before display? We have ‘hidden’ fields. > plus addition of a hidden field when sending the response. Doesn’t need to be added, just populated from when the server included it. > And then we > also have to solve the i18n issue with the field names. But that’s an issue that goes beyond 401, isn’t it? > But we need to extend the IBR flow anyway, so I don't really see a > compelling reason to use data forms here as opposed to an additional XML > element in the 'jabber:iq:register' block. I don’t see a compelling reason *not* to. I don’t think it’s adding any significant complexity on the client, and uses our existing extension mechanisms instead of inventing new ones. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
