Media type parameters for EPUB

[HadrienGardeur]

While all EPUB files share the same media type and file extension, there are a number of things that can make a specific file impossible to open or render correctly on a given device and/or app.

The top two reasons why you might not be able to render an EPUB correctly are:

• FXL
• use of a specific DRM

Adding these two info in the media type of the EPUB would make it possible for apps to trigger specific behavior: for instance an OPDS client could display a warning when downloading an FXL EPUB or it could disable the download button if the file is protected by an unsupported DRM.

[GarthConboy]

Do you mean something additional in the package? Or augmenting "application/epub+zip" (and ".epub")?

[HadrienGardeur]

Nothing in the package, just a media type parameter.

For example this could be:

• application/epub+zip; layout=pre-paginated
• application/epub+zip; drm=lcp

[TzviyaSiegman]

Wouldn't this break backward compat, the whole goal of 3.2?

[HadrienGardeur]

I don't think media type parameters would break anything.

[GarthConboy]

Probably okay from a backward compatibility perspective, as it's serving time only. But, I do kinda worry about information duplication (from package and encryption.xml, respectively), and the need to define a couple of more vocabularies.

[iherman]

It depends. Proper HTTP toolkits or media type 'managing' libraries separate the media parameter from the rest, ie, if a client is not interested in those (as now) then the new parameters would not bother anyone. However, it is not impossible that some tools parse the media type 'by hand', via some regular expression, for example, and does not take the extra type into account: those may get it wrong. One could argue, though, that such implementations should be considered as buggy...

[HadrienGardeur]

But, I do kinda worry about information duplication (from package and encryption.xml, respectively), and the need to define a couple of more vocabularies.

In the case of an API (like OPDS), this wouldn't be duplication since this could trigger specific behaviour before you download that file.

For FXL publications, some of them can be massive. It would make a real impact (not in a good way) if we had to download those to figure this out.

[murata2makoto]

Media type parameters are hard to sell.

In my understanding, EPUB A11Y recommends that bookstores should extract metadata from EPUB publications and use it for filtering of EPUB publications. I think that we should do the same thing.

[HadrienGardeur]

Bookstores typically receive this kind of information in ONIX where there are specific tags and code lists.
This can identify if an EPUB is an FXL or interactive, and it can identify which DRM is used.

But we need a solution that works for everyone and is not dependent on ONIX.

[dauwhe]

Just to confirm, you're proposing that the mimetype file at the root of the package would optionally contain a media type parameter, with new values to be determined?

[HadrienGardeur]

No, I'm proposing that we update our IANA registration to include additional parameters that would be used in HTTP headers and hypermedia APIs.

If you already have the package, it's too late too rely on such hint.

[BigBlueHat]

There's a separate parameters registry, fwiw: https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml

If the application/epub+zip definition does get an update, perhaps using this separate registry for parameters would serve long term goals better than updating the media type definition every time a parameter is added.

However, I'd share @dauwhe's concern that adding these to the mimetype file should be tested thoroughly as I'd be concerned that implementers may only be doing string matches at that level.

[dauwhe]

Consensus on the CG call today was this was not something we're ready to due with the 3.2 revision. With more implementer interest it would be worth discussing for EPUB 4.

[iherman]

The issue was discussed in a meeting on 2021-03-04

List of resolutions:

• Resolution No. 1: Close issue Media type parameters for EPUB #1026, will not implement

View the transcript

1. Media type parameter for EPUB

See github issue #1026.

Wendy Reid: epub type parameter would add hint to epub mime type about the specific epub
… e.g. is it FXL? Does it have a special DRM?
… these hints can be interpreted by RS for specific functionality
… there was a concern about backwards compatibility, but it was determined that that wasn't really an issue
… however, a lot of this same info can be found in package metadata

Brady Duga: clarify that this is changing IANA registration, not the mimetype file

Wendy Reid: benjamin posted that there is an existing registry of IANA properties

Matthew Chan: dauwhe joining by call-in

Dave Cramer: without interest from multiple implementers I'm not sure that we should invest in this issue speculatively

Proposed resolution: Close issue #1026, will not implement (Wendy Reid)

Matt Garrish: +1

Brady Duga: +1

Masakazu Kitahara: +1

Marisa DeMeglio: +1

Wendy Reid: +1

Toshiaki Koike: +1

Matthew Chan: +1

Resolution #1: Close issue #1026, will not implement