Fedora's alignment with each category of the Fedora API Specification needs to be verified for completeness and correctness. Below is a listing of the specification categories, the person/people taking the lead on ensuring alignment, and the current status of alignment.
Legend
Environment
...
Expand |
---|
3.1.1 LDP Containers - MUST be able to create LDP Containers: Tested in 3.3
- MUST distinguish between triple types OR MUST return 409 with constrainedBy Link in headers for ldp:contains membership predicate if server cannot distinguish between triple types
- We return a 409 because we can't distinguish and therefore the next 2 tests are not applicable.
- MAY permit ldp:contains membership predicate if server can distinguish between triple types
- SHOULD allow Prefer header in request to distinguish triple types if server can distinguish triple types
3.1.2 LDP-NR creation - SHOULD create an LDP-NR if creation request includes NonRDFSource type Link in headers, regardless of Content-Type headers
3 .2 HTTP GET- MUST return describes Link to LDP-NR if request is to associated LDP-RS
3.2.1 Additional values for the Prefer header .1.3 Constraints Document 3.1.4 Data Model 3.2 HTTP GET3.2.1 Additional values for the Prefer header - SHOULD support PreferInboundReferences URI in Prefer header
- MAY support PreferContainedDescriptions URI in Prefer header
- SHOULD support PreferInboundReferences URI in Prefer header
- MAY support PreferContainedDescriptions URI in Prefer header
3.2.2 LDP-RSs - MUST return Preference-Applied header if request's Prefer header is honored (Always applied)
- note: also test with a combinations of Prefer headers: some valid, some invalid
- MUST return describes Link to LDP-NR if request is to associated LDP-RS
3.2.3.2.3 LDP-NRs - MUST return Digest header as directed by request's Want-Digest header
3.3 HTTP HEAD- MUST NOT return a body
- SHOULD return same headers as if the request was a GET MUST return a Digest header if the same request as a GET would have MAY omit payload headers from response(should the above be marked ?)
- Almost perfect: Binary resources have duplicate headers that are not seen on HEAD
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2714 |
---|
|
- MUST return a Digest header if the same request as a GET would have
- MAY omit payload headers from response
Any LDPR must support OPTIONS per [LDP] 4.2.8. 4.2. LDP servers must support the HTTP OPTIONS method. Any LDPR must support OPTIONS per [LDP] 4.2.8. LD servers must indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP respons header Allow.
3.5 HTTP POST3.5 HTTP POST- MUST be supported on LDPC
- MAY not be supported on LDPCv
- MUST be supported on LDP Collections
- MUST include default interaction model in constrainedBy Link header
- Correct for both LDP-RS only, and LDP-NR does not return correct Link header
3.5.1 LDP-NRs - MUST support creation of LDP-NRs
- MUST create and associate an LDP-RS when an LDP-NR is created
3.5.1 LDP-NRs - MUST return 409 if request Digest header does not match calculated value for content of new LDP-NR
- SHOULD return 400 if request Digest header's type is not supported (Should 'type' be 'algorithm', like the RFC?)
3.6 HTTP PUT (Danny Bernstein)- MAY include type Link header in request
- MUST SHOULD 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 MUST change resource's interaction model if request's type Link has an LDP interaction model
3.6.1 LDP-RSs - MUST be supported support PUT on LDP-RSs for non-server-managed triples
- MUST return 4xx (409) , with more info in body and if request modifies server-managed triples on a LDP-RS
- MUST return constrainedBy Link in headers if request modifies server-managed triples on a LDP-RS
- MUST return info in body about which statements could not be persisted if request modifies server-managed triples (Are triples different than resource statements?) on a LDP-RS
- Currently we allow the use of the -Dfcrepo.properties.management=relaxed option to allow updating server managed triples. Is that something that we will continue to support and if so is the current impl in conflict with the spec?, which is fine
3.6.2 LDP-NRs (Danny Bernstein) - MUST be supported support PUT on LDP-NRs to replace binary content
- MUST return 409 if request Digest header does not match calculated value for new content of target LDP-NR
- SHOULD return 400 if request Digest header's type is not supported (Should 'type' be 'algorithm', like the RFC?)
3.6.3 Creating resources with HTTP PUT - Non-normative section If PUT is supported for creation of LDP-NRs, MUST create and associate an LDP-RS when an LDP-NR is created (Jared Whiklo )
- MUST be supported on LDP-RSs
- MUST support sparqlupdateContent-Type: application/sparql-update
- MAY support other update types
- MUST return 4xx (409) , with more info in body and constrainedBy Link in headers when modifying protected resource statements
- Tested by attempting to add "fedora:lastModifiedBy" property to a container via PATCH
- MUST return info in body about which statements could not be persisted when modifying protected resource statements
- MUST return constrainedBy Link in headers when modifying protected resource statements
- MUST return MUST return 2xx if successful
3.7.1 Interaction models - MUST return 409 when modifying the interaction model to a type that is not a subtype of the current type (LDP-NR to LDP-RS or opposite?)
- I can add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource, but I cannot remove the ldp:RDFSource type
Containment Triples - SHOULD return 409 Conflict if PATCH attempts to update containment triples
3.7.2 Interaction models - MUST return 409 when modifying the interaction model to a type that is not a subtype of the current type
- MAY be supported
3.8.1 Recursive Delete - An implementation that cannot recurse should not advertise DELETE
- MAY be supported
- An implementation that cannot recurse should not adverti DELETE in response to OPTIONS requests for container with contained resources.
- MUST use LDP containment relations for recursive deletion, if recursive deletion is supported
- NOTE: Contained resource and all subresources were return the tombstone of the root resource deleted
- An implementation An implementation must not return a 200 (OK) or 204 (N No Content) response unless the entire operation successfully completed.
- An implementation must not emit a message that implies successful DELETE of a resource until the resource has b been successfully removed.
3.8.1 Depth header ( Danny Bernstein: This section is no longer in the spec.) Compliance with LDP 5.2.5.1 When a contained LDPR is deleted, the LDPC server must also remove the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC. Compliance with LDP 5.2.5.2 When a contained LDPR is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server must also delete the associated LDP-RS it created.- LDP-NR and associated LDP-RS both return 410
- Confirm LDP-NR and LDP-RS both return 410 after being deleted recursively
MUST support a Depth header in the request, if DELETE is implemented MAY support only certain Depth header values: (How to query?) MUST return 400 if request includes Depth header and unsupported Depth header value: (How to query?) MUST use LDP containment relations for recursive deletion, if recursive deletion is supported: (How to query?)
3.9 External Binary Content- MUST return message/external-body in Accept-Post header (for each supported access-type param of supported Content-Types) if external binary content is supported
- (In response to what?)
- Danny Bernstein: a GET on the resource to be POSTed to I believe.
- MUST return 415 for LDP-NR create or update if request has message/external-body and an unsupported access-type, or if external binary content is not supported
- MUST NOT accept request (return 4xx???) for LDP-NR create or update if request has message/external-body and the server cannot return all the required response headers
- SHOULD return a Content-Location header for LDP-NR GET or HEAD (read? to match create or update above) with a URI to the content if the server is proxying: (How to query for proxying?)
- MAY support an expiration parameter (for LDP-NR create or update?) if the request has a message/external-body Content-Type header
- Expiration parameter is possibly up in the air now ? possibly replace with "Prefer" header syntax.
- SHOULD copy content (for LDP-NR create or update?) if the request has a message/external-body Content-Type header and the expiration parameter is set
- MUST return 4xx or 5xx (for LDP-NR create or update?) if the request has a message/external-body Content-Type header and the expiration parameter cannot be accommodated
- MUST return a contrainedBy Link header (for LDP-NR create or update?) if the response status is 4xx: Tested in 3.2 and 3.3
3.9.1 Referenced RDF content in mandataory LDP serializations 3.8.2 Proxied content vs. redirected content |
4 Versioning
Leads
3.9.1 Advertising External Content Support - Fedora servers supporting external content MUST include "Accept-External-Content-Handling" header in response to "OPTIONS" request.
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2814 |
---|
| currently only binary resources will return this header on an OPTIONS request. This ticket is to make containers return it as well.
- The value of the "Accept-External-Content-Handling" response header MUST be a comma-separated list of supported behaviors (copy|redirect|proxy).
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2814 |
---|
|
3.9.2 External Content for RDF Resources 3.9.3 Redirected and Proxied External Content - Fedora servers supporting "redirect" external content types MUST correctly respond to the "Want-Digest" header
- Fedora servers supporting "proxy" external content types MUST correctly respond to the "Want-Digest" header
- A successful response to a
GET and HEAD request for external content with handling of redirect must have status code of either 302 (Found) or 307 (Temporary Redirect)
|
4 Versioning
Leads
Expand |
---|
4 Resource Versioning 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:
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)
-
|
Expand |
---|
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).- curl -v -X GET http://localhost:8080/rest/test -H "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT" returns 200.
- (db) Should a post to a non-LDPRv return 406?
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. - 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 Any response to a
GET request a GET request must include a <a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link headerthe Link header.
4.2. 2 HTTP OPTIONS §2 HTTP OPTIONS (LDPRm) - An implementation must support
OPTIONS support OPTIONS. - A response to an
OPTIONS request must include Allowan OPTIONS request must include Allow: GET, HEAD, OPTIONS as per [LDP]. - An implementation may include Allow include Allow: DELETE if DELETE if clients can remove a version from the version history, as noted in 3.8 HTTP DELETE.
4.2. 3 HTTP 3 HTTP POST (LDPRm) - An implementation must not support
POST for support POST for LDPRms.
4.2. 4 HTTP 4 HTTP PUT (LDPRm) - An implementation must not support
PUT for support PUT for LDPRms.
4.2. 5 HTTP 5 HTTP PATCH (LDPRm) - An implementation must not support
PATCH for support PATCH for LDPRms.
4.2. 6 HTTP 6 HTTP DELETE (LDPRm) - An implementation may support
DELETE for support DELETE for LDPRms. If DELETE is If DELETE is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm. 4.3 Version 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.Currently returns Link: <http://fedora.info/definitions/v4/repository#TimeMap>; rel="type"
- An implementation must not allow the creation of an LDPCv that is LDP-contained by its associated LDPRv.
4.3. 1 HTTP 1 HTTP GET (LDPCv) (Jared Whiklo) - An implementation must support
GET support GET, as is the case for any LDPR. - Any response to a
GET request a GET request must include a <a <http://mementoweb.org/ns#TimeMap>; rel="type" link in the Link headerthe Link header. - Uses the URI in above 4.3 point 1, needs updating
An LDPCv must respond to GET to GET Accept: application/link-format as 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. - ] section 5 and specified in [ RFC6690 ] section 7.3.
- An implementation must include the Allow header
- If an LDPCv supports 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.
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 .- DELETE is advertised, but not currently implemented: do we plan to implement ?
- 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. 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" |
5 Resource Authorization
Leads
- 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 |
5 Resource Authorization
Leads
Expand |
---|
5. Resource Authorization- Implementations MUST follow the recommendations of Web Access Control
- acl:agentGroup appears to be implemented, per wiki documentation
-
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2742 |
---|
|
-
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2743 |
---|
|
-
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2745 |
---|
|
5.1 ACLs are LDP RDF Sources- An ACL for a controlled resource on a conforming server MUST itself be an LDP-RS.
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2833 |
---|
|
|
Expand |
---|
5. Resource Authorization § - To configure access control restrictions, implementations MUST follow the recommendations of Web Access Control [SOLIDWEBAC] with the following additional requirements:
- acl:agentGroup appears to be implemented but it wasn't working for me (Danny Bernstein)
- acl:default is not support - currently behaves as "acl:default" exists without the acl:default defined.
5.1 ACLs are LDP RDF Sources §- An ACL for a controlled resource on a conforming server MUST itself be an LDP-RS.
5.2 ACL Representation and Interpretation § 5.2 ACL Representation and Interpretation- Implementations MUST inspect the ACL RDF for authorizations.
- Implementations MUST use only statements associated with an authorization in the ACL RDF to determine access,
- except in the case of
acl:agentGroup statements where the group listing document is dereferenced.
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2275 |
---|
|
- The authorizations MUST be examined to see whether they grant the requested access to the controlled resource.
- If none of the authorizations grant the requested access then the request MUST be denied.
5.3 ACLs are discoverable via Link Headers §Headers- A conforming server MUST advertise the individual resource ACL for every controlled resource in HTTP responses with a
rel="acl" link in the Link header, whether or not the ACL exists. - The ACL resource SHOULD be located in the same server as the controlled resource.
5.4 ACL linking on resource creation §- A A client HTTP
POST or PUT request to create a new LDPR MAY include a rel="acl" link in the Link header referencing an existing LDP-RS to use as the ACL for the new LDPR.- Currently HTTP POST allows posting with the rel=acl link but does not create ACL link on the resource
- Do we plan to support this feature or not?
LDPR.- (Peter Eichman) the
rel="acl" link header for the second LDPR is ignored - (Peter Eichman) instead, the second LDPR's
rel="acl" link is to the /fcr:acl endpoint appended to that LDPR's URI
- The The server MUST reject the request and respond with a 4xx or 5xx range status code, such as 409 (Conflict) if it isn't able to create the LDPR with the specified LDP-RS as the ACL.
- Assuming we will support the rel="acl" header on creation, this may be a non-issue.
LDP-RS as the ACL.- (Peter Eichman) see the previous point; a 201 is returned instead of an expected 409 (or other 4xx or 5xx)
- In In that response, the restrictions causing the request to fail MUST be described in a resource indicated by a
rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header, following the pattern of [LDP] 4.2.1.6. - These items are silently ignoring the rel="acl" Link header, need to 4xx to change these to .
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2822 |
---|
| Some consensus on the notion that we will try to implement but if not enough time, we will fall back to rejection mode.
5.5 Cross-Domain ACLs §- Implementations Implementations MAY restrict support for ACLs to local resources.Currently we allow users to insert remote acl URIs, but on retrieval, 500 errors to local resources.
- If If an implementation chooses to reject requests concerning remote ACLs,
- it it MUST respond with a 4xx range status code
- and and MUST advertise the restriction with a
rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.- (Peter Eichman) these are failing in the same manner as the requests in 5.4; the
rel="acl" Link header in the request is silently ignored Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2822 |
---|
|
5.6 Cross-Domain Group Listings §Listings- Implementations MAY restrict support for [SOLIDWEBAC] groups of agents to local Group Listing documents.
- If an implementation chooses to reject requests concerning remote Group Listings,
- it MUST respond with a 4xx range status code
- and MUST advertise the restriction with a
rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header. - Consensus seems to be: agent groups must be internal to the repository.
- Do we need to perform any validation on the -Dfcrepo.auth.webac.userAgent.baseUri and fcrepo.auth.webac.groupAgent.baseUri to ensure these values do not cross domains?NB: Those values are used in the bodies of notifications. Are they used anywhere else? Or do fcrepo.auth.webac.groupAgent.baseUri values it MUST advertise the restriction with a
rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.
5.7 Append Mode §Mode- In the context of a Fedora implementation,
acl:Append should be understood as operations that only append, such as POST ing to a container, or performing a PATCH that only adds triples. - The Append mode is currently unimplemented.
5.7.1 LDP-RS §(Append) - When a client is allowed to perform
acl:Append operations on an LDP-RS: but not acl:Write operations on an LDP-RS:- A
DELETE request MUST be denied Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2715 |
---|
|
- A
PATCH request that deletes triples MUST be denied Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2716 |
---|
|
- A
PATCH request that only adds triples SHOULD be allowed Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2716 |
---|
|
- A
PUT request on an existing resource MUST be denied Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2717 |
---|
|
- A
DELETE request MUST be denied - A
PATCH request that deletes triples MUST be denied - A
PATCH request that only adds triples SHOULD be allowed - A
PUT request on an existing resource MUST be denied - A
PUT request to create a new resource MUST be allowed if the implementation supports creating resources using PUT (see: 3.6.3 Creating resources with HTTP PUT) Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2717 |
---|
|
5.7.2 LDPC §(Append) - When
- In addition to requirements in 5.7.1 LDP-RS, when a client is allowed to perform
acl:Append but not acl:Write operations on an LDPC, a POST request MUST be allowed.
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2823 |
---|
|
5.7.3 LDP- NR §NR (Append) - When a client is allowed to perform
acl:Append operations on an LDP-NR: but not acl:Write operations on an LDP-NR:- All
DELETE , POST , and PUT requests MUST be denied Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2718 |
---|
|
- All
DELETE , POST , and PUT requests MUST be denied - A
PATCH request that deletes or modifies existing content MUST be denied - A
PATCH request that only adds content SHOULD be allowedadds content SHOULD be allowed- because LDP-RS attached to LDP-NR are now full resources, I think this ticket should suffice for the previous 2 (Jared Whiklo )
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2716 |
---|
|
5.8 Access To Class §Class- Notwithstanding [SOLIDWEBAC]'s lack of support for it, the The
acl:accessToClass predicate MUST be supported. - When an ACL includes an
acl:accessToClass statement, it gives access to all resources with the specified type, whether that type is client-managed or server-managed. - An implementation MAY use inference to infer types not present in a resource's triples or
rel="type" links in the Link header. Danny Bernstein: This functionality appears to be implemented but I could not get it to work. No errors just got a 403 when I was expecting a 200 Implementations MAY use inference to infer types not present in a resource's triples or rel="type" links in the Link header.
5.9 Inheritance and Default ACLs §ACLs- Inheritance of ACLs in Fedora implementations is defined by the [SOLIDWEBAC] ACL Inheritance Algorithm and MUST be reckoned along the [LDP] containment relationships linking controlled resources, with the following modification:
- In the case that the controlled resource is uncontained and has no ACL, or that there is no ACL at any point in the containment hierarchy of the controlled resource, then the server MUST supply a default ACL.
NB: acl:default rather than outdated acl:defaultForNew should be used.
- The default ACL resource SHOULD be located in the same server as the controlled resource.
- we will need to enforce this once acl:default is supported.
|
6 Notifications
Lead
7 Binary Resource Fixity
Lead
- MUST be reckoned along the LDP containment relationships linking controlled resources, with the following modification:
- In the case that the controlled resource is uncontained and has no ACL, or that there is no ACL at any point in the containment hierarchy of the controlled resource, then the server MUST supply a default ACL.
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2826 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2825 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2824 |
---|
|
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2683 |
---|
|
NB: acl:default rather than outdated acl:defaultForNew should be used.
- The default ACL resource SHOULD be located in the same server as the controlled resource.
-
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2698 |
---|
| acl:default is not supported - currently behaves as "acl:default" exists without the acl:default defined.
|
6 Notifications
Lead
7 Binary Resource Fixity
Lead