Media types of Readium publications

[qnga]

I think Readium shoud conform to RFC 6838 on media types. With the current strategy, we are contributing to the global mess and could soon end up with conflicts.

A Readium Web Publication may also be distributed as a separate package where its media type must be application/webpub+zip.

While the Audiobook Manifest is technically a profile of the Readium Web Publication Manifest, it has its own media type in order to maximize compatibilty with audio apps: application/audiobook+json.

All LCP for PDF packages must use:
- the .lcpdf extension
- the application/pdf+lcp media type

Media types from the standard tree (without a prefix) must be registered and are reserved to recognized standards. Otherwise, a type in the vnd tree can be registered with the IANA, or the x tree used mainly for internal purposes. Suffixes should not be used with unregistered types, and are intended to indicate conformance to a general syntax, not to give additional information.

I think readium formats are intended to be publicly used, so some media types should be registered in the vnd tree. I guess we should have for example application/vnd.readium.webpub+json, application/vnd.readium.webpub+zip, application/vnd.readium.audiobook+json, application/vnd.readium.divina+json or application/vnd.divina+json since divina is enough specific.

If registration is not possible for any reason, I guess a systematic application/vnd.readium prefix should prevent conflicts.

[jccr]

very much in favor of this 👍

[llemeurfr]

The Readium WebPub Manifest and the associated packaged format are internal to the Readium project. Their destination is not to become an international standard, they not even meant to be used outside of Readium modules.

so some media types should be registered in the vnd tree

Because they are internal formats, we don't need to register our media types via IANA: registration of a mime type is a cumbersome task (we just did it for the W3C LPF format) and we have better things to do.

But reading rfc6838 on the .vnd branch, I see that "... public exposure and review of media types to be registered in the vendor tree are not required ...".

I therefore suppose that we can simply rename our media types with a vnd.readium prefix and avoid sending any review request to IANA.

But ... we must be careful not to break all implementations (including those which use OPDS feeds we do not control) if we decide to apply this modification. Are you confident it is the case?

Note: DiViNa may become a special case. Either (after the current incubation) our descriptive JSON structure will be accepted as-is by a W3C WG and "injected" into a W3C manifest, in which case it will become a new profile of W3C Web Publications, or we will create an EDRLab industrial standard out of it. In the latter case, application/vnd.readium.divina+json or application/divina+json will have to be registered via IANA as an interchange format.

[HadrienGardeur]

I think the list of candidates for "true standard" goes beyond DiViNa:

• LCP for both PDF and Audiobooks are IMO proper candidates for ISO since we're already going down that road for LCP + EPUB
• OPDS 2.0 is also meant to be registered in the main branch and not the vendor one once it becomes a stable release

This does raise a question about RWPM itself since all four "candidates" are based on it.

It's not uncommon for W3C or IETF drafts to declare a new media type in the media branch, even though some of these drafts never become recommendations. IMO we're in a similar spot right now and I'm wary about taking such decisions.

[qnga]

I therefore suppose that we can simply rename our media types with a vnd.readium prefix and avoid sending any review request to IANA.

I have a quite different interpretation of the RFC. I think it says that, in the vnd tree, public review of media types are not required before registration (so the procedure is simpler than in the standard tree), but registration still must be done. Unregistered media types, used for internal purposes, should be prefixed by x, not by vnd.

Whether or not Readium conforms to the RFC, it would be interested to clarify for each format whether it is intended to be public or not.

Either (after the current incubation) our descriptive JSON structure will be accepted as-is by a W3C WG and "injected" into a W3C manifest, in which case it will become a new profile of W3C Web Publications, or we will create an EDRLab industrial standard out of it.

That's the reason I think DiViNa media type should be prefixed by vnd before any draft is initiated by a standards organisation. If eventually DiViNa becomes a new profile of W3C Web Publications, it would require a new media type.

Concerning publications protected by LCP: what about an optional parameter? For example application/vnd.readium.divina+zip;protection=lcp

[mickael-menu]

Concerning publications protected by LCP: what about an optional parameter? For example application/vnd.readium.divina+zip;protection=lcp

I like this. It's probably not valid but it would be useful to add it to EPUB as well, at least as an internal media type for storage.

application/epub+zip;protection=lcp

Subtype names with "x." as the first facet may be used for types
intended exclusively for use in private, local environments. Types
in this tree cannot be registered and are intended for use only with
the active agreement of the parties exchanging them.
RFC 6838

@qnga I didn't know about this x. facet, that would probably solve my problem here. And we could use it as well to differentiate a W3C WPUB Manifest, which uses JSON-LD media type.

[qnga]

Let me give some details about suffixes:

"+suffix" constructs for as-yet unregistered
structured syntaxes SHOULD NOT be used, given the possibility of
conflicts with future suffix definitions.

Actually there is a registry of suffixes. I am not sure about that, but registering a media type with an unregistered suffix might be impossible.

So, in case some Readium formats are meant to become standards with a registered media type, a registrable suffix should be chosen. Is lcp suffix registrable? I don't know.

XML in MIME [RFC3023] defined the first such augmentation to the
media type definition to additionally specify the underlying
structure of that media type.

We can imagine lcp suffix means: readium manifest + lcp license embedded in a ZIP archive, but lcp is a strange choice to say that.
Currently registered suffixes are very low-level syntaxes, i.e. they describe syntax without semantics to allow a more generic process of the content than with the knowledge of the semantics.

[HadrienGardeur]

During the call yesterday, three proposals were discussed:

1. Keeping everything as-is (use the 🎉 emoji for a vote)
2. Moving all media types to the application/vnd.readium. prefix (use the 🚀 emoji for a vote)
3. Moving only media types that are not potential standards to the application/vnd.readium. prefix (use the 👀 emoji for a vote)

The list of media types that are potentially candidates for a real standard are:

• application/divina+json
• application/divina+zip
• application/divina+lcp
• application/pdf+lcp
• application/audiobook+lcp
• application/opds+json
• application/opds-publication+json

The following media types are not prime candidates but would be the base formats for the media types listed above:

• application/webpub+json
• application/webpub+zip
• application/audiobook+json
• application/audiobook+zip

There's also a media-type for the Position List: application/vnd.readium.position-list+json
This is already a good example of using the vendor branch for internal formats. Future services would also follow that convention.

[HadrienGardeur]

My personal preference is to keep thing as-is and revisit this in the future:

• the only media type that would've been problematic is already using the application/vnd.readium. prefix
• we have far more media types that are potential candidates for registration than not
• several organizations already use these media types in production

[mickael-menu]

I agree with Hadrien, the incorrect media types are only used internally and that could be a bit too disruptive for the older implementations.

However, I will use the x. facet for Zipped Audio Book and W3C WPUB Manifest in the Format proposal.

[HadrienGardeur]

After a vote and a discussion during a weekly call, we've decided to keep things as-is for now.