Thoughts on TAG issue EndpointsRef47

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
syntax.

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.

>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.)

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0119.ht
ml
[2] http://lists.w3.org/Archives/Public/www-tag/2005Jan/0000.html
[3] http://www.w3.org/2001/tag/issues#endPointRefs-47
[4]
http://hyperthink.net/blog/PermaLink,guid,8c9c4e73-24d0-4f9b-b28b-a7f6a8
58d721.aspx
[5] http://pluralsight.com/blogs/mgudgin/archive/2005/01/25/5438.aspx
[6] http://www.markbaker.ca/2002/09/Blog/2005/01/25#2005-01-maine-tag
[7]
http://hyperthink.net/blog/PermaLink,guid,7de8743c-29e0-46a9-ba8f-ee86c4
198813.aspx
[8] http://webpages.charter.net/chrisfer/2005/01/none-of-above.html

Received on Saturday, 5 February 2005 03:19:08 UTC