Editing a media resource, given only its content/@src and a link to the collection

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Section 10 of RFC 5023 says:

  "Clients MUST NOT assume that an Atom Entry returned in the
   Feed is a full representation of an Entry Resource and
   SHOULD perform a GET on the URI of the Member Entry before
   editing it."

It also says that the "edit" link and the "app:edited" element must appear in the feed representation of the entry (Section 10). However, no other requirements are given for the feed representation of entries. From this we can conclude:

* There is no requirement for the "edit-media" link to appear in the feed's representations of media link entries.

* The atom:content element is not required to appear in the feed representation of an entry, regardless of whether it is a media link entry or not. 

* Even if the "edit-media" link and content/@src do appear in the feed, the feed might be out of date with respect to their current values.

Often, the atom:content/@src link will be different from the edit-media link. For example, a weblog may require authentication for editing and thus use a HTTPS link for the edit-media location, but allow unauthenticated, unencrypted HTTP access via the content/@src link. For this reason, when a blog entry links to a media resource, the editor should use the content/@src property (only) for creating links to a media resource, and use the "edit-media" link (only) for editing. 

Since the "edit-media" link and the content/@src are not required to appear in the entry representations in the feed document, the client has to do a lot of work to edit a media resource that is linked from another entry. Besides being tedious, it is expensive.

For example, when editing an image in an existing blog entry, the editor needs to find the media link entry for that image, and then extract the edit-media link from that entry, then use that link to do the actual editing. The logic is something like this:

[Slow] For each entry in the feed: retrieve the entry document (via the "edit" link). If the entry has a content/@src that matches the one we are looking for, extract the edit-media link and use it to edit the image. 

[Usually faster] Find an entry in the feed that has a content/@src that matches what we are looking for. If that entry has an "edit-media" link, then use it. Otherwise, retrieve the full entry document from the "edit" link. If the content/@src matches then use THAT representation's edit-media link. If any of this fails, then fall back to the slow method.

[Potentially much faster] If the server returns a HTTP Link header with the "edit-media" link in it whenever a request is sent to the content/@src location, then the client could avoid the collection feed completely:

    Link: <https://example.org/myblog/images/image.png> ; rel='edit-media'

I recommend that servers:

* Implement the above "Link" header.
* Include each media link entry's atom:content element in the collection feed.
* Include each media link entry's "edit-media" link in the collection feed.
 
I recommend that clients use these shortcuts when possible, but don't depend on any of them. Also, don't depend on the content for content/@src to match the content for the edit-media link. And, of course, the ETag returned for content/@src should not be used to do conditional requests on the edit-media link when those links differ.

Feedback, positive or negative, is welcome.

Regards,
Brian