Ernest,

> I've taken the time to make a thorough look at the type attribute.
> I've reached somewhat different and considerably more detailed
> conclusions than what I had before, which I explain in detail below.
> These conclusions are:

thx, that gives us something to work on

> 1) The type attribute is not needed for resources retrieved using
>    HTTP or other protocols that provide a mechanism to indicate
>    the MIME type(s) of the resource.

it is never needed, but always recommended; we needn't depend on the protocol here:
as you say yourself in point 3), @type should be used to determine if the resource will be retrieved by the user agent.
even with HTTP, it might be regarded useful for the UA *not* to contact the remote resource at all before deciding whether or not to fetch the file. (e.g. dial-up connection, page displayed offline; user will prefer UA not to occupy the phone line only to find out that it does not support PNG.)

> 2) For those protocols for which a type attribute is needed,
>    a single valued type attribute containing but a single MIME type
>    is sufficient. Thus in the interest of simplicity and consistency,
>    the type attribute should keep its HTML4 format of a single type.

agreed. it's not only for simplicity and consistency, i couldn't see a UA successfully "simulate" (as the current draft puts it) HTTPs behaviour in all possible situations; with multi-valued @types, we're bound to have browser dependent peculiarities when not using HTTP.

> 3) The type attribute when present should be used  to determine
>    if the resource will be retrieved by the user agent.

agreed.

> 4) XHTML2 should define what happens if a retrieved resource
>    does not match the type attributed to it via the type attribute
>    or other method.  At a minimum, a user agent must be able to
>    provide an error message to the user and to present what
>    would be presented, had the resource not been retrieved.
>   Additional options as to what to do might be offered to the
>   user if they so choose.

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.) 

regards,
oskar