RE: [Fwd: Proposals to address SOAPAction header]

[Dick Brooks <dick@8760.com>]

Chris

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

I agree, :-)

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:28 PM
> To: Dick Brooks
> Cc: ebXML Transport (E-mail)
> Subject: Re: [Fwd: Proposals to address SOAPAction header]
>
>
> 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)