Bruce, Thanks for your review. Please see comments inline. Bruce Lilly wrote:
On Thu October 20 2005 04:14, Magnus Westerlund wrote:
I would like to request review of the DLS media type documented in: http://www.ietf.org/internet-drafts/draft-westerlund-mime-dls-00.txt
First, a registration should use the template specified in RFC 2048 section 2.8 (to be replaced by draft-freed-media-type-reg in due course). Ideally, the registration template specification (e.g. RFC 2048) would be listed as an informative reference; the reference to the template need not be normative, and indeed specifying a draft as a normative reference is guaranteed to delay publication as an RFC until such time as the referenced draft is published as an RFC. In particular, the security considerations should appear in the registration template proper so that they are readily visible when the registration is viewed. Security is a vital consideration, and implementers should not have to dig around in multiple documents for security considerations; moreover, as less-than-diligent implementers will not do so, the security considerations should be explicitly spelled out in the registration template.
As the template we have been using now is published as RFC 4288 (BCP 13) the only thing needed is to update the reference.
Second, the draft states: The DLS format may contain audio, displayable text data, and modeling parameters (a.k.a. articulation parameters). In addition, the DLS format contains a so-called conditional chunk which is 'active' in the sense that it affects the execution of a DLS file parser. If the format audio content is truly optional ("may contain"), then perhaps a subtype of the application top-level type (rather than audio) would be more appropriate, particularly as some application is necessary to interpret the format ("affects the execution of a DLS file parser"). See the description of the audio top-level type in RFC 2046 section 4.3, as well as the description of the application type in section 4.5. Note that unrecognized subtypes under both types are treated as application/octet-stream, so there is no advantage to be gained w.r.t. existing MIME type handlers by specifying audio rather than application. On the other hand, i.e. if audio content is always mandatory rather than optional, the description in the draft should be revised accordingly.
The purpose of the DLS file format is to carry and specify the audio waveforms to be used in the synthesizers when rendering a MIDI performance. To my knowledge the audio waveforms are optional but will be included in almost all DLS files. The reason the waveform are optional is that in some cases the articulation parameters are the desired way of affecting the synthesizers. Thus a DLS file is always intended for an general audio rendering application and thus fits the top media type of audio.
Third, surely there must be some interoperability considerations, else there would not be separate format specifications (see also the RFC 2046 section 4.3 reference to a "general-purpose audio playing application -- is there some such application which will handle the proposed media types as well as registered audio media types; if not, registration under the application top-level type rather than audio is strongly recommended).
The intended application is any audio player capable of rendering midi using DLS. I don't understand your reasoning why any separate format would need to have an interoperability consideration. If you define new functionalities and therefore define a new format for carrying these functionalities then there are nothing previous to interoperate with other than units not-supporting the format. I think we today with the number of file formats that are existing that basic case of not supporting a specific format does not belong in each and everyone formats interoperability specification.
Finally, see the definition of Magic numbers in RFC 2048 section 2.2.9, paragraph labeled (1). As the draft identifies a byte sequence which is always present and thus can be used to identify the content, the draft text Magic number(s): None. However, the ninth to twelfth bytes of the file must equal (in hexadecimal notation) 44, 4c, 53, and 20, respectively. is self-contradictory (removing "None. " would remove the contradiction).
Yes, I agree with removing "None". Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com