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
- content-type for files with .xml extension Larry Masinter