The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types
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' **)
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' **)
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' **)
#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?