Re: Why MD5 Headers are Imperative

I'm fleshing out that last concept, which was a little rough, but it's 
certainly workable and certainly applies to many use cases I've brainstormed. 
There is one thing which has become readily apparent, however.  We don't want 
@etag on <link rel='edit'/>, we want @xml:id.

-EJB

>
>>
>>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
>
>
>
>