MPEG asks for MIME review for the MPEG21 file format

[Graham Klyne]

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.

(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".

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.

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.

#g
--


Stephan Wenger wrote:
> That's Dave Singer as the contact, of course.  Sorry for the typo.
> Stephan
> 
> On May 14, 2007, at 6:33 AM, Stephan Wenger wrote:
> 
>> Folks,
>> MPEG (ISO/IEC JTC1 SC29) sent us an liaison statement asking us to
>> review their draft for a MIME registration of the MPEG-21 file
>> format.  I know nothing about the subject matter, but hope some of you
>> could give them a hand.  Please direct any technical questions to Save
>> Singer of Apple, singer at apple.com <mailto:singer at apple.com>.  Below,
>> please find what I believe they want to register.  Their full liaison
>> statement (in a bunch of word files) can be found
>> here: https://datatracker.ietf.org/public/liaisons.cgi, look for
>> ISO/IEC JTC1 SC29, May 2007
>> Best regards,
>> Stephan
>>
>>> MIME media type name: application
>>> MIME subtype name: mp21
>>> Required parameters: none
>>> Optional parameters: none
>>> Encoding considerations: base64 IS generally preferred; files are
>>> binary and should be transmitted without CR/LF conversion, 7-bit
>>> stripping, etc.
>>> Security considerations: It is possible to inject non-compliant MPEG
>>> streams (Audio, Video, and Systems) in the MP21 file to overload the
>>> receiver/decoder's buffers. This might compromise the functionality
>>> of the receiver or even crash it.
>>> An MP21 file supports the storage of stream types, including commands
>>> that are executed on the terminal such as Digital Item Methods based
>>> on ECMASCRIPT for which also bindings to Java(TM) and C++ exists. It
>>> is possible to use one or more of the above in a manner non-compliant
>>> to MPEG to crash the receiver or temporarily make it unavailable.
>>> Authentication mechanisms can be used to validate of the sender and
>>> the data to prevent security problems due to non-compliant malignant
>>> MP21 files.
>>> Interoperability considerations: A number of interoperating
>>> implementations exist within the ISO/IEC 21000 community, and that
>>> community has reference software for reading and writing the file format.
>>> Published specification: ISO/IEC 21000-9:2005
>>> Applications which use this media type: Multimedia
>>> Additional information:
>>>
>>> Magic number(s): none
>>>
>>> File extension(s): mp21 and mpg21 are both declared at
>>> http://pitch.nist.gov/nics/ and http://filext.com/
>>>
>>> Macintosh File Type Code(s): mp21 is registered with Apple.
>>>
>>> Person & email address to contact for further information: David
>>> Singer, singer at apple.com <mailto:singer at apple.com>
>>> Intended usage: COMMON
>>> Author/Change controller: David Singer, ISO/IEC 21000 file format chair
> 

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