Add Inbox Discovery on Client Error #253
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -688,6 +688,40 @@ <h2 property="schema:name">Notifications</h2> | |
| <p>A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> | ||
|
|
||
| <p>A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> | ||
|
|
||
| <section id="inbox-discovery-client-error" inlist="" rel="schema:hasPart" resource="#inbox-discovery-client-error"> | ||
| <h3 property="schema:name">Inbox Discovery on Client Error</h3> | ||
| <div datatype="rdf:HTML" property="schema:description"> | ||
| <p>This section extends the LDN protocol to allow the discovery of the Inbox URL of a target resource on client errors (HTTP responses with <code>4xx</code> status codes) [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>][<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p> | ||
|
There was a problem hiding this comment. Perhaps state why that is a problem / issue compared to other responses. |
||
|
|
||
| <p>Servers who want to advertise the Inbox URL in an HTTP response with a <code>4xx</code> status code, <code>MUST</code> do one of the following:</p> | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| <ul> | ||
| <li>Include the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</li> | ||
| <li>Return an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/ldp#inbox</code>. The subject of that relation is the target resource and the object is the Inbox.</li> | ||
| </ul> | ||
|
There was a problem hiding this comment. I still think that "the subject of the relation is the target resource" is confusing, because a relation can be thought of as an arrow, and the target of an arrow is the object of the arrow. So I think one should say "the subject of the relation is the resource which returned the error message" or something along those lines. There was a problem hiding this comment. I like the use of "target resource" as standard terminology across the protocol spec. There was a problem hiding this comment. "Target resource" is borrowed from RFC 7231, and I prefer not to add it to Protocol's definitions. The effective request URI (RFC 7230) is the reconstructed value of the HTTP request-target. The subject of the relation is same as the effective request URI. I've considered using effective request URI but figured that "target resource" was more readable - also stays close to LDN use. I'm open to using effective request URI or possibly even Request-URI (LDP terminology) but didn't want to associate the subject URI close to the "request". LDN uses target resource to refer to the entity with an inbox. There was a problem hiding this comment. The problem is that you can standardize meanings in a spec for that spec, but not across specs. If you have a spec that very clearly has a subject and a target then you can define the meaning of target. But otherwise it is a relational term, and you here have two resources that are targets here. The 401 resource which is a target of the initial request and the inbox which is the target of the following request. There was a problem hiding this comment. This is not discussing inbox as the target of the following request. Target is only mentioned in context of an entity with an inbox (equivalent to request-target in context of the subject of the relation) - which is what LDN says. |
||
|
|
||
| <p>Senders do the following to discover the Inbox URL in an HTTP response with a <code>4xx</code> status code:</p> | ||
|
There was a problem hiding this comment. I think the terminology of "Sender" comes from the LDN spec. Here have a client that received the 40x and suddenly turns into a "Sender". But the web server also was a Sender of the 40x resource. So it is confusing here. Instead of reifying roles like this one should continue to speak of the client that receives the 40x and wishes to send a notification to the inbox. There was a problem hiding this comment. I think I would use "Solid Clients" instead of "Senders" here and "Solid Servers" instead of "Servers" on line 697, for consistency. There was a problem hiding this comment. This is partly the reason why I mentioned where these requirements can live ie. in Solid Protocol or LDNx or whatever. The terminology is indeed based off LDN because the roles have intention. Neither is it true that any of these roles require a full blown LDP/Solid servers or applications. Minimum requirement for interop is what's expected from conforming classes (roles) of LDN.
A client may be requesting on behalf of an application implementing the "Sender" (eg. POST /bar/ ) or a "Consumer" (eg. GET /foo) roles. The client in and itself doesn't have any idea about "notifications". Only an application that's interested in sending a notification cares about the inbox.
That's inaccurate. A server is not "sending" as an "LDN Sender". Server is just responding to the request here about a target resource. A target resource that wants advertise an inbox only needs to conform to LDN's requirements. It doesn't need to do anything else. Having said that, I'm generally fine to switch from LDN terminology to using Solid-specific terminology but the intention with this section wasn't to tightly couple it with Solid. There was a problem hiding this comment.
Sorry, I think I have been a bit unclear. I am not suggesting to say Sender instead of Server. As I understand from https://www.w3.org/TR/ldn/#abstract, if keeping the LDN terminology, I would:
If adopting the Solid terminology, I would switch to "Solid Clients" for line 697 and "Solid Servers" for line 704. I am not sure which of the two options is the best, but given the context (solid protocol spec), I would probably switch to the Solid terminology. There was a problem hiding this comment. There are too many roles at play here. I would just stick to client and 40x resource, and explain everything in those terms. No need to bring in vocabulary from other specs. The reader should not have to read those specs to understand what is going on, as it is pretty simple. Instead of
write
There was a problem hiding this comment.
No. Receiver is not responsible of the target resource or has anything to do with advertising target resource's inbox.
No. Consumer is not relevant here because the context is about sending a notification to an inbox to resolve an error. See #253 (comment) |
||
|
|
||
| <ul> | ||
| <li>Use the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</li> | ||
| <li>Parse an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/ldp#inbox</code>. The subject of that relation is the target resource and the object is the Inbox.</li> | ||
| </ul> | ||
|
There was a problem hiding this comment. This passage seems to just repeat the previous one from the client's perspective. I think the client's perspective should not be limited to parsing the content, but what it can do with the given content. There was a problem hiding this comment. Also I guess that the LDN spec says everything there is to be said about LDN in other documents. We seem to be considering 40x return codes especially here and the meaning of an LDN in that situation. There was a problem hiding this comment. The intention is to discover the Inbox. Assuming that if an implementation didn't want to send a notification towards resolving the error, it wouldn't bother to get a hold of the Inbox (where available). The intention to send a notification is a separate step that needs to incorporate additional context - intentionally not specified here to keep the protocol flexible - and the requirement for Sender is already defined. An application can have multiple roles. |
||
|
|
||
| <p>These may be carried out in either order, but if the first fails to result in an Inbox the second MUST be tried.</p> | ||
|
|
||
| <figure class="listing example" id="discovery-put-example-403" rel="schema:hasPart" resource="#discovery-turtle-example-webid"> | ||
| <p class="example-h">Discovery example: Client error</p> | ||
| <pre about="#discovery-put-example-403" property="schema:description" typeof="fabio:Script"><code>PUT /article HTTP/1.1</code> | ||
| <code>Host: example.org</code> | ||
| <code>Content-Type: text/html;charset=utf-8</code> | ||
| <code></code> | ||
| <code>HTTP/1.1 403 Forbidden</code> | ||
| <code>Link: <http://example.org/inbox/> rel="http://www.w3.org/ns/ldp#inbox"</code></pre> | ||
| <figcaption>Discovering an Inbox in the response of a rejected request.</figcaption> | ||
| </figure> | ||
| </div> | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| </section> | ||
| </div> | ||
| </section> | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"by implementing the Receiver part" - the receiver part of the spec I guess. It's a bit oddly phrased.
Can on not just say: A Solid server must have an ldn:inbox to which notifications can be sent?
"And make inbox content available" - To whom?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to revise outside of this PR, but just to respond:
It is not that "a Solid server must have an ldn:inbox.." but that server needs to conform to LDN's requirements (receiver) for inbox resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am happy with this introspection pattern for enabling User Agents deduce the locations of special resources e.g., inbox folders.