- 3.1.3-0: Implementations must allow the ldp:insertedContentRelation property to be set by default to an implementation defined value.
- 3.1.3-P: Implementations SHOULD allow the ldp:insertedContentRelation property to be set by default to ldp:MemberSubject.
- 3.10.2-D: A client may include the X-If-State-Token header field in a PUT request to make the request conditional on the resource's current state token matching the client's value.
- 3.2.1-B: In addition to the requirements of [LDP], an implementation ... may support the value http://www.w3.org/ns/oa#PreferContainedDescriptions for the Prefer header when making GET requests on LDPC resources.
- 3.6.1-A: Any LDP-RS must support PUT to update statements that are not server-managed triples (as defined in [LDP] 2). [LDP] 4.2.4.1 and 4.2.4.3 remain in effect. (This is a failure of the test suite)
- 4.1.1-A-1: If no LDPRm is appropriate to the Accept-Datetime value, implementations should return a 406 (Unacceptable).
- 4.1.2-B: Must support PUT for updating existing LDPRvs
- 4.2.6: LDPRm resources must support DELETE if DELETE is advertised in OPTIONS (https://github.com/fcrepo/fcrepo/pull/1790)
- 4.3.3.1-E: 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.
- 4.3.3.1-F: 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.
- 6.1: 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-A: The notification serialization MUST conform to the [activitystreams-core] specification, and each event MUST contain the IRI of the resource and the event type.
- 6.2-B: Wherever possible, data SHOULD be expressed using the [activitystreams-vocabulary].
|