- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 5 Nov 1996 00:18:24 +0100 (MET)
- To: Fisher Mark <FisherM@is3.indy.tce.com>
- Cc: rdaniel@acl.lanl.gov, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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