Issue Description | Spec Reference | Priority | Difficulty | Story Points | Related JIRAs | Sprint | Depends on | Notes |
---|
Change the PreferInboundReferences URI in Prefer header from http://fedora.info/definitions/v4/repository#InboundReferences to the one defined in the spec (ie http://fedora.info/definitions/fcrepo#PreferInboundReferences) | 3.2.1 | 1 | 1 | 1 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2675 |
---|
|
|
|
|
|
HTTP Head does not return the same headers as if the request were a GET | 3.3 | 3 | 1 | 1 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2676 |
---|
|
(2676 is a duplicate - confirm and remove) Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2661 |
---|
|
|
|
|
|
POSTing a LDP-NR does not return correct constrainedBy Link header | 3.5 | 2 | 1 | 1 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2677 |
---|
|
|
|
|
|
MUST return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace- Though the message coming back in the case of an attempt to move from RDFSource to NonRDFSource says "Resource Already Exists" instead of returning a constrained by header
- Same message is returned trying to move from ldp:Container to an ldp:DirectContainer or ldp:BasicContainer or ldp:Container
MUST change resource's type if request's type Link is a subtype of resource's current type MUST change resource's interaction model if request's type Link has an LDP interaction model | 3.6 | 1 | 3 | 3 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2591 |
---|
|
|
|
|
|
Using PATCH it is currently possible to add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource. This should not | 3.7.1 | 1 | 2 | 2 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2591 |
---|
|
|
|
|
|
Replace current Link rel="type" Header with memento specified link (i.e. http://mementoweb.org/ns#OriginalResource) | 4.1 | 1 | 1 | 1 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2678 |
---|
|
|
|
|
|
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 | 4.1.1 | 1 | 2 | 2 |
|
| LDPm GET |
|
If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable). | 4.1.1 | 1 | 2 | 1 |
|
|
|
|
The response to a GET request on an LDPRv must include the following headers
| 4.1.1 |
|
|
| Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2678 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2679 |
---|
|
|
|
|
|
LDPm GET - An implementation must support
GET , as is the case for any LDPR. - 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. - In addition, any response to a
GET request must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link header.
| 4.2.1 | 1 | 3 | 3 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2614 |
---|
|
|
| LDPCv: POST |
|
LPPm 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.2 | 1 | 1 | 1 |
|
| LDPm GET |
|
LDPm: PUT, POST, and PATCH must return 405 method not allowed | 4.2.3-5 | 1 | 1 | 1 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2616 |
---|
|
|
| LDPm GET |
|
LDPm: DELETE The server is responsible for all behaviors implied by the LDP-containment of the LDPRm. | 4.2.6 |
|
|
| Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2620 |
---|
|
|
|
| This is a MAY: Are we planning to implement? |
LDPCv : 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. Currently the <http://fedora.info/definitions/v4/repository#TimeMap> is being used.
| 4.3.2 | 1 | 2 | 2 | Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2613 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2643 |
---|
|
(may be closed - depending on approach to fcrepo-2617) Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2681 |
---|
|
|
|
|
|
LDPCv: Disallow PUT and PATCH | 4.3.2 | 1 | 1 | 1 |
|
|
|
|
LDPCv: 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. 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.
| 4.3.3 |
|
|
| Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2617 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2618 |
---|
|
|
| Server Managed Version Creation, Client Managed Version Creation |
|
LDPCv: DELETE: Delete of an LDPCv must remove the LDPCv and removing the versioning interaction model from the original LDPRv.
| 4.3 |
|
|
| |
|
| Are we planning to support DELETE? |
Vary : When an LDPCv supports POST , and allows clients to specify a datetime for created URI-Ms, Vary-Post/Vary-Put: Memento-Datetime. | 4.4 | 1 | 1 | 1 |
|
| LDPc POST |
|
Server Managed Version Creation | 4.5.1 |
|
|
| Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2617 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2618 |
---|
|
|
|
|
|
Client Managed Version Creation | 4.5.2 |
|
|
|
|
|
| Do we plan to support client managed as well? |
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" | 4.5.3 | 5 | 3 | 2 |
|
|
| Do we plan to support this? And if so due to changes in use of "expiration" the spec will likely change. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|