>a) no faults element;
>b) faultcode and faultstring should be filled (there are a couple of standard codes for faultcode, notably Client - something wrong with Client request - and Server - something wrong with server processing, such as lack of resources; faultstring should be human-readable) - there is no point in reproducing these elements under the detail element;
>c) you can be more specific with the detail section; for instance, in a debug environment, you could return the execution context (error code, line number, ...);
>d) faultactor is optional and I don't think it applies to this case (unless it happens to be a chain of SOAP messages);
>
>>Also, doing as you say, will this generate an error on the client or this is just a standard way to send a smooth error assuming the client will verify for such content?
>
>The client is responsable for error messages handling. It will generate an error at his side if he does it improperly ;)

The requirements were quite specific so I'll have to verify to know why they want it the other way. Basically, if no error will be generated on the client side when sending such an XML string, that means we can basically sent whatever we want here, as described in the requirements, correct?

So, this approach to send errors is basically to send something that will be easy to interpret from the client side as oppose to use COMRETURNERROR(), correct?