RFC 2912

Indicating Media Features for MIME Content

📅 published September 2000, from ietf

RFC 2912: Indicating Media Features for MIME Content 🦋

okay bestie, here's the tea 🫶 this RFC was written by G. Klyne from Content Technologies, filed in the Network Working Group, and dated September 2000. It's a Standards Track doc, so it's a real Internet standards protocol 👑 The header doesn't list anything it obsoletes or updates, so no drama there ✨

Status of this Memo 💅

okay so this doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to discuss and suggest improvements 🌸 For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is totally unlimited 🌈

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

Abstract ✨

so in "A Syntax for Describing Media Feature Sets", there's an expression format for describing media feature capabilities using simple media feature tags 🧚

this memo defines a Multipurpose Internet Mail Extensions (MIME) 'Content-features:' header 🦋 You can use it to annotate a MIME message part with that expression format, and it shows some ways that could be useful 💖

Table of Contents 🌈

   1. Introduction ...............................................  2
      1.1 Terminology and document conventions ...................  2
   2. Motivation and goals .......................................  3
   3. The 'Content-features:' MIME header ........................  4
      3.1 Whitespace and folding long headers ....................  4
      3.2 Usage considerations ...................................  4
        3.2.1 Simple message parts ...............................  4
        3.2.2 Multipart and other composites .....................  5
        3.2.3 Reference to external data .........................  5
   4. Examples ...................................................  5
      4.1 Simple message .........................................  5
      4.2 Fax message ............................................  6
      4.3 Multipart/alternative data .............................  6
      4.4 Reference to external message data .....................  8
      4.5 Compressed data ........................................  8
      4.6 Multipart/related data .................................  8
   5. Security Considerations ....................................  9
   6. Acknowledgements ........................................... 10
   7. References ................................................. 10
   8. Author's Address ........................................... 10
   Full Copyright Statement ...................................... 11

1. Introduction ✨

okay so in "A Syntax for Describing Media Feature Sets" [1], there's an expression format for describing media feature capabilities as a combo of simple media feature tags. Those tags get registered according to "Media Feature Tag Registration Procedure" [2] 💅 This gives message handling agents a format to describe the media feature content of the messages they can handle, and that's literally the whole point 🫶

this memo defines a MIME 'Content-features:' header that you can use to annotate a MIME message part with these feature expressions ✨ The header lets you say what media-related features the message content has, even when they go beyond the MIME content type. It's giving extra detail 🎀

it also looks at how this header can present message media content info that's kinda tricky to express inside the basic MIME framework 🙈

1.1 Terminology and document conventions 📖

this section defines a bunch of terms and document conventions that have specific meanings in this memo, so let's get them straight 💜

  • media feature: information that says what facilities are assumed to be available so the message content can be properly rendered or otherwise presented. Media features aren't meant to include info 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]. (Check 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 specs 🧚)

this spec uses the syntax notation and conventions from RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3] 🫶

NOTE: Comments like this one give extra, nonessential info about the rationale behind this doc. You don't need it to build a conformant implementation, but it can help you understand the design in more depth 🤓

2. Motivation and goals 🌈

so media feature labelling of message parts can be used in these ways 👑

  • to supply more detailed media feature info about message content than the 'Content-type:' header can provide 💖
  • to provide summary media feature info (possibly including MIME content types) about the content of a composite MIME message part (e.g. 'multipart' or 'message'), without having to open up the inner content of the message 🧚
  • to supply media feature info about external data that a message part references (e.g. 'message/external-body' MIME type). This info wouldn't be available just by looking at the message content, which is so important 😭
  • to describe the content of a message that's encrypted or encoded using some application-specific file structure that hides the content from a MIME processor. This info also wouldn't generally be available by looking at the message content 💀

3. The 'Content-features:' MIME header 🎀

a new header field is defined that extends the allowable formats for 'optional-field' [4] with this syntax 💅

      optional-field =/ "Content-features" ":" Feature-expr
      Feature-expr   =  filter      ; See [1], section 4.1

where 'filter' is the media feature expression format defined by "A Syntax for Describing Media Feature Sets" [1] 🦋

this header gives extra info about the message content that's directly contained in, or indirectly referenced by, the corresponding MIME message part ✨

