ietf-xml-mime
[Top] [All Lists]

Re: application/xml in ietf-xml-guidelines

2002-04-17 13:28:28

I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and
saw this;

  "The "application/xml" media type is most appropriate for general
   XML; [...]"

I have three concerns about it.  In descending order of priority;

"application/xml" (and text/xml for that matter) do not have any
specified namespace dispatch behaviour.  

depending on what you mean by "dispatch", neither, really, does 
any other content-type.  in particular, content-types don't specify 
anything about presentation or processing; these decisions are up 
to the recipient.  

this wasn't so clear at the time that MIME was designed because
it was assumed to be for interpersonal email - hence there's a 
lot of language in the MIME spec about default presentation 
behaviors.  these days we're using MIME for many other applications
than interpersonal messaging, so we don't assume a priori that
just because a bit of content is encapsulated in MIME that it's
going to be presented to some recipient as if it were an email
message.  (for that matter, we no longer assume that something sent
via SMTP is intended for human consumption either)

we really ought to make this clearer when we update the MIME spec.

That is, if I send some
XHTML as application/xml, the recipient agent doesn't know whether I
want it displayed as XHTML, or in some tree like XML format, nor do
I have any expectation of what the agent might do with it.  According
to RFC 3023, both behaviours are fine, and IMO this makes
"application/xml" less suitable than believed as a generic type.  

it makes application/xml neither more or less suitable - no type 
should be expected to dictate behavior.

Also, I believe that "text/xml" should be explicitly not recommended,
due to the text/plain fallback of all text/* types.  

if it's just a fallback behavior, why does it matter much?
actually "display as text" is probably a better fallback for XML 
than for HTML - XML generally seems to be more readable than HTML :)

Lastly, there's no mention of the RFC 3023 "+xml" suffix convention,
which should at least be mentioned as a possibility for use.  

agreed.

I believe
that my first point above highlights a large part of the value of
specific media types (whether +xml is used or not), as the required
dispatch behaviour can be assigned to them.

we need to be careful about how we use the word "dispatch" -
it's used to distinguish different types from one another,
but not to actually specify the processing to be performed.

Plus, FWIW, I'm in the "don't use URNs" camp.

nobody's perfect :)

Keith