content-type for files with .xml extension

"Larry Masinter" <LMM@acm.org> Sat, 09 June 2007 02:58 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (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 owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l592wLrb042795; Fri, 8 Jun 2007 19:58:21 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from exprod6og51.obsmtp.com (exprod6og51.obsmtp.com [64.18.1.183]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l592wGfk042745 for <ietf-xml-mime@imc.org>; Fri, 8 Jun 2007 19:58:19 -0700 (MST) (envelope-from LMM@acm.org)
Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Fri, 08 Jun 2007 19:58:15 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l592wBWs029891; Fri, 8 Jun 2007 19:58:11 -0700 (PDT)
Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l592uvI9025944; Fri, 8 Jun 2007 19:56:57 -0700 (PDT)
Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 19:58:10 -0700
Received: from masinterlap06 ([10.7.241.252]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 19:58:09 -0700
From: Larry Masinter <LMM@acm.org>
To: 'Michael Good' <musicxml@yahoo.com>, 'Mark Baker' <distobj@acm.org>, 'Bjoern Hoehrmann' <derhoermi@gmx.net>
Cc: ietf-xml-mime@imc.org
References: <e9dffd640706080716k3b5db505ie5ab134cb4b0cb79@mail.gmail.com> <452496.17829.qm@web90411.mail.mud.yahoo.com>
In-Reply-To: <452496.17829.qm@web90411.mail.mud.yahoo.com>
Subject: content-type for files with .xml extension
Date: Fri, 08 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 balder-227.proper.com id l592wLfk042788
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=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
.)


Larry


-----Original Message-----
From: ietf-types-bounces@alvestrand.no
[mailto:ietf-types-bounces@alvestrand.no] On Behalf Of Michael Good
Sent: Friday, June 08, 2007 9:53 AM
To: Mark Baker; Bjoern Hoehrmann
Cc: ietf-types@alvestrand.no
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
DTDs
are the specification. We are of course aware of the desirability of a
separate
specification document, but Recordare is a small commercial company in a
small
market. We do hope to get a specification document out for 2.0 later this
year,
but it will not be ready for MusicXML 2.0's initial release later this
month. 

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
adequately
(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
1.0
and 1.1 files can use the application/vnd.recordare.musicxml+xml media type.

Thank you for the suggestion about adding information to the
interoperability
considerations section. The draft now reads "As all MusicXML 1.0 and 1.1
files
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.
One
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
www.recordare.com



       
____________________________________________________________________________
________
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469