RE: [soapbuilders] RE: [SOAP] XML Protocol: Proposals to address SOAPAction header

i think soap implementations could quite quickly be
modified to adapt to the removal of SOAPAction.

right now, some large company/consortium could publish
a "standard" WSDL for a popular service and state that
SOAPAction = "arbitrary-value-goes-here". for example,
ebXML guys could say "SOAPAction always equals ebXML".

if a SOAP server like frontier absolutely has to have
the SOAPAction set to a particular value, then it will
not be able to support services that implement this standard.

if the service was popular enough, and people wanted to 
use a SOAP server from a particular vendor to host an 
implementation, the vendor would have to adapt its 
implementation to support "arbitrary-value" or not get the 
deal. hence any SOAP server that wants to actually get used 
anywhere will have to be able to adapt to pretty much any 
SOAPAction  that any large company/consortium happens to 
pick for its WSDL, regardless of whether it happens to map 
to a method or not.

remember that the vendor of the SOAP server will have little
or no control in the future of what SOAPActions happen to
be put into a standard/shared WSDL file. it won't be the 
SOAPBuilders group being nice to each other and accomodating 
each others implementation, it will be some else saying
"here's the SOAPAction, live with it".

so to be useful, either the SOAPAction has to be some
standard, predictable value that you can rely on and
thus build your implementation around, or it should
be scrubbed and replaced with something simpler.

my 0.02.

cheers,
grahm

-----Original Message-----
From: Andrew Layman [mailto:andrewl@microsoft.com]
Sent: Thursday, June 07, 2001 8:18 PM
To: xmlp-comments@w3.org
Cc: soapbuilders@yahoogroups.com; dick@8760.com
Subject: [soapbuilders] RE: [SOAP] XML Protocol: Proposals to address
SOAPAction header


Deprecate SOAPAction or remove it entirely? I find neither of these
proposals attractive.  

SOAPAction is valuable for at least three reasons:  

1.	Its presence clearly identifies a message as being a SOAP/XMLP
message as distinct from being just a HTML POST that happens to contain
a SOAP/XMLP document.

2.	Its URI value supports the model that a SOAP/XMLP message is an
aggregate of parts, where the intent of the aggregate is not given by
any single part alone.

3.	If supports efficient processing by allowing classification and
dispatch of messages based on simple parsing of items 1 and 2.

Using a new MIME type would only address point 1.  It has the additional
problem that the conjectured MIME type does not exist.

In support of the practical nature of this points, I call your attention
to the fact that many SOAP implementations are using this today and
depending on its continued availability.  See, for example,
http://www.soapware.org/directory/4/implementations. You will notice
that a number of these detect SOAP messages by the SOAPAction header and
dispatch them based on the value.

See also the ebXML TRP specifications.

-----Original Message-----
From: Martin Gudgin [mailto:marting@DEVELOP.COM] 
Sent: Thursday, June 07, 2001 7:41 AM
To: SOAP@DISCUSS.DEVELOP.COM
Subject: [SOAP] XML Protocol: Proposals to address SOAPAction header


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 guidance 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 organizations 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
presence, absence, or value of the SOAPAction header.

Regards

Martin Gudgin
For the W3C XML Protocol Working Group

[1] http://www.w3.org/TR/SOAP/#_Toc478383528

You can read messages from the SOAP archive, unsubscribe from SOAP, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

To unsubscribe from this group, send an email to:
soapbuilders-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Received on Friday, 8 June 2001 12:52:48 UTC