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

Brian Behlendorf (
Wed, 30 Aug 1995 17:29:11 -0700 (PDT)

On Wed, 30 Aug 1995, Steven T. Roussey wrote:
> On Wed, 30 Aug 1995, Larry Masinter wrote:
> > 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:
> I like a URL like <OBJECT SCR="protocol://pathname.extension"> Then use
> standard MIME extentions to get at the actual data type (and the URL to
> get the data). Note that <OBJECT SCR=""> is
> the same as <IMG SRC="">.

You're missing the point of Larry's suggestion, which was to inline
*small* objects. Linking to objects of arbitrary mime type would have
been supported in concept since day one if <A rel="embed"...> had been
used instead of <IMG>...

Larry, is the overhead of mime/multipart, combined with the cid: URL
proposal too high for this situation? Or is there something your
proposal provides which this wouldn't?

> I'd also like to see 'inline' as a protocol. Then the HTTP server sends a
> MIME/mutipart message with an HTML part, and GIF parts etc, and the HTML
> gets the inlined data from urls like <OBJECT SCR="inline:cool.gif">. Then
> they can be sent as a single doc.

See the cid: proposal. I've been wanting to mail around HTML docs with
inlined images in a seamless fashion for a *long* time now.


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- http://www.[hyperreal,organic].com/