Re: Thoughts on TAG issue EndpointsRef47

On Mon, Feb 07, 2005 at 08:30:25AM -0500, Christopher B Ferris wrote:
> > Sure it does!
> > 
> > POST mailto:jmarsh@microsoft.com HTTP/1.0
> > Content-Type: text/plain
> > Content-Length: 5
> > Ping!

[...]

Sorry Chris, but I can't make any sense of that response.  I don't see
what my example has to do with GMail, Hotmail, etc..  I'm simply
pointing out - in response to Jonathan's claim that HTTP doesn't work
with mailto: - that the HTTP request line accepts a "Request-URI" which
is not restricted to http URIs.  See;

http://www.zvon.org/tmRFC/RFC2616/Output/chapter5.html#Request-URI

> > 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
> > implicitly.
> > 
> > FWIW, the RESTful use of HTTP is the former use.
> 
> Sorry, but how is one to distinguish one from the other?

Good question.

In the former case, clients have the same expectation (aka contract,
aka interface) as each other.  In the latter, they don't.

> For that matter, 
> what 
> is the "processing" mentioned in the first case?

It's whatever the service does, like processing invoices, orders,
notifications, etc..

> How is it different from 
> "an application-specific mutating operation" and exactly what is that? 

An example of an application-specific mutator would be "orderShoes".  The
difference is that POST is an application-generic mutator.  So, when
publishing my shoe ordering app on the Web/Internet, I don't expose the
"orderShoes" operation, I expose a URI to which the order document can be
POSTed (a Facade).

> Does RFC2616 
> place *any* constraints at all on the nature of the "processing" that can 
> be 
> performed in response to a POST?
> 
> Of course it doesn't. 

Of course, it's an implementation detail.  All that HTTP constrains is
the *interface*.

FWIW, this is the same point we've been dancing around for 4+ years now,
so I'm not expecting any progress at this point.  But you did ask...

> Sorry Mark, but exactly what *is* the problem? HTTP places *no* 
> constraints
> what-so-ever on the content in the entity body of the HTTP POST message 
> aside
> from requiring that it be valid with regards to its MIME type. WS-A is 
> placing
> no constraints on use of the URI value of wsa:Address in an EPR. As Gudge 
> has 
> pointed out, the most common use case will be that the URI value will, 
> when 
> bound to SOAP/HTTP (1.1 or 1.2), be to place the URI in the HTTP 
> RequestURI 
> field. However, that would apply exclusively to a binding of SOAP to HTTP,
> not necessarily to any other protocol such as SMTP, BEEP, FTP, 
> WebSphereMQ,
> or whatever.

Right.  Hence my suggestion to reconsider the generic SOAP binding.

> Since you seem to have all this energy to go to the trouble of alerting 
> the
> TAG to this monstrous abuse of the Web architecture that would be resolved
> by a formalized binding of SOAP+WS-A/HTTP, why don't you write one (using 
> the
> SOAP Binding Framework in SOAP1.2) and submit it to the WG (or more likely
> to both the XMLP and WS-A WGs) for consideration as a possible, but 
> non-exclusive,
> binding. That would be a much more positive and productive engagement.

Gee, that's quite a burden you'd place on those who simply want to point
out what they believe to be architectural problems with a spec. *shrug*

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 7 February 2005 15:26:18 UTC