Re: Thoughts on TAG issue EndpointsRef47

Mark,

Please see my responses 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/07/2005 10:44:13 AM:

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

I was simply pointing out that in terms of deployed software, the theory
that you can use any old URI scheme in an HTTP request is not bourne out 
in practice.

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

Say what? That makes no sense. In both cases, there is server-side 
processing.
Are you suggesting that in the first that the client need not be aware of 
the
nature of that processing whereas in the latter it does? That too is 
nonsense.
HTML FORMs involves retrieving a FORM before engaging the POST. The 
awareness
is in the FORM (and more typically with the USER who fills it out).

I still see no distinction. In both cases, whether via HTML FORM, XForm or 

built-in application knowledge, the semantics of any POST are basically 
unique to a
given URI and established by the server. 

> 
> > For that matter, 
> > what 
> > is the "processing" mentioned in the first case?
> 
> It's whatever the service does, like processing invoices, orders,
> notifications, etc..

And if the PurchaseOrder, Invoice, etc. carried an identifier (PO123, 
INV123),
that would be abuse of HTTP I suppose?

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

But the only thing that the POST accepts is an <Order/>, so the reality is 
that
the POST is constrained beyond what is specified in the HTTP spec in 
accordance
with what the server has chosen for its processing.

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

How is this relevant to the issue of what is in the entity body of the 
POST.
MY point was that HTTP doesn't constrain this in any way. You have just 
confirmed
this point. Therefore, you can't make a case that WS-A voilates the Web 
Arch
if the HTTP protocol is the realization of the Web Arch we have today and 
SOAP+WS-A
is merely defining the content of the entity body of an HTTP POST (or GET 
in the
case of SOAP1.2 Response MEP/binding).

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

I don't think that's the case at all. People who raise issues are often 
called
upon to propose resolutions. That's how the WG gets stuff done. Issues 
don't
resolve themselves.

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

Received on Monday, 7 February 2005 17:29:25 UTC