- From: Graham Klyne <GK-lists@ninebynine.org>
- Date: Tue, 22 Dec 2009 09:35:00 +0000
- To: Michael Hausenblas <michael.hausenblas@deri.org>
- CC: Jonathan Rees <jar@creativecommons.org>, www-tag@w3.org
Michael Hausenblas wrote: >> They're proposing to do conneg over the time dimension. I haven't >> analyzed this yet but wondered if anyone on this list already knows of >> any protocol or other issues. It seems to relate to some of our recent >> discussions of conneg. > > We had a longer discussion re this proposal on public-lod, starting at [1]. > > Cheers, > Michael > > [1] http://lists.w3.org/Archives/Public/public-lod/2009Nov/0124.html > Most interesting - thanks for the link. ... This is the second time in a few weeks that I've run across a proposal to introduce a new X-Accept-<foo> header field. (Sorry, I don't offhand remember the other one.) The use of X- as a prefix for experimental elements is generally regarded in the IETF as unsatisfactory. Specifically, they tend to escape into the wild, so the original intent that they be purely experimental doesn't work out in practice, and 'X-' becomes just another bit of noise we have to deal with. The current solution is to not apply the 'X-' prefix, but instead provisional registration, per http://www.rfc-editor.org/rfc/rfc3864.txt, which is by design very easy to accomplish. The other thought I have about these new header field proposals is this: is it time to dust off the 'Accept-features' header and review content negotiation more generally, rather than for isolated special cases? Cf. http://www.rfc-editor.org/rfc/rfc2912.txt, and http://www.rfc-editor.org/rfc/rfc2506.txt. (This header field and registry could, I believe, be used separately from the more complex formats described in related specifications. For example, SIP specifies use of the registry and a subset of the feature expression format - http://www.rfc-editor.org/rfc/rfc3840.txt). (FWIW, I've also had discussions about possible use of RFC2912 to conveny information about content *within* data packaged for transmission using SWORD (http://www.swordapp.org/) - though I don't know if that idea is actually being adopted.) ... Changing gear slightly, I also noticed this in the referenced discussion: Mark Baker: [[ My claim is simply that all HTTP requests, no matter the headers, are requests upon the current state of the resource identified by the Request-URI, and therefore, a request for a representation of the state of "Resource X at time T" needs to be directed at the URI for "Resource X at time T", not "Resource X". ]] -- http://lists.w3.org/Archives/Public/public-lod/2009Nov/0140.html Maybe the appropriate response, then, is an HTTP redirect rather than to just return the representation of resource-at-time-X? (ala HTTP-range-14?). Which appears to be pretty much what Memento does: http://lists.w3.org/Archives/Public/public-lod/2009Nov/0148.html #g
Received on Tuesday, 22 December 2009 09:38:14 UTC