RFC 2913

MIME Content Types in Media Feature Expressions

📅 published September 2000, from ietf

MIME Content Types in Media Feature Expressions ✨

Network Working Group, Request for Comments: 2913 🎀 Author: G. Klyne, Content Technologies Category: Standards Track Date: September 2000 Obsoletes/Updates: nothing listed, so no drama there 🙌

Status of This Memo 🌸

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💜 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🦋

Okay so, "A Syntax for Describing Media Feature Sets" gives us an expression format for describing what a device can handle, using simple media feature tags ✨

This memo adds a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. That means you can build feature expressions that actually take the MIME content type of the data into account. It's giving precision 💅

Table of Contents 📖

   1. Introduction .................................................. 2
      1.1 Terminology and document conventions ...................... 2
   2. Motivation and goals .......................................... 3
   3. MIME content type feature tag ................................. 3
   4. Examples ...................................................... 4
      4.1 Simple text ............................................... 4
      4.2 Fax image ................................................. 4
      4.3 Voice message ............................................. 4
      4.4 Web browser capabilities .................................. 5
   5. IANA Considerations ........................................... 5
   6. Security Considerations ....................................... 5
   7. Acknowledgements .............................................. 5
   8. References .................................................... 6
   9. Author's Address .............................................. 6
   Appendix A: 'Type' feature tag registration ...................... 7
   Full Copyright Statement ......................................... 9

1. Introduction 💖

Okay bestie, so the paper "A Syntax for Describing Media Feature Sets" [1] gives us an expression format for describing media feature capabilities. You build it by combining simple media feature tags, and those tags get registered through the "Media Feature Tag Registration Procedure" [2]. The result is a format that message handling agents can use to describe the media feature content of messages they're able to handle 🧚

This memo defines a media feature tag whose value is a MIME content type. This lets you build feature expressions that take the MIME content type of the matching data into account 🎀

Heads up, though: a content type feature value may contain parameters, but this is discouraged. See section 3 and appendix A, "Summary of the media features indicated" for the discussion of this point 🙈

1.1 Terminology and document conventions 📖

This section defines a few terms and document conventions, which carry a specific meaning in this memo. Read these first, they're important 💅

  • media feature: information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.
  • feature set: some set of media features described by a media feature assertion, as described in "A Syntax for Describing Media Feature Sets" [1]. (See that memo for a more formal definition of this term.)
  • feature set expression: a string that describes some feature set, formulated according to the rules in "A Syntax for Describing Media Feature Sets" [1] (and possibly extended by other specifications).

This specification uses the syntax notation and conventions described in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3] ✨

NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth. 🤓

2. Motivation and goals 🦋

The media feature expression syntax [1] and feature tags [2] were designed to provide content media information that augments basic MIME content type information. There are some situations where it's useful to be able to include that content type information in a media feature expression, like so:

  • Media feature details may depend on the content type being used. The media feature combining algebra and syntax [1] can't apply to content type information unless it appears in the feature expression.
    • For example, in HTTP 1.1 [4] with Transparent Content Negotiation (TCN) [5], acceptable content types and other media features are indicated in different request headers, with no clear way to indicate that they may be acceptable only in certain combinations. That's a whole mess 😭
  • It's sometimes useful for all media capability information to be included in a single expression. For example, the DSN and MDN extensions [6] that let a recipient indicate media capabilities provide a single field for conveying this information. One field, no chaos 👑
  • When media features are used to describe message content, they may refer to inner parts of a MIME composite, e.g. the component parts of a 'multipart', files in a compressed archive, or encrypted message data. Nested vibes 🪆

3. MIME content type feature tag 🎀

Here's the feature tag at a glance:

   Feature tag name    Legal values
   ----------------    ------------
   type                <string>
                       containing a MIME content-type value.

Reference: this document, appendix A.

The 'type' feature tag indicates a MIME media content type, meaning the one that shows up in a 'Content-type:' header of the corresponding MIME-formatted data. It must be a string of the form "type/subtype", where 'type' and 'subtype' are defined by the MIME specification [7]. Only lower-case letters should be used 🔡

The content type must be given without any content-type parameter values. No parameters allowed, babe 🚫

If you want to include information in media feature expressions that would otherwise be conveyed in a MIME content-type parameter, you should register a separate media feature tag [2] and use that in the expression instead. The 'charset' example in 4.1 below shows this in action. The 'charset' tag is defined by its own registration [10] 💖

NOTE: Allowing content-type parameters to be part of a type tag value was considered, but rejected because of concerns about canonicalization, ordering, case sensitivity, etc. Only exact, case-sensitive, character matching is defined for media feature expressions [1]. 🙅‍♀️

Part 2 picks up with Section 4 (the examples, which are so good) and runs through IANA Considerations, the Security Considerations, the Acknowledgements, the References, and the Author's Address 💜🌈

Appendix A: 'Type' feature tag registration ✨

okay bestie, this is the registration template for the Type feature tag 🦋 it's a whole form that tells everyone what the tag is for, and every field matters 💅

  • Media Feature tag name(s): Type 🎀
  • ASN.1 identifier associated with this feature tag: 1.3.6.1.8.1.30 🔢
  • Summary of the media features indicated: This tag tells you which MIME content type a message agent can handle, or which one is hiding inside some message data 👀

The content type is the MIME media type and subtype. It's always written in all lowercase letters, with any whitespace removed ✨

  • Values appropriate for use with this feature tag: String 🧵
  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: Basically any application that wants to share MIME content type info inside a media feature expression 💜
  • Examples of typical use:
(type="image/tiff")

(& (type="text/plain") (charset=US-ASCII) )
  • Related standards or documents:
    • MIME, RFC 2045 [7]
    • MIME, RFC 2046 [8]
    • Registration of Charset and Languages Media Features Tags [10]
  • Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: (N/A) 🙈
  • Interoperability considerations: ngl this is the important part 😭 String feature matching is case sensitive, so you have to use case consistently for content type values and parameters. Otherwise matching won't line up the way MIME content type matching does 🔥

white space has to be used consistently too, bestie 🫶

This registration sets a canonical form for content type values: lowercase letters, and all whitespace removed 🌈

  • Related feature tags: (N/A) 🌸
  • Intended usage: Common ⭐
  • Author/Change controller: IETF 👑
the legal part is kept word for word on purpose, because copyright notices don't get a vibe check 🙈

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 💖

📦 where this page comes from