- Created by Collin Brittle, last modified by Danny Bernstein on Feb 15, 2018
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 20 Next »
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
- Untested
- Tested, working
- Tested, not working
- Tested, not applicable
- Needs review
Environment
- Version of Fedora: 6034a73
- Version of Fedora Specification: e6fc281
- Test Compatibility Suite
- Legacy - Version of script: 9d20fad (repo and usage here: https://github.com/rotated8/fedora-spec-testing)
3 Resource Management
Lead
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
- Returns a 400 when attempting to POST with Link: http://www.w3.org/ns/ldp#NonRDFSource; rel="type"
3.2 HTTP PATCH (Jared Whiklo)
- MUST be supported on LDP-RSs
- MUST support sparqlupdate
- MAY support other update types
- MUST return 4xx (409), with more info in body and constrainedBy Link in headers when modifying protected resource statements
- MUST return 2xx if successful
3.2.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
3.3 HTTP POST
- MUST be supported on LDP Collections
- MUST include default interaction model in constrainedBy Link header
- LDP-RS only, LDP-NR does not return correct Link header
- MUST support creation of LDP-NRs
- MUST create and associate an LDP-RS when an LDP-NR is created
3.3.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.4 HTTP PUT
- MAY include type Link header in request
- MUST 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.4.1 LDP-RSs
- MUST be supported on LDP-RSs for non-server-managed triples
- MUST return 4xx (409), with more info in body and constrainedBy Link in headers if request modifies server-managed triples (Are triples different than resource statements?) on a LDP-RS
3.4.2 LDP-NRs
- MUST be supported 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.4.3 Creating resources with HTTP PUT
- Non-normative section
3.5 HTTP GET
- MUST return describes Link to LDP-NR if request is to associated LDP-RS
3.5.1 Additional values for the Prefer header
- MAY support PreferContainedDescriptions URI in Prefer header
- SHOULD support PreferInboundReferences URI in Prefer header
3.5.2 LDP-RSs
- MUST return Preference-Applied header if request's Prefer header is honored (Always applied)
3.5.3 LDP-NRs
- MUST return Digest header as directed by request's Want-Digest header
3.6 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
3.7 HTTP DELETE
- MAY be supported
3.7.1 Depth header
- 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.8 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?)
- 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
- 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.8.1 Referenced RDF content in mandataory LDP serializations
- Non-normative section
3.8.2 Proxied content vs. redirected content
- Non-normative section
4 Versioning
Leads
4.1 Versioned Resources
- When an LDPR is created with a
rel="type"
link in theLink
header specifying typehttp://mementoweb.org/ns#OriginalResource
to indicate versioning, it must be created as an LDPRv and a version container (LDPCv) must be created to contain Memento resources (LDPRm) capturing time-varying representations of the LDPRv. Patterns for version creation are described in 4.5 Implementation Patterns.- NB: Spec has changed: currently LDPRv is created using the type http://fedora.info/definitions/fcrepo#VersionedResource in the link header.
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).- 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 theLink
header referencing itself - A
<http://mementoweb.org/ns#TimeGate>; rel="type"
link in theLink
header - A
<http://mementoweb.org/ns#OriginalResource>; rel="type"
link in theLink
header- NB: Spec has changed: currently LDPRv is returning type http://fedora.info/definitions/fcrepo#VersionedResource
- At least one
rel="timemap"
link in theLink
header referencing an associated LDPCv - A
Vary: Accept-Datetime
header, exactly as per [RFC7089] section 2.1.2.
- A
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 response to a
GET
request must include a<http://mementoweb.org/ns#Memento>; rel="type"
link in theLink
header.
4.2.2 HTTP OPTIONS §
- An implementation must support
OPTIONS
. - A response to an
OPTIONS
request must includeAllow: 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. IfDELETE
is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm.
4.3 Version Containers (LDPCv)
- 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
- An implementation must support
GET
, as is the case for any LDPR. Any response to aGET
request must include a<http://mementoweb.org/ns#TimeMap>; rel="type"
link in theLink
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 as outlined in 4.3.2 HTTP OPTIONS. - If an LDPCv supports
POST
, then it must include theAccept-Post
header described in 4.3.3 HTTP POST. - If an LDPCv supports
PATCH
, then it must include theAccept-Patch
header.
4.3.2 HTTP OPTIONS
- 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 onDELETE
if supported. - An implementation may
Allow: PATCH
if the LDPCv has mutable properties. See 3.7.1 Containment Triples for requirements onPATCH
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 onPOST
if supported. - Currently PUT is allowed. The spec doesn't explicitly ban it, but perhaps it should?
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
, aPOST
that does not contain aMemento-Datetime
header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of thePOST
. Any request body must be ignored. - If an LDPCv supports
POST
, aPOST
with aMemento-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 theMemento-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 aPOST
to an LDPCv, or aPUT
orPATCH
to an LDPRv creates a new LDPRm, the response indicates this by using aVary
header as appropriate. When an LDPCv supportsPOST
, 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 supportPOST
to mint versions, that must be advertised viaOPTIONS
as described in 4.3.2 HTTP OPTIONS. This allows a client to perform anOPTIONS
request on an LDPCv to determine if it can explicitly mint versions. If the LDPCv does not supportPOST
, 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: UponPUT
orPATCH
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 onPOST
to any LDPCv associated with that LDPRv. The new LDPRm is contained in the LDPCv to which thePOST
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 arel="timemap"
link in theLink
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 theURL
parameter in aContent-Type: message/external-body
header. For example, given an LDPRm with URLhttp://example.org/some/memento
, the full header would beContent-Type: message/external-body; access-type=URL; expiration=1;
URL="http://example.org/some/memento"
5 Resource Authorization
Leads
5. Resource Authorization §
- To configure access control restrictions, implementations MUST follow the recommendations of Web Access Control [SOLIDWEBAC] with the following additional requirements:
5.1 ACLs are LDP RDF Sources §
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. - 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 theLink
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
orPUT
request to create a new LDPR MAY include arel="acl"
link in theLink
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 theLink
response header, following the pattern of [LDP] 4.2.1.6.
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 theLink
response header.
5.6 Cross-Domain Group 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 theLink
response header.
5.7 Append Mode §
- In the context of a Fedora implementation,
acl:Append
should be understood as operations that only append, such asPOST
ing to a container, or performing aPATCH
that only adds triples.
5.7.1 LDP-RS §
- When a client is allowed to perform
acl:Append
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 usingPUT
(see: 3.6.3 Creating resources with HTTP PUT)
- A
5.7.2 LDPC §
- In addition to requirements in 5.7.1 LDP-RS, when a client is allowed to perform
acl:Append
operations on an LDPC, aPOST
request MUST be allowed.
5.7.3 LDP-NR §
- When a client is allowed to perform
acl:Append
operations on an LDP-NR:- All
DELETE
,POST
, andPUT
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
- All
5.8 Access To Class §
- Notwithstanding [SOLIDWEBAC]'s lack of support for it, 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 theLink
header.
5.9 Inheritance and Default 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:
6 Notifications
Lead
6.2 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.3 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.
7 Binary Resource Fixity
Lead
- No labels