Erik Hetzner wrote:
Accept-Encoding is a little strange. It is used for gzip or deflate
compression, largely. I cannot imagine needing a link to a version
that is gzipped.
It is also hard to imagine why a link would want to specify the
charset to be used, possibly overriding a client’s preference. If my
browser says it can only supports UTF-8 or latin-1, it is probably
telling the truth.
Perhaps when the client/user-agent is not actually a "web browser" that
is simply going to display the document to the user, but is some kind of
other software. Imagine perhaps archiving software that, by policy, only
will take UTF-8 encoded documents, and you need to supply a URL which is
guaranteed to deliver such a thing.
Sure, the hypothetical archiving software could/should(?) just send an
actual HTTP header to make sure it gets a UTF-8 charset document. But
maybe sometimes it makes sense to provide an identifier that actually
identifies/points to the UTF-8 charset version -- and that in the actual
in-practice real world is more guaranteed to return that UTF-8 charset
version from an HTTP request, without relying on content negotation
which is often mis-implemented.
We could probably come up with a similar reasonable-if-edge-case for
encoding.
So I'm not thinking so much of "over-riding" the conneg -- I'm thinking
of your initial useful framework, one URI identifies a more abstract
'document', the other identifies a specific representation. And
sometimes it's probably useful to identify a specific representation in
a specific charset, or, more of a stretch, encoding. No?
I notice you didn't mention 'language', I assume we agree that one is
even less of a stretch, and has more clear use cases for including in a
URL, like content-type.
Jonathan
