specify use of message/external-body for referenced content #121

barmintor · 2017-05-28T21:22:09Z

fixes #118

barmintor · 2017-05-28T21:23:16Z

I'll have limited ability to respond to this thread this week, please feel free to add commits as necessary.

ajs6f · 2017-05-28T21:32:21Z

index.html

-            <code>Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\"</code>,
-            as defined in [[!RFC2017]].
+          <p class='informative'>
+            Implementations may support <code>Content-Type: message/external-body</code> extensions for


may => MAY?

ajs6f · 2017-05-28T21:33:42Z

index.html

+      <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 LDP-S but not resolvable


Where is the def'n for LDP-S? What is it?

I am guessing LDP-S is intended to mean LDP Server... which should probably be the Fedora server...as the server is probably not exactly accurate in this situation.

I agree: s/LDP-S/the Fedora server/

ajs6f · 2017-05-28T21:34:36Z

index.html

+        content is addressed in ways that are external to LDP-S but not resolvable
+        by all clients. This specification describes the use of <code>message/external-body</code>
+        Content-Type value to signal, on POST or PUT, that the LDP-S should should not consider the
+        request entity to be the LDP-NR's content, but that a Content-Type value will signal a


Content-Type => <code>Content-Type</code>. There are several other missing <code> tags.

ajs6f · 2017-05-28T21:36:38Z

index.html

+      </section>
+      <section id='external-content-content-location'>
+        <p>
+          LDP-NR GET and HEAD responses SHOULD include a Content-Location: header with a URI


Doesn't this destroy the "proxying for authZ" use case?

Only if the URIs can be resolved by the client, and also doesn't enforce it's own access control. If either or both of things aren't true, then the server can safely expose the content location URI to the client, even when proxying for authZ.

When not proxying for authZ, exposing the content location URI allows the client to disintermediate the server if it wishes for performance or other reasons.

Exactly-- the server is forced to trust the client (trust that the client won't resolve the URI or that the client will enforce the same authZ), so the use case is unsupported if this SHOULD is executed. (It's unusual, to say the least, to make authZ depend on a trustworthy client.) It's not of great interest to me, because my institution does not require this use case, and we will be "implementing" by returning 415s in all cases, so I won't pursue it further.

awoods · 2017-05-30T21:09:12Z

index.html

+      <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 LDP-S but not resolvable


I am guessing LDP-S is intended to mean LDP Server... which should probably be the Fedora server...as the server is probably not exactly accurate in this situation.

awoods · 2017-05-30T21:39:47Z

index.html

+      </section>
+      <section id='external-content-expires'>
+        <p>
+          Per [[!RFC2017]], all <code>message/external-body</code> Content-Type values


I am seeing no mention of expires or expiration in RFC2017... but do in RFC1521

awoods · 2017-05-30T21:41:42Z

index.html

+          may include an <code>expires</code> parameter. LDP-S receiving requests that
+          would create or update a LDP-NR with a <code>message/external-body</code> content
+          type SHOULD respect the <code>expires</code> parameter, if present, by copying
+          content. If the expires parameter cannot be accomodated, the request MUST be rejected


typo: accomodated should be accommodated

awoods · 2017-05-30T21:43:01Z

index.html

+          would create or update a LDP-NR with a <code>message/external-body</code> content
+          type SHOULD respect the <code>expires</code> parameter, if present, by copying
+          content. If the expires parameter cannot be accomodated, the request MUST be rejected
+          with a 4xx or 5xx status code.


A constrainedby link header would also be useful here.

awoods · 2017-05-30T21:47:16Z

index.html

+          This specification assumes that clients interested in resolving a <code>type='url'</code>
+          or other value without the LDP-S 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.


Not necessarily a question for the spec, but what would the expected response body be on a GET request of a redirect LDP-NR? ... if we are expecting the client to figure out that an implicit redirect is available via inspection of the Content-Location header.

I read this paragraph as specifying a way for a client (at its option) to use HEAD to decide whether it can go fetch remote content from the Content-Location itself, avoid a default proxy action on GET. It seems that from https://tools.ietf.org/html/rfc7231#section-3.1.4.2 the response to GET should be either:

200, Content-Location and content in body to proxy

3xx, Content-Location and Location to same URI to redirect (no body)

zimeon · 2017-06-01T14:57:34Z

This PR seems to be heading in the right direction, it would be really helpful to have a pass that fixes the minor formatting issues so that we can focus on the more substantive ones

birkland · 2017-06-06T19:11:48Z

index.html

+          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


