 |
 |
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