Re: wsa:To -> SOAP1.2's ImmediateDestination

> That's incorrect.  As an example of how the binding doesn't treat HTTP
> as a transport protocol, consider that SOAP faults are returned using
> HTTP error codes.

In SOAP 1.2, which is what I assumed we're talking about, they're not.

> In fact, other than the ambiguous definition of the
> ImmediateDestination property, I challenge you to point out a single
> part of the specification which supports your claim that the binding is
> a transport binding.

In addition to the one above, there's also the fact that the
request-uri only conveys target information to the ultimate recipient.

So that's two.

> >So the justification for your interpretation
> > here is just being obstinate. :)  Until WS-Addressing came along,
> > SOAP had no end-to-end for defining the target.
>
> You don't think that's odd?  That a Request-Response MEP had no
> means of actually identifying the thing that provides the response?

I'm sure there were various adhoc mechanisms for doing it before WSA
came along.  It doesn't bother me all that much that we're only "just now"
defining addressing for multi-hop SOAP traffic.  There hasn't been
all that much need, yet.

> That's either a massive oversight, or else something else is going on
> here.

Few protocol suites are emerge fully-baked from the mind of Zeus.

> Consider the issue you guys had over how one knew whether WS-Addressing
> was active for a given message; an issue that completely vanishes with
> my interpretation of the spec.

But at the cost of giving other things up, like transport neutrality,
and limiting HTTP implementations to be the ultimate recipient.

> > > should also add though, for clarity and completeness' sake, that
> > > SOAP/HTTP gateways can be SOAP intermediaries, and I'm not suggesting
> > > those shouldn't be able to be used, except insofar as they must also
> > > be the ultimate recipient.

It would be interesting to see if any of the people you mention,
still (if ever) really believe this.

> > > Earlier you mentioned a "SOAP level" and an "HTTP level".  FWIW, my
> > > view is that there is only one level there that both technologies share.
> >
> > That is not the way SOAP works.  You know this.
>
> If it worked this way, I would have objected, strenously, during its
> development.  And it's not like I was trepidacious about raising
> objections during that time, if you recall. 8-)

And my impression of your objections was that SOAP should do a better
job of leveraging HTTP, and use it more as an application protocol
than a transport protocol, and "defer" to HTTP whenever that's used.
To me, that is saying "it should be one" whereas those on the "other
side" were saying there's two layer.

> I don't have time to waste on games, Rich, and I resent your suggestion
> that I do.

At times it seems like making SOAP be RESTful is one of the most
important (technical) things in the world to you.  The sheer
amount of time spent typing is ... inspiring.  And many of these
discussions seem to me to be so repetitive that the only reason I
came to was that you're trying to engage in Socratic discourse as
a pedagogical technique.

> So how do you explain the value of the ImmediateDestination being
> described as "An identifier (URI) that denotes the responding SOAP
> node"?  If that's a typo, as Chris suggested, is it just a coincidence
> that it's a typo completely consistent with my view?

Yes.  Because that interpretation is in direct conflict with the
definition in table 3.  There is no way that the SOAP processing
model would "limit" itself such that HTTP nodes couldn't be active
intermediaries.  And I would expect this to be called out in
section 2.7 of part 1.

> In short, my interpretation of the spec is at least as consistent with
> the SOAP 1.2 spec-as-written than yours, possibly more so.

I believe my previous paragraph shows that this claim is wrong.

> Moreover,
> it's consistent with the HTTP specification and Web architecture, unlike
> your interpretation.

I'll give you that one.

And arguably it proves my point, not yours.  IF it fits so well into
HTTP and Webarch, then it can't be part of SOAP, right? :)

        /r$

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html

Received on Thursday, 25 August 2005 03:28:35 UTC