Re: Why MD5 Headers are Imperative

You cannot reject, point by point, a solution on its surface when you have 
not attempted to understand or refute the problem it solves.  I reject your 
"-1's" on my solution until you explain to me why this is true:

"The Member URI may be used to retrieve an representation of the resource, 
period."

This is where your train has gone off the tracks, I'm afraid.  Because your 
statement assumes that there is only one possible representation of that 
resource.  I have two, because the Atom Format specifically allows me two.

Your section 5.3 also puts the determination of "significant edit" in the 
hands of editors, not publishers as called for in RFC 4287, by treating ALL 
edits as significant.

Please, keep the debate framed to my assertions, before moving on to the 
solution.

-EJB

>-----Original Message-----
>From: James M Snell [mailto:jasnell-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx]
>Sent: Thursday, August 17, 2006 04:41 PM
>To: atom-protocol-O6w3ZxSwtmQ@xxxxxxxxxxxxxxxx
>Subject: Re: Why MD5 Headers are Imperative
>
>
>
>
>Eric J. Bowman wrote:
>> [snip]
>> 5.3  Once a resource has been created and the URI of its Atom Entry Document 
>> (its 
>>      'Member URI') is known, that URI may be used to update and delete the 
>>      resource.  The Member URI may also be used to retrieve a readable 
>>      representation of the resource or, using the Atom Protocol, a writable 
>>      representation of the resource.
>> 
>
>-1.  The last sentence is meaningless.  The Member URI may be used to
>retrieve an representation of the resource, period.
>
>> 5.3.1   Retrieving  a  Resource 
>>  
>>     Client                                      Server 
>>       |                                            | 
>>       |   1.)  APP-GET  to  Member  URI                 | 
>>       |------------------------------------------>| 
>>       |                                            | 
>>       |   2.)  Writable Member  Representation        | 
>>       |<------------------------------------------| 
>>       |                                            | 
>>  
>>     1.   The  client  sends  an APP-GET  request to  the  Member  URI  to  
>>      retrieve its  writable representation, as follows:
>> 
>>      1a.  The client MUST force revalidation on the server
>>      1b.  The client MUST send an X-APP-MD5 header with the value "GET"
>>      1c.  The client MAY send an URL parameter with a specific XML ID:
>>              http://example.com/resource;id={xml:id}
>>          This supports the selection of multiple revisions of a Member
>>          Resource when an @xml:id exists for <link rel='edit'/>
>>  
>
>-1. X-APP-MD5 is useless invention and the id={xml:id} thing is just wierd.
>
>>     2.   The  server  responds  with  the  writable representation  of  the 
>>      resource.  An APP-aware server MUST:
>> 
>>      2a.  Send a VARY:X-APP-MD5 header in response to any GET request 
>>          for the Member URI
>>      2b.  Send a Content-Md5 header in response to any APP-GET request 
>>          as per 1b
>>  
>
>-1. Again, md5 hashes serve no useful purpose in this case.
>
>>  
>> 5.3.2   Updating  a  Resource 
>>  
>>     Client                                      Server 
>>       |                                            | 
>>       |   1.)  APP-PUT  to  Member  URI                 | 
>>       |------------------------------------------>| 
>>       |                                            | 
>>       |   2.)  409  Conflict                          | 
>>       |<------------------------------------------| 
>>       |                                            | 
>>       |   3.)  200  OK                                | 
>>       |<------------------------------------------|  
>>  
>>     1.   The client sends an updated representation  to  the  Member's URI 
>>      utilizing APP-PUT as follows:
>> 
>>      1a.  The client MUST send an X-APP-MD5 header whose content is equal to 
>>       the value the server returned in the Content-Md5 header
>> 
>
>-1. Again, the md5 serves no useful purpose in this case.
>
>>     2.   If the X-APP-MD5 value of the APP-PUT request is not equal to the 
>>       current Content-Md5 value of the Member URI the server MUST respond 
>>       with a status code of 409.
>>  
>>     3.   Upon  a  successful  update  of  the  resource  the  server  
>>       responds  with  a  status  code  of  200. 
>> 
>> -EJB
>> 
>> P.S. I would like to thank everyone for their time, who has chosen to give 
>> of 
>> it, throughout the course of the project and as pertains to my concerns.
>> 
>> 
>> 
>
>- James
>
>