Re: Auto-Download tags/function?

"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 19 May 1994 17:39:42 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405191533.AA10779@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Auto-Download tags/function? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0

In message <199405191500.KAA00661@austin.BSDI.COM>, Tony Sanders writes:
>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>
>
>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.

OK. Stick it in the URL. As long as it can go in the source anchor
somewhere, I'm happy. I generally like the idea of using the SGML
parser to handle syntactic issues, but if folks like to use the
URL syntax cuz it's short and sweet, that's fine by me...

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

This is one of the reasons why I wanted to use the SGML parser to
do these things... If we had coded URLs all along as:

	<A linkend=ftp1>link</a>
	<ftp id=ftp1 host="foo.com" dir="/abc" file="foo.txt">

then we could add this attribute to the FTP element with confidence
that we wouldn't be breaking anything.

On the other hand, a lot of folks would have said "What a pain!"
and perhaps WWW wouldn't be as popular as it is today... Who knows?

>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.
>    ftp://host/path/file;{attr=value,value;attr=value};

Well, the current spec reserves the characters ; and = for this
purpose. I don't know how many implementations comply, nor how
many existing URLs violate this constraint, but I support
the idea of allowing:

	ftp://host/path/file;attr=value;attr=value

>New protocol types using attr/value pairs might look something like:
>    anon-ftp:h=hostname:p=port:p=/pub/README:content-type=application/x-tarZ

First, I think anon-ftp is a bad example. anon-ftp: already exists...
it's just called ftp: most of the time :-). Second, I suggest the
slightly different syntax:

	scheme:/path;param=value;param=value

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

Right. You can write:
	HREF="http://host/path"
and the client will tell the server all the content-types it Accepts:
Or you can write
	HREF="http://host/path;content-type=applicaiton/postscript"
and the client should tell the server that it will only Accept: the
postscript version of the document.

It's doable.

Dan