#pragma section-numbers off
Regarding Draft protocol-09
Cleanup for "Member" and "Edit" URIs, consolidating into only one thing: "Member".
list item 2: ".. a Location header that contains the Member URI of the newly created ..."
Section 5.3, rewrite
Once a resource has been created and its Member URI is known, that URI can be used to retrieve, update, and delete the resource.
Create new section 8.1, causing 8.* sections to shuffle down
8.1 Member and Edit URIs
The Member URI is expected to yield a representation in the form of an Atom Entry. The Member URI is expected to support updating and deleting the resource via the use of PUT and DELETE as described in this section.
In the APP, Member URIs appear in two places: returned in a Location header after successful resource creation using POST, as described below, and in member entries of a collection, in an atom:link element with a link relation of "edit".
Each member Entry within a collection SHOULD contain such an atom:link element providing a Member URI.
(section numbers from here down are the original section-8 numbers, pre-shuffle)
In section 8.1:
2nd para: "... received in the POST, its Member URI MUST be..."
3rd para: "... if, provided, MUST be an Atom Entry Document representing the newly-created resource, and SHOULD include its Member URI in an atom:link element with a link relation of "edit".
Delete 2nd-last paragraph beginning "Clients MUST NOT assume..."
In section 8.2:
2nd para after first example: "The response includes a "Location" header indicating the Member URI of..."
Delete section 8.3, it's covered above in the new section 8.1
In Section 8.4:
First para: "... and return its Member URI."
2nd para: ".. the Location header included in the response MUST be the Member URI of the media link entry"
In section 8.4.2:
Para beginning "THe server signals...": "The response includes a "Location" header indicating the Member URI of the media link entry..."
In Section 9:
3rd para: "... and should perform a GET on the resource's Member URI before editing"