- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 7 Jul 2001 09:34:07 -0700
- To: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
- Cc: henrikn@microsoft.com, xml-dist-app@w3.org
On Sat, Jul 07, 2001 at 12:44:28PM +0100, Eamon O'Tuathail wrote: > > > I think the current debate is whether layering is an accurate > > and useful model for what SOAP does. > > Agreed. To use Stuart Williams' lovely phrase, I'm an unashamed > layerist. Is anyone seriously arguing that layering is not the way > to go? The heretics! *grin* > If the anti-layerists are prepared to skip a layer or two, why not > more - to use their logic to its ultimate conclusion what argument > is there against creating a wonderful "fiber-optic binding" for > SOAP, which might be a 1,000 page document describing how SOAP > envelopes can be transported directly in strands of fiber without > any intervening layers (hey, who needs IP?). It could start off > from base principles with the light equations, etc. Good luck to > them. It's not a matter of skipping layers below - it's saying that SOAP isn't a new layer in the OSI stack, just what is effectively an application-layer messaging toolkit. If somebody *really* wants to go to the trouble, why stop them? Some uses of SOAP may be in-machine IPC or other things that don't travel across a wire. > > Interesting - Akamai uses pre-arranged conventions (distributed, > > out-of-band state) to configure somewhere around 10,000 > > intermediaries in a global deployment... what's you're definition of > > 'wide'? ;) > > Eh, .. well .. a 'minimalist' wide deployment could start with two > companies. > > When we get to 100 companies or 10,000 companies I think we will > see the issues with pre-arranged conventions. Akamai's fine > architecture shows it can work well within a single company - I am > not disputing that. I don't dispute there'd be problems with scaling to large numbers of participants if they don't have a broker. The point is that there are a number of use cases for SOAP, not just dynamic find-and-bind Web Services between parties (even though it's getting the most press time currently). > > There are already proposals for routing and endpoint > > identification (SOAP-RP), authentication (XML Digital > > Signatures), caching ("Optimising Web Services with > > Intermediaries"), and discussion of others, including explicit > > correlation. All of these are expressed in SOAP blocks. > > XML Digital Signatures provide integrity, message authentication, > and signer authentication only - all (useful) services at the > messaging protocol layer. Authentication services at the > application protocol layer would authenticate the communicating > endpoints themselves. XML DigSigs alone do not verify that the > sender of the message (who might not necessarily be the signer as > it could have got the msg routed from somewhere else) is who the > recipient thinks it is, or vice versa. What proves that the validly > signed XML message is actually being transported to the intended > recipient, as opposed to an imposter recipient (and no, we do not > wish to encrypt it, for business/legal reasons). Authentication at > the application protocol level would provide these (very necessary) > additional services. So you're saying that using auth provided by the transport is stronger because the transport provides endpoint identification, and therefore the auth speaks about the message path? Why can't in-message authentication speak about the endpoints identified in-message (or by the transport, for that matter)? DigSig alone doesn't do this to the best of my knowledge, but a Module utilizing it could. [Just to clarify, the text you respond to below wasn't written by me - I think they might be Henrik?] > > so many people have figured out how to make bindings to all kinds > > of underlying protocols including SMTP, FTP, TCP, IPC, HTTP, MIME > > multipart, BEEP, SIP, etc. > [...] > > > The binding is exactly what it sounds like - a gluing mechanism > > between SOAP and whatever underlying protocol. There should be no > > additional semantics defined by the binding because the places > > where we add semantics is either as SOAP extensions or as > > underlying protocol > > Agreed - thin bindings are good, fat bindings are bad. I'd agree as well. -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 7 July 2001 12:34:13 UTC