- From: Roy T. Fielding <fielding@ebuilt.com>
- Date: Thu, 17 Jan 2002 15:18:13 -0800
- To: Keith Moore <moore@cs.utk.edu>
- Cc: "Simon St.Laurent" <simonstl@simonstl.com>, www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net
On Thu, Jan 17, 2002 at 05:36:15PM -0500, Keith Moore wrote: > > It would be difficult for such a thing to happen without the IETF, but > > making changes to MIME of any fundamental sort is intensely difficult. > > Despite the work I put into RFC 3023, and the very rough consensus we > > managed to achieve there, I think XML is demonstrating the limitations > > of MIME on a regular basis. > > that's a pretty bizarre statement. perhaps it's truer to say that XML > is trying to misuse MIME on a regular basis? Right. I don't think XML is a media type, for the same reason that SGML is not a media type. [I know both are registered -- they are simply never used correctly in the generic form.] > or that expecting the MIME content-type to convey the action that > should be performed by a recipient, rather than a description of > the content, is a bit of a mis-application of MIME? That's not always true. MIME uses the content-type to indicate what type of handler should be selected for the message body. The same content can be sent for different purposes by using different media types. E.g., image/jpeg vs application/octet-stream, multipart/alternative vs multipart/mixed, etc. > the fact that XML picked a means of labelling content that is > incompatible with MIME's content-type is hardly MIME's fault. I think the mistake is in assigning such messages a type that implies it should be handled by a generic XML processor. There is no such thing, even though it is possible to view all XML types via generic XML tools. A more architecturally fitting course of action would be to create a top-level media type of xml and then have xml/* subtypes, but for some reason (deployed apps, I presume) the top-level namespace has been frozen for ages. ....Roy
Received on Thursday, 17 January 2002 18:23:42 UTC