From 9557b0a64792b543a8141d11e452d31a6dc198be Mon Sep 17 00:00:00 2001 From: Benjamin Armintor Date: Sun, 28 May 2017 17:21:37 -0400 Subject: [PATCH] specify use of message/external-body for referenced content fixes #118 - fix formatting and terminology issues in discussion - Move 'External Binary Content' section into Section#3 'Resource Management' --- index.html | 94 +++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 76 insertions(+), 18 deletions(-) diff --git a/index.html b/index.html index a083989..b2a5d67 100644 --- a/index.html +++ b/index.html @@ -259,12 +259,12 @@

LDP-NRs

A HTTP POST request that includes an unsupported Digest type (as described in [[!RFC3230]]), SHOULD be rejected with a 400 Bad Request response.

-

- Implementations SHOULD support Content-Type: message/external-body extensions for - request bodies for HTTP POST that would create LDP-NRs. This content-type requires - a complete Content-Type header that includes the location of the external body, e.g - Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\", - as defined in [[!RFC2017]]. +

+ Implementations may support Content-Type: message/external-body extensions for + request bodies for HTTP POST that would create LDP-NRs. + This content-type requires a complete Content-Type header that includes the location + of the external body, e.g Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\", + as defined in [[!RFC2017]]. Requirements for this interaction are detailed in External LDP-NR Content.

@@ -294,12 +294,12 @@

LDP-NRs

A HTTP PUT request that includes an unsupported Digest type (as described in [[!RFC3230]]), SHOULD be rejected with a 400 Bad Request response.

-

- Implementations MUST support Content-Type: message/external-body extensions - for request bodies for HTTP PUT to LDP-NRs. This content-type requires a - complete Content-Type header that includes the location of the external body, e.g - Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\", - as defined in [[!RFC2017]]. +

+ Implementations may support Content-Type: message/external-body extensions for + request bodies for HTTP PUT that would create LDP-NRs. + This content-type requires a complete Content-Type header that includes the location + of the external body, e.g Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\", + as defined in [[!RFC2017]]. Requirements for this interaction are detailed in External LDP-NR Content.

@@ -372,12 +372,7 @@

LDP-RSs

LDP-NRs

GET requests to any LDP-NR MUST correctly respond to the Want-Digest header - defined in [[!RFC3230]] unless the Content-Type of the LDP-NR is a - message/external-body extension. -

-

- GET requests to a LDP-NR with Content-Type: message/external-body, MUST result - in an HTTP 3xx redirect message redirecting to the external URL. + defined in [[!RFC3230]].

@@ -389,6 +384,69 @@

HTTP HEAD

as specified in [[!RFC7231]] section 4.3.2.

+ +
+

External Binary Content

+
+ Non-normative note: Variability among client types and locations may mean that LDP-NR + content is addressed in ways that are external to the Fedora server but not resolvable + by all clients. This specification describes the use of Content-Type: message/external-body + values to signal, on POST or PUT, that the Fedora server should should not consider the + request entity to be the LDP-NR's content, but that a Content-Type value will signal a + name or address at which the content might be retreived. The url + and local-file type values motivate this specification, but a Fedora server + may support any type parameters per the requirements for advertisement and + rejection specified here. +
+

+ Fedora servers that support LDP-NR with message/external-body + MUST advertise that support in the Accept-Post response + header for each supported type parameter of supported Content-Type values. +

+

+ Fedora servers receiving requests that would create or update a LDP-NR + with a message/external-body with an unsupported + type parameter MUST respond with HTTP 415 UNSUPPORTED MEDIA TYPE. + In the case that a Fedora server does not support external LDP-NR content, all + message/external-body messages must be rejected with HTTP 415. +

+

+ Fedora servers receiving requests that would create or update a LDP-NR + with a message/external-body MUST NOT accept the + request if it cannot guarantee all of the response headers required + by the LDP-NR interaction model in this specification. +

+

+ LDP-NR GET and HEAD responses SHOULD include a Content-Location header with a URI + representation of the location of the external content if the Fedora server is proxying + the content. +

+

+ Per [[!RFC1521]], all Content-Type: message/external-body values + MAY include an expiration parameter. Fedora servers receiving requests that + would create or update a LDP-NR with a message/external-body content + type SHOULD respect the expiration parameter, if present, by copying + content. If the expiration parameter cannot be accommodated, the request MUST be rejected + with a 4xx or 5xx status code. Following [[!LDP]] 4.2.1.6 + and 4.2.4.3, + 4xx responses MUST be accompanied by a Link header + with http://www.w3.org/ns/ldp#constrainedBy relation. +

+
+

Referenced RDF Content in Mandatory LDP Serializations

+

+ This specification takes no position on the use of message/external-body + to create or update LDP-RS with ttl or json-ld. +

+

Proxied Content vs Redirected Content

+

+ This specification assumes that clients interested in resolving a type='url' + or other value without the Fedora server as an intermediary (effectively, redirection as opposed + to proxying) will be able to negotiate the Content-Location response header + value from a HEAD request. +

+
+