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

[my mail blew up last week, so I'm posting this from home (yes, I
still work at Akamai!), and as a result this won't be properly
threaded]

So, I never really understood the SOAPAction header, but I think I
might now. SOAPAction allows the service to be identified, while the
request-line URI allows the service to be located.

For example, I could design a SOAP service that allows invalidations
to be sent to caches. Individual deployments will be at different
URLs, so that they can be located, while SOAPAction allows the
message to be identified as an instance of that service, without
tying it to its location. This is primarily useful for software which
handles the SOAP messages but does not process the messages (such as
HTTP intermediaries which need to make decisions like access
control), as well as being useful as a dispatch hint for processors.

Is this well-aligned with other people's conception of SOAPAction?
For me, this is primarily illuminated by background from URI/URN/URL
distinctions...

RE: response code - the IANA registry is at 
  http://www.isi.edu/in-notes/iana/assignments/http-status-codes


P.S. - I found the comments comparing SOAP to JSP, CGI, etc.
revealing. We're designing a protocol, not an application platform,
although I've heard several external people express surprise about
that ;)

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

Received on Monday, 30 April 2001 22:29:56 UTC