Following up to Martijn's observations on the ZTK, I'd like to propose a clean-up of how we handle content types. There are several unrelated pieces of code concerned with content types, these include at least zope.contenttype, zope.mimetype and zope.publisher.contenttype. - zope.contenttype does some content-type guessing from file names. It's just a few lines of code and comes with a table of some 30 associations of file-name extensions with content types. - zope.mimetype is a more substantial package that deals with content-type specific marker interfaces. - zope.publisher.contenttype contains a parser for content-type specifications. I propose merging those two packages and one module into one package, zope.contenttype. At present, zope.contenttype doesn't have any dependencies within the ZTK, and zope.mimetype depends on zope.configuration, zope.component and zope.interface. zope.publisher.contenttype doesn't import any zope code. - Switching packages that depend on zope.mimetype would therefore add no additional dependencies to them. - There are three packages within the ZTK and the set of packages under review which depend on zope.contenttype: zope.browserresource, zope.app.file and zope.app.onlinehelp. All of them already depend on zope.mimetype's dependencies, so there's nothing to be lost for them either. - Finally, the same holds for zope.publisher which would only acquire a new dependency on zope.contenttype if zope.publisher.contenttype were to be merged with the latter. Further, the parser in zope.publisher.contenttype needs to be made more conformant with RfC 2045 and be used by other code that does some content-type matching of its own right now, such as zope.publisher.http. -- Thomas