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