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

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


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

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