The SOAP in BEEP spec describes how SOAP envelopes (of XML data) are
transported. It will carry SOAP 1.1. and any future compatible version.
SOAP 1.1. is in very widespread use already - the quicker people are
provided with a strong alternative to running it over HTTP the better.
SOAP 1.2 also relies on the SOAP envelope concept - so it can be also
carried over the current proposal. There are ongoing discussions in the
W3C about certain XML fields inside the envelope - as BEEP does not even
examine the envelope it is not a factor.
I don't know what might be in some future SOAP 1.3 - if it is compatible
with the SOAP envelope concept it too will be able to be carried in the
current 'soap over beep' spec without modifications.
Some of the new extension fields in SOAP 1.2 are in effect to produce a
mini-application protocol inside SOAP - what we might accurately call
the "soap with custom application protocol over tcp option" - what
others call the "soap-over-tcp" option (the former is technically more
accurate while the latter is nicer from a marketing perspective [are we
technical or marketing people here?]). I can see why those who approve
this competing approach would like to delay 'soap in beep' as long as
possible, but I hope you can appreciate that the rest of us people
believe **IETF** BEEP is a good idea, believe the mapping as specified
is finished, and now would like to agree on the spec and get on with
using it.
Eamon O'Tuathail