Re: Why MD5 Headers are Imperative

Sorry, that should have been "entry-client-3.xml" for the third file.  Well, 
now they both work, drat.

-EJB

>-----Original Message-----
>From: Eric J. Bowman [mailto:eric-MkmoNbc1SAncr/OS1auqaA@xxxxxxxxxxxxxxxx]
>Sent: Thursday, August 17, 2006 01:44 AM
>To: atom-protocol-O6w3ZxSwtmQ@xxxxxxxxxxxxxxxx
>Subject: Re:   Why MD5 Headers are Imperative
>
>
>Here's the server-side resource, no "representation" to it, this is the whole 
>enchilada:
>
>http://canuck.bisonsystems.net/dev/atom/entry-server-2.xml
>
>Here's the client-side, writable representation retrieved by an APP client:
>
>http://canuck.bisonsystems.net/dev/atom/entry-server-2.xml
>
>Here's the read-only representation with eTag=atom:id+atom:updated for the 
>majority of use cases, which are read-only and do not even see the <p/> tag:
>
>http://canuck.bisonsystems.net/dev/atom/entry-server-3.xml
>
>In my implementation, editors can move that <p/> tag around all they want 
>without altering the published read-only representation, provided an Atom-
>friendly publishing protocol...
>
>Go back to my first post.  All other conversations aside, this is why I'm 
>here despite my desire to have remained an anonymous lurker.  I'm still 
>working this out myself, but I think I've nailed down the basic contradiction.
>
>-EJB
>
>
>
>