Follows are some notes on revamping the "options" for WSRequest in order to bring it more in line with the message framing algorithms in WSDL 2.0.

New Properties

A new error property allows the WSRequest object to signal whether the response was obtained, whether the response was a fault or a normal response, and abstracts out the differences between fault information conveyed in SOAP 1.1 and SOAP 1.2.

For a normal response, the error property is empty.  For a fault, the error property is a WSError object with the following properties:

WSError	code	A string (often a QName) representing the error code.
	reason	A brief textual description of the error.
	details	A full description (usually XML) of the error.

For SOAP 1.2 the properties are mapped to a SOAP fault as follows:

error.code	S:Fault/s:Code/S:Value[0] (string)
error.reason	S:Fault/s:Reason/s:Text (string)
error.detail	S:Fault/s:Detail (XML serialized as a string)

For SOAP 1.1 the properties are mapped to a SOAP fault as follows:

error.code	S:Fault/faultcode (string)
error.reason	S:Fault/faultstring (string)
error.detail	S:Fault/detail (XML serialized as a string)

For either SOAP version, if the response doesn't contain a SOAP Envelope, the error property is set as follows:

error.code	"HTTPxxx" where xxx is the HTTP status code
error.reason	"No SOAP Body."
error.detail	HTTP status text

New Options

Allowing a message exchange (represented by WSRequest) to be configured with these options, makes configuring an exchange from the description easier.  It also demystifies the framing algorithms while providing more power - as the WSDL 2.0 standard becomes our documentation and specification mechanism for the details of framing.

Options	useSOAP (deprecated)	"1.2", 1.2, "1.1", 1.1, true, false Supported for backward compatibility only - use useBinding instead.
	useBinding	"SOAP 1.2" | "SOAP 1.1" | "HTTP" Specifies whether to frame messages as described in the WSDL 2.0 SOAP (http://www.w3.org/ns/wsdl/soap) or HTTP (http://www.w3.org/ns/wsdl/http) bindings.  The spec for each of those bindings describes precisely how the message is to be framed. For the values "SOAP 1.1" and "SOAP 1.2" the WSDL 2.0 {soap version} property takes the corresponding value "1.1" or "1.2".  When "1.1", the WSDL 2.0 SOAP 1.1 Binding is used.
	SOAPUnderlyingProtocol	xs:anyURI Corresponds to WSDL 2.0 {soap underlying protocol} property.  When this property is unspecified, and SOAPVersion is "1.2" or 1.2, this property defaults to the SOAP 1.2 HTTP protocol binding URI http://www.w3.org/2003/05/soap/bindings/HTTP/.  When the SOAPVersion is "1.1" or 1.1, this property defaults to the SOAP 1.1 HTTP protocol binding URI http://www.w3.org/2006/01/soap11/bindings/HTTP/.   Currently no other values than these are supported, but a SOAP over JMS binding would define a new
	SOAPMep	xs:anyURI Corresponds to WSDL 2.0 {soap mep} and {soap mep default} properties.  Defaults similarly to the {soap mep} property.
	SOAPHeaders	list of xs:anyType SOAP headers to be inserted into the message, as XML elements, corresponds to the WSDL 2.0 {soap headers} property.
	HTTPLocation	xs:anyURI Corresponds to WSDL 2.0 {http location} property.
	HTTPLocationIgnoreUncited	TRUE | FALSE Corresponds to WSDL 2.0 {http location ignore uncited} property.
	HTTPHeaders	xs:string The HTTP header to insert.  Corresponds to the WSDL 2.0 {http headers} property, particularly the {name} and {required} components.  The value is presumed to match the {type definition} of the header.
	HTTPQueryParameterSeparator	xs:string Corrsponds to the WSDL 2.0 {http query parameter separator} and {http query parameter separator default} properties.
	HTTPMethod	xs:string | "POST" Corresponds to the WSDL 2.0 {http method} and {http method default} properties.
	HTTPInputSerialization	xs:string Corresponds to the WSDL 2.0 {http input serialization} property.
	HTTPContentEncoding	xs:string Corresponds to the WSDL 2.0 {http content encoding} and {http content encoding default} properties.
	useMTOM	TRUE | FALSE Indicates whether the attachments should be sent MTOM optimized or not.  If TRUE, attachments would be sent out of SOAP message, optimized, with MIME headers in place.  If FALSE, attachments would be sent within SOAP payload, as base64Binary.
	responseXOP	TRUE | FALSE Controls whether XOP elements in a response with MTOM are resolved into the logically equivalent straight XML infoset or not.  If TRUE the member variable "attachments" of the message returned as a result of calling the request method would be set.  If FALSE, the binary content would be present in the response payload in base64 format.
	useWSA	TRUE | FALSE | 1.0 | "1.0" | "submission" Indicates whether to use WS-Addressing.  If TRUE, 1.0 or "1.0", WS-Addressing 1.0 is used.  When "submission" is specified, the submitted version is used.  Except when FALSE, the "action" must option must also be set.
	action	xs:anyURI The WS-A action to use when constructing the WS-A headers.  Also used as the SOAP Action, regardless of whether WS-A is engaged or not.
	replyto	xs:anyURI The address to use for the wsa:ReplyTo header. Defaults to the anonymous URI (depending on version). (note: this doesn't support reference parameters.)
	faultto	xs:anyURI The address to use for the wsa:FaultTo header. (note: this doesn't support reference parameters.)
	from	xs:anyURI The address to use for the wsa:From header. (note: this doesn't support reference parameters.)
	messageid	xs:anyURI The uri to use for the wsa:MessageID header. If not supplied, one will be manufactured.

Note that the following WSDL binding extension properties are not represented above - as they relate to the response message: 

• {soap fault code}
• {soap fault subcodes}
• {soap modules}  - replacement for useMTOM, useWSA, responseXOP, action?
• {http output serialization}
• {http fault serialization}