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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new Request for Comments is now available in online RFC libraries.

        
        RFC 6381

        Title:      The 'Codecs' and 'Profiles' Parameters 
                    for "Bucket" Media Types 
        Author:     R. Gellens, D. Singer,
                    P. Frojdh
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2011
        Mailbox:    rg+ietf@qualcomm.com, 
                    singer@apple.com, 
                    Per.Frojdh@ericsson.com
        Pages:      19
        Characters: 39790
        Obsoletes:  RFC4281
        Updates:    RFC3839, RFC4393, RFC4337

        I-D Tag:    draft-gellens-mime-bucket-bis-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6381.txt

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', that
are used with various MIME types or type/subtype combinations to
allow for unambiguous specification of the codecs employed by the
media formats contained within, or the profile(s) of the overall
container format.  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.
This is an indication of the compatibility of the container format
and its contents to some specification.  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.  [STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux