RFC 2111

Status of this Memo 📜

Okay, quick legal-ish bit 💅 This doc is an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

---

Abstract 💌

The URL schemes cid: and mid: let you reference messages and their body parts 🎀 For example, inside one multipart message, an HTML body part could embed references to other parts of that same message 🦋

---

1. Introduction ✨

So, the whole reason this exists: [MIME] email is how we send web pages and their images together, and the HTML needs a way to point at those images or other data sitting inside the message 🌸 That's what the Content-ID URL, cid:, is for 🧚

Net News readers also use Message-IDs to link related messages together 📰 The Message-ID URL gives us the mid: scheme to refer to those messages as a "resource" 💜

The mid (Message-ID) and cid (Content-ID) URL schemes give you identifiers for messages and body parts ✨ mid uses (a part of) an email's message-id to point at one specific message 💅 cid points at one specific body part of a message, and it's generally only used to reference other body parts in that same message as the body part doing the referencing 🫶 mid can also point at a specific body part inside a designated message, by including the content-ID's address 👑

A quick terminology note 🍓 "body part" and "MIME entity" mean the same thing 💖 They both refer to the headers and body of a MIME message, whether that's the whole message or one of the body parts inside a Multipart message 🌈

---

2. The MID and CID URL Schemes 🦋

Okay, so [URL] (that's RFC1738) reserves "mid" and "cid" for Message-ID and Content-ID, respectively 💅 This memo defines the syntax for those URLs 🎀 They use the same syntactic bits, so they get presented together 🫶

The URLs look like this:

        content-id    = url-addr-spec

        message-id    = url-addr-spec

        url-addr-spec = addr-spec  ; URL encoding of RFC 822 addr-spec

        cid-url       = "cid" ":" content-id

        mid-url       = "mid" ":" message-id [ "/" content-id ]

Note 👀 In Internet mail, the addr-spec in a Content-ID [MIME] or Message-ID [822] header is wrapped in angle brackets, <>. An addr-spec in a Message-ID or Content-ID might have characters that aren't allowed in a URL, so any such character (including "/", which is reserved within the "mid" scheme) must be hex-encoded using the %hh escape mechanism in [URL]. 🙈

A "mid" URL with only a "message-id" refers to a whole message 💌 Add a "content-id" on the end and it refers to a body part within that message, same as a "cid" URL does 🧚 A MIME body part's Content-ID is required to be globally unique 🌸 But plenty of systems that store messages don't index body parts on their own, separate from the message they belong to 😭 That's why the long form of the "mid" URL (message-id/content-id) was designed: to carry that context and keep things interoperating with those systems 🫶

An implementation that conforms to this spec is required to support the long form of the "mid" URL (message-id/content-id) ✨ Conforming implementations can choose to take advantage of the content-id's uniqueness and read a "cid" URL as pointing at any body part in the message store, but they don't have to 🦋

In limited situations (for example, inside multipart/alternate), one message might have several body parts sharing the same Content-ID 🌈 That happens when the same data can be reached through different methods [MIME, sect. 7.2.3] 💅 In those cases, conforming implementations are required to use the rules of the containing MIME entity (e.g., multi-part/alternate) to pick which body part the Content-ID refers to 👑

Converting a "cid" URL into the matching Content-ID header [MIME] is pretty straightforward 🎀 You drop the "cid:" prefix, turn %hh hex-escaped characters back into their ASCII equivalents, and wrap what's left in an angle bracket pair, < and > 🍓 For example, "mid:foo4%25foo1@bar.net" corresponds to:

        Message-ID: <foo4%foo1@bar.net>

A "mid" URL gets turned into a Message-ID, or a Message-ID/Content-ID pair, in a similar way 💖

Both message-id and content-id are required to be globally unique 🫶 That means no two different messages will ever have the same Message-ID addr-spec, and no different body parts will ever have the same Content-ID addr-spec 😭 A common move that lots of message systems use is a time and date stamp combined with the local host's domain name, like 950124.162336@XIson.com 🧚

---

Some Examples 🧚

Example one 💌 The message below has an HTML body part that references an image in another body part 🦋 Both body parts live inside a Multipart/Related MIME entity 🌈 The HTML IMG tag has a cidurl that points to the image 💅

     From: foo1@bar.net
     To: foo2@bar.net
     Subject: A simple example
     Mime-Version: 1.0
     Content-Type: multipart/related; boundary="boundary-example-1";
                   type=Text/HTML

     --boundary-example 1
     Content-Type: Text/HTML; charset=US-ASCII

     ... text of the HTML document, which might contain a hyperlink
     to the other body part, for example through a statement such as:
     <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">

     --boundary-example-1
     Content-ID: foo4*foo1@bar.net
     Content-Type: IMAGE/GIF
     Content-Transfer-Encoding: BASE64
     R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
     NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
     etc...

     --boundary-example-1--

Example two 🍓 This message points at another message (hopefully still in the recipient's message store) 🫶

     From: bar@none.com
     To: phooey@all.com
     Subject: Here's how to do it
     Content-type: text/html; charset=usascii

     ...  The items in my
     <A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">
     previous message</A>, shows how the approach you propose can be
     used to accomplish ...

---

3. Security Considerations 🔐

⚠️ Serious moment, bestie 🥺 The URLs defined here are an addressing or referencing mechanism 🔐 The values of these URLs disclose no more about the originator's environment than the corresponding Message-ID and Content-ID values do 🔐 Wherever there's concern about that kind of disclosure, the originator of a message that uses mid and cid URLs must take precautions to ensure that confidential information is not disclosed 🚨 Those precautions should already be in place to handle existing mail use of the Message-ID and Content-ID 💀

🚨 Don't leak confidential info through your mid and cid URLs. Your existing Message-ID and Content-ID precautions should already cover this, but double-check anyway. 🚨

---

4. References 📚

• [822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages," August 1982, University of Delaware, STD 11, RFC 822.
• [MIME] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies," September 1993, RFC 1521.
• [URL] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform Resource Locators (URL)," December 1994.
• [MULREL] E. Levinson, "The MIME Multipart/Related Content-type," December 1995, RFC 1874.

---

5. Acknowledgments 🫶

The original idea of "mid" and "cid" URLs was part of Tim Berners-Lee's original vision of the World Wide Web 🌐 The ideas and design have hugely benefited from discussions with Harald Alvestrand, Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others in the MHTML working group 💜

---

6. Author's Address 💌

   Edward Levinson
   47 Clive Street
   Metuchen, NJ  08840-1060
   USA
   +1 908 549 3716
   <XIson@cnj.digex.net>