- From: Jonathan Rees <jar@creativecommons.org>
- Date: Wed, 8 Jul 2009 17:30:15 -0400
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Pat Hayes <phayes@ihmc.us>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
On Wed, Jul 8, 2009 at 4:59 PM, Roy T. Fielding<fielding@gbiv.com> wrote: > Please, folks, stop making up things about the HTTPrange-14 issue > which did not exist at the time it was resolved. If there are problems > with the 303 definition (like "resource owner"), then they will be > fixed in the HTTP spec. When the spec is approved, it will define > the protocol. If people use the protocol incorrectly, that's their > problem. The TAG decision was input to the process, not a sacred cow. > > ....Roy I agree completely (although it would be nice if HTTPbis took into account the way 303 responses are currently being used by the community you thought you would serve by adding GET/303 to HTTPbis). In my opinion this sentence "A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP." makes up things about the decision - namely the idea that the server would be in possession of information about the resource's representations or lack thereof, and would use it in deciding what responses to send. This change is consequential to current users of GET/303 and I just don't understand why you want to do it. Was your comment aimed only at Pat, or at me as well? What was your opinion of my proposed compromise (the server doesn't have a representation etc.)? Jonathan
Received on Wednesday, 8 July 2009 21:30:57 UTC