MPEG asks for MIME review for the MPEG21 file format

[Graham Klyne]

Dave Singer wrote:
> I've added Christian here, who actually authored the document.
> 
> 
> At 8:50  +0100 14/05/07, Graham Klyne wrote:
>> I have a couple of comments:
>>
>> (1) the "Encoding considerations" section appears to confuse MIME
>> requirements
>> for text with encoding for transmission over non-binary channels.  A MIME
>> content transfer encoding of "Binary" would be sufficient to indicate
>> prohibition of CR/LF conversion or 7-bit stripping.
> 
> I think this text was copied from other MIME registrations.

Hmmm... no comment :)

>> (2) the subtype name -- if I recall correctly, MPEG-21 uses an XML
>> encapsulation
>> layer (MPEG21-DIDL) for assembling various subparts into a composite for
>> transmission (unfortunately, lack of a freely available online version
>> of the
>> cited document means that I can't check this).  If I am correct here,
>> then it
>> may be more appropriate to use content type name "application/mp21+xml".
> 
> Correct, the main document inside the binary archive is indeed in XML. 
> But the overall file format is binary.  Doesn't the mime type "+xml"
> suggest that the document is specialized XML only (i.e. a text document)?

Not really - as I understand it, content transfer encoding tells us about the
domain of the document.  The top-level media types make the distinction between
text and non-text (cf. RFC2046 - section 4.1.1 has specific relevant comment
about restrictions on text/... types).   Thus, I'd say the use of
application/... indicates otherwise.  As far as I'm aware, the MIME
specifications don't actually discuss CRLF conversions beyond this, though it's
implicit that for text/... the line separators would be converted from/to local
form when encoding/decoding MIME objects.

RFC 3023 (http://www.ietf.org/rfc/rfc3023.txt) describes the use of the +xml
convention, and also defines application/xml, text/xml, etc.
[[
A.15 Why must I use the '+xml' suffix for my new XML-based media type?

   You don't have to, but unless you have a good reason to explicitly
   disallow generic XML processing, you should use the suffix so as not
   to curtail the options of future users and developers.
]]

>> Also, if I recall correctly, the use of BASE64 for binary components
>> within an
>> MPEG21-DIDL XML wrapper is covered by the MPEG21 specification itself,
>> so it may
>> be quite inappropriate to suggest Base64 encoding applied at the MIME
>> level.
> 
> The file format contains the XML, and also the attached binary
> resources, outside the XML but inside the file format.  They are not
> (necessarily or normally) encoded at all.
> 
>>
>> It would be very much easier to give useful review if there was at least a
>> publicly web-accessible summary of what this content type is expected
>> to convey.
> 
> Sure.  There are brief intros at
> 
> <http://www.chiariglione.org/mpeg/mpeg-tech.htm>;  have a look at
> ISO Base Media File Format
> and specifically:
> Digital Item File Format
> 
> The base file format specification contains a lot of otehr stuff as well
> (stuff MPEG-21 doesn't use), but if you want to view it, it is freely
> available
> 
> <http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm>
> and find 14496-12

Hmmm, with a quick scan, I can't really find any material about MPEG-21 there,
which is what the registration is about.

Of course, this isn't technically required for the MIME type registration, but I
think it would help.  The wikipedia entries
(http://en.wikipedia.org/wiki/MPEG-21,
http://en.wikipedia.org/wiki/Digital_Item) are more helpful, though sketchy.

There's also:
* http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm
* http://www.dlib.org/dlib/november03/bekaert/11bekaert.html

I think that including a non-normative reference to something like these would
make the registration vastly more useful.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact