You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »


The table below is derived from the following document

Fedora API Spec and Delta Document Verification


Issue DescriptionSpec ReferencePriorityDifficultyStory PointsRelated JIRAsSprintDepends onNotes

Change the PreferInboundReferences URI in Prefer header

from http://fedora.info/definitions/v4/repository#InboundReferences to the one defined in the spec (ie http://fedora.info/definitions/fcrepo#PreferInboundReferences)

3.2.1111

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




HTTP Head does not return the same headers as if the request were a GET3.3311

Unable to locate Jira server for this macro. It may be due to Application Link configuration. (2676 is a duplicate - confirm and remove)

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




POSTing a LDP-NR does not return correct constrainedBy Link header3.5211

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




MUST return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
  • Though the message coming back in the case of an attempt to move from RDFSource to NonRDFSource says "Resource Already Exists" instead of returning a constrained by header
  • Same message is returned trying to move from ldp:Container to an ldp:DirectContainer or ldp:BasicContainer or ldp:Container

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

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




Using PATCH it is currently possible to add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource. This should not 3.7.1122

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




Replace current Link rel="type" Header with memento specified link (i.e. http://mementoweb.org/ns#OriginalResource) 4.1111

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




The Accept-Datetime header is used to request a past state, exactly as per [RFC7089section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm4.1.1122

LDPm GET
If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).4.1.1121



The response to a GET request on an LDPRv must include the following headers


4.1.1


Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




LDPm 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 [RFC7089section 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 the Link header.
4.2.1133

Unable to locate Jira server for this macro. It may be due to Application Link configuration.


LDPCv: POST

LPPm OPTIONS

  •  An implementation must support OPTIONS.
  •  A response to an OPTIONS request must include Allow: 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.2111

LDPm GET
LDPm: PUT, POST, and PATCH must return 405 method not allowed4.2.3-5111

Unable to locate Jira server for this macro. It may be due to Application Link configuration.


LDPm GET

LDPm: DELETE

The server is responsible for all behaviors implied by the LDP-containment of the LDPRm.

4.2.6


Unable to locate Jira server for this macro. It may be due to Application Link configuration.



This is a MAY: Are we planning to implement?

LDPCv : 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. Currently the <http://fedora.info/definitions/v4/repository#TimeMap> is being used.


4.3.2122

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration. (may be closed - depending on approach to fcrepo-2617)

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




LDPCv: Disallow PUT and PATCH4.3.2111



LDPCv: POST

  • POST 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. Any request body must be ignored.
  • A Memento-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 the Memento-Datetime request header.
4.3.3


Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.


Server Managed Version Creation,

Client Managed Version Creation


LDPCv: DELETE:

Delete of an LDPCv must remove the LDPCv and removing the versioning interaction model from the original LDPRv.

4.3





Are we planning to support DELETE?

Vary :

When an LDPCv supports POST, and allows clients to specify a datetime for created URI-Ms, Vary-Post/Vary-Put: Memento-Datetime.

4.4111

LDPc POST
Server Managed Version Creation4.5.1


Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.




Client Managed Version Creation4.5.2





Do we plan to support client managed as well?


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 the URL parameter in a Content-Type: message/external-body header. For example, given an LDPRm with URL http://example.org/some/memento, the full header would be 
Content-Type: message/external-body; access-type=URL; expiration=1;
    URL="http://example.org/some/memento"

4.5.3





Do we plan to support this? And if so due to changes in use of "expiration" the spec will likely change.














































Critical Non-Alignment Issues to be included in the 5.0.0 release

JiraPriorityDepends OnStory Points















  • No labels