Steve takes issue with the issue. 8-) He starts with a paragraph which very accurately summarizes the issue, and then goes on to explain why he believes that it would be a mistake for the TAG to “make a short-sighted decision in the direction that Mark is proposing”. First though, a quick response to that point; I don’t recall proposing a solution (though it’s possible I have on the list), but I think the damage that Steve’s worried about has already happened, as they’ve agreed that the use of wsa:To I described is a problem (update; in fact, they’ve just agreed that they need to investigate it, though the comments in the minutes clearly indicate they all grok the problem).
He writes;
To me, this issue is really about the central notion of “transport address”: Can the URI that identifies my service be different than the URI that identifies the thing that takes the bits off the network and hands them to my service?
Again, an http URI is not a “transport address” (btw, is an IP address a transport address??). It’s an application layer identifier – a string – and it can serve its identifying-purpose completely outside of the context of a network. If you have one which identifies your service and can also be used to send messages to that service, what value is there in another one? HTTP is not a transport protocol, it’s an application protocol! Its clear to me that Steve (and every other Web service proponent for that matter) has yet to fully absorb the implications of that. Remember, we’re talking about very different stacks that use the same word (protocol) to refer to very different parts of that stack; in the Web services stack a “protocol” is inconsequential, while in any Internet/Web based stack, the protocol is the fundamental building block of interoperability, the exact opposite of “inconsequential”.
no comment until now