Re: SOAP MIME Type

Hi Noah,

This discussion happens to be taking place on dist-app because of SOAP
1.1's use of text/xml and the resulting problems, not because it's an
issue specific to SOAP.

I don't think the intent here is to mimic what many people want to use
SOAPAction for (that is, to identify a purchase order, for example, inside
a SOAP message). Rather, it's merely to fix what some people in the XML
community see as an impediment to the use of XML to describe new formats
on the Web.

XML allows decentralized formats to be described; that is, I can create a
purchase order format with associated namespace, schema, etc. without
using a central registry*. However, to make that format a first-class
citizen on the Web (e.g., to negotiate for that format and properly
dispatch messages when they arrive at agents), I need to go to IANA and
register a media type for it. For many in the XML community, IETF's and
IANA's processes are confusing and opaque; although there are efforts[1]
underway to revise that process, I think it's legitimate to ask why
central registration is required at all.

I do agree that choosing the identifier for a format should be done
carefully, and may not always correspond with the root QName (RSS 1.0 is
an excellent example). I also agree that there may be multiple ways to
identify a document, but I think the areas of interest here are those
outlined above.

* except for DNS, obviously; one of the reasons that the Web succeeded is
that URIs leveraged DNS so that no central registry beyond that was
necessary.

1. http://www.ietf.org/internet-drafts/draft-freed-mime-p4-00.txt


> Not wanting to overcomplicate this, but I have felt for some time that
the
> current MIME type system is way too limited to do what we may be about
to
> ask of it.  For example, consider a purchase order in a SOAP envelope.
> Before we get to assigning it a type, let's ask what is it?   Well, in
> some fundamental sense, it's a purchase order.  Note that you can't find
> that out from the root QName.  Of course, it's equally fundamentally a
> SOAP message. And it's an XML document.  And it's, by the way, a UTF 8
or
> UTF-16 encoding of Unicode.  If it has a routing header it's also  a
> "routable message".
>
> I honestly view the natural semantics of these things as more of a
"mixin"
> sort of model.  It seems to me that we keep trying to take little slices
> through this mixin space, and then we always find out we need something
> else.  I have no constructive suggestions for exactly what to do,
> organizationally or technically, except that I think it might be useful
to
> step back and gather some requirements and use cases before inventing
new
> mechanisms.
>
> I don't want to cross-post, but David you are welcome to relay this or
> point it out to the TAG if useful.  Both lists are public.  Thanks.

Received on Monday, 12 May 2003 15:25:21 UTC