Re: Issue 2: specifying protocol headers other than SOAPAction (was: SOAPAction)

 Jean-Jacques,
 I see two problems with your proposal:

 1) The element http:field is named intuitively because it really does
only relate to HTTP fields.
 The element soap:field, on the other hand, needs clarification: does it
only support HTTP or does it support other transports, too? How does it
handle the possible transports that don't have MIME headers?
 So, I suggest that the element soap:field is renamed to soap:mimeField
and is only applicable to transports that support MIME headers.

 2) MIME/HTTP header fields don't necessarily have parameters. Their
content is a string. In case of a media type, this string is formed by
concatenating the type, subtype and possible parameters, but for example
in the SOAPAction field (SOAP/1.1) there is no notion of a parameter. I
think that the soap:parameter and http:parameter elements should rather
be something like mime:contentTypeParameter.

 The commonality here is the handling of cases where the WSDL would
become inconsistent, for example:

<soap:binding transport="http://example.org/SOAP-TCP-binding"/>
<soap:field name="X-MD5-Hash">
    <soap:parameter name="foo"
                    value="bar"/>
</soap:field>

 In case the example SOAP TCP binding doesn't transfer MIME headers nor
anything equivalent, or in case X-MD5-Hash doesn't define any
"parameter"s, the WSDL description would be broken.

 Basically, what I'm opposed to is the possibility of schema-valid but
broken constructs; I think we should strive to allow as few of these as
possible.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/




On Thu, 2002-09-12 at 17:16, Jean-Jacques Moreau wrote:
> 
> A while ago, the WG decided to generalize the "soapAction" header 
> mechanism to other protocol headers. I took a todo to provide the 
> corresponding write up. Here is that write up.
> 
> Jean-Jacques.
> 
> ---------------------
> 
> Summary
> 
> The "soapAction" attribute is used to specify the value of the 
> "SOAPAction" HTTP header field. Two issues:
> 
>    1. SOAP 1.2 has replaced "SOAPAction" with the "action" parameter on
>       the HTTP Content-Type header field.
>    2. There is a desire from the WG to replaced the specific, ad-hoc
>       "soapAction" attribute by a mechanims which works for other
>       headers (and possibly other protocols).
> 
> Proposal
> 
>    1. Remove the "soapAction" attribute
>    2. Introduce instead an <http:field> element to the HTTP binding.
>    3. Introduce an equivalent <soap:field> element to the SOAP binding.
>    4. Both elements would be direct descendents of the <input> and
>       <output> elements.
> 
> Grammar
> 
> The grammar for <http:field> is as follows. The grammer for <soap:field> 
> is equivalent
> 
> <http:field name="http-header-field-name"
>             value="http-header-field-value"?>?
>     <http:parameter name="parameter-name"
>                     value="parameter-value"?>?
> </http:field>
>   
> 
> Description
> 
> When present in a WSDL description, the <http:field> and 
> <http:parameter> indicate that the corresponding header field or 
> parameter MUST be present in the inbound message or WILL be present in 
> the outbound message (depending on whether they appear in <input> or 
> <ouput>).
> 
> The "value" attribute for <http:field> or <http:parameter> MAY be 
> omitted, indicating that it may not be known in advance. Example: 
> Content-Length or a cipher. When a value is supplied, this value MUST be 
> present in the inbound or outbound message.
> 
> Examples
> 
> <http:field name="X-MD5-Hash"/>
> 
> 
> <soap:field name="Content-Type"
>             value="application/soap+xml">
>     <soap:field name="action"
>                 value="http://example.org/fishTheTrouts"/>
>     <soap:field name="charset" value="utf-16"/>
> </soap:field>
>   
> 
> Variants
> 
> An alternative would be to combine the <http:field> and  <soap:field> 
> element into a single <wsdl:field> element. Each binding would then 
> indicate how this element would be interpreted.
> 
>  
>

Received on Wednesday, 18 September 2002 07:21:37 UTC