Re: Why MD5 Headers are Imperative

And I think you guys are making this waaaaay too simple by asserting a one-to-
one relationship between resource and representation which exists nowhere 
else in web development, certainly not in RFCs 4287 or 2616.

I really do not care whether or not anybody adapts my solution.  The solution 
is simply not relevant yet.  What I do care about is that the working group 
acknowledges the underlying contradiction that I have brought up, and in that 
respect it feels like I'm talking to a brick wall.  :(

If the group doesn't like the results of ignoring this issue, i.e. "I post 
too much" or whatever, then perhaps you should question just how someone like 
me is supposed to get your attention on this?  Because there's no FAQ...

So please, address the technical merit of the issue I am trying to solve 
instead of dismissing me out-of-hand with your "-1" stuff and categorical 
rejection of my ideas.

-EJB

>-----Original Message-----
>From: James M Snell [mailto:jasnell-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx]
>Sent: Thursday, August 17, 2006 09:00 AM
>To: atom-protocol-O6w3ZxSwtmQ@xxxxxxxxxxxxxxxx
>Subject: Re: Why MD5 Headers are Imperative
>
>
>+1.
>
>Eric: I think you're making this stuff *way* too difficult.
>
>- James
>
>Paul Hoffman wrote:
>> 
>> At 4:53 AM +0000 8/17/06, Eric J. Bowman wrote:
>>> So let's extend HTTP 1.1
>>> with an APP-specific header, for example when requesting the Member
>>> resource
>>> an APP client MUST send "X-APP-MD5:GET" AND "max-age:0".  An APP-aware
>>> server
>>> MUST return VARY:X-APP-MD5 and a Content-Md5 header.
>> 
>> -1. This is vast overkill, as shown by other responses on this thread.
>> 
>> 
>
>