MIME Content Types in Media Feature Expressions
Extracted elements (15)
Allowing content-type parameters as part of a 'type' tag value was considered but rejected due to concerns about canonicalization, ordering, and case sensitivity. Only exact, case-sensitive character matching is defined for media feature expressions.
Including MIME content type in feature expressions is useful when all media capability information must be conveyed in a single expression, such as in DSN and MDN extensions that provide a single field for this information.
The 'type' feature tag is also useful when media features describe inner parts of a MIME composite (e.g., component parts of a 'multipart', files in a compressed archive, or encrypted message data), allowing the content type of inner parts to appear in the outer expression.
The 'type' feature tag was motivated by the need to include MIME content type information within media feature expressions, since HTTP 1.1 with TCN indicates acceptable content types and media features in different request headers with no way to indicate acceptable combinations.
String feature matching is case sensitive, so consistent use of lower-case for content type values is essential for matching behavior consistent with MIME content type matching. The canonical form requires all lower-case letters with all whitespace removed.
White space must be used consistently in 'type' feature tag values. The canonical form specified by this registration removes all whitespace from content type values.
The content type value for the 'type' feature tag must be given without any content-type parameter values. Only lower-case letters should be used.
To include information otherwise conveyed in a MIME content-type parameter within media feature expressions, a separate media feature tag should be registered and used in the expression rather than embedding parameters in the 'type' tag value.
For voice messages, the 'type' feature tag can be set to a multipart MIME type such as "multipart/voice-message", where other media features in the expression describe the inner MIME parts rather than mirroring the MIME structure exactly.
The 'type' feature tag can appear within compound feature expressions using the combining algebra from RFC 2533, enabling expressions like (& (type="text/plain") (charset=US-ASCII) (color=binary) (paper-size=A4)).
The 'type' feature tag indicates a MIME media content type appearing in a 'Content-type:' header of corresponding MIME-formatted data. Its value must be a string of the form "type/subtype" using only lower-case letters, with no content-type parameter values included.
The 'type' feature tag value consists of the MIME media type and subtype presented using all lower-case letters with any whitespace characters removed, as in "image/tiff" or "text/plain".
Web browser capability expressions can use the 'type' tag in disjunctions to indicate support for multiple content types each with their own associated feature constraints, as shown in the example combining text/html, text/plain, image/gif, and image/jpeg capabilities.
This document registers the 'Type' feature tag in the IETF tree (subject to IETF Consensus policies per RFC 2434), with ASN.1 identifier 1.3.6.1.8.1.30 assigned by IANA. The tag takes string values representing MIME content types.
This memo is not believed to introduce any security considerations beyond those already inherent in the use of media feature tags and expressions as defined in RFC 2533 and RFC 2506.