Addition of http protocol for retrieving remote metadata records

[mattgarrish]

EPUB 3.1 now defines how reading systems request remotely-hosted metadata records, and how the servers hosting the metadata should respond to such requests:

https://rawgit.com/IDPF/epub-revision/master/build/31/spec/epub-packages.html#app-meta-protocol

There are currently a number of open issues in the tracker that have yet to be addressed: #686, #687, #688, #689 and #702.

The working group is seeking additional feedback concerning the implementability of this protocol, and will address in a future draft.

Additional suggestions and proposals can be added as comments to this issue.

[bduga]

I have added a few more issues, #705 - #709.

On Mon, Apr 25, 2016 at 6:01 AM Matt Garrish notifications@github.com
wrote:

EPUB 3.1 now defines how reading systems request remotely-hosted metadata
records, and how the servers hosting the metadata should respond to such
requests:

https://rawgit.com/IDPF/epub-revision/master/build/31/spec/epub-packages.html#app-meta-protocol

There are currently a number of open issues in the tracker that have yet
to be addressed: #686 #686,
#687 #687, #688
#688, #689
#689 and #702
#702.

The working group is seeking additional feedback concerning the
implementability of this protocol, and will address in a future draft.

Additional suggestions and proposals can be added as comments to this
issue.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#703

[acabal]

Sorry if this has already been discussed, but why are we defining a metadata transmission protocol in an ebook file specification in the first place?

Seems a little unnecessary to me. The spec appears to be trying to pin down some subset of http, but I think that approach will inevitably run in to unexpected edge cases and will produce unnecessary complexity. We're already seeing that with the bevy of issues just opened about this. http evolved over decades and trying to cherry-pick features to include in a frozen-in-time epub file will lead to headaches for everyone involved.

We're leaving the realm of an ebook format spec and entering the realm of an ecosystem spec. Why not leave it to the RS to interpret the URI, with the spec merely recommending using http/s if possible, and a soft failure case if the URI is a protocol not supported by the RS?

[bduga]

@acabal I was wondering the same thing, actually. I wasn't involved in these discussions, so I don't know all the background.

[mattgarrish]

It came up in the metadata group as a request for more precision about the communication between RS and server, as it was suggested that it could lead to non-implementation if the RS didn't know what to send or what kind of response it would get.

I missed the discussions in Bordeaux, so I can't really say more about it than that. There are some notes at: https://docs.google.com/document/d/1k_mLviZc1NuHL--FXV9LxFVlGo4gdldSUBMRARcP3XY/edit#bookmark=id.tobtmbybvpi4

[acabal]

Well a glance at the spec suggests that

Linked resources that are not Publication Resources are not subject to Core Media Type requirements

indicating that you can link to nearly any kind of format; and it acknowledges that complexity in

Due to the variety of metadata record formats and serializations that can be linked to an EPUB Publication, and the complexity of comparing metadata properties...

So if I'm reading that right, from the perspective of non-implementation risks IMHO the more glaring issue is getting an RS to understand a linked record at all, not defining what flavor of http it uses to get the record. What use is defining a quirky subset of http if the RS can't even parse the result?

IMHO a better area of focus for getting RS's to implement metadata fetching is blessing a single file format and data layout, with a suggestion, but not a definition, of the protocol used to fetch the format. Something like, "Use an XML file and schema.org, which we recommend be fetched over https."

(Though I think we had a fine thing going with epub 3.0's packaging metadata--and if RS's couldn't parse that, no way will they bother implementing an http client and parsing a linked record anyway.)

[mattgarrish]

It is going to be something of a niche need, I expect. The ambition is to stop epub becoming a dumping ground for metadata needed by various branches of publishing because the needed information isn't expressable in dublin core or by the meta tag. If there is a common record format for a branch of publishing, it can be attached. If a reading system understands that format and can make use of the richer information in, it is available to it.

We're not trying to define a common record format and have it live outside the container. I think remote records are probably a niche need within a niche need. It's arguably more practical for the record to travel inside the container, in which case a protocol isn't needed at all. The disadvantage is that it doesn't allow live updating by the creator, but given that vendors typically ignore linked records we may only be talking about use for side-loaded content.

[acabal]

If it's a niche-within-a-niche need, then most RS's are unlikely to develop support for it, regardless of what the spec demands, thus rendering non-implementation concerns practically moot. So why complicate things with complex subsets of existing specs, when we can just point to an existing protocol spec (like https) as a recommendation, and otherwise require RS's to negotiate URIs in whatever way they please?

[HadrienGardeur]

Fully agree that we shouldn't try to define a subset of HTTP.

I believe that we can limit this section to a smaller number of statements, most of them should be recommandations rather than MUST statements.

It also makes sense to extend this to all remote resources and not just metadata records.