Review of DLS media type

Bruce Lilly blilly at erols.com
Sun Dec 11 16:26:30 CET 2005


On Thu October 20 2005 04:14, Magnus Westerlund wrote:
> Hi,
> 
> 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
> 
> Thanks
> 
> 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

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.

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.

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).

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).


More information about the Ietf-types mailing list