Re: text/xml for SOAP (and XP) considered harmful

From: Mark Baker <mark.baker@canada.sun.com>
Subject: Re: text/xml for SOAP (and XP) considered harmful
Date: Mon, 18 Dec 2000 12:22:57 -0500

> FWIW, I was the one who proposed using a "namespace" attribute on a
> */xml media type to Makoto, Simon, and Dan (and Larry too) a few months
> ago.  Unfortunately, that discussion was held in private and therefore
> not archived.  I also do not recall the reasoning given for its
> rejection.

The rest of this mail is quoted from the latest I-D, which will become 
a Proposed Standard very soon.


A.5 Why not use a MIME parameter to specify that a media type uses XML
    syntax?

   For example, one could use "Content-Type: application/iotp;
   alternate-type=text/xml" or "Content-Type: application/iotp;
   syntax=xml".

   Section 5 of [RFC2045] says that "Parameters are modifiers of the
   media subtype, and as such do not fundamentally affect the nature of
   the content". However, all XML-based media types are by their nature
   always XML. Parameters, as they have been defined in the MIME
   architecture, are never invariant across all instantiations of a
   media type.

   More practically, very few if any MIME dispatchers and other MIME
   agents support dispatching off of a parameter. While MIME agents on
   the receiving side will need to be updated in either case to support
   (or fall back to) generic XML processing, it has been suggested that
   it is easier to implement this functionality when acting off of the
   media type rather than a parameter. More important, sending agents
   require no update to properly tag an image as "image/svg+xml", but
   few if any sending agents currently support always tagging certain
   content types with a parameter.


A.6 How about labeling with parameters in the other direction (e.g.,
    application/xml; Content-Feature=iotp)?

   This proposal fails under the simplest case, of a user with neither
   knowledge of XML nor an XML-capable MIME dispatcher. In that case,
   the user's MIME dispatcher is likely to dispatch the content to an
   XML processing application when the correct default behavior should
   be to dispatch the content to the application responsible for the
   content type (e.g., an ecommerce engine for
   application/iotp+xml[RFC2801], once this media type is registered).

   Note that even if the user had already installed the appropriate
   application (e.g., the ecommerce engine), and that installation had
   updated the MIME registry, many operating system level MIME
   registries such as .mailcap in Unix and HKEY_CLASSES_ROOT in Windows
   do not currently support dispatching off a parameter, and cannot
   easily be upgraded to do so. And, even if the operating system were
   upgraded to support this, each MIME dispatcher would also separately
   need to be upgraded.

A.7 How about a new superclass MIME parameter that is defined to apply
    to all MIME types (e.g., Content-Type: application/iotp;
    $superclass=xml)?

   This combines the problems of Appendix A.5 and Appendix A.6.

   If the sender attaches an image/svg+xml file to a message and
   includes the instructions "Please copy the French text on the road
   sign", someone with an XML-aware MIME client and an XML browser but
   no support for SVG can still probably open the file and copy the
   text. By contrast, with superclasses, the sender must add superclass
   support to her existing mailer AND the receiver must add superclass
   support to his before this transaction can work correctly.

   If the receiver comes to rely on the superclass tag being present
   and applications are deployed relying on that tag (as always seems
   to happen), then only upgraded senders will be able to interoperate
   with those receiving applications.

A.8 What about adding a new parameter to the Content-Disposition header
    or creating a new Content-Structure header to indicate XML syntax?

   This has nearly identical problems to Appendix A.7, in that it
   requires both senders and receivers to be upgraded, and few if any
   operating systems and MIME dispatchers support working off of
   anything other than the MIME type.

A.9 How about a new Alternative-Content-Type header?

   This is better than Appendix A.8, in that no extra functionality
   needs to be added to a MIME registry to support dispatching of
   information other than standard content types. However, it still
   requires both sender and receiver to be upgraded, and it will also
   fail in many cases (e.g., web hosting to an outsourced server),
   where the user can set MIME types (often through implicit mapping to
   file extensions), but has no way of adding arbitrary HTTP headers.

A.10 How about using a conneg tag instead (e.g., accept-features:
     (syntax=xml))?

   When the conneg protocol is fully defined, this may potentially be a
   reasonable thing to do. But given the limited current state of
   conneg[RFC2703] development, it is not a credible replacement for a
   MIME-based solution.

   Also, note that adding a content-type parameter doesn't work with
   conneg either, since conneg only deals with media types, not their
   parameters. This is another illustration of the limits of parameters
   for MIME dispatchers.


Cheers,

<warning>Speaking for himself only</warning>

IBM Tokyo Research Lab / International University of Japan, Research Institute
MURATA Makoto (FAMILY Given)

Received on Monday, 18 December 2000 22:28:54 UTC