W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2002

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

From: Jacek Kopecky <jacek@systinet.com>
Date: 18 Sep 2002 13:21:33 +0200
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
Cc: Web Service Description <www-ws-desc@w3.org>, FABLET Youenn <fablet@crf.canon.fr>
Message-Id: <1032348093.10627.51.camel@krava>

 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"

 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

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:39 UTC