- From: Jonathan Rees <jar@creativecommons.org>
- Date: Tue, 12 Oct 2010 06:55:15 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Tim Berners-Lee <timbl@w3.org>, David Booth <david@dbooth.org>, nathan@webr3.org, Yves Lafon <ylafon@w3.org>, www-tag@w3.org
On Mon, Oct 11, 2010 at 6:15 AM, Julian Reschke <julian.reschke@gmx.de> wrote: ... > Yves already mentioned a use case: > >> GET http://www.example.com/book_ab/chapter_1.html >> => 301 http://www.example.com/bookshelf/ab#chapter_1 > > This happens today, is supported by clients and servers, and has been legal > (as per approved RFC 2616 errata) for a very long time. > > The *only* area that we (the HTTPbis WG) really *can* improve is the advice > on recombining fragments (which is > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>). > > Best regards, Julian With all due respect... I'm confident you're right, but if I were to attempt to champion this cause on your behalf, someone might challenge me to exhibit not a theoretical use case, but an actual case in the wild, one that would break if 2616 were enforced. Surely there is one, or this issue would never have been raised? And if there is one, you should be able to provide me with a resolving URI? Not only would such a URI advance the cause, but it might also give us details about what actual needs are out there, and perhaps shed light on Tim's question about information loss. We've come across two in-the-wild cases relating to linked data, but these don't qualify because (a) the linked data world is not the main concern for 2616, and (b) each case represents an error that can be easily fixed without the use of fragid-in-Location:. Best Jonathan
Received on Tuesday, 12 October 2010 10:55:44 UTC