3.1 General

• Empty section

3.1.1 LDP-NR creation

•  SHOULD create an LDP-NR if creation request includes NonRDFSource type Link in headers, regardless of Content-Type headers: Untested

3.1.2 LDP Containers

•  MUST be able to create LDP Containers: Tested in 3.3
•  MUST distinguish between triple types
•  MUST return 409 with constrainedBy Link in headers for ldp:contains membership predicate if server cannot distinguish between triple types (Contradictory?)
•  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.2 HTTP PATCH

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

3.3 HTTP POST

•  MUST be supported on LDP Collections
•  MUST include default interaction model in constrainedBy Link header (LDP-RS only)
•  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

empty

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 §

• An ACL for a controlled resource on a conforming server MUST itself be an LDP-RS.

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 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, 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 the Link 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 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 §

• 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 using PUT (see: 3.6.3 Creating resources with HTTP PUT)

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, a POST 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, 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

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 the Link 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:
  • 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.
  • The default ACL resource SHOULD be located in the same server as the controlled resource.

empty

7.1 What is fixity?

7.2 Transmission Fixity

•   MAY be verified by including a Digest header (defined in [RFC3230]) in POST
•  MAY be verified by including a Digest header (defined in [RFC3230])  in PUT
  

7.3 Persistance Fixity

• MAY retrieve the checksum of an LDP-NR by performing a HEAD request on it with the Want-Digest header
  
• MAY retrieve the checksum of an LDP-NR by performing a GET request on it with the Want-Digest header