Ernest,

> > I'd rather stick to HTML 4.01 here:
> > in case the MIMETYPE of the resource retrieved differs from
> > what @type says, the UA should simply forget about @type
> > and do what it would normally do with this kind of content
> > (which, of course, *might* be to display an error message).
> > the point, again, is: @type should be a hint about what will be
> > on the other end of the line, so that the UA can make
> > decisions *before* contacting the remote resource. as soon
> > as the file is retrieved, though, we usually know what it is - and
> > can act upon facts rather than upon hints. (of course, it may
> > happen that after retrieving a file, we still don't know what it's
> > supposed to be. in this case, again, the UA should try to
> > apply the MIMETYPE given by @type. if this doesn't work,
> > we'll have to present an error message.) 
> 
> Actually, I wasn't referring to what to do in the case of a
> discrepancy between the type attribute and the Content-Type
> header returned by HTTP.  But if for example the Content-Type
> says that it is "image/jpeg" but the resource returned is not
> of that MIME type, what is the user agent to do?  I think
> requiring the user agent to be able to both inform the user
> of the problem and make use of the alternative content
> while allowing the user agent to provide the user with other
> options of how to handle this error condition is reasonable.

I wasn't referring to the content-type header either but to the actual data type. (i know, HTML 4.01 does refer to the HTTP header here - doesn't make too much sense.)
i'm still not sure about the necessity of informing the user and using the alternative content.
if you explicitely include src="logo.gif" and for what reason ever type is "image/png", why not simply display the gif retrieved and don't tell the user anything?
you know, once we accepted that @type is a information only to be used only as long as the real mimetype of the file is not known, and that the real mimetype will take precedence over the type-value, it should be a logical consequence that @type gets ignored alltogether as soon as the real mime type is identified. this includes not caring about a possible inconsistency here and not presenting any kind of error message to the user.

see, if it's @src and only @src that uniquely identifies the remote resource, it's no error at all if the mimetype of the resource differs from a @type attribute that was needed only before the resource was known.


regards,
oskar