Expand

3.1 General (Jared Whiklo)

Empty section

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.1.3 Constraints Document

SHOULD SHOULD respond with <Link: http://www.w3.org/ns/ldp#constrainedBy> header on failures due to implementation choices

3.1.4 Data Model

MUST MUST respond with <Link: http://www.w3.org/ns/ldp#constrainedBy > header on failures due to unallowed data model ... like single-subject-restriction scenario

3.2 HTTP GET

3.2.1 Additional values for the Prefer header

SHOULD support PreferInboundReferences URI in Prefer header
- Supports the old " http://fedora.info/definitions/v4/repository#InboundReferences " but not the one defined in the spec.
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 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
- 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

3.4 HTTP OPTIONS (Yinlin Chen)

Any LDPR must support OPTIONS per [LDP] 4.2.8. 4.2. LDP servers must support the HTTP OPTIONS method.

3.5 HTTP POST

MUST be supported on LDPC
MAY not be supported on LDPCv
MUST include default interaction model in constrainedBy Link header
- Correct for both LDP-RS and LDP-NR

3.5.1 LDP-NRs

MUST support creation of LDP-NRs
MUST create and associate an LDP-RS when an LDP-NR is created
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

MAY include type Link header in request
SHOULD return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
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 LDP-RSs

MUST support PUT on LDP-RSs for non-server-managed triples
MUST return 4xx (409) 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 on a LDP-RS
3.6.2 LDP-NRs (Danny Bernstein)
- MUST 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
3.6.3 Creating resources with HTTP PUT
- If If PUT is supported for creation of LDP-NRs, MUST create and associate an LDP-RS when an LDP-NR is created (Jared Whiklo )
3.7 HTTP PATCH (Jared Whiklo)
- MUST be supported on LDP-RSs
- MUST support Content-Type: application/sparql-update
- MAY support other update types
- MUST return 4xx (409) 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
  - Returns "Could not persist triple containing predicate http://fedora.info/definitions/v4/repository#lastModifiedBy to node /test_container"
- MUST return constrainedBy Link in headers when modifying protected resource MUST return constrainedBy Link in headers when modifying protected resource statements
- MUST return 2xx if successful
3.7.1 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
  3.8 HTTP DELETE (Yinlin Chen)
  - MAY be supported
  - - Tested by attempting to add "ldp:contains" relation referencing another LDPR via PATCH.
    - Rejected with status 409
    - Link: <http://localhost:8080/static/constraints/ServerManagedPropertyException.rdf>; rel="http://www.w3.org/ns/ldp#constrainedBy"
    - Could not persist triple containing predicate http://www.w3.org/ns/ldp#contains to node /test_container
  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
  3.8 HTTP DELETE (Yinlin Chen)
  - MAY be supported
  3.8.3.8.1 Recursive Delete
  - An implementation that cannot recurse should not advertise 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 must not return a 200 (OK) or 204 (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 been successfully removed.
  - Compliance 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 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
  3.3.9 External Binary Content
  - Image Added Fedora servers should support the creation of LDP-NRs with content external to the request entity, as indicated by a link with rel="http://fedora.info/definitions/fcrepo#ExternalContent" and target that is the location of the external content.
    - Image Added handling="copy"
    - Image Addedhandling="redirect"
    - Image Addedhandling="proxy"
  - Image Added Fedora servers should support the update of LDP-NRs with content external to the request entity, as indicated by a link with rel="http://fedora.info/definitions/fcrepo#ExternalContent" and target that is the location of the external content.
    - Image Added handling="redirect"
    - Image Added handing="copy"
    - Image Added handling="proxy"
  - Fedora servers that do not support the creation of LDP-NRs with content external must reject with a 4xx range status code
  - Fedora servers that do not support the creation of LDP-NRs with content external must describe this restriction in a resource indicated by a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.
  - Image AddedFedora servers must use the handling attribute in the external content link to determine how to process the request.
    - At least one of the following handling attributes must be supported
      - Image Added copy - requests that the server dereference the external content URI and treat that as if it were the entity body of the request.
      - Image Added redirect - requests that the server record the location of the external content and handle requests for that content using HTTP redirect responses with the Content-Location header specifying the external content location.
      - Image Added proxy - requests that the server record the location of the external content and handle requests for that content by proxying. See also 3.9.3 Redirected and Proxied External Content .
  - Image Added Fedora servers must reject with a 4xx range status code requests for which the handling attribute is not present or cannot be respected.
  - Image AddedIn the case that the specified handling cannot be respected, 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.
  - Image AddedFedora servers must use the value of the type attribute in the external content link as the media type of the external content, if provided.
  - Image Added Fedora servers should ignore any Content-Type header in the request .
    - Image Added no "type=" attribute in the Link header results in 'application/octet-stream'
    - Image Added "type=" as well as 'Content-Type' header result in "type=" taking precedence
    - Image Added no "type=", but with 'Content-Type' results in 'Content-Type' being ignored (as it should be)
  - If there is no type attribute:
    - Servers may use the media type obtained when accessing the external content via the specified scheme (e.g. the Content-Type header for external content accessed via http).
    - Image Added Servers may use a default media type.
      - server uses default content type of "application/octet-stream"
    - Servers may reject the request with a
    If there is no type attribute:
    - Servers may use the media type obtained when accessing the external content via the specified scheme (e.g. the Content-Type header for external content accessed via http).
    - Servers may use a default media type.
    - Servers may reject the request with a 4xx range status code.
  - A Image Added A Fedora server receiving requests that would create or update an LDP-NR with content external to the request entity must reject request if it cannot guarantee all of the response headers required by the LDP-NR interaction model in this specification
    3.9.1 Advertising External Content Support
    - Fedora servers supporting external content MUST include "Accept-External-Content-Handling" header in response to "OPTIONS" request.
    - The value of the "Accept-External-Content-Handling" response header MUST be a comma-separated list of supported behaviors (copy|redirect|proxy).
    3.9.2 External Content for RDF Resources
    - Non-normative section
    3.9.3 Redirected and Proxied External Content
    - Fedora servers supporting "redirect" or "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

...

When an LDPR is created with a rel="type" link in the Link header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, it must be created as an LDPRv
When an LDPR is created with a rel="type" link in the Link header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, a version container (LDPCv) capturing time-varying representations of the LDPRv MUST be created
- todo: create JIRA requiring the LDPCv to have: "Link: <http://www.w3.org/ns/ldp#Container>;rel="type""

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
- The response is a 200 instead of the expected 302.
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.
- todo - ensure that 406 is return (instead of 404) when the LDPCv is empty. (dbernstein)
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 (LDPRv) (Danny Bernstein)

An implementation must support PUT, as is the case for any LDPR.

...

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.

...

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.

...

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
- todo: create JIRA to add Accept-Post header on LDPCv
If an LDPCv supports PATCH, then it must include the Accept-Patch header - PATCH not supported

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
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
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)

