Re: Value of content negotiation? [was RE: content negotiation anti-principle]

I'll claim some responsibility for the introduction of content
negotiation
into HTTP; at least, content negotiation was a key part of the PARC
"System 33", and was the subject of much discussion during Tim's
sabattical at PARC in 1992, and appeared in HTTP well after that.

In the 1992 System 33, content negotiation worked OK: there were six
different clients, and each client had perhaps five or six
formats that it understood.  However, the concept doesn't scale
very well, for several reasons. First, content negotiation was
introduced in a world that predated the NCSA Mosaic introduction
of "img" tags, and the necessity of a separate transaction (and
separate data types) for each embedded image. And it wasn't designed
for today's PC world where a typical workstation has software
that understands hundreds of different file formats.

So as a design element, it hasn't done well as the rest of
the web has evolved.

One of the problems that remains is to allow the web to
evolve: how can we ever introduce a new format/type in
a distributed world? If we invent PNG2, how can a server
tell that it can serve PNG2 to new clients but must keep
PNG for old ones?  I think that's the most compelling use case,
and it isn't one that will naturally be solved through 
local selection, because local optimization doesn't require
evolution.

I think evolvability is an important criteria for a good
architecture for the web, and having source documents contain
the MIME types of the expected formats from the target of a URI
would get in the way.

Received on Wednesday, 15 January 2003 22:34:56 UTC