Skip to content

Commit

Permalink
Merge pull request #1 from awoods/issue-118
Browse files Browse the repository at this point in the history
Move 'External Binary Content' section into Section#3
  • Loading branch information
barmintor authored Jun 8, 2017
2 parents f1ba361 + ba514aa commit b10a22f
Showing 1 changed file with 65 additions and 73 deletions.
138 changes: 65 additions & 73 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -384,6 +384,71 @@ <h2>HTTP HEAD</h2>
as specified in [[!RFC7231]] <a href='https://tools.ietf.org/html/rfc7231#section-4.3.2'>section 4.3.2</a>.
</p>
</section>

<section id='external-content'>
<h3>External Binary Content</h3>
<p id='message-external-body-variability' class='informative'>
<blockquote>
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 <code>Content-Type: message/external-body</code>
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 <code>Content-Type</code> value will signal a
name or address at which the content might be retreived. The <code>url</code>
and <code>local-file</code> type values motivate this specification, but a Fedora server
may support any type parameters per the requirements for advertisement and
rejection specified here.
</blockquote>
</p>
<p id='message-external-body-accept-post'>
Fedora servers that support LDP-NR with <code>message/external-body</code>
MUST advertise that support in the <code>Accept-Post</code> response
header for each supported <code>type</code> parameter of supported <code>Content-Type</code> values.
</p>
<p id='message-external-body-unsupported-type'>
Fedora servers receiving requests that would create or update a LDP-NR
with a <code>message/external-body</code> with an unsupported
<code>type</code> parameter MUST respond with HTTP 415 UNSUPPORTED MEDIA TYPE.
In the case that a Fedora server does not support external LDP-NR content, all
<code>message/external-body</code> messages must be rejected with HTTP 415.
</p>
<p id='message-external-body-response-headers'>
Fedora servers receiving requests that would create or update a LDP-NR
with a <code>message/external-body</code> MUST NOT accept the
request if it cannot guarantee all of the response headers required
by the LDP-NR interaction model in this specification.
</p>
<p id='external-content-content-location'>
LDP-NR GET and HEAD responses SHOULD include a <code>Content-Location</code> header with a URI
representation of the location of the external content if the Fedora server is proxying
the content.
</p>
<p id='external-content-expires'>
Per [[!RFC1521]], all <code>Content-Type: message/external-body</code> values
MAY include an <code>expiration</code> parameter. Fedora servers receiving requests that
would create or update a LDP-NR with a <code>message/external-body</code> content
type SHOULD respect the <code>expiration</code> parameter, if present, by copying
content. If the <code>expiration</code> parameter cannot be accommodated, the request MUST be rejected
with a 4xx or 5xx status code. Following [[!LDP]] <a href="https://www.w3.org/TR/ldp/#ldpr-gen-pubclireqs">4.2.1.6</a>
and <a href="https://www.w3.org/TR/ldp/#ldprs-put-servermanagedprops">4.2.4.3</a>,
4xx responses MUST be accompanied by a <code>Link</code> header
with <code>http://www.w3.org/ns/ldp#constrainedBy</code> relation.
</p>
<section id='external-content-caveats' class='informative'>
<h4>Referenced RDF Content in Mandatory LDP Serializations</h4>
<p>
This specification takes no position on the use of <code>message/external-body</code>
to create or update LDP-RS with ttl or json-ld.
</p>
<h4>Proxied Content vs Redirected Content</h4>
<p>
This specification assumes that clients interested in resolving a <code>type='url'</code>
or other value without the Fedora server as an intermediary (effectively, redirection as opposed
to proxying) will be able to negotiate the <code>Content-Location</code> response header
value from a HEAD request.
</p>
</section>
</section>
</section>

<section id="resource-versioning">
Expand Down Expand Up @@ -884,79 +949,6 @@ <h4>A basic notification with some additional detail</h4>
</section>
</section>

<section id='external-content'>
<h3>External LDP-NR Content</h3>
<p class='informative'>
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 <code>Content-Type: message/external-body</code>
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 <code>Content-Type</code> value will signal a
name or address at which the content might be retreived. The <code>url</code>
and <code>local-file</code> type values motivate this specification, but a Fedora server
may support any type parameters per the requirements for advertisement and
rejection specified here.
</p>
<section id='message-external-body-accept-post'>
<p>
Fedora servers that support LDP-NR with <code>message/external-body</code>
MUST advertise that support in the <code>Accept-Post</code> response
header for each supported <code>type</code> parameter of supported <code>Content-Type</code> values.
</p>
</section>
<section id='message-external-body-unsupported-type'>
<p>
Fedora servers receiving requests that would create or update a LDP-NR
with a <code>message/external-body</code> with an unsupported
<code>type</code> parameter MUST respond with HTTP 415 UNSUPPORTED MEDIA TYPE.
In the case that a Fedora server does not support external LDP-NR content, all
<code>message/external-body</code> messages must be rejected with HTTP 415.
</p>
</section>
<section id='message-external-body-response-headers'>
<p>
Fedora servers receiving requests that would create or update a LDP-NR
with a <code>message/external-body</code> MUST NOT accept the
request if it cannot guarantee all of the response headers required
by the LDP-NR interaction model in this specification.
</p>
</section>
<section id='external-content-content-location'>
<p>
LDP-NR GET and HEAD responses SHOULD include a <code>Content-Location</code> header with a URI
representation of the location of the external content if the Fedora server is proxying
the content.
</p>
</section>
<section id='external-content-expires'>
<p>
Per [[!RFC1521]], all <code>Content-Type: message/external-body</code> values
MAY include an <code>expiration</code> parameter. Fedora servers receiving requests that
would create or update a LDP-NR with a <code>message/external-body</code> content
type SHOULD respect the <code>expiration</code> parameter, if present, by copying
content. If the <code>expiration</code> parameter cannot be accommodated, the request MUST be rejected
with a 4xx or 5xx status code. Following [[!LDP]] <a href="https://www.w3.org/TR/ldp/#ldpr-gen-pubclireqs">4.2.1.6</a>
and <a href="https://www.w3.org/TR/ldp/#ldprs-put-servermanagedprops">4.2.4.3</a>,
4xx responses MUST be accompanied by a <code>Link</code> header
with <code>http://www.w3.org/ns/ldp#constrainedBy</code> relation.
</p>
</section>
<section id='external-content-caveats' class='informative'>
<h4>Referenced RDF Content in Mandatory LDP Serializations</h4>
<p>
This specification takes no position on the use of <code>message/external-body</code>
to create or update LDP-RS with ttl or json-ld.
</p>
<h4>Proxied Content vs Redirected Content</h4>
<p>
This specification assumes that clients interested in resolving a <code>type='url'</code>
or other value without the Fedora server as an intermediary (effectively, redirection as opposed
to proxying) will be able to negotiate the <code>Content-Location</code> response header
value from a HEAD request.
</p>
</section>
</section>

<section id="privacy">
<h2>Privacy Considerations</h2>
<p>
Expand Down

0 comments on commit b10a22f

Please sign in to comment.