Re: Thoughts on TAG issue EndpointsRef47

Mark,

Please see my comments below.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 02/06/2005 08:19:47 AM:

> 
> 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!
> 
> POST mailto:jmarsh@microsoft.com HTTP/1.0
> Content-Type: text/plain
> Content-Length: 5
> Ping!

I just tried to send Jonathan an email via my browser by entering his 
mailto: URI
in the URI field. Of course, that's a GET not a POST. However, apparently 
both Firefox 
and IE tried to transfer the message to Google's gmail service. It really 
didn't work in either case. Gmail was thoroughly confused by the request. 
Granted, 
they could update their origin server to recognize this and respond with a 

Compose Mail form pre-addressed to Jonathan. However, that would only be a 
hack if 
you ask me. The important thing, from my perspective, is that there is 
clearly a
line missing from the HTTP POST above, that which identifies the HOST to 
which the
message is to be sent. Seems to me that for this to work, it really should 
be 'microsoft.com'
but I kinda doubt that Microsoft would oblige by supporting this request.

Bottom line for me, this is merely a hack that is keying off of what the 
*browser* 
does in response to the user clicking on a link that contains a URI with 
the 
mailto: scheme.

Note that Hotmail and probably Gmail as well, use an HTML Form with 
METHOD="POST"
and to a URI that is NOT the mailto: URI of the addressee of the email but 
to a
URI of a Servlet, ASP or CGI script that will process the entity body into 
a 
valid SMPT request (most likely). 

OMG! They are tunnelling an RFC2822 To: address over HTTP POST! Watch out, 
the 
Web's gonna crash! Alert the TAG! Stop the insanity!

> 
> 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
> implicitly.
> 
> FWIW, the RESTful use of HTTP is the former use.

Sorry, but how is one to distinguish one from the other? For that matter, 
what 
is the "processing" mentioned in the first case? How is it different from 
"an application-specific mutating operation" and exactly what is that? 
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. 

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

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.

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.

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

Received on Monday, 7 February 2005 13:31:12 UTC