3.1 Whitespace and folding long headers 🌸

sometimes media feature expressions can get really long 🙈

according to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature expression. And RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears, so you can dodge line length restrictions 🫶

so it's recommended that you include whitespace as permitted, especially in long media feature expressions 💖 That helps headers get folded by agents that don't otherwise understand the syntax of this field 🧚

3.2 Usage considerations 💜

3.2.1 Simple message parts 🦋

when this gets applied to a simple MIME message part, the header should appear just once 💅 It's used to convey extra info about the message part content that goes beyond what the MIME 'Content-type:' header field gives you ✨ The 'Content-features:' header may indicate a content type that's different from the one in the MIME 'Content-type:' header. That's possible, but it's not recommended when applied to a non-composite body part. Either way, MIME content type processing must be performed in accordance with the 'Content-type:' header 🙅‍♀️

NOTE: Once the message content has been delivered to an application, subsequent processing may be affected by the content type info indicated by the media feature expression. See example 4.5 below 👀

3.2.2 Multipart and other composites 🌈

'Content-features:' headers may be applied to a MIME multipart, indicating info about the inner content of that multipart 👑

implementations must not assume a one-to-one relationship between 'Content-features' headers and contained body parts 😭 Headers may appear on a containing multipart wrapper in a different order than the body parts they refer to. A single header may refer to more than one contained body part, and several headers may refer to the same contained body part 🌀

if it's important to relate specific media features to specific contained MIME body parts, then the 'Content-features:' header should be applied directly to the body part concerned, rather than the surrounding composite 💖

NOTE: The intent here is to let you provide summary media feature info without having to open up and examine the inner content of the MIME message 🧚

similar usage may apply when the message format is a non-MIME or opaque composite, e.g. 'application/zip', or an encrypted message 🔐 In these cases, the option of examining the message content to find media feature info isn't available 💀

3.2.3 Reference to external data 🦋

media feature info about data that a MIME body part indirectly references (rather than having it contained within the message) can be conveyed using one or more 'Content-features:' headers ✨

for example, media info (including the contained MIME content type(s)) about the data referenced by a MIME 'Message/external-body' may be conveyed 🌸

4. Examples 🧁

4.1 Simple message 💅

      Mime-Version: 1.0
      Content-type: text/plain;charset=US-ASCII
      Content-features: (& (paper-size=A4) (ua-media=stationery) )

       :
      (data)
       :

4.2 Fax message 📠

      Mime-Version: 1.0
      Content-Type: multipart/mixed; boundary="break"
      Content-features:
        (& (Type="image/tiff")
           (color=Binary)
           (image-file-structure=TIFF-S)
           (dpi=200)
           (dpi-xyratio=200/100)
           (paper-size=A4)
           (image-coding=MH) (MRC-mode=0)
           (ua-media=stationery) )

      --break
      Content-Type: image/tiff; name="coverpage.tiff"
      Content-Transfer-Encoding: base64
      Content-Description: This part is a coverpage
      Content-Disposition: attachment; filename="coverpage.tiff"

      0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
      AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
       :
      (more data)
       :
      --break

      Content-Type: image/tiff; name="document.tiff"
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename="document.tiff"

      AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
      GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
       :
      (more data)
       :
      --break--

4.3. Multipart/alternative data

