- From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- Date: Sat, 4 Nov 2006 13:33:53 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
Julian- I apologize for the absurdly slow response, but here goes. Overall feedback: I think this is excellent. Section 1.2: I'm not sure the "Furthermore" note is interesting. Of course it is possible that one a resource is put onto a server that it's body may change again later. Whether that happens via a PUT request, or via PROPPATCH, or even outside of HTTP altogether isn't really all that relevant. What matters is that changed content requires a changed ETag, and that's already quite clear in HTTP. OK, this becomes clearer when we get to section 5... Section 1.2: The t(e2(e1(c))) = t(e2(t(e1(c)))) explanation is very useful. As a general note, I still don't quite understand the widespread aversion to weak ETags, and I think that the this editing property show why weak ETags *do* work in an authoring environment. That the server might give you a different-but-equivalent representation isn't a problem if any "equivalent" version of the document can be edited by a client and sent back to the server and produce an "equivalent" result in the end. I'm rather annoyed that CalDAV was short-sighted here and insisted that all calendar resources must have strong ETags when a weak ETag could be entirely appropriate, but then I think the entire section 5.3.4 in CalDAV was hasty and poorly thought out. Section 4: I think it's useful here to say something about weak ETags. In particular, I would expect an entity-transform-keyword of "identity" followed by a weak entity-tag to indicate that a semantically equivalent entity was stored, not an octet-by-octet copy. Thus, a user agent MUST NOT assume an octet-by-octet entity was stored if a weak ETag was assigned. I suppose another entity-transform-keyword could indicate semantic equivalence, but that's already covered by the nature of the ETag. Section 4.1: What's an example of a situation in which a server would send you a stale Entity-Tag header? Section A.1: This example works well to illustrate what you are trying to explain, but, for what it's worth, doesn't work well for a Subversion client per se. The reason being that the whole point of the $Revision $ keyword is that it shows you want revision of a document you have checked out in your working copy. That is, which is doesn't matter in terms of the integrity of the authoring process (what you are explaining), it does matter for it's intended usage, which is as an informational bit of text maintained by the subversion software in your document. That said, in this particular case, the client should understand this aspect of how the protocol works, and it should be able to modify the $Revision$ text in the document itself without having to follow an edit with a GET request, assuming that it knows that the ETag == the revision number. That may not work for other keywords, though. Section A.2: This is a particularly notable example if the client did a LOCK operation, followed by the PUT and PROPPATCH in the example, in which case a client might have more reason to assume that the content hasn't been modified since the PUT operation, since no other client could have made an edit in the mean time. Section A.2: Note that in Request (3), the title property sent contains spaces and newlines which were removed in the new entity body shown. So even in the PROPPATCH example, there is some server-side transformation of sent data going on. Obviously the Entity-Transform header can't help us here due to the Multi-Status response, but one might imagine an equivalent sort of thing in a new child of the the propstat element. More on Entity-Transform: An Entity-Transform example with a transformed entity might be useful. (I like lots of examples.) Perhaps an example of PUTing JPEG image data where the server stores it as PNG? It's easy to turn this into a rat-hole, I suppose; what if the transform is lossy (PNG- >JPEG), etc.? Is that worth exploring here, or too zany? Perhaps limiting the example to something that's easily transformable both ways is best. iCalendar <-> hCalendar, for example. Of interest here is the change of Content-Type. I reckon that you may have lets this out intentionally, to be addressed later. I'm just trying to think of cases where this draft might make that sort of operation harder than necessary... not thinking of any as yet. More on weak ETags: I think there is room for a weak ETag example here, new style. I'll assume for now that my comment about the "identity" entity- transform-keyword makes sense: >> Request (1) PUT /cal.ics HTTP/1.1 Host: example.com Content-type: text/icalendar BEGIN:VCALENDAR CALSCALE:GREGORIAN VERSION:2.0 BEGIN:VEVENT UID:00B33BAF-30A0-4C2A-A93A-8236318F8002 DTSTART;VALUE=DATE:20020212 DTEND;VALUE=DATE:20020213 DTSTAMP:20041015T171054Z RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=2 SUMMARY:Lincoln's Birthday END:VEVENT END:VCALENDAR >> Response (1) HTTP/1.1 204 NO_CONTENT Content-Type: text/plain Entity-Transform: "identity" ETag: "W/1" Because the server stores the iCalendar data in an intermediate format, it is possible that the entity changes in a semantically equivalent manner between requests, for example: >> Request (2) GET /test.html HTTP/1.1 Host: example.com >> Response(2) HTTP/1.1 200 OK Content-Type: text/icalendar ETag: "W/1" BEGIN:VCALENDAR CALSCALE:GREGORIAN VERSION:2.0 BEGIN:VEVENT DTSTAMP:20041015T171054Z RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=2 SUMMARY:Lincoln's Birthday DTSTART;VALUE=DATE:20020212 DTEND;VALUE=DATE:20020213 UID:00B33BAF-30A0-4C2A-A93A-8236318F8002 END:VEVENT END:VCALENDAR In this case, the iCalendar properties in the event are in a different order. Perhaps the server retrieves these values from separate sources and renders them as they arrive; the timing may be different in future requests, but the data is semantically equivalent in all cases. Regardless, the result is similar to the example in appendix A.2; the client can continue editing the cached local copy despite the differences that exist in the stored entity on the server.
Received on Saturday, 4 November 2006 21:34:05 UTC