Specify a Detectable, Optional Behavior for LDP-NR with message/external-body

[barmintor]

A new section of the spec should:

• recapitulate the use case for proxied content and justification for message/external-body in an informative preamble
• require LDP-C that support the creation of LDP-NR proxying content this way to advertise message/external-body;type=TYPE in the Accept-Post: response header for all supported values of TYPE
• require LDP-S receiving a PUT or POST request that would create or update a LDP-NR with an unsupported Content-Type: message/external-body;type=TYPE value of TYPE to respond with HTTP 415
• require LDP-S receiving a PUT or POST request that would create or update a LDP-NR with Content-Type: message/external-body;type=TYPE to guarantee that it can provide all GET and HEAD response headers required of LDP-NRs, or reject with a 4xx
• LDP-NR GET/HEAD responses SHOULD also include a Content-Location: header with a URI representation of the location of the referenced content.
• LDP-S SHOULD respect the expires parameter on message/external-body by either copying the data to other storage or rejecting the request with a 5xx

See also: https://github.com/fcrepo/fcrepo-specification/wiki/External-Content

[barmintor]

Re-posting because it was hard to see what ticket to close/PR under this tag.

[barmintor]

That seems like another issue, but I that sounds like 400 + constraints link to me?

[barmintor]

@acoburn I just wanted to flag something here: The specs for message/external-body don't require that there is no entity, just that the entity not be understood to be the message. That sounds weird, but the examples you'll see have a body, and the spec says that it should be ignored by the recipient. I just want to make sure that presence/absence of an entity isn't over-interpreted.