The Codecs Parameter for "Bucket" Media Types
RFC 4281

Note: This ballot was opened for revision 04 and is now closed.

(Ted Hardie) Yes

Comment (2005-05-24 for -)
No email
send info
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.

(Allison Mankin) Yes

(Brian Carpenter) No Objection

Comment (2005-05-20 for -)
No email
send info
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.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

Comment (2005-05-24 for -)
No email
send info
The reference to RFC 2234 could be updated to point to draft-crocker-abnf-rfc2234bis instead.  It's in the RFC Editor queue.

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

Comment (2005-05-26 for -)
No email
send info
!! 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].

(Alex Zinin) No Objection