Re: Why MD5 Headers are Imperative

>
>Just for a moment lets pretend that atom:updated was actually atom:urgent (a
>

No, as soon as you pretend that you're talking about something which should be 
under app:control.  ;)

OK, here's a use case.  Bear with me please, as it integrates @etag later 
on.  I have a wiki where multiple authors have agreed to work on version 2 of 
a shared document.  The existing version 1 of the document is served at this 
location:

(1) http://example.com/2006/jul/category/sub_category/27.11

Here's what's returned in the Content-Location:

(2) 
http://example.com/2006/jul/category/sub_category/27.11;etag=atom:id+atom:updated

The draft of version 2 has a new <updated> value but does not overwrite the 
existing resource.  It is kept as a separate resource, has app:draft set to 
"yes" and is dereferenceable to edit here:

(3) http://example.com/2006/jul/category/sub_category/27.11;etag=Content-Md5

Multiple revisions may be kept separately with different MD5 values, each of 
these multiple entries must have <updated> equal to basically app:modified 
(maybe I'm -1 to app:modified...) but may be distinguished from the real 
McCoy and each other by virtue of @etag in the <link rel='edit'/>.

Location (2) is still editable independently of its sibling atom:id entries, 
by virtue of the client sending the X-APP-MD5 header with the MD5 value.  In 
this case @etag differs from eTag.  Otherwise, they match and the client is 
choosing whichever version the editor chooses of the new revision.

When the editors agree on a version 2, one of them PUTs app:modified="no" 
which causes the server to treat the whole thing as a significant edit, 
writing a new <updated> value and transforming a new readable representation 
with a new eTag=atom:id+atom:updated and a Content-Md5 value equal to the 
final draft.

I thought this was the point of allowing the publisher to determine what's 
significant, and I think it shows that in order to support that objective 
there must be a separate readable and writable representation.  So it looks 
to me like my solution to that issue also provides a workable, robust 
solution to the versioning problem.

-EJB