Romain Deltour

> are there any strong reasons for wanting this change? One reason would be better interoperability between reading systems. Another is that there seems to be security considerations involved. HTML...

To be clear, I'm not aware of any concrete problem that fixing this would solve. I went down that spec rabbit hole when trying to answer the question "what is...

FWIW, I ran a little experiment with the attached EPUB ([mimetypes.zip](https://github.com/w3c/epub-specs/files/10123477/mimetypes.zip)). It contains: - a PNG image named "png.png" and declared in the package document with the expected `image/png` MIME...

@bduga > And even if we wanted to require (or suggest) that reading systems make sure the MIME type given in the package doc actually matches the MIME type of...

> Looking at this again, I was thinking the original prose was requiring reading systems to verify the media type, but if all this is asking is that reading systems...

Here's a proposal: Create a new section in [3. Publication resource processing](https://www.w3.org/TR/2022/CRD-epub-rs-33-20221206/#sec-pub-resources), before all other sections, which would say something like: > 3.1 Determining the type of a resource >...

(the note above could also add, informatively: > Reading systems may use the MIME types provided by the author in the package document `item` elements as the supplied MIME type...

@mattgarrish > > MUST ... in a manner consistent with ... > > Is there a way to make this more precise? I've taken this language [from HTML](https://html.spec.whatwg.org/multipage/urls-and-fetching.html#content-type-sniffing). @bduga >...

> Dave Cramer: if someone can come up with a test that behaves different in different RS, or finds an example in the real world, definitely bring it up in...

> why not slugify by yourself? Decoupling the AST from the slugifyer seems to be a better architecture. Yeah, I agree that with the current approach it is not critical...