...

todo: create JIRA to return a 405 instead of the current 400 on:

Code Block
curl -i -u fedoraAdmin:fedoraAdmin -XPUT -H"Content-Type: application/sparql-update" @patch.ru localhost:8080/rest/test4/obj/fcr:versions/new

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

Non-normative section

Required "describedby" Link header present for all non-historic-memento

Image AddedHistoric mementos of external binaries are currently failing, so cannot confirm behavior for historic mementos (although they most likely will violate the Link requirement after the historic binary has been created but not the historic description):

Code Block

curl -i -XPUT -H "Link: <http://mementoweb.org/ns#OriginalResource>; rel=\"type\"" -H "Link: <https://duraspace.org/wp-content/themes/duraspace/assets/images/whitedura.png>; rel=\"http://fedora.info/definitions/fcrepo#ExternalContent\"; handling=\"proxy\"; type=\"image/png\"" "http://localhost:8080/rest/coollogo" -ufedoraAdmin:fedoraAdmin

curl -XPOST http://localhost:8080/rest/coollogo/fcr:versions -H "Memento-Datetime: Sat, 1 Jan 2000 00:00:00 GMT" -H "Link: <https://wiki.duraspace.org/download/attachments/31655033/fedora_logo_2in.png>; rel=\"http://fedora.info/definitions/fcrepo#ExternalContent\"; handling=\"proxy\"; type=\"image/png\"" -ufedoraAdmin:fedoraAdmin

#Response:
# < HTTP/1.1 415 Unsupported Media Type
# Invalid Content Type application/octet-stream

Jira
server DuraSpace JIRA
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
key FCREPO-2815

Server provides a default "application/octet-stream" Content-type if one is not determined from a proxied or redirected resource
- Confirmed for copy, redirect and proxy HTTP URLs.
NOTE: For a proxy binary from a HTTP URL that does not return a Content-Length header, the premis:hasSize property will be set to -1 and no Content-Length header is returned from Fcrepo.

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

Non-normative section

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

When an LDPR is created with a rel="type" link in the Link header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, it must be created as an LDPRv
When an LDPR is created with a rel="type" link in the Link header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, a version container (LDPCv) capturing time-varying representations of the LDPRv MUST be createde

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:
- 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 (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)

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

Non-normative section

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

