The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types
draft-gellens-mime-bucket-bis-09

[Ballot discuss]
1) cleared


2) It would help to describe what "profile" means, and disambiguate the kinds of profiles that are already encoded in the codecs values from the kinds of profiles this parameter is intended to talk about.

3) cleared

[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 5-Jul-2011 raised several
  concerns with the RFC 2119 language, ABNF, and IANA considerations.
  Please respond to this review, which can be found at:

  http://www.ietf.org/mail-archive/web/gen-art/current/msg06490.html

[Ballot comment]
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.

[Ballot comment]
It's not good to place normative text into ABNF comments, so please move these directives to real paragraphs:

                  ; Parsers MAY ignore
                  ; 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.

[Ballot discuss]
1) The document states that if the codecs parameter is lost, the information it contained can be found in the body - adding it to the Content-Type header field is essentially an optimization. Futher, if the information in the body contradicts the information in the codecs parameter, the information from the codecs parameter is discarded. I'm not seeing the same statements for the profile parameter. So:

Is it true that the information that is intended to be captured in the profile parameter is always already available in the body? If so, text analogous to what exists for the codecs parameter needs to be added to the draft. I would also encourage text making it even clearer to someone wanting to use these two parameters that it must be the case that the body can be correctly interpreted if the parameter values are lost.

If it's not true that the information intended for the profile parameter value is already available in the body, the draft needs to explore the ramifications of minting new parameter values more explicitly.


2) It would help to describe what "profile" means, and disambiguate the kinds of profiles that are already encoded in the codecs values from the kinds of profiles this parameter is intended to talk about.

3) How should a recipient treat a Content-Type header field value that has both a codecs and profile parameter that are inconsistent with each other?

[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 5-Jul-2011 raised several
  concerns with the RFC 2119 language, ABNF, and IANA considerations.
  Please respond to this review, which can be found at:

  http://www.ietf.org/mail-archive/web/gen-art/current/msg06490.html

[Ballot comment]
#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?

[Ballot discuss]
If you're adding this an optional parameter to media types defined in RFCs aren't you updating those RFCs?  This would adding "Updates: 3839, 4339, and 4393 (once approved)" to the header.

Please add a section that lists the differences between RFC 4281 and this draft.  This will greatly aid implementers.

IANA understands that there is one action required to be completed upon
approval of this document.

A reference to this document is to be added to each of the following
media types:

In the audio media types registry located at:

http://www.iana.org/assignments/media-types/audio/index.html

audio/3gpp
audio/3gpp2
audio/mp4

In the video media types registry located at:

http://www.iana.org/assignments/media-types/video/index.html

video/quicktime
video/3gpp
video/3gpp2
video/mp4

In the application media types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

application/mp21
application/mp4

IANA understands that this is the only IANA action that needs to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Codecs and Profiles Parameters for "Bucket" Media Types) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Codecs and Profiles Parameters for "Bucket" Media Types'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Several MIME type/subtype combinations exist that can contain
  different media formats.  A receiving agent thus needs to examine the
  details of such media content to determine if the specific elements
  can be rendered given an available set of codecs.  Especially when
  the end system has limited resources, or the connection to the end
  system has limited bandwidth, it is helpful to know from the Content-
  Type alone if the content can be rendered.

  This document specifies two parameters, "codecs" and "profiles",
  which are used with various MIME types or type/subtype combinations
  to allow for unambiguous specification of the codecs and/or profiles
  employed by the media formats contained within.  This document
  obsoletes RFC 4281; RFC 4281 defines the "codecs" parameter, which
  this document retains in a backwards compatible manner with minor
  clarifications; the "profiles" parameter is added by this document.

  By labeling content with the specific codecs indicated to render the
  contained media, receiving systems can determine if the codecs are
  supported by the end system, and if not, can take appropriate action
  (such as rejecting the content, sending notification of the
  situation, transcoding the content to a supported type, fetching and
  installing the required codecs, further inspection to determine if it
  will be sufficient to support a subset of the indicated codecs, etc.)

  Similarly, the profiles can provide an overall indication, to the
  receiver, of the specifications with which the content complies.  The
  receiver may be able to work out the extent to which it can handle
  and render the content by examining to see which of the declared
  profiles it supports, and what they mean.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-gellens-mime-bucket-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-gellens-mime-bucket-bis/


No IPR declarations have been submitted directly on this I-D.