- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Thu, 18 Apr 2002 08:23:13 -0400
- 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 UTC