At Wed, 2 Jun 2010 15:23:05 -0400,
Jonathan Rochkind wrote:
> 
> 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’m certainly not thinking it should never be done. Personally I would
leave it out of SRU without a serious use case, but that is obviously
not my decision. Still, in my capacity as nobody whatsoever, I would
advise against it. ;)
 
> 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.

Definitely.

best, Erik



Sent from my free software system <http://fsf.org/>.