okay so this example is giving three big lessons 🎀

  • info about the parts inside a multipart/alternative can be shared before the alternatives get processed, which might make one-pass processing way easier 🧠
  • alternatives can share the same basic MIME content-type but use different content features 🌈
  • there is no defined correspondence between 'Content-features' headers and the body parts they sit next to 🙈
   Mime-Version: 1.0
   Content-Type: multipart/alternative; boundary="break"
   Content-features: (& (Type="text/plain") (charset=US-ASCII) )
   Content-features:
     (& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
   Content-features:
     (& (Type="text/html") (charset=ISO-8859-1) (color=binary) )

   --break
   Content-type: "text/plain";charset=US-ASCII
   Content-features: (color=binary)

    :
   (data)
    :
   --break
   Content-type: "text/plain";charset=US-ASCII
   Content-features: (color=limited)

    :
   (data)
    :
   --break


   Content-type: text/html;charset=iso-8859-1
   Content-features: (color=binary)

    :
   (data)
    :
   --break
   Content-type: text/html;charset=iso-8859-1
   Content-features: (color=limited)

    :
   (data)
    :
   --break--

4.4. Reference to external message data

   Mime-Version: 1.0
   Content-type: message/external-body; access-type=URL;
                 URL="http://www.foo.com/file1.html"

   Content-type: Multipart/mixed
   Content-features: (& (Type="text/plain") (charset=US-ASCII) )
   Content-features: (& (Type="image/tiff") (color=limited) )

   <end>

4.5. Compressed data

this one is so clever 💅 it shows how the 'Content-features' header can fix the problem flagged in the MIME registration for 'Application/zip', which is that the zip format doesn't tell you anything about what's inside it ✨

   Mime-Version: 1.0
   Content-type: application/zip
   Content-features: (& (Type="text/plain") (charset=US-ASCII) )
   Content-features: (& (Type="image/tiff") (color=limited) )
   Content-transfer-encoding: base64

    :
   (data)
    :
   <end>

(See also: RFC 2387, "The MIME Multipart/Related Content-type" [8])

   Mime-Version: 1.0
   Content-Type: multipart/related; boundary="boundary-example";
                 type="text/html"; start="<foo3@foo1@bar.net>"
   Content-features: (& (type="text/html") (charset=US-ASCII) )
   Content-features: (type="image/gif")

   --boundary-example
   Content-Type: text/html;charset=US-ASCII
   Content-ID: <foo3@foo1@bar.net>

   referencing a resource in another body part, for example
   through a statement such as:
   <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
    ALT="IETF logo">

   --boundary-example
   Content-Location:
      http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
   Content-Type: IMAGE/GIF
   Content-Transfer-Encoding: BASE64

   R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
   NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
   etc...

   --boundary-example--

5. Security Considerations

okay this section is serious, so read it carefully bestie 🔐😭

when a media feature expression is applied to simple or multipart MIME data, it gives summary info about the message data, and in lots of cases you can work that out just by looking at the message content. in those situations, no extra security considerations seem to come up 🫶

when it's applied to other message composites, especially encrypted content, feature expressions might reveal info that would otherwise be unavailable. in those cases, some of the security considerations around media content negotiation [1,2] could matter a lot more 👀

it's suggested here that media feature descriptions can be useful with encrypted message content. but be careful 🚨 make sure the purpose of the encryption doesn't get broken. for example, encryption might be meant to hide the fact that a particular application data format is in use, and that could be exposed by a carelessly placed Content-features header 💀

if a 'Content-features' header is applied to a multipart/signed object (or really outside of any other form of signed data), the media feature information is not protected. that unprotected info could be tampered with, which could trick implementations into doing inappropriate things with the content inside. (putting the media feature information inside the signed information would fix this, but then implementations would have to parse the inner structure to find it 🥲)

6. Acknowledgements

this proposal came out of discussions with Dan Wing 🌸 the fax message example was taken from a proposal by Mike Ruhl, and the multipart/related example was developed from RFC 2557 [7] 💖

the author also wants to thank these people, whose comments led to big improvements: Mr Hiroshi Tamura, Ted Hardie, Maurizio Codogno, Jacob Palme, and Ned Freed 🫶✨

7. References

  • [1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
  • [2] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
  • [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [4] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
  • [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Internet message bodies", RFC 2045, November 1996.
  • [6] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
  • [7] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.

8. Author's Address

   Graham Klyne
   Content Technologies Ltd.
   1220 Parkview,
   Arlington Business Park
   Theale
   Reading, RG7 4SA
   United Kingdom

   Phone: +44 118 930 1300
   Fax:   +44 118 930 1301
   EMail: GK@ACM.ORG

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

this document and translations of it can be copied and shared with others, and derivative works that comment on or explain it, or help with implementing it, can be made and published and distributed, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph are included on every copy and derivative work. however, this document itself may not be modified in any way (like removing the copyright notice or the references to the Internet Society or other Internet organizations), except to develop Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or to translate it into languages other than English 📜

the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 💜

this document and the information in it are 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