Indicating Media Features for MIME Content
Extracted elements (13)
If relating specific media features to specific contained MIME body parts is important, the 'Content-features:' header should be applied directly to the body part concerned rather than the surrounding composite, because no defined correspondence exists between multipart-level headers and inner body parts.
Multiple 'Content-features:' headers on a multipart/alternative part allow feature information about all alternatives to be available before any alternative body parts are processed, potentially facilitating optimum one-pass processing.
The 'Content-features:' header allows summary media feature information to be provided about a multipart composite without requiring recipients to open and examine the inner content. This is particularly useful for opaque composites such as 'application/zip' or encrypted messages where examining content to discover features is not possible.
The 'Content-features:' header allows supplying media feature information about external data referenced by a body part (e.g., 'message/external-body'), where such information would not be available by examination of the message content itself.
The 'Content-features:' header can overcome the limitation in 'application/zip' MIME registration where information about inner data content is otherwise unavailable, by annotating the zip part with feature expressions describing the contained types.
Whitespace is allowed between lexical elements of a media feature expression per RFC 2533, and RFC 822/MIME allows folding of long headers at whitespace points. It is therefore recommended that whitespace be included in long feature expressions to facilitate header folding by agents that do not understand the field syntax.
Implementations must not assume a one-to-one relationship between 'Content-features' headers and contained body parts; headers may appear in different order than body parts, a single header may refer to more than one body part, and several headers may refer to the same body part.
MIME content type processing must be performed in accordance with the 'Content-type:' header, regardless of any differing content type indicated by a 'Content-features:' header on a non-composite body part.
The 'Content-features:' header is a new MIME optional-field with syntax: 'Content-features' ':' Feature-expr, where Feature-expr is a media feature expression (filter) as defined in RFC 2533. It provides additional information about message content beyond what the MIME 'Content-type:' header supplies.
If a 'Content-features:' header is applied outside a multipart/signed object or other signed data structure, the media feature information is unprotected and could be tampered with, potentially causing implementations to process the contained material inappropriately. Placing the feature information inside the signed structure would protect it at the cost of requiring inner-structure parsing.
When applied to simple or multipart MIME formatted data where feature information can be determined by examining message content, the 'Content-features:' header raises no additional security considerations beyond those already associated with media content negotiation.
When 'Content-features:' headers are applied to encrypted message content, the feature expressions may disclose information about content type or application format that encryption was intended to conceal. Care must be taken to ensure the purpose of encryption is not compromised by injudicious use of this header.
The 'Content-features' header value is defined as Feature-expr = filter, using the ABNF extension optional-field =/ "Content-features" ":" Feature-expr, where filter is the media feature expression format from RFC 2533 section 4.1.