bad-idea-of-the-day: Inline data as URL scheme?

Larry Masinter (
Wed, 30 Aug 1995 12:01:34 PDT

I've noted from time to time (and been asked to help with more
locally) a request to embed some other (small) media type inline.
I was looking for a way that this would work for VRML and PDF as well
as HTML.

I've been thinking that this might be a new kind of URL scheme. It is
most like 'immediate addressing', i.e., you actually stick the value
into the address field. What kind of data? Well, perhaps any MIME
type, suitably encoded. For example:


where <mimetime> is a media type (with optional parameters, etc.),
<encoding> is either Q (for 'quoted-printable') or 'B' for 'base64'
(with possibly other encodings defined), and <encoded-value> is the
data to be recreated as an 'immediate' value.

This is only to be used for very short data types. For example,


might be useful in a footnote link, while,


could be used for a small inline image.

The application that I really wanted to use this for is one where
we've designed a custom 'helper' application which invokes some other
process with more information than just 'the URL', e.g.,


This is only appropriate for delivery of very small inline data. The
embedded image above is probably near the limit of utility. For
anything else larger, or where the base64 encoding is problematic or
cumbersome, you're better off sending multipart/related with the first
part being the data containing the references (e.g., a HTML or PDF
file) and the subsequent parts being the actual data, all linked by
cid: URLs in the first part and content-ID headers in the subsequent