W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

Re: [URN] HTTP resolution protocol

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 5 Nov 1996 00:18:24 +0100 (MET)
Message-Id: <199611042318.AAA16118@wsooti04.win.tue.nl>
To: Fisher Mark <FisherM@is3.indy.tce.com>
Cc: rdaniel@acl.lanl.gov, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1878
Fisher Mark:
>

>>How about:
>>   1) We define text/uri-list as a new media type?
>>   2) We allow the Accept: header to be used to pick between returning
>>      the result as text/html or text/uri-list.
>>
>>I think that the primary use of the lists will be for automated processing,
>>thus the new media type allows us to launch those content handlers easily.
>>Clients that don't support text/uri-list have a fallback that will allow
>>humans to pick URI if necessary. New clients of the agent variety should
>>use text/uri-list.
>
>Sounds OK to me.  Automated processing is important!

Hmmm.  This is starting to sound like the use of variant lists in
transparent content negotiation.  What does a `HTTP resolution
protocol' do?

By the way, it is OK for a protocol extension on top of HTTP/1.1 to
extend (i.e. be inconsistent with) the HTTP/1.1 semantics of the
Accept header.  A protocol extended server should however be careful
to avoid that responses inconsistent with HTTP/1.1 end up at plain
HTTP/1.1 clients.  This means in particular that you have to be
careful in making your responses cacheable.

>Mark Leighton Fisher                   Thomson Consumer Electronics

Koen.
Received on Monday, 4 November 1996 15:35:29 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC