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

Cyrus Daboo wrote:
> 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.

I like this.

Promising generic keywords suggest themselves: encoding (for text/*),
XML-whitespace, XML-syntax (whitespace, encoding, namespace prefix
changes, collapse empty tags, reorder attributes, generic "&#..;",
etc.), content-encoding ((re-)compression).

-- Jamie