4.1 Versioned Resources4.1.1 HTTP GET (LDPRv) The Accept-Datetime header is used to request a past state, exactly as per [RFC7089] section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).The response to a GET request on an LDPRv must include the following headers: A rel="original timegate" link in the Link header referencing itself (Jared Whiklo)A <http://mementoweb.org/ns#TimeGate>; rel="type" link in the Link header (Jared Whiklo) A <http://mementoweb.org/ns#OriginalResource>; rel="type" link in the Link header At least one rel="timemap" link in the Link header referencing an associated LDPCv A Vary: Accept-Datetime header, exactly as per [RFC7089] section 2.1.2.4.1.2 HTTP PUT (Danny Bernstein) - An implementation must support
PUT , as is the case for any LDPR.
4.2 Version Resources (LDPRm)- An LDPRm may be deleted;
- however, it must not be modified once created.
4.2.1 HTTP GET § - An implementation must support
GET , as is the case for any LDPR (LDP-RS memento) - An implementation must support
GET , as is the case for any LDPR (LDP-NR memento)
4.2.2 HTTP OPTIONS §- An implementation must support
OPTIONS . - A response to an
OPTIONS request must include Allow: GET, HEAD, OPTIONS as per [LDP]. - An implementation may include
Allow: DELETE if clients can remove a version from the version history, as noted in 3.8 HTTP DELETE.
4.2.3 HTTP POST - An implementation must not support
POST for LDPRms.
4.2.4 HTTP PUT - An implementation must not support
PUT for LDPRms.
4.2.5 HTTP PATCH - An implementation must not support
PATCH for LDPRms.
4.2.6 HTTP DELETE - An implementation may support
DELETE for LDPRms. If DELETE is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm.
- An implementation must indicate TimeMap in the same way it indicates the container interaction model of the resource via HTTP headers.
- An implementation must not allow the creation of an LDPCv that is LDP-contained by its associated LDPRv.
4.1 Versioned Resources - MUST provide TimeGate interaction model, detailed below
4.1.1 HTTP GET (LDPRv) - The Accept-Datetime header is used to request a past state, exactly as per [ RFC7089 ] section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm
- If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2812 |
---|
|
- The response to a GET request on an LDPRv must include the following headers: An implementation must support
GET , as is the case for any LDPR. Any response to a GET request must include a <ns#TimeMap" link in the Link header.- Uses the URI in above 4.3 point 1, needs updating
- An LDPCv must respond to
GET Accept: application/link-format as indicated in [RFC7089] section 5 and specified in [RFC6690] section 7.3. - An implementation must include the
Allow header as outlined in 4.3.2 HTTP OPTIONS. - If an LDPCv supports
POST , then it must include the Accept-Post header described in 4.3.3 HTTP POST. - If an LDPCv supports
PATCH , then it must include the Accept-Patch header.- Accept-Patch it is not mentioned in the spec.
- An implementation must
Allow: GET, HEAD, OPTIONS as per [LDP]. - An implementation may
Allow: DELETE if the versioning behavior is removable by deleting the LDPCv. See 4.3.4HTTP DELETE for requirements on DELETE if supported. - An implementation may
Allow: PATCH if the LDPCv has mutable properties. See 3.7.1 Containment Triples for requirements on PATCH if supported.- NB: it does not allow PATCH
- An implementation may
Allow: POST if versions can be explicitly minted by a client. See 4.3.3 HTTP POST for requirements on POST if supported. - Currently PUT is allowed. The spec doesn't explicitly ban it, but perhaps it should?
- Esmé Cowles : an update to the spec should specify that LDPCv may disallow PATCH and PUT. Esme will do that.
- We will need a JIRA to disallow PATCH and PUT and remove from OPTIONS.
- PUTting on binaries and their description mementos not quite done.
4.3.3 HTTP POST - Although an LDPCv is both a TimeMap and an LDPC, it may disallow POST requests.
- If an LDPCv supports
POST , a POST that does not contain a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of the POST . Any request body must be ignored. - If an LDPCv supports
POST , a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body and the datetime given in the Memento-Datetime request header. - If an implementation does not support one or both of
POST cases above, it must respond to such requests with a 4xx range status code and a link to an appropriate constraints document (see [LDP] 4.2.1.6).
4.3.4 HTTP DELETE - An implementation may support
DELETE . - An implementation that does support
DELETE should do so by both removing the LDPCv and removing the versioning interaction model from the original LDPRv.
4.4 Vary Non-normative note: When a POST to an LDPCv, or a PUT or PATCH to an LDPRv creates a new LDPRm, the response indicates this by using a Vary header as appropriate. When an LDPCv supports POST , and allows clients to specify a datetime for created URI-Ms, Vary-Post/Vary-Put: Memento-Datetime. Verify whether this is done and if not create JIRA.e 4.5 Implementation Patterns Non-normative note: This section describes the way the normative specification might be applied to implement discoverable versioning patterns. If an implementation of an LDPCv does not support POST to mint versions, that must be advertised via OPTIONS as described in 4.3.2 HTTP OPTIONS. This allows a client to perform an OPTIONS request on an LDPCv to determine if it can explicitly mint versions. If the LDPCv does not support POST , the client should assume some other mechanism is used to mint versions, for example, the implementation may automatically mint versions instead, but that is outside the requirements of this specification. This document specifies normatively only how LDPCvs and LDPRms can be discovered, and how they should act. 4.5.1 Server-Managed Version Creation § Non-normative note: Upon PUT or PATCH to an LDPRv, a new LDPRm is created in an appropriate LDPCv. This LDPRm is the version of the original LDPRv that was just created. 4.5.2 Client-Managed Version Creation § Non-normative note: An LDPRm for a particular LDPRv is created on POST to any LDPCv associated with that LDPRv. The new LDPRm is contained in the LDPCv to which the POST was made and features in that LDPCv-as-a-TimeMap. This pattern is very flexible and might be useful for migration from other systems into Fedora implementations. Responses from requests to the LDPRv include a rel="timemap" link in the Link header that references the same LDPCv as per [RFC7089] section 5. 4.5.3 Replacing Contents from Mementos §Non-normative note: Using the ingest-by-reference mechanism, one can replace the contents of an LDPRvwith that of an LDPRm by providing it's URL as the URL parameter in a Content-Type: message/external-body header. For example, given an LDPRm with URL http://example.org/some/memento , the full header would be
Content-Type: message/external-body; access-type=URL; expiration=1; URL="http://example.org/some/memento" - " link in the Link header
- At least one rel="timemap" link in the Link header referencing an associated LDPCv
- A Vary: Accept-Datetime header, exactly as per [ RFC7089 ] section 2.1.2.
4.1.2 HTTP PUT (LDPRv) (Danny Bernstein) - An implementation must support PUT, as is the case for any LDPR.
4.2 Version Resources (LDPRm)- An LDPRm may be deleted
- An LDPRm must not be modified once created.
4.2.1 HTTP GET (LDPRm) - An implementation must support GET, as is the case for any LDPR (LDP-RS memento)
- An implementation must support GET, as is the case for any LDPR (LDP-NR memento)
- The headers for GET requests and responses on this resource must conform to [ RFC7089 ] section 2.1 . Particularly it should be noted that the relevant TimeGate for an LDPRm is the original versioned LDPRv .
- Any response to a GET request must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link header.
4.2.2 HTTP OPTIONS (LDPRm) - An implementation must support OPTIONS.
- A response to an OPTIONS request must include Allow: GET, HEAD, OPTIONS
- An implementation may include Allow: DELETE if clients can remove a version from the version history
4.2.3 HTTP POST (LDPRm) - An implementation must not support POST for LDPRms.
4.2.4 HTTP PUT (LDPRm) - An implementation must not support PUT for LDPRms.
4.2.5 HTTP PATCH (LDPRm) - An implementation must not support PATCH for LDPRms.
4.2.6 HTTP DELETE (LDPRm) - An implementation may support DELETE for LDPRms. If DELETE is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm.
4.3 Version Containers (LDPCv) (Jared Whiklo)- An implementation must indicate TimeMap in the same way it indicates the container interaction model of the resource via HTTP headers.
- An implementation must not allow the creation of an LDPCv that is LDP-contained by its associated LDPRv.
4.3.1 HTTP GET (LDPCv) (Jared Whiklo) - An implementation must support GET, as is the case for any LDPR.
- Any response to a GET request must include a <http://mementoweb.org/ns#TimeMap>; rel="type" link in the Link header.
- An LDPCv must respond to GET Accept: application/link-format as indicated in [ RFC7089 ] section 5 and specified in [ RFC6690 ] section 7.3.
- An implementation must include the Allow header
- If an LDPCv supports POST, then it must include the Accept-Post header
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2811 |
---|
|
- If an LDPCv supports PATCH, then it must include the Accept-Patch header - PATCH not supported
- An LDPCv, being a container must have a "Link: <http://www.w3.org/ns/ldp#Container>;rel="type "" header
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2809 |
---|
|
4.3.2 HTTP OPTIONS (LDPCv) (Jared Whiklo) - Implementations MUST support OPTIONS
- Implementation's response to an OPTIONS request MUST include "Allow: GET, HEAD, OPTIONS"
- Implementations may Allow: DELETE if the versioning behavior is removable by deleting the LDPCv
- Implementations may Allow: PATCH if the LDPCv has mutable properties
- (it does not allow PATCH because LDPCv does not have mutable properties).
- Implementations may Allow: POST if versions can be explicitly minted by a client
- If an LDPCv supports POST, the response MUST include the "Accept-Post" header
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2820 |
---|
|
- If an LDPCv supports PATCH, the response MUST include the "Accept-Patch" header
4.3.3 HTTP POST (LDPCv) - Although an LDPCv is both a TimeMap and an LDPC, it may disallow POST requests. - POST is allowed
4.3.3.1 Implementations that allow POSTs for LDPCvs - If an LDPCv supports
POST , a POST request that does not contain a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv , reflecting the state of the LDPRv at the time of the POST . - If an LDPCv supports
POST , a POST request that does not contain a Memento-Datetime header MUST ignore any request body - If an LDPCv supports
POST , a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body - If an LDPCv supports
POST , a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the datetime given in the Memento-Datetime request header.
4.3.3.2 Implementations that disallow POSTs for LDPCvs - If an implementation does not support one or both of
POST cases above, it must respond to such requests with a 4xx range status code and a link to an appropriate constraints document
4.3.4 HTTP PUT (LDPCv) - Implementations MAY disallow PUT - we should disallow
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2821 |
---|
|
4.3.5 HTTP PATCH (LDPCv) - Implementations MAY disallow PATCH - disallowed
4.3.6 HTTP DELETE (LDPCv) - An implementation may support
DELETE . - An implementation that does support
DELETE should do so by both removing the LDPCv and removing the versioning interaction model from the original LDPRv.
4.4 Implementation Patterns |