Larry,
First, thanks for moving this debate to a technical discussion on issues
relevant to soap over beep.
SOAPAction
==========
SOAPAction is not supported in SOAP over BEEP on purpose.
SOAPAction is an HTTP header field that is used for many things,
including, most worryingly, to get through firewalls. This is a BAD
idea, and the use of SOAPAction is strongly discouraged. The current
debate on the W3C list is how best to tell people not to use it.
The use of SOAPAction has been extensively discussed:
http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0104.html
I particularly liked the comment from Valdis.Kletnieks:
"Consider that the user behind a firewall could, in conjunction with a
site
that supported it, just tack onto the end of the URL a
&callit=whateverSoap
and the web site could just label it with SOAPAction=whateverSoap
will get through the firewall.
So what is this actually fixing? The guy *inside* the firewall
presumably knows what will be allowed to pass, and can tell the
guy outside what to call it. This sounds like a scene from a
James Bond movie - if he knows that the roadblock up ahead is
looking for a Jaguar with Swiss plates, he hits a button and
he's now driving a Jaguar with French plates."
Concerning the other issues you raised:
=======================================
For those interested, the W3C SOAP issues list is at:
http://www.w3.org/2000/xp/Group/xmlp-issues.html
Issue 12 - "SOAP and HTTP status codes": We use SOAPFault envelopes
(which BEEP will not parse) for SOAP-related errors. It is up to the
SOAP implementation sitting above BEEP to decide what to do with it.
Issue 67 - "convey error information": see comment for 12 above
Issue 69 - " http binding bias": Much of SOAP 1.1. was written with a
strong HTTP bias - essentially the SOAP over BEEP spec is an alternative
for the HTTP pieces. With respect to the intermediaries, we need to
distinguish between BEEP intermediaries (running the BEEP TUNNEL) who
know nothing about the contents of the SOAP envelope and simply forward
it on, and SOAP intermediaries (identified as SOAP actors), who do parse
the SOAP envelope and may take some local actions before forwarding the
same or an altered SOAP envelope onwards. BEEP intermediaries are
handled naturally as part of the BEEP infrastructure and there is
nothing specific to SOAP that we have to discuss. SOAP intermediaries
are a topic for SOAP processing engines which will understand the main
SOAP spec - and for the BEEP over SOAP spec we resolutely don't want to
get involved in that layer - that is for the W3C.
Issue 95 - "SOAPAction" - see SOAPAction above
Issue 105 - I think the three main messaging patterns - one-way,
request-response and request/N-response - are covered in the SOAP over
BEEP spec.
At the very least, you should be explicit about the
fact that SOAP is undergoing active review.
First line of section 1: Introduction states: "This memo specifies how
**SOAP 1.1** envelopes are transmitted using a BEEP profile".
http://www.xmethods.net/ilab/ has a list of some SOAP 1.1.
implementations - there are plenty - which indicates its status as an
accepted spec in the community.
It is likely over the next number of years the W3C will produce updated
SOAP and SOAP-related specs every 18 months or so. SOAP 1.2 will be
coming out next year, but there are plenty of other topics that need to
be covered in future. What should we do? We have two options - wait
until all the SOAP work is completed, or define a SOAP over BEEP spec
for the current situation, with a clear eye to the future.
We are not guaranteeing that the current soap over beep spec will work
for every future SOAP spec, but given that we are not interacting with
the SOAP envelope at all, and given that we have the "features" option
to cater for some future adjustment, it is sensible to go ahead and
define it now.
Eamon