Fix Media Collections in Draft-08




It's great that a media resource can have an associated atom entry for editing metadata, however, the way this is defined, after posting the image, the client would either have to hope that the server included the generated Atom entry in the response to the POST operation (an undefined behavior) or do a GET on the collection-uri, dig through the entries to find the one that matched the image they just posted, look for the edit link, etc. Solution: return an edit Link header in the response:

    Link: <>; rel="edit"

The other problem with media collections is that they are unusable in scenarios where the public referenceable uri is different than the edit uri. Solution: limit Location to editing, use a Link header to optionally point to alternative public read-only references. The Location URI MAY still be used for public referencing.

    Link: <>; rel="alternate"

Complete example response:

    HTTP/1.1 201 Created
    Date: nnnn
    Link: <>; rel="edit",
      <>; rel="alternate"

The Link headers would also be returned in response to GET and HEAD operations on the URI specified by Location.


Add to Section 8.3

The response to a POST to a Media Collection creating a resource or the 
response to a GET or HEAD on the URI of the media resource URI MAY contain a Link 
header with a "rel" parameter value of "edit" that contains the URI of an Atom 
Entry document representing the metadata of the member resource.  A client MAY
use this to edit the metadata associatd with the resource.

The response MAY also include zero or more Link headers with a "rel" parameter
value of "alternate" that specify alternative URI's that can be used for publicly
referencing the member resource.

Modify section 8.3.1

Change: "When creating a public, read-only reference to the member resource, a client SHOULD use this value." to "When creating a public, read-only reference to the member resource, a client MAY use this value."

Fix the example in Section 12

   POST /binary/edit/ HTTP/1.1
   User-Agent: Thingio/1.0
   Content- Type: image/png
   Content- Length: nnnn
   Title: A picture of the beach

   ...binary data...
   The member resource is created and an HTTP status code of 201 is
   returned.  An alternate read-only URI is provided in the response.
   HTTP/1.1 201 Created
   Date: Fri, 25 Mar 2005 17:17:11 GMT
   Content- Length: nnnn
   Content- Type: application/atom+xml
   Link: <>; rel="alternate"

   The client then POSTs the Atom Entry that refers to the newly created
   image resource.  Note that the client takes the URI and uses it in the 'img'
   element in the Entry content:

   POST  /blog/edit/ HTTP/1.1
   User-Agent: Thingio/1.0
   Content- Type: application/atom+xml
   Content- Length: nnnn

   <?xml version="1.0" encoding="utf-8"?>
   <entry xmlns="">
       <title>What I did on my summer vacation</title>
       <link href=""/>
       <content type="xhtml" xml:lang="en">
           <div xmlns="">
               <p>We went to the beach for summer vacation.
                   Here is a picture of the waves rolling in:
                       alt="A picture of the beach"