RE: [i95, i22] - Proposal for clarifying use of SOAPAction

Henrik --

> >I'd agree that text/xml would be really hard to distinguish 
> >SOAP messages from others without processing the XML directly. 
> > I'd be more in favor of a text/xml-soap or 
> >application/xml-protocol or something like that to clearly 
> >identify the kind of XML involved.  It's not a perfect 
> >solution, but it solves the "signal" problem without having to 
> >resort to another header. Another thought might be to use 
> >something like:
> >
> >	Content-Type: text/xml; format=xml-protocol
> >
> >This would have the same signal effect as SOAPAction, but 
> >without the extra header value.  
> 
> But it doesn't really - there are two parts to the SOAPAction fields -
> the fact that it is a SOAP message (which at the end of the 
> day doesn't
> say much of anything) and then there is the hint which is 
> administrated
> in a decentralized manner. 

I agree that it doesn't cover the "hint".  But that's the point really --
the use of a hint.  To quote Noah, the "hint" is a solution looking for a
problem.  If the "hint" is a dispatch address within a given web server,
then I question why the URI doesn't provide the same function.  If the
"hint" is merely an indicator of the type of the content, then I suggest
that Content-Type does the same thing.  The real question is where is a
"hint" required?  SOAP or XMLP intermediaries should clearly be expected to
process the XML, hence no "hint" required.  As such, I'd say than an HTTP
binding must work on existing web infrastructure -- browsers and servers,
intermediaries and firewalls.  The addition of the SOAPAction header changes
the semantic characteristics of a web transaction, making existing
infrastructure not work.  Web browsers would need to implement it to support
SOAP, which means that a common POST from a form couldn't generate an XML
stream and simply POST it to a waiting web server.  

Similarly, think about the transport intercepts that the hotels use to get
you to pay your $9.95 for 24 hours of high speed Internet.  This means that
an intercepted SOAP message would receive a 200 back, although the content
in the message wouldn't be a SOAP response.  Unfortunately this is all real
life.  We are much better off letting HTTP mean "the web" and not adding
constructs that are unnecessary.  In this regard, an HTTP binding is better
viewed merely in the context of transport, where the payload happens to be
XMLP content rather than presuming that the web needs to understand anything
about the package it's carrying.

So there are really two arguments mixed in here.

1) SOAPAction is unnecessary because it duplicates what could be in the
Content-Type header and in the URI.
2) An HTTP binding must conform to the expectations (good and bad) of the
web as we know it.  The stack should be constructed such that the lower
layer (in this case HTTP) knows as little as possible about the upper layer
(in this case SOAP or XMLP).  This is virtually identical to the approach
used with HTTP over TCP, right?  I don't see the TCP binding for HTTP
needing any "hint" to understand something about the HTTP package and
neither should the HTTP binding for XMLP require any "hint".
 
> Btw, there is an RFC on XML and media types - it's RFC 3023

Thanks for the pointer.  With this RFC in hand, I'd revise my previous
suggestion to application/xmlp+xml or application/protocol+xml.  

Regards --

jeffrey kay <jkay@engenia.com>
chief technology officer, engenia software, inc. 
"first get your facts, then you can distort them at your leisure" -- mark
twain 
"golf is an endless series of tragedies obscured by the occasional miracle"
-- sports illustrated 
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein

Received on Tuesday, 8 May 2001 12:49:00 UTC