Re: Last Call: Using SOAP in BEEP to Proposed Standard

[Lloyd Wood <l.wood at eim.surrey.ac.uk>]

On Mon, 10 Sep 2001, Eamon O'Tuathail wrote:

> 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. 

That's very W3C fast-track approach. It strikes me it's not the IETF
standard cycle, which has been known to take... well, rather longer.

I can't see feature negotiation working well in implementations; it's
nice in theory, but often problematic in practice. The feature
negotiation described in your draft seems clean and simple, but see
further comments on this at end. I'm not convinced it's needed.

 
> 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 - 

natural? beg to differ.


> 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). 

One _could_ ask why the xml protocol work was done at all. (and isn't
xml a format?)


> 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"

...which is why I cited IANA in the following lines:
$ What happens to the standard if that profile described on that url
$ (or an IANA equivalent - see IANA considerations) changes?

I have trouble viewing any url/uri as a normative reference, and would
much prefer to see the original content embedded in the nascent rfc,
so that the starting point is a fixed target.


> >> 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. 

Well, RFC 3080 supports ERR. You do not, overloading RPY in this case,
and by your reasoning above you should.


> >> ... 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. 

Then you don't need to support both RPY and ANS to distinguish between
types of SOAP message patterns, do you? That's not opaque.

And if you *really* want to be opaque, why would you need any feature
negotation in BEEP? You could leave that up to the SOAP versioning in
the Envelope element...


I am concerned by the phrase 'tuned for privacy' and use of 'beeps'
(presumably as analogous to 'https') to suggest an equivalent level of
security, when all that is required is the start of a user
authentication profile.

Is that really strong enough from a security perspective, or simply
desirable from the marketing viewpoint that the phrase 'tuned for
privacy' suggests? (I'm by no means a security expert.)

thanks,

L.

being tuned for privacy isn't much use if you're not in the right key.

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>