...

• 4.1.2 The Fcrepo spec doesn't mention it directly, but is there a conflict between the Memento "Content-Location" header and External File's "Content-Location"?  Can they both appear in the same response?
• 4.1.3.1 In supporting PUT to LDPRv , which would cause an LDPRm to be createdin order to create a LDPRm, is this just in support of included for server managed versions?  Or is PUT to an LDPRv intended to be addressable separately from a LDPR so as to trigger this behavior?
  • https://github.com/fcrepo/fcrepo-specification/issues/215
• 4.3.1 How do you determine what serializations are available for TimeMaps?  HEAD is not currently supported and is not in the Memento spec.
  
  • GET response formats are not actually listed in any other requests, only for Post and Patch.
  • However, it would likely be helpful to include info about HEAD and GET requests in the spec
    • https://github.com/fcrepo/fcrepo-specification/issues/223
• 4.3.1 What is the default serialization for GET requests to LDPCv?  The only required encoding is application/linked-format.
• 4.3.5 What is the expected behavior if a POST to an LDPCv is made which specifies a Memento-Datetime which that is already in use by an existing LDPRm for that LDPRv?
  
  • Having two memento's with the same datetime would result in datetime negotiation yielding indeterminate results.  
  • Ignore request and return a 412 response?  Delete and replace the existing version?
  • This could be something we decide - perhaps the new one overwrites the existing one?
• 4.3 There is currently no section defining that GET requests are required for LDPCv
  • What is the default serialization?
  4.5  Does the modeshape fcrepo currently have a server managed option for versioning? 
  • We need to make sure that a server managed scenario knows how to handle an LDPCv correctly - in that it doesn't version that resource if a user issues a PUT against it (as a user would if they want the original resource LDPRv to get versioned).

...

• 4.1.1 Add HTTP header Link: rel="timegate" referencing itself
  • versions will need to be accessible via the TimeGate, which is the LDPRv, versus TimeMap (which is what '/path/to/object/fcr:versions' currently is).  New URL for TimeGate access to versions?  Actually, a URL with fcr:versions in it could probably be returned, so long as negotiation on what the DateTime the user wants happens via the TimeGate, which is the LDPRv itself.  The timemap will still include the regular path to the LDPRm. 
• 4.1.2.1 include 'Vary: Accept-Datetime' header in response
• 4.2.3 When requesting a Memento or a TimeGate, a Link header must be returned with type of "original" which points to the URI of the original.  See 2.2.1. Link Relation Type "original"
• 4.2.3 "Memento-Datetime" should be returned when making a GET against a memento, indicating the timestamp of the memento
• 4.1.2.2 The TimeMap link may support include "from" and "until" attributes, do we want to provide /support these?  See 2.2.3. Link Relation Type "timemap"
• 4.1.2.1 How is fedora going to handle Accept-Datetime negotiation?  nearest version?  nearest version before requested time?  Or is it even going to be used this way?  See 3.1. Datetime Negotiation (first paragraph after example steps)
• 4.3.5 Are we going to need to take away the ability to provide version labels since they are not a part of the Memento API and not mentioned in the fcrepo speccontinue allowing the "slug" header on requests to create versions?
• It would be helpful to record which Datetime Negotiation pattern the modeshape implementation uses in documentation
  
  

...

• 2.2.1  - noted above in 4.2.3: on a GET/HEAD request to a LDPRm or TimeGate (the LDPRv, in this case) a Link header must be returned with relation type of 'original' which points to URI of the original resource (LDPRv)
• 2.2.2  - on a GET/HEAD request to a LDPR or LDPRm, a Link header must be returned with the relation type of 'timegate', which points to the the timegate for the resource.
  • multiple timegate Links are possible
• 2.2.3 - on a GET/HEAD request to a LDPR or LDPRm or TimeGate(which is the LDPR, in this case), a Link header must be returned with the relation type of 'timemap', which points to the timemap for the resource.
  • support "from" and "until" attributes?  These would cause the returned representation of the time map to only include the interval requested.
  • the link should make use the 'type' attribute to indicate the mime type of the timemap. 

Other questions

• Should LDPRv's return Content-Location and Memento-Datetime headers?  The later is required by https://tools.ietf.org/html/rfc7089#section-4.1.2 but may not make sense in fcrepo's usage.

Draft Tickets

Add versioning response headers to LDPRv HEAD/GET responses

...