Re: Thoughts on TAG issue EndpointsRef47

Jonathan Marsh wrote:

>Mark Baker raised this issue first with us [1], and when we didn't
>address it to his satisfaction, with the TAG [2], who accepted it [3].
>Steve Maine was one of the first to blog about it [4], suggesting that
>the central question here is "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?"  He also considers
>formalizing a "yes" answer into a new [TransportAddress] property,
>though it doesn't appear that doing so would have any affect on the
>Gudge in his blog [5] points out that a "no" answer would limit the
>ability of an EPR to describe an endpoint in a transport-independent
>manner, for instance, an endpoint available over several different
>protocols.  A transport-level address appropriate for one protocol might
>not be appropriate over a different protocol - http: doesn't work over
>SMTP, mailto: doesn't work over HTTP.  Also it seems in conflict with a
>basic tenet of Web services, which is that different hops might use
>different protocols, each hop with a transport address appropriate to
>that hop.
If what Gudge is describing is required, we might consider a multiple 
Protocol profile structure
for the "EPR".   This is what IONA was getting at.  We could represent 
all the variant
transport addresses required in the EPR.

Otherwise I am not at all clear on how the "logical" uri gets mapped to 
the various
transport addresses required for the variants desired.

Tom Rutt

>>From my simplistic practical perspective, that's enough to put the issue
>to rest.
>However Mark ups the discussion to the architectural level in his next
>thread [6], returning to a familiar theme of "HTTP is not a transport
>protocol, it's an application protocol!"  Perhaps somebody could explain
>to me that while HTTP is layered on top of the underlying TCP/IP
>protocol, it is dangerous to layer another protocol on top of HTTP
>itself.  The nature of the danger in practical terms is a subtle point
>that is well beyond the comprehension of mere mortals like myself
>despite years spent on the fringe of this discussion.
>Steve Maines responds [7] to Mark: "ProcessMessage/POST is not an
>operation, it's a punt. It's a verb that effectively means 'hey, I have
>no idea what you meant by this, so you go deal with this blob of data in
>whatever way you see fit'. In other words, it's a non-verb."  Chris
>Ferris immortalizes himself by making a similar point [8]: "'When I
>accept POST', said Humpty Dumpty, 'it means just what I choose it to
>mean, neither more nor less.'"  The implication is that POST is more of
>a hook for a higher-level application protocol than a component of an
>application protocol itself.  Looks to me like higher layers are
>arguably blessed by HTTP itself.
>In the end, I can't conceive of any non-draconian solutions, and Mark
>doesn't propose any either (which is one of the reasons his posts are so
>frustratingly abstract).  I'm not looking forward to the discussion,
>which is why I want to make sure the Working Group rejection of his
>issue is acknowledged as deliberate and let the TAG deal with it.
>Hope this helps (though I doubt it at this point.)

Tom Rutt	email:;
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Sunday, 6 February 2005 20:41:37 UTC