On Sep 21, 2011, at 12:10, Remko Tronçon wrote: >> For both account management and registration, using the ad-hoc framework >> seems most sensible - it would allow us maximum flexibility as well as >> near-instant deployment. > > I don't think registration fits the ad-hoc use case, because it is a > special action outside of the general session flow, which means you > can't rely on it being accessed from the generic "Execute ad-hoc > command" functionality of a client. That's why i think such a thing > should probably get a dedicated protocol (on top of data forms). > > That said, I agree with Kurt that the need for in-band registration is > probably not very high, because of typical out-of-band registrations > these days. So I'm also inclined to suggest to develop a XEP for > account management without registration, and possibly base it on > ad-hoc commands. > > Putting account management in ad-hoc commands means that we don't > expect clients to have a "Change password" button, but instead go > through the server provided "Change account settings" dialog. It takes > away power from the client (it won't be able to add fancy things like > password strength measurers), but it gives more power to the server to > provide a UI (e.g. instructions) that fit it, and it saves client > development time :-)
If it's a well-defined FORM_TYPE, a client could do something fancy for the
well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass gets a
special strength meter nearby), and an "advanced" button/tab/overlay/etc for
the non-standard things.
It might not be trivial, but it is possible (-:
- m&m
<http://goo.gl/voEzk>
smime.p7s
Description: S/MIME cryptographic signature
