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