RE: SOAP/XML Protocol and filtering, etc.

The question here isn't whether SOAPAction is allowable within the HTTP spec
-- it is.  The argument is that SOAPAction is a duplication of information
that should appear in the URI and the Content-Type headers. As a result, the
SOAP spec _mandates_ its use.  The problem with it is that it unnecessarily
levies a requirement on the web infrastructure.  SOAP would work just as
well without it.  Frontier's implementation, per Jake Savin's excellent
posts, describe how SOAPAction is used instead of a URI for a SOAP
dispatcher.  That alone sort of defies the nature of the web where URIs are
supposed to identify resources.  In the Frontier model, a SOAP post to any
URI is resolved by the SOAPAction header for dispatching.  In this model,
the SOAPAction header could easily be replaced by a URI and a Content-Type
header with the same effect.  In this way, existing web servers could
process SOAP without being required to process a special HTTP header.  In
addition, the approach I suggest doesn't bleed information out of the SOAP
envelope into the transport, much like HTTP doesn't bleed into TCP.

jeffrey kay <jkay@engenia.com>
chief technology officer, engenia software, inc. 
"first get your facts, then you can distort them at your leisure" -- mark
twain 
"golf is an endless series of tragedies obscured by the occasional miracle"
-- sports illustrated 
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein  

> -----Original Message-----
> From: Dave Winer [mailto:dave@userland.com]
> Sent: Tuesday, May 08, 2001 10:33 AM
> To: Keith Moore; Dick Brooks
> Cc: moore@cs.utk.edu; Henrik Frystyk Nielsen; Mark Nottingham;
> ietf@ietf.org; xml-dist-app@w3.org
> Subject: Re: SOAP/XML Protocol and filtering, etc. 
> 
> 
> Does the HTTP spec allow applications to add headers?
> 
> If so, what the heck is the argument about?
> 
> BTW, I thought SOAPAction was dorky when I first heard the 
> idea. But it's
> there.
> 
> There's deployment based on SOAPAction.
> 
> Dave
> 
> 
> ----- Original Message -----
> From: "Keith Moore" <moore@cs.utk.edu>
> To: "Dick Brooks" <dick@8760.com>
> Cc: <moore@cs.utk.edu>; "Henrik Frystyk Nielsen" 
> <henrikn@microsoft.com>;
> "Mark Nottingham" <mnot@akamai.com>; <ietf@ietf.org>; 
> <xml-dist-app@w3.org>
> Sent: Tuesday, May 08, 2001 6:25 AM
> Subject: Re: SOAP/XML Protocol and filtering, etc.
> 
> 
> > > >far better for the SOAP-specific message broker to have intimate
> knowledge
> > > >of the SOAP-specific payload, than to have the 
> SOAP-specific message
> broker
> > > >to have intimate knowledge of the HTTP-specific request header.
> > >
> > > I never said a message broker was SOAP specific.
> >
> > a message broker that looks at a SOAPAction header isn't 
> SOAP specific?
> >
> > > There are message brokers running on HTTP servers that 
> can dispatch
> > > processing for EDIINT AS2, GISB EDM, AIAG E-5, ebXML, 
> SOAP and other
> types.
> >
> > what you are saying is that there are people out there who do not
> understand
> > the value of clean separation of function between layers.  
> how is that a
> > justification for a standards-setting organization to propagate that
> > misunderstanding?
> >
> > Keith
> >
>

Received on Tuesday, 8 May 2001 13:04:47 UTC