Re: text/xml for SOAP is incorrect

This presupposes the necessity of reflecting the message's namespaces
in the content-type; why is this necessary? Defining a content-type
always involves a tradeoff in the granularity of information
available. IIRC, the discussion you reference was in the context of
replacing SOAPAction with something in the content-type, which is not
the intent here (based upon our resolution of issue 95).

application/soap+xml says, roughly; 

  This is a format that isn't really interesting for humans to read,
  as it's intended for machines.  It follows the 'SOAP' format, which
  happens to be based upon xml.

IMHO this is about the amount of information that's appropriate. I'd
also be happy with application/soap. 

Cheers,



On Tue, Sep 18, 2001 at 02:18:38PM -0700, Henrik Frystyk Nielsen wrote:
> 
> I completely agree with Jacek's concerns about the assumptions behind
> "+xml".
> 
> It was my understanding that last time (Dec 2000) this issue was
> discussed at length [1], it was pointed out that the notion of "+xml"
> does not match well with SOAP messages which in all interesting
> scenarios will be composed by multiple namespaces.
> 
> Unless this has been addressed (which I am not aware of) it seems
> premature to claim that "application/soap+xml" is a reasonable approach.
> 
> Henrik
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0152.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0198.html
> 
> >I've skimmed through appendix A of RFC 3023 and I feel like it 
> >is based on the assumption that most MIME dispatchers will be 
> >upgraded or built to support this +xml thingie. On the other 
> >hand the RFC is very opposed to other, more general ways like 
> >for example A.5 or A.7 (section of the appendix A), while 
> >these approaches would require about the same level of support 
> >in MIME dispatchers as the +xml suffix.
> >
> >I'd be OK either with application/xml for SOAP or with 
> >something like A.5(A.7) in a new release of MIME spec RFCs.
> 

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

Received on Tuesday, 18 September 2001 17:50:44 UTC