This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From http://trac.tools.ietf.org/wg/websec/trac/ticket/15 Take the bullets in reverse order: The specification covers "situations where the content is not being delivered via HTTP at all, but via other protocols." http://mimesniff.spec.whatwg.org/#determining-the-supplied-media-type-of-a-resource line 3 "If the resource is retrieved directly from the file system, set supplied-type to the media type provided by the file system." So the specification covers resources retrieved by the file system. However, neither the abstract nor the introduction mention that it covers sniffing of resources retrieved from the file system. So the *Scope* of the specification -- what it says it is about, the justification for having it, in the introduction -- does not match the actual content of the document. It isn't clear that the algorithm for sniffing from file systems matches what browsers do or should do. The same is also true of resources retrieved by other methods, including ftp: URIs, which are still quite common on the Internet. The specification covers "situations where no content-type is supplied at all via HTTP." Adam Barth replied "For bullet 3, a correctly configured web server will always supply the correct MIME type with a response, but that's just a matter of semantics." but http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-3.1.1.5 says explicitly A sender SHOULD include a Content-Type header field in a message containing a payload body, defining the media type of the enclosed representation, unless the intended media type is unknown to the sender. If a Content-Type header field is not present, recipients MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the representation data to determine its type. That is, the HTTP specification allows for client sniffing and explicitly allows it. The abstract does not mention this use case, and it's not clear that the same sniffing algorithm is appropriate. NOTE: Fixing this may be difficult, but PLEASE at least acknowledge in the draft that the issue is open or that behavior is currently unspecified, rather than leaving readers to think that the spec is complete.
Now that I've gotten a fuller handle on this document and what it is for, I can better address any concerns about scope. However, it's not clear to me, based on comment 0, precisely how many separate concerns there are, or whether they still apply to document as it stands now (or will be in the future). Can you provide me with a simplified, bulletted list of outstanding issue with regard to the scope of the MIME Sniffing Standard. (Is the question of scope one that is IETF-specific?)
Closing in favor of https://github.com/whatwg/mimesniff/issues/51