Review of DLS media type

[Magnus Westerlund]

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 at ericsson.com