W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Proposal for dealing with issue 200: SOAPAction header vs. ac tion parameter

From: Christopher Ferris <chris.ferris@sun.com>
Date: Thu, 18 Apr 2002 08:23:13 -0400
Message-ID: <3CBEBAB1.9020703@sun.com>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: "'Mark Baker'" <distobj@acm.org>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, xml-dist-app@w3.org
-1

If you want to identify the "tarball" as a SOAP message
then this can be achieved using 2a at least for multipart/*
you would have the 'type' parameter which would have
'application/soap+xml' as its value and that would identify
the message as a SOAP message.

Cheers,

Chris

Williams, Stuart wrote:

> Hi Mark,
> 
> 
>>-----Original Message-----
>>From: Mark Baker [mailto:distobj@acm.org]
>>Sent: 18 April 2002 02:31
>>To: Henrik Frystyk Nielsen
>>Cc: xml-dist-app@w3.org
>>Subject: Re: Proposal for dealing with issue 200: SOAPAction 
>>header vs.
>>action parameter
>>
>>
> 
> <snip/>
> 
>>>2) This is the trickiest part - one of the important reasons for having
>>>a known content type is to indicate that *this* is a SOAP message. If
>>>two parties are not using a known content type then that information
>>>clearly is not there anymore. I can think of two ways to go:
>>>
>>>2.A) We leave it entirely up to the media type being used to indicate in
>>>some manner that this is a SOAP message.
>>>
>>>2.B) We maintain the SOAPAction in some manner (for example in an
>>>appendix) that allows is to be used with content types other than
>>>"application/soap+xml" indicating that this is a SOAP message.
>>>
>>Right.
>>
>>I don't believe that we can rule out 2A in the future, so I think the
>>answer is both.  For now, IMO that means taking action on 2B to soften
>>up the wording about recommending that SOAPAction not be required.
>>
> 
> The presense of a SOAPAction header to signify that whatever 'tarball' there
> might be in the HTTP message body contains a SOAP message seems like a good
> idea. It would provide a means to do this independent of content-type, which
> also seems like a good idea, particularly in the light of the use of the
> Content-Type: Multipart/Related by SOAP with Attachments. I don't think that
> we can just go adding parameters like "action" that pre-existing
> media-types.
> 
> I don't think that the presense of SOAPAction has ever be controvertial as a
> means to indicate that an HTTP body contains a SOAP message, however it
> happens to be wrapped.
> 
> The piece that is/was controvertial, was the significance of the action
> value carried in the SOAPAction header. IIRC the intent of the resolution
> [1] was to ensure that the value carried in SOAPAction header be regarded as
> a 'hint' and that correct operation at a recipient *not* be dependent on SA
> being set correctly - but it could be used to optimise message processing.
> 
> I think a proposal for a header whose sole purpose is to signify the
> presense of a SOAP message could be successful. I think that a proposal that
> seeks to attribute more significance to the action value than its current
> significance as a hint will be problematic in the light of [1].
> 
> Personnally, I think that the SOAPAction header as currently specified does
> what it does on a way that is independent of the media-type.
> 
> If I were going to choose one mechanism I'd stick with the SOAPAction header
> that we currently have. However, I may be that I have not understood the
> merits of moving it being a parameter of the media-type - that seems to
> restrict the leverage of existing media types.
> 
> I can see the worms beginning to wriggle as I look inside the can :-)
> 
> <snip/>
> 
>>MB
>>-- 
>>Mark Baker, Chief Science Officer, Planetfred, Inc.
>>Ottawa, Ontario, CANADA.      mbaker@planetfred.com
>>http://www.markbaker.ca   http://www.planetfred.com
>>
> 
> Regards
> 
> Stuart
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Sep/0091.html
> 
> 
> 
Received on Thursday, 18 April 2002 08:24:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT