- From: Werner Baumann <werner.baumann@onlinehome.de>
- Date: Sun, 06 Jan 2008 20:55:15 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: ietf-http-wg@w3.org
Julian Reschke wrote: > My understanding is that your proposal changes the semantics of RFC2616, > breaks existing servers, and rules out lots of applications what work > fine today. > Your examples: XCAP, CalDAV and AtomPub. They are protocols, defined in an RFC. These protocols (hopefully) clear the matter of rewriting by the server. When a client and a server use one of these protocols, this is clearly caught by "unless it knows that the client is aware of this changes and can handle them". There is no conflict and nothing is ruled out. I don't know about JCR, JCS and ICS. Please give me the full names. Example A.1 and A.2 of draft-reschke-http-etag-on-write-08 is about version control. There are protocols for this. See above. Example A.3, A.4 is an example that will not work without additional knowledge. It is some kind of server-side-include and not very realistic. Authors of a website will want to use WebDAV to edit the *sources* and not the output from server-side processing of this sources (which is intended for normal, none-WebDAV-access with GET). Other examples? Clients that just know about RFC 4918 and that use simple WebDAV-servers like Apache/mod_dav/mod_dav_fs or IIS for distributed authoring. They will never be able to make use of etags in PUT-responses, when it is defined according to your proposal. Werner
Received on Sunday, 6 January 2008 19:55:33 UTC