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(_at_)engenia(_dot_)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(_at_)userland(_dot_)com]
> Sent: Tuesday, May 08, 2001 10:33 AM
> To: Keith Moore; Dick Brooks
> Cc: moore(_at_)cs(_dot_)utk(_dot_)edu; Henrik Frystyk Nielsen; Mark 
> Nottingham;
> ietf(_at_)ietf(_dot_)org; xml-dist-app(_at_)w3(_dot_)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(_at_)cs(_dot_)utk(_dot_)edu>
> To: "Dick Brooks" <dick(_at_)8760(_dot_)com>
> Cc: <moore(_at_)cs(_dot_)utk(_dot_)edu>; "Henrik Frystyk Nielsen" 
> <henrikn(_at_)microsoft(_dot_)com>;
> "Mark Nottingham" <mnot(_at_)akamai(_dot_)com>; <ietf(_at_)ietf(_dot_)org>; 
> <xml-dist-app(_at_)w3(_dot_)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