- From: Mark Baker <distobj@acm.org>
- Date: Wed, 17 Apr 2002 21:30:38 -0400
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Cc: xml-dist-app@w3.org
Henrik, On Tue, Apr 16, 2002 at 09:13:09AM -0700, Henrik Frystyk Nielsen wrote: > 1) Should we both have a SOAPAction header field *and* an > "application/soap+xml" media type "action" parameter? > > 2) Given the discussion of issue 197 [3], what happens if the media type > is *not* "application/xml+soap" (either directly or indirectly in some > nested manner)? > > 3) We have a general issue with the dependency between the SOAP 1.2 spec > and the media type draft. I consider this an editorial issue but it > should be made clear. > > 4) Where can I find the resolution text for what SOAPAction header field > means? > > Proposal > -------- > > 1) I would say that we should only have it in one place and like the > direction of moving it entirely into the media type definition as a > parameter. Agreed. > 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. > 3) The spec editors should add a note to the spec that we know that this > is an ID with no standing. I guess that will suffice for last call. We should revisit later. > 4) This was carefully put together as the resolution [6] of issue 95 > [5]. While some of the details regarding the status codes used will be > changed slightly as a result of it being a media-type parameter, and > that its value can't be relative, the overall resolution still stands. Thanks! I'll incorporate that. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Wednesday, 17 April 2002 21:24:09 UTC