Is the presence of expiration intended to be a mechanism by which a client can instruct the repository to durably persist ephemeral content (see fedora-tech thread?

Sorry, I simply find this section hard to understand what this section means from a high level. It suggests that a server SHOULD copy content if an expiration parameter is present, but it could do something else, Including (as the above thread suggests) "expire the resource", which I understand as making the LDP-NR content unavailable once the expiration date is met. So is it consistent with the spirit of this section that one implementation might interpret expiration as "make this ephemeral content durable", and another implementation might interpret it as "expire the content at the appropriate time"? It may be a stupid question, but I'd really appreciate some help from the editors to help understand how to interpret this section.

From the MODE implementation, the answer to your first comment is, yes.
If there is no expectation that this be implemented in any other way, I would suggest we tighten the language to more clearly define what the expiration parameter means/requires.

Great, I believe some tightening and/or non-normative text is necessary if that's the case

Should I create a new issue after this is merged to address this?

Yes, please open that ticket.

awoods · 2017-06-07T16:22:01Z

index.html

@@ -889,6 +884,79 @@ <h2 class='informative'>Vary</h2>
      </section>
    </section>

+    <section id='external-content'>


Besides the boilerplate text (Conformance, Terminology, X-Considerations, Acknowledgements, References) the top-level specification elements are the core Fedora capabilities:

Resource Management

Resource Versioning

Binary Resource Fixity

Resource Authorization

Notifications

With that in mind, I would expect this new section (External LDP-NR Content) to be a sub-element under Resource Management, instead of a new top-level specification element.

awoods · 2017-06-07T16:24:05Z

index.html

@@ -889,6 +884,79 @@ <h2 class='informative'>Vary</h2>
      </section>
    </section>

+    <section id='external-content'>
+      <h3>External LDP-NR Content</h3>
+      <p class='informative'>


This informative annotation does not appear to have a visual effect in the rendered spec.

dannylamb · 2017-06-09T17:18:36Z

index.html

-            as defined in [[!RFC2017]].
+          <p class='informative'>
+            Implementations may support <code>Content-Type: message/external-body</code> extensions for
+            request bodies for HTTP <code>POST</code> or <code>PUT</code> that would create <a>LDP-NR</a>s.


Do we need to have both verbs here? Can we just have only POST in the POST section and PUT in the PUT section?

If this prevents you from approving, I can get to it sometime this weekend.

dannylamb · 2017-06-09T17:29:35Z

@barmintor I can pull on pull if you're strapped for time.

barmintor · 2017-06-09T17:34:09Z

I wouldn't worry about it, it's the commit-merge-squash-travis dance that I'll need to wait to do.

…

On Fri, Jun 9, 2017 at 1:29 PM, dannylamb ***@***.***> wrote: @barmintor <https://github.com/barmintor> I can pull on pull if you're strapped for time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#121 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHUNPuSzNTCxcCsWJoknmdX_eLkqv2mks5sCYD_gaJpZM4Now7t> .

dannylamb · 2017-06-09T17:42:50Z

@barmintor ok, nbd

fixes fcrepo#118 - fix formatting and terminology issues in discussion - Move 'External Binary Content' section into Section#3 'Resource Management'

ajs6f reviewed May 28, 2017

View reviewed changes

awoods requested changes May 30, 2017

View reviewed changes

escowles approved these changes Jun 6, 2017

View reviewed changes

birkland reviewed Jun 6, 2017

View reviewed changes

awoods requested changes Jun 7, 2017

View reviewed changes

barmintor force-pushed the issue-118 branch from 3a99c18 to 021783f Compare June 9, 2017 15:23

awoods approved these changes Jun 9, 2017

View reviewed changes

awoods requested review from zimeon and dannylamb June 9, 2017 15:28

dannylamb reviewed Jun 9, 2017

View reviewed changes

zimeon approved these changes Jun 10, 2017

View reviewed changes

specify use of message/external-body for referenced content

9557b0a

fixes fcrepo#118 - fix formatting and terminology issues in discussion - Move 'External Binary Content' section into Section#3 'Resource Management'

barmintor force-pushed the issue-118 branch from 021783f to 9557b0a Compare June 11, 2017 16:03

awoods merged commit 1fc6bb1 into fcrepo:master Jun 11, 2017

cjcolvar mentioned this pull request Jun 20, 2017

ActiveFedora External File PR avalonmediasystem/avalon#1859

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

specify use of message/external-body for referenced content #121

specify use of message/external-body for referenced content #121

barmintor commented May 28, 2017

barmintor commented May 28, 2017

ajs6f May 28, 2017

ajs6f May 28, 2017

awoods May 30, 2017

zimeon Jun 1, 2017

ajs6f May 28, 2017 •

edited

Loading

ajs6f May 28, 2017

escowles May 28, 2017

ajs6f May 28, 2017

awoods May 30, 2017

awoods May 30, 2017

awoods May 30, 2017

awoods May 30, 2017

awoods May 30, 2017

zimeon Jun 1, 2017

zimeon commented Jun 1, 2017

birkland Jun 6, 2017

birkland Jun 7, 2017

awoods Jun 7, 2017

birkland Jun 8, 2017

birkland Jun 9, 2017

barmintor Jun 9, 2017

awoods Jun 7, 2017

awoods Jun 7, 2017

dannylamb Jun 9, 2017

barmintor Jun 9, 2017

dannylamb commented Jun 9, 2017

barmintor commented Jun 9, 2017 via email

dannylamb commented Jun 9, 2017

specify use of message/external-body for referenced content #121

specify use of message/external-body for referenced content #121

Conversation

barmintor commented May 28, 2017

barmintor commented May 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajs6f May 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zimeon commented Jun 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dannylamb commented Jun 9, 2017

barmintor commented Jun 9, 2017 via email

dannylamb commented Jun 9, 2017

ajs6f May 28, 2017 •

edited

Loading