Do we intent to require the constraints document link on all responses?

[zimeon]

In the spec sec 3.1.3, we reiterate LDP 4.2.1.6 that a link to the constraints document SHOULD/MUST be added to responses in the case that the server constrains cause a failure (oddly we say SHOULD when I think it is MUST per LDP). LDP says the header MAY be added to other responses, we are silent on that.

However, in spec sec 3.5 POST we say:

The default interaction model that will be assigned when one is not specified must be recorded in a constraints document.

without any mention of whether one is expected to be able to find that document without making a failing request. One interpretation of this is that the constrainedBy link must be present on successful response as well (for POST at least) and this is the interpretation taken by the test suite in test 3.5-B. It is certainly legal for an implementation to do that but the spec seems unclear at present. I think there are two options:

• Change spec sec 3.1.3 to say that Fedora implementations should return a link to the constraints doc in all responses
• Clarify spec sec 3.5 to say that Fedora implementations are required to return a link to the constraints doc only on failure responses

[awoods]

I believe the idea with 3.5 HTTP POST (you can confirm, @barmintor) is that a "constrainedBy" Link header will be returned on creation requests indicating the interaction module under which a new resource will be constrained.

That perspective would imply that a "constrainedBy" Link would be returned on failure responses and creation requests, but not necessarily on successful read requests.

[barmintor]

I think the first interpretation (of 3.1.3) would still only require you to return such a document for resources advertising POST in their OPTIONS response, no?

I the @awoods reading is a valid one, too - do we really need to choose between them?

RE: @zimeon's point about the SHOULD in this spec vs the MUST in LDP - I'm having intense deja vu reading that observation. Have we talked about this before?

[zimeon]

If we want to have a constrainedBy link in responses for both failures and successful creation requests to POST (for resources that support it) then to be consistent the same requirement should be added into create with PUT. Still feels a little odd to have the link on all failures that are constrained, and two create cases. Since this is not (likely) a machine readable document I also don't really see the point on success.

As for @barmintor's deja vu, it is all mixing together for me, I don't recall. Thinking about it now I don't see why we would loosen LDP's MUST.

[escowles]

If the intent of the constraints doc in 3.5 POST is for clients to know what will happen if they create a resource without specifying an interaction model, then it seems reasonable for all containers to include the constraints doc.

[awoods]

I could be ok with either of two options:

1. Add constrainedBy Link on all responses
2. Only add constrainedBy Link on failures... since resources do have rdf:type properties

[zimeon]

I prefer option 2, I do not like the idea of expanding the requirement for a link to the constraints document to some subset of successful requests, or to all requests. The constrains document does not provide an effective auto-discovery mechanism because it is not machine readable. I think the only supported auto-discovery mechanism is to create a container with no interaction model specified, and see what model it gets (else you are down to out-of-band means).

I propose striking the second sentence from:

3.5 HTTP POST § Any LDPC except Version Containers (LDPCv) must support POST ([LDP] 4.2.3 / 5.2.3). The default interaction model that will be assigned when one is not specified must be recorded in a constraints document.

which removes any ambiguity about expecting a constraints document link on successful requests.

[dannylamb]

Late to the party but won't the interaction model be returned as a rel="type" link header if you HEAD the Location that gets returned for a successful POST?

It's a two-step, which I know irks people, but the information is there in an already specified manner. I'm :+1: on striking the language @zimeon is suggesting.

[barmintor]

We should delete that 3.5 bit, I agree.

[zimeon]

Agreement on 2018-08-29 Editors' Call that we will delete the second sentence of 3.5.