- From: Glen Daniels <gdaniels@macromedia.com>
- Date: Mon, 11 Jun 2001 15:03:44 -0400
- To: "'Jean-Jacques Moreau'" <moreau@crf.canon.fr>, Dave Winer <dave@userland.com>
- Cc: Williams Stuart <skw@hplb.hpl.hp.com>, "'christopher ferris'" <chris.ferris@east.sun.com>, Larry Masinter <LMM@acm.org>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Simon Fell <soap@zaks.demon.co.uk>, xml-dist-app@w3.org
Hi all: May I suggest the following interpretation? SOAP is essentially a point-to-point protocol, and the binding information that you use to talk to the guy on the other side of the wire is also therefore point-to-point. You need SOME level of "magical" data from outside the SOAP world to be able to find and talk to someone - a simple example of this is the endpoint URI, or the fact that you're using SOAP-over-HTTP, or perhaps SOAP-with-attachments-over-HTTP. I would purport that SOAPAction is just like target URI - it's a piece of transport-specific binding information which you may need to get the right thing to happen. I think it's precisely equivalent to saying "to talk to me, use HTTP POST to this URL" - it's all just metadata. If client C talks to intermediary I and then to server S, the contracts to get the message there are from C->I, and then from I->S. Either of these links might run over any particular transport binding, and might require any sort of transport-specific information such as SOAPAction values, authentication credentials, multiplexing IDs, what have you. If I is a "fixed path" intermediary, it will have a priori knowledge of S, and any appropriate information it needs to contact it successfully. In this case, C must know the same type of contact information about I, but nothing more. In other words, it can appear to C that he's talking to I with no knowledge that I talks to S behind the scenes. On the other hand, if I is a "generic" intermediary which can potentially talk to anywhere, we need some way of expressing to I that it's supposed to talk to S in particular, and again, what specific info it needs to make that connection. As it stands, this is "out of band" to SOAP itself - C might explicitly pass URLs, SOAPAction values, etc. in the message, or you might rely on some registry to get the information for you based on something else (C's address, authentication info, the QName of the body element, etc). The main point here is that I believe SOAPAction to be a useful bit of transport-level optimization information, but in a similar way that almost anything could be specified by a particular transport binding. As I mentioned at the F2F, I would like to see the group discuss two issues before I personally feel like we can make any really well-informed decisions about SOAPAction. First, what is a transport binding? What information can be carried there, which bits can the SOAP processor itself (or applications built on top) utilize to access extra functionality or optimize things (for example, the implicit correlation provided by an HTTP binding), etc. The tension here is between simple bindings that everyone can use without any "extra" knowledge, and more full-featured bindings that provide a lot of value-add for the users. Second, what do we want to say, if anything, about metadata? Argh - I have to head to a meeting, so I can't expound further at the moment, but I want to get this basic thought out there and see what you all think. --Glen
Received on Monday, 11 June 2001 15:03:55 UTC