Re: SOAPAction Proposal

Here's a go.

Assuming that discussion of SOAPAction would occur in the HTTP
binding section of the specs:

  Previous versions of SOAP required the SOAPAction HTTP request
  header to be present when the HTTP binding was in use; in this
  binding, SOAPAction is OPTIONAL.

  SOAPAction is designed as an optimisation mechanism to convey the
  'intent' of a SOAP message bound to a HTTP request. SOAP
  Applications using this binding MAY require the presence of a
  SOAPAction HTTP request header. However, SOAPAction SHOULD NOT be
  generated or required by SOAP implementations UNLESS a particular
  SOAP Application invokes this functionality.

  It is RECOMMENDED that SOAP Applications which do so formally
  express their requirements through some form of service
  description.

I've tried to avoid using 'Web Service' here, as we seem to have done
without it in the documents so far. This text is pending our
definition of 'SOAP Application', of course, but I *think* it's
somewhat appropriate here, based on recent discussion. If it's felt
that this is an incorrect use of SOAP Application, we'd probably need
to fall back to 'Web Service' (and therefore define the term?), or
maybe 'ultimate SOAP receiver'.

The last paragraph may or may not be a Good Thing, as it is probably
our only reference to service description.

There also isn't a mention of what 'intent' means, or how it can be
used to optimise SOAP; I'm somewhat ambivalent as to whether we
should attempt to address this.


On Wed, Sep 05, 2001 at 03:38:55PM -0400, Doug Davis wrote:
> Mark - could you propose some clarifying text?
> -Dug
> 
> 
> "Henrik Frystyk Nielsen" <henrikn@microsoft.com>@w3.org on 09/05/2001
> 03:27:12 PM
> 
> Sent by:  xml-dist-app-request@w3.org
> 
> 
> To:   "Mark Nottingham" <mnot@mnot.net>
> cc:   "Rich Salz" <rsalz@zolera.com>, <Noah_Mendelsohn@lotus.com>, Doug
>       Davis/Raleigh/IBM@IBMUS, <xml-dist-app@w3.org>
> Subject:  RE: SOAPAction Proposal
> 
> 
> 
> 
> Sounds great!
> 
> >Some implementations automagically generate and/or require it,
> >IIRC. Stuart's question is framed very nicely; the optionality
> >should be the service provider's/service consumer's, not the
> >particular stack implementation's. Perhaps if we target
> >(groan) the 'optional', this would be resolved to everyone's
> >satisfaction?
> 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Wednesday, 5 September 2001 19:12:03 UTC