Re: Auto-Download tags/function?

Tony Sanders <sanders@BSDI.COM>
Date: Thu, 19 May 1994 17:08:40 +0200
Message-id: <199405191500.KAA00661@austin.BSDI.COM>
Reply-To: sanders@BSDI.COM
Precedence: bulk
From: Tony Sanders <sanders@BSDI.COM>
To: Multiple recipients of list <>
Subject: Re: Auto-Download tags/function? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: Berkeley Software Design, Inc.
Organization: Berkeley Software Design, Inc.
Martijn Koster writes:
> Dan wrote:
> > A looooooong time ago, I suggested:
> > 	<A HREF="ftp://host/file.tar.Z" CONTENT-TYPE="application/x-tarZ">
> > 	a tar file</a>
> I don't think this should be in the link either, it rules out protocol
> specific type negotiation.
> Different systems (protocols) need different methods to determine this

As Martijn says, ``content-type'' should not be a special keyword in the
anchor because it's not an attribute of the link.  If the protocol *can't*
type the data then the URL should allow some place to define this.  E.g.:
    <A HREF="ftp://host/file.tar.Z;{content-type=application/x-tarZ};">
Simply stated, protocol dependent parts should go in the URL space.

A ***BIG*** problem with the URL space right now is that it's not
extensible!!!!  So we can't add this without breaking things somewhat.
That issue really needs to be addressed.

The only solutions that I can see are to make it heuristic and define a
syntax that isn't likely to break any existing URLs, or add new protocol
types.  Either way, all browsers would have to be updated before we could
start using the new syntax but the sooner the better I would say.
Geez, what a mess.

So if we use something like ``;{...};'' that isn't likely to appear
in current URLs then we can remain 99.9% backwards compatible.

New protocol types using attr/value pairs might look something like:

BTW: (need I say it?) *IF* we go with something like the above the HTTP
request format would NOT change.  The additional information would go in
the headers somewhere.