Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Hi Jamie,

--On September 14, 2006 10:16:54 AM +0100 Jamie Lokier 
<jamie@shareable.org> wrote:

>> Would it be OK for a server to return a 205 Reset Content with the Etag ?
>> That way the client would know that a refetch is in order.
>
> No, because 205 Reset Content doesn't mean that.
>
> Firstly, what's the point in sending the Etag in that case?  The
> client can't do anything useful with it.

Not true.

Here is my take on what information is useful to a client:

1) Server does not re-write the content at all - client should be given the 
ETag of the stored entity so that it does not have to download it in future 
if it does not get re-written by someone else.

2) Server does a non-semantic change (e.g. adds unimportant whitespace, 
re-formats, uses different XML namespace prefixes etc) - client should be 
given the ETag of the changed entity plus an indication that there was a 
non-semantic change. If the client cares about octet-equality it can then 
download the modified resource, if not it can use the ETag as above.

3) Server does significant change to the resource - client should be given 
the ETag of the new entity plus an indication that the resource was 
changed. Why is that useful? Well if the client does decide to fetch the 
re-written resource it will know, by comparing the ETag it got with what is 
actually on the resource, whether any other entity has in the meantime 
itself over-written the resource. The issue here is being able to 
distinguish between a re-write done to MY resource (the one I put) as 
opposed to a re-write done as a result of someone else's put or some other 
action. That may or may not be useful information but I see no reason not 
to expose it.

CalDAV chose to solve the case of discriminating between (1) and (2)/(3) 
together. So if a strong ETag is returned the client knows that (1) is 
true, otherwise either (2) or (3) may be the case, but there is no way to 
tell between them.

So, for Julian's current proposal, I would like to see an additional 
entity-transform-keyword to help discriminate between (2) and (3). Of 
course what constitutes a 'non-semantic' change is not at all clear, and 
will likely depend on the application and data type. So perhaps 
entity-transform-keyword just needs to be extensible, and other specs can 
extend it - the important point being that if the client sees a keyword it 
does not know about it treats it as 'unspecified'. So CalDAV could declare 
a 'CalDAV-unchanged' keyword that serves could use to indicate case (2). 
AtomPub, XCAP etc could define there own. Each spec would have to be very 
explicit as to what 'non-semantic' changes are allowed to the data.

-- 
Cyrus Daboo

Received on Thursday, 14 September 2006 13:45:34 UTC