Re: text/xml for SOAP is incorrect

At 11:18 AM 9/17/2001 -0700, John J. Barton wrote:
>With all respect to the authors of RFC 3023 (XML Media Types),
>binding behavior to representations of Web resources is not
>at good engineering direction for Web technologies[1]

Fielding's criticisms of MIME types in an HTTP context are generally sensible:
>HTTP inherited its message syntax from MIME [47 ]in order to retain 
>commonality with other Internet protocols and reuse many of the 
>standardized fields for describing media types in 
>messages.Unfortunately,MIME and HTTP have very different goals,and the 
>syntax is only designed for MIME 's goals.
>
>In MIME,a user agent is sending a bunch of information,which is intended to be
>treated as a coherent whole,to an unknown recipient with which they never 
>directly interact. MIME assumes that the agent would want to send all that 
>information in one message,since sending multiple messages across Internet 
>mail is less efficient. Thus, MIME syntax is constructed to package 
>messages within a part or multipart in much the way postal carriers wrap 
>packages in extra paper.
 >
>...The problem with MIME syntax is that it assumes the transport is 
>lossy,deliberately corrupting things like line breaks and content 
>lengths.The syntax is therefore verbose and inefficient for any system not 
>based on a lossy transport,which makes it inappropriate for HTTP. Since 
>HTTP/1.1 has the capability to support deployment of incompatible 
>protocols,retaining the MIME syntax won 't be necessary for the next major 
>version of HTTP,even though it will likely continue to use the many 
>standardized protocol elements for representation metadata. (Page 134.)

However, we are not yet at "the next major version of HTTP", nor does it 
seem that abusing the current understanding of MIME types for no particular 
reason is a worthy endeavor.

>A SOAP message is text: it can be read with text tools and
>it is encoded as XML so XML parsers can study it and parse
>further information without hints.

That is not the understanding the IETF has about the use of text/ top-level 
types.  Text is expressly for human-readable usages.  There were a number 
of participants on ietf-xml-mime who wanted text/xml struck from 3023 
entirely, and I have to admit that I would support such action.

>There should not be a
>different media type for XML sent to an "application"
>verses one sent to a "browser" (which is just another
>application).  The server should not assume the use of
>the media representation.

The server should label the content it sends to the client to the best of 
its ability.  In this case, I would argue that text/xml is at best a 
cop-out, at worst a lie.

>Therefore application/xml is not necessary.  I suppose it
>may be to late to turn back from that.  But let us not go
>further down the path to application/soap+xml,
>application/soap_for_ecommerce+xml,
>application/soap_for_book_buying+xml
>application/soap_for_book_buying_and video_buying+xml, etc.
>Content-type should describe the media type, not its use,
>or provide other information that is elsewhere.

I'll settle quite happily for application/soap+xml, and the rest you can 
sort out within SOAP, thanks.

Simon St.Laurent
Associate Editor
O'Reilly & Associates, Inc.

Received on Monday, 17 September 2001 14:45:34 UTC