Re Mime sniffing, the minutes reported:
Nobody in the group objected
to having this move to WHAT-WG, and according to Larry Manister, the
W3C is also fine with referencing the WHAT-?WG document, so the work
item will be removed from our charter.
I did not say this. What I said in the meeting
Going back to the scope question, should the mimesniff document cover
sniffing in contexts other than browsers, e.g., by web servers during file
upload, by proxies or firewalls or gateways, by spiders or search engines, etc.?
Within the browser context, does it cover sniffing in special
I think it would be really helpful to have a test suite for MIME sniffing where
we can test out what browsers do and various cases where sniffing *should*
improve the experience, as well as test cases where sniffing makes things
worse, if there are some.
Probably focusing on the test suite
I don't understand, Philip. A central case of this document involves taking
documents that look like text/html but are labeled as text/plain and sniffing
them to be text/html after all.
It's claimed that this is necessary, part of most browsers today, regular
practice, etc.
Are you opposed to
It's been emphasized that there is no reason why third parties can't register
media types if they're wanted. So there should be no barrier to specifying
content-type for fonts, if that's what is wanted.
Why is it a lost cause when no one even tried?
Larry
-Original Message-
From:
I'd meant to do more careful write-ups of the issues I put into the tracker,
but I've put in the main issues left over from draft-masinter-mime-sniff.
The document also contains several sections (on sniffing fonts, for example)
which are left as TBD. I suppose each of those is a separate issue
- in which way is it more certain that there is no mislabeled PDF than a
mislabeled jpg or mislabeled rtf?
I don't think this is relevant. There is likely mislabeled PDF. But I had
specific feedback from implementors of PDF readers that sniffing from other
content-type resulted in a worse
Agree with this one.
With one addition: it must be clear, that if you opt-in for sniffing, than
you MUST (SHOULD?) follow the mime-sniffing algorithm.
I don't think that's possible. I think the crux of this issue is that I don't
think the mime-sniffing algorithm is currently structured in a
First you determine the content-type and then after that you may want to
determine the charset used within that content-type
That's wishful thinking that doesn't match what has to happen ... the
mime-sniffing document ALREADY is looking at the charset, by looking for
byte-order-mark
