This camps on the q-param namespace that normally belongs to the application. I'm shocked this would be considered. The only way to do this without camping on

This camps on the q-param namespace that normally belongs to the application. I'm shocked this would be considered. The only way to do this without camping on the q-param or fragment namespaces is via a new URI scheme, but then that would be very difficult to deploy anytime soon. This is a quandary that is usually resolved by camping on the namespace, yes, but with some very unlikely name (think of the IDNA xn-- A-label prefix). Also, there is some value to doing this via a fragment identifier as an alternative: you can distribute the link with the digest, but the server you request the link from doesn't get to know what digest you have. This could be useful for immutable resources. Also, maybe the request for a particular version identified by a particular digest could be done with an HTTP header, which then lends itself to making for a conditional request ("GET /this/thing, but only if it has different digest than I last saw"), which, again, would best be done using a fragment identifier if we're not going to do a new URI scheme. My preference is still for a new URL scheme, much like the data URI scheme.