Subject: Re: SOAP/XML Protocol and filtering, etc.

From: Vernon Schryver <[email-masked]>
Date: Tue, 8 May 2001 11:02:35 -0600 (MDT)

> From: Mark Nottingham <[email-masked]>

> > such as that it's a good idea to use XML for everything, or that it's a good
> > idea to layer new protocols on top of HTTP.
>
> Ah, diplomacy at its finest. ;)
>
> I didn't intend for the issues to be debated cross-group on the main
> IETF list; a better forum would be the [email-masked] list,
> which is archived and explained at
>   http://www.w3.org/2000/xp/Group/

I'm confused.  Either this is an IETF issue and so can only be debated
on IETF lists, or it has nothing to do with the IETF and shouldn't have
been brought here.  My guess was the second alternative, but people said
that SOAP involves changing HTTP, and the IETF owns HTTP.  If that is
true, than the a W3.org list would be wrong.  Worse, this whole exercise
could be seen as an attempt to co-opt the IETF's approval for a change
to an IETF protocol without letting IETF know what's going on.

Vernon Schryver    [email-masked]

---

From: Jeffrey Kay <[email-masked]>
Date: Tue, 8 May 2001 13:04:54 -0400

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 <[email-masked]>
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:[email-masked]]
> Sent: Tuesday, May 08, 2001 10:33 AM
> To: Keith Moore; Dick Brooks
> Cc: [email-masked]; Henrik Frystyk Nielsen; Mark Nottingham;
> [email-masked]; [email-masked]
> 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" <[email-masked]>
> To: "Dick Brooks" <[email-masked]>
> Cc: <[email-masked]>; "Henrik Frystyk Nielsen" 
> <[email-masked]>;
> "Mark Nottingham" <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> 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
> >
>

---

From: "Henrik Frystyk Nielsen" <[email-masked]>
Date: Tue, 8 May 2001 08:47:12 -0700

Hi Scott,

Just as a heads-up - SOAP/1.1 [1] changed this to allow any URI in the
SOAPAction header field so this should not be a problem anymore.

Henrik

[1] http://www.w3.org/tr/soap/

>As for the specific question that began this thread (whether the 
>SOAPAction header is useful or not), I can offer an implementation 
>perspective.  We've implemented the 0.9 version of SOAP as a part of 
>our UPnP implementation.  SOAP/0.9 is carried in HTTP and does 
>include the SOAPAction header.  It also includes the same 
>information (the action identifier) in the XML body of the message. 
>  We found the potential conflict between these to be a major pain 
>to deal with, especially since the namespace was represented 
>differently in the header and body (which meant that the comparison 
>had to be namespace-aware, it couldn't just be the equivalent of 
>strcmp).