Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)
draft-edwards-mime-mxf-03

[Ballot discuss]
By choosing application/mxf, with no available parameters,  SMPTE is putting forward a "bucket" mime type.  These have historically created problems in low-capacity links, as clients have to download the content and examine its internal metadata before knowing if they have the capability to use the content.    See RFC 4281 for a description of this problem relative to the 3gpp and 3gpp2  audio and video sub-types.  In that case, a "codecs" parameter increased the usability of the types considerably.

I would like to ask SMPTE to consider whether one or more parameters might not increase the usability in this case as well.  Even if they were optional, those offering these MIME objects in relevant network environments could take advantage of them to enhance the user experience.  Without knowing more about the base specification, I am hesitant to suggest specific parameters, but I do note that the registration implies that a parameter capturing the Operational Pattern (OP) might be effective in this case.

GenArt review comment from David Black:

I found one minor nit - Section 3.1 uses the phrases "compressed
essence types" and "essence types".  That terminology should be
explained and the explanation should include a few specific
examples of such types.

AD evaluation comments:

"Applications which use this media type": Please identify some of the applications that use this type.  It's not enough to say that applications exist.  You need to identify some of them.

Please add a URL for the specification identified by the [SMPTE377M] normative reference to the description of the reference.

I'll last call the document once these two issues have been addressed.