Rendering cannot refer to an interstitial page

[azaroth42]

Can the rendering property refer to an interstitial page, or must it refer directly to the downloadable resource?

For example, we would like to replicate the experience of the download menu here: http://www.getty.edu/art/collection/objects/826/vincent-van-gogh-irises-dutch-1889/

When you select one of the download options, it takes you to a page where you fill in how you're going to use the image, and it collects different information for different uses. Clearly that menu can be replicated in rendering, but the expectation I imagine is that the id of the resource will be the thing to download, rather than a second step form to fill.

[workergnome]

I would assume that " the preferred viewing environment for that resource" means that it's acceptable to show that environment in a state that is not actively showing the resource. I don't think of the ID in this context as a URI to a data representation, but rather as a URL that points to a document or online experience that shows a version of the content.

At least, that's my 2¢.

[glenrobson]

We would use this if it was available probably to sell high resolution images. Currently we do this in the metadata:

http://hdl.handle.net/10107/1

'Buy a digital copy'

[jpstroop]

Generally 👍 on the 10 May 2017 community call, but open questions about the MIME type should be.

[tomcrane]

A client might be relying on the format of the rendering to generate UI for the available downloads (pdf, epub etc). If the format of the rendering has to be that of the interstitial page (usually text/html) this would not be possible.

[azaroth42]

To clarify the use case from discussion on the technical call:

The use case isn't authentication, just tracking usage if there's a human in the loop . The rendering would be just a reference to a IIIF Image URL, perhaps with some trigger to add Content-Disposition header to force a download rather then display. Thus using an intercept on the URL to require a redirect to the interstitial page would need to trigger off something other than just the URL.

That could be accomplished by the rendering having a non spec query parameter like default.jpg?form=true to bounce the client?

[azaroth42]

Confirm okay in Toronto.

[azaroth42]

New Proposal: Just use auth (see #547), and refer directly to the resource. The services.json file could describe a click-through that was presented by the IIIF client directly even, or be a login that captured the usage / shrinkwrap agreement.

[zimeon]

:+1: at Toronto WG meeting, one must refer directly to the resource

[zimeon]

Fixed by #1303