Re: MIME marking for SOAP and XP (was text/xml for SOAP (and XP) con sidered harmful)

Editors; note the proposed DR at the bottom.

Andrew Layman wrote:
> 
> If I understand your reply "Were XP to be transport over something other
> than HTTP, a content-type parameter might not be necessary at all", you
> suggest that, when conveyed through HTTP on port 80, it is desirable to have
> some indication on a XP message that it is an XP message and not some other
> use of HTTP and XML.  (Similarly for SOAP.)  Presumably this makes life
> easier for routers and similar processors.
> 
> If so, then there seem to be at least the following mechanisms available to
> mark the message:
> 
> 1.      Use a distinguished HTTP header.
> 
> 2.      Use a distinguished MIME type.
> 
> 3.      Use a distinguished namespace on the root element of the XML
> instance.
> 
> Numbers 1 and 3, both, are already specified to be present by the SOAP 1.1
> design, and are presumably available options to XP.  Given their presence,
> what is the motivation for wanting number two in addition?

IMO, #2 is required because *current practice* is to dispatch additional
processors off a media type, not an HTTP header or an XML namespace.

To respond (belatedly) to Makoto;
> My understanding of SOAP is limited, but I am not sure if we need
> specialized media types for SOAP.  I could be wrong.
> 
> MIME headers are useful for dispatching only when you have few ideas
> about what you will receive.  If you already know that your SOAP/XP
> processor directly receives SOAP message from another SOAP/XP
> processor or a SOAP/XP proxy, MIME headers do not help dispatching.
> To the contrary, if WWW browsers may receive SOAP messages as well
> as different types of XML documents, a specialized media type for SOAP
> does help.

Exactly right.  I don't believe that we should be assuming that only XP
(or SOAP) processors will be receiving XP (or SOAP) messages.  Both XP
and HTTP processors are addressed the same way, so given an URL, one has
no way of knowing whether the processor bound to that URL can accept XP
messages or not.  I think distinguishing them by media type is safer.

> Another reason for introducing specialized media types is proxy
> servers.  If we have a specialized media type for SOAP/XP, proxy
> servers can easily take some actions for SOAP messages.  If this is
> useful, we need a specialied media type for SOAP.

Right.  I believe that we should try to ensure HTTP-only intermediaries
can participate in an XP (or SOAP) processor route (or at least not foul
it up).  Hmm, sounds like a new requirement to me;

"XP should ensure that using non-XP-aware application level
intermediaries in a chain of XP processors (e.g. an HTTP-only proxy
between XP-over-HTTP intermediaries), should not interfere with the
end-to-end contract of that chain."

MB

Received on Wednesday, 3 January 2001 12:01:05 UTC