Re: rfc2518-bis-04 issues (part 1)

Julian Reschke wrote:

>>><Julian Reschke> 03-C17:
>>>
>>>8.1.5.: "Because clients may be forced to prompt users or throw away changed
>>>      
>>>
>>>content if the ETag changes, a WebDAV server MUST not change the  ETag (or
>>>      
>>>
>>>getlastmodified value) for a resource when only its property values change."
>>>      
>>>
>>>Some servers do, and I don't think we can change that. Therefore I think
>>>this change at least needs explicit consensus on the mailing list.
>>>      
>>>
>><Jason Crawford> I vote for the wording that is in there.  I think we've already reached consensus that changing property values should not be changing etags.
>>    
>>
>
><Julian Reschke> Where and when?
>
While I had agreed with Jason and thought that there had been some 
concensus on this, an exhaustive search of the mailing list archives has 
not backed this up. I is entirely likely that I was misremembering the 
consensus that had been reached regarding the inclusion of stronger ETag 
requirements in 2518bis.

That being said, however, there has been a fair amount of discussion 
around this very issue and the majority opinion seems to be in favor of 
this interpretation... (more below). As an aside, after reading through 
the previous discussions, I now firmly believe that the specification of 
a property tag, PTag, would put this issue soundly to rest. The idea has 
been brought up before, and I think it deserves consideration.

>><Elias Sinderson> I also believe that there was already concensus re: property values not affecting ETags... Since doing a PUT of a resource doesn't affect properties
>>and a GET doesn't retrieve properties, the ETag should not change when properties on a resource do. That is to say that ETags should only be
>>    
>>
><Julian Reschke> That's simply not true. You're argueing from a world view where the server stores properties and content as separate entities. However, it's perfectly
>legal to have a server that
>
>- extracts some properties upon PUT (for instance metadata from a WORD
>document) and/or
>- changes the content upon PROPPATCH of one of the aforementioned
>properties.
>
>I think that we can't and shouldn't make this behaviour illegal.
>
No, implementation issues aside (that is, I don't care how a server 
stores properties as it is orthogonal to my position), ETags as defined 
in RFC 2616 have nothing to do with WebDAV properties. The fact that 
resources have subsequently been defined as having properties doesn't 
change this fact. More to the point, the WebDAV specification should not 
change the definition or semantic properties of ETags.

Let us, however, consider existing implementations where resource 
properties are stored as the same blob of bits as the resource entity. 
This situation does not imply that changing a property of a resource 
entails changing it's ETag. In this case, the server must know how to 
seperate the two when responding to a GET or PROPFIND request and is 
perfectly capable of modifying the ETag without taking property values 
into consideration. The fact that RFC 2518 doesn't treat this matter 
directly has certainly complicated the issue for implementors, as 
evidenced by the different approaches that server implementations have 
taken in generating ETags.

The two points you raise above are red herrings, if you ask me. In the 
first case you have stipulated that the client has done a PUT which 
affects some properties. This is, as you identify, a valid case for 
generating a new ETag, but this is simply because the client has done a 
PUT, not because of any property value(s) changing (i.e. you have 
refuted my assertion that a PUT won't change properties, but not 
provided a compelling reason why changing properties alone should affect 
the ETag).

In the second case you state that modifying some special properties may 
change the content of the resource. Again, I think this is a valid case 
for generating a new ETag, but not due to the property changing but 
because the resource contents have changed. In short, this is similar to 
doing a PUT and modifying the resource itself although it is 
accomplished via a PROPPATCH instead.

In short, my argument is this: ETags should only change when the 
contents of a resource change (e.g. when the entity itself changes). 
Generating strong ETags doesn't place an undue burden on server 
resources and neither does detecting when the actual contents of a 
resource have changed by any means. There will be some frustrations in 
updating existing server code to be compliant if we take a firm stand on 
this issue but, in the long run, the benefits to clients far outweigh 
any drawbacks. The alternative is to have different server 
implementations of ETags and, as a consequence, balkanizing the 
interoperability of clients and servers.

Apologies for the long wind, I feel this particular issue is quite 
important and deserving of a thorough treatment on the road to consensus.


Cheers,
Elias