Re: Generalising inlined images

Tony Sanders <sanders@bsdi.com>
X-Delivered: at request of secret on dxcern.cern.ch
Errors-To: sanders@bsdi.com
Message-id: <9310070002.AA05701@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Generalising inlined images 
In-Reply-To: Your message of Wed, 06 Oct 93 14:06:38 -0800.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 06 Oct 1993 19:02:48 -0500
From: Tony Sanders <sanders@bsdi.com>

I'm sorry, I confused a couple of issues here (shame on me).  However,
we are further apart than I thought...

kevin@scic.intel.com (Kevin Altis) writes:
> Yeah, yeah, yeah, we know all that, what's your point. Well, a couple of things.
> I think we might be better off making <IMG SRC...> and <INC SRV...> into a
> single "inclusion" tag with a modified syntax to support an arbitrary set
> of inclusion types. What I have in mind is to put the MIME types into the
> tag syntax so you might do <INC text/html="..."> or <INC image/gif="...">
> or <INC sound/wav> or <INC x-command/. This simplifies the syntax and at
> the same time allows a lot more flexibility than we currently have. The
<INC> isn't part of HTML.  It's a hack in the NCSA server.  It's a
simple macro expansion.  It has nothing to do with HTML or <IMG>,
nor should it.
[   My personal problem with <INC> is just that it tends to generate email
    for me since people don't understand why foo.html doesn't work anymore
    when they switch servers.  If, for example, the NCSA server required
    the files to be called foo.ncsa before <INC> worked I wouldn't care.
    I understand *why* they did this (because some naughty HTTP0 browsers
    look at the URL) but that doesn't mean I have to like the email :-)
]

You are confused about the file extension issue.  I'll not explain it here
for fear of further confusion.  Suffice it to say that this is a non-issue,
HTTP/1.0 objects are self-typing, no file extensions are looked at.

On moving this type of functionality into HTML (call it <IMG> <EXTERN>
<EMBED> or whatever), my basic argument still stands, one does not want
to type the reference to an object (HREF).

For example, a particular instantiation of the object:

    <A HREF="http://www.bsdi.com/setext/usenet-email.etx">

might look like this (this is an actual example, try it):

    HTTP/1.0 200 Document follows
    Last-modified: Monday, 28-Jun-93 16:27:47 GMT
    Date: Wednesday, 06-Oct-93 22:53:02 GMT
    Server: plexus/3.0i
    MIME-version: 1.0
    Content-type: text/html

    <TITLE>Usenet and Email Hypertext</TITLE>
    ...html document here...

Note the content-type.  This does *not* depend on the file extension, it
only depends on the object.  This object happened to begin it's life as
text/x-setext and got converted on the fly to text/html because the browser
doesn't support text/x-setext.  If you had typed the link and the browser
didn't support text/x-setext you wouldn't be able to read that document.
To see the "source" try: http://www.bsdi.com/setext/usenet-email.etx.txt

--sanders