Re: Why MD5 Headers are Imperative

>
>In 4287, it is made clear that atom:updated in feeds is under the  
>control of the publisher of the feed, and they're going to change it  
>whenever they choose to change it.
>
>Some of the discussions on APP have argued out that for an authoring  
>client to do synchronization, they need to get a reliable last- 
>modified timestamp of an entry, and there are a bunch of proposals on  
>the table to handle this, and I have the unenviable task of wading  
>through and figuring out if any of them have rough-consensus support.
>

My counter-proposal is that a last-modified timestamp is not an achievable 
goal when the data format is Atom, which is why it's based on the MD5 header. 
Unless, of course, we just decide that Atom Format is borked somehow and that 
it shouldn't be adhered to in APP, which can indeed force the issue by making 
a fundamental change to a widely deployed format...
 
Under the implementation I based my spec extension on, app:modified works 
perfectly well because only editors ever need to see it and it's decoupled 
from <updated>, Last-Modified and eTag.  The only way I have found to keep 
any of this straight is the pattern I recognized in the Content-Md5 headers 
as I was building it. They give a completely unambiguous means of determining 
the freshness of the retrieved version for editing and allows the 
representation PUT back to the server to go to a non-public version, i.e. the 
next draft, instead of only the published, cached version.

>
>However, it is clearly the case that RFC4287 and APP could end up  
>with different notions of last-modified.  Is this a problem? -Tim
>

It is only a problem if the WG is not aware that this will break the 
implementation of anyone who has deployed Atom in a version-control or 
content-management system by leveraging Atom's ability to keep multiple 
versions straight by allowing shared Atom IDs.  So I think APP should account 
for the way people actually use Atom instead of assuming that's a bug in 4287.

-EJB