A couple of solutions:
1) No longer require a primary 'Mode' variable to be specified. This would allow users to submit a protocol request without actually specifying any methods to be run, effectively submitting an authenticated blank request envelope and receiving back a response that is blank in case of success (unless secondary methods such as GetChallenge are tacked on).
* pro: simple, lightweight, makes sense wrt existing response encapsulation paradigm
* con: unintuitive in the case that all a user receives in <FBResponse></FBResponse> back.
2) Create a new method (let's say 'ValidateAuth' for instance). This would probably accept a User/Auth argument and return a method response with success/failure.
* pro: clients get back something that makes it very clear whether the auth was correct or not
* con: lots of special cases and confusion about root User/Auth and ValidateAuth.User/ValidateAuth.Auth variables, etc ... started working on this and problems sprouted up left and right, so I stopped.
After thinking a bit and talking to mahlon, my personal opinion is that something along the lines of (1) is the lease confusing and most useful to client authors.
So the questions are: How can I do something similar and make the response more intuitive. Is it really that unintuitive anyway? If you send a request to FotoBilder and don't specify any methods to run, would you expect anything back other than a blank response containing no errors?
I'd like to get some suggestions / thoughts. Especially from people working on new FB Protocol v2 clients. Remember one of the primary goals is to make this understandable to the average would-be client author.