Page History

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

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

• 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 LDPCvmust 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  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  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

• Implementations MUST follow the recommendations of Web Access Control

• • acl:agentGroup appears to be implemented, per wiki documentation
  • 

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

    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)

• When a client is allowed to perform acl:Append but not acl:Writeoperations 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 (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

    Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 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.