RE: [Fwd: Proposals to address SOAPAction header]

[Dick Brooks <dick@8760.com>]

Chris,

The SOAP 1.1 spec is very clear regarding the use of SOAPAction,
section 6.1.1 of the SOAP 1.1 spec states:

"6.1.1 The SOAPAction HTTP Header Field
The SOAPAction HTTP request header field can be used to indicate the intent
of the SOAP HTTP request. The value is a URI identifying the intent. SOAP
places no restrictions on the format or specificity of the URI or that it is
resolvable. An HTTP client MUST use this header field when issuing a SOAP
HTTP Request."

The spec clearly indicates that a client MUST use this header field when
issuing a SOAP HTTP Request.

I don't like either A or B and would prefer that the SOAP 1.1 spec be used
verbatim with regard to SOAPAction.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> christopher ferris
> Sent: Wednesday, June 13, 2001 3:13 PM
> To: ebXML Transport (E-mail)
> Subject: Re: [Fwd: Proposals to address SOAPAction header]
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/elists/admin_email.shtml>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> Dick/David,
>
> The required presence of SOAPAction in the SOAP1.1 spec
> doesn't REQUIRE that it be used. Thus, some SOAP implementations
> will be unaffected.
>
> The proposals on the table (A and B below) are an attempt at
> reducing any interoperability issues. Read them carefully.
> Note also the carefully chosen language of "deprecated" and
> SHOULD NOT in the option B.
>
> Cheers,
>
> Chris
>
> Dick Brooks wrote:
> >
> > David,
> >
> > If SOAPAction is removed from the XML Protocol Activity spec it
> > will not be compatible with SOAP 1.1 implementations, because SOAP 1.1
> > *requires* the SOAPAction header.
> >
> > Dick Brooks
> > Group 8760
> > 110 12th Street North
> > Birmingham, AL 35203
> > dick@8760.com
> > 205-250-8053
> > Fax: 205-250-8057
> > http://www.8760.com/
> >
> > InsideAgent - Empowering e-commerce solutions
> >
> > > -----Original Message-----
> > > From: David Fischer [mailto:david@drummondgroup.com]
> > > Sent: Wednesday, June 13, 2001 2:17 PM
> > > To: Dick Brooks; christopher ferris
> > > Cc: ebXML Transport (E-mail)
> > > Subject: RE: [Fwd: Proposals to address SOAPAction header]
> > >
> > >
> > > Does this mean W3C XML Protocol will not be backward compatible
> > > with current
> > > SOAP implementations?
> > >
> > > David Fischer
> > > Drummond Group.
> > >
> > > -----Original Message-----
> > > From: Dick Brooks [mailto:dick@8760.com]
> > > Sent: Tuesday, June 12, 2001 5:38 PM
> > > To: christopher ferris
> > > Cc: ebXML Transport (E-mail)
> > > Subject: RE: [Fwd: Proposals to address SOAPAction header]
> > >
> > >
> > > Chris, see comments inline
> > >
> > > > You can achieve the same with the Request-URI. Setting up a unique
> > > > URI to differentiate between services is trivial. Most if not all
> > > > web servers provide aliasing so there can be but one servlet
> > > > handling requests for various URIs, using the Request-URI to do
> > > effective
> > > > dispatching to appropriate handlers.
> > >
> > > I'm not sure how trivial this is from an admin standpoint
> > > but I suspect the administrative problem grows with the number of
> > > redirects/services deployed.
> > >
> > > It seems to me that keeping SOAPAction doesn't prevent people
> > > like yourself
> > > from
> > > doing redirection/aliasing, however removing SOAPAction
> *forces* those who
> > > use
> > > generic message brokers into using redirection/aliasing or assigning a
> > > one-to-one URI->executable per service.
> > >
> > > >
> > > > The problem with SOAPAction is that it's definition and use are
> > > > fuzzy at best. You know that I lobbied for ebXML to either
> > > > not specify SOAPAction or to recommend that it be "". I haven't
> > > > changed my position.
> > > >
> > > > Having a SOAPAction of "ebXML" is so limiting that I don't
> > > > even use it.
> > >
> > > As a server implementer, that is your prerogative, but should this
> > > choice be taken away from those who see value in it?
> > >
> > > > The problem of SOAPAction in the use case of messages traversing
> > > > from one transport to another [1] is yet another reason why its
> > > > use is problematic.
> > > >
> > >
> > > There are numerous "transport binding issues" that must be
> dealt with, I
> > > would classify SOAPAction as one of the items that must be
> > > addressed in any
> > > transport binding. The SMTP binding section of ebXML's
> Message Service is
> > > one way it can be accommodated.
> > >
> > > > As to the statement:
> > > > > each SOAP service OR will be
> > > > > required to write sophisticated message brokers that have
> to parse and
> > > > > understand the structure of each SOAP message in order to dispatch
> > > > > processing to the appropriate handler.
> > > >
> > > > That is what a SOAP Processor does. There are any number of these
> > > > available which can be extended to support ebXML.
> > >
> > > The SOAP processors I'm familiar with cannot distinguish an
> ebXML request
> > > from an Apache rpcrouter request or any other type of request
> because they
> > > lack semantic knowledge of these various messages. From my
> > > observations SOAP
> > > processors only know how to validate the SOAP specific parts
> of a message
> > > (e.g. mustUnderstand, actor, structure (Envelope, Header, Body), SOAP
> > > encoding rules, etc.). The "semantic"
> > > knowledge necessary to validate and process a particular type of
> > > message is
> > > contained within a SOAP aware handler that "understands" the
> structure and
> > > semantics of a particular message.
> > >
> > > IMO, SOAPAction provides a simple means to identify the type of
> > > SOAP message
> > > contained in a message exchange. Implementers that use generic message
> > > brokers  at a Request-URI rely on SOAPACtion to provide the
> information
> > > needed to facilitate dispatching. Implementers that choose to use
> > > aliasing/redirection are free to ignore the SOAPAction header
> and use the
> > > POST-URI.
> > >
> > > IMO, the cost and impact to the generic message broker implementers
> > > resulting from the removal of SOAPAction far exceeds any
> > > perceived benefits
> > > that might be gained from its removal.
> > >
> > >
> > > Dick Brooks
> > > Group 8760
> > > 110 12th Street North
> > > Birmingham, AL 35203
> > > dick@8760.com
> > > 205-250-8053
> > > Fax: 205-250-8057
> > > http://www.8760.com/
> > >
> > > InsideAgent - Empowering e-commerce solutions
> > >
> > > > -----Original Message-----
> > > > From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> > > > christopher ferris
> > > > Sent: Tuesday, June 12, 2001 11:37 AM
> > > > To: Dick Brooks
> > > > Cc: ebXML Transport (E-mail)
> > > > Subject: Re: [Fwd: Proposals to address SOAPAction header]
> > > >
> > > >
> > > > Dick,
> > > >
> > > > You can achieve the same with the Request-URI. Setting up a unique
> > > > URI to differentiate between services is trivial. Most if not all
> > > > web servers provide aliasing so there can be but one servlet
> > > > handling requests for various URIs, using the Request-URI to do
> > > effective
> > > > dispatching to appropriate handlers.
> > > >
> > > > The problem with SOAPAction is that it's definition and use are
> > > > fuzzy at best. You know that I lobbied for ebXML to either
> > > > not specify SOAPAction or to recommend that it be "". I haven't
> > > > changed my position.
> > > >
> > > > Having a SOAPAction of "ebXML" is so limiting that I don't
> > > > even use it.
> > > >
> > > > The problem of SOAPAction in the use case of messages traversing
> > > > from one transport to another [1] is yet another reason why its
> > > > use is problematic.
> > > >
> > > > As to the statement:
> > > > > each SOAP service OR will be
> > > > > required to write sophisticated message brokers that have
> to parse and
> > > > > understand the structure of each SOAP message in order to dispatch
> > > > > processing to the appropriate handler.
> > > >
> > > > That is what a SOAP Processor does. There are any number of these
> > > > available which can be extended to support ebXML.
> > > >
> > > > Cheers,
> > > >
> > > > Chris
> > > >
> > > > [1]
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0072.html
> > > >
> > > > Dick Brooks wrote:
> > > > >
> > > > > Chris,
> > > > >
> > > > > From what I can tell, SOAPAction provides a way to distinguish one
> > > > > SOAP message from another. If there is no SOAPAction header
> > > to "tell" a
> > > > > receiver
> > > > > what type of SOAP message (e.g. ebXML) is being sent,
> > > > implementers will be
> > > > > forced to
> > > > > setup unique URI's on their web server for each SOAP service
> > > OR will be
> > > > > required to write sophisticated message brokers that have
> to parse and
> > > > > understand the structure of each SOAP message in order to dispatch
> > > > > processing to the appropriate handler.
> > > > >
> > > > > It seems to me that SOAPAction serves a useful purpose.
> > > > >
> > > > > Dick Brooks
> > > > > Group 8760
> > > > > 110 12th Street North
> > > > > Birmingham, AL 35203
> > > > > dick@8760.com
> > > > > 205-250-8053
> > > > > Fax: 205-250-8057
> > > > > http://www.8760.com/
> > > > >
> > > > > InsideAgent - Empowering e-commerce solutions
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chris.Ferris@Sun.COM
> [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> > > > > > christopher ferris
> > > > > > Sent: Thursday, June 07, 2001 11:20 AM
> > > > > > To: ebXML Transport (E-mail)
> > > > > > Subject: [Fwd: Proposals to address SOAPAction header]
> > > > > >
> > > > > >
> > > > > > List-Unsubscribe:
> > > > > >
> <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> > > > > > List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> > > > > > List-Help: <http://lists.ebxml.org/elists/admin_email.shtml>,
> > > > > >  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
> > > > > >
> > > > > > FYI, from the xml-dist-app list.
> > > > > >
> > > > > > FWIW, I supported proposal B (below), to deprecate the
> SOAPAction
> > > > > > HTTP header.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > -------- Original Message --------
> > > > > > Subject: Proposals to address SOAPAction header
> > > > > > Resent-Date: Thu, 7 Jun 2001 09:42:52 -0400 (EDT)
> > > > > > Resent-From: xml-dist-app@w3.org
> > > > > > Date: Thu, 7 Jun 2001 06:42:20 -0700
> > > > > > From: Mark Nottingham <mnot@akamai.com>
> > > > > > To: XML Distributed Applications List <xml-dist-app@w3.org>
> > > > > >
> > > > > > The W3C XML Protocol Working Group is attempting to address
> > > perceived
> > > > > > and reported problems with the "SOAPAction" mechanism
> in the HTTP
> > > > > > binding (see SOAP 1.1 Section 6.1.1 [1]). As part of
> this process,
> > > > > > the WG wishes to solicit comments and guidence on two
> proposals it
> > > > > > has generated, as below.
> > > > > >
> > > > > > Comments must go to xmlp-comments@w3.org by 2001-06-18,
> and should
> > > > > > address the proposals as they sit, and may optionally
> make general
> > > > > > comments on resolution of issues with SOAPAction. Those
> representing
> > > > > > the positions of particular groups or organisations are
> requested to
> > > > > > clearly identify themselves as such. The WG encourages
> additional
> > > > > > discussion on the xml-dist-app@w3.org mailing list.
> > > > > >
> > > > > > Neither of the following options precludes equivalent
> functionality
> > > > > > elsewhere.
> > > > > >
> > > > > > Proposal A:
> > > > > > Use of SOAPAction is discouraged. SOAPAction is an
> optional part of
> > > > > > XMLP, supported but not required. Services MAY require
> > > SOAPAction and
> > > > > > any software wishing to access those services MUST be
> able to send
> > > > > > it.
> > > > > >
> > > > > > Proposal B:
> > > > > > Use of SOAPAction is deprecated. Senders SHOULD NOT
> send SOAPAction.
> > > > > > Receivers MUST NOT accept or reject messages on the basis of the
> > > > > > presense, absence, or value of the SOAPAction header.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Mark Nottingham
> > > > > > for the W3C XML Protocol Working Group
> > > > > >
> > > > > >
> > > > > > [1] http://www.w3.org/TR/SOAP/#_Toc478383528
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mark Nottingham, Research Scientist
> > > > > > Akamai Technologies (San Mateo, CA USA)
> > >
> > >