Re: Why MD5 Headers are Imperative

Here's a change from my previous example, which illustrates that my readable 
and writable representations of the <atom:id>http://example.com/2006-07-
27.11.entry</atom:id> are both derived from the real resource, atom.dbxml:

        <link rel='self' 
href='http://example.com/2006/jul/category/sub_category/27.11.entry.atom'/>
        <link rel='edit' href='http://example.com:81/2006-07-27.11.entry'/>

I don't want to expose port 81 to the world, though.  Besides, that's what we 
use internally in that edit href, which still isn't necessarily all writable 
or even readable by any outside client.

So I'd rather expose the readable and the writable representations of the 
resource node, which is stored inside atom.dbxml, at the same URI:

        <link rel='self' 
href='http://example.com/2006/jul/category/sub_category/27.11.entry.atom'/>
        <link rel='edit' 
href='http://example.com/2006/jul/category/sub_category/27.11.entry.atom'/>

They're still not the same thing, because the Principle of Orthogonality 
allows me to implement the solution I posted which alters section 5 of APP, 
*or* the first set of links above, as I see fit.  My way supports both, 
because the only unambiguous, sure-fire thing we have left to keep any of 
this straight is the Content-Md5 header.

-EJB