The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types
RFC 6381

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

(Pete Resnick) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2011-07-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
If a codecs parameter could cause a device to automatically
download code that could be (and has been) a vector for
malware installation. I think that'd be worth noting in the
security considerations since the abstract says that you
might react that way.

(David Harrington) No Objection

(Russ Housley) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-07-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
It's not good to place normative text into ABNF comments, so please move these directives to real paragraphs:

                  ; Parsers MAY ignore <language>
                  ; Parsers MAY support only US-ASCII and UTF-8

Does the text "Parsers MAY support only US-ASCII and UTF-8" actually mean "Parsers MUST support US-ASCII and UTF-8 but MAY support other encodings"? If so, please add a normative reference to RFC 3629 for UTF-8.

Nothing in the text explains why Section 3.4 is included.

http://tools.ietf.org/tools/bap/abnf.cgi reports several errors in the ABNF.

I concur with the feedback provided by Robert Sparks and Sean Turner.

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-07-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
#1) Section 3.1 & 4.2 contains the following:

   This parameter is optional in all current types to which it is added.

shouldn't it be "OPTIONAL"?

#2) Section 3.1 contains the following:

  Future types that contain ambiguity are strongly encouraged to
   include this parameter.

Could we strengthen this to say "are RECOMMENDED"?

#3) Section 3.1 and 4.2 contains the following:

   An element MAY include an octet that [RFC2045] REQUIRES to be
   encoded.

REQUIRES isn't 2119 language and I'm not sure you meant to use it here.  I think you can probably lower case this because it's a requirement from 2045.

#4) Section 3.5 contains the following:

   For existing media types, it is generally advisable for
   the parameter to be optional; for new media types, the parameter MAY
   be optional or required, as appropriate.

Shouldn't optional be OPTIONAL?

#5) Section 4.3 contains the following:

   The 'profiles' parameter is an optional parameter that indicates one
   or more profiles to which the file claims conformance.

Shouldn't it be OPTIONAL?