The Codecs Parameter for "Bucket" Media Types
draft-gellens-mime-bucket-04

Reply to the IANA request for clarification:  the 4 Media Types currently getting this parameter
do not need to have the template added to the registry.  (But it's an interesting question).

[Ballot comment]
!! Missing citation for Informative reference:
  P011 L014:    [3GPP-Codecs] TS 26.234, Third Generation Partnership Project

!! Missing citation for Informative reference:
  P011 L009:    [AMR] Sjoberg, J., M. Westerlund, A. Lakaniemi, Q. Xie, "Real-Time

!! Missing Reference for citation: [KEYWORDS]
  P003 L033:    [KEYWORDS].

IANA Comments:
Upon approval of this document the IANA is requested to add "Codecs" as an optional parameter to the media types audio/3gpp, audio/3gpp2*, video/3gpp and video/3gpp2* (* registration still pending).

For all media types defined in RFCs, the IANA points to the RFC to locate the registration template.  Should IANA add this document as a reference to the above mentioned media-types?  Will this be sufficient or is it necessary for a registration template also to be placed in the registry for these 4 MIME Media Types?  Please clarify.

[Ballot discuss]
Section 3, 4 and 5 seem inconsistent.  Section 3 defines a namespace
for ISO file formats.  Section 4 says that this parameter requires new
namespace definitions for namespaces that are not ISO file formats.
Section 5 uses examples that are not consistent with the mp4a and mp4v
defined in section 3.

If the 3gpp file formats are ISO files in the sense of section 3, then
section 3 should be expanded to define the necessary namespace entries
to make section 5 legal.  If the 3gpp files do not use the ISO
namespaces (as I suspect) then this document needs to define the
namespace they use.  In either case the examples need to be consistent
with the result.

[Ballot comment]
While I agree with Russ's comment, I am not sure that this document
(or any single document) should make the call for which to give precedence
for all systems.  For some systems, getting a bucket mime type with wrong codecs
information may cause the system to throw an error; for others, if the codecs
indicated by the parameter are wrong but the ones inside are usable, other systems
may choose to render the content.  As I read the document it sounds like
MAY choose to render based on the internal codecs or MAY choose to respond
with an error is about all you could say.  There really isn't a way to render based
on the external codec parameter if the internal data isn't in that form.

[Ballot discuss]
This specification is needed.  However, it needs to say what an
  implementation ought to do if the MIME parameter contradicts
  media content header information.  Does the media content header
  information take precedence?

[Ballot comment]
Editorial comments from Gen-ART review by Mary Barnes:

- Section 2, page 4: The paragraph starting with "Specifically," isn't grammatically correct at all.  I would suggest changing the "Specifically," to "This document specifically supports the following:"  and then replacing the "." with "," in the first three bullets and placing an "and" at the end of the third bullet.  Also, the identation for the first bullet is incorrect.

Per Fröjdh: The intention of this paragraph is not to say what the document supports, but to indicate the dimension of the current situation that the document addresses and resolves. The intention is to give specific examples: "Specifically, X can contain a, b or c. Y can contain d, e or f" etc.  Although I'm not an native speaker of English, I believe the paragraph would be grammatically correct by just making the suggested replacements of "." with "," and adding the "and".

- Section 3, page 5, first paragraph, last sentence is a bit awkward and inconsistent with sectin 4: I would suggest to simplify that sentence as "Future types which contain ambiguity are strongly encouraged to include this parameter." The normative inclusion of the parameter is appropriately addressed in section 4. If you feel it's important to discuss optionality in this section of the doc, then that last sentence should be modeled after section 4; e.g. "For future media types the parameter may be optional or required, as appropriate."

- Section 3, page 5, third paragraph under "Parameter value":  "An element MAY includes..." should be "An element MAY include..."

- Section 5, there's a missing double quote in the "Note:" section.

Finished ietf-types review:  no comments on the list.

My comments - email to go out.

Why are the codec name strings from the MPEG4 registry? or only from there?
MIME registry suggests using MIME registered codec namespace. 
Even if the MPEG4 namespace remains here, should it not be provided in a
more durable form than a url?
The strings can include codec parameters as well as the codec type - this is
beyond the amount of optimization that should be here.  The idea is to give a
hint as to whether to open the object, not give all the codec information without
requiring the file object to be opened.
IANA instructions aren't clear enough.