content-type for files with .xml extension

"Larry Masinter" <> Sat, 09 June 2007 02:58 UTC

Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id l592wL5B042798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2007 19:58:21 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id l592wLrb042795; Fri, 8 Jun 2007 19:58:21 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with SMTP id l592wGfk042745 for <>; Fri, 8 Jun 2007 19:58:19 -0700 (MST) (envelope-from
Received: from source ([]) by ([]) with SMTP; Fri, 08 Jun 2007 19:58:15 PDT
Received: from ([]) by (8.12.10/8.12.10) with ESMTP id l592wBWs029891; Fri, 8 Jun 2007 19:58:11 -0700 (PDT)
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id l592uvI9025944; Fri, 8 Jun 2007 19:56:57 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 19:58:10 -0700
Received: from masinterlap06 ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 19:58:09 -0700
From: "Larry Masinter" <>
To: "'Michael Good'" <>, "'Mark Baker'" <>, "'Bjoern Hoehrmann'" <>
Cc: <>
References: <> <>
In-Reply-To: <>
Subject: content-type for files with .xml extension
Date: Fri, 8 Jun 2007 19:58:09 -0700
Message-ID: <009701c7aa42$02e84b50$08b8e1f0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acep7YLKpe/DlP7bTDm0o1Z/fscfdgAUz6yg
Content-Language: en-us
X-OriginalArrivalTime: 09 Jun 2007 02:58:09.0876 (UTC) FILETIME=[0307E140:01C7AA42]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id l592wLfk042788
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

I think this is a topic for xml-mime more than ietf-types -- there's
a discussion about using the .xml file extension for an XML mime type.

Just a random thought: could we define a standard processing instruction for
XML bodies? 

<?MIME content-type="application/vnd.recordare.musicxml+xml"?>

It seems a pretty clear 'processing instruction', because you're instructing
the MIME receiver how to process the content.

I know there's been some aversion to using the namespace of the
root element as an indicator of content-type, although I'm not entirely
sure why XML MIME registrations shouldn't include the expected
namespace, too, or, in lieu of other information, the namespace
shouldn't be used to determine the MIME type (in servers or FTP; the
content-type header should be authoritative for MIME bodies


-----Original Message-----
[] On Behalf Of Michael Good
Sent: Friday, June 08, 2007 9:53 AM
To: Mark Baker; Bjoern Hoehrmann
Subject: Re: Review requested for MusicXML media type proposals

Dear Mark and Björn,

Thank you for your comments!

For MusicXML 1.0 and 1.1, there is no separate specification document. The
are the specification. We are of course aware of the desirability of a
specification document, but Recordare is a small commercial company in a
market. We do hope to get a specification document out for 2.0 later this
but it will not be ready for MusicXML 2.0's initial release later this

That is why the specification section of the registrations points to the DTD
index. For now, the DTDs are the specification, and that has worked
(if not ideally) in practice. 

For the compressed format, the container format will be described in the
container.dtd file. I will add a note to the specification section that "The
zip-based container format is described in the container.dtd file."

There have been no MusicXML-specific MIME types registered in the past. Most
servers probably use the application/xml type. It is intended that MusicXML
and 1.1 files can use the application/vnd.recordare.musicxml+xml media type.

Thank you for the suggestion about adding information to the
considerations section. The draft now reads "As all MusicXML 1.0 and 1.1
are valid MusicXML 2.0 files, this media type may be used by files in these
earlier versions of the MusicXML format." Does that seem appropriate?

All MusicXML software to date uses and relies on the .xml suffix, so that
cannot change. If we were starting off new, we would have more flexibility.
benefit of the compressed format is that we can add our own special .mxl
suffix, which over time will help the usability of these files.

Best regards,

Michael Good
Recordare LLC

Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.