Dear Lloyd,
The full "evolving" comment from the 'soap over beep' spec states:
"feature negotiation: SOAP is an evolving protocol. New versions
of the SOAP (such as the W3C's XMLP effort), and new features
(such as compression), are likely to emerge. For example, if a
new version of SOAP is specified, a corresponding feature for the
BEEP profile for SOAP should be defined that allows negotiated use
of the new version."
The idea is that BEEP should be able to carry a variety of SOAP
payloads - including the current version 1.1, the version under
development 1.2, and whatever the future might bring. We don't want to
limit it to the current version only. We don't want to wait a couple of
years until everything is complete and gone through a couple of updates
before defining the 'soap over beep' spec. So the sensible route we took
was to define what we can now, and add the feature negotiation mechanism
so that additional features may be easily added without breaking
existing implementations of the soap over beep spec, which might not
support that feature.
W.r.t. the question of who should be working on SOAP over BEEP - note
that there are many pieces of functionality evolving into a natural
stack - some are W3C - such as SOAP, (and I imagine soon) WSDL and UDDI,
and some are IETF - BEEP (RFC 3080), BEEP transport mapping to TCP (RFC
3081), TCP, etc. [when using BEEP for transfer].
At some point the IETF pieces have to interface with the W3C pieces.
There is naturally scope for discussion about who does what at such
interface points. (e.g. One could ask why was the XML *Protocol* work
not done in the IETF). As much of 'SOAP over BEEP' discusses usage of
BEEP and it effectively carries the SOAP envelope as an opaque piece of
data, it is fair to say it is just below the bottom of the W3C stack and
at the top of the IETF stack, so it should be an IETF spec in this
scenario.
More worryingly from a standards viewpoint:
'The BEEP profile for SOAP is identified as
http://clipcode.org/beep/soap
This URL is transient for work in progress. Note that "Appendix B. IANA
Considerations" states:
If the IESG approves this memo for publication, then the IANA
registers the profile specified in Section 7.1, and selects an IANA-
specific URI, e.g.,
http://iana.org/beep/soap
What is in the spec is normative, not what might be located at one of
these URLs.
section 4 - one-way messages: a NUL message *is* a response. Since
this is taking place over reliable TCP, it's not really a one-way
message.
All BEEP MSG messages require a response - RPY, ANS/NUL or ERR. The NUL
that is returned from a one-way *SOAP* message tells the peer that sent
the SOAP message that the BEEP implementation at the remote peer has
received the message - it says nothing about how it is further
processed.
Why have RPY *and* ANS?
RFC 3080 supports both, so we should too.
... without the *non-standard* non-BEEP error-in-RPY hackery ...
The spec is designed so that it carries an envelope of SOAP data without
having to know what is inside it.
Eamon O'Tuathail
http://www.clipcode.com