RFC 2392

Content-ID and Message-ID Uniform Resource Locators

📅 published August 1998, from ietf

Content-ID and Message-ID Uniform Resource Locators 💖

Okay bestie, this one is RFC 2392 from the Network Working Group 🎀. Edward Levinson (E. Levinson) wrote it in August 1998. It's a Standards Track doc, and it obsoletes RFC 2111 ✨. It doesn't list any updates.

Status of this Memo 🧚

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

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

Abstract 🌸

The "cid:" and "mid:" URL schemes let you reference messages and their body parts 💅. Picture a single multipart message where one HTML body part has embedded references to other parts of that same message. Iconic 🔥.

Changes from (RFC 2111) ✨

Okay so the example on page 3 about converting cid URLs to Content-IDs got clarified 💅. It now uses a cid URL instead of an mid 🎀.

The example messages also got fixed up so the Content-ID has the correct form, with angle brackets 🙈. A Message-ID header got added to the second example too 🌷.

1. Introduction 💖

So [MIME] in email is how we send web pages and their images together 📨. The HTML needs a way to point at those images or other data inside the same message, and that's exactly what the Content-ID Uniform Resource Locator, "cid:", is for 🫶.

Net News readers have a similar thing going on, since they use Message-IDs to link related messages together 🧵. The Message-ID URL gives us the "mid:" scheme so you can refer to those messages as a "resource" ✨.

Basically, "mid" (Message-ID) and "cid" (Content-ID) give you identifiers for messages and their body parts 💜. The "mid" scheme uses (a part of) an email message's message-id to point at one specific message 🦋. The "cid" scheme points at a specific body part of a message, and it's mostly meant for other body parts in the same message as the one doing the referencing 🎀. And "mid" can also point at a specific body part inside a designated message, by including the content-ID's address 🍓.

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 🎀

RFC 1738 [URL] set aside the "mid" and "cid" schemes for Message-ID and Content-ID, respectively 💅. This memo defines the syntax for those URLs 🦋. They use the same syntactic pieces, so they're covered together 💖.

The URLs take this form:

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 ]

Notes: In Internet mail messages, the addr-spec in a Content-ID [MIME] or Message-ID [822] header is wrapped in angle brackets, <> 🎀. The 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 in the "mid" scheme), has to be hex-encoded using the %hh escape mechanism in [URL] 💀.

A "mid" URL with only a "message-id" refers to a whole message 💜. Add the "content-id" on the end and it points at a body part inside the message, same as a "cid" URL does 🌸. A MIME body part's Content-ID is required to be globally unique 🔥. But lots of systems that store messages don't index body parts on their own, apart from the message they're in 🙈. The long form of the "mid" URL was built to carry that missing context so it works with those systems 🧚.

An implementation that conforms to this spec is required to support the "mid" long form (message-id/content-id) 💅. Conforming implementations can choose to, but don't have to, use the fact that a content-id is unique and read a "cid" URL as pointing at any body part in the message store 🦋.

Sometimes, in limited situations (like inside multipart/alternate), one message can have several body parts with the same Content-ID 🌈. That happens when the same data can be reached through different methods, for example 🍓. In those cases, conforming implementations are required to follow the rules of the containing MIME entity (like multipart/alternate) to pick the body part the Content-ID refers to 💖.

Converting a "cid" URL into a Content-ID message header [MIME] is pretty simple. You drop the "cid:" prefix, turn the % encoded characters back into their US-ASCII equivalents, and wrap what's left in an angle bracket pair, < and > ✨. For example, cid:foo4%25foo1@bar.net becomes:

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

Going the other way, converting URL special characters into their % encodings gets you back to the original cid 🔄.

A "mid" URL gets converted 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 ever share the same Message-ID addr-spec, and no two different body parts ever share the same Content-ID addr-spec 💜. A popular trick a lot of message systems use is a time and date stamp plus the local host's domain name, like 950124.162336@XIson.com 🕰️✨.

Some Examples 🦋

This first message has an HTML body part that references an image in another body part 🌷. Both body parts sit inside a Multipart/Related MIME entity 🌈. The HTML IMG tag has a cidurl that points at 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

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--

This second message points at another message, which hopefully is still in the recipient's message store 🤞.

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

<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 🚨

Okay, this part is serious bestie 😭. The URLs defined here are just an addressing or referencing mechanism 🔍. Their values don't reveal any more about the originator's environment than the Message-ID and Content-ID values already do 🫣. If anyone is worried about that kind of disclosure, the originator of a message using mid and cid URLs has to take precautions so confidential information doesn't leak 🔐. Those precautions should already be in place for existing mail use of Message-ID and Content-ID 💅.

4. References 📚

[822]     Crocker, D., "Standard for the Format of ARPA Internet Text
          Messages", August 1982, STD 11, RFC 822, August 1982.

[MIME]    Borenstein, N., and N. Freed, "Multipurpose Internet Mail
          Extensions (MIME) Part One: Format of Internet Message
          Bodies", RFC 2045, November 1996.

[URL]     Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
          Resource Locators (URL)", RFC 1738, December 1994.

[MULREL]  Levinson, E., "The MIME Multipart/Related Content-type",
          RFC 2387, August 1998.

5. Acknowledgments 🫶

The original idea behind "mid" and "cid" URLs was part of Tim Berners-Lee's original vision for the World Wide Web 🌐. The ideas and design got a lot better thanks to 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

Phone: +1 908 549 3716
EMail: XIson@cnj.digex.net

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

You're allowed to copy this document and give copies to others 🦋. You can also make derivative works that comment on or explain it, or help with implementing it, and publish and distribute those however you want, in whole or in part, with no restrictions 🎀. The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🙏.

The document itself can't be modified in any way, though 🙅‍♀️. That includes removing the copyright notice or references to the Internet Society or other Internet organizations 😤. The exception is developing Internet standards, where you follow the copyright procedures in the Internet Standards process, or translating it into languages other than English 🌍.

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

The document and the information in it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 💀. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 🫠.

📦 where this page comes from