Re: [Fwd: Proposals to address SOAPAction header]

[christopher ferris <chris.ferris@east.sun.com>]

Dick,

Please see my comments below.

Cheers,

Chris

Dick Brooks wrote:
> 
> 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.

I think that the same would be true w/r/t SOAPAction. There must be
some administrative binding made between SOAPAction URI value and
the appropriate SOAP handler. Why would this be any different?

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

I don't see how you can draw this conclusion.

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

True, but since SOAPAction is not a specified MIME header, it should be
x-SOAPAction in a SMTP binding, no? But my point remains as regards to
other bindings which may not have any provision for carrying something
of this nature.

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

Precisely. The mapping of these handlers is based on the namespace
and/or namespace-qualified element name (qname) of the header/body 
extension(s).

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

How does this handle the case where say an ebXML SOAP message has
additional extensions such as SAML or XACML? Does the ebXML processor
"know" how to handle these? How would this be communicated via SOAPAction?
ebXML+SAML+XACML ?

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

I guess we'll have to agree to disagree on this point.

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