5.2 ACL Representation and Interpretation (Danny Bernstein)

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

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 (Peter Eichman)

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.
- (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 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.
- (Peter Eichman) see the previous point; a 201 is returned instead of an expected 409 (or other 4xx or 5xx)
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
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

5.5 Cross-Domain ACLs (Peter Eichman)

Implementations MAY restrict support for ACLs to local resources.
If an implementation chooses to reject requests concerning remote ACLs,
- 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.
  - (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

Implementations MAY restrict support for 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
- 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

In the context of a Fedora implementation, acl:Append should be understood as operations that only append, such as POSTing to a container, or performing a PATCH that only adds triples.

5.7.1 LDP-RS (Append)

When a client is allowed to perform acl:Append 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 PUT request to create a new resource MUST be allowed if the implementation supports creating resources using PUT
  Jira
  server DuraSpace JIRA
  serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
  key FCREPO-2717

5.7.2 LDPC (Append)

5 Resource Authorization

Leads

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 (Danny Bernstein)

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.
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

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 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.
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.
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

5.5 Cross-Domain ACLs

Implementations MAY restrict support for ACLs to local resources.
If an implementation chooses to reject requests concerning remote ACLs,
- 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.

5.6 Cross-Domain Group Listings

Implementations MAY restrict support for 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
- 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

In the context of a Fedora implementation, acl:Append should be understood as operations that only append, such as POSTing to a container, or performing a PATCH that only adds triples.

5.7.1 LDP-RS (Append)

When a client is allowed to perform acl:Append but not acl:Write operations on an LDP-RS:
- 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

5.7.2 LDPC (Append)

When a client is allowed to perform acl:Append but not acl:Writeoperations on an LDPC, a POST request MUST be allowed.

5.7.3 LDP-NR (Append)

When a client is allowed to perform acl:Append but not acl:Writeoperations on an LDP-NR:

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 allowed

Expand

5. Resource Authorization

Implementations MUST follow the recommendations of Web Access Control

acl:agentGroup appears to be implemented but it wasn't working for me (Danny Bernstein)

acl:default is not supported - currently behaves as "acl:default" exists without the acl:

default defined.

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

-2742

-2823

5.7.3 LDP-NR (Append)

Jira
server DuraSpace JIRA
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
key FCREPO-2743

When a client is allowed to perform acl:Append 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-2745


key	FCREPO-2718

A PATCH request that deletes or modifies existing content MUST be denied

A PATCH request that only adds 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

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.
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

Inheritance of ACLs in Fedora implementations 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

5.8 Access To Class

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.
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

Inheritance of ACLs in Fedora implementations 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.

6 Notifications

Lead

Danny Bernstein

Expand

6.1 Notification Events

For every resource whose state is changed as a result of an HTTP operation, there must be a corresponding notification made available describing that change.

6.2 Notification Serialization

The notification serialization must conform to the [ activitystreams-core ] specification.
Wherever possible, data should be expressed using the [ activitystreams-vocabulary ].
Each event described by a notification must contain:
- The IRI of the resource that was created, modified or deleted
- The event type(s) corresponding to the HTTP operation
Each event described by a notification should contain:
- The agent(s) that caused the change to occur
- The RDF type(s) of the resource that was changed
- The location of the ldp:inbox for the resource that was changed, if such an inbox link exists
Notifications should not contain the entire content of repository resources.

6.3 Examples

Non-normative section

...

Page tree

Page History

Versions Compared

Old Version 97

New Version Current

Key

3.1 General (Jared Whiklo)

3.2 HTTP GET

3.3 HTTP HEAD

3.4 HTTP OPTIONS (Yinlin Chen)

3.5 HTTP POST

3.6 HTTP PUT

3.7 HTTP PATCH (Jared Whiklo)

3.8 HTTP DELETE (Yinlin Chen)

3.8 HTTP DELETE (Yinlin Chen)

Compliance 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 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.

3.3.9 External Binary Content

4 Versioning

Leads

4.4 Implementation Patterns

4 Versioning

Leads

4.4 Implementation Patterns

5 Resource Authorization

Leads

5. Resource Authorization

5.1 ACLs are LDP RDF Sources

5.2 ACL Representation and Interpretation (Danny Bernstein)

5.3 ACLs are discoverable via Link Headers

5.4 ACL linking on resource creation (Peter Eichman)

5.5 Cross-Domain ACLs (Peter Eichman)

5.6 Cross-Domain Group Listings

5.7 Append Mode

5 Resource Authorization

Leads

5. Resource Authorization

5.1 ACLs are LDP RDF Sources

5.2 ACL Representation and Interpretation (Danny Bernstein)

5.3 ACLs are discoverable via Link Headers

5.4 ACL linking on resource creation

5.5 Cross-Domain ACLs

5.6 Cross-Domain Group Listings

5.7 Append Mode

5.8 Access To Class

5.9 Inheritance and Default ACLs

5.8 Access To Class

5.9 Inheritance and Default ACLs

6 Notifications

Lead

6.1 Notification Events

6.2 Notification Serialization