Re: SOAPAction Proposal

While I haven't completely made my mind up about SOAPAction, I
strongly believe this option should be given consideration.

I *think* the primary objection to it is that it can't reflect
"nesting", such as a SOAP message in a MIME envelope that contains
other objects. I can imagine three ways of addressing this:

* leave it as-is; each MIME message part can have a content-type
  associated; therefore, once the message has been opened, the SOAP
  content-type is evident. This won't work if the SOAPy-ness of the
  message needs to be known before the message is de-MIMEified (solid
  use cases?)

* Use the parameter(s) on the content-type to communicate the
  SOAPy-ness. I.e.,
	Content-Type: Multipart/Related; boundary=MIME_boundary;
	  type=text/xml;
	  soap-intent="soaphints";
          start="<claim061400a.xml@claiming-it.com>"


On Wed, May 09, 2001 at 09:39:36PM -0400, Mark Baker wrote:
> I agree with Henrik that SOAPAction is akin to Content-Type (at least
> when used and documented properly 8-).  Perhaps if the media type that
> was used supported describing this extended type information, a new
> header wouldn't be necessary.
> 
> text/xml and application/xml don't include any parameter that would
> allow for this information to be carried.  I suppose we could attempt to
> updated RFC 3023 to add one, but given the other issues with using them
> (as discussed here), I suggest that using a media type of
> application/[soap|xmlp]+xml with a suitably named parameter
> ("namespace"?) may be the easiest way to go ... assuming of course, that
> SOAPAction is still unfavourable to so many.
> 
> FWIW, I'm ok with SOAPAction.  If you buy the extended type argument,
> then this discussion is about syntax.  But perhaps a syntax better
> suited to describing what SOAPAction aims to achieve isn't such a bad
> thing.
> 
> MB
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 10 May 2001 14:12:17 UTC