> ...If the requested url happens to be something like
> http://a.b.com/x.html, the chances of this resource being, say, a
> JPEG are pretty slim it seems to me....
> <img src="c.xyz" mimetype="image/jpeg">...
If you're going to hardwire the media types into the referring
document (either in the URL or in an attribute), you're defeating the
whole purpose of content negotiation.
It is true that, de facto, http:...html is almost certainly HTML and
http:...jpg is almost certainly JPEG. We could enshrine this in the
URL definition, I suppose, although that would make it hard for people
with existing documents (and links to them) to upgrade to content
negotiation.
It is also true that in references to resources under the referring
document's author's control, you can try to keep all your references
up to date, and if you only make available one form of a resource, the
URL might as well reflect that. But this defeats outside links into
your resources, which is one of the strengths of the Web.
You might think that you could at least know that something is text,
or an image, a priori, and only specify preferences for text types,
say. But think about the possible useful representations of a
mathematical formula, a Chinese text, or an engineering diagram. Are
these texts? images? application-specific? All three can be
_usefully_ represented as Postscript/PDF or as GIF, and perhaps even
as Java programs. The first two can _usefully_ be represented as HTML
(assuming formulae and character coding get solved), or as audio for
the visually impaired. The third can perhaps be usefully represented
as VRML or any of a number of other application-specific CAD or Draw
formats.
I don't claim to have a good solution to the header size problem, but
I hope the above helps clarify some of the requirements.
-s