Re: Auto-Download tags/function?

"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 19 May 1994 22:38:46 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405192034.AA11381@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 <199405192003.PAA01895@austin.BSDI.COM>, Tony Sanders writes:
>"Daniel W. Connolly" writes:
>> The way I understand it, the URI: header is a way for the server
>> to tell the client "here's the name for the document I'm sending you.
>> It's available in these formats, and that's it."
>> 
>> I don't understand how that allows me to represent, in a document,
>> a link to a specific format of a document.
>First of all, you don't want people creating links to specific formats,
>that defeats the whole point of format negotiation.  Stored links should
>be to the most varient form of the URI except in very special cases.

Ok... but I happen to be interested in "very special cases."

>What proxies need to know is more about how format negotiation works so
>they can short circut a request to a varient URI with something in the
>cache but your proposal doesn't do anything to address that.

I believe the proposal addresses exactly that situation: if the
link gives the content type, then the proxy is free to ignore
the possiblity that there are other content types, and serve
up the cached copy. I guess you have to do the same thing for
version, language, ... . The number of variant axes must be
set in stone, or this doesn't work...

>If all you want is links to specific data sets URI: works like this.
>Let's say you access http://www.bsdi.com/ and you get this back:
>    Last-Modified: Sunday, 08-May-94 20:48:20 GMT
>    Date: Thursday, 19-May-94 19:06:21 GMT
>    URI: http://www.bsdi.com/; vary=content-type,version,language
>    URI: http://www.bsdi.com/index; vary=content-type,version,language
>    URI: http://www.bsdi.com/index.html; vary=language,version
>    URI: http://www.bsdi.com/En_US/index.html; vary=version
>    URI: http://www.bsdi.com/1.19/En_US/index.html
>    Content-Language: en_US
>    MIME-Version: 1.0
>    Content-Type: text/html
>Then you know that http://www.bsdi.com/1.19/En_US/index.html (for as long
>as it's valid) will return the exact same bits as you have in your hand
>right now and you know that those bits are text/html in en_US.

Ah! The lightbulb goes on! I thought the server would just give:
	URI: http://www.bsdi.com/; vary=content-type,version,language
and that's it. This business of giving lots of URI: headers certainly
does address some of my concerns. I'll have to meditate on it a while
to see if it solves the whole problem I'm interested in.

>Please explain and give a specific protocol transaction where your scheme
>of encoding the content-type in a standard way inside the HTTP URL is any
>better than this.

Nope. This is sufficient. It's nearly equivalent: it's just a question
of what's explicit where vs. what's implicit where.

Hmmm... it seems that putting type info in the link is still
useful for FTP, though.

Thanks for clearing this up for me.

Dan