> 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 :-) cheers, Remko
