Re: Thoughts on TAG issue EndpointsRef47

Jonathan - thanks for spending the time to try to make sense of this.

On Fri, Feb 04, 2005 at 07:18:49PM -0800, Jonathan Marsh wrote:
> mailto: doesn't work over HTTP.

Sure it does!

Content-Type: text/plain
Content-Length: 5

It doesn't work the other way around, because HTTP is currently the only
application protocol which takes URIs rather than application-specific
identifiers.  That's why it's special.  It's also part of the reason why
the URI scheme has little to do with the protocol and therefore also
why it's not a "transport address".

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

Not at all.  It's definitely in conflict with the whole concept of
"protocol independence", but not with what you wrote above.  Perhaps
the mailto/HTTP example above will help illustrate why that is so.

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

POST is (at least) two things.  The first is the name of the semantic of
"document-in, document-out" style interactions, where one agent submits
a document to a service for processing, and perhaps gets a document in
return, and where that expectation - "processing" - is the only one the
client holds.  If you want all services to be able to accept documents
from any agent, then they all have to expose the same operation.

Another thing that POST is, is the correct HTTP operation to use when
you need to tunnel an application-specific mutating operation through
HTTP, since it's the closest semantic match.  So yes, it is the hook you
refer to, but no, I wouldn't say that HTTP blessed the practice, even

FWIW, the RESTful use of HTTP is the former use.

> 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 haven't proposed any because I want to be able to discuss the problem
without any solution-specific issues getting in the way.  But if you're
interested, I think the simplest solution would be to drop the concept
of an underlying-protocol-agnostic SOAP binding and create a SOAP/HTTP
binding instead which would place the important protocol metadata like
"address" in the Request-URI of HTTP, and also require other bindings
that do things similarly for other application protocols, e.g. put the
address in the "RCPT TO" SMTP operation.  Is that too draconian?  I
wouldn't personally call it that, since most SOAP usage is over HTTP
anyhow.  But I agree it's "radical" insofar as it abandons protocol


Mark Baker.   Ottawa, Ontario, CANADA.

Received on Sunday, 6 February 2005 13:01:53 UTC